“What we really need to do is go Agile.” This statement makes me cringe, since it’s often an early warning sign that an initiative has deep structural flaws, and the well-intentioned individual who uttered those fateful words is often part of the problem.
In contrast to waterfall-style methodologies, where requirements for everything under the sun are meticulously gathered and the entire team transitions between well-defined project phases, Agile uses a series of short-duration sprints to get things done. At a basic level, a sprint is a micro waterfall project with a small set of requirements, a very rapid design and build period, and a rapid interactive testing period.
Agile purists can cite the various differences, but the most obvious appeal of Agile is its speed at generating results. While a traditional waterfall methodology spends months mapping out requirements, a typical Agile product will already have produced early results that can be seen and felt.
Successfully implementing Agile practices requires significant forethought, and not every initiative can benefit from Agile. Here’s how to tell when “We need Agile” masks deeper issues.
Executive management says, “We need Agile!”
Translation: IT is too darn slow and expensive, and rather than fix the underlying problems, I just want everything faster and cheaper.
It’s easy to “blame the suits” for not understanding the nuances of Agile, but in most cases when Agile is invoked someone is struggling due to the slow pace of an initiative. Rather than instantly seeking a new method to break the logjam, look for blockers, whether they’re slow decision making, indecisive stakeholders, or insufficient resources. Blow away the blockers, and then worry about changing your method.
The developers say, “We need Agile!”
Translation: We’re tired of this documentation and formality nonsense and want to code rather than document.
While few will readily admit it, one of the major misconceptions of Agile is that it eliminates the need to document requirements and code, and lets you spend time building rather than documenting. Agile certainly has different documentation requirements than waterfall-based methods, but poorly documented code is poorly documented code, whether it was created in an Agile manner or a traditional manner, and both will be equally costly to support in the long run.
The analysts say, “We need Agile!”
Translation: No one is willing to make a decision, and we keep changing scope!
Nothing saps the early energy from a project more quickly than constantly revisiting requirements and scope, and Agile has a legitimate place in helping projects where scope is uncertain in the long term. However, it does little to help projects that can’t commit to what needs to be delivered in the next 3-30 days. It can be difficult to manage long-term scope in many situations, but if you can’t agree on what you’re doing tomorrow morning, Agile is not going to help.
The customer says, “We need Agile!”
Translation: Show us something concrete for all the money we’re spending!
A frustration of large projects is that there are few tangible results until the project has progressed significantly. To the uninitiated customer, Agile often means “real stuff faster,” and demands for Agile can be satisfied with prototypes, early involvement in development testing, or even more frequent communication.
It’s hard not to like something with a moniker that implies speed, flexibility, and panache, especially when the details behind the methodology are poorly understood, and the commitment required to successfully operate in an Agile manner is significant for all involved parties. When you hear someone clamoring for Agile, try to tease out the root causes of their request.
Sometimes, “We need Agile” masks a demand that can easily be met with an afternoon demo or a status update. Other times, “We need Agile” is an early warning sign of a fundamental problem with your project. Ignoring a request to consider Agile, or jumping headlong into implementing the methodology, are equally perilous.