Copyright notice
The essence of Agile Keynote Agile Eastern Europe, Kiev Oct 8, 2010
Henrik Kniberg Agile/Lean coach www.crisp.se
Board of directors
[email protected] 070 4925284
These slides are licensed under Creative Commons. Feel free to use these slides & pictures as you wish, as long as you leave my name and the Crisp logo somewhere. For licensing details see: http://creativecommons.org/licenses/by/ 3.0/ All slides available at: http://www.crisp.se/henrik.kniberg/
What is all this stuff?
XP Refa c
Lean
torin g
RUP Henrik Kniberg
TDD
Scrum Continuous Integration Pair g n i m m a r g o r p
Agile 2
What have we learned? Henrik Kniberg
3
Traditional SW projects are like a cannon ball Assumptions: ! The customer knows what he wants ! The developers know how to build it ! Nothing will change along the way
Henrik Kniberg
4
Most IT projects don’t succeed The Standish Group has studied over 40,000 projects in 10 years.
IT project success rate 1994: 15% Average cost & time overrun: ≈170% Plan: €1,000,000 Actual: €2,700,000
IT project success rate 2004: 34% Average cost & time overrun: ≈70% Plan: €1,000,000 Actual: €1,700,000 Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Henrik Kniberg
5
How estimates are affected by specification length Same spec – more pages
Spec
117 hrs SM
173 hrs SM
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
2007-09-28
6
How estimates are affected by irrelevant information Spec 1
Same spec + irrelevant details
A B
A
C
B C
20 hrs 39 hrs SM
SM
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
2007-09-28
7
How estimates are affected by extra requirements Spec 1
Spec 2
Spec 3
A
A
A
B
B
B
C
C
C
D
D
D
E
E
4 hrs
4 hrs
8 hrs
SM SM
SM
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
2007-09-28
8
How estimates are affected by anchoring Spec
Same spec
456 hrs
Same spec
500 hrs Never mind me
PO
50 hrs Never mind me
PO
555 hrs
99 hrs
SM
SM
2007-09-28
SM
Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
9
We tend to build the wrong thing Features and functions used in a typical system
Always 7%
Never 45%
Often 13% Sometimes 16%
Cost
Half of the stuff we build is never used!
Rarely 19%
# of features Sources: Standish group study reported at XP2002 by Jim Johnson, Chairman
Henrik Kniberg
10
This graph courtesy of Mary Poppendieck
10
What have we learned? IT project success rate 1994: 15% Average cost & time overrun: ≈170%
IT project success rate 2004: 34%
Top 5 reasons for success 1. 2. 3. 4. 5.
User involvement Executive management support Clear business objectives Optimizing scope Agile process Scope
Average cost & time overrun: ≈70%
Quality
“The primary reason [for the improvement] is that projects have gotten a lot smaller.”
Cost
Time
“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.”
Jim Johnson
Chairman of Standish Group
“There is no silver bullet but agile methods come very close”
Henrik Kniberg
Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS ”My Life is Failure”, Jim Johnson’s book
11
Agile in a nutshell Henrik Kniberg
12
Agile Manifesto
www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Feb 11-13, 2001 Snowbird ski resort, Utah
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Henrik Kniberg
Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 13
Agile Manifesto www.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 Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Henrik Kniberg
14
Principles behind the Agile Manifesto ! Our 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.
15
Agile ”umbrella”
Scrum
Kanban
XP
DSDM
FDD Crystal
Sources: 3rd Annual ”State of Agile Development” Survey June-July 2008 • 3061 respondents • 80 countries
16
Agile projects are like a guided missile Assumptions: ! The customer discovers what he wants ! The developers discover how to build it ! Things change along the way
Henrik Kniberg
17
Timeboxing Plan
A B C D
(doomed to fail, but we don’t know it yet) Week 1 Week 2 Week 3 Week 4
Traditional scenario
”We will deliver ABCD in 4 weeks”
A B
Oops, we’re late.
C D
Scope
X X X
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Quality
Cost
Time
Agile scenario
A B A B ”We always deliver something every sprint (4 weeks)” E D ”We think we can finish ABCD in 1 sprint, but we aren’t sure” ”We always deliver the most important items first” Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Scope Oops, we only finished AB. Our velocity is lower than we thought. What should we do now?
Quality Cost
Time
18 Henrik Kniberg
Planning is easier with frequent releases
Henrik Kniberg
19
Scrum in a nutshell Henrik Kniberg
20
Split your organization
Scrum in a nutshell Split your product Large group spending a long time building a huge thing Small team spending a little time building a small thing ... but integrating regularly to see the whole
Optimize business value
Optimize process
$$$
Split time January
April
$
Henrik Kniberg
21
Scrum overview – structure Product Backlog
Cross functional, self organizing Team - How much to pull in - How to build it
Stakeholders Sprint Backlog
Team
Users
Helpdesk
PO Direct communication
SM
Operations
Management
Product owner - Where are we going & why? - Priorities
Scrum Master - Process leader/coach - Impediment remover
... etc ...
Henrik Kniberg
22
Product backlog Product vision
Product Backlog
As a I want so that
As a buyer I want to save my shopping cart so that I can continue shopping later As a booker I want to receive notifications when new available slots appear in the calendar so that I don't have to keep checking manually (... 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
Henrik Kniberg
23
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 right than precisely wrong
Henrik Kniberg http://planningpoker.crisp.se
24
Planning poker
2
As a buyer I want to save my shopping cart so that I can continue shopping later
5
As a booker I want to receive notifications when new available slots appear in the calendar so that I don't have to keep checking manually
2
5
2 ?
Henrik Kniberg
2
3
25
Typical sprint Product Backlog
release 1.3.0
PO
Daily Scrum
Week 1
Sprint plan (Task board / Scrum board)
Week 2
Week 3
Demo/Review Retrospective
Sprintplanning
Timeline
Henrik Kniberg
26
Velocity V= 8
1
V= 7
2 2
2 3
Sprint 1
1 Sprint 2
V= 9
1 3
1
1 2
2 2
1
Sprint 3
Likely future velocity: 7-9 per sprint
Henrik Kniberg
27
Scope
Release planning – fixed date
Quality Cost
• Today is Aug 6 • Sprint length = 2 weeks • Velocity = 30 - 40
Time
300 What will be done by X-mas? (10 sprints)
2007-09-28
PO
400
28
Scope
Release planning – fixed scope Cost
Release burndown chart 400
Work remaining (story points)
PO
300
Quality Time
When will all of this be done?
We’ll be done around sprint 14-16
200
100
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Sprint
Henrik Kniberg
29
XP in a nutshell Henrik Kniberg
30
Scrum ”wraps” XP
Scrum Team
XP
Sprint backlog
Whole team Collective ownership
Product backlog
Product owner
Daily Scrum
Customer tests
TDD
Pair programming
Continuous Integration
Coding standard
Refactoring
Simple design
Burndown chart
Planning Sprint game Planning meeting
Sustainable Pace
Metaphor
ScrumMaster
2007-09-28
Henrik Kniberg
Small releases Sprint Review
31
Feedback loops
Sprint review Daily Scrum Continuous integration Unit test
Pair programming Henrik Kniberg
32
Agile architecture Timeline
Don’t do: Quick ’n dirty features => Slow ’n dirty => Entropy death? Big bang rewrite? F
F
F
F
F
F
Don’t do: Big Up Front Design
F
Architecture
F
F
F
Do: Find a balance F
F
F
F
F
F
F
F
F
F
A
A
A
A
A
A
A
A
A
A
Henrik Kniberg
33
import java.sql.Connection; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors;
Clean & simple code Code is an asset Simple code: All code is cost! 1. Passes all tests Some code is value. 2. No duplication 3. Readable 4. Minimal public class Dog { private final String name; private int woofCount = 0; public Dog(String name) { this.name = name; }
Simple is hard!
Embrace Change!
Kent Beck
Henrik Kniberg
public void woof() { ++woofCount; } }
public class Dog { private Executor executor = Executors.newFixedThreadPool(18); private int CACHE_SIZE = 50; public Dog() { try { Class.forName("oracle.jdbc.ThinDriver"); connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); } catch (ClassNotFoundException e) {} new Thread().start(); } public void woof(Person woofCaller) { Connection connection = null; PreparedStatement statement = null; try { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); statement.setString(2, person.getName()); statement.setString(3, person.getPhoneNumber().getNumber()); statement.executeUpdate(); } } } } Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); b = a.prepareStatement("select * from Dog where name = '" + name + "'"); c = b.executeQuery(); if (c.next()) { String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber); return person; } else { return new Person("", null); } } catch (SQLException e) { return null; } catch (IllegalArgumentException x) { throw x; } } public List getAll() { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); } if (statement != null) { if (c.next()) { String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber); return person; } else {
Robert C Martin (Uncle Bob)
34
Kanban in a nutshell Henrik Kniberg
35
Which team needs most improvement? Team 1
orem ipsum dolor orem ips um dolor sit amet, co nse sit amet , co nse ctetur ctetur orem ips um dolor sit amet , co nse orem ipsum cte dolor tur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ips um dolor sit amet , co nse ctetur dolor orem ipsum co nse sit amet, ctetur orem ipsum dolor sit amet, co nse orem ipsumctetur dolor sit amet, co nse ctetur
Russel Ackoff
Team 2
Doing
Todo
Managers who don’t know how to measure what they want settle for wanting what they can measure
Done this week
dolor orem ipsum nse sit amet, co ctetur
orem ipsum dolor oremdol ipsum or dolor sit amet, co nse orem ipsum sitco amet, co nse orem ips ctetur oremnse um dolor sit amet, ctetur ipsum dolor sit amet sit am , co nse ctetur orem ipsum dolor et, co ctetur nse cte tu r co nse sit amet, ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse ctetur ctetur
Avg lead time: 20 days
Henrik Kniberg
Todo
dolor orem ipsum co nse sit amet, ctetur
orem ips um dolor sit amet , co nse ctetur
orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur
Doing dolor orem ipsum nse sit amet, co ctetur
this week dolor orem ipsum dolor orem ipsum co nsesit amet, co nse sit amet, ctetur ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor dolor sit amet, co nse orem ipsum co nse ctetur sit amet, ctetur orem ips um dolor orem ipsum dolor sit amet , co nse sit amet, co nse ctetur ctetur orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Avg lead time:
Done
3
days
orem ips um dolor sit amet , co nse ctetur
36
Kanban @ Imperial Palace Gardens
Henrik Kniberg
37
Kanban
看板 ”Visual Card”
! Signaling system ! Visual ! Limited in supply
Henrik Kniberg
38
Kanban in your wallet
Darn. Forgot to limit the supply.
Henrik Kniberg
39
Kanban @ Toyota Buyer
Consume
Detach
Supplier
Receive
Ship
Allocate
Manufacture
The tool used to operate the [Toyota Production] system is kanban.
Henrik Kniberg
Taiichi Ohno Father of the Toyota Production System
40
Kanban in SW development ! ! ! !
Visualize the workflow Limit WIP (work in progress) Measure & optimize flow Explicit policies (definition of Done, WIP limits, etc) Backlog 5
Dev 3
UAT 2
orem ips um dolor sit amet , co nse ctetur
dolor orem ipsum nse sit amet, co tur cte
dolor orem ipsum nse sit amet, co tur cte
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Deploy Done 3 orem ips um dolor sit amet , co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
Henrik Kniberg
dolor orem ipsum dolor orem ipsum co nsesit amet, co nse sit amet, ctetur ctetur
orem ipsum dolor sit amet, co nse ctetur orem ips um dolor sit amet , co nse ctetur orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
FLOW
Pioneered by David Anderson in 2004
Avg lead time:12 days
41
Kanban example
Board shared by several teams Covers whole value stream from concept to release
Henrik Kniberg
42
One day in Kanban land Henrik Kniberg
43
”One day in Kanban land” http://blog.crisp.se/henrikkniberg/tags/kanban/
Henrik Kniberg
44
Scenario 1 – one piece flow
Next
Backlog A
2
Dev
In production :o)
3
Ongoing
Done
B
G C F H J M
D I
L K
Henrik Kniberg
E
45
Scenario 1 – one piece flow
Next
Backlog
2
Ongoing
Done
B
C F H M
In production :o)
3
A
G
J
Dev
D I
L K
Henrik Kniberg
E
46
Scenario 1 – one piece flow
Backlog
2
Ongoing
Done
B
C F H M
In production :o)
3
A
G
J
Dev
Next
D I
L K
Henrik Kniberg
E
47
Scenario 1 – one piece flow
Dev
Next
Backlog
2
Ongoing
C
G
D
In production :o)
3
Done A
B
F H J M
I L K
Henrik Kniberg
E
48
Scenario 1 – one piece flow.
Dev
Next
Backlog
2
In production :o)
3
Ongoing
Done
C
G D
A B
F H J M
I L K
Henrik Kniberg
E
49
Scenario 2 – Deployment problem
Next
Backlog PO A
2
Dev
In production :o)
3
Ongoing
Done
B
G C F H J M
D I
L K
Henrik Kniberg
E
50
Scenario 2 – Deployment problem
Next
Backlog PO
Ongoing
Done
B
C F H M
In production :o)
3
A
G
J
2
Dev
D I
L K
Henrik Kniberg
E
51
Scenario 2 – Deployment problem
Dev
Next
Backlog PO G
2
In production :o)
3
Ongoing
C
A
D
B
Done
F H J M
I L K
Henrik Kniberg
E
52
Scenario 2 – Deployment problem
Dev
Next
Backlog PO
2
Ongoing C
G D
In production :o)
3
Done A
B
F H J M
I L K
Henrik Kniberg
E
53
Scenario 2 – Deployment problem
Backlog PO
2
G D F H J M
Dev
Next
In production :o)
3
Ongoing
Done
C
A
!?
B
I L K
Henrik Kniberg
E
54
Scenario 2 – Deployment problem
Backlog PO
2
F H M
In production :o)
3
Ongoing
!?
G
J
Dev
Nexet
Done A
D
B
E
C
I L K
Henrik Kniberg
55
Scenario 2 – Deployment problem
Next
Backlog PO
2
F H M
In production :o)
3
Ongoing
Done A
G
J
Dev
D
B
E
C
I L K
Henrik Kniberg
56
Scenario 2 – Deployment problem
Next
Backlog PO
2
Dev
In production :o)
3
Ongoing
Done A
G D F H J M
E
B C
I L K
Henrik Kniberg
57
Scenario 2 – Deployment problem
Backlog PO
In production :o)
3
Ongoing
Done
H
A B
E
F
M
2
D
G
J
Dev
Next
C I
L K
Henrik Kniberg
58
Kanban board evolution Henrik Kniberg
59
Kanban evolution example April 7
April 23
Henrik Kniberg
60
Kanban www.crisp.se/kanban/example kick-start example
Henrik Kniberg
Next! 2
Analysis! 3
Ongoing!
2009-09-01!
ipsum dolor sit am et, co nse ctetur adi pis cing elit nisl
!
ctetur
!
et, co n
se
!
orem ipsum dolor sit amet, co adi pis cing elit nisl
!
2009-09-02! orem ipsum dolor sit amet, nse ctetur adi pis elit nisl
!
2009-09-08!
2009-08-30!
orem ipsum dolordolor sit orem ipsum amet, co nse amet, cosit nse ctetur orem ip ctetur m dolo adi pis cing elitsunisl sit am r
!
dolor orem ipsum nse sit amet, co ctetur orem ipsum dolor sit amet, co nse ctetur
!
!
xxxx orem ipsum dolor kjd dj d sit amet, coxxx nse ctetur
!
!
sit orem ipsum dolor pis amet, ctetur adi cing elit nisl
orem ipsum dolor orem ipsum dolorsit amet, co nse sit amet, co nse ctetur ctetur
Definition of Done:! • Goal is clear! • First tasks defined! • Story split (if necessary)!
Feature / story! Date when added to board! 2009-09-30!
2009-08-20
!
orem ipsum dolor sit amet, co nse ctetur
!
!
2009-08-22 !
!
orem adi pis cing elit nisl!
dolor orem ipsum e co ns sit amet, ctetur
!
(description)
! =task!
2009-08-25! orem ipsum dolor sit ctetur adi pis cing elit nisl
!
Task / defect!
= priority!
Who is analyzing / testing right now!
!
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co
(description)
= panic!
25! ! 2009-08lor sit do um ips orem ctetur amet, co nse elit nisl adi pis cing
orem ipsum dolor sit amet, co nse ctetur
Definition of Done:! • Code clean & checked in on trunk! • Integrated & regression tested! • Running on UAT environment!
Hard deadline! (if applicable)!
!
!
!
!
!
2009-08-20! orem olor sit amet, co nse ctetur adi pis cing elit nisl
orem ipsum dolor sit amet, adi pis cing elit nisl
!
Prod!
2009-08-26!
orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl
!
!
!
Done!
2009-08-27!
2009-08-27!
!
orem ipsum dolor sit amet, co nse ctetur
Ongoing!
2009-08-29!
orem ipsum dolor sit amet, co nse
(description)
orem ips um dolor sit amet, co nse ctetur
Done!
!
orem ipsum dolor sit amet, co nse ctetur
2009-09-02!
2009-08-20!
Acceptance! 2
Development! 3
Ongoing! Done!
2009-09-03!
version 1.2 2009-‐11-‐16
(description)
!
Definition of Done:! • Customer accepted! • Ready for production!
What to pull first! =defect!
•
! = completed!
(description)
! ! = blocked!
(description)
!
Why
= who is doing this right now!
• • •
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!
Evolve your own unique system!
Henrik Kniberg
Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people
62
Compare for understanding, not judgement Henrik Kniberg
63
Lean & Agile process toolkits Values & Principles
Lean, Agile, Theory of Constraints, Systems Thinking, etc
Kanban
XP
Other lean tools (Value Stream Mapping, Root Cause Analysis, etc)
Scrum
Henrik Kniberg
64
Compare for understanding, not judgement More prescriptive
More adaptive
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-ofconcept 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
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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
Henrik Kniberg
Scrum (9)
XP (13) • • • • • • • • • • • • •
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
Kanban (3) • • •
Do Whatever (0)
Visualize the workflow Limit WIP Measure and optimize lead time
65
Customizing your agile process Henrik Kniberg
66
Shu-Ha-Ri stages of learning
! Shu = follow the process ! Ha = adapt the process ! Ri = never mind the process
Henrik Kniberg
67
Agile does not require timeboxed iterations Sprints
week 1
week 2
week 3
week 4
Sprint 1 Plan & commit
Separate cadences
week 5
week 6
week 7
week 8
Sprint 2
Review (release?)
Retrospective
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
Retrospectives (4w) Planning cadence (2w) Release cadence (1w)
Event-driven Retrospectives (4w) Planning (on demand) Release (on demand)
68
Different ways of limiting WIP Scrum
Velocity = 15 story points
• Indirect limit per unit of time • Items must fit in a sprint
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Kanban • Direct limit per workflow state • Can combine big & small items Big item WIP limit = 3 items
Big item
69
Estimation options ”Typical” Kanban
Tasks
Features
1. Don’t estimate features. Just count them. 1. Skip tasks
2. Don’t estimate tasks. Just count them.
2. Estimate features in t-shirt size
M
S
S
L
Hours?
M
L
Days? Weeks?
3. Estimate features in story points
1sp
2sp
5sp
4. Estimate features in ideal man-days
1d
3d
Henrik Kniberg
6d
3. Estimate tasks in days 0.5d
2d
1d
”Typical” Scrum
4. Estimate tasks in hours 4h
8h
12h
70
Portfolio-level board
Develop!
Next! 1
Concept! Playable!
3Features!
Game Team Solitaire
2
Game Team
3
FLOW
Polish!
2
Pac man
1
Game Team
Release! Done! Bingo
Zork
Pong
Donkey Kong
Mine sweeper
Dugout Duck hunt
Avg lead time: 12 weeks
71
Game teams Game team 1 Current game: Pac Man
Game team 2 Current game: Pong
Game team 2 Current game: Donkey Kong
72
Final points
Henrik Kniberg
73
Distinguish between… Using the tool wrong
Using the wrong tool
Neither of these problems are caused by the tool
Henrik Kniberg
74
74
Don’t be dogmatic Go away! Don’t talk to us! We’re in a Sprint. Come back in 3 weeks.
Henrik Kniberg
Though Shalt Pair Program
75
Essential skills needed regardless of process Splitting the system into useful pieces
Craftsmanship
Retrospectives
As a buyer I want to save my shopping cart so that I can continue shopping later
Henrik Kniberg
76
Perfection is a direction, not a place The important thing is not your process. The important thing is your process for improving your process
Henrik Kniberg
77
