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
[email protected]
+46 70 4925284
 Scrum is an iterative,
incremental process for
What is all this stuff? developing any product
or managing any work

XP is a discipline of
software development TDD Ken Schwaber
Scrum is a
methodology (a set of

Scrum
process tools and

XP RUP is a
comprehensive
techniques)

process framework
Ron Jeffries XP is a Scrum is an Agile

RUP
software development
engineering framework
methodology
Jeff Sutherland

Kanban is a signalling
system to trigger action Kanban Agile is a tool, not an
excuse.

The term 'agile' refers to

Lean manufacturing is a a philosophy of
Robert C Martin
software development

Agile
generic process
management philosophy

Lean CMMI
Lean is a system designed to
provide the tools for people to
continually improve their Martin Fowler
Jeffrey Liker work. Agile is a development
approach that primarily
addresses the problems
Henrik Kniberg of rapid change 2
Alistair Cockburn
How do they relate to each other?

Lean Fork
Knife
Agile Toothpick

Scrum
Kanban
XP

Let’s just say !?

These are all tools!

Henrik Kniberg 3
 Thinking tools
a.k.a. ”mindsets” or ”philosophies”
Tool Agile Systems Thinking Toolkits
”anything used as a means of Lean
a.k.a. ”frameworks”
accomplishing a task or purpose.” Theory of Constraints
- dictionary.com RUP XP
Scrum
Physical tools Kanban

Process tools
a.k.a. ”organizational patterns”

Product Owner role

Pair programming

Visualize the workflow

To do Dev Test Release Done!
5 3 2 3

H D C A
G
B

FLOW

Henrik Kniberg 4
 Always works!

Is Agile always right?

Actual greatness vs expected greatness I told you it
ss
t ne wouldn’t work!
rea
g
Silver ed
bullet! ect
p
Ex
Works!

Pretty Majority of pracitioners experience:

Actual greatness -Improved productivity
good
Agile projects 60-80% success rate -Reduced Time to market
Greatness (compared to industry average 30%) -Reduced defect rate
-Reduced cost
level Pretty
bad

Will never work!

Useless ss
t ne
ea
gr
t ed
Harmful p ec
Ex

y2000 Time y2010

Sources:
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
http://www.ambysoft.com/surveys/agileFebruary2008.html

Henrik Kniberg 5
 Guess the company
What is un-Agile? Brilliant process management is our strategy.

We get brilliant results from average people

managing brilliant processes.

The right process will produce the right

results

Requirements Acceptance test

System design System test

Architecture Integration test

Module design Unit test

Coding

Henrik Kniberg 6
 Brilliant process management is our

Toyota 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

Henrik Kniberg 7
 Toyota uses
”waterfall” 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.

Henrik Kniberg 8
 ”Managing the development of large

What is ”waterfall” anyway? 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

Good ”un-Agile” may be – the involvement should be
better than bad ”Agile”! formal, in depth, and continuing

Henrik Kniberg 9
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
Henrik Kniberg 10
Typical pre-scrum organizations

Ad-hoc / unknown Waterfall Component teams

Requirements DB

Design Server

Code Client

Test GUI

Henrik Kniberg 11
Scrum scenario 1
1. Waterfall 2. ”ScrumButt” 3. Scrum

PO
Requirements Requirements

Feature Feature
team 1 team 2

Design Design & code

The important thing is

not where you are, but
where you are going!
Code

Test Test

Henrik Kniberg 12
Scrum scenario 2 Scrum is a tool, not a goal

“We couldn’t agree on who sets

priorities, so we skipped PO
role.”

Feature Feature
team 1 team 2
That’s ScrumButt!
You’re just hiding
from the problem!

Impressive, you have so

good collaboration that you
can manage without a
designated PO!

Henrik Kniberg 13
 Agile doesn’t require
timeboxed iterations!
Scrum scenario 3
Step 1 Step 2 Step 3

Feature Feature Feature Feature Feature Feature Feature Feature Feature

team 1 team 2 team 2 team 1 team 2 team 2 team 1 team 2 team 2
Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum

Operations / support team Operations / support team

Scrum Kanban

Henrik Kniberg 14
 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 Agile
in your context

Henrik Kniberg 15
So is Agile always right?
Agile methods aren’t
Are agile values always right? always agile
Gut feel: Usually, yes. Agile methods aren’t the
Fact: Don’t know only way to be agile
Agile is a tool, not a goal

Never blame the tool!

Is agile method
<insert your favorite method
here> always right? What is the cause of this problem?
No! Scrum sucks! It
didn’t work for us!

