Crystal is an agile methodology for software development. It places focus on people over processes, to empower teams to find their own solutions for each project rather than being constricted with rigid methodologies.
Unlike more fixed frameworks like scrum, crystal recognizes that different teams will perform differently depending on team size, criticality, and priority of the project and encourages users to adapt the framework for their individual situation.
For example, a small team can keep itself aligned with regular communication, so it doesn't need much status reporting and documentation, whereas a large team is likely to get out-of-sync and would benefit from a more structured approach.
These are categorized by color, according to the number of people in the project;
Crystal clear - Teams with less than 8 people
Crystal yellow - Teams with between 10 and 20 people
Crystal orange - Teams with between 20-50 people
Crystal red - Teams with between 50-100 people
Alistair Cockburn worked at IBM in the 1990s and was tasked with developing a framework for software development.
By interviewing successful teams, he realized there wasn't a formal methodology in place, but there are best practices that varied based upon team size, criticality, and priority.
From this research, he developed a family of methodologies called crystal.
At the heart of the crystal, a family is seven principles. The first three are compulsory for all crystal approaches, but the rest are optional and can be adopted if appropriate:
You should deliver code regularly to your real users. Without this, you might be building a product nobody needs.
Look back on what you've done, how you've done it, and why. As a team, reflect and decide how to improve it in the future.
Cockburn believed that co-location (having teams in the same physical space) is critical as it allows information to flow between team members, as if by osmosis.
Team members should feel safe to discuss ideas openly, without fear of ridicule. There are no wrong answers or bad suggestions in a crystal team.
Team members should know what to work on next and be able to do it. This requires clear communication and documentation when required.
Team members should be able to get feedback from real users and experts when required.
Even back in the 1990s, Cockburn said development teams should have access to toolings like continuous deployment, automated testing, and configuration management. This means errors and mistakes can be caught quickly without human intervention.
Teams have a lot of autonomy to work in the way they deem most effective
Teams communicate directly with each other, reducing management overhead
The framework can adapt as a team grows or shrinks
Lack of structure can slow down inexperienced teams
Not clear on how remote teams can share knowledge informally
Lack of rigid planning can lead to confusion and loss of focus
Crystal is one of the most flexible frameworks, giving a huge amount of freedom to your development team to develop processes that work for them. This is ideal for experienced and autonomous development teams.
However, as crystal focuses on team communication around the product being built and discourages unnecessary documentation and reporting, it's difficult for other parts of the organization to know how the product is developing.