Charles Cobb on Agile Methods

PMI now offers certification called Agile Certified Practitioner (PMI-ACPSM), and references to 'agile methods' appears in 5th-edition for the first time.  As I have no experience with 'agile', I purchased Making Sense of Agile Project Management: Balancing Control and Agility by Charles Cobb and had some correspondence with Mr. Cobb.  I wrote to him:

"I remain skeptical about the applicability of agile concepts to, lets say, the construction of an office building, or digging the Chunnel.  They could well be appropriate during the design and planning of projects."

In response, he sent me the following extract from his next book, not yet published. 

An issue emphasized in Agile methodology is 'value to the customer'. I noted this comment in 5th-edition on Control Costs, 7.4: 'Monitoring the expenditure of funds without regard to the value of work being performed for such expenditures has little value to the project other than . . .' Could make a good exam question!

Norris Goff

Recognize that Agile is not a Solution to Every Problem

If the only tool in your toolkit is a hammer, every problem starts to look like a nail. Whatever methodology you choose needs to fit the situation and should be customized as needed. For example, if I were building a bridge across a river, it might be somewhat ridiculous to take an Agile approach to designing and building the bridge. Imagine this:

  • Build the first span of the bridge, see how that comes out, and then we’ll figure out how to build the other spans based on how the first span came out, or
  • Start with just a vision for what the bridge is going to look like rather than having well-defined requirements and specifications from the beginning and further elaborate more detailed requirements as the building of the bridge progresses.

That approach probably wouldn’t work very well. If you’re building a bridge, at some point, you probably should have a fairly detailed design to specify how the bridge will be built early in the project. The impact of bad design decisions in the design of the bridge is too significant to leave any room for a trial-and-error approach.

An example of a situation where a pure Agile approach might be problematic is the I-35 Bridge that collapsed in Minneapolis in 2007 “dropping cars from the interstate into the 15-foot-deep Mississippi River below, trapping many passengers inside. Before they could escape or emergency help arrived, 13 people died and another 145 were injured in one of the worst bridge disasters in U.S. history”. An investigation by the National Transportation Safety Board revealed that a major cause of the failure of the bridge were weak gusset plates which are components that helped connect steel beams. The gusset plates were designed at only half the required thickness.

This is definitely not a situation where you would want to compromise the due diligence needed to verify that the bridge design meets all applicable safety standards in order to adopt a more Agile approach to get the bridge done more quickly; however, it doesn’t preclude the use of some Agile principles and practices if they are used sensibly:

  • The Agile principles certainly don’t advocate substandard design practices like this to meet a deadline or to cut costs; you potentially could use a somewhat Agile approach if it had the right level of design reviews and controls to detect these problems built into it.
  • Examples of Agile practices that might be used include early prototyping, front-loading of the riskiest, most unprecedented or ambiguous design elements, and continuous QA testing throughout the project.