The Crystal family of methodologies includes a number of different methodologies for selecting the most suitable methodology for each individual project. Besides the methodologies, the Crystal approach also includes principles for tailoring the methodologies to fit the varying circumstances of different projects.
Each member of the Crystal family is marked with a color indicating the 'heaviness' of the methodology, i.e. the darker the color the heavier the methodology. Crystal suggests choosing the appropriate color of methodology for a project based on its size and criticality. Larger projects are likely to ask for more coordination and heavier methodologies than smaller ones. The more critical the system being developed the more rigor is needed. The character symbols in Figure 6 indicate a potential loss caused by a system failure (i.e. the criticality level): Comfort (C), Discretionary money (D), Essential money (E) and Life (L). In other words, criticality level C indicates that a system crash due to defects causes a loss of comfort for the user whereas defects in a life critical system may literally cause loss of life.
The dimensions of criticality and size are represented by a project category symbol described in Figure; thus, for example, D6 denotes a project with a maximum of six persons delivering a system of maximum criticality of discretionary money.
There are certain rules, features and values that are common to all the methods in the Crystal family. First of all, the projects always use incremental development cycles with a maximum increment length of four months, but preferably between one and three months. The emphasis is on communication and cooperation of people. Crystal methodologies do not limit any development practices, tools or work products, while also allowing the adoption of, for example, XP and Scrum practices. Furthermore, the Crystal approach embodies objectives for reducing intermediate work products and shaping conventions within a methodology for individual projects and developing them as the project evolves.
There are currently three main Crystal methodologies constructed: Crystal Clear, Crystal Orange and Crystal Orange Web. The first two of these have been experimented in practice and are thus also introduced and discussed in this section.
All of the methodologies of the Crystal family provide guidelines of policy standards, work products, "local matters", tools, standards and roles to be followed in the development process. Crystal Clear and Crystal Orange are the two Crystal family members that have been constructed and used. Crystal Orange (Cockburn 1998) also presents the activities included in the process. In this subsection, these two methodologies are discussed by viewing their contexts, similarities and differences and illustrating the process and activities of Crystal Orange.
Crystal Clear is designed for very small projects (D6 project category projects), comprising up to six developers. However, with some extension to communication and testing it can be applied also to E8/D10 projects. A team using Crystal Clear should be located in a shared office-space due to the limitations in its communication structure.
Crystal Orange is designed for medium-sized projects, with a total of 10 to 40 project members (D40 category), and with a project duration of one to two years. Also E50 category projects may be applicable within Crystal Orange with additions to its verification-testing processes. In Crystal Orange, the project is split up for several teams with cross-functional groups using the Holistic Diversity strategy. Still, this method does not support the distributed development environment. The Crystal Orange emphasizes the importance of the time-to-market issue. The trade-offs between extensive deliverables and rapid change in requirements and design results in a limited number of deliverables enabling to reduce the cost of maintaining them, but still keeping the communication functioning efficiently between the teams.
Policy standards are the practices that need to be applied during the development process. Both the Crystal Clear as well as Crystal Orange suggest the following policy standards.
- Incremental delivery on a regular basis
- Progress tracking by milestones based on software deliveries and major decisions rather than written documents
- Direct user involvement
- Automated regression testing of functionality
- Two user viewings per release
- Workshops for product- and methodology-tuning at the beginning and in the middle of each increment
The only difference between the policy standards of these two methodologies is that Crystal Clear suggests incremental delivery within a two to three month time frame whereas in Crystal Orange the increments can be extended to four months at the maximum.
The policy standards of these Crystal methodologies are mandatory but can, however, be replaced with equivalent practices of other methodologies such as XP or Scrum
Cockburn's requirements for work products of Crystal Clear and Crystal Orange differ to a certain extent. The similar work products of both Crystal Clear and Orange include the following items: release sequence, common object models, user manual, test cases, and migration code.
In addition, Crystal Clear includes annotated use cases/feature descriptions, whereas in Crystal Orange the requirements document is required. In Crystal Clear, the schedule is documented only on user viewings and deliveries and the comparable work product in Orange that Cockburn lists is "schedule", indicating a need for more extensive scheduling of the project. The more lightweight nature of the work products in Crystal Clear emerges also in design documentation: while Orange demands UI design documents and inter-team specifications, in Clear only screen drafts and design sketches and notes are suggested if needed. In addition to these work products, Crystal Orange requires status reports.
Local matters are the procedures of Crystal that have to be applied, but their realization is left up to the project itself. The local matters of Crystal Clear and Crystal Orange do not largely differ from each other. Both methodologies suggest that templates for the work products as well as coding, regression testing and user interface standards should be set and maintained by the team itself. For example, project documentation is required but their content and form remains a local matter. Above this, also the techniques to be used by the individual roles in the project are not defined by Crystal Clear nor Crystal Orange.
The tools that the Crystal Clear methodology requires are compiler, versioning and configuration-management tool, and printing whiteboards. Printing whiteboards are used, for example, for replacing the formal design documents and meeting summaries. In other words, they are used for storing and presenting material that otherwise should be typed down in a formal documentation format after a meeting.
The minimum tools required by Crystal Orange are those used for versioning, programming, testing, communication, project tracking, drawing, and performance measuring. In addition, screen drivers are needed for repeatable GUI tests.
Crystal Orange proposes selecting the notation standards, design conventions, formatting standards and quality standards to be used in the project.
The activities of Crystal Orange are discussed in more detail in section Practices. They are included in the Figure as a part of the illustration of one increment of Crystal process.
Roles and responsibilities
In this section, the roles of Crystal Clear and Crystal Orange are presented according to Cockburn. The basic difference between Crystal Clear and Orange is that in the former there is only one team in a project. In Crystal Orange there are multiple teams to follow though the project. In both methodologies, one job assignment may include multiple roles.
In Crystal Clear the main roles requiring separate persons are sponsor, senior designer-programmer, designer-programmer and user. These roles embody multiple sub-roles. For example, the designer-programmer consists of business class designer, programmer, software documenter and unit tester. The sub-roles that can be assigned to other roles are coordinator, business expert and requirements gatherer. The business expert represents a business view in the project, possessing knowledge about the specific business context. He should be able to take care of the business plan, paying attention to what is stable and what is changing.
In addition to the roles introduced in Crystal Clear, Crystal Orange suggest a wide range of main roles needed in the project. The roles are grouped into several teams, such as system planning, project mentoring, architecture, technology, functions, infrastructure and external test teams. The teams are further divided into cross-functional groups containing different roles.
Crystal Orange introduces several new roles, such as UI designer, database designer, usage expert, technical facilitator, business analyst/designer, architect, design mentor, reuse point, writer, and tester. Crystal Orange also involves the skills and techniques needed in order to succeed in these roles. One project member can hold multiple roles. For example, reuse point is a part-time role that can be carried out by an architect or a designer-programmer, for instance. This role refers to the identification of reusable software components and acquisition of commercial components. Other roles that need further clarification are the writer and the business analyst-designer. The writer's role includes the construction of external documentation, such as screen specifications and user manuals. The Business analyst-designer communicates and negotiates with the users in order to specify the requirements and interfaces, and to review the design.
Each group consists of at least a business analyst designer, a UI designer, two to three designer-programmers, a database designer and possibly also a tester. Also technical facilitators may be needed in a group. The reason for having cross-functional groups is to reduce deliverables and to enhance local communication.
All Crystal methodologies involve a number of practices, such as incremental development. In the description of Crystal Orange (Cockburn 1998), the increment includes activities such as staging, monitoring, reviewing, along with parallelism and flux. . Also other activities and practices can be identified. These are included in the following descriptions.
Staging includes the planning of the next increment of the system. It should be scheduled to produce a working release in every three or four months at the maximum. A schedule of one to three months is preferred. The team selects the requirements to be implemented in the increment and schedules what they feel they are able to deliver.
Revision and review
Each increment includes several iterations. Each iteration includes the following activities: construction, demonstration and review of the objectives of the increment.
The progress is monitored regarding the team deliverables during the development process with respect to their progress and stability. The progress is measured by milestones (start, review 1, review 2, test, deliver) and stability stages (wildly fluctuating, fluctuating and stable enough to review). Monitoring is required in both Crystal Clear and Crystal Orange.
Parallelism and flux
Once the monitoring of stability gives the result "stable enough to review" for the deliverables the next task can start. In Crystal Orange, this means that the multiple teams can proceed with maximum parallelism successfully. To ensure this, the monitoring and architecture teams review their work plans, stability and synchronization.
Holistic diversity strategy
Crystal Orange includes a method called holistic diversity strategy for splitting large functional teams into cross-functional groups. The central idea of this is to include multiple specialties in a single team. The holistic diversity strategy also allows forming small teams with the necessary special know-how, and also considers issues such as locating the teams, communication and documentation and coordination of multiple teams.
The methodology-tuning technique is one of the basic techniques of Crystal Clear and Orange. It uses project interviews and team workshops for working out a specific Crystal methodology for each individual project. One of the central ideas of incremental development is to allow fixing or improving the development process. In every increment, the project can learn and use the knowledge it has gained for developing the process for the next increment.
Two user viewings are suggested for Crystal Clear per one release. In Crystal Orange, user reviews should be organized three times for each increment.
Both Crystal Clear and Orange include a rule that a team should hold pre- and post-increment reflection workshops (with recommendation for also mid- increment reflection workshops). Crystal Clear and Crystal Orange do not define any specific practices or techniques to be used by the project members in their software development tasks. The adoption of practices from other methodologies such as XP and Scrum is allowed in Crystal to replace some of its own practices, such as reflection workshops, for instance.