Agile, PMO and Air Traffic Controllers in Software Development Methodologies

Friday, August 14, 2009

I recently read a Gartner research report about the changing space of software development methodologies and the PMO. It compared the PMO to an air traffic controller coordinating flights (ie projects) – scheduling them, coordinating resources for them etc. While this might be a valid comparison, I think the changing face of software development is leaning towards taking road trips as oppose to long flights.

The air traffic controller analogy is good but if the distance is short, sometimes driving a car is faster. I think if our aim as software development managers shifts to focus on delivering small chunks of functionality more often, we don’t necessarily need all the planning & scheduling that an international flight requires. Driving to a close destination within 100 miles or so is often faster than the airport parking, luggage check-in, security screening, boarding, possible flight delays, weather conditions etc (not to mention the high upfront cost of a flight). For short distances, driving a car is often the optimal choice.

For farther destinations, say from Miami to Seattle, a flight would definitely win over a drive with no stops. However, if we think of a Seattle as being the final destination, but having several stops along the way, it becomes akin to a road trip. Each stop in a different town adds value to the overall expedition. Everyone is enjoying the progress of the trip because they’re getting value out of each stop along the way. The car will need refueling (capital) along the way, but its a smaller cost than filling the plane with 50,000 gallons of jet fuel before takeoff. The analogy here is the benefit of high business value from fast, incremental delivery of application features.

Also, a flight requires coordination from several disparate and highly specialized teams (engineers, pilots, stewards, traffic controllers, etc). In the car analogy, the team is much more close-knit and cross-functional. Anyone can drive, a couple know how to drive as well as change a flat, someone knows how to change the oil as well as fix a flat – they don’t need to “borrow” someone from another project to change a flat. Everyone on this cross-functional team is committed to the success of the road trip whereas flight teams work on multiple flights (projects) all the time and need to be coordinated and assigned accordingly.

Without a doubt, coordination and management is necessary with any software development project.  However, the scale can change dramatically depending on how far you want to look ahead.  It also gives us more options to get around detours along the way.

 

One Comment

  1. http:// says:

    Great Article. I couldn’t agree with you more. The challenge of course is limiting ourselves to the series of small successes that you describe. While this approach averts so much more risk than the old ways it still doesn’t avert the risk of scope creep that is so much a part of a developers nature. For me the easy and the smart can becomes tedious and boring. If my pipeline of little to do’s isn’t full enough I’ll creep the scope my self by targetting some truly meaningless improvement.

Leave a Reply