Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery

24

SEP

Using 'Adaptive Capacity'

24 SEP 2012 | Posted in agile governance, backlog management, contingency | Author Stan Wade | 2 Comments

Tweet

Mail

So, last time I talked about how maybe we should rethink the concept of contingency in agile projects and introduced the concept of Adaptive Capacity, our ability to deal with the ever expected change. Adaptive Capacity is comprised of three major sources:

• Uncertainty – Stuff we still haven’t made decisions on yet
• Discovery – oops I forgot about that bit!
• Innovation – That’s great but it would be even better if…

So that’s fine, but how can we apply it to a project? This is starting to move into governance and how we control our project.

The Adaptive Capacity can be made up of a number of different resources which we can call upon. To start with, we have functional contingency or Functional Adaptive Capacity using our new naming convention. This is comprised of the lower value stories at the bottom of the backlog that we don’t actually have to deliver to still complete a successful project. But if we accept that there will be a requirement for Adaptive Capacity, then the story at the bottom of the backlog is a certainty for non-delivery and so are some of those above. So, if from day one we are saying the chance of delivery of a story is almost zero, why even bother listing it? Doesn’t this give the wrong message to the business? Functional adaptive capacity is a pretty important principle to establish with the business, but I think we need more or within 5 minutes of starting the project we start cutting functionality the business was hoping to get.

So let’s add an Adaptive Capacity story to the end of the backlog. This is a story with no functional content, used as a points reserve. We can assign some points to it and decrement the points as we draw down on them. At least this way we have something to draw on before we start to tell the business the bad news that we won’t be able to deliver some of the functionality they were hoping for. This story can be monitored and the reserve reported on as part of the sprint governance process. What you do when this is exhausted is another question. Maybe it’s time to start calling on that functional adaptive capacity.

OK, that’s great, we have some instruments to play with, but can we use them a little better than adding it all to the end? So, if we are using an Incremental Delivery Strategy, we establish milestones through the project where we can deliver business value before the end of the project. Some of these milestones can move with limited effect, but some may have a significant impact if we have to move them due to the effects of change. So, we could slice up our instruments and use them to protect these. We could use Functional adaptive capacity by allowing stories to slip out of the milestone. The problem here is that if we have already moved the low value features down the backlog already, early milestones may not have much functional adaptive capacity to call on. However, it's not that hard to deal with. You could set the milestone a few stories down the backlog with the last stories not actually required for the milestone (assuming of course the addition of these stories will have no negative impact on the milestone if they do in fact get delivered as originally planned). If you need to call on adaptive capacity, you can shift the non-critical stories out of the milestone and still keep the milestone objectives. As for Adaptive Capacity stories, we can inset them at each milestone to allow for change and still protect the milestone. If you finish all the stories and reach the adaptive capacity story, you can simply move it down the backlog to keep the capacity available for later and start on the next story.

But all this is pretty basic project management isn’t it? Well you would think so, but its rare that I see an agile team planning how to deal with the effects of the change that they fully expect to hit them. ‘We will deliver less points’ seems to be a common answer and in my experience that doesn’t really go down very well with business teams planning a release.