Alistair Cockburn on what's agile, what's not |
 |
By Colleen Frye
21 May 2007 | SearchSoftwareQuality.com |
|
|
Alistair Cockburn, a signatory on The Manifesto for Agile Software Development, talks about the agile landscape, what has changed and where his methodology, Crystal, fits in.
What are some of the key ways perception and acceptance of agile methodologies have changed since the manifesto was first published?
Alistair Cockburn: Before the manifesto, there was a subset of people around the world who were working with these techniques. Then we wrote the manifesto, and a lot of people crawled out of the woodwork. People started teaching it and writing about it and so on. The immediate reaction was, to the people who weren't doing agile, that this looks like hacking. Then it gained some solid ground, and the next thing that happened is something we could have predicted, which is that it becomes such an overused word it starts to lose any meaning. So now the question is, does it meaning anything?
That causes us, the people who were thoughtful about what we were doing, to gnash our teeth. Is there any remedy for this? The answer is no. We just keep educating people, but that's just the way the world turns.
So if we look out there now, we see real developments that have been made, true proper agile programming techniques. The people who do that are having outstanding results. Then we see people who don't think about anything at all, but they like to follow the current brand and so are doing hacking and slashing, what I call "'lost in the woods development,"' and say they're doing agile. We even have waterfall-ish projects that have founds ways to use the agile lingo to make it look like they're legitimate. And then we have other people who say "'agile"' because it means they're up-to-date, but they haven't got a clue because they aren't thinking about it. And there are still people who are dead set against it.
When you all wrote the manifesto, did you mean for it to be followed in a precise way, or did you expect people to adapt it?
Cockburn: We wrote it in very generous speaking, so that there would be a lot of room for different variations to coexist. We knew it would get corrupted sooner or later, but I guess it's a sign of success if it gets corrupted, and it's better for that to happen then to be ignored.
Since "agile' seems to mean different things to different people, could you come up with a David Letterman-like Top 10 of how to know you're not doing agile?
Cockburn: In no particular order, you know you're not doing agile if:
- The team is co-located, but people are not sitting within the length of a school bus to each other.
- They're distributed, and there is an absence of microphones and webcams and one or two meetings a day.
- They have not delivered anything to real users in the last three months. Some of my agile friends would say that's much too long, but I'm being generous there.
- If no user has seen real running software inside the last month.
|
|
|
|
|
The next thing that happened is … that [agile] becomes such an overused word it starts to lose any meaning. So now the question is, does it meaning anything?
Alistair Cockburn
|
|
|
|
|
|
|
|
|
|
- They don't have the output of last month's reflection workshop or retrospective on the wall.
- They don't have fully automated unit tests, and a large number of acceptance tests aren't automated.
- They're not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.
- They write big requirements documents, and they don't know how to split those up into smaller pieces so they could deliver a piece of software every month.
- They have itty-bitty requirements on the order of "here's what happens when you click here," but they don't have long-term vision for what they're trying to accomplish.
- People keep saying, "It's not my job." One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they're doing and helps gather requirements; if tests aren't getting done, people with some spare capacity help test and so on.
You developed an agile methodology called Crystal. How does it differ from Scrum and Extreme Programming (XP)?
Cockburn: Crystal was designed to be the least intrusive methodology family that would be appropriate for many different kinds of projects with many different needs. There are two parts. The first is projects all differ, and it doesn't make any sense to try to have one methodology that works for all projects. The idea was there would be a family of methodologies. So if you had a small, co-located, not so critical project you'd work in one way that was fairly loose, and if you had a large team of 50 or 80 people and a more critical project, then of course you'd have to change the work habits. So my assignment in creating Crystal was to try to find a way to talk about what's in common across that range, and how do you adapt the way you're working as the project changes size and shape over time. That was the first problem.
The second was that I wanted to deliberately leave the most amount of self-determination for the people in the projects -- I wanted to tie their hands the least. This is very different from both Scrum and XP. XP is very explicit, especially the first version of XP back in the 1998-2000 time frame. It told you exactly what to do -- a small team, co-located, and they had to do pair programming, and so on. So it was very invasive. It's an excellent methodology, it works when you follow it, but it tells you what to do, and it also has a limited range of projects in which it works properly. That's OK as long as you're aware.
Scrum is really wonderful because they found a common subset across virtually all projects; then again, they don't tell you very much at all. They say get together, work it out, demo once a month, reprioritize your requirements once a month. That's a great piece of advice, but it has so many gaps; there's too much stuff to fill after that.
Probably the other distinguishing feature of Crystal is there should be a reflection workshop at least once a month and the results are posted on the wall, so that way the team can tune and change [the process] over the course of the project. It's one of the very few self-tailoring methodologies out there. It's supposed to be tuned and tailored at the rate of once a month. That way the project team, if they get hit with surprises -- staffing changes, technology changes, mission changes -- can respond in a timely fashion. That's probably the new thing that Crystal brings to the table.
XP brought pair programming and refactoring and automated unit tests. Scrum brought this dynamic reprioritization and self-organization. And Crystal brings this notion of a reflection workshop and the process tunes itself or the team tunes the process on a monthly basis within the course of the project. So for Crystal it would be fine if the people started off not doing pair programming, and then for whatever reason they did pair programming for a while, then for whatever reason they stopped.
What sense do you get for how widely adopted Crystal is compared with Scrum or XP?
Cockburn: It's not widely used. I tried to make it as easy as possible, remember it's the least intrusive thing. There are two reasons why it doesn't get used as much as it might. The first is plain old press. Scrum and XP both have done an excellent job of advertising and spreading the word. I haven't gone down that path. The other one is Crystal is remarkably difficult to do because so few organizations are willing to deliberately think about what they do and make changes, talk with each other and try out the changes. It's really not for the novice group. It's for people who have been in the field, they know a lot of stuff that works, they have an idea of what they want to preserve, they like the codification and they're willing to do the dialog, and then they get typically good results.
Dr. Alistair Cockburn is an internationally renowned author, project "witchdoctor," IT strategist and expert on object-oriented software development. He is best known for describing software development as a cooperative game, for co-authoring "The Manifesto for Agile Software Development" and for defining use cases. His books include Agile Software Development: The Cooperative Game, Crystal Clear: A Human-Powered Methodology for Small Teams and Writing Effective Use Cases.
|
|
|
|
