Crystal Agile Framework Customization for Your Team

Shape a Crystal process that fits your team by keeping the core properties, choosing techniques deliberately and revising conventions often.

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

Tailoring is the skill of deciding which practices your team actually runs, writing that decision down, and changing it as the project teaches you what works. In Crystal it is not an optional extra. Alistair Cockburn states plainly that there is no one Crystal methodology, and the family is built to adapt to different project types rather than prescribe one universal process. For the definition and history of Crystal, see the Crystal Agile Framework method page. This page covers the doing.

The work has clear inputs. You need the team's size and the project's criticality, which practitioner guidance treats as the starting point for choosing a Crystal approach. You need the list of properties Crystal aims for, which the book gives as frequent delivery, reflective improvement, close communication, personal safety, focus, easy access to expert users, and a technical environment with automated testing, configuration management and frequent integration. And you need a menu of techniques to choose from. The outputs are a short written set of team conventions, a record of which practices you kept or dropped and why, and a date when you will look at it again.

The central distinction is between properties and techniques. Properties describe the state the team should be in. Techniques are tools for getting there. One practitioner guide describes the properties as not optional but fundamental to the Crystal philosophy, while the Crystal Clear book presents techniques as a catalogue, starting with Methodology Shaping and Reflection Workshop. Customizing Crystal well means holding the properties fixed as goals and treating techniques as replaceable.

A team lead, delivery lead or product manager usually drives this, but the whole team should shape the result, because they are the ones who will live with it. You know it has gone wrong when the written process no longer matches what people do, when a practice survives only because nobody questioned it, or when a property such as focus or frequent delivery quietly stops holding and no convention changes in response.

How It Works

Crystal customization works in three layers, and each layer changes at a different speed.

The first layer is context. Team size and criticality decide how much structure the process needs, which is why practitioner guidance says to map team size against project criticality before anything else. Cockburn's later treatment shows the same logic at the family level: it discusses Crystal Clear, Crystal Orange, Crystal Orange Web and stretching Crystal Clear to Crystal Yellow, variants that represent different team and project conditions rather than stages everyone must pass through. Context changes slowly. Revisit it when the team grows, splits, or takes on work with higher stakes. Choosing a color is its own skill, covered in selecting the right Crystal color variant.

The second layer is the properties. These are target states, and you test them with questions rather than tick them off as ceremonies. Cockburn's checklist frames frequent delivery this way, asking whether the team has delivered running, tested, usable functions to your user community at least twice in the last six months. Writing a similar plain question for each property gives the team a quick way to see which ones are weak. A weak property is the signal to add or change a technique.

The third layer is techniques and conventions. The Crystal Clear book lists techniques including Methodology Shaping, Reflection Workshop, Blitz Planning, Delphi Estimation Using Expertise Rankings, Daily Stand-up Meetings, Essential Interaction Design and Process Miniature. None is mandatory on its own. You adopt a technique because it strengthens a property your team is missing, and you drop it when the property holds without it. Conventions are the team's own small rules built on top: how work is picked up, where decisions are recorded, what counts as done. The framework's emphasis is on people, communication, frequent delivery and learning, with practices selected or adapted to the project rather than followed mechanically.

This layer changes fastest, and the reflection workshop is the engine. Cockburn describes it as taking an hour a month, and his presentation stresses that the team must actually use the ideas it produces. In practice the loop is simple: check each property, find the weakest, propose a change to a technique or convention, try it for a cycle, and keep or revert it at the next workshop. How to run that session is covered in running reflective improvement workshops.

The decisions you are making, in order, are: how much structure does this context need, which properties are currently weak, which technique would most cheaply fix the weakest one, and which existing practice can go. The written output stays short on purpose. A process document nobody reads cannot be revised, and revision is the whole point.

Step-by-Step Guide

Step 1: Map the team's context

Write down the team's size, whether members sit together, and what a serious failure would cost: lost comfort, lost money, or something worse. Practitioner guidance treats team size and criticality as the primary inputs to shaping a Crystal approach. These facts set the ceiling on how light your process can be. A small co-located team on low-stakes work can run with very little ceremony, while a larger or higher-stakes project needs more structure.

Record the context in two or three sentences at the top of your working agreement so later changes can be checked against it.

Pro tip: If the team cannot agree on the criticality level, that disagreement is itself useful information; resolve it with the sponsor before shaping anything else.

Step 2: Take stock of how the team works today

Before choosing anything new, list the practices the team already runs, including informal ones like a daily chat or a shared spreadsheet of bugs. For each, note what it is for and roughly how much time it takes. Many teams discover they are already doing a version of several Crystal techniques under other names. This inventory keeps you from bolting a new process on top of an old one and doubling the overhead.

The output is a plain list with a one-line purpose beside each item.

