You Don’t Need a Deadline

by Ville Laurikari on Tuesday, April 28, 2009

Vague ideas

In the beginning there are vague ideas, manifested as cubes of air floating around in the office, of what the finished product should do and what it should look like.

Renoir - La Vague

Renoir: La Vague

Actually, that’s not correct.  In fact, if you were to ask anyone who has been sitting in the meetings mulling over the project scope, they would probably tell you that they have a pretty good idea of what it’ll look like. Granted, some people will say that just to avoid having to go to another meeting mulling over the project scope. But many genuinely think they have a pretty good idea; some parts they may have even imagined in moderate detail, covering maybe 5% of the entire thing, and the rest they just blithely ignore.

Still, people think they have a pretty good idea, because the human mind is frighteningly good in filling in the gaps and creating this illusion that the gaps don’t even exist.  So, there’s not just one vague idea.  There are several vague ideas and they are all different.

Whence come deadlines?

Soon enough, it’s time to start sketching the project plan.  Based on the vague ideas someone comes up with guesstimates for how long it will take to turn each air cube into working code. In absence of detailed specs and explicit understanding, the guesstimates are of course wildly inaccurate.  And I don’t mean off by 10%, I mean crazy wrong, enough to make the corner of your left eye twitch embarrassingly at the project post-mortem.

Then there’s the meeting where the project is approved: the resources (manager-speak for developers) are granted, the scope agreed upon, and the deadline is set.  That’s the holy trinity of project parameters: resources, scope, and schedule.  And suddenly, they’re all more or less locked down.  The team, the features, the deadline.  One is based on vague ideas and another is derived from them.  Sounds good to me, now let’s get to work!

Pressure

pressure-gaugeThings appear to start off well.  Code is being written, features and tasks are being ticked off as complete, and the project seems to make good progress.

At some point, reality sinks in.  The requirements have become more clear, now that there are some builds that people can actually install and notice how it doesn’t do what they had imagined it would.  Features are added and removed.  GUIs are reworked.  Bug lists start to grow like the national debt.  The project manager grudgingly announces that the project is a bit late, but nothing we can’t handle, we’ll pick up the pace, start daily status update meetings, and work really hard.

The developers start to feel a little depressed.  The project is late, and they’re constantly being pressed to finish their tasks quicker and reworking parts they already though were fine.  They start to make bad engineering decisions because there’s “no time” to do things properly. The second half of the project is a mad coding frenzy where good design flies out of the window, sadly waving bye-bye, never to be seen again.

Go agile

If anything like the above happens in your organization, you should take a close look at your business model and decide if keeping made up schedules is really the most important thing.  How much will you lose if you admit that the original schedule estimates were just guesswork, and move the schedule up a few weeks or months?  How much will you lose if half of the time your developers are stressed, depressed, and doing a poor job just to meet the schedule?

Software projects don’t complete quicker because there is a tight deadline and a lot of pressure to finish on time.  They complete quicker because the developers feel productive, positive, and in control, they have a good understanding of the priorities, the specifications were up-to-date and descriptive, and the project is ahead of schedule.

So, the next time you notice you’re setting a project deadline several months in the future, based on mostly on air cubes, stop right there.  Instead, specify the first iteration well and set an ETA for that, at most one month in the future.  It’s much easier to specify and estimate in small pieces.  When the first iteration is done, rinse and repeat until it’s all done.   That’s what agile development is all about.

If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.

Comments on this entry are closed.

Previous post:

Next post: