Crystal is a family of methodologies with a common genetic code. The genetic code helps you to design a new family member when you need one and to tell whether a given methodology is a member of the family. Jens Coldewey summarized Crystal neatly:
Crystal is my considered effort to construct a package of conventions that work well together and that, taken together, increase the odds of project success and the odds of actually being used by the team. It is possible that the package is faulty, but teams who have used it have reported good results on both fronts. The Crystal methodologies are intended to be tailored at the start of each project (and periodically within the project). I put bounds on the tailoring, identifying the places where I feel a sharp drop-off in the likelihood of success occurs (refer to "Sweet Spots and the Drop-Off", p. 290). My observation is that when people say they are "using something like Crystal," they usually don't reflect on their work habits very seriously. Without reflection, they lose the opportunity to improve their output. (They also usually don't deliver the system very often, and they don't have very good tests, but those are separate matters.) The Crystal genetic code consists of six elements:
The Cooperative Game Mind-SetTreating software development as a cooperative game of invention and communication frees the team to consider what moves make sense at any moment in time and what strategies create a good position for the next move. It frees the team from the illusion that there is a single formula to use across all projects. Treating the project as part of an interconnected series of games highlights the importance of balancing the need to deliver this system with the need to set up for the next games. This book has described the cooperative game model in depth. Methodology PrioritiesEvery methodology author has some priorities in mind while selecting what to include and what to exclude. Mine are
The first priority is the overriding one. If the project does not deliver the system, there is a basic failure. The next two priorities compete with each other. On the one hand, there are extremely efficient ways of working that people will simply refuse to use. Programmers today can still avoid or subvert the process if they don't like it. To be successful, a methodology needs to be accepted by the team. Therefore, habit-abilitywhether people are willing to live with these conventionsis critical. I used to write this priority as tolerance, meaning how much variation would be considered acceptable from person to person and from project to project. From my perspective, the methodology needs the tolerances on the conventions to be as loose as possible. It should work across the widest possible variations in practice. However, I was told that the word tolerance translates poorly into other languages, so we chose habitability. Habitability runs against efficiency because the team, or individuals on the team, may decline to use some more efficient techniques or conventions. My feeling is that possibly less-efficient conventions that are actually used may serve the team better over time. Balancing efficiency against habitability is not a Shu-level skill. It requires one or more people on the team to have a Ri-level understanding of software development to make this balance. This matches the acceptance level I have seen for Crystal. Beginner teams look at Crystal, don't see a clear formula to use, and move on to XP (version 1) or Scrum. Advanced teams know that methodologies out of the box are unlikely to fit their situation. They like Crystal because it provides just enough rules to get the project into the safety zone and leaves them plenty of room to incorporate their situation-specific adjustments. Methodology Design PrinciplesThe principles used to design Crystal were presented in Chapter 4. Crystal particularly emphasizes the value of face-to-face communications, adjusting methodology to project type, and attending to project-specific bottlenecks. These principles are visible in the differences between the Crystal family members. Seven Properties of Highly Successful ProjectsI only recently awoke to the realization that top consultants trade notes about the properties of a project rather than the procedures followed. They inquire: Is there a mission statement and a project plan? Does the team deliver frequently? Are the sponsor and various expert users in close contact with the team? Consequently, and in a departure from the way in which a methodology is usually described, I started asking teams to target key properties for the project. "Doing Crystal" becomes a matter of achieving the properties rather than following procedures. Three motives drive this shift from procedures to properties:
Naming the properties provides the team with catchphrases to measure their situation by: "We haven't done any reflective improvement for a while." "Can we get more easy access to expert users?" The property names themselves help people diagnose and discuss ways to fix their current situation.[1]
A Crystal team measures its condition by the team's mood and the communication patterns as much as by the rate of delivery. I noticed this while interviewing Géry Derbier of Solystic about his experiences with his Crystal Yellow project (see "Stretching Crystal Clear to Yellow," p. 364). I was trying to work out why he said he was using Crystal, and I realized that he had been focusing on the quality of the communications within his team, across organizational boundaries, with both his customer-side sponsors and the external test team. He watched the delivery cycles, reflected with the team each month on how to work better together, and experimented with fitting different authors' ideas into the group's working patterns. The following list presents seven properties of highly successful projects along with test questions for each. The first three are the unifying theme across the family. The other properties increase the safety factor for the project. The properties are described in greater detail in Crystal Clear (Cockburn 2005a).
One additional property is worth mentioning, one that shows up only on the very best of projects:
Techniques à DiscretionA common mistake of the beginning methodologist is to believe that the latest technique he just learned is the master technique that all people must use. As Andy Hunt and Dave Thomas, the "pragmatic programmers," have gone to great lengths to point out (Hunt 2000), there is a steadily growing number of useful techniques in the world. It is the responsibility of the professional in his field to learn how to use them. It makes no sense for me, as the author of a methodology to be used by widely varying people on teams in different countries working on different projects with different technologies, to legislate what technique will work best for each of those people and each of those teams. That is something for each person and team to work out. From the perspective of the Crystal family of methodologies, any technique of invention is quite all right, as long as the person can explain the idea to the rest of the team afterwards. Thus, some people will like to model in UML; others will not. Some will like to program in pairs; others won't. Some will thrive on test-first development; others will write code first and tests after. Some teams will use the XP planning game, some my Blitz Planning technique, and others the Scrum backlog list. What I have done in this book and the Crystal Clear book is to list techniques and strategies that you and your team may find interesting and useful. Here is short summary of interesting strategies and techniques for you to consider:
Sample Methodology DesignsHumans are better at modifying than inventing. For this reason, Crystal contains sample methodology descriptions. Think of "cutting and pasting" the following into your methodology. It is not my intention that you pick up these descriptions and use them untouched, but rather that you pick them up and critique them, adding and subtracting details until what you have suits your situation. Methodology modification is, after all, a core element of Crystal. |