This document provides an overview of agile principles and practices such as Scrum, XP, Kanban, and the Agile Manifesto. It discusses key concepts like iterative development, self-organizing teams, frequent delivery of working software, and responding to change over following a plan. Visualizations are used to illustrate differences between the traditional predictive approach and agile approaches to managing scope, quality, costs and time.

1. The Essence of Agile
Agile Israel
April 11, 2011
Henrik Kniberg
Agile/Lean coach
www.crisp.se
Board of
directors
henrik.kniberg@crisp.se
070 4925284

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

3. Agile in a
nutshell
3
3

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

5. 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 ‫כלומר, בעוד שיש ערך לפריטים בצד שמאל‬ 5
‫.אנחנו מעריכים יותר את הפריטים בצד ימין‬

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

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

8. Traditional, predictive approach
Release
Design spec
Requirements spec
Order
C
D
Actual
P need
P
R
11-04-11
Henrik Kniberg 8

9. 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
9
Henrik Kniberg 9

10. Traditional 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 10

11. Agile is like a homing missile
Assumptions:
! The customer discovers what he wants
! The developers discover how to build it
! Things change along the way
Henrik Kniberg 11

12. 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
”We always deliver something every sprint (2 weeks)” A A B A B E
”We think we can finish ABCD in 4 weeks, 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
Scope
Oops, our velocity is lower than we thought.
It looks like we’ll only finish AB by week 4.
Quality What should we do now?
Cost Time
12
Henrik Kniberg

13. Planning is easier with frequent releases
Henrik Kniberg 13

14. Scrum in a
nutshell
14 14

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

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

17. Backlog management Estimate stories
As a buyer
2
I want to save my shopping cart
As a booker
I want to receive notifications when
new slots appear in the calendar
5
Write user stories so that I can continue shopping
later
so that I don't have to keep
checking manually
As a buyer 2 2
asdf kjsk
flkjs df sd fk
asdf kjsk
flkjs df sd fk
asdf kjsk
flkjs df sd fk As a buyer
I want to save my shopping cart 5
2
soIthat a can continue shopping later
As I buyer
asdf kjsk
flkjs df sd fk
want to save my shopping cart
3
asdf kjsk
soIthat I can continue shopping later
want to save my shopping cart
flkjs df sd fk
asdf kjsk
flkjs df sd fk
asdf kjsk
flkjs df sd fk ?
so that I can continue shopping later
Break down big stories Prioritize
REgister new 3 REgister new 3
user user
Edit existing 5 Edit existing 5 Velocity-based
forecast
user user
High prio stories
Administrate small enough to
users 13 Find 3 View Invoice in HTML, fit in a sprint
April
user PDF, or Excel format
View Invoice in HTML,
PDF, or Excel format
Delete 5 As a helpdesk operator
I want to see who is May
user logged in
As a helpdesk operator
I want to see who is
logged in
View Invoice in HTML, Find 3 June
PDF, or Excel format user
Operations Later
manual
As a helpdesk operator
I want to see who is
Operations
logged in manual Realistic
100 simultaneous planning horizon
Low prio stories
users Operations 100 simultaneous not broken
manual users down yet
17
100 simultaneous
users
Delete
user
5

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

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

20. Scope
Release planning – example 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 20

21. XP in a
nutshell
21
21

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

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

24. Kanban in a
nutshell
Henrik Kniberg 24

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

42. Case study:
Cross
functional
teams
42 42

43. Before
Design-ready games Production-ready games
Game backlog
15 12
8
Lisa
Concept Graphics Sound Integr. &
Sam assigns Dev
pres. design design deploy
resources
2d 1m 6m 1w 6m 6m
2h 4h 1d 1m 3w 3m 3w
(1m+2m)
3 m value added time Process
= 12% cycle
25 m cycle time efficiency
43

44. Before
Design-ready games Production-ready games
Game backlog
15 12
8
Lisa
Concept Graphics Sound Integr. &
Sam assigns Dev
pres. design design deploy
resources
2d 1m 6m 1w 6m 6m
2h 4h 1d 1m 3w 3m 3w
Process (1m+2m)
3 m value added time
= 12% cycle
25 m cycle time efficiency
After Game team
(graphics, sound,
dev, integrate)
Cross-functional game team
3-4 m cycle time = 6-8x faster
3-4 months
44

45. Specialist teams & handovers
We’re slow!
I’m fast! 6 months
Joe Dave Lisa Release
Cross-functional teams
3 months
We’re alot faster!
Joe
I’m a bit
Dave slower
Lisa Release
January February March April May June July
Henrik Kniberg 45

46. Kanban – ”evolution over revolution”
Integrate!
Next! Graphics! Sound! Development! & deploy! Done!!
3 2 3 2 1!
Doing! Done! Doing! Done! Doing! Done! Doing! 2009-08-20!
2009-09-03!
2009-08-27! orem olor sit amet, co
ipsum dolor sit am 2009-09-01! 2009-08-30! 2009-08-26!
et, 2009-08-27! orem ipsum dolor sit nse ctetur adi pis
co nse ctetur adi
!
cing elit nisl
pis orem ipsum dolor sit
amet, co nse ctetur
orem ipsum dolor sit
amet, co adi pis cing orem ipsum dolor
sit amet, adi pis cing
! orem adi pis cing elit nisl !
!
adi pis cing elit nisl elit nisl! amet, ctetur adi
!
cing elit nisl
pis elit nisl
cing elit nisl !
2009-08-20
!
2009-08-29! dolor sit
2009-09-03! 2009-09-02! orem ipsum
ipsum dolor sit amet, orem ipsum dolor sit orem ipsum dolor sit
amet, nse ctetur adi
amet, co nse
adi pis cing
ctetur
elit nisl !
co nse ctetur adi pis
cing elit nisl ! amet, nse ctetur adi
!
pis elit nisl !
pis cing elit nisl 2009-08-22
!
orem ipsum
amet, co! dolor sit
Definition of Done:! Definition of Done:! Definition of Done:! Definition of Done:!
• …! • …! • …! • …..!
Henrik Kniberg 46

47. Final points
47 47

48. Working smart is more important than
working hard
Big team working hard
Working ”smart” is enabled by:
• Clear goal
• Transparency
• Direct contact with customers
• Focus
• Fast feedback
Small team working smart
Henrik Kniberg 48

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

50. The important thing is not your process.
Essential skills needed The important thing is
regardless of process your process for improving your 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 50