Designing A Light Methodology

Download Report

Transcript Designing A Light Methodology

The Crystal Methods,
or
How to make a methodology fit
Alistair Cockburn
Humans and Technology
Salt Lake City, UT
[email protected]
http://alistair.cockburn.us
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 1
Agile is a cultural transformation,
attending to principles over practices
• “Agile is not a matter of transitioning our projects
... it is a matter of transforming our culture.”
-- Eric Olafson, CEO, Tomax Corp. (June 26, 2003)
Executive Summit, Agile Development Conference
• “We value the agile principles over the agile practices
... that is, while there is value on the item on the right,
we value the item on the left more.”
-- Summary position, table 3, Executive Summit
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 2
Why is a methodology?
• To generate lots of work, produce lots of paper
 (there are valid reasons for this, believe it or not)
• To force people the way YOU like to work
 (most new methodologists do this)
• To train people
•
•
•
• To keep people helping, not hurting each other
 Methodology here is nothing more nor less than
the set of conventions they agree to follow.
• (may or may not include technique suggestions)
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 3
Supershort
Methodology
Tutorial
Values
Quality
Products
Standards
Alistair Cockburn
©Humans and Technology, Inc., 2003
Activities
Teams
Techniques
Roles
Tools
Skills
Slide 4
A Methodology properly discusses
the Products, the Factory and the Control System
Factory
Products
Control
System
Tools
People, Organization, Culture
Alistair Cockburn
Notation
©Humans and Technology, Inc., 2003
Slide 5
Methodology: who, what, when of interactions
Process
Milestones
Team Values
Planning
Testing
Quality
Regression tests
Object model
Project plan
Use cases Products
Microsoft Project
3month increments
UML / OMT
C++
Standards
Alistair Cockburn
Activities
MBWA
Use cases
CRC cards
Techniques
Teams
Project manager
Documenter
Designer
Tester
Roles
Envy/Developer JAD facilitation
STP
Java programming
Microsoft Project Modeling
Tools
People
Personality
Skills
©Humans and Technology, Inc., 2003
Slide 6
But people are stuffed full of personality
Ecosystem
Methodology
Activities
Quality
Milestones
Process
Products
Techniques
Standards
Tools
Alistair Cockburn
Values
Values
Teams
Jim
Peter
Jenny
Annika
Tester
Designer
Documenter
Project manager
Roles
Skills
©Humans and Technology, Inc., 2003
People
Personality
Slide 7
Methodology is organization-personal:
how you produce and deliver systems
"Methodology is a social construction" - Ralph Hodgson
Methodology is how you manage to ship systems
 Who you advertise for
 How tightly requirements are gathered
 Design standards, shortcuts, deliverables
 Team size and makeup
 Languages, standards, scheduling strategy
Designing one is NOT like designing software!
 Highly variable components (people!)
 Very long cycle / debug times
 Culture and project dependent
 Standard novice errors based on the above.
Your project leader has to design / tune one for your project
whether s/he likes it or not !!
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 8
Standard methodologist errors:
One size, intolerant, embellished, heavy, wrong.
e1. One size methodology (projects vary)
e2. Intolerant methodology (people vary)
e3. Embellished ('did do' or 'should have done'?)
e4. Heavy (more writing /= more safety)
e5. Untried (lots of errors)
e6. Tried once (limited applicability)
(e 3-6 also apply to expert methodologists!)
"Embellishment is the pitfall of the methodologist"
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 9
Who can use a defined methodology?
Any group of people
Only experts
A team with a minimum number of experts
 (How many experts?)
 (What ratio to novices?)
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 10
What is expertise?
(the Shu-Ha-Ri progression)
Level 1
 Learning “a technique that works”
 Success is following the technique (and getting a success)
Level 2
 Learning limits of the technique
 Success is shifting from one technique to another
Level 3
 Fluid mastery - shifting techniques by moment
 Unable to describe the techniques involved
The 3 levels apply to all techniques, including software
design, management, & methodology adjustment !
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 11
Finally, a Methodology is . . .
The conventions the team agrees to follow:
 range from clothing to coding
 change all the time
 the team chooses/rejects/affects
