Alistair Cockburn^[1] introduces himself as a ethno-methodologist, someone who studies the ethnology (cultures) of software methodologies. He is also a cultural relativist, having lived for 15 years in a diverse set of countries—Sri Lanka, Bangladesh, Sweden, Scotland, Switzerland, and Norway. His work travels have taken him to other exotic destinations, including, for example, lengthy stints in South Africa and Utah. As a kid, he returned from many years of living overseas (his father worked for the United Nations) to live in Cincinnati, Ohio. “Talk about culture shock,” he said. “You can pretty well imagine I was beaten up for being different. I was about as different as you can get from the norm in the Midwest—speech, clothes, vocabulary, hairstyle, attitudes.”

Alistair makes the point that most cultures work. Even though one country's or one organization's culture may seem foreign, they all have the capacity to get the job done. Not understanding the cultural aspect of methodology, process, and practice implementation leads to failure: India isn't the same as France, New Zealand isn't the same as Japan, Nokia isn't the same as General Electric, and British Telecom isn't the same as Microsoft. Every country is different, every company is different, every company location is different, every project is different.

Although Alistair and I had shared ideas back and forth for a couple of years, the genesis of our collaboration on methodology occurred while traveling up the Germania lift at the Alta ski area in Utah. We found our ideas about methodology, people, and software development compatible. His comment about our two approaches to software development is one of my favorites:

Alistair has written three books: Writing Effective Use Cases (2001), Surviving Object-Oriented Projects (1998), and Agile Software Development (2002). Alistair's Crystal Methods are actually an array of “methodologies” targeted at specific project size, criticality, and objective domains. His work is usually mentioned in any listing of Agile methodologies.

JIM: How did Crystal Methods evolve to where it is today?

ALISTAIR: The story started in 1991 when I was at IBM Zurich Research Laboratory and was looking for a job in the States. The IBM Consulting Group was just getting started, and the people there wanted advice for their consultants worldwide about OO development. They had an information engineering–based methodology, had figured out that objects were not insignificant, and then hired me to write the OO portion of their methodology. They were already using incremental development, risk analysis, and other core techniques—they had some pretty smart people—but nobody knew what an OO methodology was. One nice thing they did got me in the habit of what I do now. They had no vested interest in a particular solution—any answer would be OK, as long as it worked.

I got the books on the subject—about five at the time—and decided I couldn't discern the answers from the books. We decided that I would debrief projects inside and outside IBM to get the answers. What I found very quickly on these projects was that what the people on the projects did had no relationship to what was going on in the books. I became a strong cultural relativist in the process. In the end, of course, I flunked my assignment. That job was to produce a set of policies and documents that could be used by all consultants worldwide, and I couldn't do it. I still can't.

JIM: What happened after IBM?

ALISTAIR: In 1997, when I was working at the Central Bank of Norway, the company had several kinds of projects: 35-person, Y2K, COBOL; 2-person Java/CORBA stuff; 1-person SQL information retrieval. I would just sit there in my chair and conjure up a theory, look around at the variety of projects, and realize that the theory wouldn't work—it wouldn't cover every project. Before I got there, I already knew that one size didn't fit all, that everything is different, but I had an amazingly difficult time convincing them of that. But just taking a look around that one organization pretty much anchored, irrevocably for me, the fact that there cannot be one answer.

JIM: If every methodology is a one-off methodology, is it a methodology?

ALISTAIR: That's the dilemma. The question for me now as a methodologist who studies these things is that what I produce I almost hesitate to call a methodology because I don't think it can be used more than once. What I am finding is that certain skills are transferable across projects. However, most policies^[2] are not.

JIM: What have you learned about how to study methodologies?

ALISTAIR: As I interviewed project after project, I created a list of what people thought was important and what was not. I used to ask leading questions like, “What techniques would you use?” I would get responses like, “We would use responsibility-based design or incremental development or use cases.” What I wasn't attuned to at the time was the fact that they didn't actually do these things. I was using leading questions, and they were obliging me. In a sense, if I look at my history, I find immense numbers of filters, blinders, and preconceptions loaded into my interviewing techniques. The last ten years has been a process of detecting those and removing them one at a time.

So, after a couple years of methodology investigation, I finally got an opportunity to try out my ideas on a real project. I took the lightest, most effective ways of working I'd come across—use cases, responsibility-driven design, and increments—and taught people how to do it. Much to my chagrin, they didn't do it! We had a successful project, the software was delivered, and we wrote something like use cases and did a little incremental development, but except in rare instances, the team didn't do responsibility-driven design.

