Charting the Course to Agile Development

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.

Logical path from New York to Los Angeles

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.

Roundabout path between New York and Des Moines

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.

About Mark Crowe

Mark Crowe is Senior Director of Product Management at VersionOne. Since 2003, Mark has been driving the evolution of VersionOne's market-leading agile ALM product lines, internal Product Management team and product planning processes. Prior to joining VersionOne, Mark lived the life of a technology consultant in Silicon Valley where he developed an appreciation for iterative development principles while working at clients such as Netscape Communications, Apple, and AMD before cutting his teeth in Product Management at an Atlanta area startup. Mark's passion lies in the intersection of creating great products and maximizing value delivered through iteration. In his free time, Mark enjoys family, photography, futbol (Go Barça!), football (Go Irish!) and coaching youth soccer.
This entry was posted in Backlog Management, Product & Release Planning, Product Owner, Program Management, Program Manager, Project Manager, Stakeholder. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *