Transitioning to Kanban: From Theory to Practice


Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Transitioning to Kanban: From Theory to Practice

  1. 1.           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 ∙ ∙
  2. 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
  3. 3. Transitioning Your Team To Kanban: Theory and Practice Gil Irizarry Lead Project Manager November 2012 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 2 1
  4. 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 3 My 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: • 4 2
  5. 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 Quality 5 Quick 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 6 3
  6. 6. Lean Principles • • • • • • • Eliminate Waste Build Quality In Create Knowledge Defer Commitment Deliver Fast Respect People Optimize the Whole Leading Lean Software Development: Results Are Not the Point by Mary and Tom Poppendieck 7 What 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: 8 4
  7. 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: les_of_the_kanban_method (David Anderson) 9 5 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) 10 5
  8. 8. Kanban and Roles Org • Work mgmt. • Metrics •I Improvement • Prioritization • Definition • Ready-Ready • Delivery • Flow o Lead Team 11 You are one team! 12 6
  9. 9. Value Mapping Exercise How do you make dinner? 13 Sample Value Stream Shop for food 30 min Value: No Value: Drive to market 30 min Cook Food 15 min Unpack groceries 5 min Drive home 30 min Wash Pots 15 min Eat! Serve Dinner 5 min 50 min / 130 min = 38% efficiency 14 7
  10. 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 efficiency 15 Sample Kanban Board States Classes of Service WIP Limits 16 8
  11. 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: 17 Limit WIP • Why? • • • • Less multitasking Less time lost to context switching Better quality Smoother flow 18 9
  12. 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 development 19 Sample CFD 60 What happened here? 50 40 User Story 30 Mockups Lead Time Cycle Time Ready-Done In Development WIP Dev Done 20 In Testing Complete 10 Potential 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/2011 0 20 10
  13. 13. 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 21 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 p production, to g , give a high-level g • Open defects in p approximation of technical debt 22 11
  14. 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 23 Average Cycle Times for work items 35 30 25 20 Average of Cycle Time (small - 1 Story Point) 15 Average of Cycle Time (medium - 3 Story Points) 10 Average of Cycle Time ( g (large - 5 Story Points) y ) 5 0 2010 R7 2010 R8 2011 R1 2011 R2 2011 R3 2011 R4 24 12
  15. 15. Kanban in practice Why 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. 26 13
  16. 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 complicated… 27 Mapping the Value Stream 28 14
  17. 17. One Team – Single Flow Produc e Item and task  type by color Tod o Bugs & Footprints on board WIPL = 6 full items Visible policies 29 Cumulative Flow Diagram • • • • QA overloaded Worked on more constant delivery Identified a bottleneck with source control Changed our branching strategy to improve 30 15
  18. 18. Cumulative Flow Diagram • Later, we’re now releasing twice a week to Production • Much smoother CFD, continuous deliver improves cycle time 31 One Year Later… 32 16
  19. 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 • 33 Thank you! 17