Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Transitioning to Kanban: Theory and Practice - Project Summit Boston 2011

1,294 views

Published on

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

  • Be the first to like this

Transitioning to Kanban: Theory and Practice - Project Summit Boston 2011

  1. 1. Transitioning Your Team to Kanban: Theory and Practice Project Summit & BusinessAnalystWorld: Boston Gil Irizarry Constant ContactCopyright © 2011 Constant Contact Inc.
  2. 2. 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 diagramCopyright © 2011 Constant Contact, Inc. 2
  3. 3. 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 limitsCopyright © 2011 Constant Contact, Inc. 3
  4. 4. 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 • girizarry@constantcontact.com, gil@conoa.com • http://www.slideshare.net/conoagilCopyright © 2011 Constant Contact, Inc. 4
  5. 5. 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 2006Copyright © 2011 Constant Contact, Inc. 5
  6. 6. 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 QualityCopyright © 2011 Constant Contact, Inc. 6
  7. 7. 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 statesCopyright © 2011 Constant Contact, Inc. 7
  8. 8. 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 PoppendieckCopyright © 2011 Constant Contact, Inc. 8
  9. 9. 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_pr inciples_of_the_kanban_method (David Anderson)Copyright © 2011 Constant Contact, Inc. 9
  10. 10. 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)Copyright © 2011 Constant Contact, Inc. 10
  11. 11. Kanban and Roles • Prioritization • Definition • Ready-Ready Org • Work mgmt. • Delivery • Metrics • Flow • Improvement Lead TeamCopyright © 2011 Constant Contact, Inc. 11
  12. 12. You are one team!Copyright © 2011 Constant Contact, Inc. 12
  13. 13. Value Mapping Exercise How do you make dinner?Copyright © 2011 Constant Contact, Inc. 13
  14. 14. Sample Value Stream Shop Unpack Cook Value: for food groceries Food Eat! 30 min 5 min 15 min Drive to Drive Wash Serve No market home Pots Dinner Value: 30 min 30 min 15 min 5 min 50 min / 130 min = 38% efficiencyCopyright © 2011 Constant Contact, Inc. 14
  15. 15. 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 efficiencyCopyright © 2011 Constant Contact, Inc. 15
  16. 16. Sample Kanban Board States WIP Limits Classes of ServiceCopyright © 2011 Constant Contact, Inc. 16
  17. 17. 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:Copyright © 2011 Constant Contact, Inc. 17
  18. 18. Limit WIP • Why? • Less multitasking • Less time lost to context switching • Better quality • Smoother flowCopyright © 2011 Constant Contact, Inc. 18
  19. 19. 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 developmentCopyright © 2011 Constant Contact, Inc. 19
  20. 20. Sample CFD 60 What happened here? 50 40 User Story Mockups Lead Time Cycle Time Ready-Done 30 In Development WIP Dev Done In Testing 20 Complete 10 Potential Bottlenecks 0 11/9/2010 12/9/2010 1/9/2011 2/9/2011 3/9/2011 4/9/2011Copyright © 2011 Constant Contact, Inc. 20
  21. 21. 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 systemCopyright © 2011 Constant Contact, Inc. 21
  22. 22. 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 debtCopyright © 2011 Constant Contact, Inc. 22
  23. 23. 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 itemsCopyright © 2011 Constant Contact, Inc. 23
  24. 24. 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 (large - 5 Story Points) 5 0 2010 R7 2010 R8 2011 R1 2011 R2 2011 R3 2011 R4Copyright © 2011 Constant Contact, Inc. 24
  25. 25. Kanban in practiceCopyright © 2011 Constant Contact, Inc. 25
  26. 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. 26
  27. 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. 27
  28. 28. Mapping the Value StreamCopyright © 2011 Constant Contact, Inc. 28
  29. 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. 29
  30. 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. 30
  31. 31. One Team – Single Flow Produc e Tod o Item and task type by color Bugs & Footprints on board WIPL = 6 full items Visible policiesCopyright © 2011 Constant Contact, Inc. 31
  32. 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. 32
  33. 33. Cumulative Flow Diagram • QA overloaded • Worked on more constant delivery • Identified a bottleneck with source control • Changed our branching strategy to improveCopyright © 2011 Constant Contact, Inc. 33
  34. 34. Cumulative Flow Diagram • By September, we’re now releasing twice a week to Production • Much smoother CFD, continuous deliver improves cycle timeCopyright © 2011 Constant Contact, Inc. 34
  35. 35. One Year Later… New classes ofCopyright © 2011 Constant Contact, Inc. service 35
  36. 36. 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 diagramCopyright © 2011 Constant Contact, Inc. 36
  37. 37. 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. 37
  38. 38. Conclusion Thank you!Copyright © 2011 Constant Contact, Inc. 38

×