The notion of doneness pervades everything we, as humans, set out to achieve. Want to send a manned rocket to Mars? It’ll be done when it’s done. Composing a new symphony? Can’t wait to hear the finished piece. Want to create a payroll system for an automotive company? Better deliver it on time, otherwise they might grow tired of waiting and pull the plug on the whole project.
This notion of doneness exists for a reason. Without it, projects would just spin off indefinitely, and nothing would ever really be accomplished. There’s nothing quite like an impending deadline to focus the mind.
Doneness is a mindset thing: the dogged determination to deliver what the customer wants, and then move on to other things (be it a new project, or the next iteration of the same project). But as soon as you start planning for doneness, all sorts of complications snag up the nice clean concept of “job done”. Did the bug count exceed some arbitrary limit of project quality? Were individual features cut back to allow the project to be delivered on time? Was the latest feature-set delivered late?
Small wonder that, in IT, we have such a hard time with deducing what the customer wants and delivering what’s needed on time, and determining whether or not it was all a success. Software agility is a response to this quagmire of schedule uncertainty. There's much wisdom in the agile world; for example Mike Cohn’s book Agile Estimating and Planning is well worth a read, as it maintains an emphasis on focused delivery. It shows how to run an agile project without losing sight of the concepts of doneness, deadlines, and keeping to a schedule.
However, not all software processes are entirely compatible with deadlines: at least, not with a combination of fixed scope and deadlines. The Extreme Programming ethos, for example, is best summed up by agile guru Robert C. Martin’s posting to the now-defunct OTUG discussion group (October 2000):
“There is a difference between ‘Schedule’ and ‘The Schedule’. In XP, ‘Schedule’ is very important, but ‘The Schedule’ doesn't exist per se.
“The notion of having ‘The Schedule’ is related to the notion that a software project reaches a point where it is ‘Done’. The notion of ‘Doneness’ pervades our thinking and our communications. We say to each other things like ‘When this project is done…’ or ‘When will this project be done…’, etc, etc.
“The reality, of course, is that a software project is never done until it has been terminated. So long as the market is active, the project will continually evolve. Certainly it will reach points where it is releasable; but at each release there will be a whole list of things that need to be done to it.”
We dissected this quote and gave plenty of attention to its ramifications in Extreme Programming Refactored, so I won’t dwell on it here. To be fair to Robert C. Martin and to XP, a fundamental tenet of agile planning is that the dates are fixed but the scope may vary.
That is, the planned features may be dropped or pushed back to a future iteration, or, rarely, new features may be slipped in if there's time; but the actual delivery date for the current iteration will remain unchanged. You can see this not just in XP but in just about any agile process, e.g. timeboxed delivery in DSDM, or monthly sprints in Scrum.
But it doesn’t take a great leap of logic to flip the equation. If the question is “when will feature XYZ be delivered?” then “fixed date, variable scope” is roughly equivalent to “variable date, fixed scope”. Feature XYZ may be delivered in this iteration or it might slip to the next, so the delivery date for a specific feature is variable. It doesn’t answer to deadlines.
The real world is different: it runs on deadlines. For example, the new product must be on the shelves in time for the Christmas shopping season, or the new air traffic control system must go live by the year 8-billion; or the payroll system must be up and running for all employees in time for the new tax year.
In theory (and sometimes even in practice), agile projects are well set up to cope with hard deadlines. Perhaps the payroll system must be ready before year-end so all those P60s can be printed off and stuffed into little envelopes. So the team could at least ensure that the P60 printing-and-envelope-licking feature is ready in time, if not the complete system.
But the danger is that, with the XP mindset of software never being done and the schedule not existing per se, a meandering lack of focus can easily work its way into the project. At this point, the team loses track of the project’s long-term goals. Project managers focus on incremental delivery of features that are more about the project itself than about the real-world problems that they originally set out to solve; and the programmers, like pigs in mud, write unit tests and mock objects that give each other mutual kisses and cuddles.
They spend a day refactoring some code to a neater design pattern. They’ve got a green bar assuring them that everything’s okay. Warm fuzzy feelings all round; eternal sunshine of the spotless geek. And so the project spins away, immersed in its own issues, looking inwards on itself and forgetting to look outwards, until suddenly it’s cancelled and all involved glance up from their keyboards, wide-eyed and blinking.
This isn’t true of all agile projects; just the ones that have become tragically lost within the warm and fuzzy agile message. Of course, many agile projects successfully deliver small, incremental, tightly focused updates to happy customers and end-users.
The difference tends to be that in a successful project, the project manager (or customer/analyst, or architect, or lead developer) is a control fiend, a benevolent dictator, who never loses sight of the project’s original set of goals. With such focus, there’s invariably a fixed notion of doneness; some delivery criteria (even if the details may change); a point where you can look at what’s been accomplished so far and say “there, it’s done.”