Can Agile help with predictability?

Agile Australia Keynote Speaker 2015

It’s entirely possible to make predictions with Agile. They’re just as good as predictions made with other methods, and with XP practices, they can be much better.

Software is inherently unpredictable. So is the weather. But forecasts (predictions) are possible in both situations, given sufficient rigour. How your team approaches predictions depends on what level of fluency they have.

“Focus on Value” teams tend to fall into two camps: either “estimation is bad Agile” or “we’re terrible at estimating”. These statements are the same boy dressed by different parents. These teams can’t provide reliable estimates because their iterations are unpredictable, with stories drifting into later iterations (making velocity meaningless), and a lot of technical debt (so even if they took a rigorous approach to “done done” iterations, there would be wide variance in velocity from iteration to iteration). They don’t have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams. They believe predictions are impossible in Agile.

“Deliver Value” teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff in XP. They tend to take a “we serve our customer” attitude and are very good at delivering what the customer asks for – if not necessarily what they want! Their velocity is predictable, so they can make quite accurate predictions about how long it will take to get their current backlog done. Variance primarily comes from changes to the backlog and difficulty discussing needs with customers (leading to changes down the road), but those are manageable. Some “Deliver Value” teams retain the “estimation is bad Agile” philosophy, but any team at this level of fluency with a reasonably stable backlog should be capable of making useful predictions.

“Optimise Value” teams are more concerned with meeting business needs than delivering a particular backlog. Although they can make predictions about when work will be done, especially if they’ve had a lot of practice at it during their “Deliver Value” phase, they’re more likely to focus on releasing the next thing as soon as possible by reducing scope and collaboratively creating clever shortcuts. They conduct experiments and change direction depending on market opportunities. These teams can make predictions just as well as the other teams can, but estimating and predicting has a cost. They may make predictions to share with stakeholders, but those stakeholders are higher-level and more willing to accept “we’re working on business goal X” rather than wanting a detailed timeline.

So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organisations, an “Optimise Value” fluency isn’t desired. It’s too big of a cultural shift. In those cases, a “Deliver Value” team is a great fit, and can provide the predictability the organisation wants.

About the author

Widely regarded as one of the top thought leaders in the Agile software community, James Shore was an early adopter of Agile development and one of the first 10 people to sign the newly-released Agile Manifesto. He remains a popular lecturer on software development process and his writing has appeared in many industry publications. His Art of Agile blog is regularly found on AgileDaily’s list of top twenty most recommended Agile blogs. James is also the co-author of The Art Of Agile Development.

This article originally appeared in Volume 9 of AgileTODAY.