Crystal Clear Methodology

The CrystalClearMethodology is for 2-8 person projects, it attempts to describe a full methodology of the lightest, most habitable kind that will still produce good results. (see also MaximalistMethodology). It is prioritized for project safety (delivering a system in adequate time / budget per the sponsor's priorities) and for that to be effective and habitable (meaning the people can live with it and will actually use it). It emphasizes:

First documented in a book draft in 1998, the book is finally out! (Details here: CrystalClear). There is some discussion of the CrystalClearMethodology in pages at ( is no longer working). A yahoo eGroup has been started for discussion of the methodology and book at

For links to other descriptions of Crystal Clear, see
The difference between CrystalClear and XP: This inevitable question occupies most of this page.

The difference between CrystalClear and ExtremeProgramming is that XP is much more disciplined, CrystalClear is much more tolerant, even sloppy-looking. I would say XP is more productive, CrystalClear more likely to get followed. -- AlistairCockburn

I have read through the (1999) Crystal Clear description again. I had done so about a year ago and found it easier to read this time. I don't know what has changed but it seems much better. (Thanks. I haven't changed anything in the last year. I suspect you got better at understanding my writing over the course of a year.)

You say that ExtremeProgramming would simply be a version of CrystalClearMethodology if only it produced a few more work products. I wasn't able to tell which were missing; can you tell us flat out which are missing? -- DonWells

Don, That is an interesting sentiment to take out of the book. I find it hard to believe I would write that XP would "simply" be a Clear "if only" it produced a few more work products! Can you say where you found that, so I can fix it? What I find in the book are the following two paragraphs, which imply something quite different:
CC's work products.

Some people like to evaluate a methodology by counting the work products produced. There is disagreement as to whether the number should count for or against the methodology. You will find both on this page. Recognizing that a list of work products may not be the way to evaluate a methodology, here they are nonetheless.

The (producer) work products list of Crystal Clear are:
Re: risk list not in XP: WhatIsTheWaterStrategyOfaFish

The fish won't detect if the water supply is drying up. A risk list should include that.

I don't understand the above statement in this context. It seems to me that, to be in keeping with the analogy being drawn by WhatIsTheWaterStrategyOfaFish, it should be saying "How does XP deal with the possibility that risk will go away?" and I don't think that's a very important thing to consider. Am I just befuddled as normal? -- BrettNeumeier

I think you're taking the analogy too literally. A better summary would be "How does XP [or the fish] deal with the current status of the risk [or water] becoming life-threatening?"
Tolerance versus Discipline:

I was reading the draft since I didn't want my view of flexible processes to be entirely skewed by ExtremeProgramming (though it already is). It is interesting how you push tolerance on the techniques that are used while ExtremeProgramming is quite adamant about its practices being important. I'll admit that I'm leaning toward the XP side. The idea behind being tolerant of techniques comes from acknowledging that people have different strengths and weaknesses and think differently. The idea behind being "intolerant" about *certain* techniques is the belief that some ways are simply more effective for everyone.

I think the main point is whether tolerance should be applied to all techniques or whether there is a core BestPractice that everyone should do (or at least try to do) no matter who they are. -- JasonYip

Go right ahead and stick with XP. It'll be good for you. If you find your group can't or won't follow it, you can join the majority of the world and drop back to Clear.

Kent turned all the good knobs to 10, as he said, and all the bad knobs to 0. That was and is great. People are remarkably resistant to good things, though. Do you floss your teeth every night? keep away from sweets, exercise 20 minutes 3 times a week, change your car's oil every 2,000 miles, remove the dust from your refrigerator's cooling coils, and all the other things that we know are good? If not, you are in the majority.

I'm actually trying to floss every night though it's a bit sporadic. Don't tend to eat many sweets anyway. Kung Fu twice a week for 1-2 hours. Was 3 times a week but I have schedule conflicts right now. Don't do the oil changing or dust removing though... -- JasonYip

