The Crystal Genetic Code


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:

The Crystal methodologies are about frequent delivery, close communication, and reflective improvement.

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-set

  • The methodology priorities

  • The methodology design principles

  • The seven properties of highly successful projects

  • Techniques selected per personal discretion, but with "interesting" starter techniques to consider

  • Sample methodologies to copy from

The Cooperative Game Mind-Set

Treating 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 Priorities

Every methodology author has some priorities in mind while selecting what to include and what to exclude. Mine are

  • Project survival (it should deliver the system)

  • Process efficiency

  • Process habitability, or tolerance

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 Principles

The 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 Projects

I 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:

  • The procedures may not produce the properties. Of the two, the properties are more important.

  • Procedures other than the ones I choose may produce the properties for your particular team.

  • I hope to reach into the feeling of the project. Most methodology descriptions miss the critical feeling that separates a successful team from an unsuccessful one.

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]

[1] Paul Oldfield catalogs problems that teams encounter and counteracting practices they may want to consider: http://www.aptprocess.com/whitepapers/risk/RiskToPatternTable.htm.

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).

  • Frequent Delivery. Have we delivered running, tested, and usable code at least twice to our user community in the last six months?

  • Reflective Improvement. Did we get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss our group's working habits, and discover what speeds us up, what slows us down, and what we might be able to improve?

  • Close / Osmotic Communication. For Crystal Clear projects: Does it take us 30 seconds or less to get our question to the eyes or ears of the person who might have the answer? Do we overhear something relevant from a conversation among other team members at least every few days? For other Crystal colors, replace those specific times with an inquiry into how long it takes to get a question to the right person, and the frequency of serendipitous discovery.

  • Personal Safety. Can we tell our boss we misestimated by more than 50 percent or that we just received a tempting job offer? Can we disagree with him or her about the schedule in a team meeting? Can we end long debates about each other's designs with friendly disagreement?

  • Focus. Do we all know what our top two priority items to work on are? Are we guaranteed at least two days in a row and two uninterrupted hours each day to work on them?

  • Easy Access to Expert Users. Does it take less than three days, on the average, from when we come up with a question about system usage to when an expert user answers the question? Can we get the answer in a few hours?

  • Technical Environment with Automated Tests, Configuration Management, and Frequent Integration. Can we run the system tests to completion without having to be physically present? Do all our developers check their code into the configuration management system? Do they put in a useful note about it as they check it in? Is the system integrated at least twice a week?

One additional property is worth mentioning, one that shows up only on the very best of projects:

  • Collaboration Across Organizational Boundaries. Collaboration across organizational boundaries is not a given result on any project. It results from working with amicability and integrity both within and outside the team. It is hard to achieve if the team does not itself have personal safety and, to a lesser extent, frequent delivery. I consider the presence of good collaboration across organizational boundaries as evidence that others of the top seven safety properties are being achieved.

Techniques à Discretion

A 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:

  • Exploratory 360°. Pre-project safety check. In a few days or a few weeks, sample the project's business value, requirements, domain model, technology plans, project plan, team makeup, and methodology.

  • Early Victory. Small wins help a group develop strength and confidence. Arrange for some early in the project. Walking Skeleton is a great start.

  • Walking Skeleton. A tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link the main architectural components.

  • Incremental Rearchitecture. Evolve the architecture in stages, keeping the system running as you go. This applies both to the Walking Skeleton and to later revisions.

  • Information Radiator. A display posted in a place where people can see it as they work or walk by. It shows readers information they care about without their having to ask anyone a question. Ideally it is large, visible to the casual observer, easily kept up to date, and understandable at a glance, and changes periodically so that it is worth visiting.

  • Pair Programming. Two people sit side-by-side, working on the same code. They can be two programmers or a programmer and a user, business specialist, or tester.

  • Side-by-Side Programming. Two people sit side-by-side but at different workstations, working on different assignments. The workstations need to be close enough that each person can read the other's workstation simply by turning her head (60 cm90 cm, or 12"18"). They help each other as needed.

  • Test-Driven Development. The test, or executable example, is written before deciding how to design the code. It serves both as a specification of what to design and as a practice run at using the call sequence to the function. Also called XXD (see page 275).

  • Blitz Planning. An index card-based planning session in which the sponsor, business expert, expert user, and developers together build the project map and timeline. Unlike XP's Planning Game, the cards in the Blitz Planning technique show tasks and task dependencies.

  • Daily Stand-up Meeting. Everyone in the team meets, standing, for a maximum of 10 minutes to announce what they each are working on and where they are getting stuck.

  • Agile Interaction Design. A one- or two-day sticky note and index card-based system usage modeling session, based on the ideas in Software for Use (Constantine 1999). Described in (Patton 2003).

  • Burn Charts. A time-based graph of features to be completed over time and features completed so far.

  • Dynamic Priority Lists. A list of features to work on in the next iteration or the whole project, prioritized and put into ranking order by the sponsors and updated by them at the end of each iteration or delivery cycle.

  • Reflection Workshop. A work pause, for an hour periodically, certainly after each delivery, to reflect on the product, progress, and process.

Sample Methodology Designs

Humans 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.



Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net