What is the Crystal Method?
Crystal is an agile framework focusing on individuals and their interactions, as opposed to processes and tools. In other words, this framework is a direct outgrowth of one of the core values articulated in the Agile Manifesto.
The Crystal agile framework is built on two core beliefs:
- Teams can find ways on their own to improve and optimize their workflows
- Every project is unique and always changing, which is why that project’s team is best suited to determine how it will tackle the work
What is the History of the Crystal Method?
Alistair Cockburn, credited as one of the original popularizers of agile, developed the Crystal method for IBM in 1991. He decided to focus not on developing specific step-by-step development strategies that would work across the board for teams involved in any project, but instead to develop guidelines for team collaboration and communication. The traits of Cockburn’s Crystal method were therefore all based around the team itself:
- Human-powered (meaning the project should be flexible and tailored to the needs and the preferred work modalities of people involved)
- Adaptive (meaning the approach uses no fixed tools but can be altered to meet the team’s specific needs)
- Ultra-light (meaning this methodology does not require much documentation or reporting)
What are the Strengths and Weakness of Crystal?
Crystal’s strengths include:
- Allows teams to work the way they deem most effective
- Facilitates direct team communication, transparency and accountability
- The adaptive approach lets teams respond well to changing requirements
Crystal’s weaknesses include:
Should You Use Crystal?
The Crystal method is among the more flexible agile frameworks, because it is designed around a project’s people and is not dependent on any single set of processes or tools. In that sense, it can be a viable methodology for organizations that want to empower their teams to work however they deem most effective.
It is important to keep in mind, however, that because Crystal emphasizes direct team collaboration around the software they’re building—and de-emphasizes the importance of documentation and reporting—this could mean the other teams across the organization will have less visibility into the team’s progress.