Crystal Clear A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams

by Cockburn, Alistair

• ISBN13: 9780201699470
• ISBN10: 0201699478
• Edition: 1st
• Format: Paperback
• Copyright: 2004-10-19
• Publisher: Addison-Wesley Professional

Summary

Introducing Crystal Clear, a new agile method proven to increase worker productivity while helping organizations deliver better software.

Author Biography

Alistair Cockburn is a renowned software expert and accomplished instructor

Table of Contents

Preface	p. xiii
Explained (View from the Outside)	p. 1
Applied (The Seven Properties)	p. 17
Frequent Delivery	p. 19
Reflective Improvement	p. 22
Osmotic Communication	p. 24
Personal Safety	p. 29
Focus	p. 32
Easy Access to Expert Users	p. 34
Technical Environment with Automated Tests, Configuration Management, and Frequent Integration	p. 37
Evidence: Collaboration across Organizational Boundaries	p. 42
Reflection on the Properties	p. 43
In Practice (Strategies and Techniques)	p. 45
The Strategies	p. 45
Exploratory 360[degree]	p. 46
Early Victory	p. 48
Walking Skeleton	p. 49
Incremental Rearchitecture	p. 51
Information Radiators	p. 54
The Techniques	p. 59
Methodology Shaping	p. 60
Reflection Workshop	p. 65
Blitz Planning	p. 68
Delphi Estimation Using Expertise Rankings	p. 76
Daily Stand-up Meetings	p. 78
Essential Interaction Design	p. 79
Process Miniature	p. 91
Side-by-Side Programming	p. 92
Burn Charts	p. 94
Reflection about the Strategies and Techniques	p. 108
Explored (The Process)	p. 111
The Project Cycle	p. 117
The Delivery Cycle	p. 123
The Iteration Cycle	p. 126
The Integration Cycle	p. 130
The Week and the Day	p. 131
The Development Episode	p. 132
Reflection about the Process	p. 133
Examined (The Work Products)	p. 135
The Roles and Their Work Products	p. 138
Roles: Sponsor, Expert User, Lead Designer, Designer-Programmer, Business Expert, Coordinator, Tester, Writer	p. 140
A Note about the Project Samples	p. 144
Sponsor: Mission Statement with Trade-off Priorities	p. 146
Team: Team Structure and Conventions	p. 148
Team: Reflection Workshop Results	p. 151
Coordinator: Project Map, Release Plan, Project Status, Risk List, Iteration Plan and Status, Viewing Schedule	p. 153
Coordinator: Project Map	p. 154
Coordinator: Release Plan	p. 155
Coordinator: Project Status	p. 159
Coordinator: Risk List	p. 162
Coordinator: Iteration Plan to Iteration Status	p. 163
Coordinator: Viewing Schedule	p. 166
Business Expert and Expert User: Actor-Goal List	p. 167
Business Expert: Requirements File	p. 169
Business Expert and Expert User: Use Cases	p. 174
Expert User: User Role Model	p. 176
Designer-Programmers: Screen Drafts, System Architecture, Source Code, Common Domain Model, Design Sketches and Notes	p. 178
Designer-Programmer: Screen Drafts	p. 181
Lead Designers: System Architecture	p. 183
Designer-Programmer: Common Domain Model	p. 188
Designer-Programmer: Source Code and Delivery Package	p. 191
Designer-Programmer: Design Notes	p. 192
Designer-Programmer: Tests	p. 196
Tester: Bug Report	p. 199
Writer: Help Text, User Manual, and Training Manual	p. 201
Reflection about the Work Products	p. 202
Misunderstood (Common Mistakes)	p. 205
"We colocated and ran two-week iterations-why did we fail?"	p. 206
"Two developers are separated by a hallway and a locked door."	p. 208
"We have this big infrastructure to deliver first."	p. 209
"Our first delivery is a demo of the data tables."	p. 210
"No user is available, but we have a test engineer joining us next week."	p. 211
"One developer refuses to discuss his design or show his code to the rest."	p. 212
"The users want all of the function delivered to their desks at one time..."	p. 213
"We have some milestones less than a use case and some bigger."	p. 214
"We wrote down a basic concept and design of the system. We all sit together, so that should be good enough."	p. 215
"Who owns the code?"	p. 216
"Can we let our test engineer write our tests? How do we regression test the GUI?"	p. 217
"What is the optimal iteration length?"	p. 218
Questioned (Frequently Asked)	p. 221
What is the grounding for Crystal?	p. 223
What is the Crystal family?	p. 232
What kind of methodology description is this?	p. 235
What is the summary sheet for Crystal Clear?	p. 240
Why the different chapter formats?	p. 241
Where is Crystal Clear in the pantheon of methodologies?	p. 243
What about the CMM(I)?	p. 252
What about UML and architecture?	p. 256
Why aim only for the safety zone? Can't we do better?	p. 258
What about distributed teams?	p. 260
What about larger teams?	p. 262
What about fixed-price and fixed-scope projects?	p. 263
How can I rate how "agile" or how "crystal" we are?	p. 264
How do I get started?	p. 266
Tested (A Case Study)	p. 267
The Field Report	p. 269
The Auditor's Report	p. 293
Reflection on the Field and Audit Reports	p. 299
Distilled (The Short Version)	p. 303
References	p. 304
Index	p. 308
Table of Contents provided by Ingram. All Rights Reserved.

Excerpts

