It's a Scottish name, and it's pronounced "coh-burn." C-o-c-k-b-u-r-n. I put the pronunciation of my name in the preface of all my books. It's really funny I've met people who called me Alistair all day long and they go back and talk to the team and they say "I had lunch with Alistair Cockburn." "No you didn't! You didn't know how to pronounce his name, it's written right here in the book, it's Co-burn!"
The Manifesto creation was pretty interesting. I got started in the object-oriented community in '91 coming out of IBM research and IBM consulting group, wanting to create a methodology for object technology projects. I didn't know anything about methodology at that time, so my boss gave me unlimited plane tickets to go and interview projects inside and outside IBM, all around the world. As I did that I noticed a very sharp division between projects that succeeded and failed. Basically those who were doing these things we call agile - co-location, face-to-face, fast iterations, feedback, customer access and that sort of stuff - were succeeding, and those who were being very diligent in their process were pretty much failing. Among the people that I interviewed were Ward Cunningham and Kent Beck. There was a group of people through the '90s, coming in through object-oriented technology in a sort of pathway, who were all kind of saying this lightweight, people-centric stuff, all through the '90s, and then in 2000 Bob Martin said "I'd like to get these people together and find out, are we all coincidentally sounding alike, or is there something fundamental there that causes us to be the same - and by the way, I don't like the name 'lightweight process' and 'lightweight methodologists.' This just doesn't work for me." So we met. Jim Highsmith was living in Salt Lake City at the time and he and I were kind of partnering. So we induced everybody to meet in Snowbird. We had the European representative for DSDM, FDD, Scrum - we had Ken Schwaber, Jeff Sutherland and Mike Beedle here, a bunch of XP people, Jim Highsmith doing adaptive stuff and me doing my Crystal stuff. We spent a day about who we are and what we are standing for. That didn't look like a coincidence. Do we write a manifesto? Is there a name for what we do that's not reactionary against - lightweight is against - so what are we for? We did a very deliberate name search. We spent about an hour looking for names and took votes and so on. It came up with the word "agile." What we are, what we stand for as an umbrella term for all of us, across all our different styles is "agile." Then we rummaged around and somebody had the idea of doing value statements. What do we stand for? What do we not stand for? We came up with the four values saying "It would be legitimate for people to choose the other 4 values or any combination. So there's like 16 combinations. What we want to assert is however different we look on a moment-to-moment basis, we do stand for these 4 things when push comes to shove. The way to interpret the Manifesto isn't that the stuff on the right is bad, and the stuff on the left is good. You need all the stuff, but when push comes to shove, and push always comes to shove on a project it seems, you have to go stand somewhere. And you can either put your money on your tools or put your money on your process or put your money on your people. We put our money on people so that was the way you read the Manifesto. We came out with those 4 values that are very well known and then we tried to ask, was there any more that we could agree with, like more specific, knowing that when it comes to the day-to-day stuff we actually disagree. But we wanted to have space for us to disagree, so you cannot expect to ever see the unified Agile methodology. As far as we're concerned it can't be done, it has no meaning, it shouldn't be done. So we went for the 12 principles and there we were really on the edge of what we could agree on. And also it was interesting that people started to get on planes and go home. Which means that we were losing the face-to-face and we were going back to emails and phone. That really illustrates the whole point of the Agile stuff. While we were face-to-face we could construct this; the moment we split up - distributed teams, all that stuff - it just gets much harder. So that was the construction of the Agile Manifesto, and it was amazing; it just clicked like that within months. There were panels all over the world, you could sign up on the website, thousands of people signed up. So it was being done all along, there was a whole universe of people already doing this around the world, they just needed a place to center. And I have to lead in to 2005, the Project Leadership Declaration of Interdependence, which is a follow-on, if you will, of the Agile Manifesto, because the Manifesto is very much software-focused and project-focused. But what do you do if you're doing non-software? It's very much programmer-centric, the Agile Manifesto. What if you're not doing software, if you're not a programmer? What would it look like? The principles apply. I do house reconstruction and I use all the Agile ideas for that. Conference design, book production: I did one of my own books and shrank the production time from 3 months to 3 weeks by using all the Agile principles: co-location, feedback, iterative development, all that sort of stuff, and I can't get the book companies to match that at all. We had a time line and I said, "The only way we're going to do this is to use agile techniques." So the question was: What's the larger view of this if you take the word "software" out of it? First thing is you could take the Agile Manifesto and plug in the word "product"; instead of saying "working software" it would say "working product". And now you could be doing anything. In fact I met a guy who designs airports for Delta and he uses all the Agile ideas - early integration, co-location, trust, community, all that kind of stuff - in designing and building airports. In fact he uses what I call Crystal Clear. Many of the same techniques he uses for airport construction. It's really fascinating to talk with this guy. So, product managers, project managers, line managers, consultants, we spent about a half year coming up with what's the project management view and then in January 2005 we came up with a similar thing but we decided not to make it a manifesto and not to have an enemy so it's called the Declaration of Interdependence. So pmdoi.org has got that, and I won't go into that, but that's got now a whole movement of trying to get project managers and leaders to understand incremental iterative development, people-centric, iteration-based reflection, value-based instead of tasks, all that sort of stuff.
3. You were involved in the Declaration of Interdependence as well: Is that getting a good response?
It's growing really nicely and we've got APLN (Agile Project Leadership Network) locations going up around the country - Calgary, Washington DC, Seattle and so on. Some people like to make fun of the PMI as being heavyweight stuff, but there are a lot of people in the PMI who are not satisfied with what they are seeing there, they're hungry also, so they're joining the APLN and it's very nice. We're taking it out of project programmer territory up to executives to help them understand how to manage projects - in effect, companies - and we're taking it out of the product development and away from software.
I was in IBM and was going around, doing all those interviews and one of the things that struck me was the fact that pretty much every project is different; every project really needs a different methodology. I started in '91 and in 2003 I got my PhD in Methodology. That was the big culmination of all this research, of doing all these interviews and stuff. I actually turned it into a doctoral dissertation at the very end. One of the things that became clear is that you can't have one methodology, you can't do XP for all projects - it wouldn't make any sense. You can't do FDD for all projects, you can't do what I call Crystal Clear for all projects - it's not even meaningful. So what I decided was that there should be a family of methodologies and not a methodology framework like RUP, where you have all the parts and you have to assemble the motorcycle, but rather I'll show you a motorcycle and a bicycle and a car and a van and teach you how to make the intermediary things. So Crystal is a family of methodologies, and there's a sort of genetic code so you can detect family resemblances and there's some guidelines about how to create a new family member. So when you say the word Crystal, it isn't yet a methodology, but is the declaration of the family resemblance, if you will. That's a key in Crystal. Because you don't have to be upward and downward compatible in a methodology. It's not needed. People don't need that. We've done projects where people come in and say "We've just picked up a satellite site, we're no longer 3 people together, we're now 18 people on 3 sites, let's use the following rules and conventions". That's all a methodology is, rules and conventions. And you tell everybody "We're now going to meet here, we're now going to do this, we're now going to plan this way," and they say "OK". That's about how much they care. So you can really convert methodologies, really it takes about a day. So you don't have to have upward or downward compatibility. So what's together, and you'll spot the Agile stuff here, is: 1. Frequent delivery. We can negotiate how frequent is frequent, we can negotiate how delivery is delivery, but nonetheless frequent delivery is a core concept of any Crystal methodology. 2. Close communication. There's this cool phrase: "osmotic communication," so when you're co-located you hear stuff out of your background hearing called osmotic communication. Really a tight focus on the frequency and closeness and richness of communication; face-to-face is really rich, and email is very, very dry. Any Crystal methodology is tightly focused on communication. 3. Reflective improvement. Most people pick a methodology and they just run with it, and they don't think about it, they don't take time out to think about it. So in Crystal, once a month, twice a quarter, once a quarter at worst, get together for an hour and say: What are we doing that we like that we want to keep, what's happening that we don't like, and what are the antidotes? You don't write down what you don't like; you write down what you're going to try next, so you always have initiatives rolling. So you could start from anywhere. So what happens is you start from an existing Crystal or you start from XP or you start from Scrum, it doesn't matter - you start from what you've done, you make a big list of what you like; you can start anywhere. You do it for a month and of course since you're doing frequent deliveries, you've got some running software there and then you get together and say, "Anybody heard of anything they want to try differently?" So there should be for any Crystal implementation, if you had a Crystal users group the discussion would be "What have you tried lately? What have you changed lately? How do you feel about that? Is the team happy or are they sad?" It's not, are we adhering to the XP principles or the Scrum rules or something like that. The real discussion in the Crystal group would be "What have you changed and how does the team feel? What's the community like? What's the morale like? What are your feedback paths like?" And that's Crystal. I've got them indexed by colour, kind of to match gems. I was going to call them quartz and topaz and sapphire and ruby; that wasn't working real well so I just went to colours. Crystal Clear was targeted basically for 6 people in a room, Crystal Yellow would be around 20 people, Crystal Orange around 40-50 people, Crystal Red around 100 people, and I haven't done more that that. So that's Crystal.
5. Is adaptability the distinguishing feature of Crystal?
One of the two distinguishing things about Crystal is, it's not a methodology but it's really tuned by the team. When I was finishing writing my PhD dissertation I already knew that you needed one methodology per project; what I learned was that you need a new methodology about every 3 months, so creating methodology has to be about as easy as picking up a tissue, blowing your nose in it and throwing it away. It has to be that easy. So Crystal contains some techniques for methodology tuning in less than a day. You have to be able to tune your methodology in less than a day. The other thing that's a distinguishing characteristic is, for instance, XP really tries to figure out what works best, what is most productive, what's the fastest and all the rest. I have this view of humans - frankly, I'm pretty lazy and sloppy and there are a lot of people like me. When I go inside organisations people are kind of resisting, they've got their habits and so on. So my quest is what is the least intrusive set of rules that will still add safety to the project? What I care is that the project delivers something regularly - it's like base hits in baseball. You don't have to hit a home run; a lot of base hits is really great. The other distinguishing feature besides the tunability is the fact that it is trying to be low-impact on the organization. Not what's best, but what's good enough and let them live with it, so habitability becomes a primary. Those are the two distinguishing features of Crystal.
6. So it sounds quite different from XP in the way that it's rolled out.
People think it looks alike but at the feeling level when you go to introduce it - Kent would say "Why would you want to have a base hit? Why wouldn't you want a smashing success?" And that's a great view. People like to introduce Crystal just because it's not as frightening to the people when you first bring it in. It also makes a good fallback, when people find XP too high disciplined they can go to a lower disciplined model, which is the Crystal model.
No. I just say "Pick an iteration length." Literally. Iteration length is an interesting topic because there's this funny kind of macho badge that comes with Agile, which can be pretty hazardous. The theory says the iteration length should be as short as possible. There's a very good theory that says 3 months is good. I will not allow anything longer than 3 months. One month is better, 3 weeks is better, 2 weeks is better, one week is better, one day is great. I was just talking about continuous delivery the other day. But the first principle of Crystal is frequent delivery not frequent iteration, so you really need a feedback all the way to the customer site. So what happens is that when people get together they talk about what they use. I watch what happens and I see that people don't have enough time in one week to actually talk to each other, build it and show it to the user, integrate it and get it tested and show it to the user twice so they get feedback inside the iteration. So they get this half-baked stuff, quickly integrate it, and they move on. What happens is that they get so focused on iterations and they get focused on the internal stuff and they never actually look at how they're delivering and what's the rate of delivery. So the more people focus on the word "iteration," the more they're disconnected from their user base. They should instead have a fanatical focus on the word "delivery" and get the end-to-end feedback. So I wrote an article called "Are Iterations Hazardous to Your Project?" which causes a lot of consternation in certain places, but it highlights these differences. If I could, I'd like to talk about the macho thing for a second. I don't do macho, so it really frightens me when you see these people do this chest-thumping, "I'm more Agile macho that you." And I've watched people get scorched. So I wrote a tongue-in-cheek blog about Agile Machismo points. It goes like this: give yourself 10 points if everybody sits within 10 meters of each other. That's pretty good. Then give yourself an additional 100 points if the team has delivered the software twice in the last six months and real users are using it for real business work. That's top of the line. However, if you haven't, subtract 200 points if they haven't delivered it at all in the last six months. Now if your score is positive, divide it by the number of people on the team - so we're going to reward the small teams, so you're not more macho if you doing it with 50 people. If your score is negative multiply it by the number of people on the team. And then the final thing - with all due apologies to Ken Schwaber - if your score is negative, multiply it by the number of certified Scrum masters on your team. The funny thing with this formula is that it actually has some interesting properties. The big waterfall project that hasn't delivered has an agility score of zero, because they haven't delivered in six months. And Ken would probably support me on this - if you have a certified Scrum master on your team and you haven't delivered in six months, you need a very big negative score. If you have a certified Scrum master on your team, you can't not deliver every six months because that would be pretty much a violation of Scrum. So you get these really big negative numbers on those things. That's the actual Agile machismo point system
No. And we agreed at the beginning of the writing of the Agile Manifesto. It was clear that we had different styles on a day-to-day basis, so we were pretty explicit between us that we would absolutely not try to create a unified Agile. We wanted to preserve differences of style, in different projects and in different authors, even. One of the interesting things that came out of that was that you sort of get these brand name wars going on. I'm doing XP, or I'm selling XP, which is the harmful version of it. What we're seeing over time is that people are blending them. They're looking more and more alike, without us creating a unified agile methodology or something. In fact, XP is looking more like Crystal and Scrum and Crystal, FDD is still different and DSDM is different. A lot of people are doing "roll your own", which is fine, and in fact most people were doing roll-your-own successful Agile stuff before we came up with the name "Agile," so it's not a problem. But the question that keeps coming up is this: Is it merely commercial greed that causes the brand names to persist? Should we just erase them completely? That's actually worthwhile picking up for a moment, because Kent doesn't get any royalties on people saying XP or doing XP, I don't get any royalties on people saying Crystal or doing Crystal. So why would we care about the word at all? So I've been giving it some thought because there are people who trying to literally erase the brands. And it dawned on me one day that what this when a person comes up with a methodology, what they are saying is that there's a set of practices and behaviours which when taken together have a good effect and I believe that I've got a packaging of these things and I'll sign my name to the packaging, so it says: "If you do these things, good things will happen on your project" signed, Kent Beck, or signed, Alistair Cockburn. And that's actually a very powerful statement. XP works, and when XP came out Kent said: "There are these 12 things. If you do these 12 things, good stuff will happen, signed, Kent Beck. If you do a subset I can't promise you what's happening. Maybe it will work, maybe it won't. But I'm not signing my name to it." So when someone says we're going to do XP, what they're getting is the Kent Beck certified bundling of "Hopefully good things will show up if we do these 12 things." And so when you get to Crystal, one of the reasons that I wouldn't get rid of the Crystal brand, is because it says: "I can sign my name to this package." And if you take this package I can pretty much promise you good stuff will happen if you stay inside the bounds. If you do it differently, could be, could be, but I don't know, that's your business. So in fact I'd even go further and say we need more brands and I would encourage people - and I know some, James Shore is coming up with some, we've got Joshua Kerievsky with Industrial XP, and what he said is there's a set of circumstances where vanilla XP isn't working. In this other area I'll create this other packaging and I'll sign my name at the bottom - signed Joshua Kerievsky, good stuff happens if you do this package in this arena. I think we need more of these not because there's brand wars, not because Joshua Kerievsky doesn't get a royalty if I do Industrial XP, but we need more packages where somebody will stand up and say in public: "I'm standing up for this collection of stuff." How about the gaming industry? We don't do Agile in the gaming industry very much. What would be an interesting package that makes sense in the gaming industry? Who would sign up? We need a gaming person that says "Done this in the gaming industry, here's a package of practices, signed 'my name'." And then it becomes a brand. But it's an attestation that's useful. So it's not just commercial wars, it's actually useful information. Are we doing XP, are we doing Crystal, are we doing Scrum? Has to do with, if our project fails did we somehow not read this packaging correctly, or is it flawed? It could be that it's flawed or it could be that we just didn't do it right. But that becomes now an interesting question, distinct from all the roll-your-own methodologies which are also fine.
Everybody asks "what the difference is between use cases and user stories?" It's a very good question and it turns out not to have a trivial answer. The trivial answer is that they are not the same. Some people believe a user story is just a small use case. Not true, they're fundamentally different beasts, and Gerard Meszaros wrote a paper at the XP conference two years ago, which as far as I'm concerned has solved the riddle of what's the mapping between use cases and user stories. He knows use cases, he knows user stories, he found the mapping and it's perfect. A user story is basically a one sentence thing that you write on a card and it's a marker for a conversation. It says the user wants to be able to do this. It's like an externally visible feature. One of the interesting characteristics is that if it's too fat, if it takes longer than an iteration to build, almost all user stories can be cut into two user stories. It's not very flattering but it's a valid description to say it's like a flatworm. So the characteristic of a flatworm is that you cut a flatworm in half, you get two flatworms, you let them grow a little bit, you cut them in half again and you get four flatworms and you can keep doing this. It's an interesting property of flatworms, it's an interesting property of user stories. You can take a user story and cut it and you have two user stories. There was one project I saw where a user story called "Select something on the screen" - it's a pretty small user story, not much story there, but it's still a user story - for perfectly valid reasons, they separated out "select text with the keyboard" as a story, from "select text with a mouse" as a story. It was valid, but it's weird. Those are not use cases, you can't pretend they are use cases, but it shows you how finely you can divide them and it's a nice property of user stories that as you shrink the iteration length you'll get smaller user stories and they stay consistent inside the language of user stories and the purpose and the planning work and all the rest of it. That's not at all the case with use cases. A use case is fundamentally a collection of scenarios of usage, some of which succeed and deliver the purpose of the thing and some of which fail and you abort. So you go to an ATM and you will or you won't get cash, or you go to Amazon and you will or you won't order the book - your credit card could be wrong, the line could be down, all kinds of stuff. So a use case is fundamentally different because it's got a shape. It's not like a flatworm - it looks like a horse. You can't cut a horse in half and get two horses. There's good news and bad news, because now if you're an Agile project and you're running one week iterations, how on earth do you manage your way - you're painting the horse, and you've got this short period of time - they are not at all the same. Typically the short answer is this: a user story is probably a sentence in a use case. This is not the correct answer, it's not the full answer but it gives you a hint of the nature and the difference between them. So horses have shapes, it's a horse or it's not a horse, you can't split them up. The next thing that Gerard did that was really excellent was that he found that some of the user stories aren't function requirements at all. You have a user story that improves the usability of the system. You might have a user story that says something about remapping the screens or changing the number of clicks or whatever it is. He found there's a bunch of user stories that just have to do with usability - they don't show up in use cases at all. There's a bunch of user stories that have to do with data structures, you have big fat data structures and you incrementally on different iterations pick up different elements of the data structure. Not in a use case at all. So we've got two categories of user stories that aren't in use cases at all. And then two categories of user stories that are in use cases and he calls the first one new functionality and that would be, for anybody who knows use cases, it's the thinnest possible path through the main success scenario. It might just be steps one, two, three and six, skipping four and five. But the functionality would be there, it would very, very skinny. And then, on the last categories, added functionality - or added business rule as he calls it - so then you would take step four as its own user story, you'd take extension 2a is its own user story, extension 2b, and you can split those up. He calls them story-o-types. You'd have to do a web search on Gerard Meszaros story-o-types published in the XP/Agile Universe 2004. There are four categories of user stories - two of which map to use cases, two of which don't. New functionality - skinny path through main success scenario; added business rule - that's another step in a use case; added data - not in a use case; and improved usability - not in a use case. So there's the long answer for the viewers so that they can see that it's not a trivial mapping. You can use use cases on Agile projects, it makes sense - not the 25-page version, the 2-page version - and you have to split them up into iterations and Gerard's paper kind of talks about how you can do that. That's the long answer to the question "What's the difference between use cases and user stories?"
10. I hear you're working on a book. Is it Advanced Techniques for Crystal?
I am doing a second edition of the Agile Software Development book to answer all the questions. I wrote that book in 2001 right after the Manifesto and basically everything that's happened in the Agile industry is different, is new material compared to what's in the book. That will be out in fall 2006. Instead of just adding 30 pages I have 130 pages because I picked a lot of topics that have been hot topics - software engineering, iteration length, methodology, all that stuff. But in fact, my current big project is a book of poetry. Anybody who goes to my website sees lots of poetry up there. My wife's an artist and she's doing the illustrations. So I'm going to take a little foray into self-publishing and produce a book on poetry. It will be called "Two Potatoes Groping in the Dark" because that's the title poem.
11. Will you give us a sample?
I'll give you this one: Two potatoes, groping in the dark Love one another in the warm, dry earth. Their neighbours all around Extend their eyes To spy - To no avail. A bump, a lump Of new potato grows To learn to spy, To love, To make potatoes. That's "Two Potatoes Groping in the Dark," the title poem.