That's when I detected that what goes on in a project is more complex than I could write down. People don't follow instructions. They do, somehow in their heads, solve problems, and they don't necessarily use even the simplest formal technique. That was one of my first crises: Whenever I go in with a prescriptive recommendation, teach people to work this way, basically they don't. They work, however they work, inside their own heads, and a few people will pick up a few bits of a few of the techniques. So I now accept that as a part of life.

Bottom line of my research: Put four to seven people who exhibit good citizenship [behavior toward each other] in a room, and you will get software out. Playing well together is the bottom line.

JIM: Can you give me a couple of examples of successful projects?

ALISTAIR: The first one: 45-person, fixed-time, fixed-price, consulting house work with an IT department, client-server project, GUI, Smalltalk. I did this one by raw instinct. We created functionality teams in which business experts were in close contact with two to three programmers. A business expert (an IT staff member with significant business experience) would sit with users, get requirements, do use cases, and then, by word of mouth, transmit the information to the programmers. The requirements basically grew and lived in the personal memories of the requirements gatherer. So notes on the use cases that a person chose to take and the evolving code base of the programmers made up the requirements documentation, but we made this work because two to three times per day there was a conversation between these people. We were also absolutely hooked on increments.

I wrote this methodology up in my Surviving Object-Oriented Projects book, defined its domain as internal IT with 40 people, and called it Crystal Orange. The point is that we dropped the written deliverables, the written documentation, to next to zero. This is the kind of thing that puts me in the “light” methodology camp.

We also had excellent executive support, the latest equipment, and good training, and the executives had already experimented with iterative development and weren't scared by that. Our users were directly involved, we had good designer-programmers, and we had a good collaborative environment and short, rich communications paths. We had all those things that make a project successful as I now define it.

The second project was at the Central Bank of Norway in the 1997–98 time frame. It was a COBOL, mainframe project. I'm sitting there minding my own business, and this person comes in and says, “Alistair, would you please be the technical coordinator of this project: COBOL, VSAM, assembler, LU6.2, nationwide banking project.” I looked at this person and said, “Excuse me, I must have this wrong: I don't know anything about COBOL, I don't know anything about banking, I don't speak Norwegian, and I don't know any of the people. Am I on Candid Camera? Is this a trick question?”

But they persisted, so I asked about how long and how many people and was told three people and 15 work-weeks. The three people had just finished a similar project and deployed it, so they assured me the new project would be pretty easy. I said, “Wait, we're talking five weeks elapsed time. You don't need a technical coordinator. Just do it and go home!” But they insisted, and I said OK. The first thing I figured out was a technique for assessing risk. I got each of the three programmers in a room and brainstormed all the considerations I could think up that they might encounter, and whether they had dealt with them before. With each one, what I watched for was whether his body language matched his answers. If he said it was easy and they'd done it before, I figured it must be so. I was looking for when he didn't seem sure about something. If it was something he hadn't done before but thought they had ideas about how to do, that went on my risk list.

Anyway, as you might guess, the project ended up being a 14-month project. It got bigger, became a split-site project, and when it got tough, I stepped up the personal interaction—conference calls, emails, visits—I did not step up bureaucracy. In the end, the project was considered a success since it did what it was supposed to, our eventual project plan stayed stable over the last eight months of the project, and there were no problems in bringing the system live.

JIM: You talk about skills and policies on projects.

ALISTAIR: Skills go in one dimension, and policies go in another. Project policies—notations, standards, increment length, milestone length—are specific to a project and don't transfer. Skills, however, do transfer—how to code, how to do test-first development, how to do user interface (UI) design. However, some skills aren't learnable or teachable. Project managers need interviewing, communicating, decision-making, creating skills—those aren't skills I'm going to teach someone. I can give them some techniques to get them out of the woods, but they'd better show up with that other stuff.

JIM: Are you saying that the so-called “soft” skills aren't learnable?

ALISTAIR: Ah, I'm saying that you can add techniques to the soft skills, but the person has to be talented in that area to start. When I look at programming and design, we can teach CRC cards or test-first programming, but have to have an ability for abstract thought—I can't teach that. Just as you can teach paper-based prototyping to UI designers, but you can't teach color sensitivity.

My proudest thing on the banking project, besides the risk management, was working with a new project manager from the user department, who knew nothing about project management or software. I coached her in how to read the body language of the participants in our weekly videoconference. The programmers would mumble to each other, and what she and I had to do was to determine where to insert a question to get clarification on the problems.

At the end of three months, she was better at it than I was. She could understand the tone of the discussion even when she didn't understand the technical language. That, for me, was a successful moment in conveying a large part of what project management is about, and she couldn't have learned it if she didn't already have a talent for watching and listening.

JIM: You have lived and worked in many countries and seen multiple national and project cultures at work. What have you taken away from these experiences?

