So many times as project delivery professionals we hear the postmortems when projects fail:
“We must not have planned enough…”
“Our functional spec must not have been detailed enough…”
“Our brainstorming sessions should have been longer…”
“Our sponsors didn’t really know what they wanted when we captured the requirements…”
“We delivered on time and on budget…but the customers still weren’t happy…”
“Our stakeholders changed their minds, and by then it was too late…”
We also hear that an Agile, iterative development approach isn’t adequate for complex problems because the traditional pre-planning effort is much less rigorous. To people who don’t share the Agile mindset, pre-planning is the appropriate response to complexity…And the more complex the problem, the more pre-planning that is needed.
In many cases, this apparent need for pre-planning is justified. Scientific processes, such as building highways or skyscrapers, automobiles or hospitals, can usually be broken down into defined steps and can be enumerated up-front and executed with little risk of change midstream. In these cases, the cost of change is very high. But software development is not a well-defined, scientific process. It is very much EMPIRICAL in nature. Why do we continue to apply methods that work best with well-defined, scientific processes to empirical problems?
In May of 1961, president John F. Kennedy issued a challenge to the country and a warning shot to our largest geopolitical adversary of the time: that the United States will land a man on the moon and return him safely before the end of the decade. Did he do this because he knew that we had the full plan to accomplish it at that time? Quite the contrary. In 1961, no one on Earth knew how to get to the moon. We had only just twenty days prior sent our first man into space. NASA was only three years old. Many of the tools and materials that were ultimately needed were yet to be invented…the idea of a moon landing and return might as well have been a Mars landing and return. Both were equally impossible at the time. No amount of pre-planning could have yielded the desired result. A waterfall-style, prescriptive plan simply wasn’t in the cards…because nothing like this had ever been done before.
We accomplished the most complex, challenging endeavor that man has ever undertaken, not by prescription and pre-planning, but by fostering emergence, accelerating the feedback loop, and then inspecting and adapting. Basically failing over and over again, with each failure enabling us to make the necessary changes to get closer to our goal. That is the formula for solving complex, empirical processes…and make no mistake, this was the mother of all empirical processes.
The high-level gates of the Mercury, Gemini, and Apollo programs served as iterations; opportunities for inspection and adaption. Inside each of those programs were countless smaller iteration, emergence, feedback, and inspection and adaption cycles. Autonomous teams of empowered individuals, free to fail, learn from that failure, and implement change were the only way to approach this type of complexity. We all know the result: July 20, 1969…
“One small step for man, one giant leap for mankind.”
Software development, believe it or not, works in much the same way.
The Agile mind-set challenges the traditional belief that complexity should be met with pre-planning, and proposes that emergence is the appropriate response.
The customer can’t, and shouldn’t, be expected to know their full wants and needs up-front. Not because they don’t want to, but because it’s impossible. Just as impossible as creating a Gantt chart for going to the moon in 1961. They may have a high level vision, but the true details of what constitutes value emerge over time and through iteration. Written words in a functional specification, static 2-D representations of proposals, and non-functional mock-ups simply can’t replicate working software for sparking your customers’ imagination. Combine this with the fact that the passage of time between presentation of the non-working concept and actual delivery increases the chance of obsolescence.
Agilarc can help you cultivate the idea of emergence within your organization. We can develop strategies to accelerate the feedback loop, help you inspect and adapt, help to educate, empower and connect your value providers and value consumers, and ultimately help to provide the RIGHT solution; not necessarily the solution you thought you were signing up for six months ago. Your software problems may not be as complex as landing on the moon, but the approach to solving them is fundamentally the same: emergence defeats complexity!
*(image credit: The John F. Kennedy Presidential Library and Museum)