Crystal Methods and Choosing an Agile Approach

Crystal is actually a family of agile methods — developed by Alistair Cockburn, the same thinker behind the osmotic communication and caves-and-commons ideas covered earlier — rather than a single fixed process. Where many agile frameworks hand a team one process and expect it to fit every project, Crystal explicitly tunes itself to the specific project in front of it, based on five factors: People, Skills, Size, Complexity, and Criticality.

Crystal is best known for its color-coded family, which maps a project's team size against its criticality — what's actually lost if the system fails — to select the right "weight" of process. Criticality is graded on four levels, from least to most severe: Comfort (a failure is merely an inconvenience), Discretionary Money (a failure costs money the business can choose to spend elsewhere), Essential Money (a failure costs money the business genuinely needs), and Life (a failure could cost someone their life). Team size runs across five bands: roughly 1–6 people, 7–20, 21–40, 41–80, and 81–200, corresponding to the colors Clear, Yellow, Orange, Red, and Maroon respectively.

The logic is straightforward once you see the grid: a small team building something where failure is merely uncomfortable (say, an internal tool with no financial or safety stakes) can run Crystal Clear — minimal ceremony, maximal trust in the team's own judgment. A large team building something where failure could cost lives needs Crystal Maroon — much heavier documentation, verification, and coordination, because the cost of an undetected defect is categorically different. The same underlying agile values apply across the whole family; what changes is how much formal process weight is actually justified by the project's real size and stakes.

Crystal is one of the clearest concrete examples of a broader idea PMI tests throughout the Mindset domain: agile models should be integrated based on the project's actual needs — its use case, its team, its organization — rather than a single methodology being applied uniformly regardless of fit. A two-person spike team and an eighty-person platform team modifying life-safety software shouldn't run the same process, and Crystal gives that intuition an explicit, nameable framework rather than leaving it as an unstated judgment call.

Study focus: when a question describes a small, low-stakes project being forced through the same heavyweight documentation and sign-off process as a large, safety-critical one, the expected diagnosis is a process-to-project mismatch — Crystal's own framework (or process tailoring, covered earlier) is exactly the tool meant to catch and correct it.