Getting Disciplined Agile Certified

As a Agile coach, I believe it is my responsibility to provide the best guidance to the organizations and teams that I work with to him them gain mastery of agile practices.  In most of my engagements, the first step is to provide initial training to the team  to help them gain the knowledge they need to apply techniques such as Scrum, XP, DAD, SAFe SPC, Lean and Continuous Delivery (sometimes referred to as DevOps).

Why get certified?

While certifications are no guarantee that a coach such as myself as the appropriate knowledge or experience to help, obtaining certifications along with the ability to demonstrate projects and programs where the agile techniques learned have helped is often a great way to ensure this.  As such, since 2008 I have embarked on a continuous learning journey to improve my skills and experience through certifications. Presently, I hold certifications as CSM, PMP, SAFe and am in the process of obtaining my DAD certifications.

People who are learning and attempting to mastering new skills often pass through three quite different stages of behavior: followingdetaching, and fluent.  The Disciplined Agile Consortium recently has established a certified approach based on a principled, Shu-Ha-Ri strategy.

Shu-Ha-Ri

Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes from Japanese martial arts (particularly Aikido), and Alistair Cockburn introduced it as a way of thinking about learning techniques and methodologies for software development.

The word “Shuhari” roughly translates to “first learn, then detach, and finally transcend.”  

In this approach, the consortium has established four certification levels:

  1. Disciplined Agilist-White Belt(Shu)
  2. Disciplined Agilist-Yellow Belt(Shu)
  3. Disciplined Agilist-Green Belt(Ha)
  4. Disciplined Agilist-Black Belt (Ri)

References

About the Author

Reedy has over 20 years of experience in Solution Architecture, and  IT/software development where he has worked in a variety of roles such as Business Analyst, Tester, Development Project Manager, Consultant and Agile Coach.   He provides thought leadership and coaching that focus on helping medium and large companies achieve organizational agility using a combination of Lean, Agile, DevOps and Business Continuous Delivery practices.

Opinions represent those of the author and not of any other organization.  The content  shared on this site does not imply endorsement of specific agile or lean methods or practices beyond those described on the official IBM websites.

 

 

 

 

rfeggins:

Working with new teams is always fun. Here are some Agile Coaching essentials

Originally posted on Reedy Feggins Jr:

Picking an Agile Coach is often a trying task for most organizations. What is an Agile Coach and what qualities make a good one. These are just some of the common questions most organizations have.

As it takes time to really adopt new practices and behaviors, the Agile Coach must be more than just a recently trained ScrumMaster that usually “swoops in” to deliver words of wisdom and then makes a sharp exit. The coach must be able to spend time with the team to help them to become more aware of their workflow and how to collaborate effectively.

In a nutshell, an “Agile Coach” must help the project leaders, and the teams learn how to successfully apply the required agile practices.  The coach must be familiar with how each agile role (e.g.,  Team, Product Owners, and ScrumMaster) are impacted by an Agile Transformation as well as the…

View original 517 more words

Originally posted on Reedy Feggins Jr:

Successful agile transformations often times require successful agile pilot projects. Often time a successful initial pilot is the most critical step early in a successful enterprise agile adoption. If the pilot project is a success then the organization has a tangible example to get behind but if the project fails (or just fails to meet expectations) then the entire agile initiative could be derailed by critics. Because no one really likes change unless they are driving it.

Here is a presentation a I delivered a few years ago on running a successful agile pilot Succeeding with your First Agile Pilot Project

The presentions covers

  • Picking the Right Agile Pilot
  • Choosing the best set of Agile Practices to adopt
  • Providing the necessary education, tooling and governance
  • Learn and Adapt from the pilot

View original

What is DevOps?

Posted: July 22, 2014 in Continuous Delivery

rfeggins:

Here is a good article on the five key practices for what IBM considers DevOps. They are:

Plan, Track, and Version Everything
Dashboard Everything (my personal favorite, I am a big believer in transparency)
Automate Everything
Test Everything
Monitor and Audit Everything

Check out article for more details

Originally posted on Dan Toczala's Blog:

