Slides of a keynote by Henrik Kniberg done at Agile Eastern Europe 2010.

1. Copyright notice
These slides are licensed under Creative
The essence of Agile
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:
Keynote http://creativecommons.org/licenses/by/
3.0/
Agile Eastern Europe, Kiev All slides available at:
Oct 8, 2010 http://www.crisp.se/henrik.kniberg/
Henrik Kniberg
Agile/Lean coach
www.crisp.se
Board of
directors
henrik.kniberg@crisp.se
070 4925284

2. What is all this stuff?
TDD
Scrum
XP
Continuous
Integration
Refa
c torin Pair
g
ming
Lean program
RUP Agile
Henrik Kniberg 2

3. What have
we learned?
Henrik Kniberg 3

4. 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

5. 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

6. How estimates are affected by
specification length
Spec Same spec – more pages
117 hrs 173 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 6

7. How estimates are affected by
irrelevant information
Spec 1 Same spec
A + irrelevant details
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

8. 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

9. How estimates are affected by anchoring
Spec Same spec Same spec
500 hrs 50 hrs
456 hrs PO Never mind me Never mind me
PO
555 hrs 99 hrs
SM
SM
SM
Source: How to avoid impact from irrelevant and misleading info
2007-09-28 on your cost estimates, Simula research labs estimation seminar,
Oslo, Norway, 2006
9

10. We tend to build the wrong thing
Features and functions used in a typical system
Half of the stuff we
build is Always
never used! 7%
Often
13%
Never
Cost
45%
Some-
times
16%
Rarely
19%
# of features
Sources:
Standish group study reported at XP2002 by Jim Johnson, Chairman This graph courtesy of Mary Poppendieck
10
Henrik Kniberg 10

11. What have we learned? Top 5 reasons for success
1. User involvement
2. Executive management support
IT project success rate 1994: 15% 3. Clear business objectives
4. Optimizing scope
Average cost & time overrun: ≈170% 5. Agile process Scope
IT project success rate 2004: 34%
Average cost & time overrun: ≈70%
Quality
Cost Time
“The primary reason [for the improvement]
is that projects have gotten a lot smaller.”
“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
Jim Johnson
forward.”
Chairman of
Standish Group
“There is no silver bullet but
agile methods come very close” Sources:
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Henrik Kniberg ”My Life is Failure”, Jim Johnson’s book 11

12. Agile in a
nutshell
Henrik Kniberg 12

13. 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 Ron Jeffries
Mike Beedle Jon Kern
Arie van Bennekum Brian Marick
Alistair Cockburn Robert C. Martin
Ward Cunningham Steve Mellor
Martin Fowler Ken Schwaber
James Grenning Jeff Sutherland
Jim Highsmith Dave Thomas
Andrew Hunt
Henrik Kniberg 13

14. 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

15. Principles behind the Agile Manifesto
! Our highest priority is to satisfy the ! Working software is the primary
customer through early and continuous measure of progress.
delivery of valuable software. ! Agile processes promote sustainable
! Welcome changing requirements, even late development. The sponsors, developers,
in development. Agile processes harness and users should be able to maintain a
change for the customer's competitive constant pace indefinitely.
advantage. ! Continuous attention to technical
! Deliver working software frequently, from excellence and good design enhances
a couple of weeks to a couple of months, agility.
with a preference to the shorter timescale. ! Simplicity--the art of maximizing the
! Business people and developers must work amount of work not done--is essential.
together daily throughout the project. ! The best architectures, requirements,
! Build projects around motivated and designs emerge from self-organizing
individuals. Give them the environment and teams.
support they need, and trust them to get ! At regular intervals, the team reflects on
the job done. how to become more effective, then
! The most efficient and effective method of tunes and adjusts its behavior
conveying information to and within a accordingly.
development team is face-to-face
conversation.
15

16. Agile ”umbrella”
FDD
DSDM
Scrum XP Crystal
Kanban Sources:
3rd Annual ”State of Agile Development” Survey June-July 2008
• 3061 respondents
• 80 countries
16

17. 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

18. Timeboxing A B
Plan C D
(doomed to fail, but we don’t know it yet)
Week 1 Week 2 Week 3 Week 4
Traditional scenario A B
”We will deliver ABCD in 4 weeks” Oops, we’re late.
C D
Scope
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
X X Quality
X
Cost Time
Agile scenario A B
”We always deliver something every sprint (4 weeks)” A B
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.
Quality Our velocity is lower than we thought.
What should we do now?
Cost Time
18
Henrik Kniberg

