transitioning to kanban: from theory to practice
DESCRIPTION
You're familiar with agile and, perhaps, practicing Scrum. Now you're curious about Kanban. Is it right for your project? How does Kanban differ from Scrum and other agile methodologies? From theory to practice, Gil Irizarry introduces Kanban principles and explains how Kanban's emphasis on modifying existing processes rather than upending them results in a smooth adoption. Instead of using time-boxed units of work, Kanban focuses on continuous workflow, allowing teams to incrementally improve and streamline product delivery. Explore how to move from Scrum to Kanban with new, practical techniques that can help your team quickly get better. Discover the use of cumulative flow diagrams, WIP (work-in-progress) limits, and classes of services. In a hands-on classroom exercise, you'll help create a value stream map, determine process efficiency, and experience techniques from the Kanban toolset. Come and grow your agile repertoire in the Kanban way.TRANSCRIPT
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 ∙ [email protected] ∙ 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 [email protected].
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: [email protected]• 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!