Requiring a certain level of prior experience to apply:
 at least one person having done something similar
 some mixture of new people and experienced
 ideally a level-3 person present to make adjustments
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 12
End of
Supershort
Methodology
Tutorial
Values
Quality
Products
Standards
Alistair Cockburn
©Humans and Technology, Inc., 2003
Activities
Teams
Techniques
Roles
Tools
Skills
Slide 13
Crystal aims to be the lightest, least intrusive set of
rules that puts a project in the safety zone.
• Keep people from crossing over each other, keeping each
other informed (its Purpose)
• A set of conventions (its Nature)
• Its Philosophy:
 People learn in class or on the job, not from the methodology
 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
 ... ergo ... One methodology won’t suffice.
 ... ergo ... Need many. --How do we do that?
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 14
What is Crystal?
“Crystal is the way Alistair works.”
Methodologies look like their authors’ work habits !
“Let’s talk about me for a minute.”
-- Brian Marick writing about methodologists
1991-94: Debriefed OO project teams all over the world.
1994-95: Project Winifred - delivered on time (over budget)
 45 people: 24 Smalltalk, 4 COBOL, 2 DBAs
 Fixed-price, fixed-time, 18-mo. bid 15M$ (1994 $)
1997-98: Norges Bank project
 3 people -> 8 people linking to 35 people, two cities
 Banking: COBOL, Assembler, CICS, LU 6.2
2001: First Rand Bank (S. Africa) web presence
 50-person company, steady stream of initiatives
 2-week release cycles
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 15
What is Crystal?
“Crystal is the result of Alistair’s researches.”
1991-1994 … present: ~40 interviews with project teams
 What did you do? . . . What happened then? . . . How did
you like that? . . . Would you work that way again?
Is what s/he said true? . . . Show me work products
Results:
 People don’t do what the book says to do,
(nor do they do what they say they did!).
 They can’t keep the documentation in sync with the code.
 The lightest methodology that works is already too heavy.
 Fiddling with it is a CSF of methodology adoption.
 “Crystal Clear” is an ultralight methodology capturing
common practices of successful small teams around the
world, across different technologies.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 16
“Crystal is a family of agile methodologies,
from principles, examples and base techniques”
It’s easier to tune a methodology than to invent one.
Tuning a methodology is critical to its adoption.
Crystal Consists of:
 A minimal rule set
• Deliver increments every 2- to 14 weeks
• Post-increment reflection session workshop
 A base tuning technique
• Pre-project methodology tuning workshop
• Post-increment reflection session workshop
 Principles and tuning rules
• 2D methodology selection grid, bottleneck detection
 Three samples
• Clear -- Orange -- Orange Web
Crystal is underspecified rather than overspecified:
• YOU have to fill in the details of your organization !
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 17
“Crystal is a family of methodologies.”
Choose a Methodology according to
(project size, system criticality, team priorities)
Technologies
change
techniques.
Criticality
Cultures
change
norms.
Distances
change
communication.
(defects cause loss of...)
. . . Prioritized for Legal Liability
Prioritized for Productivity & Tolerance
Life
(L)
L6
L20
L40
E6
E20
E40
Discretionary
money
D6
(D)
D20
C20
Essential
money
(E)
Comfort
(C)
C6
1-6
- 20
L200
L500
L1000
E100
E200
E500
E1000
D40
D100
D200
D500
D1000
C40
C100
C200
C500
C1000
- 500
- 1,000
- 40
L100
- 100
- 200
Number of people involved +20%
Alistair Cockburn
©Humans and Technology, Inc., 1998-9
Slide 11
Not even conceivable to have a single, common methodology.
Every project is slightly different and needs its own.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 18
Crystal is a family of methodologies . . .
. . . Emphasizing fast, personal communications
(speed of change)
. . . Tolerating many styles of development
(well-meaning but careless people who work in many ways)
. . . With a common, key set of values
L6
L20
L40
L80
and principles
. . . Increments & reflection
E6
E20
E40
E80
only common themes
. . . No upward / downward
D6
D20
D40
D80
compatibility (fit-for-the-job)
. . . Three examples documented
C6
C20
C40
C80
(Clear, Orange, OrangeWeb)
Orange Red
Yellow
Clear
. . . Needing one level-3 person
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 19
Crystal lives on three levels:
-Mindset
-Principles
-Examples
Mindset: “Software development is a (resource-limited)
cooperative game of invention and communication.”
 (generates & limits ideas, provides consistency)
Principles: “Lighten work products, improve fast & informal
communication, deliver early & regularly”
 (guide adjusting to circumstances)
Examples: Crystal Clear, Orange, OrangeWeb
 (provide concreteness, seed the process)
 (People work better by copying than inventing from scratch)
