Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Beyond scrum of scrums scaling agile how it works

694 views

Published on

Session by Ritu Mehta at Regional Scrum Gathering South Asia 2015

Published in: Leadership & Management
  • Be the first to comment

Beyond scrum of scrums scaling agile how it works

  1. 1. BEYOND SCRUM OF SCRUMS-SCALING AGILE HOW IT WORKS…..
  2. 2. 2 Agenda • A bit about me • Scrum at the team-level • Scaling up to an engineering org
  3. 3. 3 My background •Currently working as Director Product Development at Pitney Bowes Softwares. •15+ years of Development experience with 9+ years in Agile •Master’s in IT with SMP from IIM,Calcutta. •CSM,CSP,SPC & PMP certified • Global Agile Head for Pitney Bowes Software. Heading five regions including Europe, US, Asia Pacific
  4. 4. 4 Our Goal •One team or a handful of teams may be able to deliver small systems. Large complex systems require teams of teams to deliver significant features. How can companies benefit from “the team effect” at scale?
  5. 5. 5 The Challenge • 15 software development teams •6 development and testing server clusters • 3 production server clusters in 4 data centers • A code base that was first created around 2007 and built up over time • And all utilizing one operations team
  6. 6. 6 What do we have? • A mess of inter-dependencies
  7. 7. 7 So, how do we address this? • Scrum of Scrums! • Um, wait…
  8. 8. 8 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
  9. 9. 9 Scrum in a slide 3 Meetings Sprint: 4 weeks 3 Documents 3 Roles PO 1 SM 3 Product Backlog 1 Sprint BL 2 Burn-down 3 Product Stakeholders On-going Collaboration Sprint Planning Sprint Planning 1 Daily Scrum 2 Sprint Review Sprint Review 3 Daily TEAM 2
  10. 10. 10 Scrum of Scrums (of Scrums (of Scrums…)) • How to integrate teams in Scrum? •Hold a Scrum of Scrums • What happens if you have too many teams? •Hold a Scrum of Scrums of Scrums, and so on… •Add a MetaScrum or two
  11. 11. 11 Can we apply few core principles 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)
  12. 12. 12 Sample Kanban Board
  13. 13. 13 Scrum and Kanban: Let’s combine them! (But how? And why?)
  14. 14. 14 Transitioning from Scrum to Kanban • We did not change how teams were currently working • We modeled existing hand-offs within the team, i.e. each team’s kanban board reflected that teams style of work
  15. 15. 15 The Dilemma Remember that teams want (and often need) to work continuously, but releases are discrete. Multiple teams working together create interdependencies How to resolve this?
  16. 16. 16 Transforming Scrum (and Scrum of Scrums) • At the enterprise-level, team(s) management becomes a problem of dependency management • Planning, coordination and stand-ups at the departmental and organizational level need to be executed with this mind
  17. 17. 17 What we have done • At the organization-level: •Prioritized project list •All At Once Planning •Classes of Service •(Near) Continuous integration and (mostly) automated regression testing •Dependency and deliverable review •Release train
  18. 18. 18 What we have done: • At the team-level: •Continuous delivery •Better metrics and metrics-driven estimation
  19. 19. 19 Prioritized Project List • Product Management, Engineering and Operations leads meet every two weeks to prioritize all development projects • This becomes the organizational backlog, which drives each team’s backlog
  20. 20. 20 All At Once Planning
  21. 21. 21 All At Once Planning • Prior to the start of an iteration, teams use the prioritized project list to plan their upcoming work. • Planning involves the identification of deliverables and dependencies. • Dependencies are discussed with dependent teams. • 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.
  22. 22. 22 All At Once Planning, cont’d • At the end of the meeting, each team has their planned deliverables and incoming dependencies. • If they haven’t already, they determine their capacity and, based on the priorities, commit to a set of work. • 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. • Once the iteration starts, we will have each team’s set of commitments.
  23. 23. 23 Classes of Service • Inevitably, the operations team can often become a bottleneck for development. • 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. • For example, we may decide that 20% of ops time should be spent on infrastructure improvements, and 80% spent on servicing development
  24. 24. 24 (Near) Continuous integration and (mostly) automated regression testing • It is important that builds, deployments and testing are as automated and continuous as possible. Tools we use: •Team City for continuous integration • Automated deployments •Maven for managed builds •Selenium for automated testing •SVN for source control and versioning • We still have a lot of work to do in this area
  25. 25. 25 Dependency and deliverable review • We have a daily meeting, about 20 minutes, long in which we review each project, not each team. • Project leads review the deliverables and dependencies to which they have committed and say if they are on track or not.
  26. 26. 26 Dependency and deliverable review, cont’d • 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 • However, we still call the review meeting “Scrum of Scrums” because the name stuck!
  27. 27. 27 Release Train • Releases are iterative but development is continuous
  28. 28. 28 Release Train, cont’d • Scrum aims to make development iterative but this causes problems: •How do you handle all the testing at the end of the sprint? What if defects are found a day before the sprint ends? • If a deliverable misses a release (the train), it simply waits to capture the next one. • 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
  29. 29. 29 Release Train, cont’d • To make this work: •Releases must be short •Must have those tools for automated deployments •Marketing and support must be flexible enough to react to last-minute product changes
  30. 30. 30 Kanban at the team-level • Teams plan continuously • Teams test continuously • It’s OK if a team finds a defect on the last day of the release. • It’s OK if a team starts work for the next release in the current release • Development and testing can flow more smoothly, because we do not want the end of an iteration to feel like this:
  31. 31. 31 Kanban at the team-level
  32. 32. 32 Metrics • We gather for each team: •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 gross measure of technical debt
  33. 33. 33 Metrics guide planning and estimation • Over time, we 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. • 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. • Large items are broken down in smaller items
  34. 34. 34 How did we do? • Releases used to take 12 weeks. Now they take 5 weeks. • 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%. • We have a better picture of our release at any given moment
  35. 35. 35 QUESTIONS…

×