AT4 Concurrent Session 11/8/2012 10:15 AM 

       

"Transitioning to Kanban: From Theory to Practice"

   

Presented by:

Gil Irizarry Yesmail

       

Brought to you by:  

  

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Gil Irizarry Yesmail

Gil Irizarry has worked in software development for more than twenty years as a software developer and engineering manager in both corporate and start-up environments. Gil is currently lead project manager at Yesmail, managing their transition to Lean and guiding the implementation of new project workflows. Gil mentors and trains teams on Agile and Kanban. A frequent speaker at conferences, Summits, and local chapters of the PMI, Gil is a Certified ScrumMaster (CSM), a Kanban coach, and has been a certified Project Management Professional (PMP). Reach him at gil@conoa.com.

1

Transitioning Your Team To Kanban:

Theory and PracticeTheory and PracticeGil Irizarry

Lead Project Manager

November 2012

• Learn what Kanban is

Learning Objectives

• Learn value stream mapping and how to apply it to your team

• Learn how to read a cumulative flow diagram

2

2

• A bit about me

Agenda

• Theory• Motivations• Background• What is Kanban and how does it work

3

• Practice• Setting up a Kanban board• Establishing Policies and Limits

• Lead Project Manager at Yesmail/Infogroup• Over 20 years software development and

My background

management experience, over 5 years in an agile software development environment

• CSM and PMP certifications, Kanban coaching training with David Anderson

• BS from Cornell, ALM from Harvard, certificate in

4

Management from MIT Sloan• E-mail: gil@conoa.com• http://www.slideshare.net/conoagil

3

• We want to move to Agile management methods. Why?

Motivations

y• React quicker to changing market conditions• Get new features to users more quickly• Frequent releases are smaller releases• Better Quality

5

• Fixed Iterations

Quick Review of Scrum

• Daily Stand-ups• What did you do yesterday, what will you do today,

any impediments?

• Retrospectives

6

Retrospectives

• Burn-down chart• Board with To Do, In Progress, and Done states

4

• Eliminate Waste• Build Quality In

Lean Principles

• Create Knowledge• Defer Commitment• Deliver Fast• Respect People• Optimize the Whole

7

• Optimize the Whole

Leading Lean Software Development: Results Are Not the Point by Mary and Tom Poppendieck

• A scheduling system that tells you what to produce, when to produce it, and how much to produce

What is Kanban?

produce.• An effective tool to support the running of the

production system as a whole.• An excellent way for promoting improvements

because reducing the number of work cards in i l ti hi hli ht d bl

8

circulation highlighted problem areas

Wikipedia: http://en.wikipedia.org/wiki/Kanban

5

• Start with what you do now

Foundational Principles of Kanban

• Agree to pursue incremental, evolutionary change

• Respect the current process, roles, responsibilities & titles

9

From:http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method (David Anderson)

• Visualize the workflow• Team board states are a reflection of the value

t

5 Core Properties of Kanban

stream• Limit WIP• Manage Flow

• Implied that flow should be continuous• Make Process Policies Explicit

10

• Improve Collaboratively (using models & the scientific method)

6

Kanban and Roles

• Prioritization• Prioritization

Org

• Definition• Ready-Ready• Definition• Ready-Ready

• Work mgmt.• Metrics

I

• Work mgmt.• Metrics

I

• Delivery• Flow• Delivery• Flow

11

Lead Team• Improvement• Improvement

oo

You are one team!

12

7

Value Mapping Exercise

How do you make dinner?

13

Sample Value Stream

Shop for food 30 min

Unpack groceries

5 min

Cook Food

15 minEat!Value:

Drive to market 30 min

30 min

Drive home 30 min

5 min

Wash Pots

15 min

15 min

Serve Dinner 5 min

No Value:

14

50 min / 130 min = 38% efficiency

8

• Work with your teams or teams on which you are dependent in order to drive more efficiency

Map the value stream in your group/dept./firm

15

Sample Kanban Board

States

WIP Limits

Cla

sses

of

Serv

ice

16

9

• Work items should be pulled into available lanes

Pull, not Push

• Work should not be pushed when completed, even if its lane is full

Pull: Push:

17

• Why?• Less multitasking

Limit WIP

• Less time lost to context switching• Better quality• Smoother flow

18

10

