The thinking tool called Agile

1
The thinking tool called Agile
Integrating Agile conference keynote, Amsterdam,
June 18, 2009
Henrik Kniberg - Crisp AB Agile coach Java
guy Cofounder / CTO of Goyada (mobile
services) 30 developers Lead architect at Ace
Interactive (gaming) 20 developers Chief of
development at Tain (gaming) 40 developers Agile
coach at various companies
henrik.kniberg_at_crisp.se 46 70 4925284
2
Scrum is an iterative, incremental process for
developing any product or managing any work
What is all this stuff?
TDD
XP is a discipline of software development
Scrum is a methodology (a set of process tools
and techniques)
Ken Schwaber
Scrum
XP
RUP is a comprehensive process framework
XP is a software engineering methodology
Scrum is an Agile development framework
Ron Jeffries
RUP
Jeff Sutherland
Kanban
Agile is a tool, not an excuse.
Kanban is a signalling system to trigger action
The term 'agile' refers to a philosophy of
software development
Lean manufacturing is a generic process
management philosophy
Robert C Martin
Agile
Lean
CMMI
Lean is a system designed to provide the tools
for people to continually improve their work.
Martin Fowler
Agile is a development approach that primarily
addresses the problems of rapid change
Jeffrey Liker
Alistair Cockburn
3
How do they relate to each other?
Lean
Fork
Knife
Agile
Toothpick
Scrum
XP
Kanban
!?
Lets just say These are all tools!
4
Thinking tools a.k.a. mindsets or philosophies
Tool
Toolkitsa.k.a. frameworks
Agile
Systems Thinking
Lean
anything used as a means of accomplishing a task
or purpose.- dictionary.com
Theory of Constraints
RUP
XP
Scrum
Physical tools
Kanban
Process tools a.k.a. organizational patterns
Product Owner role
Pair programming
Visualize the workflow
5
Is Agile always right?
Always works!
I told you itwouldnt work!
Actual greatness vs expected greatness
Silver bullet!
Works!

• Majority of pracitioners experience
• Improved productivity
• Reduced Time to market
• Reduced defect rate
• Reduced cost

Pretty good
Actual greatness
Agile projects 60-80 success rate(compared to
industry average 30)
Greatnesslevel
Pretty bad
Will never work!
Useless
Harmful
Time
y2000
y2010
Sources http//www.softwaremag.com/L.cfm?Docnew
sletter/2004-01-15/Standish http//www.versionone.
com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf h
ttp//www.ambysoft.com/surveys/agileFebruary2008.h
tml
6
What is un-Agile?
Guess the company
Brilliant process management is our strategy.
We get brilliant results from average
peoplemanaging brilliant processes.
The right process will produce the right results
Requirements
Acceptance test
System test
System design
Integration test
Architecture
Module design
Unit test
Coding
7
Toyota
Brilliant process management is our strategy.
We get brilliant results from average people
managing brilliant processes.
Our competitors get average results from
brilliant people working around broken processes.
When they get in trouble they hire even more
brilliant people.
We are going to win
Fujio Cho Chairman of the board, former
President, Toyota Motor Corporation
8
Toyota useswaterfall for software development

• Not happy with it
• Trying to implement TPS (lean)
• Want to go Agile, but not ready yet

Source We visited Toyota in Japan during our
Lean Study Tour, April 2009.
9
What is waterfall anyway?
Managing the development of large software
projects Dr Winston Royce, 1970
The remainder of this discussion presents five
additional features that must be added to the
basic approach to eliminate most of the
development risks
I believe in this concept, but the
implementation described above is risky and
invites failure
Step 5 Involve the customer the involvement
should be formal, in depth, and continuing
Good un-Agile may be better than bad Agile!
10
What about the agile methods?
Over 70 of Agile companies use Scrum (or try
to...)

• Sources
• 3rd Annual State of Agile Development Survey
  June-July 2008
• 3061 respondents
• 80 countries