Crystal Clear: A Human-Powered Methodology for Small Teams Crystal Clear: A Human-Powered Methodology for Small Teams Preface Crystal Clear: A few key rules to get a small project into its safety zone. You have barely enough resources to get the system out. You don't want the team to write long documents, but they are forgetting things they are supposed to know about. You dislike heavy software development processes, but you want your team to work better than just randomly. You particularly want the software to come out the door successfully. You considered sitting down and writing out the basic discussions the team should have and the work products they must be careful to attend to. You asked yourself: What have other small, successful project teams done? What practices do they use? This book answers those questions. It is the result of ten years of debriefing successful small teams. Most of them repeated the same message: Seat people close together, communicating frequently and with goodwill. Get most of the bureaucracy out of their way and let them design. Get a real user directly involved. Have a good automated regression test suite available. Produce shippable functionality early and often. Do all that, and most of the process details will take care of themselves. This book sets out one of the most efficient and habitable methodologies you might hope to find: Crystal Clear. It is a human-poweredmethodology, most simply described as follows: The lead designer and two to seven other developers in a large room or adjacent rooms, with information radiators such as whiteboards and flip charts on the wall, having access to key users, distractions kept away, delivering running, tested, usable code every month or two (okay, three at the most), periodically reflecting and adjusting on their working style. This simple recommendation rests on both experience and theory. Software development can be characterized as an economically constrained cooperative gameof invention and communication.1The way the team plays each game has everything to do with the project's outcome and the resulting software. Crystal Clear tackles the economic-cooperative game directly, addressing where to pay attention, where to simplify, and how to vary the rules. A number of teams have shared with me--and now with you, through this book--examples of their rules, work products, and even office layouts. Many so-called "best" methodologies get rejected by a team as being too constraining, too invasive, or too difficult. Crystal Clear does not aspire to be a "best" methodology; it aspires to be "sufficient," in order that your team will shape it to itself and then actually use it. Origin of the Material in This Book The IBM Consulting Group asked me in 1991 to write a methodology for object--technology projects. Not knowing enough about methodologies at that time to make the crucial decisions, and at the suggestion of my boss, Kathy Ulisse,2I started interviewing project teams. What they told me was very different from what I had been reading in the books. In particular, they stressed aspects not covered in the methodology texts: close communication, morale, access to end users, and so on. It was not long before these issues separated in stark contrast the successful projects I visited from the failing ones. I came to see these issues, and not the design techniques, as the key to reaching a successful project outcome. I got to try these ideas out as lead consultant on a $15 million, fixed-price, fixed-scope project of forty-five people. The ideas worked as advertised (coupled with a lot of creativity along the way), and showed themselves as core success factors. I wrote up the lessons learned from the project interviews and that project in Surviving Object-Oriented Projects(Cockburn 1998).3 One particular triplet showed up repeatedly: colocation of the team, frequent delivery, and access to an expert user. The differences in results between projects that did and didn't do these far exceeded any other short list of practices. This book builds from that triplet. The projects in my career have generally been of the fixed-price, fixed-scope variety. People usually underbid on these projects, which means that the only way the team can deliver on time is by being very creative with their development process. Unlike most of the other authors of the Agile Development Manifesto, I came to the agile principles through the need for efficiency, not the need to handle rapidly changing requirements. As a result, Crystal Clear is well suited to the fixed-price context. If you are in such a situation, use the planning, communication, and reporting mechanisms I describe to meet your (probably unrealistic) deadline, and just be careful not to change the requirements at the start of every iteration. If you have an exploratory project in which the requirements are unknown or fluid, that is fine. Then allow the requirements to move at the start of each iteration. Crystal Clear in the Crystal Family Crystal is a family of methodologies with a common genetic code, one that emphasizes frequent delivery, close communication and reflective improvement. There is no oneCrystal methodology. There are different Crystal methodologies for different types of projects. Each project or organization uses the genetic code to generate new family members. The name "Crystal" comes from my characterization of projects along two dimensions, size and criticality, matching that of minerals, color and hardness (see Figure 7-1). Larger projects, which require more coordination and communication, map to darker colors(clear, yellow, orange, red, and so on). Projects for systems that can cause more damage need added hardnessin the methodology, as well as more validation and verification rules. A quartz methodology is suited to a few developers creating an invoicing system. The same team controlling the movement of boron rods in a nuclear reactor needs a diamond methodology--one calling for repeated checks on both the design and the implementation of their algorithms. I characterize Crystal methodologies by color, according to the number of people being coordinated: Clear is for collocated teams of 8 or fewer people, Yellow is for teams of 10-20 people, Orange is for 20-50 people, Red is for 50-100 people, and so on, through Maroon, Blue, and Violet. Crystal Orange is described in Surviving Object-Oriented Projects(Cockburn 1998), and its variant Crystal Orange/Web is described in Agile Software Development(Cockburn 2002) .I find that, except on life-critical projects, people can add in the verification activities through the methodology shaping and tuning workshops.4 Crystal's genetic code is made up of: The economic-cooperative game model Selected priorities Selected properties Selected principles Selected sample techniques Project examples The economic-cooperative game model says that software development is a series of "games" whose moves consist of nothing else besides inventing and communicating, which is typically resource limited. Each game in the series has two goals that compete for resources: to deliver the software in this game and to set up for the next game in the series. The game never repeats, so each project calls for strategies slightly different from all previous games. The economic-cooperative game model leads people on a project to think about their work in a very spec