Clear is for the majority. Anyone who can step up to XP can benefit from doing so, and I won't say anything bad about XP except that I predict it will be hard to get people to actually use. I think the discussions on wiki over the last several years bear this out. Clear comes mostly from my interviews with successful 3-6 person project teams, writing down what those people did. Tolerance was in there.

Personally I think Clear is already hard enough, and am looking at what I can take out to make it easier. Access to a user, automated regression test suite, and (surprisingly) proximate seating seem to be stumbling blocks for several of the projects I have talked to.

I am after the most tolerance that will still let the project deliver. Kent is after the fastest, best set of integrated practices (reminds me of a a family sedan vs a high-performance car). Note that his next book's byline is "Playing to win". My book was titled "Surviving OO Projects". It is perhaps depressing, but most places I visit are lucky or happy just to get their software delivered.

Clear permits use of XP as part of its tolerances so you can start with Clear, and move up and down to XP. The opposite won't work - you can't stick tolerance into XP. -- AlistairCockburn
The comment about flossing got me thinking. Not many people floss every night but I have yet to meet the dentist that doesn't tell me to floss. I would think there was a time when not everyone brushed too so I'm not sure if it's the right approach to be tolerant about flossing.

On the other hand, it would be preferable for people to at least brush even if they just aren't disciplined enough to floss. In other words, "let's just make sure your teeth don't fall out when you're 30 before we worry about when you're 80". I think this is your point of view? -- JasonYip

(p.s. I just learned from my dentist that the anaerobic bacteria take 3 months to build up. In other words, if you floss 3 times a week, that's probably good enough, and you could actually go and get a deep cleaning every other month and be fine! So what is happening is that the dentists can't get you to floss weekly, so they tell you to floss daily, or even after every meal, in the hopes that you'll floss at least weekly! arghh! I'd much prefer to have been told the real truth up front.)

Approximately right (who knows what completely right is?). I used to be a "minimalist", but am now a "maximalist", ever since a friend reoriented my head. Maximal effect for a certain energy output. If I can keep my teeth in my head without flossing every day - say, flossing 3 times a week - I'll prefer that. I'm as lazy as the next person, and equally resistant to good advice. Here it is Jan 31, and I'm doing last year's accounting because I didn't do it on an as-you-go basis last year. Why am I so dumb/lazy/resistant? I teach my kids to do their homework early so they won't have a last minute cram - not that they follow my advice anyway. Why are people like this? I don't know, but we can pretty much count on them to be that way.

Hard work may pay off tomorrow - but laziness always pays off RIGHT NOW.

In the light of that, start asking people to develop software the "best" way. Good luck. As a maximalist, I'm asking, what's the maximum effect we can get from the limited amount of energy and discipline people have? The result looks something like Crystal.

People with more discipline can do better, of course. Disciplined adherence to effective practices is more effective than sporadic use of effective practices. Your mileage will vary, of course. -- AlistairCockburn

You wrote you can't stick tolerance into XP. -- AlistairCockburn I am not convinced that this is true. Clearly stated rules and a lack of tolerance are not synonymous.

Generally speaking at any given moment on an XP project most of the team is following most of the rules, but not all. This does not seem to be a problem so long as we, as coaches, don't out right say "go ahead and break the rules". That is not the same as intolerance. It is working with people's faults and aiming a bit high so that we will hit the bull's eye.

The key question is how long can we ignore the rules and do as we please and the project will not suffer. I am not sure how long that would be for CrystalClear, if the answer were a very long time, I would be surprised. I apologize for not having reread CrystalClear in the recent past. Perhaps you can talk further about how crystal keeps deviations from going too far while being tolerant of them? -- DonWells

