©Alistair Cockburn Slide 1 The Crystal Approach to Developing Software Alistair Cockburn The Crystal Approach to Developing Software

©Alistair Cockburn Slide 2 Elements to understanding the Crystal family of methodologies Software development as a cooperative game Economics of communication Crystal’s “DNA” Reflection technique 7 properties of successful projects Role of a project manager 2D project grid Methodologies as transient Incremental development 10 critical success factors Burn-up charts People as key ingredients

©Alistair Cockburn Slide 3 10 Critical Success Factors

©Alistair Cockburn Slide 4 History : Alistair Cockburn told to develop an effective software development methodology.  interviewed and studied project teams for 10 years.  found that “people-centric methodologies” do better than “process-centric” methodologies.  found that you must choose and tailor the methodology to the team and the assignment (no methodology fits all projects). 1994: “Orange” used on 45-person fixed-price project 1997: “Orange” published in Surviving OO Projects 1998: Family of methodologies the name “Crystal” 2004: Crystal Clear published as book

©Alistair Cockburn Slide 5 What were the most common characteristics of successful projects? People sit close together They communicate frequently and with good will The eliminate bureaucracy and let them design They get a real user directly involved They have good automated regression tests THey produce shippable functionality early and often A good methodology (family) must prioritize for these!

©Alistair Cockburn Slide 6 10 Critical Success Factors Community (communication, amicability) Focus (known priorities, focus time) Nourishment from Executive Sponsors (decisions, money) People (abilities, motivation) Incremental development & Reflection

©Alistair Cockburn Slide 7 Role of the Project Manager on modern projects: Pull in support, motivate team, block interrupts. Sponsor(s) Visibility Decisions $ Interruptions X PM developers Communication Amicability Priorities Focus time Skills development Motivation Reflection Community (communication, amicability) Focus (known priorities, focus time) Nourishment from Executive Sponsors (decisions, money) People (abilities, motivation) Incremental development & Reflection

©Alistair Cockburn Slide 8 7 Properties of Successful Projects

©Alistair Cockburn Slide 9 7 Properties of Successful Projects 1Frequent Delivery 2 Osmotic Communication 3 Reflective Improvement 4 Personal Safety 5 Focus 6 Easy Access to Expert Users 7 Technical Environment with - Frequent integration - Automated testing - Configuration management Core properties of “Crystal” Properties increasing project safety (rubustness to adverse events)

©Alistair Cockburn Slide 10 Frequent Delivery Have you delivered running, tested, usable functions to your user community at least twice in the last six months?

©Alistair Cockburn Slide 11 Reflective Improvement Did you get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss your group's working habits, and discover what speeds you up, what slows you down, and what you might be able to improve?

©Alistair Cockburn Slide 12 Osmotic Communication Does it take you 30 seconds or less to get your question to the eyes or ears of the person who might have the answer? Do you overhear something relevant from a conversation among other team members at least every few days?

©Alistair Cockburn Slide 13 Personal Safety Can you tell your boss you mis-estimated by more than 50 percent, or that you just received a tempting job offer? Can you disagree with him or her about the schedule in a team meeting? Can people end long debates about each other’s designs with friendly disagreement?

©Alistair Cockburn Slide 14 Focus Do all the people know what their top two priority items to work on are? Are they guaranteed at least two days in a row and two uninterrupted hours each day to work on them?

©Alistair Cockburn Slide 15 Easy Access to Expert Users Does it take less than three days, on the average, from when you come up with a question about system usage to when an expert user answers the question? Can you get the answer in a few hours?

©Alistair Cockburn Slide 16 Technical Environment with Automated Tests, Configuration Management, and Frequent Integration Can you run the system tests to completion without having to be physically present? Do all your developers check their code into the configuration management system? Do they put in a useful note about it as they check it in? Is the system integrated at least twice a week?

©Alistair Cockburn Slide 17 Software Development as a Cooperative Game

©Alistair Cockburn Slide 18 Cockburn 1998: Making software consists only of making ideas concrete in an economic context: People inventing and communicating, solving a problem they don't yet understand (which keeps changing), Creating a solution they don't really understand (and which keeps changing), Expressing ideas in restricted languages they don’t really understand, (and which keep changing) To an interpreter unforgiving of error. Resources are limited, and every choice has economic consequences. It is a cooperative game of invention and communication

