Alistair Cockburn - Agile Software Development

Thus, in 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 the 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 6-1).

Figure 6-2. The Crystal methodologies are named by color. In Figure 6-1, I omit life-critical systems from the shaded areas. This is because I have not worked on or interviewed life-critical-system projects, and so don't have enough information to say exactly how an agile life-critical project looks.

The gray E6 box, outside Crystal Clear, indicates that Crystal Clear does not explicitly address "essential moneys" 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 only address colocated teams. As discussed earlier, none of the distributed and off-shore development projects I have seen would count as methodologically successful. They only recommendation I have for such projects is to put the team together at one location.

Crystal does not aim to be upward or downward compatible. In using computer hardware, there are large financial consequences to changing hardware, which cause 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:

Software development is usefully viewed as a cooperative game of invention and communication, with the primary goal of delivering useful, working software, and the 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 High tolerance

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 were 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 they use 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 evolve. The shifting bottlenecks in the system determine the use of overlapped work and stick information holders.

The two rules common to the Crystal family are: The project must use incremental development, with increments of four months or less (with strong preference to one- to three-month increments). The team must hold pre- and post-increment reflection workshops (with strong preference to also hold mid-increment reflection workshops).

The two base techniques in Crystal are: The methodology tuning technique: using project interviews and a team workshop to convert a Crystal Clear is a methodology for D6-category projects. You should be able to stretch Crystal Clear to an E8 or D10 category project with some attention to communication and testing, respectively. I expect it to be difficult to extend beyond that, since Crystal Clear contains no communication structure for more people than can conveniently work in the same room, and lacks the system validation elements needed for life-critical systems.

Brief Description of Crystal Clear

There is only one team, seated in one or adjoining offices.

The roles needing separate people are: Sponsor, Senior Designer-Programmer, Designer-Programmer, User (part-time at least)

One of those people may pick up the assignment of being Project Coordinator. Some one will be the 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 acoomplishing their goals.

Attending to the above issues creates something that has 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, pragmatism in reaching the two goals of the game.

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

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

Clear

Business Expert, and either one or many people will share the role of Requirements Gatherer.

The Senior Designer-Programmer is the key person on the team. The other Designer-Programmers may be at some mixture of novice and medium levels as the Senior Designer-Programmer and the problem can support. Hiring people who know their jobs of course helps.

The policy standards are that Software is delivered incrementally and regularly, every 2-3 months. Progress is tracked by milestones consisting of software deliveries or major decisions, as opposed to written documents. There is some amount of automated regression testing of application function. There is direct user involvement. There are two user viewings per release. Downstream activities start as soon as upstream is "stable enough to review".

Product and methodology tuning workshops are held at the start and middle of each increment.

The policy standards are mandatory, but equivalent substitution is permitted, as would be the case if Scrum work scheduling (Schwaber 2001), XP, or Adaptive Software Development (Highsmith 1999) policies were used.

The work products that are produced include: Release sequence

Schedule of user viewings and deliveries Annotated use cases or feature descriptions Design sketches & notes as needed Screen drafts A common object model Running code Migration code Test cases User manual

The following are left as "local matters," to be set and maintained by the team: Templates for the work products Standards for coding and user interface Standards and details of regression testing

Crystal Clear does require project documentation to be created. Just what that documentation consists of is not spelled out by Crystal. That is left as a matter of local judgement. The combined team must decide how to present their design notes to future team members.

The most important tools the team can own, besides a compiler are:

A versioning and configuration management system A printing whiteboard.

You should be able to cost-justify several printiing whiteboards on any project, based on just the time people save typing design documents and meeting

Crystal

Crystal Orange is a methodology for D40 category projects: up to 40 people, sitting in one building, working on a system that might cause loss of discretionary moneys, summaries, and lost communications cost when people do not copy down whiteboard contents.