* 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.
Everyone was on one floor. The had movable glass and whiteboard partitions as walls, so they could see and signal to each other, while still keeping some privacy. Ongoing distractions were keeping people from having the quiet time they needed to make progress on their assignments (in all job roles).
Each person was working on multiple initiatives, with frequent interruptions.
Crystal Orange / Web
Attitude, amicability and morale were still quite good, but sinking because of the frequent interruptions and lack of progress. Also, the programmers sat on one side of the building, while the business specialists sat on the other. This meant that the chit-chat in each group drove negative commentary about the other group.
The company was less than a year old, meaning that old habits had not yet set in, so people were open to inventing new work habits and conventions. In keeping with the idea that a methodology is the set of conventions the group agrees to, we wrote the methodology as a set of conventions, in five categories. Here they are:
1. Regular Heartbeat, with Learning
The purpose of this category is establish a core procedure for getting feedback on "how we work around here" and taking the time to reflect and improve on that. Every convention except the post-cycle reflection workshop can be altered as an outcome of the reflection workshops.
2-week development cycles. Overall production runs in fixed-length development cycles of two weeks. After each delivery, each team may opt for their next delivery to be either two or four weeks, depending on what they can deliver of use to the public. Each team must deliver something useful to the public every four weeks.
Post-cycle reflection workshop, suggestions visibly posted. At the end of every cycle, the company meets to discuss what worked well, what didn't work so well, and what ideas to try out on the next cycle. The outcome of the meeting is a posted list of things to keep.
2. Basic Process
The purpose of this category is to organize who creates which pieces of work and who makes which decisions, in order to avoid duplication or gaps in the effort, and to look far enough ahead to spot potential troubles early. The process aims for delivery of business initiatives live to the web.
A business owner writes a business use case and a system use case brief (Cockburn 2001). The business use case illustrates the proposed new system features in operation, paying particularly close attention to the manual business processes that get invoked when things go wrong.
The brief is used by the technology group to estimate the work involved in creating the features. The business executives review the business use case, technology estimate and value of the initiative before agreeing to further work. The user interface designers work with marketing and the detail business analysts to incorporate the features into the overall site flow, and then produce screen designs and the XML for the screens.
The detail business analysts produce detailed use cases and data descriptions, which go to the user interface designers, the server programmers and the servlet programmers. The servlet programmers work from the XML for the user interface, the use cases, the data descriptions and the server interfaces, producing the servlets. The server and servlet programmers produce regression tests for their code, peer-review the test cases. When the test cases are deemed good and the code passes the tests, the code is passed to the integration testers, who perster the developers to fix whatever remaining errors they find before the major deployment.
The integration testers post the changes going out in the new release to the internal group and also to the call center.
For live code, the call center returns bug reports to a special SWAT team whose sole purpose is to fix problems in production. The SWAT team is selected from the development group on a rotating basis every two cycles.