Friday, May 18, 2007

Agile Styles: Crytsal

Agile Software Development: The Cooperative Game (2nd Edition)Alistair Cockburn introduces us to Crytsal in a presentation give at Agile 2006. He starts by discussing Japanese Ikido and the concepts of Shu, Ha, and Ri. He states that people learn things in 3 stages:

1. Shu or following: Show me one way that works. Once I know it, I’ll move on to others
2. Ha or breaking away: Learn limitations of technique A and look for others that complement it or competes with it
3. Ri or fluency: Improvise, slice, shift, or combine techniques in a moment

Alistair recommends getting the starter level kit for all the agile styles. He mentions that a methodology is a reflection of the methodology author and people pick a methodology because the style of the author resonates with them.

Alistair then introduces us to Crystal be stating that it aims to be the lightest, least intrusive set of rules that puts a project in the safety zone. Its purpose is to keep people informed and keep them from hurting each other. Its nature is enable people to follow a set of conventions that gets updated regularly. Its philosophy is that people differ in their working styles, projects differ in needs, and software development is communication-intensive, experiment-based, needs lots of feedback in all directions, less is generally better, techniques and technologies change over time, and people learn in class or on the job and not from methodology.

Crystal Clear: A Human-Powered Methodology for Small TeamsAlistair shares a study he conducted which concluded that people centric methodologies do better than process centric methodology. Methodology is nothing more than a set of conventions that people agree to follow. He recommends adjusting a methodology based on the team and project like having a meeting every month and tuning the methodology based on what was learnt. As the people on the team change, the conventions of the team change. As the project evolves from beginning, middle to end, the strategies and conventions also change.

Alistair then defines the Crystal family of methodologies Clear, Yellow, Orange, and Red. Each one is better suited depending on the project needs.

Crystal is a family with genetic code:
1. Mindset: Not modeling, but cooperative game where people help each other to succeed. There are 2 goals: The primary is to delivers software, and the secondary is to setup for the next game. These two goals conflicting with each other.
2. Design priorities: Project safety (first and foremost), then development efficiency process habitability (tolerance). Will people use the suggestions.
3. Principles:
  • a. interactive face to face communication is most efficient,
  • b. methodology weight is costly,
  • c. use heavier methodology for large groups,
  • d. use more ceremony for more criticality,
  • e. use more feedback and communication instead with fewer intermediate deliverables
  • f. Discipline, skills, understanding counter process, formality, documentation
  • g. Efficiency is expendable at non bottleneck activities

4. Crystal’s Project Properties
  • a. Part of genetic code: Frequent delivery, close communication, reflective improvement.
  • b. Good ideas: Personal safety (freedom to speak without fear of reprisal), focus (knowing what to develop and having time for it), easy access to expert users, technical environment with frequent integration, automated testing, configuration management.
5. Starter Techniques:
  • a. Methodology shaping
  • b. Reflection workshop (2 columns 1st: keep these, problem areas, 2nd :try these)
  • c. Blitz planning
6. Crystal sample methodology: Crystal clear, Crystal orange

To get started with crystal, Alistair recommends finding your place on the project chart, picking a frequency of delivery, focusing on the top 3 properties, starting work, and every month doing a reflection workshop and deciding what to change.

Alistair concludes by mentioning that to know if you are doing Crystal look for close communication, see users every week, deliver software every 1 to 3 months, monitor project by quality of communication and moral of community, actively reflect on team quality and working habit.
This presentation is available on InfoQ at