An Interview with Alistair Cockburn (circa 2001)
An Interview with Alistair Cockburn (circa 2001)
Join the DZone community and get the full member experience.Join For Free
Alistair Cockburn 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.”
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.
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: 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 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: 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: 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: 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
Published at DZone with permission of Jim Highsmith , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.