vad är ett agilt projekt?
DESCRIPTION
Vad är ett agilt projekt?. PMI Oct 26, 2010. Henrik Kniberg Agile/Lean coach www.crisp.se. [email protected] 070 4925284. Board of directors. What is all this stuff?. TDD. Scrum. XP. Continuous Integration. Kanban. Pair programming. Refactoring. Lean. Agile. - PowerPoint PPT PresentationTRANSCRIPT
Board of directors
Henrik KnibergAgile/Lean coach
www.crisp.se
Vad är ett agilt projekt?
PMIOct 26, 2010
070 4925284
2Henrik Kniberg 2
Lean
XPScrum
Agile
TDD
KanbanContinuous Integration
What is all this stuff?
Pair
programmin
g
Refactoring
3
What have we learned?
3
4
Many SW projects are like a cannon ball
Henrik Kniberg
Assumptions:The customer knows what he wantsThe developers know how to build itNothing will change along the way
5
Most IT projects don’t succeed
Henrik Kniberg 5
IT project success rate 1994: 15% Average cost & time overrun: ≈170%
IT project success rate 2004: 34% Average cost & time overrun: ≈70%
The Standish Group has studied over 40,000 projects in 10 years.
Sources:http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Plan: €1,000,000
Actual: €2,700,000
Plan: €1,000,000
Actual: €1,700,000
6
How estimates are affected by specification length
2007-09-28
117 hrs 173 hrs
Spec Same spec – more pages
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
7
How estimates are affected by irrelevant information
2007-09-28
20 hrs
Spec 1
A
B
C
Same spec+ irrelevant details
A
B
C
39 hrs
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
8
How estimates are affected byextra requirements
2007-09-28
4 hrs
Spec 1
A
B
C
D
Spec 2
A
B
C
D
E
4 hrs
Spec 3
A
B
C
D
E
8 hrs
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
9
How estimates are affected by anchoring
2007-09-28
456 hrs
Spec
500 hrsNever mind me
Same spec
555 hrs
50 hrsNever mind me
Same spec
99 hrs
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
10
We tend to build the wrong thing
Henrik Kniberg 1010
Sources:Standish group study reported at XP2002 by Jim Johnson, Chairman
Always7%
Often13%
Some-
times16%
Rarely19%
Never45%
Features and functions used in a typical system
Half of the stuff we build is
never used!
Com
plex
ity
Cost
# of features
This graph courtesy of Mary Poppendieck
11
Less is more
Henrik Kniberg 11
”Perfection is attained,not when there is nothing more to add,but when there is nothing left to take away”- Antoine de Saint-Exupery
12
What have we learned?
Henrik Kniberg 12
“Doing projects with iterative processes as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”
IT project success rate 1994: 15% Average cost & time overrun: ≈170%
IT project success rate 2004: 34% Average cost & time overrun: ≈70%
“The primary reason [for the improvement]is that projects have gotten a lot smaller.”
Jim JohnsonChairman ofStandish Group
Top 5 reasons for success1. User involvement2. Executive management support3. Clear business objectives4. Optimizing scope5. Agile process
Sources:http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS”My Life is Failure”, Jim Johnson’s book
“There is no silver bullet but agile methods come very close”
Scope
Cost Time
Quality
1313
Agile in a nutshell
14Henrik Kniberg 14
Agile Manifesto
www.agilemanifesto.orgWe are uncovering better ways of developing software by doing it and helping others do it.
Feb 11-13, 2001Snowbird ski resort, Utah
Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon Jeffries
Jon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas
15Henrik Kniberg 15
Agile Manifestowww.agilemanifesto.org
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Individer och interaktioner framför processer och verktyg
Working software over comprehensive documentation
Fungerande programvara framför omfattande dokumentation
Customer collaboration over contract negotiationKundsamarbete framför kontraktsförhandling
Responding to change over following a planAnpassning till förändring framför att följa en plan
That is, while there is value in the items on the right, we value the items on the left more.
16
Principles behind the Agile ManifestoOur highest priority is to satisfy the
customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
17
Agile ”umbrella”
Sources:3rd Annual ”State of Agile Development” Survey June-July 2008• 3061 respondents• 80 countries
Scrum XPDSDM
FDD
Crystal
Kanban
18
Agile is like a homing missile
Henrik Kniberg
Assumptions:The customer discovers what he wantsThe developers discover how to build itThings change along the way
Req.
Design Code Test
Principle #2:Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Kent Beck
Embrace Change!
19
A
Henrik Kniberg
C D
TimeboxingA
Plan
Traditional scenario
Agile scenario
Week 1 Week 2 Week 3 Week 4
B
C D
A
Week 1 Week 2 Week 3 Week 4
B
Week 5 Week 6 Week 7 Week 8
A
Week 1 Week 2 Week 3 Week 4
B
Week 5 Week 6
A B
”We will deliver ABCD in 4 weeks”
”We always deliver something every sprint (2 weeks)””We think we can finish ABCD in 4 sprints, but we aren’t sure””We always deliver the most important items first”
(doomed to fail, but we don’t know it yet)
Oops, we’re late.
Oops, we only finished AB.Our velocity is lower than we
thought. What should we do now?
Scope
Cost Time
Quality
Scope
Cost Time
Quality
X XX
E
20
Planning is easier with frequent releases
Henrik Kniberg 20
21
Scrum in a nutshell
21
22
Scrum in a nutshell
Henrik Kniberg 22
January April
Split your organization
Split your product
Split time
Optimize business valueOptimize process
$
$$$
Burndown
Unplanned items
Notchecked out Done! :o)
Write f ailing test
DAO
DB design
I ntegr test
Migration tool
Write f ailing test
GUI spec
Tapestry spikeI mpl.
migrat ion
2d
Code
cleanup
Deposit
2d1d 0.5d1d
2d
8d
1d2d
2d
BackofficeLogin
BackofficeUser admin
Write f ailing test
3d
2d
1d2d
I mpl GUI
1dI ntegr. with
J Boss2d
Write f ailing test
3d
I mpl GUI
6d
Clarif y require-ments
2d
GUI design (CSS)
1d
Fix memory leak(J I RA 125)2d
Sales support
3d Write whitepaper
4d
SPRINT GOAL: Beta-ready release!
Next
WithdrawPerf testWithdraw
checked out
Write f ailing test
Large group spending a long time building a huge thingSmall team spending a little time building a small thing
... but integrating regularly to see the whole
23
Product owner- Vision: Where are we going & why?- ROI- Priorities & tradeoffs
Henrik Kniberg 23
Scrum overview – structure
POSM
Users
Stakeholders
Helpdesk
Operations
Management
ProductBacklog
SprintBacklog
... etc ...
Team
Direct communication
Scrum Master- Process leader/coach- Impediment remover
Cross-functional,self-organizing Team- How much to pull in- How to build it- Quality- Sustainable pace
24
As a bookerI want to receive notifications when new available slots appear in the calendarso that I don't have to keep checking manually
Henrik Kniberg 24
Product backlog
ProductBacklog
Product vision
As a <stakeholder> I want <what> so that <why>
As a buyerI want to save my shopping cartso that I can continue shopping later
(... etc ...)
Definition of Done• Releasable
• User Acceptance tested• Merged to Trunk• release notes written• No increased technical debt
= I haven’t messed up the codebase
GUI
Client
Server
DB
25
Agile estimating strategy
Don’t estimate time.Estimate relative size of stories.Measure velocity per sprint.Derive release plan.
Estimates done by the people who are going to do the work.
Not by the people who want the work done.Estimate continuously during project, not all up front.Prefer verbal communication over detailed, written specifications.Avoid false precision
Better to be roughly rightthan precisely wrong
Henrik Kniberg 25http://planningpoker.crisp.se
26
As a bookerI want to receive notifications when new available slots appear in the calendarso that I don't have to keep checking manually
Henrik Kniberg 26
Planning poker
As a buyerI want to save my shopping cartso that I can continue shopping later
2
52
5
3
2
2
?
27
Typical sprint
Week 1 Week 2 Week 3
Timeline
Iteration1
Sprint-planning
Demo/ReviewRetrospective
ProductBacklog
Daily ScrumBurndown
Unplanned items
Notchecked out Done! :o)
Write f ailing test
DAO
I ntegr test
Write f ailing test
GUI spec
I mpl. migration
2d1d
8d
2d
2d
BackofficeLogin
BackofficeUser admin
Write f ailing test
1d2d
I mpl GUI
I ntegr. with
J Boss
Write f ailing test
I mpl GUI
Clarif y require-ments
Sales support
3d Write whitepaper
4d
SPRINT GOAL: Beta-ready release!
Next
Withdraw
checked out
Write f ailing test
release1.3.0
PO
Sprint plan(Task board / Scrum board)
Henrik Kniberg
28
Backlog creation & grooming– sample schedule
Henrik Kniberg 28
Initial backlog creation Backlog workshop every Wednesday 10:00 –
11:00Backloggroomingcycle
Sprint cycle
Sprint 1 Sprint 2 Sprint 3
Timeline
29
Velocity
Henrik Kniberg 29
Sprint 1 Sprint 2 Sprint 3
Likely future velocity:7-9 per sprint
2
2 3
1 2
31 1 2 2 1
1 1 2
V= 8 V= 7 V= 9
302007-09-28
Release planning – fixed date• Today is Aug 6
• Sprint length = 2 weeks• Velocity = 30 - 40
(10 sprints)
300
400PO
What will be doneby X-mas?
Scope
Cost Time
Quality
31
Release planning – fixed scope
Henrik Kniberg 31
100
200
300
400
Work remaining(story points)
Sprint
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
We’ll be done around sprint
14-16
Release burndown chart When will all ofthis be done?
PO
Scope
Cost Time
Quality
32
Scrum scaling example
32
33
Example: Simplest possible Scrum organization
Henrik Kniberg
ScrUML(inofficial Scrum Modeling Language)
34
Example: multiple teams
2007-09-28
35
Example: multiple product owners
2007-09-28
36
Case study: Stopping a death march 3
6
37
Symptom: Waterfall process (under Scrum banner)
Henrik Kniberg 37
20072006 Requirements
Coding
Testing?Release
We are here
Q1 Q2 Q3 Q4 Q1 Q2
38
Symptom: Long, detailed requirements specifications
Henrik Kniberg 38
39
Symptom: Lack of trust & commitment
Henrik Kniberg 39
40
Strategy: Implement Scrum
Henrik Kniberg 40
Show us where we standHelp us move faster
Create product backlog
Estimate product backlog
Execute 2 sprints, measure velocity
2007
Jan Feb
We are here
41
Step 1: Change Definition of Done
Old definition of done:Code checked in
New definition of done:Releasable
Tester added to team
Henrik Kniberg 41
To doDoing DoneRegister
DepositWithdra
w
Transfer
42
Step 2: Create a product backlog
Henrik Kniberg 42
Features left to implement Features implemented but not tested & integrated
feature Xfeature X
feature X
feature X
feature X
feature X
feature X
feature X
feature Xfeature X
feature X
feature X
feature X
feature X
feature X
feature X
feature X
feature X
feature Xfeature X
feature Xfeature X
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature YTest/integr
feature Y
Test/integrfeature Y
PO
43
Step 3: Estimate product backlog
Henrik Kniberg 43
Features left to implement Features implemented but not tested & integrated
2
5
3
2
2
?
Total:180 points
Total:70 points
feature Xfeature X
feature X
feature X
feature X
feature X
feature X
feature X
feature Xfeature X
feature X
feature X
feature X
feature X
feature X
feature X
feature X
feature X
feature Xfeature X
feature Xfeature X
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature Y
Test/integrfeature YTest/integr
feature Y
Test/integrfeature Y
44
Step 4: Execute 2 sprints
Henrik Kniberg 44
EstimatedVelocity
ActualVelocity
30 925 10
Sprint 1
Sprint 2
45
Step 5: Face reality & Revise the plan
Henrik Kniberg 45
Backlog = 230 pointsVelocity = 10 points/sprint
23 sprints> 1 year until release!
2007Promised release
Q1Q1 Q2 Q3 Q4
2008 Earliest likely release
Q2
We are here
46
Step 6: Act
Henrik Kniberg 46
Backlog = 230 pointsVelocity = 10 points/sprint
Fix impedimentsPressure on teamIneffective build & test environmentLack of teamwork, discipline & motivationDisruptions & context switchingUnrealistic expectationsROOT CAUSE: Company not focused
Reduce
Increase
Reduce total scopeIncremental releases
Overall priorities1. Operations2. Project X3. Anything
else
47
Result
Henrik Kniberg 47
2007Originally promised release(big-bang)
Q1Q1 Q2 Q3 Q4
2008Earliest likely release if process hadn’t changed(big-bang)
Actual release(incremental)
Actual release(incremental)
Velocity
10
20
30
9-10
25-30estimated
actual
Q2
Q1 Q2 Q3
2007
48
Case study: Take-away pointsWaterfall is still waterfall even if you call it Scrum
Know your tools, get training & coaching early.Don’t believe your plan
There is no ”the plan must be right because we promised”.Make sure you have reliable feedback loops & a changeable plan.
There is no ”too low velocity”Just actual velocity, and a realistic or unreleastic plan.
Build quality inDon’t postpone test & integration, that gives a false velocity.
Having good people isn’t enoughAn inappropriate process can cause even a great team to fail.
Dramatic improvements can be made quicklyWith a strong management team that has access to empirical data and is willing to focus.Henrik Kniberg 48
49
Agile contracts
49
50
Contracts
Henrik Kniberg 50
Fixed everything(price / scope / time)
Time & materials($ per iteration)
Money for nothing, change for free
More agileLess agile
Requires trust
Problem: Trust requires trust
Scope
Cost TimeQ
Scope
Cost Time
Quality Scope
Cost TimeQ
Scope
Cost TimeQ
51
Money for nothing, change for free
Henrik Kniberg 51
Always7%
Often13%
Some-
times
16%
Rarely19%
Never45%
Features and functions used in a typical system:
Source: Standish Group Study Reported at XP2002by Jim Johnson, Chairman
Unnecessary features thatshouldn’t be in(but we don’t know which)
Importantant features that should be in(but we don’t know which)
”Req””Req”
Price: 10 MTime: 1 yearScope:
Contract
Option #1
”Change for free” as long as total scope doesn’t increase
Option #2
”Early termination”Customer can end project early.Costs only 20% of remaining budget.
52
Change for free
ROI
Time
Skip this one!
Want to raise prio of this one!
Need this one too!
Option #1
”Change for free” as long as total scope doesn’t iincrease
53
Customer saves 80% of remaining budget
Supplier gets 20% av remaining budget
Early termination
End project!
Option #2
”Early termination”Customer can end project early.Costs only 20% of remaining budget.
ROI
Time
ROIcutoff
Plan:• Price: 10 M• Time: 12 months
Result:• Price: 5+1 M• Time: 6 months
54
Money for nothing, change for free
Henrik Kniberg 54
Always7%
Often13%
Some-
times
16%
Rarely19%
Never45%
Features and functions used in a typical system:
Source: Standish Group Study Reported at XP2002by Jim Johnson, Chairman
Unnecessary features thatshouldn’t be in(but we don’t know which)
Importantant features that should be in(but we don’t know which)
”Req””Req”
Price: 10 MTime: 1 yearScope:
Contract
Option #1
”Change for free” as long as total scope doesn’t iincrease
Option #2
”Early termination”Customer can end project early.Costs only 20% of remaining budget.
55
Contracts
Henrik Kniberg 55
Fixed everything(price / scope / time)
Time & materials($ per iteration)
Money for nothing, change for free
More agileLess agile
Scope
Cost TimeQ
Scope
Cost Time
Quality Scope
Cost TimeQ
Scope
Cost TimeQ
56
LimitWork in Progress (WIP) 5
6
57
N R I K
Ö R G E N
O H A N
N D E R S
A N I E L
How long does it take to write a name?
Henrik Kniberg 57
10s 20s 30s 40s 50s 60s 70s
HenrikJohan
Anders
Jörgen
Daniel
10s 20s 30s 40s 50s 60s 70s
H E
J
J
A
D
10s 20s 30s 40s 50s 60s 70s
Never keep aCustomerwaiting
Start early= Finish early
JO
A
J
D
HE
JOH
HENRIK HenrikJohan
Anders
Jörgen
Daniel
Limit WIP
Current limit:1 customerat a time
58Henrik Kniberg 58
Bail water
Water in boat
Hole in boat
Fix hole
Fix problems, not symptoms
59
Case study: Cross functional teams 5
9
60
Before
Sam
Concept pres.
Lisa assigns resource
s
Graphics
design
Sound
design
DevIntegr. & deploy
2d 1m 4h
6m
8
Game backlog
1w 6m
6m
15
Design-ready games
12
Production-ready games
1m
3w 3m 3w2h 1d(1m+2m)
3 m value added time25 m cycle time
= 12%Process cycle efficiency
61
Limit work to capacity
Input: 3 customers / hour Output capacity: 2 customers / hour
62
Before
Sam
Concept pres.
Lisa assigns resource
s
Graphics
design
Sound
design
DevIntegr. & deploy
2d 1m 4h
6m
8
Game backlog
1w 6m
6m
15
Design-ready games
12
Production-ready games
1m
3w 3m(1m+2m)
3w2h 1d
Cross-functional game team
3-4 m cycle time = 6-8x faster
Game team(graphics, sound, dev, integrate)
3-4 months
3 m value added time25 m cycle time
= 12%Process cycle efficiency
After
63
Case 2 – Key points
Speeding up product development is usually a matter of improving the process rather than adding people.Value stream mapping is a great tool for spotting bottlenecksPush scheduling + too much WIP (work in progress)is usually the root cause
Scrum & Kanban = two good approaches to fix thisBeware suboptimization!
Henrik Kniberg 63
”Hey, let’s do Scrum here! Maybe we can
cut OUR time in half!”
w2w1 w4w3 w6w5 w8w7
Case 2: Speeding up product develompent
”Cross-functional teams are no good, that will make OUR work take longer!”
SamConcept
pres.
Lisa assigns
resources
Graphics design
Sound design
DevIntegr. & deploy
2d 1m
4h
6m 1w 6m 6m
1m 3w 3m(1m+2m)
3w2h 1d
8 15 12
64
Cross-functional teams
Henrik Kniberg 64
DaveJoe Lisa
Dave
Joe
Lisa
January February March April May June July
6 months
3 months
Release
Release
We’re alot faster!
I’m a bitslower
We’re slow!I’m fast!
65
XP in a nutshell
65
66
Scrum”wraps”XP
2007-09-28
Henrik Kniberg 66
SprintPlanningmeeting
Daily Scrum
Sprint Review
Sprintbacklog
Productbacklog
TDD
Pair programming
Refactoring
Simpledesign
Coding standard
SustainablePace
Metaphor
Continuous
Integration
Collective
ownership
Whole team
Planning game
Small releases
Customer tests
Burndownchart
Productowner
Team
ScrumMaster
Scrum
XP
67
Feedback loops
Henrik Kniberg
Pair programmin
g
Continuous integration
Daily Scrum
Sprint review
Unit test
68
Continuous Integration
Henrik Kniberg 68
Req Code Test
Release!Traditional ”big bang” integration
Continuous integration
69
Agile architecture
Henrik Kniberg 69
F F F F
F F F F
F
Architecture
F
F
A
F
A
F
A
F
A
F
A
F
A
Don’t do: Quick ’n dirty features=> Slow ’n dirty=> Entropy death? Big bang rewrite?
Don’t do: Big Up Front Design
F
A
F
A
F
A
F
A
Do: Find a balance
Timeline
70
Kanban in a nutshell
70
71
Which team needsmost improvement?
Henrik Kniberg 71
Team 1 Team 2
Todo Doing
Donethis week
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse cteturorem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
Avg lead time: days
3
Todo Doing
Donethis week
orem ipsum dolor sit amet, co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Avg lead time: days
20
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse cteturorem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum
dolor sit amet,
co nse cteturorem ipsum dolor sit amet, co nse ctetur
Russel Ackoff
Managers who don’t know how to
measure what they wantsettle for
wanting what they can measure
72
Kanban @ Imperial Palace Gardens
Henrik Kniberg 72
73
Kanban
Signaling systemVisualLimited in supply
Henrik Kniberg 73
看板”Visual Card”
74
Kanban in your wallet
Henrik Kniberg 74
Darn. Forgot to limit the
supply.
75
Kanban in SW development
Henrik Kniberg
Backlog
Dev Done
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum dolor sit amet, co nse cteturorem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse cteturorem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
UAT Deploy5 3 2 3
FLOW Avg lead time: days 12
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Visualize the workflowLimit WIP (work in progress)
Measure & optimize flowExplicit policies (definition of Done, WIP limits, etc)
Pioneered byDavid Andersonin 2004
76
Kanban exampleBoard shared by several teamsCovers whole value streamfrom concept to release
Henrik Kniberg 76
77
One day in Kanban land
77
78
”One day in Kanban land”
Henrik Kniberg 78
http://blog.crisp.se/henrikkniberg/tags/kanban/
79
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 1 – one piece flow
Henrik Kniberg 79
B
C
A
D
E
F
G
H I
J LKM
80
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 1 – one piece flow
Henrik Kniberg 80
BC
A
D
E
F
G
H I
J LKM
81
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 1 – one piece flow
Henrik Kniberg 81
BC
A
D
E
F
G
H I
J LKM
82
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 1 – one piece flow
Henrik Kniberg 82
B
C A
D
E
F
G
H I
J LKM
83
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 1 – one piece flow.
Henrik Kniberg 83
B
C A
D
E
F
G
H I
J LKM
84
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 84
B
C
A
D
E
F
G
H I
J LKM
PO
85
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 85
BC
A
D
E
F
G
H I
J LKM
PO
86
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 86
B
C A
D
E
F
G
H I
J LKM
PO
87
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 87
B
C A
D
E
F
G
H I
J LKM
PO
88
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 88
B
C A
D
F
G
H I
J LKM
!?
E
PO
89
NexetDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 89
B
C
A
D
EF
G
H I
J LKM
!?
PO
90
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 90
B
C
A
D
EF
G
H I
J LKM
PO
91
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 91
B
A
D
EF
G
H I
J LKM
C
PO
92
NextDev
Done
Backlog 32
In production :o)Ongoing
Scenario 2 – Deployment problem
Henrik Kniberg 92
B
AD
EF
G
H I
J LKM
C
PO
93
Kanban board evolution
93
94
Kanban evolution example
Henrik Kniberg 94
April 7
April 23
2009-08-29
orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl
2009-09-01
orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
2009-09-02
orem ipsum dolor
sit amet, nse
ctetur adi pis elit
nisl
Analysis Development
Acceptance
ProdNext
Definition of Done:• Customer accepted• Ready for production
Ongoing Done
Definition of Done:• Code clean & checked in on trunk• Integrated & regression tested• Running on UAT environment
Ongoing DoneOngoing Done
Definition of Done:• Goal is clear• First tasks defined• Story split (if necessary)
2 3 3 2
Feature / story
= completed
= blocked
= who is doing this right now
2009-08-20 2009-09-30
(description)
• Panicfeatures(should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary)
• Priority features• Hard deadline features
(only if deadline is at risk)• Oldest features
2009-09-03ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
2009-09-02
orem ipsum dolor sit amet, co nse
2009-08-27
orem ipsum dolor
sit amet, ctetur
adi pis cing elit
nisl
2009-08-27
orem ipsum dolor sit amet, adi pis cing elit nisl
2009-08-20
orem olor sit amet, co nse ctetur adi pis cing elit nisl
2009-08-30
orem ipsum dolor sit amet, co adi pis cing elit nisl
2009-09-08
2009-08-20
orem ipsum dolor
sit amet, co nse
ctetur adi pis cing
elit nisl
2009-08-25
2009-08-22orem ipsum dolor sit amet, co
2009-08-25
orem ipsum dolor sit ctetur adi pis cing elit nisl
Task / defectHard deadline
(if applicable)Date when added to board
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse cteturorem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum
dolor sit amet,
co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
(description)
(description)
(description)Why
(description)
Who is analyzing / testing right now
= priority
= panic
What to pull first
xxxx kjd dj d xxx
Kanban kick-start exampleHenrik Kniberg www.crisp.se/kanban/example
version 1.22009-11-16
(description)
orem ipsum dolor sit amet, co nse ctetur
2009-08-26
orem adi pis cing elit nisl
orem ipsum dolor sit amet, co nse ctetur
=task =defect
96
Evolve your own unique system!
Henrik Kniberg 96
Some of these photos courtesy ofDavid Anderson, Mattias Skarin,and various other people
97
Compare for understanding, not judgement
97
98
Lean & Agile process toolkits
Henrik Kniberg 98
Kanban
Scrum
XP
Values & PrinciplesLean, Agile, Theory of Constraints, Systems Thinking, etc
Other lean tools(Value Stream Mapping, Root Cause Analysis, etc)
99
More prescriptive More adaptive
Compare for understanding, not judgement
Henrik Kniberg 99
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• Requirements Reviewer• Requirements Specifier• Software Architect• Stakeholder• System Administrator• System Analyst• Technical Writer• Test Analyst• Test Designer• Test Manager• Tester• Tool Specialist• User-Interface Designer• Architectural analysis• Assess Viability of architectural
proof-of-concept• Capsule design• Class design• Construct architectural proof-of-
concept• Database design• Describe distribution• Describe the run-time
architecture• Design test packages and
classes• Develop design guidelines• Develop programming
guidelines• Identify design elements• Identify design mechanisms• Incorporate design elements• Prioritize use cases• Review the architecture• Review the design• Structure the implementation
model• Subsystem design• Use-case analysis• Use-case design• Analysis model• Architectural proof-of-concept• Bill of materials• Business architecture
document• Business case• Business glossary• Business modeling guidelines• Business object model• Business rules• Business use case
• 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
• 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• Iteration assessment• Iteration plan• Manual styleguide• Programming guidelines• Quality assurance plan• Reference architecture• Release notes• Requirements attributes• Requirements
management plan• Review record• Risk list• Risk management plan• Software architecture
document• Software development
plan• Software requirements
specification• Stakeholder requests• Status assessment• Supplementary business
specification• Supplementary specification• Target organization assessment• Test automation architecture• Test cases• Test environment configuration• Test evaluation summary• Test guidelines• Test ideas list• Test interface specification• Test plan• Test suite• Tool guidelines• Training materials• Use case model• Use case package• Use-case modeling guidelines• Use-case realization• Use-case storyboard• User-interface guidelines• User-interface prototype• Vision• Work order• Workload analysis model
100
Customizing your agile process10
0
101
Agile does not require timeboxed iterations
Sprints week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Sprint 1
Plan & commit Review(release?)
Separate cadences
week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Planning cadence (2w)
Sprint 2
Retrospective
Release cadence (1w)
Retrospectives (4w)
Event-driven week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Planning (on demand)
Release (on demand)
Retrospectives (4w)
102
Different ways of limiting WIP
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Big item
Big item
Scrum• Indirect limit per unit of time• Items must fit in a sprint
Kanban• Direct limit per workflow state• Can combine big & small items
WIP limit = 3 items
Velocity = 15 story points
103
Estimation options
TasksFeatures
Henrik Kniberg 103
1. Don’t estimate features. Just count them.
2. Estimate features in t-shirt size
1. Skip tasks
2. Don’t estimate tasks. Just count them.
3. Estimate tasks in days1d
2d0.5d
4. Estimate tasks in hours
12h8h4h
S M LHours?
Days?Weeks?
S ML
3. Estimate features in story points
1sp2sp
5sp
4. Estimate features in ideal man-days
1d3d
6d
”Typical”Kanban
”Typical”Scrum
104
Portfolio-level boardNext
Develop
Bingo
1
FLOW Avg lead time: weeks12
Release
Done2Conce
ptPlayable
Features
Polish3
Zork
Pac man
Pong
Donkey Kong
Mine sweepe
r
DugoutDuck hunt
GameTeam
1
GameTeam
2
GameTeam
3
Solitaire
105
Game teams
Burndown
Unplanned items
Notchecked out Done! :o)
Write f ailing test
DAO
DB design
I ntegr test
Migration tool
Write f ailing test
GUI spec
Tapestry spikeI mpl.
migration
2d
Code
cleanup
Deposit
2d1d 0.5d1d
2d
8d
1d2d
2d
BackofficeLogin
BackofficeUser admin
Write f ailing test
3d
2d
1d2d
I mpl GUI
1dI ntegr. with
J Boss2d
Write f ailing test
3d
I mpl GUI
6d
Clarif y require-ments
2d
GUI design (CSS)
1d
Fix memory leak(J I RA 125)2d
Sales support
3d Write whitepaper
4d
SPRINT GOAL: Beta-ready release!
Next
WithdrawPerf testWithdraw
checked out
Write f ailing test
Game team 1Current game: Pac Man
Burndown
Unplanned items
Notchecked out Done! :o)
Write f ailing test
DAO
DB design
I ntegr test
Migration tool
Write f ailing test
GUI spec
Tapestry spikeI mpl.
migration
2d
Code
cleanup
Deposit
2d1d 0.5d1d
2d
8d
1d2d
2d
BackofficeLogin
BackofficeUser admin
Write f ailing test
3d
2d
1d2d
I mpl GUI
1dI ntegr. with
J Boss2d
Write f ailing test
3d
I mpl GUI
6d
Clarif y require-ments
2d
GUI design (CSS)
1d
Fix memory leak(J I RA 125)2d
Sales support
3d Write whitepaper
4d
SPRINT GOAL: Beta-ready release!
Next
WithdrawPerf testWithdraw
checked out
Write f ailing test
Game team 2Current game: Pong
Burndown
Unplanned items
Notchecked out Done! :o)
Write f ailing test
DAO
DB design
I ntegr test
Migration tool
Write f ailing test
GUI spec
Tapestry spikeI mpl.
migration
2d
Code
cleanup
Deposit
2d1d 0.5d1d
2d
8d
1d2d
2d
BackofficeLogin
BackofficeUser admin
Write f ailing test
3d
2d
1d2d
I mpl GUI
1dI ntegr. with
J Boss2d
Write f ailing test
3d
I mpl GUI
6d
Clarif y require-ments
2d
GUI design (CSS)
1d
Fix memory leak(J I RA 125)2d
Sales support
3d Write whitepaper
4d
SPRINT GOAL: Beta-ready release!
Next
WithdrawPerf testWithdraw
checked out
Write f ailing test
Game team 2Current game: Donkey Kong
106
Final points
106
107Henrik Kniberg
107
Distinguish between…
Using the tool wrong Using the wrong tool
Neither of these problems are caused by the tool
108
Don’t be dogmatic
Henrik Kniberg 108
Go away! Don’t talk to us!We’re in a Sprint.
Come back in 3 weeks.
Though ShaltPair Program
109
Essential skills neededregardless of process
Henrik Kniberg 109
CraftsmanshipSplitting the system into useful pieces Retrospectives
As a buyerI want to save my shopping cartso that I can continue shopping later
110
Perfection is a direction, not a place
Henrik Kniberg
The important thing is not your process.The important thing is
your process for improving your process