One of the core priniciples of Agile is a realistic attitude about the unknown. We might have a rough idea of how much work it will take to complete a project, but we cannot state with the certainty of a papal bull how we're going to get to that destination. Therefore, Agile teams have to embrace Agile principles like loving plans, but abandoning any fetishistic relationship with specific, immutable plans.

Agilists learn to live with uncertainty, but they're far from fatalistic about it. In fact, the opposite is true: the truly good Agile teams assume a very aggressive posture about the management of uncertainty. In this respect, Agile software teams behave a lot like military professionals. First, they accept the inherent unpredictability that they'll face, either on the battlefield or in the backlog. They adopt maxims like, "No plan survives contact with the enemy," or concepts like friction, to describe the nature, sources, and effects of uncertainty. Next, they develop strategies, like the OODA loop (observe, orient, decide, and act), to navigate through the minefields of unexpected outcomes. And finally, they adopt a great deal of rigor and discipline, plus no small amount of self-criticism, to the application of these uncertainty-management practices.

Normally, we see these precepts at work within Agile teams, applied to the software product. However, what we've learned from our research is that, for Agile to have the highest probability of success, the organization needs to adopt the same perspective on the software development process. Agile is itself an exploration into the unknown, in which teams must self-organize, select the the order in which to adopt Agile practices, decide on how quickly to adopt these practices, and even strike a Faustian bargain with Waterfall where necessary. Agile, therefore, is the passage through a cone of uncertainty, with a big range of choices and challenges at the beginning, shrinking in size as the team learns and adapts. (Actually, there are multiple cones of uncertainty, but that's a better topic for a later blog post.)

And here is where many organizations can do themselves grievous injury, not adopting the Agile ethos about uncertainty outside the Agile team. Raise your hand if you have ever witnessed one of the following situations:

  • Someone outside the newly-Agile team grumbles that, "They're just doing daily stand-ups. You call that Agile?"
  • An executive has a simplistic understanding of Agile (usually, Agile equals speed), and gets his or her C-level knickers in a twist when the process seems slower than expected.
  • Business stakeholders wonder what all the fuss is about, since the software looks not much different than it did before.
  • QA people, used to a more peaks-and-troughs schedule for testing, are having a hard time seeing how to insert themselves into a schedule of more consistent activity (and need for their services).
  • Project managers feel sidelined, and wonder aloud who's doing all the work needed to manage risks and keep the project on track.

In all these cases, the people voicing these concerns might have a point. On the other hand, they might be jumping the gun with their criticism.

  • The team might be struggling to adopt Agile practices beyond the daily stand-up, but given time, they will succeed.
  • The team might have encountered some unexpected barriers to Agility (working with off-shore teams is a common scenario we discuss with clients), and hasn't yet worked out how to eliminate these obstacles.
  • Software quality improvements usually aren't visible over the course of a couple of sprints.
  • The dev team may be very concerned about testing issues, and may be willing to take some bold steps, such as adopting test-driven development, to address them.
  • The team is collecting data about risk mitigation over the course of sprints, and hasn't yet worked out their strategy for managing risks more effectively. 

In other words, there's a great deal of thrashing about that happens as the team traverses the cone of uncertainty, at the end of which lies Agile adoption. Some key investments, such as coaching and training, can shrink the cone of uncertainty, but it won't eliminate it entirely. Hence, the thrashing about that's inevitable. Unless people outside the team understand that principle, they will not understand that key element of Agile transformation — or any form of disruptive change, for that matter.

And that's something that people in the military could tell you, too. When military doctrine is relatively stable, teams (squads, crews, etc.) need to learn how to work together. They may apply some well-established practices (often codified in field manuals), but they have to apply them together. Mistakes will occur, relationships won't work out — in other words, thrashing about will occur.

When military organizations go through disruptive changes, as the US Army did over the last decade, even more thrashing about will occur. Not only are the teams learning how to work together better, but they're also experimenting with new practices that have effects beyond just the team. Intelligence, close air support, command — it's hard to find aspects of modern warfare that haven't changed in the US Army, as a result of adopting a brand new doctrine, birthed in the mountains of Afghanistan and the streets of Baghdad. Fortunately, they had commanders who ran top cover for them, providing guidance from past experience, letting them try risky new experiments, accepting the inevitable thrashing about.

And if the US Army can do it, why can't an IT department?