When Agile Projects Go Bad
- 22 November, 2008 09:09
- Comments
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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.
- Bookmark this page
- Share this article
- Got more on this story? Email CIO
- Follow CIO on twitter
- Manifesto for Agile Software Development
- Does a Tech Manager Need to be Tech-Savvy?
- How to Improvise SCRUM for Corporate IT Projects
- Blog: 6 Stupid Mistakes Companies Make with Their Online Communities
- The Core Development Team's Role in an Agile Project
- 7 Agile Leadership Lessons for the Suits
- Stupid QA tricks: Colossal testing oversights
-
China's Alibaba sees big growth with AliExpress site
-
Pfizer's Future Depends on IT Transformation
-
10 Tips for Dealing with a Bully Boss
-
Social networking security in the workplace
-
Facebook stock slumps for third day
-
Protecting Against the Leading Causes of Data Breach
This whitepaper was written for the organisation that wants to focus on prevention of data loss and doesn’t have millions to spend, but needs affordable solutions that can be implemented today to protect millions of sensitive records and dollars worth of intellectual property. This whitepaper addresses: - What organisations can do to prevent the four leading causes of data breaches - Why dedicated (pure-play) DLP solutions may not protect you from all four leading causes of data breaches - How to get prevent sensitive data leaving your organisation -
Why Hackers have Turned to Malicious JavaScript Attacks
Website attacks have become a serious business proposition. In the past, hackers may have infected websites to gain notoriety or just to prove they could—but today, it’s all about the money. Reaching unsuspecting users through the web is easy and effective. Hackers now use sophisticated techniques—like injecting inline JavaScript—to spread malware through the web. Learn about the threat of malicious JavaScript attacks, and how they work. Understand how cybercriminals make money with these types of attacks and why IT managers should be vigilant. -
Enterprise Buyers Guide for Printers
Every enterprise owns, and regularly replaces, printers, copiers, multifunctional products and fax machines. The problem most face is not too few choices, but too many. How do you even begin to select the right one? Here is the Computerworld guide to buying a printer for the enterprise.

















Comments
Post new comment