Core Crystal Elements
The core Crystal philosophy is:
Software development is usefully viewed as a cooperative game of invention and communication, with the primary goal of delivering useful, working software, and the secondary goal of setting up for the next game. Two consequences of that philosophy are that different projects need to be run differently, and the amount of modeling and communication that people need to do is just the amount they need to jointly move the game forward.
Members of the Crystal family share
Values and principles
On-the-fly tuning
Two values are that Crystal methodologies are intrinsically
People and communication centric High tolerance
The former means that tools, work products and processes are there only to support the human component. The latter recognizes varying human cultures. Within the tolerance of the Crystal family, though, the team can choose to work in a high-ceremony or high-discipline manner (adopting parts of PSP or XP, for example).
Seven principles were discussed in Chapter 4, "Methodologies." The principles are roughly summarized as follows:
The team can reduce intermediate work products as it produces running code more frequently, and as they use richer communication channels between people. Because every project is different and evolves over time, the set of conventions the team adopts, must also be shaped and evolve. The shifting bottlenecks in the system determine the use of overlapped work and stick information holders.
The two rules common to the Crystal family are: The project must use incremental development, with increments of four months or less (with strong preference to one- to three-month increments). The team must hold pre- and post-increment reflection workshops (with strong preference to also hold mid-increment reflection workshops).
The two base techniques in Crystal are: The methodology tuning technique: using project interviews and a team workshop to convert a Crystal Clear is a methodology for D6-category projects. You should be able to stretch Crystal Clear to an E8 or D10 category project with some attention to communication and testing, respectively. I expect it to be difficult to extend beyond that, since Crystal Clear contains no communication structure for more people than can conveniently work in the same room, and lacks the system validation elements needed for life-critical systems.
Brief Description of Crystal Clear
There is only one team, seated in one or adjoining offices.
The roles needing separate people are: Sponsor, Senior Designer-Programmer, Designer-Programmer, User (part-time at least)
One of those people may pick up the assignment of being Project Coordinator. Some one will be the base methodology to a starter methodology for the project. The technique used to hold the reflection workshop.
You are welcome to replace those two techniques with others, if you have another way of acoomplishing their goals.
Attending to the above issues creates something that has a particular feeling. As someone wrote, it is possible to make another methodology look like a Crystal project, without making it feel like a Crystal project. A visitor to a successful Crystal project will notice communications and community in action, pragmatism in reaching the two goals of the game.
The following three sections describe the three Crystal methodologies I have so far constructed and seen used.
The structural differences between them are obvious. See if you can spot the commonalities.
Clear
Business Expert, and either one or many people will share the role of Requirements Gatherer.
The Senior Designer-Programmer is the key person on the team. The other Designer-Programmers may be at some mixture of novice and medium levels as the Senior Designer-Programmer and the problem can support. Hiring people who know their jobs of course helps.
The policy standards are that Software is delivered incrementally and regularly, every 2-3 months. Progress is tracked by milestones consisting of software deliveries or major decisions, as opposed to written documents. There is some amount of automated regression testing of application function. There is direct user involvement. There are two user viewings per release. Downstream activities start as soon as upstream is "stable enough to review".
Product and methodology tuning workshops are held at the start and middle of each increment.
The policy standards are mandatory, but equivalent substitution is permitted, as would be the case if Scrum work scheduling (Schwaber 2001), XP, or Adaptive Software Development (Highsmith 1999) policies were used.
The work products that are produced include: Release sequence
Schedule of user viewings and deliveries Annotated use cases or feature descriptions Design sketches & notes as needed Screen drafts A common object model Running code Migration code Test cases User manual
The following are left as "local matters," to be set and maintained by the team: Templates for the work products Standards for coding and user interface Standards and details of regression testing
Crystal Clear does require project documentation to be created. Just what that documentation consists of is not spelled out by Crystal. That is left as a matter of local judgement. The combined team must decide how to present their design notes to future team members.
The most important tools the team can own, besides a compiler are:
A versioning and configuration management system A printing whiteboard.
You should be able to cost-justify several printiing whiteboards on any project, based on just the time people save typing design documents and meeting
Crystal
Crystal Orange is a methodology for D40 category projects: up to 40 people, sitting in one building, working on a system that might cause loss of discretionary moneys, summaries, and lost communications cost when people do not copy down whiteboard contents.
The techniques used by the individual roles are left entirely to the discretion of the individuals.
Substitution of elements from from similar methodologies is permitted. For example, the team could decide to Scrum or DSDM's timeboxing and dynamic prioritization policies, Scrum's daily stand-up meetings, pair programming from XP, and so on.
Reflection on Crystal Clear
Crystal Clear is the most tolerant, low-ceremony small-team methodology that I can find that still works.
It contains those elements claimed by my interviewees to be the cause of their success: Focus on close seating and close communication Frequent delivery Information from real users Code versioning tools.
The printing whiteboard has proven more valuable than any of its higher-tech replacements, with the possible exception of the newest generation whiteboard capture software (see Pixid URL). People usually start a discussion thinking it won't be worthwhile recording. They discover after their discussion that it would be good to have a record of.
Crystal Clear provides a place to fall back to if you try and give up on XP. Any part of XP can be substituted for Clear, since XP meets all Crystal Clear standards except for documentation. If you move from XP to Crystal Clear, you will have to add documentation. I don't think you can get any sloppier than Crystal and still plan on having better-than-even odds of completing successfully.
Orange
Crystal Clear calls out more team structures and more team coordination than is needed on a 20-person project. It is lacking in the subteaming structures that are needed on an 80-person project, and it is missing design- and code verification activities as would be used on life-critical systems.
Crystal Orange receives given 18 pages of description in Surviving Object-Oriented Projects (Cockburn 1998). It is characterized there as "for a medium-sized production project in an industrial setting. The characteristic of such are project are:
* 10 to 40 people total.
* 1 to 2 years duration.
* Time-to-market is important.