Agile Zone is brought to you in partnership with:

Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Software Rhythm Part 1: The Opening

  • submit to reddit

How do we build it?

Once you’ve chosen a set of features and prioritized them, you need to do some design work. You may actually have done some of it already when estimating the features. I tend to favor light-weight, no cruft design docs, preferably just 2-3 pages per feature. I don’t like design docs that spell out every detail of the implementation. Do that when you write the code. The design is for flushing out the details of what you’re building and discovering what you didn’t already know.

You also need to determine a schedule for who is doing the work and how long it will take. Now again, you should remember that your estimates suck so don’t put too much stock in whatever you lay out. The key here is to build a schedule you believe is possible.

The most commonly used tool when building a schedule is the Gantt chart. I loathe Gantt charts (see Part 2 of this series for why and some better tracking options) but for an initial cut at whether you have a believable schedule, they’re not bad. I’m especially in favor of them for this if I can sucker a project manager into creating them for me.

Personally I find I can get the same amount of information by creating what I call a “blocking chart”. It’s just a table with weeks on one axis and the people in your team on the other. 2 Indicate in each block what feature the person is working on. Based on your estimates, you should know roughly the time available and you probably have a good idea who is actually working on it too. The who is very important of course, because people’s knowledge, skills, and abilities vary by 10x. Fortunately, as a person that knows the people in your team, you can make these calculations by just playing the idea in your head. This technique is probably worth a post in itself…


The most common thing to screw up in the Opening is to under-estimate the amount of time it will take. A lot of people schedule one or two weeks to do analysis and design. That’s not enough, unless you have timeboxed only 4 weeks for your release. 3 It’s a good rule of thumb that you should spend a third of your release cycle figuring out what you’re building, a third building it, and a third releasing it. Those proportions will vary quite a bit based on your processes and environment, but I find the tendency is to make the Opening activities too short and the End Game activities too long.

If you short-change figuring out what you are building, you’re going to fail. You will discover at some point that you’ve built the wrong thing. If you’re lucky, you’ll discover it before you release and you can correct it and you will fail merely by being late. If you discover it after you release, you will fail by delivering something that isn’t what people want. The trick of course is to figure out what to build AND build it before what you need to build changes. :)

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Alexander Shirkov replied on Wed, 2008/09/10 - 5:57am

Nice article, Alex. Waiting for next parts.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.