Recently I took over as the manager of the Emerging Technologies team at IBM/Rational.  One of the Emerging Technologies that my team is supposed to focus on is the area of DevOps.  So now I have a small team that is focused on DevOps.  But what in the world is DevOps?  I thought that I knew what it was, but I figured that I would do a quick experiment to improve my understanding.  I decided to ask several different people for their definition of DevOps.  Surprise!!  I got back about as many different answers as people that I  asked.  (OK, I wasn’t surprised, but that is why I did the experiment in the first place)

“Big deal”, you may be thinking, “all you have done is to state the obvious”.  But the more that I thought about it, the more that it bothered me.  The goal of my team is…

View original 614 more words

rfeggins:

Nice article on Blue Mix

Originally posted on Dan Toczala's Blog:

Recently I have been getting a lot of email requests from people asking if they can do something “non-standard” with Jazz.  I am going to answer your questions, but I am also gong to tell you WHY you get the answers that you do from our experts.  Here is a sanitized example of a recent email:

Hi Daniel
My name is John Doe. I saw that you wrote an article on the CLM deployment wiki 
on Jazz.net. I have a question that you may be able to help with.
A customer is deploying CLM 5.0 with Oracle and they have a standard practice of creating a single "temp" tablespace for a set of applications like our CLM suite. Will everything in the CLM suite function correctly if all four CLM apps use the same "temp" tablespace or is it necessary for each app to have its own temp tablespace as…

View original 824 more words

Disciplined Agile Delivery (DAD) is a agile process decision framework is that it promotes a full, end-to-end, solution delivery lifecycle. It has a three-phase lifecycle where team incrementally define, build and deliver a potentially shippable increment, or a consumable solution,  incrementally over time.

http://disciplinedagiledelivery.files.wordpress.com/2014/05/disciplined-agile-lifecycle-basic.jpg

 

Scott Ambler has identified four lifecycles based on different circumstances. They are:

  • Basic/Scrum-based lifecycle
  • Advanced/Lean lifecycle
  • Continuous Delivery/DevOps lifecycle
  • Exploratory/Lean Startup lifecycle

All assume that the lifecycle can be divided into three phases:

  1. Inception. or initiation iteration where the majority of teams up front work is done. As Scott points out, in many cases the Inception phase may span more than 1 iteration so shouldn’t be mistakenly as Sprint/Iteration 0.
  2. Construction. During this phase, the majority of the software “construction” is done by the team. Assumes each iteration the team will produce a potentially consumable solution. Depending on the project needs, different iteration approaches may be used such as: lean, continuous flow approach, iterations. 
  3. Transition. This phase is used to address the needs of larger teams where deploying the solution is often a trivial exercise. 

For more information see Scott’s blog here

Recently read a really good article on managing requirements for large programs that I thought you might like. 

Managing Requirement Dependencies Between Agile Teams 

by Scott W. Ambler,

Although we strive to avoid functional dependencies between requirements, the fact is that they occur in practice.  They certainly occur between requirements that are being addressed by a single team and they will even occur between requirements being addressed by different development teams.  This is particularly true between the subteams within a program (a large development team organized into a “team of teams”)….

Check it out

 

 

rfeggins:

Updated post based on presentation I delivered at recent 2014 IBM Innovate conference.

Originally posted on Reedy Feggins Jr:

Updated post based on presentation I delivered at recent 2014 IBM Innovate conference. Here is the link to the actual presentation, click here.

Agile Practices.   What is SAFe?

The Scaled Agile Framework® (pronounced SAFe™) is an interactive knowledge base for implementing agile practices at enterprise scale. SAFe provides organizations with a set of best practices, artifacts and suggested tooling necessary to scale agile from the team to program to the portfolio level. SAFe** aims to address some of the concern that many have had with other Agile methodologies such as Scrum when attempting to scale. Created by Dean Leffingwell, SAFe has been successfully adopted by a number of large organizations internationally, click link to some of their case studies

Over the last 4 or 5 years, I have had a fair bit of experience helping organizations scale agile, see blog post from 2011 on Scaling Agile –…

View original 619 more words