Crystal Orange


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 monies.

Crystal Orange 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 is given 18 pages of description in Surviving Object-Oriented Projects (Cockburn 1998). It is characterized there as being useful "for a medium-sized production project in an industrial setting. The characteristics of such a project are:

  • It is staffed by 10 to 40 people total.

  • It is of 1 to 2 years in duration.

  • Time-to-market is important.

  • There is a need to communicate with present and future staff, and a need to keep time and costs down.

  • It is not a life-critical system.

"It is a common sort of project, requiring trade-offs between complete, extensive deliverables and rapid change in requirements and design. I have kept the number of deliverables low, to reduce the cost of maintaining them, yet included enough to keep the teams communicating. I tailored job assignments and teams to allow the fluidity usually needed on this kind of project. Many other sorts of projects also need provisions for fluidity and can take advantage of this methodology."

Recalling that lighter is better as long as it lasts, a team on an E50 type of project might extend Crystal Orange with some additional verification-testing elements rather than shift to a Red methodology targeted at 80 people.

Brief Description of Crystal Orange

The roles on the project include

  • Sponsor

  • Business expert

  • Usage expert

  • Technical facilitator

  • Business analyst/designer

  • Project manager

  • Architect

  • Design mentor

  • Lead designer-programmer

  • Other designer-programmers

  • UI designer

  • Reuse point

  • Writer

  • Tester

They are arranged in several teams:

  • System planning

  • Project monitoring

  • Architecture

  • Technology

  • Functions

  • Infrastructure

  • External test

The larger functional team is split into cross-functional groups using the Holistic Diversity strategy (Cockburn 1998). Each such group contains a business analyst-designer, a UI designer, and one to three designer-programmers. Each group also contains a database designer and representatives of other technologies if several technologies are in use on the project. Each group may have a tester.

The structure of the teams has to be adjusted to account for possible shortages of certain specialists. The point of having a cross-functional group is to reduce deliverables and to enhance local communication. The people are evaluated as a single group so that each sees a purpose to contributing wherever he is needed, not just in his job description.

The work products include

  • Requirements document

  • Release sequence

  • Schedule

  • Status reports

  • UI design document

  • Common object model

  • Inter-team specs

  • User manual

  • Source code

  • Test cases

  • Migration code

Each work product is developed until it is understandable by colleagues, to a level of precision and stability that permits peer review.

The policy standards are identical to those of Crystal Clear, except that the incremental delivery period may be extended to three or four months.

As with Crystal Clear, the policy standards are mandatory, but equivalent substitution is permitted, as would be the case if Scrum, XP, or Adaptive Software Development policies were used.

Work product templates, coding style, user interface standards, and details of regression testing are left as local standards to be set and maintained by the team. The techniques used by the individual roles are left entirely to the discretion of the individuals.

Reflection About Crystal Orange

Crystal Orange is not a structure to impose on a group of only 10 people. It is much too heavy. However, for 40 people working in three or four technologies, it is very light. It is held together by close communication within the Holistic Diversity functional groups and the frequent viewings by the users.

This methodology has been used successfully. That experience is described in the project Winifred report in Surviving Object-Oriented Projects (Cockburn 1998).

Although I would use the basics of the methodology again gladly, technology has shifted so that the specialists who show up on the project are different today than they were then, and their work products and needs for interaction are different. Also, the bottlenecks on the next project will probably be different than they were on project Winifred.

On a new project, I would use Crystal Orange as a base methodology and shape it using the methodology-tuning technique described earlier.



Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net