Why did you

use it?

Because the %&£$

Pete Scrum trainer
convinced us! Ola

Henrik Kniberg 16
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?

Henrik Kniberg 17
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!

18

Henrik Kniberg 18
 Tools must be combined.
No single tool is complete.

Prescriptive vs Adaptive tools Compare tools for

understanding, not for
judgement.
More prescriptive More adaptive
RUP XP Scrum Kanban Do Whatever
(120+) (13) (9) (3) (0)
• Architecture Reviewer • Business use case realization
• Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow
• Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP
• Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time
• Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting
• Change Control Manager • Configuration management plan • Customer tests • Daily Scrum
• Code Reviewer • Data model • Pair programming • Sprint review
• Configuration Manager • Deployment model • Refactoring • Product backlogt
• Course Developer • Deployment plan • Planning game • Sprint backlog
• Database Designer • Design guidelines • Continuous integration • BUrndown chart
• Deployment Manager • Design model • Simple design
• Design Reviewer • Development case • Sustainable pace
• Designer • Development-organization • Metaphor
• Graphic Artist assessment • Small releases
• Implementer • End-user support mateirla
• Integrator • Glossary
• Process Engineer • Implementation model
• Project Manager • Installation artifacts
• Project Reviewer • Integration build plan
• Requirements Reviewer • Issues list
• Requirements Specifier • Iteration assessment
• Software Architect • Iteration plan
• Stakeholder • Manual styleguide

Do not develop an attachment

• System Administrator • Programming guidelines
• System Analyst • Quality assurance plan
• Technical Writer • Reference architecture
• Test Analyst • Release notes

to any one weapon

• Test Designer • Requirements attributes
• Test Manager • Requirements
• Tester management plan
• Tool Specialist • Review record

or any one school of fighting

• User-Interface Designer • Risk list
• Architectural analysis • Risk management plan
• Assess Viability of architectural • Software architecture
proof-of-concept document
• Capsule design • Software development
• Class design plan
• Construct architectural proof-of- • Software requirements specification
concept • Stakeholder requests
• Database design • Status assessment
• Describe distribution • Supplementary business
• Describe the run-time architecture specification
• Design test packages and classes • Supplementary specification
• Develop design guidelines • Target organization assessment
• Develop programming guidelines • Test automation architecture
• Identify design elements • Test cases
• Identify design mechanisms • Test environment configuration
• Incorporate design elements • Test evaluation summary
• Prioritize use cases • Test guidelines
• Review the architecture • Test ideas list
• Review the design • Test interface specification
• Structure the implementation model • Test plan
• Subsystem design • Test suite
• Use-case analysis • Tool guidelines
• Use-case design • Training materials
• Analysis model • Use case model
• Architectural proof-of-concept • Use case package
• Bill of materials • Use-case modeling guidelines
• Business architecture document • Use-case realization
• Business case • Use-case storyboard
• Business glossary • User-interface guidelines
• Business modeling guidelines • User-interface prototype

Henrik Kniberg
•
•
•
Business object model
Business rules
Business use case
•
•
•
Vision
Work order
Workload analysis model
Miyamoto Musashi 19
17th century samurai
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?

Henrik Kniberg 20
 Are
Are you
you staying
staying in
in business
business so
so you
you
can
can earn
earn money?
money?

Sample goal - Toyota Or