©Alistair Cockburn Slide 19 Software development is a Cooperative Game of Invention and Communication. To understand team software development: Understand goal-directed cooperative games Understand people communicating Understand people inventing Understand people cooperating Notes on Cooperative Game: Two goals: Primary Goal  Deliver this software Secondary Goal  Set up for the next game Two conflicting games in one Net result: Not repeatable !

©Alistair Cockburn Slide 20 Infinite Organization Survival Career Management Games, finite/infinite or cooperative/competitive, consist of better/worse ‘moves’ Competitive Cooperative Finite w/ no fixed end Jazz music King-of-the-hill wrestling Finite & goal-directed Tennis Software Developmen t Poker Rock-Climbing

©Alistair Cockburn Slide 21 Every game run uses different strategies -- Set up each project suitably or suffer Number of people coordinated Comfort Essential moneys Life ,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Discretionary moneys “Criticality” X X X

©Alistair Cockburn Slide 22 Musashi 1685: swordfighting - discuss how this relates to programming - 1 The field is particularly rife with flambouyant showmanship, commercial popularization and profiteering... dressing up and showing off. 2 One can win with the long sword, and one can win with the short sword. Whatever the weapon, there is a time and situation in which it is appropriate. 3 In my school, even unreasonable ideas are given full consideration; the heart of the matter is to use the power of knowledge of martial arts to gain victory any way you can. 4 You should observe reflectively, with overall awareness of the large picture as well as precise attention to small details... 5 If your sword misses the opponent, leave it there for the moment, until the opponent strikes again, whereupon strike from below 6 Where you hold your sword depends on your relationship to the opponent, on the place, and must conform to the situation; 7 wherever you hold it, the idea is to hold it so that it will be easy to kill the opponent. 8 Whatever guard you adopt, think of it as part of the act of killing. 9 The views of each school, and the logic of each path, are realized different, according to the individual person, depending on the mentality...

©Alistair Cockburn Slide 23 Naur 1986: The primary result of programming is the theory held by the programmers 1. Theory: The knowledge a person must have to do certain things intelligently, explain, answer queries, argue about them The programmer must Build a Theory of how certain affairs of the world will be handled by a program; Explain how the affairs of the world are mapped into the program and documentation; Respond to demands for modifications, perceiving the similarity of the new demand with the facilities built. This knowledge transcends that possible in documentation. 3. This theory is the mental possession of a programmer; the notion of programmer as an easily replaceable component in program production has to be abandoned.

©Alistair Cockburn Slide 24 Naur 1986: Modifying a program depends on the new programmers building the same theory ! 4. Problems of program modification arise from assuming that programming consists of text production, instead of theory building. 5. The decay of a program from modifications made by pro- grammers without proper grasp of the underlying theory becomes understandable. The need for direct participation of persons who possess the appropriate insight becomes evident. For a program to retain its quality it is mandatory that each modification is firmly grounded in its theory. 6. The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaption, modification, and correction, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them.

©Alistair Cockburn Slide 25 Naur : Programming as Theory Building (Case Studies) A program of 200,000 lines... The installation programmers have been closely concerned with the system as a full time occupation over a period of several years, from the time the system was under design. When diagnosing a fault they rely almost exclusively on their ready knowledge of the system and the annotated program text, and are unable to conceive of any kind of additional documentation that would be useful to them. Other groups, who received documentation and guidance from the producer's staff, regularly encounter difficulties that upon consultation with the installation programmers are traced to inadequate understanding of the documentation, but which can be cleared up easily by the installation programmers. A compiler extension... Group B’s solutions were found by group A to make no use of the facilities that were inherent in the existing compiler and were discussed at length in its documentation; based instead on patches that effectively destroyed its power and simplicity. Group A members were able to spot these instantly and could propose simple, effective solutions, framed within the existing structure. This is an example of how the program text and additional documentation is insufficient in conveying to even the highly motivated group B the deeper insight into the design, that theory which is immediately present to the members of group A.

©Alistair Cockburn Slide 26 Our perceptions lie to us; our memory lies to us; We all parse experience differently. (wine bottle) This figure is built from which of the figures on the right?

