Johanna’s comment in the Are pre-defined release dates bad for Quality posts has had me thinking for the last little bit. Are pre-defined dates okay for Agile projects? I think they might still act as a hindrance to the overall project.

Let’s say you are working on a project that is using 2-week iterations. The number of iterations for the project is often a straight calculation from the pre-defined release date / 2. Eeach iteration is then mapped out with desired features. As I understand the theory, iterations content should be based upon the complexity of features coupled with the teams’s velocity.

Sure, not all Agile projects have pre-defined release dates. But I suspect a lot of so called Agile projects are really Wagile ones. Almost by definition, if there is a contract, you are Wagile which is dangerous. Sure, you might use iterations, and story cards, but if the contract says that you deliver at X, you better be sure to deliver on (or before) X. This is significantly different than the model where you control all the pieces and can release when things are actually ready for release.

This leads to the 3 things I think would help you overcome the danger of Wagile release planning.

  • A really good build person – An intelligent, effective build is something that should not be taken for granted and might be the most important deliverable other than the actual code
  • Everyone on the same team – I’m starting to think that a smell for whether a project has a greater chance of success is whether there is a single “team” or if there is “the dev group”, “the testing group”, “the database group”. Yes, in Agile projects there is the notion of shared ownership so everyone does everything else, but I’ve been in Waterfall organizations where that was true as well. The split between dev and qa, while not optimal is not (usually) fatal. I think though that a separate database group through is the kiss of death. Yes, a really clueful DBA is a must, but their role should be in making sure the database runs smoothly and point out which interactions are having negative impacts on that goal, not holding up development, forcing bad data models upon development or acting as a roadblock to innovation and refactoring.
  • Architect for refresh – In today’s web application, there is almost no excuse to not design things in such a way that an update cannot be pushed out without minimal notice to the consumer. This often means building your application from the start to be deployed inside a cluster, a way to get new configuration information (either re-read files on disk or pulling from the database) and perhaps storing session information somewhere central to all parts of the application.

The common element is that these all help increase your Agility by upping your ability to Release Early / Release Often; another tenet of Agile. While perhaps pushing production code 37 times in one day (like Flickr is reported to have done once) is a bit excessive, being able to do so frees you the eventual release date and lets you concentrate on the now. When the end of the project rolls around, the release then becomes a non event as it is something that you have been doing all along.

Something to chew on.