Or are
are you
stay
you earning
earning money
money soso you
you can
can
stay in
in business?
business? (Toyota)
(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-san’s slides during our ”Lean Study Tour” to Toyota,
Henrik Kniberg April 2009. 21
Real-life example
What is the problem?
Problem
Crashing demos
A causes B

Bad code quality

Why?
(etc) Lack of test No pair
(etc)
(etc) automation programming

Our problem is that we’re not

doing XP practices like TDD
and pair programming.

Really?

Henrik Kniberg 22
 Why?
Not pair programming
Real-life example
What is causing the problem?
No ”proof” that pair
Fear of failure programming works

No experience of
pair programming

No time to
experiment

No slack

Push instead
Root Cause of pull

Lack of trust
Henrik Kniberg 23
Real-life example
The big picture Problem
Understand the problem
Crashing demos before you try to solve it!
A causes
B

Bad code quality

(etc) Lack of test No pair

(etc)
(etc) automation programming

Lack of trust
Root Cause

Henrik Kniberg 24
 = Addressed by Scrum+XP
= root cause
Another real-life example = problem
Teams not
focused Teams don’t have = mentioned
own PO PO doesn’t have
Teams not own team = implied
business-
oriented
Team not getting Ineffective = vicious cycle
feedback from requirements
customer communication Unclear roles &
responsibilities
Teams grouped
Too much focus
by component
Lack of team on written specs
Lack of discipline
spirit
in teams

Feature split across Hard to Lack of No

multiple teams Delayed releases
plan transparancy burndowns

Fear of
Bad throughput in
development
Sometimes Agile will
committing solve lots of problems
Not
Problems Cutting quality
measuring
estimating instead of scope Difficult to
velocity
release

Teams disrupted Hard to

during sprint Many Lack of test change the
defects automation code

Many operational Customers

problems dissatisfied

Henrik Kniberg 25
The illusion of a ”bad tool”
Template Example 1 Example 2
We failed because the We failed because the
We failed because of X requirements kept customer kept
changing disrupting the team
Possible conclusions:
X is bad! We should
We should resist change We should lock the door
forbid X
We should spend more
We should lessen the
We should time on requirements
need for disruptions by
remove the need for X up-front, so they don’t
doing shorter iterations
need to change

We should We should have a We should double all our

anticipate X change-friendly process estimates

Henrik Kniberg 26
The illusion of a ”good tool”
We succeeded
thanks to Scrum!
Placebo effect
The tendency of any medication or treatment,
Really? even an inert or ineffective one, to exhibit results
simply because the recipient believes that it will work.

Hawthorne effect
A form of reactivity whereby
subjects 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_effect
http://en.wikipedia.org/wiki/Hawthorne_effect

Henrik Kniberg 27
 You can fail despite a
great tool
Are there no universally You can succeed despite
Good or Bad tools? a lousy tool

Probably not.
But some are pretty close.
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

Almost universally good tools:

Visualize the workflow
Kanban
Limit work in progress
Focus on quality
Prioritize
Short feedback loops

Henrik Kniberg 28
The Thinking Tool called Agile
Agile is Simple but Hard

... like chess

... and piano playing

Henrik Kniberg 29
 Split your organization

Scrum in a nutshell
Split your product

Optimize process
Optimize business value

$$$

Split time
January April

Not
checked out Done! :o) SPRINT GOAL: Bet a-ready release!
checked out
Write
Deposit failing

2d
test Burndown
DAO
Code Integr
p DB
cleanu tes t
2 d 0 .5d design
1d
2d
1d

GUI Write

Migrat ion spec

2d
failing
2d test
1d 3d

tool Tap estr

spi ke
y

Im pl . 1d
2d
migration
8d

Backoffice Write
failing
test

Login
Integr .
Impl
GUI
2d
Unplanned it ems Next
1d
with
JBoss
2d

Write
Fix m emor
leak
y
Sales support PW it hdraw
erf t est
Backoffice
failing
test
Write
(JIRA
2d
failing
test
12 5)
3d
Withdraw
3d Write
whitepaper
User admin 4d

GUI
Clarify
design Impl
require-
(CS S ) GUI
ments
1d 2d 6d

Henrik Kniberg 30
Kanban in a nutshell
To do Dev Test Release Done!
5 3 2 3

Visualize the workflow H F D C

A
I G E
Limit WIP (work in progress) J
B

K
Measure & optimize flow
FLOW
FLOW

Henrik Kniberg 31
 You call that
simple? ... and maybe
some on DSDM
Agile is simple Simple is hard
and Crystal and
Lean while you’re
but hard ... and Scrum...
at it.

A few books on Agile... ... and XP

32
Henrik Kniberg
Agile is empirical

Capacity Lead time Quality Predictability

(aka velocity) (aka cycle time) (defect rate, etc) (SLA fulfillment, etc)

Learn by doing,
watching others doing,
and reflecting.
Many small teams Few large teams

Low WIP limits High WIP limits

Experiment!

Few workflow states Many workflow states

Short iterations Long iterations

Little planning Lots of planning

.... etc ... .... etc ...

Henrik Kniberg 33
Don’t be dogmatic

Go away! Don’t talk to us!

We’re in a sprint.

Come back
in 3 weeks. Though Shalt
Be Agile

Henrik Kniberg 34
Take-away points
To succeed with integrating agile:
To do Dev Test Release Done!

Know your Goal. 5

H
3 2
D
3

C A
G

Agile is a tool, not a goal

B

Tools don’t fail or succeed. People do. FLOW

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.
Don’t 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
Don’t worry about getting it right from start. You won’t.
The only real failure is the failure to learn.

Henrik Kniberg 35