There is no, can be no, “formula”
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 20
Crystal’s
Mindset
“Software development is a
(resource-limited)
finite, goal-seeking
cooperative game
of invention and communication.”
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 21
A finite, goal-directed
cooperative game
Infinite
Organization Survival
Career Management
Finite w/
no fixed end
Finite &
goal-directed
Games
Alistair Cockburn
King-of-the-hill
wrestling
Tennis
Poker
Competitive
©Humans and Technology, Inc., 2003
Jazz music
Rock-Climbing
Software
Developmen
t
Cooperative
Slide 22
Sw Development is a Game of Economics
Economic consequences to each choice.
Resources are limited.
“Less” is usually better.
“Barely sufficient” is Best !
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 23
Players in the game are “People” Highly nonlinear, spontaneous active devices
Weak points:
Consistency
Discipline
Following instructions
Strong points:
Looking around
Taking initiative
Copy /modify-ing
Communicating
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 24
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
©Humans and Technology, Inc., 2003
Slide 25
Communication Effectiveness
Crystal’s
Principles
2 people at
whiteboard
2 people
on phone
Videotape
2 people
on email
Audiotape
Paper
Richness (“temperature”) of communication channel
“cold”
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 26
“hot”
Agile methodologies emphasize
“manoeverable, responsive to change”
Agile Software Development Manifesto: We value
 Individuals and interactions over Processes and Tools.
 Working software over Comprehensive documentation.
 Customer collaboration over Contract negotiation.
 Responding to change over Following a plan.
(©2001, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim
Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland,
Dave Thomas )
All very nice, but how do you do it?
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 27
Seven principles
1. Face-to-face
 Interactive face-to-face communication is the cheapest and
fastest channel for exchanging information
2. Weight is costly
3. Heavier methodologies for larger teams
4. More ceremony for more criticality
5. More feedback & communications, fewer intermediate
deliverables
6. Discipline, skills, understanding counter
process, formality, documentation
7. Efficiency is expendable at non-bottleneck activities.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 28
Communication Effectiveness
Principle 1:
People communicate best interactively face-to-face.
(but not for legal traceability!)
2 people at
whiteboard
2 people
on phone
(Courtesy of Thoughtworks, inc.)
Videotape
2 people
on email
Audiotape
Paper
Richness (“temperature”) of communication channel
“cold”
“hot”
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 29
Seven principles
1. Face-to-face
 Interactive face-to-face communication is the cheapest and
fastest channel for exchanging information
2. Weight is costly
3. Heavier methodologies for larger teams
4. More ceremony for more criticality
5. More feedback & communications, fewer intermediate
deliverables
6. Discipline, skills, understanding counter
process, formality, documentation
7. Efficiency is expendable at non-bottleneck activities.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 30
Adding people is expensive.
(Methodology grows with number of roles.)
Effectiveness
per person
Communications Load
(Methodology Cost)
Number of people
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 31
Problem Size
Methodology weight is costly
Larger teams need more … diminishing returns
large team
small team
Methodology Weight
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 32
Lighter methodologies are better, but have limits
Number of People Needed
Heavy
Medium
Light
Problem Size
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 33
(defects cause loss of...)
Criticality
Different methodologies are possible & needed
(project size, system criticality, priorities, fears)
. . . Prioritized for Legal Liability
Prioritized for Productivity & Tolerance
Life
(L)
L6
L20
L40
L100
L200
L500
L1000
Essential
money
(E)
E6
E20
E40
E100
E200
E500
E1000
Discretionary
money
D6
(D)
D20
D40
D100
D200
D500
D1000
C20
C40
C100
C200
C500
C1000
Comfort
(C)
C6
1-6
Alistair Cockburn
- 20
- 40
- 100
- 200
- 500 - 1,000
Number of people involved +20%
©Humans and Technology, Inc., 2003
Slide 34
Damage from
over/underplanning
The “correct” mix of planning vs. reacting
depends on the individual project’s risk exposure.
Plan-driven
sweet spot
Agile
sweet spot
Time and Effort Invested in Plans
from “Get Ready for Agile Methods – With Care”
(Barry Boehm, IEEE Computer, January 2001)
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 35
Seven principles
1. Face-to-face
 Interactive face-to-face communication is the cheapest and
