I recently discussed some release planning approaches with a customer who had some traditional fixed project-type constraints: contractual relationship with milestones (in the form of multiple releases) and dates built in.
The typical agile development approach, of course, would be to take the estimate (total scope of work) and apply an estimated velocity to it based on the team(s) who will work on it. This estimated velocity is used to determine an estimated delivery date. This is the approach that the release forecast in VersionOne takes and could be applied at an individual release level or in aggregate at a level that includes all of those releases.
New York to Los Angeles - A Happy Path
If done in aggregate, a next step could be to go through the projections and count off the iterations that would need to be allocated to each release. This would provide a best case scenario for release delivery dates with the assumption that the entire team is focused on only one release at a time.
This approach is the rough equivalent of asking, “With a car that goes 100 mph, how long will it take me to get from New York to Los Angeles?”, then “How long to get to stops in Cleveland, Chicago and Denver along the way?”
A common alternative would be, “With a car that goes 100 mph for X days, how far can I go?” and then judge whether the answer is worth taking the trip. If you can only make it to Dayton, maybe it’s not worth going (not that there’s anything wrong with Dayton, mind you).
The challenge the customer faced, however, was more of determining the required speed based on known waypoints: “How fast a car must I have to get from New York to Cleveland on Monday, Chicago and Dayton on Tuesday, etc.?” which might mean very different cars for different portions of the trip. Heck, it might mean different cars going to different cities all at the same time, which makes it kinda tough on the driver. As we can see, this “how-fast-do-we-need-to-go?” approach can create a good amount of complexity.
The Unhappy Path
As textbook agile planning is focused more around a fixed team (i.e,. the same car), that’s not a popular approach to take. Note the very valid (and characteristically blunt) argument made by Ron Jeffries. We, too, encourage re-positioning the question and approach such that an agile approach can be applied. Doing this simplifies soooo much.
Still, for the customer I was speaking with, the classic agile approach just didn’t work for this project given the contractual arrangements they had in place. This greatly complicates the planning effort, dragging the logical agile approach back toward the land of falling water, but it is their current reality.
Does your organization face similar challenges? Are you, too, forced to vary your speed or enter several cars in the race to fit pre-determined dates and waypoints? Burning needs to help ease the pain? Do you have any clever approaches to avoiding the madness?
Please tell us about it: challenges, successes, frustrations and other thoughts. We’re all ears.
