Vad är ett agilt projekt?

Board of directors

Henrik KnibergAgile/Lean coach

www.crisp.se

Vad är ett agilt projekt?

PMIOct 26, 2010

[email protected]

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%


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


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


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


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



“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


B


A


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


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


Write f ailing test

DAO

I ntegr test

Write f ailing test

GUI spec

I mpl. migration

2d1d

8d

2d

2d

BackofficeLogin


Write f ailing test

1d2d

I mpl GUI

I ntegr. with

J Boss

Write f ailing test

I mpl GUI


Sales support

3d Write whitepaper

4d


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 YTest/integr

feature 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 YTest/integr

feature 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


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


ROI

Time

ROIcutoff

Plan:• Price: 10 M• Time: 12 months

Result:• Price: 5+1 M• Time: 6 months

54


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


55

Contracts

Henrik Kniberg 55

Fixed everything(price / scope / time)

Time & materials($ per iteration)


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 cteturorem 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





Avg lead time: days

20






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






UAT Deploy5 3 2 3

FLOW Avg lead time: days 12



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/

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



Henrik Kniberg 80

BC

A

D

E

F

G

H I

J LKM

81

NextDev

Done

Backlog 32



Henrik Kniberg 81

BC

A

D

E

F

G

H I

J LKM

82

NextDev

Done

Backlog 32



Henrik Kniberg 82

B

C A

D

E

F

G

H I

J LKM

83

NextDev

Done

Backlog 32


Scenario 1 – one piece flow.

Henrik Kniberg 83

B

C A

D

E

F

G

H I

J LKM

84

NextDev

Done

Backlog 32


Scenario 2 – Deployment problem

Henrik Kniberg 84

B

C

A

D

E

F

G

H I

J LKM

PO

85

NextDev

Done

Backlog 32



Henrik Kniberg 85

BC

A

D

E

F

G

H I

J LKM

PO

86

NextDev

Done

Backlog 32



Henrik Kniberg 86

B

C A

D

E

F

G

H I

J LKM

PO

87

NextDev

Done

Backlog 32



Henrik Kniberg 87

B

C A

D

E

F

G

H I

J LKM

PO

88

NextDev

Done

Backlog 32



Henrik Kniberg 88

B

C A

D

F

G

H I

J LKM

!?

E

PO

89

NexetDev

Done

Backlog 32



Henrik Kniberg 89

B

C

A

D

EF

G

H I

J LKM

!?

PO

90

NextDev

Done

Backlog 32



Henrik Kniberg 90

B

C

A

D

EF

G

H I

J LKM

PO

91

NextDev

Done

Backlog 32



Henrik Kniberg 91

B

A

D

EF

G

H I

J LKM

C

PO

92

NextDev

Done

Backlog 32



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 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)


2009-08-26

orem adi pis cing elit nisl


=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


Write f ailing test

DAO

DB design

I ntegr test

Migration tool

Write f ailing test

GUI spec


migration

2d

Code

cleanup

Deposit

2d1d 0.5d1d

2d

8d

1d2d

2d

BackofficeLogin


Write f ailing test

3d

2d

1d2d

I mpl GUI

1dI ntegr. with

J Boss2d

Write f ailing test

3d

I mpl GUI

6d


2d

GUI design (CSS)

1d


Sales support

3d Write whitepaper

4d


Next


checked out

Write f ailing test

Game team 1Current game: Pac Man

Burndown

Unplanned items


Write f ailing test

DAO

DB design

I ntegr test

Migration tool

Write f ailing test

GUI spec


migration

2d

Code

cleanup

Deposit

2d1d 0.5d1d

2d

8d

1d2d

2d

BackofficeLogin


Write f ailing test

3d

2d

1d2d

I mpl GUI

1dI ntegr. with

J Boss2d

Write f ailing test

3d

I mpl GUI

6d


2d

GUI design (CSS)

1d


Sales support

3d Write whitepaper

4d


Next


checked out

Write f ailing test

Game team 2Current game: Pong

Burndown

Unplanned items


Write f ailing test

DAO

DB design

I ntegr test

Migration tool

Write f ailing test

GUI spec


migration

2d

Code

cleanup

Deposit

2d1d 0.5d1d

2d

8d

1d2d

2d

BackofficeLogin


Write f ailing test

3d

2d

1d2d

I mpl GUI

1dI ntegr. with

J Boss2d

Write f ailing test

3d

I mpl GUI

6d


2d

GUI design (CSS)

1d


Sales support

3d Write whitepaper

4d


Next


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


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

Documents

Vad är ett agilt projekt?