fastest channel for exchanging information
2. Weight is costly
3. Heavier methodologies for larger teams
4. More ceremony for more criticality
5. More feedback & communications, fewer intermediate
deliverables
6. Discipline, skills, understanding counter
process, formality, documentation
7. Efficiency is expendable at non-bottleneck activities.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 36
Jim Highsmith: Skill, discipline, understanding vs.
process, documentation, formality
(Agile methods draw more on
team’s “tacit” knowledge.)
Modern Light/Heavy Debate
4
Alistair Cockburn
X Typical Light Methodology
Adapting
Skill, Discipline, Understanding
High
X Typical Heav y Methodology
Low
Light
Heav y
Optimizing
Process, Documentation, Formality
©Humans and Technology, Inc., 2003
Slide 37
Completeness, Stability
Principle 7: Efficiency is expendable
away from bottleneck activities (1).
Requirements
UI design &
Object Design
Programming
Testing
Serial
Development
Requirements
Design
Program
Test
Concurrent
Development
Requirements
Design
Program
Test
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 38
Principle 7: Efficiency is expendable
away from bottleneck activities (2).
Designer/
Programmer
Designer/
Programmer
Designer/
Programmer
Designer/
Programmer
Designer/
Programmer
Alistair Cockburn
DBA
Completeness, Stability
Requirements
Designer/Programmer
DBA
Time
©Humans and Technology, Inc., 2003
Slide 39
Warning: Methodology is cultural engineering!
A methodology is a micro-culture embedded in
two outer cultures.
 Company culture
 National culture
 fit the outer culture?
 Rejected?
 Both will change
What sort of culture do you have?
 Hierarchy
 Chaos
 Consensus
 Synchronized Silence
Alistair Cockburn
People Tools
Organization
& Culture
©Humans and Technology, Inc., 2003
Notation
Slide 40
Crystal
Methodology Tuning
Workshop
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 41
Buy-In: self-determination or crisis
Expert's buy-in
 Has mental tool box proven complete
 Needs full breakdown to create space for alternate tools
Novice's buy-in
 Has mental tool box with space and need for new tools
 expert may need crisis to accept new ideas.
Buy-In through self-determination:
 In methodology workshop, team members name their
 roles, teams, products, standards, milestones, tasks.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 42
Base technique in Crystal:
Methodology-tuning interviews, workshops
Build the control system first.
 Settle increment size,
 Hold interview & workshop before/after each.
Preload the system.
 Interview projects to learn key issues, hazards, tricks.
 Ask what they did, liked, didn't, would change or keep.
 Identify fears, priorities, success factors, hazards.
Ask the group.
 Let the group influence first increment's methodology.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 43
Base technique in Crystal:
Post-iteration reflection workshop
Hang a flipchart, create two columns
 “Keep these”
 “Try these”
• (Create a small area for “Recurring Problems”)
• (Don’t create an area for “Don’t Like These”!)
Spend 30 minutes filling in the chart
HANG THE CHART IN A PUBLIC, VISIBLE
FREQUENTLY SEEN PLACE !!!!!
Make sure you actually try some of the Try These ideas !
Repeat after each iteration
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 44
Crystal
Examples
&
Specifics
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 45
Crystal family
L6
L20
L40
Roles
Crystal (Clear)
Crystal (Yellow)
Crystal (Orange)
Crystal (Red)
...
L80
project monitoring
application development
sponsor
coordinator
business expert
user
lead designer
designer/programmer
tester
writer
setup requirements design code test
Project Lifecycle
E6
D6
C6
E20
D20
C20
E40
E80
D40
Activities
Teams
Products
Techniques
Roles
D80
C40
C80
Clear Yellow Orange
Alistair Cockburn
Quality
Standards
Red
©Humans and Technology, Inc., 2003
Skills
Slide 46
Crystal family of Agile methodologies
Prioritized for Productivity & Tolerance
Common philosophy:
Strong on communications,
Light on deliverables.
"Sw dev't is a cooperative game,
which uses markers
that remind and incite.”
L6
L20
L40
L80
E6
E20
E40
E80
D6
D20
D40
D80
C6
C20
C40
C80
Orange
Clear Yellow
Red
Principles:
Fewer intermediate products are needed with :
* Short, rich, informal communications paths
* Frequent delivery.
* Use people's natural strengths (talking, looking around)
beware natural weaknesses (careless, low on discipline)
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 47
Crystal separates improve individual skills AND improve team.
Individual track:
 Becoming a better <designer, manager, tester, …>
 Qualities & Standards for <use cases, OO designs, …>
 Techniques for <facilitating, getting use cases,, scheduling,
resolving conflicts>
Team track:
 Big-M methodology for <6 people, 15 people, 40, …>
 Techniques for <improving collaboration, …>
Non-jealous methodology set
 Improve people, and improve team
 Whichever you need next, whatever you can manage.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 48
