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


That trick of course, is what agile methods are all about. An agile process gets out of the way so you can translate a software need to actual software rapidly. This gives you short periods of clarity that can be repeated to spiral in on what you really need.

If you are using short iterations in an agile methodology, I think that everything here still applies, but at two separate levels. First, my opinion is that you still need an opening phase at the beginning of a release cycle to set the overall direction (others may not agree). You may choose to just map out a series of features (*cough* stories) and their initial ordering. Second, you still need to do some form of planning and design in each iteration that will look very similar to the opening phase, just in compressed form.


1 If the engineering team is being handed both dates and a feature list then the only variable they can affect is quality, and it’s gonna be bad. It’s your responsibility as an engineering team to push back if this happens to you. My experience has usually been that there is some way to compromise if everyone goes into the discussion with the idea that there is actually a compromise. Sometimes that means looking at whether the parts of a feature that are most costly to build are the most important to the business. If not, you might be able to pare down a feature or come up with some way to stage the feature.

2 If either axis is too big to fit on a page, you’re either working on much bigger projects than me or on much bigger teams and in that case, this probably won’t work.

3 By the way, I find a release with 4-6 weeks of dev is what I like the best. I can hold the schedule outline in my head for something scoped to that size. I expect to spend at least 2 weeks of that period doing planning and design. Realistically the planning lasts longer as a few people may start the process before the prior release is out and/or may bleed late for a subset of the features.


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.