19. Planning is easier with frequent releases
Henrik Kniberg 19

20. Scrum in a
nutshell
Henrik Kniberg 20

21. 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 process
Optimize business value
$$$
Split time
January April
$
Henrik Kniberg 21

22. Scrum overview – structure
Product
Backlog Cross functional, self
organizing Team
Stakeholders - How much to pull in
- How to build it
Sprint
Backlog Team
Users
PO
Helpdesk SM
Direct communication
Operations
Product owner
Management - Where are we going & why? Scrum Master
- Priorities - Process leader/coach
- Impediment remover
... etc ...
Henrik Kniberg 22

23. Product backlog As a <stakeholder>
I want <what> Definition of Done
Product vision
so that <why> • Releasable
• User Acceptance tested
Product • Merged to Trunk
Backlog As a buyer • release notes written
I want to save my shopping cart
• No increased technical debt
so that I can continue shopping later
As a booker = I haven’t messed up
the codebase
I want to receive notifications when
new available slots appear in the
calendar
so that I don't have to keep checking
GUI
manually
Client
(... etc ...)
Server
DB
Henrik Kniberg 23

24. 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 24
http://planningpoker.crisp.se

25. Planning poker
As a buyer
I want to save my shopping cart 2
so that I can continue shopping later
As a booker
I want to receive notifications when
new available slots appear in the
5
2 2
calendar
so that I don't have to keep checking 2 5
manually
? 3
Henrik Kniberg 25

26. Typical sprint
Product
Backlog
release
PO
1.3.0
Daily
Scrum
Week 1 Week 2 Week 3
Sprint- Demo/Review
Sprint plan
(Task board / Scrum board) planning Retrospective
Timeline
Henrik Kniberg 26

27. Velocity
V= 8 V= 7 V= 9
1 2 2 1 1 2
2 3 1 3 1 2 2 1
Sprint 1 Sprint 2 Sprint 3
Likely future velocity:
7-9 per sprint
Henrik Kniberg 27

28. Scope
Release planning – fixed date Quality
Cost Time
• Today is Aug 6
• Sprint length = 2 weeks
• Velocity = 30 - 40
300
What will be done PO
by X-mas?
(10 sprints) 400
2007-09-28 28

29. Scope
Release planning – fixed scope Quality
Cost Time
Release burndown chart When will all of
this be done?
400 We’ll be done
around sprint
Work remaining
14-16
(story points) PO
300
200
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Sprint
Henrik Kniberg 29

30. XP in a
nutshell
Henrik Kniberg 30

31. Scrum Scrum
”wraps” Team
Daily Scrum
XP XP Sprint
backlog
Whole
team
Coding Burndown
Collective chart
ownership TDD standard
Product
backlog
Customer
tests Pair Refactoring Planning Sprint
Product programming game Planning
owner meeting
Continuous Simple Sustainable
Integration design Pace
Metaphor
Small
releases
ScrumMaster
Sprint
Review
2007-09-28
Henrik Kniberg 31

32. Feedback
loops Sprint review
Daily Scrum
Continuous
integration
Unit test
Pair
programming
Henrik Kniberg 32

33. 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 F F F
Architecture
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

