Upload
conoagil
View
105
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
Copyright © 2011 Constant Contact Inc.
Transitioning Your Team to Kanban: Theory and Practice
Project Summit &BusinessAnalystWorld: Boston
Gil IrizarryConstant Contact
2Copyright © 2011 Constant Contact, Inc.
Learning Objectives
• Learn what Kanban is
• Learn value stream mapping and how to apply it to your team
• Learn how to read a cumulative flow diagram
3Copyright © 2011 Constant Contact, Inc.
Agenda
• A bit about me and Constant Contact
• Theory –
• Motivations
• Background
• What is Kanban and how does it work
• Practice –
• Setting up a Kanban board
• Establishing policies and limits
4Copyright © 2011 Constant Contact, Inc.
My background
• Program Manager at Constant Contact
• Over 20 years software development and 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 Management from MIT Sloan
• [email protected], [email protected]
• http://www.slideshare.net/conoagil
5Copyright © 2011 Constant Contact, Inc.
Background on Constant Contact
• SaaS company offering on-line e-mail marketing, event marketing and surveys. Recent enhancements extend the services to the social media space
• >$200MM gross revenue per year
• >850 employees
• >475K paying customers
• Engineering and Operations total about 150 people
• First Scrum team formed in 2006
6Copyright © 2011 Constant Contact, Inc.
Motivations
• We want to move to Agile management methods. Why?
• React quicker to changing market conditions
• Get new features to users more quickly
• Frequent releases are smaller releases
• Better Quality
7Copyright © 2011 Constant Contact, Inc.
Quick Review of Scrum
• Fixed iterations
• Daily stand-ups
• What did you do yesterday, what did you do today, any impediments
• Retrospectives
• Burn-down chart
• Board with To Do, In Progress and Done states
8Copyright © 2011 Constant Contact, Inc.
Lean Principles
• Eliminate Waste
• Build Quality In
• Create Knowledge
• Defer Commitment
• Deliver Fast
• Respect People
• Optimize the WholeLeading Lean Software Development: Results Are not the Point by Mary and Tom Poppendieck
9Copyright © 2011 Constant Contact, Inc.
Foundational Principles of Kanban
• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities & titles
From: http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method (David Anderson)
10Copyright © 2011 Constant Contact, Inc.
5 Core Properties of Kanban
• Visualize the workflow
• Team board states are a reflection of the value stream
• Limit WIP
• Manage Flow
• Implied that flow should be continuous
• Make Process Policies Explicit
• Improve Collaboratively (using models & the scientific method)
11Copyright © 2011 Constant Contact, Inc.
Kanban and Roles
Lead Team
Org
• Prioritization• Definition• Ready-Ready
• Work mgmt.• Metrics• Improvement
• Delivery• Flow
12Copyright © 2011 Constant Contact, Inc.
You are one team!
13Copyright © 2011 Constant Contact, Inc.
Value Mapping Exercise
How do you make dinner?
14Copyright © 2011 Constant Contact, Inc.
Sample Value Stream
Drive to
market 30 min
Shop for
food 30 min
Drive home
30 min
Unpack groceries 5 min
Wash Pots 15 min
Cook Food
15 min
Serve Dinner 5 min
Eat!
50 min / 130 min = 38% efficiency
Value:
No Value:
15Copyright © 2011 Constant Contact, Inc.
Map the value stream in your group/dept./firm
• Work with your teams or teams on which you are dependent in order to drive more efficiency
16Copyright © 2011 Constant Contact, Inc.
Sample Kanban Board
States
Cla
sses o
f S
erv
ice
WIP Limits
17Copyright © 2011 Constant Contact, Inc.
Pull, not Push
• Work items should be pulled into available lanes
• Work should not be pushed when completed, even if its lane is full
Pull: Push:
18Copyright © 2011 Constant Contact, Inc.
Limit WIP
• Why?
• Less multitasking
• Less time lost to context switching
• Better quality
• Smoother flow
19Copyright © 2011 Constant Contact, Inc.
Classes of Service
• Different types of work need to be handled and prioritized differently
• 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
20Copyright © 2011 Constant Contact, Inc.
Sample CFD
11/9/2010 11/28/201012/17/2010 1/5/2011 1/24/2011 2/12/2011 3/3/2011 3/22/2011 4/10/2011 4/29/20110
10
20
30
40
50
60
User StoryMockupsReady-DoneIn DevelopmentDev DoneIn TestingComplete
Cycle Time
WIP
What happened here?
Lead Time
Potential Bottlenecks
21Copyright © 2011 Constant Contact, Inc.
Team Kanban
• Teams plan continuously. Backlogs should be constantly groomed.
• 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 the current release
• Aim for development and testing to flow more smoothly through your system
22Copyright © 2011 Constant Contact, Inc.
Metrics
• Considering gathering the following:
• Cycle time on items after grouping them by size:
• Completion time for small, medium and large
• Spread of cycle times
• Work items completed
• Open defects in production, to give a high-level approximation of technical debt
23Copyright © 2011 Constant Contact, Inc.
Metrics guide planning and estimation
• 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 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 estimate for the upcoming release.
• Large items should in most cases be broken down into smaller items
24Copyright © 2011 Constant Contact, Inc.
2010 R7 2010 R8 2011 R1 2011 R2 2011 R3 2011 R40
5
10
15
20
25
30
35Average Cycle Times for work items
Average of Cycle Time (small - 1 Story Point)
Average of Cycle Time (medium - 3 Story Points)
Average of Cycle Time (large - 5 Story Points)
25Copyright © 2011 Constant Contact, Inc.
Kanban in practice
Copyright © 2011 Constant Contact, Inc. 26
Why Kanban?
• Shorter sprint lengths were forcing us to artificially break up items in order to fit within 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 sprint.
• QA had nothing to do at the beginning of a sprint, but were overworked at the end.
Copyright © 2011 Constant Contact, Inc. 27
Mapping the Value Stream
• At the time, the Website team was really 2 teams, Engineering and Design.
• We asked the teams to map out their current development process.
• It was really complicated…
Copyright © 2011 Constant Contact, Inc. 28
Mapping the Value Stream
Copyright © 2011 Constant Contact, Inc. 29
How do you set a WIP limit?
• Setting WIP limit is more art than science.
• Don’t overthink the initial WIP limit, it will change based on metrics.
• Start WIP limit at 1.5X the number of team members.
• That WIP limit is for the whole board.
• Divide total WIP amongst the columns, whatever feels right.
• Take photos of the board daily for Cumulative Flow Diagram.
Copyright © 2011 Constant Contact, Inc. 30
Policies
• The team defined policies for moving items into each state.
• Policies are the requirements that must be met before an item is considered ready for the next state.
• Policies were written down in a wiki and posted on the board.
• The team frequently ignores policies, so the scrum master has to keep them honest ;-).
Copyright © 2011 Constant Contact, Inc. 31
One Team – Single Flow
Produce
Todo Item and task
type by color
WIPL = 6 full items
Bugs & Footprints on board
Visible policies
Copyright © 2011 Constant Contact, Inc. 32
Metrics are the Key to Improvement
• Cycle Time – Elapsed time from Design to Release to Production
• Perceived lack of predictability compared to Scrum was an issue.
• By tracking Cycle Time, we can eventually provide Service Level Agreements to stakeholders.
• SLA = Avg. Cycle Time + 2(Standard Deviation)
Copyright © 2011 Constant Contact, Inc. 33
Cumulative Flow Diagram
• QA overloaded
• Worked on more constant delivery
• Identified a bottleneck with source control
• Changed our branching strategy to improve
Before After
Copyright © 2011 Constant Contact, Inc. 34
Cumulative Flow Diagram
• By September, we’re now releasing twice a week to Production
• Much smoother CFD, continuous deliver improves cycle time
Copyright © 2011 Constant Contact, Inc. 35
One Year Later…
New classes of service
36Copyright © 2011 Constant Contact, Inc.
What were our objectives?
• Learn what Kanban is
• Learn value stream mapping and how to apply it to your team
• Learn how to read a cumulative flow diagram
37Copyright © 2011 Constant Contact, Inc.
Resources
• Kanban by David J Anderson
• 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 Ladas
• http://www.netobjectives.com/
Copyright © 2011 Constant Contact, Inc. 38
Conclusion
Thank you!