Every now and then someone tells me "my team is Agile", only to proceed with an example that just floors me. Here's a recent gem:

"For my manager Agile means using XPlanner as a time reporting tool."

Agile has become a buzzword. For many people, it's something you just want to do or be because, well, everybody does it. Or so it seems. Everywhere I turn, companies are "going Agile". For many years I've been helping teams and companies adopt it; nowadays, I also help many of the do-it-yourself companies fix or improve it.

I've discussed Agile with hundreds of folks over the years. Most hear about Agile principles, such as collaboration and close customer contact, and nod; of course they make sense. Some engage me in an academic argument over other principles, such as frequent releases and evolutionary design. But when they agree to try the methods out, they discover just how devilishly difficult they are to implement.

Now, close to the end of "The Agile Decade" in software development, we have ironed out many of the kinks in our practices and tools. We've done Agile projects in every industry. We've done distributed Agile. We even know how to do Agile contracts. And still, misconceptions and "process mixes" abound. For example:

1. A lady told me, "We do Scrum". "How frequently do you ship software?" I asked. "As before, every year." A couple of questions later I discovered that their management "brought Scrum in" and "bought into it" by just having a daily status meeting as opposed to weekly. They truly believed that was Scrum.


2. I was coaching a large transition at a well-known financial company two years ago. The program manager was very supportive of the effort and open to all the recommendation my fellow coaches and I made. But after our first retrospective, he told me: "You did it all wrong. After you solicited input from everybody, you should have simply compiled it, presented your results, and told them what to do next."


3. I was interviewing a team leader for a large multinational who'd submitted an experience report about adopting XP. In a nutshell, his message was: "We were doing XP for a while, but didn't like pair-programming. We tried to have everyone review code after it was written, but that didn't work so well. We still do XP, but in many instances the best way is to spend quite some time on up-front design."

Even when they get the practices right, organizations might still just be going through the motions. Sure, you can hold a retrospective, but if it's not a true team learning and improvement opportunity, that meeting won't amount to much. You can collaborate with your customer all day long, but if the customer isn't empowered or informed, you'll build a great wrong product.

The way I see it, it's following the Agile principles that counts.

When I assess an organization's or team's Agility, I give the practices a cursory look before starting to ask questions that tell me how well they are following the principles. Which is why I bristle at some people's blind attempt to make a standardized test out of the famous "Nokia test". That test is very specific about Nokia's particular way of doing Scrum — down to Planning Poker, which is but one technique of many and not native to Scrum — but you would fail the test if you got creative and optimized.

For a condensed form of the principles, look at the Agile manifesto. Even though that document is almost a decade old, and there are newer proclamations, its concise wording is extraordinarily accurate and every word packs a punch.

If you say you're Agile, you must educate yourself on what that means. You must embody the principles and values, not just follow practices. If you don't truly get Agility, making up a nominally Agile process is courting disaster.

Copyright © 2009, 3P Vantage, Inc. All rights reserved.