Pro tip: Interview two or three team members separately; the practices people name differ, and the gaps show you what is invisible to the lead.

Step 3: Test each core property

Take the seven properties Cockburn lists, from frequent delivery through to the technical environment, and write one honest yes or no question for each. Answer them as a team. The questions should be about outcomes, such as whether users have seen working software recently, not about whether a meeting happened. Mark each property as holding, weak, or missing.

The weakest one or two become the focus of your first tailoring decisions.

Pro tip: Keep the answers anonymous for the personal safety question; a public vote on whether people feel safe to speak tends to produce a misleading yes.

Step 4: Select techniques for the weakest properties

Look through the technique catalogue in Crystal Clear, which starts with Methodology Shaping, Reflection Workshop and Blitz Planning, and pick the smallest technique likely to fix each weak property. Resist adopting several at once. If close communication is weak, a change to seating or a short daily check-in may be enough. If reflective improvement is missing, the reflection workshop comes first because it drives every later change.

Write down which property each chosen technique is meant to strengthen.

Pro tip: Adopt no more than, for example, two new techniques per cycle so you can tell which change produced which effect.

Step 5: Write the team's conventions down

Turn the decisions into a short working agreement: context, the techniques in use and the property each serves, and the team's own conventions such as definition of done or where decisions are logged. Keep it short enough that everyone reads it. Put it where the team already works, not in a separate archive. Add a line for practices deliberately not used, with the reason.

This makes future debates faster because the reasoning is already recorded.

Pro tip: Aim for something that fits on a single page; if it grows past that, the team has probably stopped shaping and started accumulating.

Step 6: Drop practices deliberately

Go back to the inventory from the second step and ask of each practice which property it serves. If the answer is none, or if the property now holds without it, propose dropping it. Crystal's emphasis on adapting practices to the project rather than following them mechanically applies to removal as much as to addition. Treat each removal as an experiment for one cycle and note what you will watch to see whether something broke.

If a property weakens after a drop, restore the practice or find a cheaper replacement.

Step 7: Revise at every reflection workshop

Bring the working agreement to each reflection workshop, which Cockburn sizes at an hour a month. Re-run the property questions, review the experiments from the last cycle, and decide what to keep, change or revert. Record each change in the agreement with the date and reason. His presentation insists that the team actually use the ideas, so every workshop should end with at least one concrete change or an explicit decision to keep things as they are.

Revisit the context section whenever team size or criticality shifts.

Pro tip: Keep a short change log at the bottom of the agreement; reading it back after a few months shows whether the team is learning or cycling through the same fixes.

Best Practices

• Hold the properties fixed and let techniques vary. The properties describe what a healthy Crystal team looks like, so changing them changes the method; changing techniques is simply tuning how you get there.
• Tie every practice to the property it serves. When a practice has a named purpose, the team can judge whether it still earns its time, and removal debates become short and factual.
• Change one or two things per cycle. Small changes let you see cause and effect at the next reflection workshop; large reorganizations blur which change helped and which hurt.
• Record what you chose not to do and why. New members and future workshops will ask the same questions, and a written reason saves re-arguing a settled decision.
• Let the whole team shape the agreement. The people doing the work see friction the lead cannot, and a process they helped write is one they are more likely to follow and to challenge honestly.
• Re-check context when the team changes. A process shaped for a small co-located group can quietly fail when the team grows or spreads out, so treat headcount or criticality shifts as triggers for a fresh shaping pass.

Common Mistakes

• Adopting a named variant or technique list wholesale and running it as written.: Cockburn states there is no single Crystal methodology, so treat any list as a starting menu. Keep only what strengthens a property your team actually needs.
• Treating properties as optional because techniques are optional.: Dropping a technique is fine; letting frequent delivery, focus or personal safety lapse is not. If removing a practice weakens a property, replace it with another way of reaching that property.
• Adding practices after every problem and never removing any.: Pair every addition with a check for something to drop. A growing process eats the attention Crystal is meant to protect, and a stale item is easier to spot when each has a stated purpose.
• Holding reflection workshops that produce ideas but no changes.: End each workshop with a concrete change to the working agreement or an explicit decision to keep it. Collecting lessons without acting on them is the failure Cockburn warns against.
• Letting the written agreement drift away from real practice.: Review the document against what people actually do at each workshop. When they differ, either update the document or change the behavior, but never leave both standing.

References

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

Related Skills

• Selecting the Right Crystal Color Variant for Your Team
• 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
• Establishing Personal Safety for Honest Team Collaboration
• Running Reflective Improvement Workshops in Crystal

Sources

• Crystal Clear: A Human-Powered Methodology for Small Teams|eBook
• Crystal Agile Methodology - Project Management Formula
• Crystal Methodologies | Agile3
• Agile 2007
• [PDF] Crystal Clear: A Human-Powered Methodology for Small Teams

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