Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

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

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 38 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Anzeige

Ähnlich wie Transitioning to Kanban: Theory and Practice - Project Summit Boston 2011 (20)

Anzeige

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 Contact Copyright © 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 diagram Copyright © 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 limits Copyright © 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/conoagil Copyright © 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 2006 Copyright © 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 Quality Copyright © 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 states Copyright © 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 Poppendieck Copyright © 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 Team Copyright © 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% efficiency Copyright © 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 efficiency Copyright © 2011 Constant Contact, Inc. 15
  16. 16. Sample Kanban Board States WIP Limits Classes of Service Copyright © 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 flow Copyright © 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 development Copyright © 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/2011 Copyright © 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 system Copyright © 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 debt Copyright © 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 items Copyright © 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 R4 Copyright © 2011 Constant Contact, Inc. 24
  25. 25. Kanban in practice Copyright © 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 Stream Copyright © 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 policies Copyright © 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 improve Copyright © 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 time Copyright © 2011 Constant Contact, Inc. 34
  35. 35. One Year Later… New classes of Copyright © 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 diagram Copyright © 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

Hinweis der Redaktion

  • We had 3 “swim lanes” “P1” or “expedite”, Engineering and Design. The lanes converged in the verify column.We had WIP limits for each column or “state”Engineering Lanes: Queue, Requirements & Test Plans, Design, Review& Revision, Code, Review & Revision, Verify, DoneDesign Lanes: Queue, User Experience, UX Review & Revision, Design, Review& Revision, Test Plan, Code, Review & Revision, Verify, Done
  • We had trouble managing dependencies between the two boards/teamsWe decided to pull together as one team, one board, one goal
  • This example is from September of last year. Pretty smooth.
  • Throughput was down because we had 4 large projects going on simultaneously, so smaller items blocked.Infrastructure work (e.g. code cleanup, upgrades, etc.) were not getting done.Team defined classes of service – pebbles, rocks, sand, plus infrastructure and design only.

×