ALISTAIR: First, all these cultures work; they all have different rules. It's not that a particular culture is wrong and needs to be fixed. So actually, now I'm a severe cultural relativist in the sense that I go from project to project and assume that the organization is working or it wouldn't be in business. I always start by saying, “You guys are doing something right.”

JIM: In the knowledge management field, there has been a lot of discussion about tacit knowledge and knowledge transfer. How do you think people learn new things?

ALISTAIR: We're talking about the motivation for the person who picks up a book or takes a course, or whatever. You cannot predict for any given person what they will pick out. In this searching and picking, there is something special about stories. Stories give a trajectory for actions. Not just a single action, not if-then-else rules, but they tell what different people did over time, and human beings digest that very well.

This project that you are working on now—developing stories of projects [for this book]—is to me simply perfect. Because if you want to influence somebody's mind, a strong way is to tell them a story. You may not guess exactly what they will take out of it, but they will be able to follow the trajectory, they will do an abstraction, learn their own lessons, and then, if you give a digest of what you learned from the story versus what they saw, that has some likelihood of impacting their thinking.

JIM: So if stories are important, why continue to teach courses on subjects like use cases?

ALISTAIR: My current theory is to teach techniques, in workshops, schools, on the job, whatever, and that those skills go into people's personal kit bags, which they then use for however many seconds at a time. They internally flip from technique to technique to help solve problems. The focus of a technique is to put something in their kit bag, and that is transferable across projects. The other thing a course does, particularly if a group takes it together, is align their vocabulary.

JIM: So what is a methodology?

ALISTAIR: To me, a methodology is the set of communications and coordination policies used on a project. So what a person does is not a methodology to me. How three to n people coordinate their activities is methodology. Things like doing increments, milestone-based planning, specifying use case templates, using Microsoft Project—whatever the team agrees upon at a cross-team level are the parts I want to influence.

JIM: So policies are boundaries. Whereas traditional methodologies specify activities and documents, your approach is to have a few policies that organize the communications and coordination and then depend on individuals to use their “kit bag” of skills as they and the team deem appropriate.

ALISTAIR: Once people show up on a project, you don't tell them how to write Java. What you need to tell them is who they need to talk to and how their code is to be accepted and what meetings they have to attend. The techniques go into an educational curriculum that you set up for your corporation, which says we want people to have certain skills.

JIM: You wrote a paper about software development as a cooperative game of invention and communication (Cockburn 2000). How did you arrive at that analogy?

ALISTAIR: Mostly to get rid of this aberration called software engineering. Actually, the cooperative game idea describes large sections of normal engineering activities. The other parts of engineering involve looking up previous solutions in standards books. But engineering has given us a faulty vocabulary, a vocabulary that leads us in a direction that's not fruitful to a software project. It gives us questions like “Is the model accurate and complete?” Much more interesting are “Do we have our goals aligned as a team?” “Do we have a correct set of skills?” “Is our product meeting the customer's needs?” and “What is the next move in this game, given that our competitor has just announced a new product?”

JIM: To me, software development is mind work more than anything else I can think of, maybe with the exception of writing.

ALISTAIR: There is nothing but the idea. I did the thought experiment. Let's say you had a group of people who were hired to write a 20,000-word epic poem for John D. Rockefeller—what would it look like to coordinate this effort? I wrote a story about the person, the poet, who takes this on, gets swamped, recruits four friends to help. They get swamped and hire several more friends. What would happen? What would this project look like? The poet is pulling her hair out trying to coordinate things and eventually hires a manager and buys tools. Then subgroups form—you get some people who are good at descriptive passages, some who are good at fight scenes, some who are good at describing personalities, and then you get a splinter group that goes off and then comes back again. I wrote this up and showed it to a guy at Novell who works on operating systems. He loved the article and took it home to his wife and said, “That's what my life is like at work!”

So software development is a cooperative game of invention and communication. All we do is to invent and then communicate our invention. If we hold that thought and want to make it work, then what we want to do on a project is ask, “How do we enhance people's invention actions?” and “How do we enhance their communications?”

The reason I like this definition of a cooperative game of invention and communication is that it does lead us to issues that I find do show up on project after project and didn't have a home in the process-oriented, software engineering vocabulary.

JIM: What passion drives your work?

ALISTAIR: For me, it's understanding the human mind. Even when I designed hardware, I've always had an interest in the interface between the human mind and technology.

There is nothing that happens to me, anywhere, at any time during the day, that I can't apply to a project. I will read a book or have a work experience and move things around on a project as a result. It gives me a chance to see how things work. Programmers are my clientele or my study group. It is a subculture that I used to belong to—I'm still affiliated with it—and one I care for. You can keep everybody else around on a project and send the programmers home, and you won't come up with a system. They are really the heart and soul of the story. So I really like to study them.