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.
- 1. AT4 ConcurrentSession 11/8/201210:15AM "Transitioning to
Kanban: From Theory to Practice" Presented by: Gil Irizarry Yesmail
Broughttoyouby: 340CorporateWay,Suite300,OrangePark,FL32073
[email protected]
2. 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]. 3. Transitioning Your Team To Kanban: Theory and
Practice Gil Irizarry Lead Project Manager November 2012Learning
Objectives Learn what Kanban is Learn value stream mapping and how
to apply it to your team Learn how to read a cumulative flow
diagram21 4. Agenda A bit about me Theory Motivations Background
What is Kanban and how does it work Practice Setting up a Kanban
board Establishing Policies and Limits 3My background Lead Project
Manager at Yesmail/Infogroup 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 E-mail: [email protected]
http://www.slideshare.net/conoagil 42 5. Motivations We want to
move to Agile management methods. Why? y React quicker to changing
market conditions Get new features to users more quickly Frequent
releases are smaller releases Better Quality5Quick Review of Scrum
Fixed Iterations Daily Stand-ups What did you do yesterday, what
will you do today, any impediments? Retrospectives Burn-down chart
Board with To Do, In Progress, and Done states 63 6. 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 7What is Kanban? A scheduling system that tells you
what to produce, when to produce it, and how much to produce.
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 circulation
highlighted problem areas i l ti hi hli ht d bl Wikipedia:
http://en.wikipedia.org/wiki/Kanban 84 7. 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_princip
les_of_the_kanban_method (David Anderson)95 Core Properties of
Kanban Visualize the workflow Team board states are a reflection of
the value stream t Limit WIP Manage Flow Implied that flow should
be continuous Make Process Policies Explicit Improve
Collaboratively (using models & the scientific method)105 8.
Kanban and RolesOrg Work mgmt. Metrics I Improvement Prioritization
Definition Ready-Ready Delivery Flow oLeadTeam11You are one
team!126 9. Value Mapping ExerciseHow do you make dinner?13Sample
Value StreamShop for food 30 minValue:No Value:Drive to market 30
minCook Food 15 minUnpack groceries 5 minDrive home 30 minWash Pots
15 minEat!Serve Dinner 5 min50 min / 130 min = 38% efficiency 147
10. 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
efficiency15Sample Kanban Board StatesClasses of ServiceWIP
Limits168 11. 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:17Limit WIP Why? Less multitasking Less
time lost to context switching Better quality Smoother flow189 12.
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 development19Sample CFD
60What happened here? 5040 User Story 30MockupsLead TimeCycle
TimeReady-Done In DevelopmentWIPDev Done20In Testing
Complete10Potential Bottlenecks 11/9/2010 11/12/2010 11/17/2010
11/22/2010 11/25/2010 11/30/2010 12/3/2010 12/8/2010 12/13/2010
12/16/2010 12/21/2010 12/24/2010 12/29/2010 1/3/2011 1/6/2011
1/11/2011 1/14/2011 1/19/2011 1/24/2011 1/27/2011 2/1/2011 2/4/2011
2/9/2011 2/14/2011 2/17/2011 2/22/2011 2/25/2011 3/2/2011 3/7/2011
3/10/2011 3/15/2011 3/18/2011 3/23/2011 3/28/2011 3/31/2011
4/5/2011 4/8/2011 4/13/2011 4/18/2011 4/21/2011 4/26/2011
4/29/201102010 13. Team Kanban Teams plan continuously. Backlogs
should be constantly groomed. Teams test continuously Its 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 Its 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 21Metrics 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 p
production, to g , give a high-level g Open defects in p
approximation of technical debt2211 14. 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 So, time, 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
23Average Cycle Times for work items 35302520Average of Cycle Time
(small - 1 Story Point)15Average of Cycle Time (medium - 3 Story
Points)10Average of Cycle Time ( g (large - 5 Story Points) y )50
2010 R72010 R82011 R12011 R22011 R32011 R42412 15. Kanban in
practiceWhy Kanban? Shorter sprint lengths were forcing us to
artificially break up items in order to fit within sprint
boundaries 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. i t QA had nothing to do
at the beginning of a sprint, but were overworked at the end. 2613
16. 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
complicated27Mapping the Value Stream2814 17. One Team Single Flow
Produc eItemandtask typebycolorTod oBugs&Footprintsonboard
WIPL=6fullitemsVisiblepolicies 29Cumulative Flow Diagram QA
overloaded Worked on more constant delivery Identified a bottleneck
with source control Changed our branching strategy to improve3015
18. Cumulative Flow Diagram Later, were now releasing twice a week
to Production Much smoother CFD, continuous deliver improves cycle
time31One Year Later3216 19. 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/ 33Thank you!17
