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 Beck, 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, Beck 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," Beck says.