November 18, 2008 — CIO — 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.
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.
It's really a pretty predictable mess, says Cockburn. The people driving the process keep being told, we don't need this much thinking. "I actually saw someone write on a [discussion] list, 'If you have to plan, you're not Agile enough.' And unfortunately, that really does bad things to projects," he adds.
Alternately, the team may have a good rapport with their customers, but be unable to control the project scope. Another problem, says Cockburn, is when people don't get the size and shape of the system they're supposed to build; they only work from user stories. "The user stories multiply like rabbits. If you were to do a burn-up chart, where the line goes toward the ceiling, instead of down toward zero, you'd find that the ceiling is going up faster than the progress being made." That's depressing for everybody involved, Cockburn says.
"I'm not sure where this has come out of the manifesto," he wonders. "But what happens is that [developers] say 'We don't need to know how big the problem is, because we'll give you great stuff as we go along.' So they never figure out the shape of what it is they're building, which means they don't have a clue how much it's going to cost." The 'Agile' team might say, "This looks like 170 story points," but they don't have any basis for that estimate. It turns out to be 700 story points, "But they only discover that as they go along, much to the depression of everyone involved," Cockburn adds.
When All You Have Is A Hammer, You Want to Bang on Too Many Nails
It's also possible for developers to insist on using every tool in the Agile/Scrum tool-bag, even when it doesn't make sense. "I struggle at times to determine how to apply the principles to a particular task that I'm doing," Beck confesses. "It often comes down to a practice that makes sense in general, but that doesn't make sense in a particular situation." Even though he's being "doing Agile" for years, he can sometimes have a hard time figuring out how to apply it.
"I don't think that's a problem with Agile development per se," he says. "If I was a dyed in the wool waterfallist, I think the same thing would apply. You need to be able to get to a context where you can see that it doesn't apply to this situation."
But even when the techniques don't apply, the underlying principles of Agile—such as transparency and accountability—still do, according to Beck. "That makes sense whether I'm doing a technology spike or production programming or a research paper, or doing some kind of highly risky blue sky research. But how they apply is different, in different contexts." This can be especially true in early project stages.
It's good for teams to call their shots, but Beck says it's important to make commitments. That isn't easy when you don't know a lot about the user's needs, and it can be hard to know what to say with any certainty. Still, Beck says, you can explain to management and users, "At the end of the week, we're going to know something we didn't know before," even if you can't say that at the end of the week you'll have a specific feature. "Because you might not know it that feature is even possible, but you can still call your shots as far as what it is you expect to be able to learn," he says. "The principle of transparency holds even at an early stage. You might not expect to see a bunch of tests or some production-ready code. But it takes a kind of flexibility to apply that without clinging rigidly to the practice."
That's why the manifesto has a line about individuals and interactions over processes and tools, Beck says. It's not that processes and tools are not valuable. But in fluid situations, Beck's experience has shown, you're better off relying on people who can recognize the situation and respond to it creatively. That's far better than saying "Here's the point in the process where I'm supposed to write a test, so I'll write a test."
It's also possible for an individual to lose sight of the Agile principles and become focused solely on process. Beck met one team at a conference dinner, several years ago, which had been working under a very dogmatic coach who insisted that everything had to be done in exactly "this" way. "The management had said that they had to do [Agile] or they would be fired, and they were furious—understandably so," says Beck. It's not that Agile was inappropriate, he points out. They could write tests, they could deliver something at the end of every week. All that stuff was physically possible. But, Beck says, "If you're going to ask someone to do something difficult or challenging, you need to build a relationship to begin with. You need to spend time maintaining that relationship through the difficult situation, and the coach hadn't done that."
It can also be very difficult to take when a well-functioning team suddenly finds themselves stuck with what they see as an unneeded burden. "It's certainly frustrating," says Beck, "if you have a process that's working well for you, and somebody comes along and says 'You have to change it, because everyone else is changing.' At that point, it's getting in the way of your progress."
Broken Engagements
Agile development also depends upon the engagement of the sponsors or customers in the process. That's a difficult transition for some, according to Cockburn. "It looked like for a while that we were pushing all the power down to the programmers, but in fact we were evening out the power and responsibilities. Everyone gets to feel awkward about that." In some organizations, he says, programmers ignored their bosses and built whatever they wanted.
At the other extreme, programmers expected the bosses or managers or sponsors to tell them accurately what the priorities were—not something the managers were used to. "So you get a breakdown on both sides," says Cockburn. "The sponsors aren't used to being asked to show up and care about the project, even [about] the requirements. ... They say 'No, that's what we hired you to do.'" The programmers respond, 'We don't know; we need you to help us figure it out,'" he adds. And the sponsors say, 'We don't have time. Work it out yourselves.'"
Agile's Not Always Appropriate
Then there are places where Agile just isn't the right fit at all, says Cockburn, such as organizations with high turnover (i.e. franchises like McDonald's). The processes are really critical, and staff doesn't have the time to learn by apprenticeship because people are coming in and being trained all the time. Other venues where Agile isn't workable, he says, include situations where you need comprehensive documentation, life-critical systems or certain types of legal situations—when that's more important than the working software. "
Finally, remember that Agile is intended for processes that will go through multiple iterations, reminds Cockburn. "Agile is built on incremental development," he points out. Not for projects that are one-shots, like a Bar Mitzvah or wedding. ("You know you don't get more than one iteration on a wedding," he says.) To apply Agile principles in those scenarios, you have to plan very, very carefully. "You might still borrow a burn-down chart, you might borrow some techniques; but you're not going to get the advantage of multiple iterations [or] reflective improvement in that."
Agile as Religion: When Even Founders are Heathen
Finally: once individuals become familiar with Agile, either through training or practice, they can become inflexible and intolerant of people new to the process. Cockburn has seen this in action. "I'm one of the authors of the manifesto, so if I say something 'weird,' they can't tell me I don't understand Agile. But if someone else— and it doesn't matter how many years of experience they have—says something funny, they get told they don't understand Agile." That makes Cockburn gnash his teeth. "They can't yank my club card, but they can pretend you don't have one," he says.
Sometimes Agile principles are grossly misinterpreted, according to Cockburn. "I get called in by a CIO, CTO, any CXO, and they're suffering because their programmers are telling them 'You don't know anything about Agile. Agile means we don't have to give you a plan, Agile means we don't need an architecture'—a whole bunch of rubbish that isn't in the Agile manifesto." So Cockburn, or people like him, have to come in and tell the CIO that it's okay to ask for a plan and an architecture. "But it takes me to come and do it," Cockburn says. "If anyone else says it, they get told that they're just an old fuddy-duddy, [and that] they don't know anything about Agile."
via http://www.cio.com/article/464169/When_Agile_Projects_Go_Bad
Posts
