Selecting crystal agile methodology variants for your team

Assess team size and project criticality, then choose Crystal Clear, Yellow or Orange, and recognise when no Crystal variant fits.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Crystal is not one process. It is a family of variants, and the first practical decision a team lead or product manager makes is which member of the family to start from. For background on where Crystal came from and how it compares with Scrum and XP, see the Crystal Agile Framework method page. This page is about making the variant choice and living with its limits.

The choice rests on two inputs. Practitioner guidance says to map your team size against your project criticality before choosing a Crystal variant, because the variants scale their practices to those two factors. Cockburn's later book contents describe Crystal Clear, Crystal Orange, Crystal Orange Web, and stretching Crystal Clear to Crystal Yellow, which tells you the colors are positions on a spectrum of project conditions rather than stages every project passes through.

The variants also come with documented gaps. A review of the family notes that Crystal does not cover life-critical projects and is most useful for co-located teams. Knowing these limits before you commit is as important as picking the color, because a wrong fit tends to show up months later as missing verification or coordination that nobody planned for.

The table summarises what the sources say about the three most discussed variants. Where a cell says a source is silent, treat that as a real gap in the published material, not as permission to assume.

The output of this skill is a short written decision: the variant you chose, the size and criticality facts behind it, the gaps you will patch, and the date you will revisit it. That record lets the team challenge the choice later with evidence instead of memory.

How It Works

The selection works as a screen followed by a match. You gather two facts, rule out the cases Crystal does not cover, then place the project on the color spectrum and list what the chosen variant leaves out.