• Different types of work need to be handled and prioritized differently

Classes of Service

• We manage this through the concept of classes of service. Similar projects are grouped into classes and each class is assigned an allocation.• For example, we may decide that 20% of ops time

should be spent on infrastructure improvements, and 80% spent on servicing development

19

and 80% spent on servicing development

Sample CFD

50

60

What happened here?

20

30

40

User Story

Mockups

Ready-Done

In Development

Dev Done

In Testing

Complete

Cycle Time

WIP

Lead Time

20

0

10

11/9

/201

011

/12/

2010

11/1

7/20

1011

/22/

2010

11/2

5/20

1011

/30/

2010

12/3

/201

012

/8/2

010

12/1

3/20

1012

/16/

2010

12/2

1/20

1012

/24/

2010

12/2

9/20

101/

3/20

111/

6/20

111/

11/2

011

1/14

/201

11/

19/2

011

1/24

/201

11/

27/2

011

2/1/

2011

2/4/

2011

2/9/

2011

2/14

/201

12/

17/2

011

2/22

/201

12/

25/2

011

3/2/

2011

3/7/

2011

3/10

/201

13/

15/2

011

3/18

/201

13/

23/2

011

3/28

/201

13/

31/2

011

4/5/

2011

4/8/

2011

4/13

/201

14/

18/2

011

4/21

/201

14/

26/2

011

4/29

/201

1

Potential Bottlenecks

11

• Teams plan continuously. Backlogs should be constantly groomed.

Team Kanban

• Teams test continuously• It’s OK if a team finds a defect on the last day of

the release. Pull the feature or delay the release, but keep the flow continuous

• It’s OK if a team starts work for the next release in

21

the current release• Aim for development and testing to flow more

smoothly through your system

• Considering gathering the following:• Cycle time on items after grouping them by

Metrics

size:• Completion time for small, medium and large

• Spread of cycle times• Work items completed• Open defects in production, to give a high-level

22

p p , g gapproximation of technical debt

12

• Over time, we would expect that the spread of cycle times for a given item size goes down.So over time an estimate of completion time for

Metrics guide planning and estimation

• So, over time, an estimate of completion time for items of a given size should become more accurate.

• Work items can be sized by t-shirt sizes (smalls, mediums or larges) and the average cycle times for those sizes from the last release become the

23

for those sizes from the last release become the estimate for the upcoming release.

• Large items should in most cases be broken down into smaller items

30

35

Average Cycle Times for work items

10

15

20

25

Average of Cycle Time (small - 1 Story Point)

Average of Cycle Time (medium - 3 Story Points)

Average of Cycle Time (large - 5 Story Points)

24

0

5

2010 R7 2010 R8 2011 R1 2011 R2 2011 R3 2011 R4

( g y )

13

Kanban in practice

• Shorter sprint lengths were forcing us to artificially break up items in order to fit within sprint boundaries

Why Kanban?

sprint boundaries.• Sprint planning consumed the team for an entire

day.• Most of the work for a sprint was getting

completed all at once, close to the end of the i t

26

sprint.• QA had nothing to do at the beginning of a sprint,

but were overworked at the end.

14

• At the time, the Website team was really 2 teams, Engineering and Design.

Mapping the Value Stream

• We asked the teams to map out their current development process.

• It was really complicated…

27

Mapping the Value Stream

28

15

One Team – Single Flow

Produce

Todo

Item and task type by colorItem and task type by color

WIPL = 6 full itemsWIPL = 6 full items

Bugs & Footprints on boardBugs & Footprints on board

29

Visible policiesVisible policies

• QA overloaded• Worked on more constant delivery• Identified a bottleneck with source control

Cumulative Flow Diagram

• Identified a bottleneck with source control• Changed our branching strategy to improve

30

16

• Later, we’re now releasing twice a week to Production

Cumulative Flow Diagram

• Much smoother CFD, continuous deliver improves cycle time

31

One Year Later…

32

17

• Kanban by David J Anderson

• Implementing Lean Software Development:

Resources

Implementing Lean Software Development: From Concept to Cash - by Mary Poppendieck and Tom Poppendieck

• Scrumban - Essays on Kanban Systems for Lean Software Development - by Corey

33

Lean Software Development by Corey Ladas

• http://www.netobjectives.com/

Thank you!