Can Agile help with predictability?

By James Shore

Agile Australia Keynote Speaker 2015

shore

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.

One thought on “Can Agile help with predictability?

  1. I think James misses the issue here. Stakeholders want predictions about when a feature-set will be ready. They want these to inform their marketing timelines, their partners, their customers, their financial planners and/or downstream teams too. That’s not an unreasonable thing for them to expect at all.

    They don’t mind if these predictions aren’t perfect – they’re used to “high level” or “ballpark” estimates being unreliable, and you can account for variations in a release plan or Agile contract without fuss if you align people to doing that. But your stakeholders will mind a great deal if you don’t let them know immediately when you discover your sprint planning breaks the release plan.

    It’s not a difficult matter to project your story throughput to find this out provided you have a clear picture about feature-level acceptance criteria, budgets and priorities. Unfortunately, few Agilists bother doing that. A breadth-first release plan doesn’t take very long to put together and raising exceptions to it when you need to is this simplest thing that could possible maintain trust in your competence …

    You can do that kind of thing ad hoc, but I’ve found it best to align the various authorities – design, tech and business – to a very simple Agile Product Management pattern language so they can be confident there are no dramas involved. I’ve made it part of XSCALE here: http://xscale.wiki/#Product%20Management

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s