34. import java.sql.Connection;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class Dog {
Clean & simple code
private Executor executor = Executors.newFixedThreadPool(18);
private int CACHE_SIZE = 50;
public Dog()
{
try
{
Class.forName("oracle.jdbc.ThinDriver");
Simple code: Code is an asset
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
} catch (ClassNotFoundException e) {}
All code is cost!
new Thread().start();
1. Passes all tests Some code is value.
}
public void woof(Person woofCaller) {
Connection connection = null;
PreparedStatement statement = null;
2. No duplication
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());
3. Readable
statement.setString(3, person.getPhoneNumber().getNumber());
statement.executeUpdate();
public class Dog { }
private final String name; }
}
4. Minimal
private int woofCount = 0; } Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
b = a.prepareStatement("select * from Dog where name = '" + name + "'");
public Dog(String name) { c = b.executeQuery();
this.name = name; if (c.next()) {
} String foundName = c.getString("name");
PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount"));
Person person = new Person(foundName, phoneNumber);
public void woof() { return person;
++woofCount; } else {
Simple is hard!
} return new Person("", null);
} }
} catch (SQLException e) {
return null;
} catch (IllegalArgumentException x) {
throw x;
}
}
public List<Person> 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"));
Embrace
Person person = new Person(foundName, phoneNumber);
return person;
} else {
Change!
Robert C Martin (Uncle Bob)
Kent Beck
Henrik Kniberg 34

35. Kanban in a
nutshell
Henrik Kniberg 35

36. Which team needs Managers who don’t know how to
measure what they want
settle for
most improvement? wanting what they can measure
Russel Ackoff
Team 1 Team 2
Todo Doing Done Todo Doing Done
this week this week
dolor
orem ips
um dolor
orem ipsum dolor orem ipsum orem ipsum dolor orem ips
sit amet, co nse nse um dolor dolor
sit amet
, co nse sit amet, co dolor sit amet orem ipsum
ctetur ctetur ctetur orem ipsum
oremdolor dolor
ipsum sit amet, co nse orem ipsum , co nse
sit amet, co
nse orem ipsum
dolor
orem ipsum dolor
sit amet, co nse co nse ctetur
orem ips
um dolor oremnse
sit amet, co ipsum
orem
ctetur ips
um dolor sit amet, ctetur sit amet,
co nse amet, co nse
sit
sit amet ctetur do sit amet ctetur ctetur
orem ipsum ctetu
dolor
, co nse ctetur sit amet, dolor lor
orem ipsum co ns , co nse orem ipsum dolor ctetur
ctetur orem ipsum dolor
r ctetur co nse e
sit amet, sit amet, co nse
sit amet, co nse sit amet, co nse
ctetur orem ipsum dolor ctetur ctetur
ctetur
sit amet, co nse orem ipsum dolor orem ipsum dolor orem ipsum dolor
dolor
ctetur sit amet, co nse sit amet, co nse
orem ipsum dolor
sit amet, co nse orem ipsum
orem ips ctetur co nse
um dolor ctetur
sit amet, co nse
ctetur sit amet,
sit amet orem ipsum dolor
, co nse ctetur
ctetur dolor sit amet, co nse ctetur orem ips
um dolor
orem ipsum ctetur orem ipsum dolor sit amet orem ipsum dolor
co nse , co nse
sit amet, orem ipsum dolor
sit amet, co nse ctetur sit amet, co nse
ctetur sit amet, co nse orem ipsum dolor ctetur
ctetur
ctetur sit amet, co nse
orem ipsum dolor
ctetur
sit amet, co nse
ctetur orem ips
orem ipsum dolor um dolor
sit amet
sit amet, co nse , co nse
Avg lead time: 20 days
ctetur
Avg lead time: 3 days
ctetur
Henrik Kniberg 36

37. Kanban @ Imperial Palace Gardens
Henrik Kniberg 37

38. Kanban
”Visual Card”
! Signaling system
! Visual
! Limited in supply
Henrik Kniberg 38

39. Kanban in your wallet
Darn. Forgot to
limit the supply.
Henrik Kniberg 39

40. Kanban @ Toyota
Buyer Supplier
Consume Detach Receive Ship Allocate Manufacture
The tool used to operate the
[Toyota Production] system is
kanban.
Taiichi Ohno
Father of the
Toyota Production System
Henrik Kniberg 40

41. Kanban in SW development
! Visualize the workflow Pioneered by
David Anderson
in 2004
! Limit WIP (work in progress)
! Measure & optimize flow
! Explicit policies (definition of Done, WIP limits, etc)
Backlog Dev UAT Deploy Done
5 3 2 3
orem ips dolor dolor orem ips
sit amet
um dolor orem ipsum orem ipsum um dolor
, co nse nse nse sit amet
ctetur sit amet, co sit amet, co , co nse
ctetur
cte tur cte tur dolor
orem ipsum dolor
orem ipsum
co nse amet, co nse
sit
sit amet,
ctetur
ctetur
orem ipsum dolor orem ipsum dolor orem ipsum dolor
sit amet, co nse sit amet, co nse sit amet, co nse
ctetur ctetur orem ipsum dolor
ctetur
sit amet, co nse
ctetur
orem ipsum dolor orem ips
sit amet, co nse um dolor
sit amet
ctetur , co nse
ctetur
orem ipsum dolor
sit amet, co nse
orem ipsum dolor ctetur
sit amet, co nse
ctetur
FLOW Avg lead time:12 days
Henrik Kniberg 41

42. Kanban example
Board shared by several teams
Covers whole value stream
from concept to release
Henrik Kniberg 42

43. One day in
Kanban land
Henrik Kniberg 43

44. ”One day in Kanban land”
http://blog.crisp.se/henrikkniberg/tags/kanban/
Henrik Kniberg 44

45. Scenario 1 – one piece flow
Dev
Backlog Next 3 In production :o)
2
Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
Henrik Kniberg 45

