Agile Forest

We’ve all seen it before. Agile projects that turn tragile, commonly without any one person’s fault and despite the best intentions of the team.

Projects which have no known velocity, no iteration kickoffs or showcases, little visibility of the plan and who is doing what and total uncertainty as to whether the business’s desired scope will be achieved by the release date, are more than just tragile – they are chaos in motion.

Imagine a chaotic project that is ¾ complete (or perceived to be) that you have been asked to fire fight. When faced with this type of project a purist Agile coach would (or could) be tempted to stop the line and force (or drag) the team back into adhering to normal Agile practices. An inexperienced coach would throw up their hands in terror and say ‘this isn’t Agile, don’t call it that’ and might walk away. A brave Agile coach will tackle the chaos in the manner they know best – with Agile itself.

When a chaotic project is ¾ complete there is a very strong push mentality of the team to get the project over the line. Any factors not directed at accomplishing the last 25% are ignored. This presents an Agile coach with an immediate risk and change threat. So how much change do you try to make so that the team is better enabled to deliver that 25%?

The following are some guidelines you might like to consider:

1. The first step to fire fighting an Agile project that has turned into chaos in motion is to recognise all the failure points. Write them down as a coaching backlog of areas to course correct. Each story is a practice that the team needs to embrace further (or even begin doing).
2. Size up the correction stories in complexity points – this needs to consider the cost to implement change as a coach and the cost to change as a team.
3. Set the value that will be obtained by addressing the failure points. Keep in mind that you have 25% of the project to go!
4. Set the priority of what needs to be fixed first based upon the value and complexity. This priority has to take into account externally influencing factors such as the planned release date and what can be accomplished in that duration vs. what needs to be addressed for the next release.
5. Hold your own iteration kickoff walking the team through your approach to get buy-in, feedback and changes. Communicate frequently with progress so that the team cannot only see and feel how they are changing but also understand why they are changing.

As a high level approach it looks very simple. The difficulty is in knowing what are the right stories and how to approach them. Consider this chaos in motion – there is no known velocity, there are 80+ stories in some form of progress and there are four more weeks until the release date – How do you even know to what extent the scope will be delivered by the planned release date? How do you advise and plan for the future, especially if the current state is even unknown? This is uncontrolled chaos. You want to move this to controlled chaos by fundamentally breaking this down into stories that are achievable, for example:

1. Find out the current status of all stories. The team doesn’t have time to do this, the Iteration Manager / Scrum Master is in all likelihood now busy delivering and is no longer doing their iteration management function. An email won’t suffice as everyone is too busy to read emails. This is the uncomfortable bit since you have to get in everyone’s face and get the right status on everything. And it won’t be just once. You will find out what they are doing and then there will be a bucket load of stories which you have no idea what their status is. This will be a journey of discovery.

2.  Here comes the tricky bit. You won’t get an iteration velocity that is worth anything at this point in time, but you need to know whether you will meet the release date or to what extent you won’t. You will need to take a leap of faith that goes slightly against the norm of Agile iteration training. Ignore iteration velocity.  Forget it even existed. You will also need to ignore the complexity points of the stories that the team are trying to deliver. Forget that they exist too. This probably won’t be a huge leap for the team as it is highly likely that some stories don’t have complexity points due to the very fact that they are chaos in motion. From now on each story is worth a number of points based upon its current state in the flow. If the flow is:

backlog->analysis->build->system test->business test->completed

then allocate new points to the story based on its state as follows:

Backlog = 5
Analysis = 4
Build = 3
System Test = 2
Business Test = 1

Fundamentally this makes the assumption that all the stories are the same size and that each process step in the flow takes the same amount of time. We know this won’t be 100% correct but we are looking for an 80% fit here.

3. Add up the new values of all the stories. It might look like 273 points. Now on a daily basis track the number of transitions that all the stories make. Each single transition is worth a single point. If a story transitions more than one flow state in a day then count the multiple transitions e.g.  Analysis to Build and then from Build to System Test will be two points.

4. Establish your average velocity over a few days. It is now a simple mathematical equation of total points left divided by average daily velocity to establish your new release date (or confirm your existing one).

This gets you through the hardest problem. You can now provide the business with some clarity of delivery and the team now has a visible mechanism to track and celebrate progression. Now that you have an element of control in this chaos in motion you can continue down your backlog fixing further issues.