#1 Agile Game
#1 Agile Game
#1 Agile Game
Slide 1
Agile Software Development,Cooperative Game
Schedule of the day
Slide 2
Things you may take away from today:
• The Cooperative Game vocabulary
• Manage the incompleteness of communication
• Distance hurts. (So DON’T DO IT !)
• Take advantage of face-to-face communication.
• Incremental delivery => Product feedback
• Reflection workshops => Process feedback
• Use of information radiators
• Relevance of amicability and convection currents
• Three levels of skill (shu, ha, ri)
• Why methodologies need tuning to fit their ecosystem
• How to tune yours to your project and your people
• Timeboxing / increments as core technique
• Burn-down charts for visibility, iceberg list for scheduling
• Concurrent development saves time
• Optimize the rules to fit project-specific bottenecks
• All agile methodologies use empiriical process, cooperative game
concepts
• How to mix in Scrum, consider other named agile methodologies
• How to look for agile methodologies in your environment Slide 3
Agile Software Development,Cooperative Game
Schedule of the day
Slide 4
Cockburn 1998: Making software consists only
of making ideas concrete in an economic context:
Slide 6
Games, finite/infinite or cooperative/competitive,
consist of better/worse ‘moves’
Organization Survival
Infinite
Career Management
Finite w/ King-of-the-hill
Jazz music
no fixed end wrestling
Tenni Rock-Climbing
Finite &
Software
goal-directed s Poker Developme
nt
Competitive Cooperative
Slide 7
Musashi 1685: swordfighting (or gaming?)
-discuss how this relates to programming-
* The field of martial arts is particularly rife with * One
win
can win with the long sword, and one can
with the short sword.
flambouyant showmanship, with commercial
popularization and profiteering. * Where you hold your sword depends on your
*You should observe reflectively, with overall *Whatever guard you adopt, do not think of it as
awareness of the large picture as well as precise being on guard; think of it as part of the act of
attention to small details... killing.
*The views of each school, and the logic of each *In my school, no consideration is given to
path, are realized different, according to the anything unreasonable; the heart of the matter
individual person, depending on the mentality... is to use the power of knowledge of
martial arts to gain victory any way you can.
Slide 8
Every game run uses different strategies --
Set up each project’s suitably or suffer
“Criticality”
Life
L6 L20 L40 L100 L200 L500 L1000
Essential
X X
moneys E6 E20 E40 E100 E200 E500 E1000
Discretionary X
moneys
D6 D20 D40 D100 D200 D500 D1000
Comfort
C6 C20 C40 C100 C200 C500 C1000
1-6 - 20 - 40 - 100 - 200 - 500 - 1,000
Number of people coordinated
Slide 9
Naur 1986: The primary result of programming
is the theory held by the programmers
Slide 13
Phil Armour’s 2003 “Laws of Software Process”
match Theory Building, Cooperative Gaming:
Slide 14
Agile Software Development,Cooperative Game
Schedule of the day
Slide 15
COMMUNICATION (e.g. this talk) is
a sequence of touching into shared
experience
Linked sequences of shared experience
becomes a shared experience !
- Project colleagues have rich shared the program
experiences, a shortcut “theory”
vocabulary
Implications for documentation:
design
- can never fully specify
patterns
requirements
- can never fully document
design UML
- must assume reader’s
experiences more => can
write less source code
less => must write more. Slide 16
COMMUNICATION:
Perfect communication is impossible
(wine bottle)
Slide 18
You don’t need perfect communication:
You need “good enough to proceed”
• You don’t know what you know, nor the thing you are
trying to communicate nor what you are communicating.
• Your listener sees only a part of what you are saying.
- Your body communicates subvocally directly to the
listener’s emotions
• What your listeners learn depends on their mental
state.
- You only ‘take on’ what you are ready to
• “Equivocality” is the ambiguity in communication.
- It will never be zero (no matter how hard you try)
- Action and feedback reduces it to acceptable
levels.
- That is Good Enough
Slide 19
Face-to-face allows vocal, subvocal, gestural
information to flow, with fast feedback
2 people at
Communication Effectiveness
whiteboard
2 people
on phone
(Courtesy of Thoughtworks, inc.) Videotape
2 people
on chat
A s wer)
n
u Question-A
(No
di
cooler ot warmer
Richness of communication
a channel
pe
Paper Slide 20
Experience incommunicability and elementary
Agile techniques for yourselves
Slide 21
Draw a Drawing
1st round -- 10 minutes
Ongoing Problems
Slide 24
Draw a Drawing
2nd round -- 5 minutes
Slide 26
Draw a Drawing
3rd round -- 5 minutes
Slide 27
End. You have just seen a cooperative game
of invention & communication in action.
Slide 28
Things you may take away from today:
• The Cooperative Game vocabulary
• Manage the incompleteness of communication
• Take advantage of face-to-face communication.
• Pause and reflect on your Process with a Reflection workshop
• Distance hurts. (So DON’T DO IT !)
• Use Incremental delivery to get Product feedback
• Use of information radiators
• Relevance of amicability and convection currents
• Three levels of skill (shu, ha, ri)
• Why methodologies need tuning to fit their ecosystem
• How to tune yours to your project and your people
• Timeboxing / increments as core technique
• Burn-down charts for visibility, iceberg list for scheduling
• Concurrent development saves time
• Optimize the rules to fit project-specific bottenecks
• All agile methodologies use empiriical process, cooperative game
concepts
• How to mix in Scrum, consider other named agile methodologies
• How to look for agile methodologies in your environment Slide 29
COMMUNICATION uses
“Convection Currents of Information”
Kim
Proximity
Osmosis
Drafts
Radiator Pat
s
Slide 30
What can we tell from
an office plan?
Courtesy of
RoleModel Software
Slide 31
Poor office layout costs the project a lot
Slide 32
People don’t ask questions if they have to
climb stairs.
Pat
Slide 33
Information drifts in currents --
(not unlike perfume)
Slide 34
“Nearby programming” is effective.
“Programming in pairs” is more effective.
Slide 35
Notes: Put barriers up to reduce DRAFTS !
Morale also flows through convection currents!
Slide 36
Set up rooms to balance drafts
and osmotic communication
Private work
Library
Watch for:
- drafts
- convection currents
- communities
✓ Proximity
✓ Osmosis
✓ Drafts
➜ Radiators
Slide 38
Information radiators emit
passively
Slide 40
COOPERATION: The alignment of people’s
goals affects the team efficiency
Normal team
Aligned team
Slide 43
People, cooperation, communication issues
determine much of a project’s speed
Slide 44
PEOPLE: The teams with the best people
usually win
Slide 45
PEOPLE learn skill in a 3-stage progression
Following - Breaking away - Fluency
Slide 48
A methodology is a formal structure that
idealizes personality
Values
Quality Process Teams
Regression tests Tester
MBWA Designer
Object model
Use cases Documenter
Project plan Project
CRC cards
Use cases Products manager
Techniques Roles
Slide 49
A methodology addresses notations, tools,
AND people, organization and culture
Factory Products
Control
System
Notation
Tool
s People, Organization, Culture
Slide 50
Any methodology attacks a limited subset of
the project lifecycle, roles, role activities
rest and recreation
vacations and basic business
technical education
timesheets
project development
project
sponsor project
manager expert
user business
expert lead
designer UI
Roles
expert
reuse point
designer/programmer
tester
writer
trainer
secretary
contractor
night watchman
janitor Project Lifecycle
envisioning proposal sales setup requirements design & code test deploy train
alter
Slide 51
A methodology meets its limits when it meets
-people-
Slide 52
A methodology is a formula across people, but
People are stuffed full of personality
Methodology Ecosystem
Values
Activities Milestones
Values
Jim
Tester
Quality Process Teams Designer Peter
Documenter Jenny
Project manager Annika
Products Techniques Roles People
Slide 53
Level 1 practice: Stick to the methodology
Level 2, 3 practice: Adapt to the situation
Marketing Business
Marketplace group Programmers
analysts
Jenny
(Pete)
Bill
Mary
Slide 54
Consider clustering subteams around skills
with an Assignment X Skills matrix
Team 1 Team 2
Slide 56
Methodologies have quick payoff, early
diminishing returns. Larger teams need more
Many people
(using a very heavy
methodology)
Methodology Weight
Slide 57
No methodology will fit the whole company.
Select one to suit your project
“Criticality”
Life
L6 L20 L40 L100 L200 L500 L1000
Essential
X X
moneys E6 E20 E40 E100 E200 E500 E1000
Discretionary X ?
moneys
D6 D20 D40 D100 D200 D500 D1000
Comfort ?
C6 C20 C40 C100 C200 C500 C1000
1-6 - 20 - 40 - 100 - 200 - 500 - 1,000
Number of people coordinated
Slide 58
Any methodology attacks a limited subset of
the project lifecycle, roles, role activities
rest and recreation
vacations and basic business
technical education
timesheets
project development
project
sponsor project
manager expert
user business
expert lead
designer UI
Roles
expert
reuse point
designer/programmer
tester
writer
trainer
secretary
contractor
night watchman
janitor Project Lifecycle
envisioning proposal sales setup requirements design & code test deploy train
alter
Slide 59
You can mix in complementary segments.
e.g. add UI design techniques to XP
project monitoring
application development
sponsor
coordinator
Roles
XP user
UI designer
designer / programmer
designer / programmer
coach
setup
requirements design
code test
project monitoring
application development
sponsor
Usage-centered
coordinator
design user
Roles
UI designer
designer / programmer
coach
setup
requirements design Slide 60
code test
Most importantly, a methodology needs to
allow itself to EVOLVE
Almost none do
How?
Slide 61
Crystal self-adapts: methodology tuning early;
reflection workshops monthly/quarterly
Start of project:
Choose an iteration (increment) duration,
Interview people to learn key issues, hazards.
Hold tuning workshop to build starter set of rules.
That is your “starter” methodology.
Get feedback periodically:
Hold “reflection workshop” periodically:
monthly / quarterly / mid- & post-increment;
one hour, half hour, half day
Update the project with new rules and
conventions
Post the results prominently for all to see!
(Hidden results are no results) Slide 62
Reflection technique: Write in this chart.
What worked? What might you try next time?
Ongoing Problems
Slide 65
The Agile Manifesto embodies the
cooperative game ideas
Alistair Cockburn
Humans and Technology
alistair
[email protected]
http://Alistair.Cockburn.us
Slide 67
If you wanted to ‘cheat’ and win,
what could you do?
Slide 69
House packing exercise
Slide 70
Create an Information Radiator for
Packing your House (15 minutes)
Slide 72
The “burn-down” chart and variations show a
project’s progress visibly and publicly
Pack the 80 %
not-so-
critical No visibility into
what is happening here !
Discard the 5% junk
Time Day expected actually
18 done done
Slide 74
Method #2. Estimate boxes to be packed.
Good visible progress. No warning of trouble!
# Boxes Packed
(actual # boxes needed)
An unknown
expected # boxes needed number !!
Surprise!
An unknown
time !!
Surprise!
Estimate Day 18 expected actually Time
# done done
boxes
needed Slide 75
Method #3. Packing each room to completion.
Good visibility & early warning.
Design Validate
logic
Code Validate syntax
Slide 77
1 24-month V is “waterfall”.
6 4-month Vs are incremental, effective.
? ?
Adjustment
Points
1-10
Slide 78
Short Vs allow focus of attention, learning,
better estimation, process & team changes.
Staff changes
Management changes
Process changes
Aha !
Aha !
6-16 weeks
Ah
?
1-10
Slide 79
Some Vs (iterations) end with “examination”
Some Vs (increments) end in “delivery”
Increments should be 4 months or less.
D D D
use case 21
screen 11
class 9
use case 22
Slide 81
“Every team must deliver working function
every 2 - 4 months.”
Slide 82
Concurrent Development
Slide 83
Serial Development takes most time,
least money (maybe)
Requirements
Completeness, Stability
UI & Object
Design
Programmin
g
Testing
Time
Slide 84
Concurrent Development takes less time
more money (maybe)
Requirements
Completeness, Stability
UI & Object
Design
Programmin
g
Testing
Time
Slide 85
Correct amount of Stability depends on the
Bottlenecks !
Completeness, Stability
to speed the game!
Smalltalk
Smalltalker
DBA
Smalltalker
Req’ts
Smalltalker DBA Time
Smalltalker
Req’ts
Smalltalker
Slide 86
Different project have different bottlenecks,
and need different strategies
Project 1: Simplify life for the DB designer, make programmers do extra
Programmer
Programmer
Req’ts
User Programmer Database designer
Programmer
Req’ts
Programmer
Project 2: Simplify life for the programmers / tester, make Bus. Mgrs. do extra
User Programmer
Bus. Mgr.
User Programmer Tester
Bus. Mgr.
User Programmer
Slide 87
Things you may take away from today:
• The Cooperative Game vocabulary
• Manage the incompleteness of communication
• Take advantage of face-to-face communication.
• Pause and reflect on your Process with a Reflection workshop
• Distance hurts. (So DON’T DO IT !)
• Use Incremental delivery to get Product feedback
• Use of information radiators
• Relevance of amicability and convection currents
• Three levels of skill (shu, ha, ri)
• Why methodologies need tuning to fit their ecosystem
• How to tune yours to your project and your people
• Timeboxing / increments as core technique
• Burn-down charts for visibility, iceberg list for scheduling
• Concurrent development saves time
• Optimize the rules to fit project-specific bottenecks
• All agile methodologies use empiriical process, cooperative game
concepts
• How to mix in Scrum, consider other named agile methodologies
• How to look for agile methodologies in your environment Slide 88
Agile Software Development,Cooperative Game
Schedule of the day
Slide 89
Some agile methodologies are named,
Many never get named.
Scrum
XP
FDD
DSDM
Crystal
Grizzly
....and an indefinite
number of others
Slide 90
Scrum: Software needs an “empirical
process”, therefore check on it regularly !
Slide 92
XP: A high-discipline, programmer-centric
minimalist methodology
user
UI designer
designer / programmer increasing discipline.
designer / programmer
coach
setup requirements design code test
E6 E10 E20
Project Lifecycle
Slide 93
Extreme Programming characterized
Quality Activities Values:
System comparison test Setting the metaphor Communication
Functional test Planning Keeping it simple
Full unit tests Daily stand-upmeeting Testing
Coding standards DesigningProgramming
Code cost model Testing
Courage
"Once and only Postpartum
once" Teams
Programming teams
Products User team
Release Plan Techniques Production team
Story Cards Metaphor building
Task list & estimates Planning Game Roles
Running code Teamwork motivation Sponsor
Migration programs Test-case-first development User
Tests Refactoring
Reports Coordinator
Designer/Programmer
Standards Production support
Tools Coach
Coding style Smalltalk / Java / ...
Episodal development Envy/Developer Skills
3-week deliveries Refactoring browser Programming
Test case style Test-case Refactoring
Always perfect unit test framework Testing
Programming in Pairs Performance tuning
Slide 94
XP expects discipline in the team,
distributes responsibilities across roles
“Customer” on site
- “Customer” role is overloaded Slide 95
DSDM: Industrialized “rapid
application development”
Developed in the UK in the mid-1990s from RAD
References:
www.dsdm.org
DSDM: A Framework for Business-
Centered Development
Jennifer Stapleton, Addison-Wesley
2003.
Core practices:
Business study, prototyping,
project management
Slide 96
DSDM is built around 9 core principles
Slide 97
DSDM Model
Slide 99
FDD and Its Five Parts
An object model Major feature sets, The development Sequence diagram Client-valued
feature sets, plan functionality
(more detail than
(more shape than features
shape)
detail)
Slide 100
“Adaptive” Software Development is an agile
mindset for running projects
Slide 101
The Adaptive Life Cycle
Slide 102
The Adaptive Life Cycle
Slide 103
Crystal is a family of self-adapting, tolerant
agile methodologies
Slide 104
Crystal comes with
Philosophy, Principles, Techniques, Samples
Start of project:
Choose an iteration (increment) duration,
Interview people to learn key issues, hazards.
Hold tuning workshop to build starter set of rules.
That is your “starter” methodology.
Get feedback periodically:
Hold “reflection workshop” periodically:
monthly / quarterly / mid- & post-increment;
one hour, half hour, half day
Update the project with new rules and
conventions
Post the results prominently for all to see!
(Hidden results are no results) Slide 107
Most “agile” methodologies are home-grown,
but share essential qualities:
(more
to
come?)
Slide 110