46. Scenario 1 – one piece flow
Dev
Backlog Next 3 In production :o)
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 46

47. Scenario 1 – one piece flow
Dev
Backlog Next 3 In production :o)
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 47

48. Scenario 1 – one piece flow
Dev
Backlog Next 3 In production :o)
2
Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 48

49. Scenario 1 – one piece flow.
Dev
Backlog Next 3 In production :o)
2
Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 49

50. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
Henrik Kniberg 50

51. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 51

52. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 52

53. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 53

54. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
C A
G
D
!? B
F
H
I
J L E
M K
Henrik Kniberg 54

55. Scenario 2 – Deployment problem
Dev
Backlog Nexet 3 In production :o)
2
PO Ongoing Done
G !? A
D B
F
E C
H
I
J L
M K
Henrik Kniberg 55

56. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
G
D B
F
E C
H
I
J L
M K
Henrik Kniberg 56

57. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
G
D B
F
E C
H
I
J L
M K
Henrik Kniberg 57

58. Scenario 2 – Deployment problem
Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
D A
G
B
E
F
C
H
I
J L
M K
Henrik Kniberg 58

59. Kanban
board
evolution
Henrik Kniberg 59

60. Kanban evolution example
April 7
April 23
Henrik Kniberg 60

61. Henrik
Kniberg
Kanban www.crisp.se/kanban/example
example
kick-start version
1.2
2009-­‐11-­‐16
Next! Analysis! Development! Acceptance! Prod!
2 3 3 2
Ongoing! Done! Ongoing! Done! Ongoing! Done! 2009-08-20!
2009-09-03!
2009-09-01! 2009-08-27! orem olor sit amet, co
ipsum dolor sit am 2009-08-30! 2009-09-08!
orem ips 2009-08-27! nse ctetur adi pis
et,
co nse ctetur adi
!
cing elit nisl
pis orem ipsumipsum dolor
orem dolor sit orem ipsum dolor sit orem ipsum dolor
sit amet,
!
ctetur
um dolor
co nse orem ipsum dolor
amet, ctetur adi
sit
pis
orem ipsum dolor sit cing elit nisl !
amet, cosit amet, co nse
nse ctetur
!
or
cteturem
adi pis cingt amipsum dolor
si elit nisl ! amet, co adi pis cing
elit nisl ! !
sit amet, co nse
ctetur
cing elit nisl ! amet, adi pis cing
elit nisl!
ctetur
! et, co n
se
orem ipsum dolor ! 2009-08-
25!
2009-08-20
2009-09-02! orem ipsum
dolor
xxxx
orem ipsum dolor
ctetur !
sit amet, co nse
orem ipsum dolor
sit
! ctetur
!
kjd dj d
amet, co nse
nse
orem ipsum dolor sit ctetur !
sit amet, co
ctetur!
sit amet, co nse
xxx
orem ipsum dolor
!
sit amet, co nse orem ipsum dolor
adi pis cing
elit nisl
amet, nse ctetur adi
!
ctetur
!
orem ipsum dolor sit amet, co nse
2009-08-22
pis elit nisl
orem ipsum dolor ctetur!
sit amet, co nse ctetur
orem ipsum
!
!
sit amet, co nse
ctetur amet, co ! dolor sit
2009-08-29! 2009-08-26!
2009-09-02!
orem ipsum dolor sit orem adi pis
orem ipsum dolor
sit amet, co nse ! amet, nse ctetur adi
pis cing elit nisl !
orem ipsum dolor orem ipsum e
dolor
co ns
cing elit nisl! 2009-08-25!
orem ipsum dolor sit
sit
!
orem ipsum dolor amet, co nse sit amet,
ctetur ! ctetur adi pis cing
!
!
sit amet, co nse ctetur
ctetur
elit nisl
Definition of Done:! Definition of Done:! Definition of Done:!
• Goal is clear! • Code clean & checked in on trunk! • Customer accepted!
• First tasks defined! • Integrated & regression tested! • Ready for production!
• Story split (if necessary)! • Running on UAT environment!
Feature / story! Hard deadline!
Task / defect! What to pull first!
! =task! !
Date when added to (if applicable)!
(description) (description)
=defect! • Panicfeatures!
board! (should be swarmed and kept
(description) ! = completed! moving. Interrupt other work and
= priority! break WIP limits as necessary)!
2009-08-20! 2009-09-30!
! ! = blocked!
!
(description)
Why • Priority features!
= panic! • Hard deadline features!
(description)
! (only if deadline is at risk)!
(description)
= who is doing
Who is analyzing / • Oldest features!
this right now!
testing right now!