11
Typical pre-scrum organizations
Component teams
Ad-hoc / unknown
Waterfall
12
Scrum scenario 1
3. Scrum
1. Waterfall
2. ScrumButt
Feature team 1
Feature team 2
Design code
The important thing is not where you are, but
where you are going!
13
Scrum scenario 2
Scrum is a tool, not a goal
We couldnt agree on who sets priorities, so we
skipped PO role.
Feature team 1
Feature team 2
Thats ScrumButt! Youre just hiding from the
problem!
Impressive, you have so good collaboration that
you can manage without a designated PO!
14
Scrum scenario 3
Agile doesnt require timeboxed iterations!
Step 1
Step 2
Step 3
Feature team 1
Feature team 2
Feature team 2
Feature team 1
Feature team 2
Feature team 2
Feature team 1
Feature team 2
Feature team 2
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Operations / support team
Operations / support team
Scrum
Kanban
15
Is ScrumButt bad?

• ScrumButt is not Scrum
• ScrumButt could be bad
• cheap excuse to hide problems
• ScrumButt could be good
• stepping stone towards Scrum
• excellent implementation of Agilein your context

16
So is Agile always right?
Agile methods arent always agile

• Are agile values always right?
• Gut feel Usually, yes.
• Fact Dont know
• Is agile methodltinsert your favorite method
  heregt always right?
• No!

Agile methods arent the only way to be agile
Agile is a tool, not a goal
Never blame the tool!
What is the cause of this problem?
Scrum sucks! It didnt work for us!
Why did you use it?
Because the Scrum trainer convinced us!
Pete
Ola
17
Before criticizing or praising Agile....

• Be clear about what you are criticizing or
  praising
• Agile itself?
• www.agilemanifesto.org?
• One particular consultant/coach/trainer?
• Henrik?
• One particular process?
• Kanban? Scrum?
• One particular implementation?
• DSDM at company Z?
• One particular organization?
• Agile Alliance? Scrum Alliance?

18
Beware of comparing tools
There is no such thing as a good or bad tool
Any tool can be misused
The old tool was better!
19
Prescriptive vs Adaptive tools
Tools must be combined. No single tool is
complete.
Compare tools for understanding, not for
judgement.
More prescriptive
More adaptive
XP (13)
Scrum (9)
Kanban (3)
Do Whatever (0)
RUP (120)

• Architecture Reviewer
• Business Designer
• Business-Model Reviewer
• Business-Process Analyst
• Capsule Designer
• Change Control Manager
• Code Reviewer
• Configuration Manager
• Course Developer
• Database Designer
• Deployment Manager
• Design Reviewer
• Designer
• Graphic Artist
• Implementer
• Integrator
• Process Engineer
• Project Manager
• Project Reviewer

• Business use case realization
• Business use-case model
• Business vision
• Change request
• Configuration audit findings
• Configuration management plan
• Data model
• Deployment model
• Deployment plan
• Design guidelines
• Design model
• Development case
• Development-organization assessment
• End-user support mateirla
• Glossary
• Implementation model
• Installation artifacts
• Integration build plan
• Issues list

• Whole team
• Coding standard
• TDD
• Collective ownership
• Customer tests
• Pair programming
• Refactoring
• Planning game
• Continuous integration
• Simple design
• Sustainable pace
• Metaphor
• Small releases

• Scrum Master
• Product Owner
• Team
• Sprint planning meeting
• Daily Scrum
• Sprint review
• Product backlogt
• Sprint backlog
• BUrndown chart

• Visualize the workflow
• Limit WIP
• Measure and optimize lead time

