Your SlideShare is downloading. ×
Transitioning to Kanban - Aug 11
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Transitioning to Kanban - Aug 11

620
views

Published on

Published in: Business, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
620
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • We didn’t get it right the first week.
  • 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 decided to use post it “flags” to indicate a blocked item.We created a parking area for “work not on the board” for visibility sake.
  • Breaking items into tasks allowed for better tracking of progress, and made it easier for people to see item that they could collaborate on.
  • We had trouble managing dependencies between the two boards/teamsWe decided to pull together as one team, one board, one goal
  • Cycle times look good, but would like to see more predictability on Pebbles.
  • Spike in February cycle times due to Know How items
  • Standard Deviation is a measure of predictability. The bigger the standard deviation, the less predictable we are.
  • We still “retro”. We try to look at items that exceed estimates to try to learn from our mistakes.
  • Throughput dramatically higher in March due to Know How. May throughput down because of Google/Open ID and Network Solutions items. Lots of work, but didn’t deliver until June. Increase in the number of bugs also affects throughput.
  • 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.
  • Transcript

    • 1. Copyright © 2011 Constant Contact Inc.
      Transitioning Your Team to Kanban: Theory and Practice
      Gil Irizarry & Susan Jacobs
      Constant Contact
      August 2011
    • 2. Copyright © 2011 Constant Contact, Inc.
      2
      Agenda
      • A bit about us and Constant Contact
      • 3. Theory –
      • 4. Motivations
      • 5. Background
      • 6. What is Kanban and how does it work
      • 7. Practice –
      • 8. Setting up a Kanban board
      • 9. Establishing policies and limits
    • Copyright © 2011 Constant Contact, Inc.
      3
      Gil’s background
      • Program Manager at Constant Contact
      • 10. Over 20 years software development and management experience, over 5 years in an agile software development environment
      • 11. CSM and PMP certifications, Kanban coaching training with David Anderson
      • 12. BS from Cornell, ALM from Harvard, certificate in Management from MIT Sloan
      • 13. girizarry@constantcontact.com, gil@conoa.com
      • 14. http://www.slideshare.net/conoagil
    • Copyright © 2011 Constant Contact, Inc.
      4
      Susan’s background
      • Engineering Manager, Advanced Editor Team, at Constant Contact
      • 15. BS degree in Computer Science / Information Science from Binghamton University
      • 16. sjacobs@constantcontact.com, Twitter: @sjacobs146
    • Copyright © 2011 Constant Contact, Inc.
      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
      • 17. >$200MM gross revenue per year
      • 18. >800 employees
      • 19. >470K paying customers
      • 20. Engineering and Operations total about 150 people
      • 21. First Scrum team formed in 2006
    • Copyright © 2011 Constant Contact, Inc.
      6
      Constant Contact
      • Constant Contact is HIRING!
      • 22. http://www.constantcontact.com/about-constant-contact/careers/index.jsp
    • Copyright © 2011 Constant Contact, Inc.
      7
      Motivations
      • We want to move to Agile management methods. Why?
      • 23. React quicker to changing market conditions
      • 24. Get new features to users more quickly
      • 25. Frequent releases are smaller releases
      • 26. Better Quality
    • Copyright © 2011 Constant Contact, Inc.
      8
      Quick Review of Scrum
      • Fixed iterations
      • 27. Daily stand-ups
      • 28. What did you do yesterday, what did you do today, any impediments
      • 29. Retrospectives
      • 30. Burn-down chart
      • 31. Board with To Do, In Progress and Done states
    • Copyright © 2011 Constant Contact, Inc.
      9
      Lean Principles
      Leading Lean Software Development: Results Are not the Point by Mary and Tom Poppendieck
    • 38. Copyright © 2011 Constant Contact, Inc.
      10
      Foundational Principles of Kanban
      • Start with what you do now
      • 39. Agree to pursue incremental, evolutionary change
      • 40. Respect the current process, roles, responsibilities & titles
      From: http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method (David Anderson)
    • 41. Copyright © 2011 Constant Contact, Inc.
      11
      5 Core Properties of Kanban
      • Visualize the workflow
      • 42. Team board states are a reflection of the value stream
      • 43. Limit WIP
      • 44. Manage Flow
      • 45. Implied that flow should be continuous
      • 46. Make Process Policies Explicit
      • 47. Improve Collaboratively (using models & the scientific method)
    • Copyright © 2011 Constant Contact, Inc.
      12
      Kanban and Roles
      Org
      • Prioritization
      • Definition
      • Ready-Ready
      Lead
      Team
      • Work mgmt.
      • Metrics
      • Improvement
      • Delivery
      • Flow
    • 48. Copyright © 2011 Constant Contact, Inc.
      13
      You are one team!
    • 49. Copyright © 2011 Constant Contact, Inc.
      14
      Value Mapping Exercise
      How do you make dinner?
    • 50. Copyright © 2011 Constant Contact, Inc.
      15
      Sample Value Stream
      Shop for food 30 min
      Cook Food 15 min
      Unpack groceries 5 min
      Value:
      Eat!
      Serve Dinner 5 min
      Drive home 30 min
      Wash Pots 15 min
      Drive to market 30 min
      No Value:
      50 min / 130 min = 38% efficiency
    • 51. Copyright © 2011 Constant Contact, Inc.
      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 efficiency
    • Copyright © 2011 Constant Contact, Inc.
      17
      Sample Kanban Board
      States
      WIP Limits
      Classes of Service
    • 52. Copyright © 2011 Constant Contact, Inc.
      18
      Pull, not Push
      • Work items should be pulled into available lanes
      • 53. Work should not be pushed when completed, even if its lane is full
      Pull:
      Push:
    • 54. Copyright © 2011 Constant Contact, Inc.
      19
      Limit WIP
      • Why?
      • 55. Less multitasking
      • 56. Less time lost to context switching
      • 57. Better quality
      • 58. Smoother flow
    • Copyright © 2011 Constant Contact, Inc.
      20
      Classes of Service
      • Different types of work need to be handled and prioritized differently
      • 59. We manage this through the concept of classes of service. Similar projects are grouped into classes and each class is assigned an allocation.
      • 60. 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.
      21
      Sample CFD
    • 61. Copyright © 2011 Constant Contact, Inc.
      22
      Team Kanban
      • Teams plan continuously. Backlogs should be constantly groomed.
      • 62. Teams test continuously
      • 63. 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
      • 64. It’s OK if a team starts work for the next release in the current release
      • 65. Aim for development and testing to flow more smoothly through your system
    • Copyright © 2011 Constant Contact, Inc.
      23
      Metrics
      • Considering gathering the following:
      • 66. Cycle time on items after grouping them by size:
      • 67. Completion time for small, medium and large
      • 68. Spread of cycle times
      • 69. Work items completed
      • 70. Open defects in production, to give a high-level approximation of technical debt
    • Copyright © 2011 Constant Contact, Inc.
      24
      Metrics guide planning and estimation
      • Over time, we would expect that the spread of cycle times for a given item size goes down.
      • 71. So, over time, an estimate of completion time for items of a given size should become more accurate.
      • 72. 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.
      • 73. Large items should in most cases be broken down into smaller items
    • Copyright © 2011 Constant Contact, Inc.
      25
    • 74. Copyright © 2011 Constant Contact, Inc.
      26
      Resources
      • Kanban by David J Anderson
      • 75. Implementing Lean Software Development: From Concept to Cash - by Mary Poppendieck and Tom Poppendieck
      • 76. Scrumban - Essays on Kanban Systems for Lean Software Development - by Corey Ladas
      • 77. http://www.netobjectives.com/
    • Copyright © 2011 Constant Contact, Inc.
      27
      Kanban in practice
    • 78. Copyright © 2011 Constant Contact, Inc.
      28
      Kanban in Practice
      • The Website team at Constant Contact started using Kanban in the Spring of 2009.
      • 79. I was a Principal Engineer at the time. I’m currently the Engineering Manager of our advanced editor team.
      • 80. Mike Fitterman (currently Director of Engineering) and Rick Simmons introduced Kanban to the team.
      • 81. It has been an evolutionary process.
    • Why Kanban?
      • Shorter sprint lengths were forcing us to artificially break up items in order to fit within sprint boundaries.
      • 82. Sprint planning consumed the team for an entire day.
      • 83. Most of the work for a sprint was getting completed all at once, close to the end of the sprint.
      • 84. QA had nothing to do at the beginning of a sprint, but were overworked at the end.
      Copyright © 2011 Constant Contact, Inc.
      29
    • 85. Mapping the Value Stream
      • At the time, the Website team was really 2 teams, Engineering and Design.
      • 86. We asked the teams to map out their current development process.
      • 87. It was really complicated…
      Copyright © 2011 Constant Contact, Inc.
      30
    • 88. Mapping the Value Stream
      Copyright © 2011 Constant Contact, Inc.
      31
    • 89. How do you set a WIP limit?
      • Setting WIP limit is more art than science.
      • 90. Don’t overthink the initial WIP limit, it will change based on metrics.
      • 91. Start WIP limit at 1.5X the number of team members.
      • 92. That WIP limit is for the whole board.
      • 93. Divide total WIP amongst the columns, whatever feels right.
      • 94. Take photos of the board daily for Cumulative Flow Diagram.
      Copyright © 2011 Constant Contact, Inc.
      32
    • 95. Week 2 – Patterns emerge
      Copyright © 2011 Constant Contact, Inc.
      33
      Verify column over limit
      Blocked Items
      Work not on board
    • 96. Week 4 – Board Changes
      Copyright © 2011 Constant Contact, Inc.
      34
      Wait states
      Less columns
      Team adding policies
    • 97. Policies
      • The team defined policies for moving items into each state.
      • 98. Policies are the requirements that must be met before an item is considered ready for the next state.
      • 99. Policies were written down in a wiki and posted on the board.
      • 100. The team frequently ignores policies, so the scrum master has to keep them honest ;-).
      Copyright © 2011 Constant Contact, Inc.
      35
    • 101. Copyright © 2011 Constant Contact, Inc.
      Items
      Tasks
      Week 5 – Items broken into Tasks
      36
    • 102. One Team – Single Flow
      Copyright © 2011 Constant Contact, Inc.
      37
      Item and task type by color
      Produce
      Todo
      Bugs & Footprints on board
      WIPL = 6 full items
      Visible policies
    • 103. Metrics are the Key to Improvement
      • Cycle Time – Elapsed time from Design to Release to Production
      • 104. Perceived lack of predictability compared to Scrum was an issue.
      • 105. By tracking Cycle Time, we can eventually provide Service Level Agreements to stakeholders.
      • 106. SLA = Avg. Cycle Time + 2(Standard Deviation)
      Copyright © 2011 Constant Contact, Inc.
      38
    • 107. Cycle Times – May 2011
      Copyright © 2011 Constant Contact, Inc.
      39
      SLA = Avg. Cycle Time + 2(Standard Deviation)
    • 108. Cycle Times
      Copyright © 2011 Constant Contact, Inc.
      40
    • 109. Cycle Time Standard Deviation
      Copyright © 2011 Constant Contact, Inc.
      41
    • 110. Examine Outliers to improve Process
      Copyright © 2011 Constant Contact, Inc.
      42
      • Aberdeen – delays due to churn
      • 111. SMB Week Landing Page – we decided to start work despite the fact that many dependent assets were not ready. Stakeholder pressure to meet a deadline.
      • 112. Chamber Website Design, and Add Simple Share Tutorial for potential bottlenecks.
    • Throughput
      Copyright © 2011 Constant Contact, Inc.
      43
    • 113. Cumulative Flow Diagram
      • QA overloaded
      • 114. Worked on more constant delivery
      • 115. Identified a bottleneck with source control
      • 116. Changed our branching strategy to improve
      Copyright © 2011 Constant Contact, Inc.
      44
      Before
      After
    • 117. Cumulative Flow Diagram
      Copyright © 2011 Constant Contact, Inc.
      45
      • By September, we’re now releasing twice a week to Production
      • 118. Much smoother CFD, continuous deliver improves cycle time
    • One Year Later…
      Copyright © 2011 Constant Contact, Inc.
      46
      New classes of service
    • 119. Conclusion
      Copyright © 2011 Constant Contact, Inc.
      47
      Thanks For Spending This Time With Us