1

Agile TransitioningLessons learned helping companies get started

Henrik KnibergAgile & Lean coach at Crisp, Stockholmhttp://www.crisp.se/henrik.kniberg

Architect & developerMostly Java

ManagerCTO at three IT companies ≈�40 developers

AuthorScrum and XP from the Trenches>100,000 readers, translated to 7 languages

Coach & teacherAgile & lean coachWork with Jeff Sutherland & Mary PoppendieckRegularly speak at international conferences

QCon Tokyo, 2009-04-09

2

Case 1Bootstrapping agile teams

Henrik Kniberg 2

3

First ask ”Why change?”

Typical answers:Faster deliveryHigher qualityIncreased motivation and work prideClearer roles

Henrik Kniberg 3

Case 1: Bootstrapping agile teams

4

Rough transitioning plan

Henrik Kniberg 4

Case 1: Bootstrapping agile teams

BTraining

1 day?

CWorkshops

1 week?

DPreparation

1 week?

ELaunch

1 day?

FFollow up & phase out

a few months?

Timeline

howmanypeople

Typical pattern:

AInteriews

1 week?

5

BTrain

CWorkshops

DPrepar-ation

ELau-nch

FFollow up

& phase out

AInteriews

Interviews

Henrik Kniberg 5

Case 1: Bootstrapping agile teams

6

Root cause analysis

Henrik Kniberg 6

Teams grouped

by component

Teams not business-oriented

Teams not focused Teams don’t have

own PO PO doesn’t have own team

Ineffective requirements

communication Unclear roles & responsibilities

Too much focus on written specs

Team not getting feedback from customer

Lack of team spirit Lack of discipline

in teams

Hard to plan Delayed releases Lack of

transparancyNo

burndowns

Bad throughput in development

Difficult to release

Cutting quality instead of scope

Teams disrupted during sprint

Many operational problems

Customers dissatisfied

Hard to change the

codeMany

defects

Not measuring

velocity

Feature split across multiple teams

Fear of committing

Problems estimating

Lack of test automation

= root cause

= visible damage

= talked about

= not talked about

= fix first

= vicious cycle

Case 1: Bootstrapping agile teams

7

Problem: Teams grouped by component

Henrik Kniberg 7

PO Feature A1

Product ATaskTaskTask

TaskTaskTask

TaskTaskTask

TaskTaskTask

Task

Task

Task

Task

PO

Product B

PO

Product C

PO

Product D

?!

!?

Case 1: Bootstrapping agile teams

8

Half-day Training

Henrik Kniberg 8

Case 1: Bootstrapping agile teams BTrain

CWorkshops

DPrepar-ation

ELau-nch

FFollow up

& phase out

AInteriews

9

Half-day workshops

Henrik Kniberg 9

Case 1: Bootstrapping agile teams BTrain

CWorkshops

DPrepar-ation

ELau-nch

FFollow up

& phase out

AInteriews

10

Goal: Feature teams

Henrik Kniberg 10

PO

Product A

PO

Product B

PO

Product C

PO

Product D

Feature A1

Task

Task

Task

Task

Case 1: Bootstrapping agile teams

11

Transitioning team

Henrik Kniberg 11

Case 1: Bootstrapping agile teams

Project leader CTO

Developer

Coach

TesterProductmanager

Salesperson

BTrain

CWorkshops

DPrepar-ation

ELau-nch

FFollow up

& phase out

AInteriews

Status What to do Definition of done

Done Lean & Agile training for everyone

All potential SM & PO & team members understand their roles

Done Go through product backlogs

Product backlogs ready for estimation

Ongoing

Define teams Diagram of new team structure, buy-in from all PO and SM at the very least.

Decide which team sits where

Office map showing which team sits where

Co-locate each team Alla team members sit together and have close access to sprint backlog, daily scrum, and PO.

12

Transitioning backlog

Henrik Kniberg 12

Status What to do Definition of done

Done Lean & Agile training for everyone

All potential SM & PO & team members understand their roles

Done Go through product backlogs Product backlogs ready for estimation

Ongoing Define teams Diagram of new team structure, buy-in from all PO and SM at the very least.

Decide which team sits where

Office map showing which team sits where

Co-locate each team Alla team members sit together and have close access to sprint backlog, daily scrum, and PO.

..... etc ......

Case 1: Bootstrapping agile teams

13

Who defines the teams?Option 1: Teams defined centrally(by transitioning team or management team)

+ Works+ Fast- Lack of buy-in- Doesn’t harness collective knowledge

Option 2: Teams form themselves from scratch+ Harnesses collective knowledge+ Buy-in- Slow - Might not work

Option 3: Combination of 1 + 2. Preliminary teams defined centrally,teams then allowed to reform themselves

+ Works+ Harnesses collective knowledge+ Buy-in+ Faster than option 2- Slower than option 1

Henrik Kniberg 13

Case 1: Bootstrapping agile teams

14

Constraints:•3-8 people per team•Team has PO•Focused & dedicated to shared goal•Independent (can deliver whole story)

Self-organizing to form new teams

Henrik Kniberg

CombinedCombined

New

Preliminary team allocation After a week in the kitchen

Case 1: Bootstrapping agile teams

15

Co-locate each team& launch sprint

Henrik Kniberg 15

P

P

PP

P

P

Case 1: Bootstrapping agile teams BTrain

CWorkshops

DPrepar-ation

ELau-nch

FFollow up

& phase out

AInteriews

16

Case 1 – Key pointsLook before you leap

Interviews – coach learnsTraining – coach teachesWorkshops – coach facilitates

Involve peopleUse a transitioning teamGive the teams a chance to form themselvesContinuous dialog & consensus building

Incremental process improvementUse a transitioning backlogUse root cause analysis to prioritize the transitioning backlogRefactor the organization like you refactor code

Small steps whenever possibleSystem always in working state

Henrik Kniberg 16

Case 1: Bootstrapping agile teams

17

Case 2Speeding up product development

Henrik Kniberg 17

18Henrik Kniberg 18

Sam Concept pres.

Lisa assigns

resources

Graphics design

Sound design Dev Integr. &

deploy2d 1m

4h6m

8

Game backlog

1w 6m 6m

15

Design-ready games

12

Shelf

1m 3w 3m(1m+2m)

3w2h 1d

3 m value added time

25 m cycle time

w2w1 w4w3 w6w5 w8w7

= 12%Process cycle efficiency

Estimate

Preliminary result

2 m cycle time = 12x faster

3-4 m cycle time = 6-8x faster

w2w1 w4w3 w6w5 w8w7

Games out of dateMissed market windowsDemotivated teamsOverhead costs

Case 2: Speeding up product develompent

19

Case 2 – Key pointsSpeeding 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 19

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

Sam Concept pres.

Lisa assigns resources

Graphics design

Sound design Dev Integr. &

deploy2d 1m

4h

6m 1w 6m 6m

1m 3w 3m(1m+2m)

3w2h 1d

8 15 12

20

Thank you!