Crystallizing the Software Development Process: A Chat with Alistair Cockburn
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
After spending his time in the 1990s researching and defining the object-oriented methods at IBM, Alistair Cockburn went on to write five books and co-author the Agile Manifesto, arguably the most influential document in software development of its decade.
Prominent in everything from the adoption of CRC cards to Use Cases to his “Crystal” family of methodologies, Cockburn went on to complete his Ph.D. in methodology and is a keynote speaker at this year’s Agile conference in Chicago, Illinois. Matt Heusser caught up with Alistair before the conference to ask him a few questions about his background, his present projects, and Agile’s future.
Though he’s been working in technology since 1974, Dr. Cockburn did not start out in software development – at least per se. “Actually, my degree was in computer engineering, and that was split between both hardware and software” he says. “When I first started my career, I did hardware design with associated coding - but that one was one person in isolation. At IBM we did some software, network topologies and things, but I didn’t do any formally study of what you would call ‘methodology’ until I was assigned to do in the early 1990s.” Cockburn’s first work at IBM at teaching Smalltalk and C++ using CRC cards (a design technique for object-oriented programming) was the first deliberate method of object design.
When asked about his role in defining IBM’s methodology, Cockburn laughs. “Well, it was my job assignment. IBM had a need and assigned me. I read the books and they were all different, so my boss told me to interview teams, see what they are actually doing. It turns out field research in software methods is surprisingly rare. Then I just wrote down what teams are doing.” Alistair says that his family of methods – Crystal – is more a collection of what teams were doing in the field instead of a prescriptive process.
He is quick to point out that the “I invented it, and it worked for me” approach to method is fraught with problems. Crystal is not just what everyone had in common, Cockburn says. Instead, it provides guideposts, reminders and a moderate amount of leeway. “When people say they are using Crystal, I often ask ‘How do you know?’ because it’s so undefined,” Cockburn says. His concern at that point is that it is easy to do three-quarters of Crystal and miss the guideposts. “Beyond the process, you need to pay attention to the quality of listening and the quality of communication. Do they reflect and improve? Where Scrum is a process, Crystal is really about what people can accomplish by collaborating.”
In fact, communication, listening, and improving are what Dr. Cockburn focuses on in his consulting work. “I call myself a project witchdoctor, because what I do is so hard to explain. I come into a team or project, work with them, and when I leave, things are... better.” According to Cockburn, many organizational performance issues are not based on defined processes or tooling, but are instead cultural and personal.
After creating Crystal, Cockburn attended the 2001 conference in Snowbird, Utah, that gave birth to the Agile manifesto. He calls that peer conference “the best-run work session I’ve ever been in, period full stop. [It was] fourteen competing type-A personalities who listened intently to each other for two days. We met, traded notes, aligned on purpose, and wrote the manifesto by 3:00 pm on the first day. Everybody honored everybody else, listened, contributed. There was no fighting, no grand standing; it was astonishing. A wonderful exercise in self-organization, there were no bosses, just peers.” He was impressed by the lack of ego, turf wars, and hierarchy.
As the conversation wound down, I mentioned the Agile testing discussion list, and the increasingly popular question, “Must an organization use test-driven development [TDD] or automated tests to call itself Agile?” Alistair replies, “No, absolutely not. When I was writing Crystal, and even since, I’ve been on too many projects that succeeded without automated tests. Automated tests are good – they are very good – they are wonderful – but mandatory? I don’t think so.” Test driven development done well is incredibly difficult, he says, which is something not often discussed in the Agile literature.
The past few years have been banner years for the Agile movement. While the concept started with small teams, it has since grown to be adopted by the Project Management Institute, Carnegie-Mellon’s Software Engineering Institute, and huge employers such as IBM and the Department of Defense. Dr. Cockburn’s keynote address at Agile 2009 will cover this newer, large, competitive landscape for Agile Software Development – and what Agile may come to mean in the next few years.