What’s not to love about Agile? Plenty.

The Agile software development method is fundamentally about getting better software done fast. So what’s not to love about that?

Plenty -– if cries of “Give us Agile!” are actually signs that a project, or even a whole information technology department, has deeper issues that go beyond what the technique can resolve.

That’s the argument that Patrick Gray, founder and president of the IT consulting shop Prevoyance Group, makes in a TechRepublic piece that gives a remarkably clear-headed view of both Agile’s power and its limits.

I think of Agile as a cousin to DevOps. In my simpleton mind, Agile is all about breaking up a big piece of development work into a large number of bite-sized pieces.

The idea is to quickly get one piece of software code designed, written and tested, push the end result out, and go on to the next piece. DevOps is essentially an extension of that, but focuses on securing close and cooperative work between the development team that writes the code and the operations crowd that tests the software and launches it.

But while the reward of both Agile and DevOps can be fast turnaround of improved software, both techniques take time, planning effort to implement in an IT organization. “(N)ot every initiative can benefit from Agile,” Gray notes.

Here, according to Gray, is what different stakeholders mean when they say, “We need Agile”:

  • Executive management: “IT is too darn slow and expensive, and rather than fix the underlying problems, I just want everything faster and cheaper.”
    • Solution: Find and remove what’s creating the slowdowns, such as slow decision making, indecision by stakeholders or insufficient resources, Gray advises. “Blow away the blockers, and then worry about changing your method.”
    • Developers: “We’re tired of documentation and formality. We want to code rather than document.”
      • Solution: A misconception about Agile is that it eliminates the need to document requirements and code, Gray writes. While Agile’s documentation requirements are different than other methods, such as waterfall-based techniques, “poorly documented code is poorly-documented code.”
      • Analysts: “No one is willing to make a decision, and we keep changing scope.”
        • Solution: Though Agile can assist initiatives with uncertain long-term scope, “it does little to help projects that can’t commit to what needs to be delivered in the next three to 30 days,” Gray writes. “If you can’t agree on what you’re doing tomorrow morning, Agile is not going to help.”
        • Customers: “Show us something concrete for all the money we’re spending.”
          • Solution: Large projects often lack tangible results until the effort is fairly deep into the process. Use prototypes, early involvement in development testing, or more frequent communication to keep customers up to speed on what’s happening with the work, Gray writes.

Lesson: Look before you leap

Gray’s basic message here applies equally to DevOps as it does to Agile. Both methodologies require not just work and commitment to implement, but also entail changing corporate culture. That’s a lot to think about before jumping into them.

Thus, as Gray points out, if a cry for Agile or DevOps arises, it’s important to ferret out what the real issues are. Perhaps the problems are easily solved without going through an Agile/DevOps transformation.

In other cases – such as when executives simply want better results without investing time, money or effort – going to either Agile or DevOps won’t fix anything. In these unfortunate instances, in fact, I think doing a half-baked Agile/DevOps push could easily do more harm than good.

Implemented properly, I think both Agile and DevOps can deliver good results. But as with everything in the corporate world, the key word is “execution.” If execution is lacking, nothing else matters.