One of the barriers I’ve come across during agile development transformations, is the perceived lack of predictability the shiny new methodology brings with it.
“But”, cries the nay-sayer, “with Waterfall, we knew exactly what we’d get and when we’d get it”.
The only time you can know exactly how long a project takes, is when it’s finished.
Grumpy
No. You didn’t. You just got the illusion of predictability. You spent weeks or months on extremely detailed project plans, drew up fancy Gantt charts, wrote reams of requirements and other documentation, and made promises based on the conclusions you reached before you’d even written a line of code. How often did the engineers run into an insurmountable road-block and have to change direction, completely killing the plan? How many of those projects were delivered on time, on budget, to full (and unchanged) scope? At the end of the project, the only purpose the plan serves is to show how far you’ve deviated from it. The fact of the matter is, the only time you can know exactly how long a project takes, is when it’s finished. So now ask yourself: what value did you harvest from all that effort spent estimating and planning? Other than the negative value of burned engineering hours, of course.
My good friend Adam’s article When will it be ready? is a great argument for being properly agile, putting the focus on delivering functionality rather than estimates. By the way, Adam is one of the calmest take-it-in-his-stride guys you’ll ever meet, so when he feels the need to vent, it’s generally worth paying attention. Adrian Pickering’s We Don’t Need No Estimation is another great read – he totally gets it too.
Whenever I see things going off track, I like to remind myself of what we’re trying to achieve and how we’re going about it. Time and again, I come back to the Principles of Agile Development, and in particular “Working software is the primary measure of progress“. And while I’m quoting canon, let’s have a quick look at The Agile Manifesto, and specifically two of the four foundational statements:
- Working software over comprehensive documentation
- Responding to change over following a plan
When you start trying to establish rock-solid predictability,
- You’re getting in the way; and
- You’re wasting your time. More importantly, you’re wasting engineering time. You simply won’t get the predictability you were looking for. It’s not possible.
- You’re pissing off engineers by demanding the unknowable, then subsequently holding them accountable to it. How does this taint the culture you’re trying to foster?
So how does agility help us?
It brings a continually-revised estimate, which becomes more accurate over time as requirements are firmed up and the development team learns things.
Typically, the team will quickly deliver a first-pass estimate before they’ve deconstructed all the feature requests into detailed requirements. Expect this one to be reasonably bad. And (depending on your team but in my experience fairly reliably) hopelessly optimistic. You’ll be lucky if this is within 50% of reality. Treat it as a T-Shirt-Size guess, more an indication of the scale of effort for each major component than anything else. Then let the engineers loose.
Agility is not Anarchy.
This is one of the other myths purported by the uninformed. Agile development absolutely is not uncontrolled keyboard-bashing by barefoot bearded blokes wearing tie-dye kaftans. In fact, the more agile your team becomes, the more disciplined they become too – without it even occurring to them that they’re acting like professional, highly-disciplined engineers. Which is kinda cool. It lets them maintain the self-image of being rebels furiously saving the world one line of code at a time. Foster this by providing multiple monitors so that they can work in a Command Centre or Evil Lair. Random outbursts of ominous laughter: a good sign.
You’re throwing darts at a target. The closer you are, the more accurate your throws.
Part of this discipline is the continuous-estimation process. It’s rolled into the day-to-day workflow. Pick up a task to work on, do some work on it, and before you close it off for the day, update the estimated time remaining. You’re talking about spending an extra couple of seconds here, as that update is probably on the same screen you’re using to check the code back in or change the task status anyhow. Basically for free, you’ve got ongoing estimate-revision which starts off very rough and refines itself during the course of the project. Think of this as throwing darts at a target. You start from far away, and consider yourself lucky to get any on the target at all. As the project progresses, you step closer and closer to the target, and your darts get closer and closer to the bullseye, until you finally are standing right up against it, and can push them home dead center.
The team also needs to be disciplined and pragmatic enough to know where to start. The risk of running into something that could completely derail the project needs to be minimised very early on. Few plans will survive the first Sprint or two. You may well discover a roadblock that it just doesn’t make sense to work around, and re-scope or even cancel the project. As long as that happens at the beginning of the effort, you won’t have lost much. In other words, you need to fail fast.
Let it go.
(please don’t start singing Disney movie songs at this point)
Accept that you just can’t have absolutely accurate estimates, plans and timelines at the beginning of a project. If the T-Shirt sizes (with a liberal pinch of salt) don’t sound unreasonable, you’re probably good to go. And “probably” is about as good as it ever got. You’ve lost nothing but the illusion, and saved a lot of time and heartache.
The postings on this site don’t necessarily represent the views or opinions of my employer, professional organisations, political party, family, car manufacturer or anybody at all, really. I don’t know where they come from. It scares me sometimes.
3 thoughts on “Predictability: Get over it.”