Plus ?a change

I recently had cause to review the way we used to manage software projects before agile techniques became the norm. Back in the day, you'd often get a functional design that would be intended to cover your work for maybe the coming three or six months.

We'd start with a task breakdown, and then we'd try to estimate hours for each task. There'd already be an estimate, of course, which would be the one the project manager (or even worse, someone in sales) had done without a task breakdown, and it was always wrong. So you'd try to slice it first into features, at which point it wouldn't look too bad. The thing was that developers, then as now, find it difficult to imagine concrete amounts of work that are bigger than say, half a day.

So you'd have a feature, and someone would have said "a day maybe?" and then you'd drill down and say - how many hours of that is to write the HTML? And how much for the SQL, and how much for the business layer? By this time you'd already got enough for a day, so you'd press on with "when you estimated the HTML, did you include the CSS? and the tweaking to get the design pixel-perfect on all the browsers?". (Have we even got a design?) Oh no, so some more for that then. And testing? Had you counted developer testing? ... and testing by the tester? and rework for the bugs? and re-testing the reworked code? What about getting it up the DTAP street? Somewhere along the way, someone would start asking why we were doing this; our real work was grinding out the code, right? Wrong.

Going into this level of detail was usually enough to get people thinking about amounts of work they might fit in half a day, or the couple of hours you had left in half a day after all the meetings etc. After you'd done this for the entire functional design, you usually had a pretty good estimate of what it would take to build the thing and ship it to production. This estimate was usually different from the optimistic one you'd started with, which, as I mentioned, was wrong. Then with a bit of luck, you could get into a discussion of "yeah - that was the estimate before we did the breakdown. This one is much better", or sometimes you'd be shot out of hand as the messenger bringing bad news. The thing is, the post-breakdown estimate was usually very close to the amount of effort it took to get the job done, so ideally it was a huge gift to anyone trying to actually manage things.

But still, the whole process was stressful, and nobody liked it, mostly because most people don't like to be in the way of brown steamy stuff rolling downhill. When the agile movement came along, it took a while to get across the chasm, but the developers knew it was better. It meant that when you were guessing how long something would take, you had a reference point of a piece of work one or two sprints ago, and all the things you'd discovered as you went along that had added to the scope. It was much more real.

Nobody's hankering to go back to 'waterfall' (or whatever you want to call it), but let's not forget that the important elements of agile came out of that world. For sure, I've been talking about estimating, and there are many other benefits to working with a prioritised backlog, constrained work in progress and all the other fun agile stuff. Anyway - looking back at it made me realise just how long I've been obsessing about how to get this right.

The take-aways:

If you can't imagine it fitting in a morning or an afternoon's work, you have no idea.

Planning work is work too, whether it's old-fashioned breakdowns, or refining stories.

Plus ?a change, plus c'est la même chose.