Copyright © 2011 Constant Contact Inc.<br />Transitioning Your Team to Kanban: Theory and Practice<br />Gil Irizarry & Sus...
Copyright © 2011 Constant Contact, Inc.<br />2<br />Agenda<br /><ul><li> A bit about us and Constant Contact
Theory –
Motivations
Background
What is Kanban and how does it work
Practice –
Setting up a Kanban board
Establishing policies and limits</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />3<br />Gil’s background<br...
 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</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />4<br />Susan’s backgroun...
 BS degree in Computer Science / Information Science from Binghamton University
 sjacobs@constantcontact.com, Twitter: @sjacobs146</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />5<br />B...
>$200MM gross revenue per year
 >800 employees
 >470K paying customers
Engineering and Operations total about 150 people
First Scrum team formed in 2006</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />6<br />Constant Contact<br ...
http://www.constantcontact.com/about-constant-contact/careers/index.jsp</li></li></ul><li>Copyright © 2011 Constant Contac...
React quicker to changing market conditions
Get new features to users more quickly
Frequent releases are smaller releases
Better Quality</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />8<br />Quick Review of Scrum<br /><ul><li>Fi...
 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</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />9<br />Lean P...
 Build Quality In
 Create Knowledge
 Defer Commitment
 Deliver Fast
 Respect People
 Optimize the Whole</li></ul>Leading Lean Software Development: Results Are not the Point by Mary and Tom Poppendieck<br />
Copyright © 2011 Constant Contact, Inc.<br />10<br />Foundational Principles of Kanban<br /><ul><li> Start with what you d...
 Agree to pursue incremental, evolutionary change
 Respect the current process, roles, responsibilities & titles</li></ul>From: http://agilemanagement.net/index.php/Blog/th...
Copyright © 2011 Constant Contact, Inc.<br />11<br />5 Core Properties of Kanban<br /><ul><li> 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)</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<...
Upcoming SlideShare
Loading in …5
×

Transitioning to Kanban - Aug 11

815 views
744 views

Published on

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

No Downloads
Views
Total views
815
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

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 &amp; Test Plans, Design, Review&amp; Revision, Code, Review &amp; Revision, Verify, DoneDesign Lanes: Queue, User Experience, UX Review &amp; Revision, Design, Review&amp; Revision, Test Plan, Code, Review &amp; 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.
  • Transitioning to Kanban - Aug 11

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

    ×