Alistair Cockburn - Agile Software Development

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.

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

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 cantains a Business Analyst-Designer, a UI Designer, and one to three Designer-Programmers. Each group also contains a database designer and reprentatives of other technologies if several technologies were 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 evauated 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 on 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

Crystal Orange / Web is a methodology we created for eBucks.com, a company delivering their code to the web in a continual stream. It differs from Crystal Orange in that this methodology does not deal with a single project, but with a continuous stream of initiatives requiring programming, each initiative's results being merged with the growing code base being used by the public.

This methodology is still in its trial run. I include it here because An increasing number of companies are finding

themselves in this sort of situation. It represents the most recent application of the ideas in

this book. It has a it a different shape than Crystal Orange.

The eBucks.com situation was interesting for a second reason (the first being the continuous and criss-crossing web of demands from different customer groups). The company had already established a web presence. They were no longer driven by time-to-market pressures, but were moving into one governed by the cost of defects. Customer calls, arriving in exponentially increasing volumes, could easily negate their profit margins. Thus, they 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,.

While 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 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 were shifting from productivity to defect freedom as their top priority.

There were about 50 people to coordinate in this situation, executives, business people, managers, analysts, programmers, testers. I classified this as an E50 situation.

The group was relatively new, so some process definition was needed to make clear who made which decisions, and who handed what information to whom. Otherwise, people generally knew who they had to talk to in order to get their job done.

I performed interviews, as called for in the methodology tuning technique. I interviewed people in each job role, from marketing through testing and system operations.The interviews revealed that: Convection currents of information were quite good.