Crystal Orange : scope
For D40 projects:
Up to 40 people, same building
Loss of discretionary moneys
(May extend to E50)
L6
L20 L40
L80
E6
E20 E40
E80
D6 D20 D40 D80
C6
Amber
C20 C40
Not for very large projects
(insufficient subteaming)
Not for life-critical projects
(insufficient verification)
(Described in Surviving OO Projects,
Cockburn, 1998, pp. 77-93)
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 49
C80
Crystal Orange : roles & teams
Roles: Sponsor, Business expert, Usage expert, Technical
facilitator, Business analyst/designer, Project Manager,
Architect, Lead designer/programmer,
Designer/programmer, Design Mentor, Reuse Point,
Writer, Tester, UI designer.
Teams: System planning, Project monitoring, Architecture,
Technology, Functions, Infrastructure, External test.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 50
Crystal Orange : standards
Policy:
 Delivery increments every 3 + 1 months
 Tracking by milestones, not by work products
 Mandatory regression testing of application function
 Direct user involvement
 Ownership model for work products
 2 user viewings per release
 Use cases completed down to failure cases
 Single, common object (not analysis & design models)
 Downstream activities start as soon as upstream is "stable
enough to review"
Local standards (set and maintained by team):
 Work product templates, Coding style, UI style
 Regression test framework
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 51
Crystal Orange : products
Ownership assignment is negotiable,
Every product has an owner.
* Requirements doc
* Release sequence, schedule, status report
* UI design doc
* Common object model
* Inter-team specs
* Usage manual
* Code
* Test cases
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 52
Crystal Orange : tolerance
Policy standards are mandatory, but equivalent substitution
are permitted (e.g. "Scrum")
Full tolerance on techniques: any technique allowed
>Recommended techniques
 Semantic modeling, RDD, facilitated sessions
Tolerance on work products
 Minor deviation from templates permitted
 Few alternatives to intermediate products accepted
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 53
Crystal Orange : activities & milestones
Workshop:
Mid- & post-increment methodology review
Publish:
Each work product,
Iteration & increment deliveries
Review:
Each work product, Iteration deliveries, Test cases, Final
delivery
Declare:
Each work product stable enough to review,
Application correct enough to deliver.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 54
Crystal Clear : scope
E6 E10
For D6 projects:
3-6 people, close or in same room
Loss of discretionary moneys
(may extend to: E8 project)
D6 D10
C6 C10
Not for large projects
(insufficient group coordination)
Not for life-critical projects
(insufficient verification)
(Described in Crystal Clear, Cockburn, 2002
also in Agile Software Development, Cockburn 2001)
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 55
Crystal Clear : roles & teams
Must have: sponsor, senior designer, designer/programmer,
user (part-time)
Combined roles: coordinator, business expert, requirements
gatherer
Teams: single team of designers/programmers
Seating: single big room, or adjacent offices
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 56
Crystal Clear : Products and Milestones
Products
 Release sequence, Schedule of user viewings, deliveries
 Actors-goals list & Annotated use cases
 Design sketches & notes as needed, screen drafts
 Common object model
 Running code, Migration code, Test cases
 User manual
Publish: each
Review: each
 Methodology (pre- and mid-increment)
Declare:
 Requirements stable enough to design to,
 UI stable enough to document to,
 Application correct enough to deliver.
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 57
Crystal Clear : standards
Policy:
 Delivery increments every 2 + 1 months
 Tracking by milestones, not by work products
 Requirements in annotated usage scenarios (use cases)
 Mandatory regression testing of application function
 Peer code reviews
 Direct user involvement
 Ownership model for work products
Local standards (up to the team):
 Coding style
 UI style
 Regression test framework
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 58
Crystal Clear : tolerance
Policy standards are mandatory, but equivalent substitution
are permitted (e.g. "Scrum")
Full tolerance on techniques: any technique allowed
Quite wide tolerance on work products
 Many alternatives to intermediate products accepted
 e.g., paper, whiteboard, online notes
 Low precision in early stages
 High precision only required for production work products
Assess the Quality of the communications, not the quality of
the work products (except Test Cases).
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 59
Crystal is a slightly underspecified set of
principles, techniques and example methodologies.
The conventions the team agrees to follow:
 range from clothing to coding
 change all the time
 the team chooses/rejects/affects
Requiring a certain level of prior experience to apply:
 at least one person having done something similar
 some mixture of new people and experienced
 ideally a level-3 person present to make adjustments
. . . Your project leader must do this tuning for your project
whether s/he likes it or not !!
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 60
Crystal aims to be the lightest, least intrusive set of
rules that keeps a project in the safety zone.
• Crystal is a set of rules for re-tuning a methodology to be
adapted to your project within its timeline, specific to your
project, always agile, & written for those who have to do
the tuning.
• Remember, “Agile is a matter of transforming the culture,
valuing the agile principles over specific agile practices
• Visit
Alistair.Cockburn.us/crystal
Alistair Cockburn
©Humans and Technology, Inc., 2003
Slide 61