I’m sure you know how the Agile Manifesto came into existence. 17 men met in a ski resort in 2001 and, although they had different approaches to software development, they all shared certain beliefs. They formed the Manifesto that comprises four core values and 12 principles.
But did you know that one of the most represented approaches amongst them was called Crystal?
In the early 1990s, Alistair Cockburn worked at IBM and was tasked with building a methodology for object-oriented development. He interviewed successful teams and found that, although they weren’t following a formal methodology, they shared some common ways of working. From this research, he constructed a family of methodologies, along with principles for tuning them. He called this family of methodologies Crystal. He explains that this is not a kit of methodology parts for you to implement from scratch; it’s a “set of samples that you adjust to your circumstances”. In other words, this isn’t an out-of-the-box approach that you can simply implement; you use it to review your current approach and adjust.
All of the approaches within the Crystal family of methodologies are centred around people and communications, but the approaches vary according to three dimensions: team size, criticality, what the priority of the project is. The basic premise is that the more people you have in the team, the more critical the project and the more regimented the project type is, the more structured and rigid the approach needs to be. Cockburn therefore named his different approaches after geological crystals, with harder stones such as diamonds representing the more structured approaches. Conversely, the most fluid approach was named Crystal Clear.
Whilst Crystal Diamond might suit projects that have a team size of 500+, could result in loss of life or the collapse of your corporation from litigation; Crystal Clear would be recommended for teams of 1-6 people and at worst will cost the company a bit of non-essential money, with an aim of improving productivity.
Although you might start out using one approach, you should adjust it as team size, risk or project priorities change.
The 7 properties of Crystal
Although there are whole books and training courses explaining the details of Crystal, I found one area particularly interesting: the 7 principles of Crystal. The first 3 properties are compulsory for all of the Crystal family’s approaches; but only the first 3 are compulsory for Crystal Clear – with the others being optional (but advisable?). In short, they are:
(1) Frequent Delivery
The most important property in every project is to frequently deliver working, tested code to real users. If you don’t do this, then you risk finding out too late that you have produced a product that nobody needs.
(2) Reflective Improvement
However bad it is right now, there is hope. And however good a team thinks it is, it can always improve. Teams should work together to find out how they can improve their future working practices.
(3) Osmotic Communication
Osmosis is a way of learning that is passive and subtle – a gradual absorption of information. Cockburn believes that by being co-located, information flows around team members so they pick up valuable and relevant information even when not actively involved. He believes that, with this, projects can operate with very little structure. However, he does acknowledge that sometimes people need a bit of space and suggests co-located teams also have a private area that people can go.
(4) Personal Safety
Every member of the team should be able to speak without fear of ridicule or reprisal, whether it be a new idea, a concern or a problem they are encountering. The key tenet to this is trust. If we trust people, then we are more open and will share information more freely. This kind of environment enables teams to work through their problems and improve performance. As Lencioni’s 5 Dysfunctions of a Team tells us, politeness is not the same as safety/trust: showing disagreement is healthy when done in the correct way.
Knowing what to work on and being able to get on and do it. This suggests clear communication, prioritisation of requirements, goal setting, etc. It also means reducing context switching.
(6) Easy Access to Expert Users
In short, getting feedback from real users. He doesn’t state how frequently or for how long.
(7) Technical Environment with Automated Tests, Configuration Management & Frequent Integration
These are very specific tools for software teams which are still not common place across all teams. Even in the 90s he was talking about continuous integration so that errors could be caught within minutes.
Haven’t I heard something like that before?
Exactly! When I first read these, I was struck by how many of Crystal’s 7 properties mapped to the Agile Manifesto. I shouldn’t have been as Crystal was clearly a large part to the writing of the Manifesto.
Frequent delivery (property 1) and “Working software over comprehensive documentation”. Reflective improvement (property 2) and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”. Although the Manifesto doesn’t talk about osmotic communication or stick its neck out to push for automated tests, etc, its clear that Cockburn had a major influence on its writing.
So why don’t more people (in the UK) know about Crystal Clear?
Is it because other approaches have done an amazing job on marketing: selling courses that certify people after a short course? Is it because other methods such as Scrum are more prescriptive? Is it too similar to the Agile Manifesto that people don’t think they need both? Is it because Scrum is easier to implement?
Maybe it is partly to do with each of those. But, as Cockburn himself highlighted to me, Crystal is specified at the ha/ri level, not the shu. People who are doing good work can use Crystal to “remind themselves how to stay centred”. So it requires people to be quite experienced in software development before they pick up Crystal. But, anyone capable of following Crystal probably doesn’t want to follow someone else’s methodology because they are at (or near) the Shu level and writing their own rules. As Cockburn put it, “It’s kind of a catch-22 designed to avoid followers. Evidently I’m no good at business models.”
Luckily for us, Cockburn clearly isn’t driven by a desire to maximise income over providing ideas. I’ve barely scratched the surface on his ideas, and would urge you to read about Crystal and his other ideas. I’ve included a list below with some guided links. This isn’t the last you’ve heard of Crystal Clear on this site …