Note: Part 1 is here.
Alistair Cockburn is a signatory of the Agile Manifesto, an author of multiple Agile book titles, a keynote speaker at numerous Agile conferences, and most recently, the spokesperson for ICAgile.org, a credentialing body offering several levels of Agile certification. This is a multi-part interview that covers a wide range of topics in the Agile space.
Alistair, tell us where Crystal Clear is. I hear you are publishing a new release of the framework.
"Crystal" is really just a handle for "all the stuff Alistair knows about software development" (leaving out project management strategies and design idioms, which I package and publish in other places). Crystal "Clear" is a subset of Crystal, addressing the 2-10 person project. The other colors address larger projects ("Yellow" for 10-25 people, "Orange" for 25-50 people, and so on).
The term "Crystal" was useful in the late 1990s to help people see that different sorts and sizes of project needed different strategies and operating conventions (what we tend to lump as "methodologies"). The color was to trigger the thought of different colors of crystals: clear for quartz, yellow-orange for topaz, red for ruby, blue for sappire, and so on. The "hardness" was to trigger the idea of life-criticality, matching the mineral hardness scale, with quartz being soft, around 1, for low-danger projects, and diamond being hard, at 10, for life-critical systems. With this system, we could differentiate between two people working on a corporate-internal food-ordering system (quartz) and two people working on a nuclear reactor system (diamond).
It seems to me that both the two-dimensional crystal metaphor and the attachment of these ideas to software development has run its course.
Anyone who has worked with Crystal for a bit notices that the ideas in Crystal are scarcely tied to software – they apply to projects of all sorts, to non-project work, even to job-hunting, school-work for kids, and much more. What I'm trying to do now is to release Crystal from it's binding to software.
Someone wrote to me the prescient phrase, "I like the ideas in Crystal". Not that he liked Crystal, or the name "Crystal", or the binding to software, just the ideas inside it. He wants to apply those ideas to the world, to his work, to his life, in general.
So imagine, if you will, that we burned off the name "Crystal" and it's attachment to software – what then do we have?
What we get is the Crystal 3-step model , showing the interplay of Practices, Theory (or Principles, or Laws, as you prefer), and Self-Awareness. And we get the Oath of Non-Allegiance .
In the 3-step model, we see that Practices (which includes the Shu – Ha – Ris progression so many people are now familiar with) run into a limitation when applied without theory or self-awareness. The Theory portion is what directs us to understand the underlying forces we are dealing with when working with other people on design problems (or working on design problems by ourselves; or even just working with other people – leave design out of it!). The Self-Awareness portion is what directs us to pay attention to our own personalities, our priorities, our values, and what is happening to us as we go. It's what allows us to tune the practices to ourselves and to optimize to our current situation.
As you can see, this model is much more applicable than merely software. What really gives it an identity, though, is pairing those three steps with the Oath of Non-Allegiance. Core to the entire notion of Crystal (or whatever name it develops in the future) is the belief that good ideas come from everywhere, that diversity is a power to be harnessed, not something merely to be tolerated.
The Oath of Non-Allegiance gives the consumer or client a buyer's protection program: "Here," says the consultant or advisor, "Here is my promise not to withhold from you any neat ideas just because I don't like the person who created or publicized them. Your problem takes top priority, not my affiliation with some group."
Personally, I think this program is a lot harder to step into than most people imagine. I see people signing the Oath of Non-Allegiance, and nodding their heads at the 3-step model, but when I put them in front of a situation in my new "Advanced Agile" classes, they quickly back off or give up. The new Crystal-thing is clearly not for weaklings :).
There is much to develop with this model. I am looking for people to partner with to develop this and free it from software development (it needs, just for starters, a better name and description.)
How does Crystal Clear play in the ICAgile structure?
I think of them as separate topics. Crystal Clear is my nickname for a set of properties and behaviors that increase the odds of successful delivery by a small, colocated development team: frequent delivery, reflective improvement, osmotic communication, and so on. At its most commercial, it might morph into a consulting organization, which will consult to businesses in any field looking to improve their effectiveness in team & design work.
ICAgile is a bookkeeping and accounting agency for training courses in the agile development space. It will first help map out the learning objectives suited to each specialty involved, then keep track of the courses taken by individuals as they grow through the learning objectives.
Each of those topics has a separate value to the industry. The International Consortium for Agile will probably help the industry more, since it is working to sew together groups that have been disparate and even divergent over the last decade: agile, the Project Management Institute, the International Institute for Business Analysis, the International Software Testing Quality Board, the various national agile and certification bodies, and so on. What excites me about ICAgile is this possibility, of not just bridging, but of getting collaboration and cross-recognition between those groups. If we're lucky enough to do that, that will be a big step forward.
If the next version of Crystal – the commercial version, for example – takes off, I will try to focus on the deeper issues, developing cross-team coherence, communication, community, and decision-making as cultural habits in organizations. Simple teaching won't accomplish this, nor will bookkeeping the courses people take, nor will getting recognition across certification and training organizations. This is a smaller and narrower, but deeper quest than the ICAgile quest.
You are known as a thought leader and iconoclast. What do you think are the most interesting problems or concepts to focus on now in the Agile space? Why?
Our industry has improved substantially in the last 10-15 years. The quality of discussion, the quality of practice, the quality of awareness have all improved in companies and at conferences. I was particularly struck by the high quality of the sessions and discussions at Agile 2010 last month. The topics that really strained our understanding back in 1991-1995 have largely been resolved: We understand how to do incremental development, iterative development and risk-driven development; We understand communication, delivery, feedback, automated testing, craftsmanship, integration, delivery, even distributed development, and a bit of large-scale distributed development. We have some fairly solid theories behind software development as a practice, theories that tell us how to adjust what's happening within a project to increase its chance of success.
There are still people stuck behind, but that will always be the case. To me, the term Agile has nearly served it's purpose. It served to catalyze the industry to pay attention to people in the design process, and to fine-grained, end-to-end feedback (typically accomplished through shorter iterations).
The utility of the term "agile" is not yet done, because people still too quickly drift into process religions or mathematical dreamland and forget that our industry is built on people getting together, inventing and deciding as they go. I repeat yet and yet again: people, human people, with all their weird characteristics. Math and process are relevant, but soooo much easier than dealing with the actual people in front of us.
This leaves three topics wide open:
- All the theory in the world does not guarantee that people will work well together. Individual people have strange effects on each other – either increasing trust or trigger unexpected angry outbursts. The topic here is to learn to observe individual people in action, and see what can be extracted and encoded as advice for others to use, and what must be left as personal abilities of individual people.
- Decision making as a new topic of investigation (I am grateful to David Anderson for bringing this to my attention after one of my talks on the cooperative game – He opened up a whole new field of inquiry with this observation). We still make decisions unconsciously in our teams and organizations, we don't discuss how we come to decisions, and we don't discuss alternative ways to make decisions. We do – now, 15 years after I first became aware of it – deliberately discuss our techniques for invention, our communications, our "community", but we don't yet discuss decision-making. I think this will be an interesting field of inquiry and development over the next 20 years.
- Continuing to develop a respect for the fact that design is made by people, which aside, from the weird interpersonal chemistry already mentioned, involves the quality of community and workplace. It is all too easy for any manager to lean on a process to improve output, rather than to develop his or her personal skill in knitting together the people across departments. I don’t think we'll ever stop needing to remind managers of this.
Article Note:
This is Part 2 of the Alistair Cockburn interview. Watch for the closing segment of this interview, where Alistair discusses some of the more controversial topics facing the Agile community.
Note: Part 1 is here