©Alistair Cockburn Slide 27 P erfect communication is impossible You try to communicate what you “know” What you “know” depends on your individualized parsing of the world around you; You don’t know what it is you do know; You don’t know the thing you are trying to communicate; You don’t know what you are actually communicating; Your listener sees only a part of what you are saying; What your listener learns depends on his/her internal state. (How is it we communicate at all?)

©Alistair Cockburn Slide 28 COMMUNICATION is touching into shared experience Linked sequences of shared experience becomes a shared experience  Project colleagues have rich shared experiences, a shortcut vocabulary Implications for documentation:  can never fully specify requirements  can never fully document design  must assume reader’s experiences more => can write less less => must write more. Our task is to manage the incompleteness of communications the program “theory” design patterns UML source code

©Alistair Cockburn Slide 29 Face-to-face allows vocal, subvocal, gestural information to flow, with fast feedback Richness of communication channel Communication Effectiveness 2 people at whiteboard 2 people on phone 2 people on chat Videotape Paper Audiotape (No Question-Answer) (Question-and-Answer) (Courtesy of Thoughtworks, inc.) coolerwarmer

©Alistair Cockburn Slide 30 Experience incommunicability and elementary Agile techniques for yourselves Divide each into Specifiers and Artists. The Specifiers will ask the Artists to draw a drawing for them.

©Alistair Cockburn Slide 31 Draw a Drawing 1st round minutes 1. Specifiers and Artists move to opposite ends of the room. (this corresponds to distributed virtual teams) 2. Specifiers WRITE instructions to their Artists on what to do (no drawings allowed). One Specifier carries messages back and forth, can watch but NOT speak at Artist side. 4. Artists may write messages back. 5. NO SMS or MMS. 6. NO speaking or drawing between Specifiers and Artists.

©Alistair Cockburn Slide 32 Reflection technique: Write in this chart. What worked? What might you try next time? (this is a core technique you should use every month on every project !) Try TheseKeep These Ongoing Problems

©Alistair Cockburn Slide 33 PAUSE 5 MINUTES 1. Pause. Most teams do not create a way to change process “on the fly”. We need a way to evolve the process. 2. Discuss and reflect: what went good and bad. 3. Adjust your strategy for the next round. 4. Use the reflection technique & chart. (this corresponds to “iterative development” with process feedback.)

©Alistair Cockburn Slide 34 Draw a Drawing 2nd round -- 5 minutes 1. As before, but use incremental technique: 2. Specifiers describe only ONE shape. (Advanced teams: two people one shape each.) 3. After Artists have drawn the shape, they send it (or copy) to the Specifiers to see. 4. Specifiers can decide whether to correct that shape, or go on with the next shape. (this corresponds to “incremental delivery” with product feedback.)

©Alistair Cockburn Slide 35 PAUSE 5 MINUTES 1. Assume only 1 Specifier on next drawing (everyone else is an Artist). 2. Strategize on the Best way to work (including sitting together, talking in person).

©Alistair Cockburn Slide 36 Draw a Drawing 3rd round -- 5 minutes 1. Specifier from each team comes and looks at drawing, puts into her/his memory. 2. Specifier, WITHOUT DRAWING ANYTHING, communicates it as well as possible to rest of team. (this corresponds to Customer attempting to describe needed product to development team)

©Alistair Cockburn Slide 37 End. You have just seen a cooperative game of invention & communication in action. 8 things you may have observed: Distance hurts. (So DON’T DO IT !) Sitting together, multimodal communication help. Communication has its limits. Both Process and Product feedback are needed. A process needs to allow for its own evolution. Action & Feedback help reduce ambiguities. Pause and reflect to get better. One possible reflection workshop technique.

©Alistair Cockburn Slide 38 Economics of Communication

©Alistair Cockburn Slide 39 Poor office layout costs the project a lot Programmers cost = $ 2.10 / minute (± 50%) Reference pair 100 questions/week 1 minute delay / question = (100 work min.)... for 12 people, 12 months = 1.5 work months (= $ 100,000 ) + Lost Opportunity Costs for questions not asked!

©Alistair Cockburn Slide 40 Kim Pat Think (1/3 work year) / yr penalty (= $300,000 / yr) Kim Pat (1.5 work month) / yr penalty. (= $100,000 / yr) People don’t ask questions if they have to climb stairs. (However, this fact makes for a useful strategy sometimes, ref: Cone of Silence)