Do not develop an attachmentto any one weaponor
any one school of fighting
Miyamoto Musashi17th century samurai
20
The Goal is the goal!A Tool is just a tool
Focus on Why, not How.
How do we get Agile?
What is your goal?
We want to get Agile.
Why?
21
Sample goal - Toyota
Are you staying in business so you can earn
money? Or are you earning money so you can stay
in business? (Toyota)
Only when you know your real goal can you talk
about success or failure.
A problem is only a problem if it conflicts with
your goal!
Source ishii-sans slides during our Lean Study
Tour to Toyota, April 2009.
22
Real-life exampleWhat is the problem?
Problem
Crashing demos
A
B
causes
Bad code quality
Why?
(etc)
(etc)
No pair programming
Lack of test automation
(etc)
Our problem is that were not doing XP practices
like TDD and pair programming.
Really?
23
Real-life exampleWhat is causing the problem?
Why?
Not pair programming
No proof that pair programming works
Fear of failure
No experience of pair programming
No time to experiment
No slack
Push instead of pull
Root Cause
Lack of trust
24
Real-life exampleThe big picture
Problem
Understand the problem before you try to solve it!
Crashing demos
A
B
causes
Bad code quality
(etc)
(etc)
No pair programming
Lack of test automation
(etc)
Lack of trust
Root Cause
25
Another real-life example
Addressed by ScrumXP
root cause
problem
Teams not focused
mentioned
Teams dont have own PO
PO doesnt have own team
implied
Teams not business- oriented
vicious cycle
Ineffective requirements communication
Team not getting feedback from customer
Unclear roles responsibilities
Teams grouped by component
Too much focus on written specs
Lack of team spirit
Lack of discipline in teams
Feature split across multiple teams
Hard to plan
Delayed releases
Lack of transparancy
No burndowns
Bad throughput in development
Sometimes Agile will solve lots of problems
Fear of committing
Not measuring velocity
Cutting quality instead of scope
Problems estimating
Difficult to release
Teams disrupted during sprint
Hard to change the code
Many defects
Lack of test automation
Many operational problems
Customers dissatisfied
26
The illusion of a bad tool
Template
Example 1
Example 2
We failed because of X
We failed because the requirements kept changing
We failed because the customer kept disrupting
the team
Possible conclusions
X is bad! We should forbid X
We should resist change
We should lock the door
We shouldremove the need for X
We should spend more time on requirementsup-front
, so they dont need to change
We should lessen the need for disruptions by
doing shorter iterations
We shouldanticipate X
We should have a change-friendly process
We should double all our estimates
27
The illusion of a good tool
We succeeded thanks to Scrum!
Placebo effect The tendency of any medication or
treatment,even an inert or ineffective one, to
exhibit results simply because the recipient
believes that it will work.
Really?
Hawthorne effect A form of reactivity
wherebysubjects improve an aspect of their
behavior being experimentally measured, simply in
response to the fact that they are being
studied,not in response to any particular
experimental manipulation.
It was suggested that the productivity gain was
due to the motivational effect of the interest
being shown in them
Sources http//en.wiktionary.org/wiki/placebo_ef
fect http//en.wikipedia.org/wiki/Hawthorne_effect

28
Are there no universallyGood or Bad tools?
You can fail despite a great tool
You can succeed despite a lousy tool

• Probably not.
• But some are pretty close.
• Almost universally good tools
• Visualize the workflow
• Limit work in progress
• Focus on quality
• Prioritize
• Short feedback loops

http//www.crisp.se/henrik.kniberg/Kanban-vs-Scrum
.pdf
Kanban
29
The Thinking Tool called Agile
Agile is Simple but Hard
... like chess
... and piano playing
30
Scrum in a nutshell
Split your organization
Split your product
Large group spending a long time building a big
thing Small team spending a little time building
small thing ... but integrating regularly to see
the whole
Optimize process
Optimize business value

Split time
April
January

31
Kanban in a nutshell
To do
Dev
Release
Test
Done!
3
3
5
2

• Visualize the workflow
• Limit WIP (work in progress)
• Measure optimize flow

F
H
C
D
A
I
E
G
B
J
K
FLOW
32
Agile is simple but hard
You call that simple?
... and maybe some on DSDM and Crystal and Lean
while youre at it.
Simple is hard
... and Scrum...
... and XP
A few books on Agile...
33
Agile is empirical
Capacity (aka velocity)
Lead time (aka cycle time)
Quality (defect rate, etc)
Predictability (SLA fulfillment, etc)
Learn by doing, watching others doing, and
reflecting.
Many small teams
Few large teams
Experiment!
Low WIP limits
High WIP limits
Few workflow states
Many workflow states
Short iterations
Long iterations
Little planning
Lots of planning
.... etc ...
.... etc ...
34
Dont be dogmatic
Go away! Dont talk to us! Were in a sprint.
Come back in 3 weeks.
Though Shalt Be Agile
35
Take-away pointsTo succeed with integrating
agile

• Know your Goal.
• Agile is a tool, not a goal
• Tools dont fail or succeed. People do.
• There is no such thing as a good or bad tool.
  Only good or bad decisions about when, where,
  how, and why to use which tool.
• Dont limit yourself to one tool
• Learn as many tools as possible.
• Compare for understanding, not judgement.
• Focus on Why, not How.
• Experiment enjoy the ride
• Dont worry about getting it right from start.
  You wont.
• The only real failure is the failure to learn.