1. What Is Agile Development & What does it Imply?
Alistair Cockburn

2. Talk structure What agile is (isn’t), and what it implies
What is ‘agile’, how did it get there?
Methodology theory meets project details
Getting / Misconstruing the message

3. ‘Agile’ got there by winning the development races in the turbulent 1990s.
Agile techniques were in use since the beginning.
Agile (mobility-based) techniques did not show competitive advantage in the 1970s / 1980s,
but did during the 1990s and do now.
Trial runs of current agile methodologies,
RAD DSDM
XP Crystal
Scrum Adaptive

4. Agile software development is about valuing “maneuverability” and “efficiency”
Differing tactics fit differing focuses of attention:
? predictability
? repeatability
? cost
? agility
Agile methods make greater use of:
+ Individuals and interactions
+ Working software
+ Customer collaboration
+ Responding to change
Within ‘agility,’ different tactics fit different situations
(“Agile” is not just a retitling of Extreme Programming !)

5. Software development is making ideas concrete in an economic context.
People inventing / communicating, Solving a problem Creating a solution Using limited languages
Where every choice has economic consequences, and resources are limited
Which
they don’t fully understand
& keeps changing under them

6. A resource-limited cooperative game of invention and communication
Primary Goal  Deliver this software
Secondary Goal  Set up for the next game
Elements of the Game:
People,
Cooperation,
Invention,
Communication
(p.s.
The game
never
repeats !!)
Infinite
Organization Survival
Career Management
Competitive
Cooperative
Finite w/
no fixed end
Jazz music
King-of-the-hill
wrestling
Finite &
goal-directed
Tennis
Poker
Rock-Climbing
Games
Software
Development

7. Key topics in the cooperative game
1. Different tactics for different projects
2. People’s Personalities, Motivation, Goal Alignment
3. Talent & Skill (fewer better people)
4. Communication (developers - developers - users)
5. Energy Management (minimal requirements/design)
6. Reflecting on what works / doesn’t work
7. Quality in work (good, simple designs)
8. Good Tools (configuration management, testing)
9. Tacit knowledge, verbal communication
10. Frequent Delivery (incremental development)

8. The players in the game are “People,” Highly spontaneous, active devices
Weak on: Strong on:
Consistency Communicating
Discipline Looking around
Following instructions Copy / modify-ing
Motivated by:
Pride in work
Pride in contributing
Pride in accomplishment

9. People communicate most effectively interactively, face-to-face.
2 people at
whiteboard
2 people
on phone
Communication Effectiveness
Photo courtesy of Evant corp.
Videotape
2 people on
Paper
Richness of communication channel

10. Methodology meets Project details:
Methodology meets Project details: (a) Methodology = theory of a project
Methodology
Activities
Milestones
Values
Quality
Process
Teams
Regression tests
Object model
Project plan
Use cases
Tester
MBWA
Use cases
CRC cards
Designer
Documenter
Project manager
Products
Techniques
Roles
Microsoft Project
3month increments
UML / OMT
C++
Microsoft Project
STP
Envy/Developer
Modeling
Java programming
JAD facilitation
Personality
Standards
Tools
Skills

11. “Ecosystem” = the actual project details
“Ecosystem” = the actual project details. (b) People are stuffed full of personality
Methodology
Ecosystem
Values
Values
Activities
Milestones
Jenny
Jim
Peter
Annika
Quality
Process
Teams
Tester
Designer
Documenter
Project manager
Products
Techniques
Roles
People
Standards
Tools
Skills
Personality

12. Methodology and Ecosystem are always in interplay
When each changes, the ecosystem rearranges itself.
Ecosystem:
Project details (“environment”)
Staff expertise (“species”)
Specific dominant / mild people (“predators”)
Flights of stairs people must climb (“cliffs”)
Office layout (“terrain”)
Amicability between the individuals

13. Projects get restructured around ecosystem details
Marketing
group
Business
analysts
Jenny
(Pete)
Marketplace
Programmers
Bill
Mary

14. Misconstruing the message: 1. Agile is hacking.
Hackers
“Avoid planning”
“Spend all their time coding”
“Talk to each other when they are stuck [only]”
“Management caves in out of fear”
Agilists
Plan regularly
Test according to project priorities, recheck results with users often.
Talk to each other and customers as a matter of practice
Expect management to provide priorities, to participate jointly in making project adjustments.
(Hacker interpretations are available & inevitable.)

15. Misconstruing the message 2. Agile only works with the best developers.
Every project needs at least one experienced and competent lead person. (==Critical Success Factor)
Each experienced and competent person on the team permits the presence of 4-5 “average” or learning people.
With that skill mix, agile techniques have been shown to work many times.

16. Getting the message: 1. Agile techniques are “cheating”.
· Hire good people;
· Seat them close together to help each other out;
· ... close to the customers and users;
· Arrange for rapid feedback on decisions;
· Let them find fast ways to document their work;
· Cut out the bureaucracy.
This is:
cheating
stacking the deck
the heart of agile software development
a good idea

17. Getting the message: 2. Agile won’t work for all projects.
Right.
Not every project team
- values agility
- can set up the needed trust and communication
(p.s. Business isn’t fair).

18. Alistair Cockburn alistair. cockburn@acm. org http://members. aol
Alistair Cockburn