It sounds like you are setting up a straw man, fishing for an ad for a methodology in which it doesn't matter what the people do, the methodology will protect them. Neither you nor I believe such a methodology exists. What people do, matters. -- AlistairCockburn
Alistair, I've been reading some of the material about Crystal Clear from your web site. It's very interesting, and informative, especially how its based on such extensive study of actual project teams. I have one question. You wrote: "Extreme Programming is one of the very few to push against both of the known other extremes - heavyweight methodologies and cowboy programmers. Prior to XP, there was really no way to talk about avoiding solo, wild programmers and poor designer / documenters without introducing heaviness into the methodology.". If a team chooses not to use XP, but goes for another lightweight methodology such as Crystal Clear, is there anything that can be done to avoid solo, wild programmers and poor designer/documenters? (Other than, "don't hire then in the first place".) -- JohnRusk

Interesting question . . . Currently I'm seeing that (e.g. 1-month) timeboxes are being used to some effect like that, in projects using Scrum. Apparently the need to deliver code regularly has some effect on people arguing, designing, getting into ruts, and the like. And the ReflectionWorkshop helps in airing some of the issues publicly, so some designers can exert peer pressure on the others. That's all I've got in this particular bag, though . . . -- AlistairCockburn

Can you use two methods/processes together to fix some of these problems. For example, use Scrum with Clear to benefit from the advantages of both, while using them to balance out the weaknesses in each other? C. Workman
Thanks, I can see how those things could help. I guess that, along the lines of what you wrote in CanAnArchitectureEmerge, it also helps if the team shares a common definition of what "good" design/code actually is.

There's also the idea of code review etc, but I feel that it's usually too late by that time. If a particular design has been implemented, tested etc, then many people will be reluctant to change it afterwards, just because a review points to a "better" way. Have you seen any successful uses of preview rather than review? I.e. designer/developers discussing their intentions before cutting (significant amounts of) code to get feedback before they start. -- JohnRusk

Sure ... this is called ThreePeopleAtaWhiteboard? :-) Is used all the time. Also the idea behind CRC card design. It works really really well, because there is critique before much energy is expended or ego attachment. If your group isn't already doing it, that may indicate too much stove-pipe activity, people not yet speaking to each other and trading notes.

One way we got past that in one project was that we had a big room, and I just started doing all my design discussions at the whiteboard. People became used to hearing and speaking design. After a few months, the others were also doing it. -- AlistairCockburn
Alistair, do you think that Crystal Clear could be used where the developers are all in the same room, but the users are in a different city? I've checked the latest draft of your Crystal Clear book (which is looking real good by the way) and it's not 100% clear to me whether you suggest that users must physically visit the development team, or whether "virtual" visits would be OK.

(Sure, this happens all the time. If there were one geographic split I'd have to set on a team, this is the one. This split is the one that allows successful off-site, even off-shore development. To do CrystalClear, you still have to find a way to get EasyAccessToExpertUsers?, of course. -- AlistairCockburn)
Going back to the Preview instead of Review: my team has a daily StandUpMeeting where we all turn around, stand up and tell the group what we did the day before and what we are going to do today, there are 7 or 8 of us who usually 'attend' and we never go over 15 minutes. Any ancillary discussions that crop up, either of the "you can't do that" or "I have an idea as to how to do that" types, are separated out so that only the people who are affected have their time used up.

(The daily StandUpMeeting comes from the ScrumMethodology, AFAIK, and is a simple, easy and effective mix-in to almost any project and methodology. Highly recommended. Fits very neatly with CrystalClear, of course)
It's hard not to be skeptical of a methodology with a name like "crystal clear". It smells like something marketers would conjure up. Might as well go all the way: "Happy Rainbow Big Raise Methodology".

It is of course much easier to simply not investigate. Then one can throw stones from a safe distance and stay skeptical.

Oh? And have you "investigated" some of the links? Lots of people trying to sell lots of books, but little in the way of detailed explanations regarding this "methodology." I personally prefer Happy Rainbow Big Raise, myself. Used it extensively on the last job I was fired from.
CategoryAgileMethodology, CategoryMethodology

View edit of September 5, 2011 or FindPage with title or text search