Crystal Clear: A Human-Powered Methodology for Small Teams

Alistair Cockburn (2004)
Review date: February 2012, (read August 2011)
Summary

For once, a first chapter deviates from the standard "an introduction to...". The first chapter is written around a fictitious conversation between the author and Crystal - the method. The author asks a series of questions that the method answers in order to tell him what it's all about.

Chapter two is about the seven properties of Crystal Clear. Readers familiar with Scrum, and especially XP will find very familiar ground, although some things will have different names and some will be more emphasized:

  1. Frequent delivery
  2. Reflective improvement
  3. Osmotic communication
  4. Personal safety
  5. Focus
  6. Easy access to expert users
  7. Technical environment with automated tests, configuration management, and frequent integration

The next chapter is about strategies and techniques. Five strategies and nine techniques are described. Again, readers that know Scrum and XP may start finding new concepts here. The strategies are:

  1. Exploratory 360°
  2. Early victory
  3. Walking Skeleton
  4. Incremental Reachitecture
  5. Information Radiators

Chapter four is about the process. Here the various time horizons are described; the development episode, the iteration, the delivery period, and the full project, and what happens therein. The next chapter is about work products; artifacts created during the lifecycle of a software project.

Chapters six and seven are about common mistakes and answers to supposedly common questions like "What about CMM(I)". Finally, chapter eight is about a case study.

Opinion

I reviewed this book half a year after reading it, and I seem to have lost my notes. Therefore this review might miss in accuracy. I probably have to start by saying that this book was kind of difficult. I read it while preparing for a course in "Advanced Agile" given by the author, and not until I met him could I make sense out of parts of it.

Let's take the first chapter where Crystal Clear is defined. It's not a very long chapter, but a lot of things are going on. For instance, we have a reference to learning and competence levels (shu, ha, ri), which are treated at length in the author's other book, "Agile Software Development". There are references to XP and Scrum (and comparisons), and at the end the chapter doesn't really give you a definition of what Crystal Clear is. Instead it gives you three lists. If the items on the first list are satisfied, you're doing Crystal Clear. If practices on the second lists are followed, you might be doing it. If the third list best describes your work, you're not doing it. The crux is that the lists contain pretty much all the not so easy master agile practices, and many not so easy to solve barriers to agile. That's why this is a hard chapter.

The second chapter is easier to digest. It describes properties that the best Crystal teams set up. In contrast, the next chapter describes strategies and practices. Now, I know that these words are explained at length in some books, but I always forget which is which.

Anyway, the properties are fairly uncontroversial. I believe they pretty much map to what you found in XP. On the other hand, I found chapter three to contain some new things. For example, the Exploratory 360° strategy is pretty much what you would call the Inception phase in RUP. It's about looking at the various dimensions of the project and making sure that it will not fail prematurely. The author suggests examining business value, requirements, domain model, technology plans, project plan, team makeup, and methodology/working conventions. This is not controversial, but many agilists and books one agile methodologies seem to shy away from this. I'll always like a passage in an agile text that acknowledges this dirty up front work that's so very crucial, and doesn't fit in a sprint or iteration, since it's not a development activity.

I seldom write this, but discussing the details of the nine techniques, described in the book (inchapter 3), would require more text than is suitable for a review. I really encourage everybody to read the roughly 50 pages that are devoted to the techniques. As a whole, I can say that these pages are very information-dense. Of all the things that could be picked out from this enormous pile of information, I choose to emphasize side-by-side programming, a more humane candidate to pair programming.

I liked the chapter on work products. While one could argue back and forth about whether to include a given work product in your particular delivery, it's a fact that artifacts that are something else than code need to be created during a software project. The book lists roughly 30 of them. I won't argue about the relevance of each individual work product, but I'm very happy about these things are not neglected in a book on an agile methodology.

Chapter five starts with reasoning about project dependency. Instead of viewing a project as a linear sequence of steps, it should be viewed as a dependency graph and read right to left, i.e., in order to deliver software, the team first has to test it, in order to test it, the team first needs to write it etc. For me, that was a fresh way of looking at a seemingly undisputable structure like the "waterfall project."

Towards the end of the book, there are some pages that compare Crystal Clear with Scrum, XP, and RUP. Finally a clarification, and a precise one. Speaking of clarifications, it's good that the author decided to include chapters six and seven (what usually goes wrong and answers to questions). They are needed in order to further clarify the text.

So what did I actually think about the book? So far I've been repeating what the chapters were all about. To be honest, I have to start someplace else, by saying that I'm not particularly happy with this review. It lacks flow and coherence. I might be due to the fact that I read the book a while ago, but I suspect the cause is the complexity of the text. The text is packed with information, and I pick out individual things to comment on, and it comes out weird.

I think that this is a great book! It gives you more agile that you could possible ask for, but I almost think the author is too smart for his own good. There is only so much information a reader can process. For example, while describing 30 work products is a good thing, cramming that in with a deep methodology description and thorough analysis and breakdown of a method is a heavy thing to do in roughly 200 pages. The text is, of course, very well written, and I certainly can't accuse the author for wasting words.

In conclusion: great book with lots of information and things that get you thinking. Must be read several times probably. On the downside is the weight of the text, the quality of the photographs in the book, and the last chapter (the case study).

Who should read this book

Read this one more as a book on agile software development than an introduction to Crystal Clear.




News

  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.