Agile The Kanban Way - Central MA PMI 2011

1,101 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,101
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • Agile The Kanban Way - Central MA PMI 2011

    1. 1. Agile The Kanban Way PMI: Central MA Chapter 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. What is Kanban? • A scheduling system that tells you what to produce, when to produce it, and how much to 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 Wikipedia: http://en.wikipedia.org/wiki/KanbanCopyright © 2011 Constant Contact, Inc. 9
    10. 10. 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. 10
    11. 11. 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. 11
    12. 12. Kanban and Roles • Prioritization • Definition • Ready-Ready Org • Work mgmt. • Delivery • Metrics • Flow • Improvement Lead TeamCopyright © 2011 Constant Contact, Inc. 12
    13. 13. You are one team!Copyright © 2011 Constant Contact, Inc. 13
    14. 14. Value Mapping Exercise How do you make dinner?Copyright © 2011 Constant Contact, Inc. 14
    15. 15. 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. 15
    16. 16. 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. 16
    17. 17. Sample Kanban Board States WIP Limits Classes of ServiceCopyright © 2011 Constant Contact, Inc. 17
    18. 18. 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. 18
    19. 19. Limit WIP • Why? • Less multitasking • Less time lost to context switching • Better quality • Smoother flowCopyright © 2011 Constant Contact, Inc. 19
    20. 20. 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. 20
    21. 21. 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. 21
    22. 22. 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. 22
    23. 23. 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. 23
    24. 24. 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. 24
    25. 25. 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. 25
    26. 26. Kanban in practiceCopyright © 2011 Constant Contact, Inc. 26
    27. 27. 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
    28. 28. 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
    29. 29. Mapping the Value StreamCopyright © 2011 Constant Contact, Inc. 29
    30. 30. 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. 30
    31. 31. 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. 31
    32. 32. 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. 32
    33. 33. One Year Later… New classes ofCopyright © 2011 Constant Contact, Inc. service 33
    34. 34. 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. 34
    35. 35. Conclusion Thank you!Copyright © 2011 Constant Contact, Inc. 35

    ×