Agile project management has taken the software development community by storm, with terms like sprint and Scrum becoming part of everyday team conversations. But as Agile techniques are incorporated into company practices, there exists the very real danger that Agile will be adopted in name, but not in spirit. With this in mind, we turned to the original authors of the 2001 Agile Manifesto for advice on how Agile can be subverted.

Paint-by-Numbers Innovation

A typical developer pain point is when Agile techniques are applied dogmatically, without thinking through whether a specific practice makes sense for a given task. They confuse checklists with real Agile adoption.

According to Alistair Cockburn, one of the original 17 signatories to the manifesto, some of this weakness can be traced back to how people acquire new skills. People tend to have three stages of skill acquisition, he says. "In the first stage, people need to follow a recipe. In the second stage, you say 'That's all very nice, but I need more,' so you go off and collect recipes and ideas and techniques. And in the final stage-if you ever get there-is a level of fluency and intuitiveness where you can't say what you're doing, but you kind of borrow and blend."

As a result, says Cockburn, level-one thinking leads to the mentality of "I have my checklist, I have my certificate." He says, "In general, we tend to deplore it, because Agile is really about level two and level three." The experienced developers and team leads should be paying attention to how things are going. However, adds Cockburn, "Anyone who comes into the business will naturally, perhaps necessarily, ask for a checklist. So now you get the Scrum-master certification and the Agile checklist and the Scrum checklist and the XP extreme programming checklist; everybody wants a checklist. We need to get people out of that box and into an arena where they're thinking about principles and feelings, and not [about] a checklist."

Kent Brock, another Agile manifesto signatory, says it can be a challenge for organizations to take on the new challenges of Agile development. "Lately we've been talking about Agile in terms of words like 'self-awareness' and 'self-discipline.' And somehow it was an unnamed presupposition or an unnamed characteristic of a group of people who were successful using lightweight processes that they were pretty self-aware people, and that they would have a lot of self-discipline." But now, the Agile community is asking organizations to take on those characteristics. "They think they can just go by rote and issue some edicts," he says, and people will magically take on those attributes.

When companies apply Agile practices without self-examination, Brock says, peril lies ahead. When companies try to "do" Agile mechanically, he says, "We ask, 'Well, aren't you talking about it? About what's working and not working in the quality of your communications and your community?'" Because the initial community was self-motivated, those issues didn't need to be addressed early on. "These are the things we didn't think to say back in 2001, and now we're seeing people applying it very mechanically, we're seeing what's missing," Brock says.

If You Don't Know Where You're Going, Agile Won't Get You There

Cockburn also sees teams use Agile as an excuse not to engage their customers at a detailed level. Developers don't have a plan, don't get requirements -- and may not even be very good designers to start with.

Cockburn says, "They start going around in circles, and the customers or users try to tell them what they want, and the developers say 'No, no, no! That's too much information. Just give me the first sentence out of what you said and I'll go build it.' And then the users say 'But no, it's more complicated than that, let me tell you more.' The developers say 'That's all I need, we're doing increments, let me just build that.'" The result, of course, is that "They go around in circles, and they get lost, and they're over-budget," he says.