Shaping the Crystal Family

Two plausible responses to the problem of needing multiple methodologies are to

• Create a kit of methodology parts that the project team assembles for its project

• Create a copy-and-alter family of specific methodologies that can be tailored on each project

Rational Corporation used the kit approach in the first generation of its methodology product, the Rational Unified Process (RUP) (Kruchten 1999). RUP is a framework for constructing methodologies for individual projects. It is centered on processes, work products, and tools and includes a collection of "best practices" to guide the practitioner along the way.

The assembling of a correct methodology for a RUP project hinges around creating a "development case" for the project and then assembling the parts from the RUP kit that fit the development case (Larman 2002).

The standard mistake managers make is not to do that assembling and tuning. They drop the library of work products on the development team and say, "Do that." The developers do one of two things:

• They recognize that producing all of those work products will damage the project, so they ignore the manager's instructions.

• They do as they are told and produce all of those work products (and damage the project accordingly).

RUP is not incompatible with the principles developed in this book, but it doesn't naturally lead people to focus on the two key success factors: communication and community.

My hope is that after reading this book, managers who buy RUP will allocate time to get it tuned to their projects. I also hope that the people who do the tuning will cut down the required work products produced to the smallest possible set and augment RUP with attention to communication, community, concurrent development, and so on.

An alternative way of approaching methodology-per-project is to collect a set of concrete, sample methodologies that have been used on projects and let the people on the project use the tailoring techniques described in the last chapter to adjust them on the fly.

This is the approach Jim Highsmith and I are following. We are collecting examples of successfully used communication- and community-based agile methodologies that people can use as starting points.

By seeing one that is already written, the new project team can see how the communication and community issues were addressed in a real situation. By having a set of examples to choose from, the team can find the one that most closely matches its situation.

I call the methodologies I design Crystal.

The word Crystal serves two purposes.

First, it is just a pleasant name. In the book Crystal Clear, a protagonist called Crystal personifies the methodology and argues for its design.

Second, it provides a metaphor that supports the first two degrees shown in the project grid in Figure 4-21.

Moving to the right in the grid means coordinating more people, which requires a heavier methodology. Using the crystal metaphor, moving right corresponds to choosing a darker color (clear quartz, topaz, ruby, sapphire).

Movement up in the grid corresponds to more potential damage from the system and the use of more rigor and ceremony. Using the crystal metaphor, moving up means increasing "hardness" (in the mineral hardness scale, the diamondthe hardest stonereceives hardness number 10).

Thus, according to the crystal metaphor, two people programming the overtime food menu are working on a project that calls for a soft, clear quartz crystal methodology. The two people programming the movement of boron rods in a nuclear reactor are working on a project that calls for a diamond-category methodology.

Of the two dimensions, I find the color dimension more useful as the project index. The hardness dimension can be more easily picked up in the methodology-tuning workshops.

I therefore index the Crystal methodologies by color: Clear, Yellow, Orange, Red, Magenta, Blue, Violet, and so on (Figure).

In Figure, I omit life-critical systems from the shaded areas. This is because I have not worked on or interviewed people about life-critical-system projects, so I don't have enough information to say exactly how an agile life-critical project looks.

The E6 box, outside Crystal Clear, indicates that Crystal Clear does not explicitly address "essential monies" projects but that the team may be able to stretch Crystal Clear to such a situation.

The other restriction on Crystal methodologies is that they address only colocated teams. As discussed earlier, none of the distributed and offshore development projects I have seen would count as methodologically successful. The only recommendation I have for such projects is to put the team together at one location.

Figure 6-1. The Crystal methodologies are named by color.

Crystal does not aim to be upward- or downward-compatible. In using computer hardware, there are large financial consequences to changing hardware, which causes compatibility to be a key issue. I don't see similar consequences in moving up and down the methodology scale. People working on a four-person project that grows to become a 20-person project shouldn't ask, "How do I preserve our former working conventions?" They should ask, "What is a good way for 20 people to work together?"

Core Crystal Elements

The core Crystal philosophy is that software development is usefully viewed as a cooperative game of invention and communication, with a primary goal of delivering useful, working software and a secondary goal of setting up for the next game.

Two consequences of that philosophy are that different projects need to be run differently, and the amount of modeling and communication that people need to do is just the amount they need to jointly move the game forward.

Members of the Crystal family share

• Values and principles

• On-the-fly tuning

Two values are that Crystal methodologies are intrinsically

• People- and communication-centric

• Highly tolerant

The former means that tools, work products, and processes are there only to support the human component. The latter recognizes varying human cultures.

Within the tolerance of the Crystal family, though, the team can choose to work in a high-ceremony or high-discipline manner (adopting parts of PSP or XP, for example).

Seven principles are discussed in Chapter 4, "Methodologies." The principles are roughly summarized as follows:

• The team can reduce intermediate work products as it produces running code more frequently and as it uses richer communication channels between people.

• Because every project is different and evolves over time, the set of conventions the team adopts must also be shaped and must evolve.

• The shifting bottlenecks in the system determine the use of overlapped work and "sticky" information holders.

The two rules common to the Crystal family are:

• The project must use incremental development, with increments of four months or less (and a strong preference for one- to three-month increments).

• The team must hold pre- and post-increment reflection workshops (with a strong preference for holding mid-increment reflection workshops as well).

The two base techniques in Crystal are:

• The methodology-tuning technique: using project interviews and a team workshop to convert a base methodology to a starter methodology for the project

• The technique used to hold the reflection workshop

You are welcome to replace those two techniques with others if you have another way of accomplishing these goals.

Attending to these issues creates a particular feeling. As someone wrote, it is possible to make another methodology look like a Crystal project without making it feel like a Crystal project. A visitor to a successful Crystal project will notice communications and community in action and will observe pragmatism in reaching the two goals of the cooperative game.

The following four sections describe the four Crystal methodologies I have so far constructed and seen used.

The structural differences between them are obvious. See if you can spot the commonalities.