Being Agile - Say it, Do it, Prove it

I was working with a team recently and as we talked about all of the planning that Agile entails, I broke it down into very simple terms - Say it , Do it , Prove it. That is really what Agile is about.  Anything else outside of these three concepts is noise to your ability to deliver product and services to internal and external customers.  As Product Owners in an Agile organization, you need to understand all of the effort and dynamics involved in getting your teams to Say it, Do it, Prove it.

Delivering what you say you are going to deliver is the best way to build credibility with your stakeholders.

For Agile teams, this translates into being effective at decomposing your stories into small enough increments so that you are confident in your understanding of the user story and estimates that the team believes in.

1. Say it = Release Planning and Backlog Grooming -
   1. Starting at a high level, the Product Owner is responsible for saying what is important to the organization from a value standpoint and beginning the process of developing a user story backlog that supports this vision.
   2. User story decomposition is so important to effective Agile teams and the Product Owner must start with a set of well-formed stories that provide context to the team.
   3. What is 'context'?   Context is anything that provides definition.  It is basically what the product should do from a functional standpoint.  One of the biggest mistakes many teams make is writing declarative stories that start with the 'How'.  This,\ in turn,  puts the technical team on the defensive as they may have many different ways to implement the feature.  As a Product Owner, be sure to steer clear of writing stories that define how you think the feature story should be implemented.  I know that as we all become well versed in technology there is a strong desire to show off our technical chops, however, as a PO you need to provide context from a business standpoint that your tech teams can consume. I've heard time and again from engineers that they would really like to understand how what they are developing delivers business value or solves a particular pain point for the customer.  The team works much more effectively when they are completely grounded in the business context of what they are building.
2. Do it = Sprint execution 
   1. An important element for teams to address once they are ready to take stories into a sprint, is that the goal during the Release Planning and Backlog Grooming activities was to begin to build out the context of 'How' the story will be implemented.  It is so important for teams to understand that there is essentially a handoff from the PO to the Scrum Team and that each of them is responsible for building what I call contextually rich user stories.  Gojko Adzic calls this Specifications by Example.  Effective teams who deliver fast and with high quality work closely as a team.
   2.  I believe that the combination of User driven stories and context driven specifications (examples) forms an extremely strong definition of both Ready and Done. which is why I coach my teams to utilize BDD as the basis for developing their User Story acceptance criteria.  The team works together to complete BDD acceptance criteria forming a clear understanding of the boundaries of the feature.  This provides the PO with a concise view of what to expect during the Demo.
   3. Another key benefit of writing BDD as part of your user story writing is that the test automation engineers can easily consume this as part of their code development for the automation.  PO's should push to get to this level of context as it also means that your test engineers can start developing their test automation code once the story is ready for development.  They can essentially perform TDD in that they can write their automation before the feature is actually developed.  Once developed the automation should run cleanly and both speed and quality are attained.
   4. The goal of teams should be to deliver user stories that do not require much further elaboration once the sprint begins.  You want your teams focused on delivery ,not on discovery.
3. Prove it = Retrospective
   1. You have done all of the work to clearly define your user stories with high levels of context.  With all of this effort, the Retrospective should be an easy affair to show the work that was defined in the stories.  The PO should not have any surprises.  In fact, if the team misses any test scenarios after the story has been started, the PO should consider that more of a missed requirement over anything else.  Since the entire team developed the stories,  there can be no finger-pointing at anyone.  It was a shared miss and everyone must accept it.

It sounds really simple when broken down into these 3 basics phrases.  The truth is that 'Being Agile' is much more involved than simply 'Doing Agile'.

"Being Agile" means exposing all of the inefficiencies in your product development processes.  It requires that the organization be completely honest in assessing what is not working and committing to letting the teams that do the work fix these processes.  You cannot top down drive the type of organizational change that is required for Agile continuous improvement.  Real organizational change is fostered at the top but truly owned by the Scrum teams that form in support of any Agile adoption.