As you may know Agile software development is inspired by the principles of Lean Manufacturing which in turn is derived from the Toyota Production System (TPS). One Agile methodology, Lean Software Development even borrows the name Lean to make the connection explicit. Since the principles in Lean and TPS have much in common with how Japanese always have approached manufacturing and that TPS supposedly permeates the whole of Toyota, it comes as a real surprise that Toyota uses a waterfall process for software development!

Crystal Clear is the smallest of a series of methodologies for software development, all created by Alistair Cockburn. It is smallest in the sense of the project size it addresses (up to eight developers) and in the number of things it prescribes. Other Methodologies, deriving their names from the colors of crystal, are increasingly heavier. They all share the same “DNA” though, which is “expressed” differently with increasing project size and criticality, the latter meaning the higher cost in terms of money or at the extreme human life.

The book in itself has an interesting setup where each chapter addresses an aspect of Crystal Clear in a different format, tone and style. The purpose of this setup is to appeal to a large audience where each reader can find at least one chapter that conveys the essence of Crystal Clear to her clearly. The most peculiar chapter is probably the one where an ignorant Alistair queries a fictive Crystal character over a series of letters about the inner workings of a successful software development team; thus mimicking a Socratic dialogue. I am not sure this stunt works in practice, but at least true to the intent some chapters work better for me than others… All chapters are, however, still written in an easy and personal prose.

In the first chapter Cockburn discusses methodologies in the context of the skill set of the practitioner – somebody who masters software development probably need not pay too close attention to the exact steps in any given methodology since she understands the deeper principles and is able to derive what actions are needed from the principles in any given context. True to this the book’s reading instructions call readers experienced in Agile development methods to read the last chapter first and then (after they stop smirking) go back to read certain key chapters. Knowing something about Scrum and XP this is exactly what I did, including the smirking part…

Chapter 9

Distilled (The Short Version)

At the end it is time to roll it all back up again: What is the core of Crystal Clear, and what puts the team farther into the safety zone? This chapter is very short.

Crystal Clear is a highly optimized way to use a small, co-located team, prioritizing for efficiency, habitability, and safety in delivering a satisfactory outcome. The brief description of Crystal Clear for level-3 practitioners is just this:

The lead designer and two to seven other developers
in a large room or adjacent rooms,
using information radiators such as whiteboards and flip charts,
having easy access to expert users,
distractions kept away,
deliver running, tested, usable code to the users
every month or two (quarterly at worst)
reflecting and adjusting their working conventions periodically.

The team members establish the safety properties below using the techniques they consider appropriate. The first three properties are required in Crystal Clear, the next four get the team further into the safety zone.

1.Frequent Delivery
2.Reflective Improvement
3.Osmotic Communication
4.Personal Safety
5.Focus
6.Easy Access to Expert Users
7.A Technical Environment with Automtaded Tests, Configuration Management, and Frequent Integration

All the other pages in this book only expand on this page.

The above is the entire chapter and it really does succeed in summarizing Crystal Clear.

Patterns

Crystal Clear does not require any particular techniques but Cockburn still mentions a number of patterns of particular importance or not often seen elsewhere (according to the author). The patterns are divided in Strategies and Techniques. I find the Exploratory 360˚, Early Victory, Blitz Planning, Process Miniature and Side-by-Side Programming the most novel and interesting. Others like Walking Skeleton (aka Tracer Bullet or Spanning Application), Incremental Rearchitecture, Information Radiators, Methodology Shaping, Reflection Workshop, Daily Stand-Up Meetings and Burn Charts are, at least to me, well known from other Methodologies such as Scrum and may be considered standard practice; i.e. they are good patterns but hardly novel or unique in Crystal. The two remaining techniques Delphi Planning Using Expert Rankings and Essential Interaction Design are a bit too involved to my taste but may serve their purpose in some circumstances.

Exploratory 360˚
Simply put the Exploratory 360˚ strategy means that the project team should perform a gap analysis on all that is required to run a project successfully. In particular it also means to cover topics that really are the responsibility of others outside the development team, like the fact that there is proper funding and that the proposed project really has a clear recipient who wants the project to succeed. Cockburn supplies a list of the most common things to check for but there may be additional things particular to the organization or the project’s circumstances. If the gaps revealed are too wide or many the project can (and probably should) be terminated early and if nobody else have brought this to management’s attention it is the responsibility of the development team.
The Exploratory 360˚ strategy is something that is close to being self evident but I would guess often forgotten when starting a new project.

Early Victory
Many projects start out with the most difficult tasks first in order to minimize the risks. While this may be sound in theory, giving the team members an easy task to start with will boost morale when the team succeeds in it as well as show the sponsor(s) that the team is performant. Addressing the most difficult task first and then failing can be catastrophic for the team’s spirits and very late first delivery may erode the team’s credibility.
While I have given team’s easier tasks to start with in order to get things going I have never thought of it in terms of an Early Victory and as a reason to celebrate.

Blitz Planning
The Blitz Planning technique is similar to XP’s planning game or Scrum’s Sprint Planning but Blitz Planning uses index cards in a new, creative way. The project sponsor, developers and end users gather together and brainstorm on all the tasks that need to be done to deliver the system. Cards are collated and duplicates removed. The developer most likely to perform a task should make estimate on how long it will take to perform it. The tasks are then arranged in sequence on a large table parallel tasks are placed side-by-side and sequential tasks top to bottom. The sequence is divided in iterations and releases and cards are moved around to optimize development, to fit the sponsor’s priorities, make an Early Victory or a Walking Skeleton and so on. The planning may very well reveal the need for additional resources, change in scope etc. The outcome of the Blitz planning is a draft project plan.
What I like with the Blitz Planning is the simple and cooperative fashion in which the project plan is derived. Using index cards on a table makes changes easy and the result is very graphical.

Process Miniature
In order to learn a lengthy and/or complicated process a miniature version of the process may be run in a few minutes to a few days depending on the process being learned. If it is a development process, only trivial functionality may be developed or what is being built may simply be faked. Using Process Miniature is a variation of learning by doing but where the learning is substantially accelerated.

Side-by-Side Programming
In Pair Programming is a controversial technique in Extreme Programming. Some people find Pair Programming wasteful though proponents of XP claims it saves time in the end due to the lesser number of defects found in the final product. While this may be true some people simply do not like to program in pairs. An alternative to Pair Programming is Side-by-Side Programming where two developers sitting side-by-side with workstation of their own, helping out and reviewing code continuously. A similar effect as with Pair Programming is achieved but possibly with less wasted time.

Summary

What is interesting about the Crystal series of Methodologies (Clear, Yellow, Orange, Red) for software development is that they are founded on Alistair Cockburn’s interviews of people in successful software development projects, often in a fixed price, fixed scope contract situation. Agile methods are adaptive and often at their best in an explorative situation where the neither the scope nor the resources required are known beforehand. Thus Agile Methodologies are difficult to handle with a fixed price and scope. This begs the question as exactly what makes Crystal different. After reading the Crystal Clear I am still not clear on exactly why it should work better in fixed price and scope situation – the only reason seems to be developer participation in making estimates and a focus on always producing a workable system. And this is something that Crystal shares with all Agile methods.
Crystal Clear is probably the lightest of the Agile Methodologies I have come in contact with so far (mostly Scrum and XP) and this makes it true to its intent – it really is the minimum set of rules that could possibly work.

Since Clear only is applicable for projects up to eight developers due to its requirement of Osmotic Communication and many projects are substantially larger, it would be interesting to see how the ‘genetic code’ is adapted to fit larger projects. I guess I must read Cockburn’s other books as well…