Having a great conversation with Val the C# Gal, thought I’d share.
So, Christopher . . . Not to back you into a corner, but if you had your druthers, how small would you like projects broken up? A month of requirements gathering, followed by a month of spec writing, followed by development, for example? Or maybe a week of each followed by a release? I am interested to hear what has worked best for you.
No, no – feel free to back me into a corner. It’s a good way to get honest answers.
That said, my preference is to let each project tell me what kind of iteration period it needs. Believe me, I know how hippy-dippy that sounds. But it’s honest. For example, once I complete a high-level set of requirements – the proverbial view from 10,000 feet – and it’s time to start drilling down, I’m not likely to say “let’s write spec for a month,” but I am likely to say “let’s spec out the garthok-gnarfling feature first. And if the client agrees that it makes business sense to do so, and I have a high degree of confidence that garthok-gnarfling won’t break anything else that I need to build, I’ll test, document and deliver that garthok-gnarfling feature by itself so it can be put to use while the rest of the system is being built.
Mind you, this is just my personal preference – it is very important to me to get working product in the hands of the client. I think it helps the client feel as though the project is real, not some intangible, abstract thing that will be delivered Q3 of 200x. However, not every project lends itself to such tight iterations – usually two or three or more features will be interdependent in such a way that delivering any single one by itself is pointless, and this is OK. I’m not a fan of trying to force reality to fit my own prejudices.
In general, some combinations of the client, the market, the business process, and politics will dictate what kind of iteration is needed for a project. For example, I recently did an ASP project that had me delivering pages every week. A few years back, I did a project for Exxon-Mobil that had me delivering product every 6 months for a couple of years. Both projects were successful according to the performance measures set out at each project’s kick-off meeting, so it’s hard to say for certain that either approach is “better.” Each project got the approach it demanded.
I realize that this does not answer your questions directly – you want a concrete “x is better than y” answer. Problem is, I don’t think I have one for you. But I can say this:
- In general, shorter cycles of design/develop/test/release seem to work well
- In general, design-it-all, build-it-all, test-it-all, deploy-it-all projects are more problem-prone
- In general, prioritizing the most useful and least interdependent features leads to shorter initial delivery times
- In general, most projects have artificially short schedules anyway, so don’t be shy about putting your foot down the next time someone hands you an estimate that is obviously inappropriate.
In other words – it depends. 😉