Beyond Scrum of Scrums

2,886 views

Published on

Move beyond your team to an Agile organization by managing team inter-dependencies and applying the principles of Kanban

Published in: Business, Technology

Beyond Scrum of Scrums

  1. 1. Copyright © 2011 Constant Contact Inc.<br />Beyond a Scrum of Scrums: Scaling Up Agile with Kanban<br />Gil Irizarry<br />Program Manager<br />Constant Contact<br />June 2011<br />
  2. 2. Copyright © 2011 Constant Contact, Inc.<br />2<br />Agenda<br /><ul><li> A bit about me and Constant Contact
  3. 3. Scrum and Kanban at the team-level
  4. 4. Scaling up to an engineering org</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />3<br />My background<br /><ul><li> Over 20 years software development and management experience
  5. 5. Over 5 years in an agile software development environment
  6. 6. Most recently working with Kanban, prior to that Scrum and RUP
  7. 7. CSM and PMP certifications, Kanban coaching training with David Anderson
  8. 8. BS from Cornell, ALM from Harvard, certificate in Management from MIT Sloan</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />4<br />My contact info<br /><ul><li> girizarry@constantcontact.com
  9. 9. gil@conoa.com
  10. 10. Contact me if you would like updated slides</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
  11. 11. >$200MM gross revenue per year
  12. 12. >800 employees
  13. 13. >450K paying customers
  14. 14. Engineering and Operations total about 150 people
  15. 15. First Scrum team formed in 2006</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />6<br />The Goal<br /><ul><li> We want to release more features more frequently
  16. 16. Why?
  17. 17. React quicker to changing market conditions
  18. 18. Get new features to users more quickly
  19. 19. Frequent releases are smaller releases: our customers often cannot absorb a large set of changes</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />7<br />The Challenge<br /><ul><li> 13 software development teams
  20. 20. 5 development and testing server clusters
  21. 21. 2 production server clusters in 2 data centers (soon to be 3)
  22. 22. A code base that was first created around 2004 and built up over time
  23. 23. And all utilizing one operations team</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />8<br />What do we have?<br /><ul><li> A mess of inter-dependencies
  24. 24. Image from http://viewyonder.com/2009/07/12/data-center-consolidation-road-to-unified-computing-service-analysis/ - Data Center Spaghetti. This problem exists in many other parts of the enterprise!</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />9<br />So, how do we address this?<br /><ul><li> Scrum of Scrums!
  25. 25. Um, wait…</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />10<br />A little review: how things used to be<br />
  26. 26. Copyright © 2011 Constant Contact, Inc.<br />11<br />This is appropriate if you are building an…<br />“Originally planned to enter service in May 2008, the [Dreamliner] project has suffered from repeated delays and is now more than three years behind schedule.” -- Wikipedia<br />
  27. 27. Copyright © 2011 Constant Contact, Inc.<br />12<br />Quick Review of Scrum<br /><ul><li>Fixed iterations
  28. 28. Daily stand-ups
  29. 29. What did you do yesterday, what did you do today, any impediments
  30. 30. Retrospectives
  31. 31. Burn-down chart
  32. 32. Board with To Do, In Progress and Done states</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />13<br />Scrum in a slide<br />
  33. 33. Copyright © 2011 Constant Contact, Inc.<br />14<br />Scrum of Scrums (of Scrums (of Scrums…))<br /><ul><li> How to integrate teams in Scrum?
  34. 34. Hold a Scrum of Scrums
  35. 35. What happens if you have too many teams?
  36. 36. Hold a Scrum of Scrums of Scrums, and so on…
  37. 37. Add a MetaScrum or two</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />15<br />Foundational Principles of Kanban<br /><ul><li> Start with what you do now
  38. 38. Agree to pursue incremental, evolutionary change
  39. 39. 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 />
  40. 40. Copyright © 2011 Constant Contact, Inc.<br />16<br />5 Core Properties of Kanban<br /><ul><li> Visualize the workflow
  41. 41. Team board states are a reflection of the value stream
  42. 42. Limit WIP
  43. 43. Manage Flow
  44. 44. Implied that flow should be continuous
  45. 45. Make Process Policies Explicit
  46. 46. Improve Collaboratively (using models & the scientific method)</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />17<br />Sample Kanban Board<br />
  47. 47. Copyright © 2011 Constant Contact, Inc.<br />18<br />Sample CFD<br />
  48. 48. Copyright © 2011 Constant Contact, Inc.<br />19<br />Compare with Burndown chart<br />
  49. 49. Copyright © 2011 Constant Contact, Inc.<br />20<br />Scrum and Kanban: Let’s combine them!(But how? And why?)<br />http://en.wikipedia.org/wiki/Reese's_Peanut_Butter_Cups#Marketing_and_advertising<br />
  50. 50. Copyright © 2011 Constant Contact, Inc.<br />21<br />Transistioning from Scrum to Kanban<br /><ul><li> We did not change how teams were currently working
  51. 51. We modeled existing hand-offs within the team, i.e. each team’s kanban board reflected that teams style of work</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />22<br />The Dilemma<br />Remember that teams want (and often need) to work continuously, but releases are discrete.<br />Multiple teams working together create interdependencies<br />How to resolve this?<br />
  52. 52. Copyright © 2011 Constant Contact, Inc.<br />23<br />Transforming Scrum (and Scrum of Scrums)<br /><ul><li> At the enterprise-level, team(s) management becomes a problem of dependency management
  53. 53. Planning, coordination and stand-ups at the departmental and organizational level need to be executed with this mind</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />24<br />What we have done at CTCT<br /><ul><li> At the organization-level:
  54. 54. Prioritized project list
  55. 55. All At Once Planning
  56. 56. Classes of Service
  57. 57. (Near) Continuous integration and (mostly) automated regression testing
  58. 58. Dependency and deliverable review
  59. 59. Release train</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />25<br />What we have done at CTCT<br /><ul><li> At the team-level:
  60. 60. Continuous delivery
  61. 61. Better metrics and metrics-driven estimation</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />26<br />Prioritized Project List<br /><ul><li> Product Management, Engineering and Operations leads meet every two weeks to prioritize all development projects
  62. 62. This becomes the organizational backlog, which drives each team’s backlog</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />27<br />All At Once Planning<br />
  63. 63. Copyright © 2011 Constant Contact, Inc.<br />28<br />All At Once Planning<br /><ul><li> Prior to the start of an iteration, teams use the prioritized project list to plan their upcoming work.
  64. 64. Planning involves the identification of deliverables and dependencies.
  65. 65. Dependencies are discussed with dependent teams.
  66. 66. A meeting is held (all at once planning mtg) in which all development teams present their dependencies to each other and to the operations team.</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />29<br />All At Once Planning, cont’d<br /><ul><li> At the end of the meeting, each team has their planned deliverables and incoming dependencies.
  67. 67. If they haven’t already, they determine their capacity and, based on the priorities, commit to a set of work.
  68. 68. This means that a team may have capacity to do work, but may not get to it in a release if that work pushes the operation team beyond its capacity.
  69. 69. Once the iteration starts, we will have each team’s set of commitments.</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />30<br />Classes of Service<br /><ul><li> Inevitably, the operations team can often become a bottleneck for development.
  70. 70. We attempt to manage this through classes of service. We borrow a concept from Kanban that says similar projects are grouped into classes and each class is assigned an allocation.
  71. 71. 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 />31<br />(Near) Continuous integration and (mostly)automated regression testing<br /><ul><li> It is important that builds, deployments and testing are as automated and continuous as possible. Tools we use:
  72. 72. Hudson for continuous integration
  73. 73. Puppet for automated deployments
  74. 74. Maven for managed builds
  75. 75. Selenium for automated testing
  76. 76. svn for source control and versioning
  77. 77. We still have a lot of work to do in this area</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />32<br />Dependency and deliverable review<br /><ul><li> We have a daily meeting, about 20 minutes, long in which we review each project, not each team.
  78. 78. Project leads review the deliverables and dependencies to which they have committed and say if they are on track or not.</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />33<br />Dependency and deliverable review, cont’d<br /><ul><li> We found the teams could still miss a deliverable even if they had no impediments. Deliverable tracking provides a better view of the state of the iteration
  79. 79. However, we still call the review meeting “Scrum of Scrums” because the name stuck!</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />34<br />Release Train<br /><ul><li> Releases are iterative but development is continuous</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />35<br />Release Train, cont’d<br /><ul><li> Scrum aims to make development iterative but this causes problems:
  80. 80. How do you handle all the testing at the end of the sprint? What if defects are found a day before the sprint ends?
  81. 81. If a deliverable misses a release (the train), it simply waits to capture the next one.
  82. 82. To be reiterate (and be explicit): we don’t penalize a team if a deliverable is not done at the end of a release and misses the release train</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />36<br />Release Train, cont’d<br /><ul><li> To make this work:
  83. 83. Releases must be short
  84. 84. Must have those tools for automated deployments
  85. 85. Marketing and support must be flexible enough to react to last-minute product changes</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />37<br />Kanban at the team-level<br /><ul><li> Teams plan continuously
  86. 86. Teams test continuously
  87. 87. It’s OK if a team finds a defect on the last day of the release.
  88. 88. It’s OK if a team starts work for the next release in the current release
  89. 89. Development and testing can flow more smoothly, because we do not want the end of an iteration to feel like this:</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />38<br />Kanban at the team-level<br />
  90. 90. Copyright © 2011 Constant Contact, Inc.<br />39<br />Metrics<br /><ul><li> We gather for each team:
  91. 91. Cycle time on items after grouping them by size:
  92. 92. Completion time for small, medium and large
  93. 93. Spread of cycle times
  94. 94. Work items completed
  95. 95. Open defects in production, to give a gross measure of technical debt</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />40<br />Metrics guide planning and estimation<br /><ul><li> Over time, we expect that the spread of cycle times for a given item size goes down.
  96. 96. So, over time, an estimate of completion time for items of a given size should become more accurate.
  97. 97. We have eliminated planning poker. Work items are just sized as smalls or mediums and the average cycle times for those sizes from the last release become the estimate for the upcoming release.
  98. 98. Large items are broken down in smaller items</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />41<br />
  99. 99. Copyright © 2011 Constant Contact, Inc.<br />42<br />How did we do?<br /><ul><li> Releases used to take 12 weeks. Now they take 5 weeks.
  100. 100. More importantly, testing used to take 6 weeks. Now it takes 1 week. Testing used to be 50% of the release cycle, but now is just 20%.
  101. 101. We have a better picture of our release at any given moment
  102. 102. A year ago, CTCT was not in the social media space. Now our service has ties to Facebook, Twitter and LinkedIn. We are becoming a leader in the social media marketing space.</li></li></ul><li>Copyright © 2011 Constant Contact, Inc.<br />43<br />How did we do?<br />
  103. 103. Copyright © 2011 Constant Contact, Inc.<br />44<br />Time for Questions<br />

×