Agile Is Not "Make It Up As You Go"

Much to my delight, there is growing recognition that the Agile movement has attracted more than a few constituents that leverage the great principles of Agile as an excuse to "make it up as you go". It's true that Agile enables and even encourages a system that responds to change and adapts efficiently in response to the collective assessment of the team in the context of demonstrable progress and up-to-the-minute (or up-to-the-sprint) evaluation of needs and opportunities. Good stuff. It's also true that Agile emphasizes people and collaboration. And it encourages empowerment and local decision-making. Really good stuff. Unfortunately, there are many examples where these valuable leadership characteristics are being taken to an extreme or taken out of context and applied in ways that can be damaging to the team, to the project, and to the business.

I was speaking with a senior IT leader recently. This individual, for whom I have a great deal of respect, has not had much exposure to Agile and was telling me about an recent experience with a self-proclaimed "Agile" team. The primary take away from their close encounter of the Agile kind was frustration that months into a project the team could not even describe the most fundamental aspects of their objectives. It reminds me of that quote, "if you don't know where you're going, any road will get you there." Adaptation and empirical process controls are good things - incredibly powerful and valuable. But Agile doesn't mean "we have no idea where we're going or when we'll get there or which road we'll take." Agile in the absence of meaningful vision and direction is just hacking, and hacking gives Agile a bad name.

Mike posted a nice writeup on how we might look at RUP as an effective framework for organizing Agile teams at scale. In this post, title The Agile Heart of the Unified Process, he writes:

The secret to scaling Agile lies in doing just enough up front planning to ensure the teams understand the big picture of the product they are creating and have defined the significant mechanisms of communication between the various subcomponents. The RUP provides an ideal framework for helping a collection of small teams define what needs to be done in support of a large scale Agile development effort.

Whether you follow Mike's advise or some other, be sure to know where you're going on an Agile project - and be sure you've picked the right road to get you there.