flowchart TD
  A[Count people who coordinate] --> C[Rate project criticality]
  C --> D{Life-critical system?}
  D -- yes --> X[Out of Crystal scope]
  D -- no --> E{One team in one office?}
  E -- yes --> F[Crystal Clear]
  E -- no --> G{Modest stretch beyond Clear?}
  G -- yes --> H[Crystal Yellow]
  G -- no --> I[Crystal Orange]
  I --> J[Patch missing sub-teams and verification]
  F --> K[Revisit at [reflection workshop](https://tryhamster.com/skills/running-reflection-workshops)]
  H --> K
  J --> K

Team size. Count the people who exchange information daily, not the names on an org chart. Size matters because communication paths multiply as people are added, and the lighter variants assume those paths stay short. Crystal Clear is described as having a limited communication structure intended for one team working in the same office. Once you have more than one team or more than one location, Clear's assumptions stop holding.

Criticality. Ask what the worst plausible defect costs: annoyance, money, or human safety. Heavier consequences call for more formality, which is why practitioner guidance treats criticality as a primary input alongside team size. The hard boundary is life-critical work: the same review that describes Clear's structure states that the Crystal family does not cover life-critical projects because it lacks sufficient system-validation elements. This concern is not unique to Crystal. A broader survey of empirical findings notes that a widespread criticism of agile methods is that they do not work for systems with criticality, reliability and safety requirements.

Matching. With size and criticality known, the match is usually quick. One small co-located team points to Clear. A group that has outgrown Clear only modestly points to Yellow, which Cockburn frames as stretching Crystal Clear. Larger projects point to Orange, which the review describes as suitable for up to 40 people but lacking sub-team structure and activities for design and code verification. The published sources say little about Yellow's exact boundaries, so treat that choice as a judgement call you document and revisit.

Patching. Every variant leaves something out. Your decision record should list the gaps and who owns closing them. Orange teams, for example, need to design their own sub-team boundaries and add review or verification steps.

Signs the choice went wrong. Watch for questions that take days to answer, work blocked on another team with no agreed channel, or defects escaping because nobody verified designs. Any of these suggests the team is running a lighter variant than its size or criticality warrants. The reverse signal, ceremonies and documents nobody reads, suggests you chose something heavier than you need. Practitioner guidance places this check inside the normal cycle: select the variant, establish a delivery rhythm, then inspect and adjust through reflection workshops.

Step-by-Step Guide

Step 1: Count who must coordinate

List everyone who needs to exchange information about the product each day: developers, testers, designers, the product manager and any expert users. Leave out people who only receive reports. Note how many distinct teams exist and how many physical locations they work from. The output is three facts: a head count, a team count and a location count.

These drive the whole decision, so get them from the actual working pattern rather than the planned one.

Pro tip: Ask each person who they spoke to about the work last week. The answers reveal the real coordination group faster than any org chart.

Step 2: Rate the project's criticality

Write down the worst plausible consequence of a serious defect reaching users. Place it on a simple scale from inconvenience, through financial loss, to harm to people. Crystal variants are meant to scale their practices according to team size and criticality, so this rating matters as much as head count. Get agreement from the product owner or sponsor, because developers and business stakeholders often rate risk differently.

Pro tip: Frame the question as a concrete incident, such as a wrong invoice or a failed dosage calculation. Concrete cases end vague debates about how critical something feels.

Step 3: Screen out life-critical work

If a defect could injure or kill someone, stop the variant selection here. The Crystal family is documented as not covering life-critical projects because it lacks sufficient system-validation elements. Record that decision and choose a method with formal validation for that system. If only one component is life-critical, consider separating it so the rest of the product can still use a lighter approach.

Step 4: Match the project to a color

Use the facts from the first two steps to place the project. One small team in one office maps to Crystal Clear, which is built around one team working at the same office. A modest stretch beyond that maps to Crystal Yellow, described in Cockburn's book contents as stretching Crystal Clear to Crystal Yellow. Larger groups map to Crystal Orange.

Remember that the colors describe project conditions, not a maturity ladder, so moving to a heavier color is not a promotion.

Pro tip: When a project sits on a boundary, start with the lighter variant and add practices as problems appear. Removing unneeded ceremony later is harder than adding what is missing.

Step 5: List and assign the documented gaps

Write down what your chosen variant does not provide. Crystal Orange, for example, is described as lacking sub-team structure and activities for design and code verification, so an Orange team must design those itself. If people work from several locations, note that Crystal is considered most useful for co-located teams and decide how you will replace overheard conversation. Give each gap a named owner and a first action.

Pro tip: Keep the gap list on the same page as the variant decision. Separating them lets the gaps quietly disappear.

Step 6: Record the decision and schedule a review

Write a short decision note: the variant, the size and criticality facts, the gaps and their owners, and a review date. Then move on to setting a delivery rhythm and reflection cadence, following the sequence of assessing context, selecting a variant, establishing a rhythm, and adjusting through reflection workshops. Revisit the choice when head count, locations or criticality change. Use reflection workshops as the natural checkpoint.

Pro tip: Add one line naming the change that would trigger a re-selection, for example, a second office opening. It turns a vague review into a clear trigger.

Best Practices

• Base the decision on how people actually coordinate, not on reporting lines. Two teams that share every standup are closer to one team, while one team split across time zones behaves like two.
• Rate criticality with the business sponsor in the room. Developers tend to underrate financial and legal exposure, and sponsors tend to underrate technical fragility, so a joint rating is more honest.
• Treat the life-critical screen as a hard stop rather than a factor to weigh. The documented limitation is about missing validation, and no amount of tailoring inside a lightweight variant replaces formal system validation.
• Prefer the lightest variant that covers your facts. Extra formality has a real cost in attention and delay, and Crystal's family model exists so small teams do not carry process built for large ones.
• Write gaps down as explicitly as the variant itself. A variant choice without its gap list gives a false sense of coverage, especially for Orange's missing verification activities.
• Pair the variant choice with the practical work of tailoring the process to your context. The color is a starting point, and the conventions you adopt on top of it determine whether it works.

Common Mistakes

• Treating the colors as a maturity path, so a team moves from Clear to Orange because it feels more professional.: Colors describe project conditions such as size and criticality. Move to a heavier variant only when those facts change, and record which fact changed.
• Choosing Crystal for a system where a defect could harm people, then trying to bolt on extra testing.: Crystal is documented as not covering life-critical projects because of missing validation elements. Separate the life-critical component and run it under a method with formal validation.
• Picking Crystal Orange for a large group and assuming sub-team coordination and code verification will take care of themselves.: Orange is described as lacking sub-team structure and design and code verification activities. Design sub-team boundaries and verification steps explicitly and give each an owner.
• Running Crystal Clear across several offices because the head count is small.: Clear assumes one team in one office. If people are distributed, note the lost ambient communication as a gap and plan how you will replace it, or choose a method designed for distributed work.
• Making the choice once at kickoff and never revisiting it.: Team size and locations drift. Set a review trigger in the decision note and check the fit at reflection workshops.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Crystal Agile Framework

Related Skills

• Implementing Frequent Delivery Cycles in Crystal Projects
• Designing Technical Environments That Support Team Focus
• Facilitating Osmotic Communication in Agile Teams
• Integrating Expert User Access into Development Workflow
• Tailoring Agile Processes to Your Specific Team Context
• Establishing Personal Safety for Honest Team Collaboration
• Running Reflective Improvement Workshops in Crystal

Sources

• [PDF] Empirical Findings in Agile Methods
• Effective Implementation of Agile Practices
• Crystal Agile Methodology - Project Management Formula

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.