The Crystal agile framework is 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
The Crystal Method was created by American computer scientist and agile pioneer Alistair Cockburn during his time with IBM.
Cockburn was tasked with studying software development processes, which saw him interview a number of successful development teams to better understand how they worked.
Using what he learned from the interviews, Cockburn realized that — despite the team’s successes — there was no formal methodology in place at the time. Instead, there were a series of best practices based on team size, criticality, and priority.
At the end of the study, Cockburn came out with a solid conclusion that led to him creating the crystal methodologies.
Rather than focusing on developing specific, step-by-step development strategies, the crystal framework author sought to establish guidelines for team collaboration and communication.
There are many agile methodologies out there including XP, Scrum, ASD, FDD and of course, Crystal. Each type of agile development has its pros and cons — and choosing between them depends on how your team operates.
Most scrum methods are designed to be a one-size-fits-all solution, while Crystal development focuses on the idea that each project has unique characteristics. Crystal methodologies task us with customizing our processes to accommodate those unique characteristics, resulting in the best possible final product.
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.