Agile Certifications - Why they aren't neccessary

Agile started many years ago with some basic (note I do not say simple) concepts related to how we should work together to build better software products.  Though I struggle with the notion that mere communication among individuals can deliver quality software, it can provide a product that is closer in alignment with the product owner's vision. I remember as Agile unfolded there was a debate on whether we needed things such as certifications.  I recall the argument that the very process of creating certifications for things such as Scrum would defeat the very benefits that the Agile manifesto was attempting to address.

Now many years into the manifesto I have to say that these certifications have brought an element of rigor that 'can' be beneficial but I think often stifle the creativity that can come out of Agile teamwork.  Certifications do not make you a great Scrum Master nor a Product Owner, they merely convey that you have taken a 1-2 day class that has provided you with the  evolved standards that Scrum has been defined to be.

I've been involved in a number of Agile transformations along with working in already high performing agile organizations and none of them are alike.  One thing I have taken  away is that teams who are provided space to try new things often find creative ways to solve the unique challenges they face.

As someone who started in Agile from the project management perspective I quickly realized that I was not your standard project manager who managed against a project plan, happily disconnected from my team.  No I was always learning, asking questions, it is how I went from a project manager into QA, because I took an active role in being in helping my team deliver great software.  Through out it all I was most focused on getting feedback from my team in order to improve our processes.

In those early days there were no certifications, we just took the concepts and did what worked and continued to evaluate how and what we did.  With certifications there is almost a cookie cutter approach to engaging Agile that I don't believe was the intent of the original writers of the manifesto.

Scrum and the processes it provides are extremely important, I'm not saying that these don't bring value.  What I am saying is that you don't need certifications in order to be good at Agile and Scrum.

I always tell my teams, Agile isn't easy, it will highlight every weakness in your delivery process and force you to ask hard questions about how much the organization is committed to changing the way they deliver a product.  Having a Scrum Master or Product Owner certification does not help in these situations.  What does help is working with an experienced Agile coach who has been in the trenches, who is experienced in the demands that Agile and the transformation present.

As an organization looking to adopt Agile, getting certifications for your team is not a requirement to working the concepts that so many teams use to be successful in Agile.  Don't let certifying your team be a precursor to moving toward Agile.  At one organization I worked at we took this approach and ultimately it wasn't necessary as the majority of the people who were 'certified' were not involved in working in daily Scrum team activities.

An experienced coach will be able to guide you through how to work as a team, manage communication and change the way that you deliver software products and your organization.

And yes I have several certifications including CPO and CSM and know that these are now almost standard requirements for anyone wanting to work in an Agile environment However if you are just starting Agile don't assume that someone who has been certified is necessarily an experienced practioner.  When looking for help in adopting Agile you should look for someone who has been involved in more than 5 different Agile implementations or organizations, perspective is worth it's weight in gold.

Contextually Rich User Stories - The Importance of Details in Small Increments

Every software product that we build begins with a set of requirements. Teams or organizations who have utilized traditional requirements documentation efforts such as Product or Business requirements documents (PRD's or BRD's) typically have issues with translating their requirements process into user stories.  Instead of writing long passages of descriptive requirements that are heavy on the use of 'the user shall' we move to a smaller specification document that convey details to a specific individual feature.

What teams fail to realize is that their old requirements documents weren't all that good at conveying the necessary details that allow teams to delivery their product quickly and with quality.  You see evidence of this lack of clarity with the large number of change requests that are raised during waterfall projects.  In my pre-Agile years it was not uncommon for a typical 6 month project that I led to have over 100 change requests generated to convey the changing nature of the requirements (business, technical and UX).  The Agile manifesto addresses this reality by saying we accept change, why?  Because it's there it will happen, to deny it would be to deny the reality of product development, as we learn more we need to change our approach.

User stories, though small in format, need to have a specific level of detail if a team is to have the ability to accurately estimate and delivery the feature.

The basic User Story:

• Story
• Conversation
• Acceptance Criteria

Can be deceptively simple to those who are just starting

In one organization I worked with as we moved into an Agile process the team looked at the User Story statement  as THE requirement.  It took awhile to get them to learn that successful teams use the User Story format as a specification and not a loose statement with no context associated with it.

An example of a solid User Story specification would look like this:

Another important thing to note with this format is that the team is also collaboratively building Story acceptance criteria by using Behavior Driven Development (BDD) which directly feeds the test automation frameworks that most Agile teams utilize (Cucumber, Fitnesse, to name a few).

There are other efforts/processes that feed into getting the right amount of detail into the story such as Discovery and Pre-Planning and if these are missed you will not obtain the benefits of this format.

Over the past 5 years, teams I have engaged with, who have used this specific format for developing their User Stories have had a much greater success with both delivering on time and more importantly with higher quality.

At my last organization I asked a Scrum team to utilize this process during the Pre-Planning phase of their project.  After the project I learned that the Product Owner had been very worried about the team using precious 'development' time to talk through the work and build out the context of the user stories. After the project was completed he could state without reservation that taking the time to build out contextually rich user stories with the team had produced two key results:

1. The team delivered on time and with more features than he had originally promised the client.
2. When he delivered the demo to the client he had high confidence in the product as it met all of the context that had been build out and there were only 2 minor UI issues that were identified during the 3 iteration project.

Take away - Don't run before you are ready and get the context right before developing.