UK Tester Forums

Crystal Clear Development Methodology
(The Short Version)

Crystal Clear is a highly optimised way to use a small, co-located team, prioritizing for effective, habitability, and safety in delivering a satisfactory outcome. The brief description of Crystal Clear for level-3 practitioners is just this:

The lead designer and two to seven other developers,
in a large room or adjacent rooms,
using information radiators such as white boards and flip charts,
having easy access to expert users,
distractions kept away;
deliver running, tested, usable code to the users,
every month or two (quarterly at worst),
reflecting and adjusting their working conventions periodically.

The team members establish the safety properties below using the techniques they consider appropriate. The first three properties are required in Crystal Clear; the next four get the team further into the safety zone.
1. Frequent Delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to Expert User
7. A Technical Environment and Automated Tests, Configuration Management, and Frequent Integration

Alistair Cockburn – A Human-Powered Methodology for Small Teams

Properties for Crystal Clear Development
Frequent Delivery
The single most important property of any project, large, small, agile or not, is that of delivering running, tested code to real users every few months.
• The sponsors get critical feedback on the rate of progress of the team.
• Users get the chance to discover whether their original request was for what they actually need and to get discoveries fed back into development
• Developers keep their focus, breaking deadlocks of indecision
• The team gets to debug their development and deployment processes and gets a morale boost through their accomplishments
Reflective Improvement
This can reverse the project fortunes from catastrophic failure to success if the team will get together, list what both is and isn’t working, discuss what might work better, and make those changes in the next iteration. In other words, reflect and improve. The team does not have to spend a great deal of time doing this work – an hour every few weeks or month will do. Just the fact of taking the time out of the helter-skelter of daily development to think about what could work better is already effective.
Osmotic Communication
This means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either ‘tune in’ or ‘tune out’, contributing to the discussion or continuing with their work.
Personal Safety
Personal safety is being able to speak when something is bothering you, without fear of reprisal. It may involve telling the manager that the schedule is unrealistic, a colleague that their design needs improvement, or even letting a colleague know that they need to take a shower more often. Personal safety is important, because with it the team can discover and repair its weakness. Without it, people won’t speak up, and the weakness will continue to damage the team.
Three particular exposures are relevant to software development:
 Revealing one’s ignorance
 Revealing a mistake
 Revealing one’s incapability on an assignment
Focus
Focus is first knowing what to work on, and then having time and peace of mind to work on it. Knowing what to work on comes from communication about a goal direction and priorities, typically from the executive sponsor. Time and peace of mind come from an environment where people are not taken away from their task to work on another, incompatible thing.

Easy Access to Expert Users
Continued access to expert user(s) provides a team with:
 A place to deploy and test the frequent deliveries
 Rapid feedback on the quality of their finished products
 Rapid feedback on their design decisions
 Up-to-date requirements
All very nice, but how many users and how much time?
Even one hour a week of access to a real and expert user is immensely valuable. The more hours each week that an expert user is available to a team, the more advantage they can take of that proximity. The first hour, however, is the most crucial.
Technical Environment – Automated Tests, Configuration and Integration

Thanks to Phil Kirkham for his time in reviewing this. Below I've copied in his comments and my replies.

Very nice work - here's a little bit of feedback for you

Thank you :-)

Tools - Fit/Fitnesse seems to be a major one in Agile

I was trying to avoid adding specific tool vendors. I see Fitnesse in the "Tools – Others – Test Management" category. Is that a fair assessment?

Others - What is Agile - you have it as "a team of specialists", not sure I'd agree with that shouldn't everyone be able - or trying to - pick up other peoples work ? See TestingReflections where Antony Marcano is arguing that the distinction between tester-dev-analyst is disappearing on Agile teams

I agree to some extent and I have seen good software created and tested in teams with no test expert support. However a good tester does not necessarily make a good developer (I can code but not well however I can define and execute testing very well). Likewise, developers do not necessary make good testers. My view is:
Developers are creatively constructive.
Testers are creatively destructive.
These are two different approach providing better coverage and better independence, hence improving the overall quality of the product.

Suitability of Agile - why only low criticality projects? why does it have to be senior developers - isn't agile a great opportunity for junior ones to learn due to pair programming?

Low criticality - Agile is very difficult, if not impossible (?) in safe critical systems. High levels of architecture design and build are required and is based on strong analysis is usually very comprehensive and accurate. Hence minimal or no requirements change during development and testing. Also see studies by Barry Boehm and Richard Turner (Balancing Agility and Discipline: A Guide for the Perplexed), who advise that the selection of Agile (adaptive) over Plan Driven (e.g. waterfall) be based on the criteria of risk.

As to senior developers - the principle is that you must have some highly experienced people. The more you dilute the experience by using junior developers, the more checks and balances you need to put into place.

Retrospectives - should this be under continuous self improvement ? or is it one of the main principles?

Good one. I revisited the principles and actually, what I’ve included in the mind map are the key elements of the principles. The Agile Manifesto site actually states 12 principles and I will change this section in the next version. This includes: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”, which should cover it.

hope some of this helps
Yes and thank you.