©Alistair Cockburn Slide 41 “Managing the Flow of Technology,” Thomas J. Allen, M.I.T. Sloan School of Management “Distance Matters,” Olson & Olson KimPat Most effective. KimPat Still Effective. Information drifts in currents -- (not unlike perfume) Nearby programming Programming in pairs

©Alistair Cockburn Slide 42 Photo courtesy of Evant corp. Notes: Put barriers up to reduce DRAFTS ! Morale also flows through convection currents!

©Alistair Cockburn Slide 43 Photos courtesy of Thoughtworks People get information just by walking past ! Information radiators emit passively

©Alistair Cockburn Slide 44 Courtesy of Evant corp. Courtesy Joshua Kerievsky Iteration PlanReflection workshop results Information radiators are suited for plans, status, initiatives

©Alistair Cockburn Slide 45 Set up rooms to balance drafts and osmotic communication Courtesy of Ken Auer, RoleModel Software, Inc. Programming work Private work Meeting Kitchen Library Watch for: - drafts - convection currents - communities

©Alistair Cockburn Slide 46 People

©Alistair Cockburn Slide 47 PEOPLE learn skill in a 3-stage progression Following - Breaking away - Fluency Level 1: Following (Shu) Learn “a technique that works” “Success” is following the technique Level 2: Breaking away ( Ha ) Learn limits of the technique Learn to shift from one technique to another Level 3: Fluency ( Ri ) Shift techniques by moment Unable to describe the techniques involved These apply to design, management, methodology, are relevant to project staffing.

©Alistair Cockburn Slide 48 Weak on:Strong on: Consistency Communicating Discipline Looking around Following instructionsCopy / modify Changing habits Motivated by: Pride in work Pride in contributing Pride in accomplishment PEOPLE are essential but non-linear active components in the development process

©Alistair Cockburn Slide 49 Normal team Aligned team (Dirty Dozen again) The alignment of people’s goals affects the team efficiency

©Alistair Cockburn Slide 50 Amicability between people determines how quickly information moves Amicability : Willingness to listen with good will The “amicability index” indicates how easily information passes from one part of the organization to another. A low amicability index implies that people block the flow of information, intentionally or through not listening well. Amicability grows and rots fastest in osmotic communication settings !

©Alistair Cockburn Slide 51 People, cooperation, communication issues determine much of a project’s speed Can they easily detect something needs attention? (Good at Looking Around) Will they care enough to do something about it? (Pride-in-work; Amicability) Can they effectively pass along the information? (Proximity; face-to-face, convection currents)

©Alistair Cockburn Slide 52 Methodologies as Transient

©Alistair Cockburn Slide 53 Ecosystem Methodology Process Techniques Tools Skills Roles Standards Quality Teams Products People MilestonesActivities Personality Jenny Jim Peter Annika A methodology is a formula across people, but People change frequently Project manager Documenter Designer Tester Values

©Alistair Cockburn Slide 54 Keep These Ongoing Problems How do we make methodology construction so cheap that we can construct them each month? Answer : The Reflection technique Try These

©Alistair Cockburn Slide 55 Revise the team’s conventions every month Number of people coordinated Comfort Essential moneys Life ,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Discretionary moneys “Criticality” X X X

©Alistair Cockburn Slide 56 Crystal’s “Genetic Code (DNA)”

©Alistair Cockburn Slide 57 Crystal is the lightest, least intrusive set of rules that puts a project in the safety zone. Crystal’s purpose: Keep people from hurting each other, keeping each other informed Crystal’s nature: A set of conventions that gets updated Crystal’s Philosophy:  People differ in working styles  Projects differ in needs  Software development is communication-intensive, experiment-based, needing lots of feedback in all directions  Less is generally better (for methodologies)  Techniques / technologies change over time

©Alistair Cockburn Slide 58 Crystal is a “family” because every project is slightly different. C6C20C40 D6D20D40 E6E20E40 C80 D80 E80

©Alistair Cockburn Slide 59 Crystal’s common genetic code. 1 Cooperative Game Mindset: A series of resource- limited cooperative games of communication and invention. 2 Critical Project Properties: Frequent delivery Close communication Reflective Improvement 3 Key Techniques: Discretionary, but with a starter set. 4 Design Priorities: Project safety Development efficiency Habitability 5 Design Principles: (7 principles, including: face-to-face, concurrent development, different rules for different circumstances) 6 Design Samples: Crystal Clear Crystal Orange Crystal Orange-web

