Crystal is a family of software development methodologies with a common genetic code, including: frequent delivery, personal communications and improvement through reflection. For each type of project there’s its own method of Crystal.

Crystal Clear is a lightweight, flexible methodology created by Alistair Cockburn in 2004. It is designed for small teams of 6-8 people to develop non-critical business applications. Like all flexible methodologies for creating applications, Crystal Clear relies more on people than on processes and artifacts. This is a good alternative to extreme programming, with which it has common sides.

History of the Crystal family

In 1991, Alistair Cockburn, co-author of the Flexible Programming Manifesto, set out to create an effective software development methodology. For this, he interviewed a number of project teams and studied their development cases.

This research formed the basis for the key rules of Crystal Clear as an effective concept of software development:

– “human-oriented” methodologies are more useful than “processor-oriented”

– the methodology should be selected individually for the project and the team, there is no universal methodology for developing applications.

In 1994, he embodied these ideas as a leading consultant for the project called Orange. Practice has shown that the principles developed by Cockburn have served as the basis for the success of the project. In 1997, he wrote the book “Surviving Object Oriented Projects” about this experience, and a year later developed a family of methodologies and called them “Crystal”.

In 2004, Cockburn identified three basic methods of the concept:

1. Fast delivery of useful code, the transition from large and rare code deployments to smaller and more frequent releases.
2. Improvement through reflection – getting information about what worked well and badly in the previous version of the program to improve the next version of the software.
3. “Osmotic” communication – Cockburn explained the perception and exchange of information between application developers in one room as background noise resembling osmosis phenomena.

What is the Crystal methodology?

Crystal is a family of methodologies based on the three methods mentioned above.

“The only best” Crystal Clear methodology does not exist, each of the modifications is suitable for different types of projects. In this case, the organization or the project itself creates this modification on the basis of the “genetic code” (basic rules for using) Crystal.

The simplest of the possible classifications of Crystal – the number of people in the project, which are indicated by different colors:

– Clear – from 2 to 8 people who sit together in one or allied offices

– Yellow – 10-20 people in the team

– Orange – 20-50 people

– Red – from 50 to 100.

For large-scale projects use additional colors: Maroon, Blue and Violet.

Crystal Clear methods

Crystal Clear uses seven methods / practices, three of which are mandatory:

1. Frequent delivery of the product
2. Improvements through reflection
3. Personal Communications
4. Sense of security
5. Focusing
6. Easy access to experts
7. Qualitative technical environment

Apparently, all practices are typical for the Agile-methodology family. In this methodology, information is exchanged about the properties of the project, and not about the procedures being followed.

Consequently, deviating from the usual method of describing the methodology, it makes sense to ask the Crystal Clear group about the indicative key properties of the project. “Crystal clear execution” becomes an achievement of characteristics, and not following procedures.

There are two reasons for moving from procedures to characteristics:

1. Procedures may not generate characteristics. Characteristics are more important.
2. Other procedures other than those chosen may generate characteristics for your particular group.

Genetic code of Crystal Clear methodology

The genetic code of Crystal Clear consists of:

– an economically cooperative game model – is due to the fact that Cockburn understands software development as a series of “games”, the moves of which consist of inventions and communication limited by resources. Each game has two goals: to deliver the software in this game and to prepare for the next game in the series. In this case, the game never repeats and for each new project you need to prepare new strategies.

– selected priorities – common to all Crystal methodologies are two priorities: safety and effectiveness of development.

– selected characteristics – they serve to strengthen the security priority. Three (fast and frequent code delivery, personal communications, improvement through reflection) are basic, the remaining four are additional: personal security, focus, easy access to experts and a quality technical environment with automatic testing.

– the chosen principles – one of them continues the key direction of the individuality of setting the methodology.

Crystal Clear cycle process

Most Crystal Clear projects consist of 6 cycles, which define the list of duties and tasks of the project team:

• Project cycle – although the project itself is a unit of a product, it is usually followed by another project that repeats the cycle. The project cycle consists of three parts: preparation (team building, 360 ° study, methodology definition), a series of two or more delivery cycles and a “completion ritual”. It lasts from several days to weeks.
• Delivery cycle-consists of re-calibrating the release plan for the software, a series of one or more iterations that result in the tested integrated code, delivering to real users, and a “ritual of completion.” Duration – from 1 week to 3 months.
• Iteration – consists of three large parts: iterative planning, day and integration activities of the cycle and the “completion ritual” of the project.
• Working week / day – choosing the day or week as a unit of cycle time depends on the project format and the team. For example, weekly meetings of departments, reporting meetings of team leaders, brown-bag seminars are held in this format (when everyone brings his own lunch and during the snack the questions on the project are solved).
• Integration period – development, integration and testing of the system. In some teams, the assembly-testing process continues without stopping, for which a separate machine is responsible, others go along the path of integration once a day or three times a week. The shorter the integration cycle, the better. Duration from 30 minutes to 3 days (depending on the experience of the team).
• Development – writing and testing a piece of code. This is essentially the basis of the programmer’s work in “flexible development”. A team member takes a small task, programs a solution (ideally with testing) and checks it in a configuration with the whole system. Takes from 15 minutes to several days.

Crystal Clear Strategy and Techniques

“Clear” Crystal Clear does not require any strategies and techniques. Therefore, we suggest considering the starting set of techniques that will help the team to work effectively on each of the CC cycles.

The main strategies include:

• • “360 ° study” – at the very beginning of the project, the team needs to understand how useful and meaningful the product is and whether it can be created with available resources and technologies. For this, the project is considered in the following areas: business value, requirements, required technologies, project plan, team composition, selected methodologies. Implementation strategy takes from a couple of days to 1-2 weeks.

• • “Early victory” – victory strengthens and unites the team and increases the confidence of each of its members. When working on applications, the strategy of early victory is to find the first piece of working code. Its role is usually a small element of a useful system function (for example, the ability to add an object to the system database and look at it), which is called the “walking skeleton”. Members of the team on the basis of this small victory study the styles of each other’s work, users get an early idea of ​​the system, sponsors (customers) see the team’s performance.

• • “Incremental architecture change” – the architecture of the system should develop, because technological and business requirements change with time. The larger the project, the less effective it is to stop the development for an architectural review. The strategy is aimed at solving the problem: the team changes the architecture in stages, without disrupting the work of the entire system. This same strategy can be used to make changes to the functional of the final system.

• “Information radiators” is a display that is placed where people can see it during work or leisure. He shows the necessary information without having to ask unnecessary questions, and this embodies the important for Crystal Clear rule “more communication, less breaks.”

The information radiator should be large, easily accessible, easy to use and read, contain up-to-date information. A vivid example of such objects is Scrum- and Kanban-boards, less obvious – a working glossary, in which the interpretation of the terminology used in the project is prescribed.

The Crystal family is focused on three characteristics – permanent production, good communication and a reflective improvement, as they must be present in all projects. Crystal Clear uses advantage of the small size and short distance between groups to enhance good communication to more efficient osmotic communication. Experienced developers will notice that, except for this change, all the characteristics described here are applicable to each project, and not just to projects with small groups.

Crystal Clear is described as a set of characteristics. Most descriptions of methodologies lack an important indicator that separates a successful group from an unsuccessful one. The Crystal Clear group determines its state according to the mood of the group and the nature of the communication, as well as the degree of productivity. Assignment of names to characteristics provides the group with slogans to determine its situation: “For some time we did not perform a reflective improvement”, “Can we get easier access to experienced users?”. The very names of the characteristics help developers identify and discuss methods for resolving the current situation.