Crystal is not actually a methodology itself, but a family of methodologies that vary based on the size and complexity of the project. Crystal is the name given by its creator, Alistair Cockburn, to the entire family of methodologies. Each specific methodology in the family is named after a color corresponding to the geological crystal's hardness, representing that project's size and criticality. While Cockburn eludes to the possibility of a spectrum of methods, so far the only implementations we are aware of are: Clear, Yellow, Orange, Orange Web, Red, and Maroon.
While these flavors of Crystal share many elements, it should be noted that they are not intended by Cockburn to be upward or downward compatible. If a project starts as a Crystal Clear project it should not expect to transition to a Crystal Maroon project. The founder implies that should the project turn into a Maroon project, the project should adopt the characteristics and practices of a Maroon project, and not expect to "grow" the prior Crystal Clear practices over time.
Regardless of which Crystal implementation you choose, you will find seven key principles at the heart of each:
- Frequent Delivery: Project owners/customers can expect deliverables from the team(s) every couple of months. On larger or more critical projects the deliverables may not go into production but stakeholders will see intermediate versions and be able to provide feedback.
- Continual Feedback: The entire project team meets on a regular basis to discuss project activities. The team also meets with stakeholders regularly to make sure the project is heading in the expected direction and to communicate any new discoveries that may impact the project.
- Constant Communication: Small projects expect the entire team to be in the same room, while larger projects are expected to be co-located in the same facility. All projects expect to have frequent access to the person(s) defining the requirements.
- Safety: Crystal is somewhat unique in its focus on the safety aspect of software development. This comes in two forms. One is the safe zone that team members must have to be effective and to communicate truth during the project without fear of reprisal; this is true of most Agile methodologies. The other form of safety that only Crystal recognizes is that the purpose of each software project is not the same and that some software projects are affect the safety of their end-users. For example, a space shuttle system is much more critical than a recipe organizer.
- Focus: Team members are expected to know the top two or three priority items each member should be working on and should be given time to complete them without interruption.
- Access to Users: As with most Agile methods, Crystal expects that the project team will have access to one or more users of the system being built.
- Automated Tests and Integration: Crystal has various capacities for verification of project functionality. Controls must be put in place to support versioning, automated testing, and frequent integration of system components.
Some key Crystal concepts are project size and criticality. Size is defined as the number of people involved in a projectnothing too earth shattering here, except that as the team size grows Crystal changes to add more formality to the structure, artifacts, and management of the project.
Criticality is defined as the potential for the system to cause damage. In other words, a life support system that malfunctions could cause a lot more damage than a video game that won't let you save your game. As project criticality increases the rigidity of the project needs to increase as well to ensure the expected demands can be delivered.
Figure 2 depicts how to determine which Crystal methodology to use for a project. As the project size increases (moves to the right of the diagram), the harder the project, and hence a more comprehensive (darker color) of Crystal is necessitated. As the criticality of a project increases (moves from the bottom to the top of the diagram), aspects of the methodology need to be put in place to accommodate the additional requirements, including the artifacts generated by the team; however criticality does not affect the color of Crystal used.
The letters in the cells represent the criticality of the project as follows:
- C: Comfort
- D: Discretionary Money
- E: Essential Money
- L: Life
|Figure 2. The Crystal Family of Methodologies. One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from left to right), the darker the color.|
The numbers in the cells (along the bottom of Figure 2) represent the upper size of the project team. For teams up to six, the Crystal Clear methodology works fine. For teams of seven to 20, Crystal Yellow will introduce mechanisms to help manage the additional team size. For teams of 75 or 80 members, Crystal Red should do the trick. A project of one to six folks working on an atom splitter need a tad more in the way of checks and balances than the same size team creating yet another web site for their garage band.
Due to the bulk of the published data focusing on Crystal Clear and Crystal Orange projects, we will include some specifics of each of these methodologies. For more information on other methodologies in the Crystal family, see the references provided at the end of this article.
Roles vary across the Crystal methodologies as the size and criticality of the project increases. In other words, Clear has the fewest defined roles and Maroon has the most. The minimum defined roles for Crystal Clear projects are:
- Senior Designer
Crystal Clear expects that all team members will be working in the same room together. Support for more complex communication is not specified. The most important role is the Senior Designer, who is expected to be capable of making all the technical decisions that need to be made. Roles of project manager, business analyst, tester, etc. are shared among all team members.
Working software is expected to be delivered every two to three months. The team can work in smaller iterations if desired, but the expected release is every 60 to 90 days.
Crystal Clear requires minimal documentation, as project milestones are commonly the actual software delivery, not written documents. The team is responsible for defining any additional artifacts that they produce, and for defining their own coding standards, testing practices, etc.
As you would expect, the number of roles increases greatly for Orange projects. Roles can vary depending on the organization, but typically they include the traditional roles of Architect, Sponsor, Business Analyst, Project Manager, etc.
Because there is a greater need for verification in larger projects, specific care is taken to make sure more structure is put in place around the overall process, as well as a larger emphasis on testing, as each subgroup within the team is expected to have a tester.
Crystal Orange projects are described as typical medium-sized projects.
Working software is expected to be delivered every three to four months. The team can work in smaller iterations if desired, but the expected release is every 90 to 120 days.
Crystal Orange defines a set of specific deliverables:
- Requirements Document
- Release Sequence (Schedule)
- Project Schedule
- Status Reports
- UI Design Document (if project has a UI)
- Object Model
- User Manual
- Test Cases
As with Crystal Clear, the team is responsible for defining their own standards and guidelines for the artifacts they deliver.