©Alistair Cockburn Slide 60 1: Crystal’s Mindset “Software development is a (resource-limited) finite, goal-seeking cooperative game of invention and communication.”

©Alistair Cockburn Slide 61 Infinite Organization Survival Career Management A finite, goal-directed(resource-limited!) cooperative game Competitive Cooperative Finite w/ no fixed end Jazz music King-of-the-hill wrestling Finite & goal-directed Tennis Software Developmen t Chess Rock-Climbing Games Poker

©Alistair Cockburn Slide 62 The game has a primary and secondary goal: Two Games in One ! Primary Goal  Deliver working software.  (Mess up the first goal => no software. Secondary Goal  Set up for the next game.  Mess up the secondary goal => disadvantaged next project

©Alistair Cockburn Slide 63 2: Crystal’s Project Properties Frequent Delivery Osmotic Communication Reflective Improvement Personal Safety Focus Easy Access to Expert Users Technical Environment with - Frequent integration - Automated testing - Configuration management

©Alistair Cockburn Slide 64 Timeboxing is a critical element in iteration scheduling 2-week, 1-month (,quarterly) timeboxes. Each timebox ends with integrated, tested code. Cut scope as needed but complete on time. Deliver whatever you have Whatever you accomplished this time is a predictor of what you will accomplish next time (“Yesterday’s Weather”) (some timeboxing fixes requirements, some don’t)

©Alistair Cockburn Slide 65 Run the project with nested cycles. Project Episode Integration Day/Week Iteration Delivery

©Alistair Cockburn Slide 66 To understand Crystal (or any agile process), describe each cycle independently. Project Delivery Iteration Iterations Day/Week Integration Day/Week Integrations Days Integrations EpisodesEpisode Episodes Integrations Episodes

©Alistair Cockburn Slide 67 3: Crystal’s Starter Strategies & Techniques Methodology Shaping Reflection Workshop Blitz Planning Delphi Estimation Daily Stand-ups Agile Interaction Design Process Miniature Side-by-Side Programming Burn Charts Exploratory 360° Early Victory Walking Skeleton Incremental Rearchitecture Information Radiators

©Alistair Cockburn Slide 68 Critical technique in Crystal: The reflection workshop each month or iteration. Hang a 2-column flipchart Fill in the chart (30 minutes) Hang the chart in a public, visible, frequently seen place ! Try the ideas Repeat each month or after each iteration

©Alistair Cockburn Slide 69 4: Crystal’s Design Priorities Project Safety Development Efficiency Process Habitability

©Alistair Cockburn Slide 70 5: Crystal’s Design Principles 1. Prefer face-to-face communication  Interactive face-to-face communication is the cheapest and fastest channel for exchanging information 2. Methodology weight is costly 3. Use heavier methodologies for larger / distributed teams 4. Use More ceremony for more criticality 5. Use more feedback & communications, with fewer intermediate deliverables 6. Discipline, skills, understanding counter process, formality, documentation 7. Efficiency is expendable at non-bottleneck activities.

©Alistair Cockburn Slide 71 6: Crystal Sample Methodology Designs Crystal OrangeCrystal Orange/webCrystal Clear

©Alistair Cockburn Slide 72 Crystal Orange : scope For D40 projects: Up to 40 people, same building Loss of discretionary moneys (May extend to E50) Not for very large projects (insufficient subteaming) Not for life-critical projects (insufficient verification) (Described in Surviving OO Projects, Cockburn, 1998, pp ) Amber C6C20C40 C80 D6D20D40 D80 E6E20E40 E80 L6L20L40 L80

©Alistair Cockburn Slide 73 Crystal Orange roles & teams for 45 people Roles: Sponsor, Business expert, Usage expert, Technical facilitator, Business analyst/designer, Project Manager, Architect, Lead designer/programmer, Designer/programmer, UI designer, Design Mentor, Reuse Point, Writer, Tester Teams: System planning, Project monitoring, Architecture, Technology, Functions, Infrastructure, External test.

©Alistair Cockburn Slide 74 C6 C10 D6D10 E6E10 Crystal Clear : scope For D6 projects: 3-6 people, close or in same room Loss of discretionary moneys (may extend to: E8 project) Not for large projects (insufficient group coordination) Not for life-critical projects (insufficient verification) (Described in Crystal Clear, Cockburn, 2004 also in Agile Software Development, Cockburn 2002)

©Alistair Cockburn Slide 75 Crystal Clear roles & teams for 3-8 people Required Roles: sponsor, senior designer, designer/programmer, user (part-time) Combined Roles: coordinator, business expert, requirements gatherer Teams: single team of designer- programmers Seating: single big room, or adjacent offices

©Alistair Cockburn Slide 76 Project Visibility

©Alistair Cockburn Slide 77 House packing exercise Work in groups of 4-6 people

©Alistair Cockburn Slide 78 Create an Information Radiator for Packing your House (15 minutes) Your (American) house has 14 rooms total, including garage. In 33 days, the movers will pick up the packed boxes. Pack everything into boxes and put them into the garage. The next morning you fly to India. You cannot be late. 1. Work in groups of 3-5 people. 2. Decide on a work plan for packing the house. 3. Create information radiator (table/graph/chart) so that you always know how well you are doing. 4. Show how your display looks after 18 days.

©Alistair Cockburn Slide 79 Discuss the different approaches

©Alistair Cockburn Slide 80 The “burn-down” chart and variations show a project’s progress visibly and publicly Visibility of rate-of-progress and achievements are critical project management information Works because task list is fixed in size “Iceberg” list useful when task list changes daily Use spreadsheet or similar List tasks Developers estimate time, Managers prioritize Sort in priority order Derive which tasks are in schedule for this current iteration / delivery. Managers can change priorities

©Alistair Cockburn Slide 81 Method #1. The whole house, by “importance” No view into progress & no warning of trouble Discover the 10% completely unexpected! Discard the 5% junk Pack the 80 % not-so-critical Pack the 15% critical expected actual Time No visibility into what is happening here ! Surprise! % Complete expected done actually done Day 18

©Alistair Cockburn Slide 82 Surprise! Method #2. Estimate boxes to be packed. Good visible progress. No warning of trouble! expected # boxes needed Time Surprise! # Boxes Packed Estimate # boxes needed expected done actually done (actual # boxes needed) Day 18 An unknown number !! An unknown time !! slope = “velocity”

©Alistair Cockburn Slide 83 Method #3. Packing each room to completion. Good visibility & early warning. Time Surprise! 14 Day 33 0 # Rooms Still to Pack Day 18 This strategy works because: 1. The # rooms won’t increase. 2. Feedback is on full process. This is an example of a Burn-Down chart

©Alistair Cockburn Slide 84 Getting Started with Crystal

©Alistair Cockburn Slide 85 Select the frequency of delivery, the length of the iteration and integration cycles. Project: any length Delivery: every two months Delivery Iteration: two weeks Iteration Iterations Week Integration: daily Week Integrations Days Integrations EpisodesEpisode Episodes Integrations Episodes

©Alistair Cockburn Slide 86 Must Do These ! 1. Frequent Delivery : every month or two 2. Osmotic Communication : sit next to each other 3. Reflective Improvement : do reflection workshop monthly Focus on the first 3 properties

©Alistair Cockburn Slide 87 Add these as you can Personal Safety : speak without fear of punishment 5. Focus : Know what is critical, have time to work on it 6. Easy Access to Expert Users 7. Technical Environment with - Frequent integration : hourly, daily, 3 / week - Automated testing : unit tests, acceptance tests - Configuration management : check-in, versioning Start work, stay in good-humored communication with with your teammates !

©Alistair Cockburn Slide 88 Learn new techniques to get better... Methodology Shaping Reflection Workshop Blitz Planning Delphi Estimation Daily Stand-ups Agile Interaction Design Process Miniature Side-by-Side Programming Burn Charts Test-First Design Exploratory 360° Early Victory Walking Skeleton Incremental Rearchitecture Information Radiators

©Alistair Cockburn Slide 89 Hold a reflection workshop each month. Keep these Try these Ongoing Problems too many interruptions shipping buggy code test lock-down quiet time daily meetings pair testing fines for interruptions programmers help testers

©Alistair Cockburn Slide 90 “Crystal” is a genetic code, shaping your working conventions to your project, always agile, focused on frequent delivery, close communication, & reflection. Crystal Clear is the lightest of the Crystal family, for 3-8 people working at the same location. It can be stretched to people. Read more at