62. Evolve your own unique system!
Some of these photos courtesy of
David Anderson, Mattias Skarin,
and various other people
Henrik Kniberg 62

63. Compare for
understanding,
not judgement
Henrik Kniberg 63

64. Lean & Agile process toolkits
Values & Principles
Lean, Agile, Theory of Constraints, Systems Thinking, etc
Kanban
Other lean tools
XP (Value Stream Mapping,
Root Cause Analysis, etc)
Scrum
Henrik Kniberg 64

65. Compare for understanding, not 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
• System Administrator • Programming guidelines
• System Analyst • Quality assurance plan
• Technical Writer • Reference architecture
• Test Analyst • Release notes
• Test Designer • Requirements attributes
• Test Manager • Requirements
• Tester management plan
• Tool Specialist • Review record
• 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 • Test plan
model • Test suite
• Subsystem design • Tool guidelines
• Use-case analysis • Training materials
• Use-case design • Use case model
• Analysis model • Use case package
• Architectural proof-of-concept • Use-case modeling guidelines
• Bill of materials • Use-case realization
• Business architecture document • Use-case storyboard
• Business case • User-interface guidelines
• Business glossary • User-interface prototype
Henrik Kniberg 65
• Business modeling guidelines • Vision
• Business object model • Work order
• Business rules • Workload analysis model
• Business use case

66. Customizing
your agile
process
Henrik Kniberg 66

67. Shu-Ha-Ri stages of learning
! Shu = follow the process
! Ha = adapt the process
! Ri = never mind the process
Henrik Kniberg 67

68. 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 Sprint 2
Plan & commit Review
Retrospective
(release?)
Separate cadences 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 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Retrospectives (4w)
Planning (on demand)
Release (on demand)
68

69. 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

70. Estimation options
”Typical”
Features Tasks Kanban
1. Don’t estimate features. Just count them. 1. Skip tasks
2. Estimate features in t-shirt size 2. Don’t estimate tasks. Just count them.
S M
L
S M L
Hours?
Days?
Weeks?
3. Estimate features in story points 3. Estimate tasks in days ”Typical”
2sp 0.5d 1d Scrum
1sp 5sp
2d
4. Estimate features in ideal man-days 4. Estimate tasks in hours
4h 12h
1d 3d 8h
6d
Henrik Kniberg 70

71. Portfolio-level board
Next! Develop! Release! Done!
1 Concept! Playable!
3Features! Polish! 2
Game
Team Pac
Bingo
1 man
Solitaire
Game Zork Mine
Team Pong sweeper
2
Dugout
Game
Team
Donkey Duck
Kong hunt
3
FLOW Avg lead time: 12 weeks
71

72. Game teams
Game team 1 Game team 2 Game team 2
Current game: Pac Man Current game: Pong Current game: Donkey Kong
72

73. Final points
Henrik Kniberg 73

74. Distinguish between…
Using the tool wrong Using the wrong tool
Neither of these
problems are caused by
the tool
74
Henrik Kniberg 74

75. Don’t be dogmatic
Go away! Don’t talk to us!
We’re in a Sprint.
Come back Though Shalt
in 3 weeks. Pair Program
Henrik Kniberg 75

76. Essential skills needed
regardless of process
Splitting the system into Craftsmanship Retrospectives
useful pieces
As a buyer
I want to save my shopping cart
so that I can continue shopping later
Henrik Kniberg 76

77. 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