Have you successfully implemented Scrum on your team, but are finding the pain of scaling your Scrum deployment to the larger organization too much to handle? Is the Scrum of Scrums concept not working out the way you thought it would? Have you had success with scaling Scrum, and want to share what you’ve learned with others? If you answered yes to any of these questions, join us for this interactive session where Melanie Paquette shares the experiences of different of different types of organizations that have had success in scaling Scrum. The organizations profiled include a large, geographically dispersed team of over 300 embedded software developers as well as a smaller, mostly co-located team of 50 mobile application developers. Learn what these organizations have in common, and take back practical techniques you can use to scale Scrum, including how to leverage a traditional project management organization to help your scaling efforts, how to structure large teams to involve the right people, and how to work with geographical distribution.

1. 1

2. 2

3. 3

4. I assume everyone understands the basics of Scrum, and won’t be going through that.
Examine two very different organizations who ultimately ended up using the same techniques to be successful in
scaling Scrum. This presentation focuses on the techniques that they used, which may differ from those
recommended in some of the more popular books on the subject of scaling. My hope is that you’ll be able to use
at least one of these techniques to benefit scaling efforts in your own organizations.
Questions throughout please.
4

5. I’m defining large as > 40 people (i.e. 4 or more Scrum teams).
You want to scale when you are delivering a single product with a large team of people. You do not want to scale
Scrum if you have a large team working on a diverse set of project (that’s a whole different issue).
5

6. 6

7. Each division is like its own smaller company
Processes, tools, environment, all differ between divisions
Customer base – large telco
7

8. 4 major sites, 3 continents, 4 time zones
Organized around functions (architecture, software development, hardware development, test, project
management)
Sub-groups organized by product architecture (software/hardware components)
8

9. Releases: Typically large: >18 months duration, >100 developers, > 300K NCSL, 13 year old code base
Life cycle: Big, up front requirements gathering/documentation
Whole project scheduled early in the product life cycle
Throw over the wall to test at the end
Requirements churn
Frequent
Late (in the development life cycle)
Missed schedules
Late deliveries to test, certification, customers
Denial of schedule slips – thought development wouldn’t work hard enough if they recognized the date
needed to move
Defects
Backlog of thousands of bugs
Morale
“Sweat shop” mentality – working 24 x 7 (Anthony’s story)
9

10. Started with one pilot team – developers only
Later added testers
Slowly added additional teams
Brought in people from other parts of the organization who had successfully scaled Scrum
Note – this was a work in progress when I left – still expanding the organization. We’ll talk more about how far
they got in the second half of the presentation.
10

11. 11

12. Customer base: consumer, enterprise, wireless carriers
12

13. 13

14. Releases: Typically small: < 6 months duration, < 30developers
Life cycle: Big, up front requirements gathering/documentation
Whole project scheduled early in the product life cycle
Throw over the wall to test at the end
Requirements churn
Frequent
Late (in the development life cycle)
Changing priorities
Uncertain schedules
14

15. Brought in internal Scrum coaches to transition to Scrum (boot camp) – trained 50
people and had them up running their sprints and Scrum of Scrums in one week.
Was a good place for us to experiment with Scaling – open environment, cohesive
team, co-located.
15

16. 16

17. Org Structure:
•Functional/architecture based organization
•Dealing with being part of the new organization
•Difficult to deliver user visible features
•Creating cross functional teams tended to be problematic – silos
•How to ensure architecture didn’t deteriorate
Beyond SW:
•How to manage dependencies between Hardware and Software
•Can hardware developers use Scrum?
•Dealing with dependencies on corporate functions
•Working with other teams who aren’t using Scrum
Geography:
•Obvious issues:
•Communication difficulties
•Some sites had no common working time
•No sense of commitment or team due to having never met teammates in person
•Not so obvious issues:
•Cultural resistance to Scrum
•European site was much more adverse to Scrum than North American or Asian sites
Delivery Schedules:
•Releases were defined based on content
•But, schedule was king
•And content kept changing
Release Management
•A traditional project management structure was in place, and it needed to be maintained
•Senior management still needed some level of more traditional oversight
•Releases were so big (from a content, personal and schedule perspective) that PMs could not effectively function as
SMs, unless they were cloned
17

18. 18

19. I recently attended Alan Altas’s of Rally webinar titled Scaling Agile in 7 Smooth Steps, and one of the first pieces
of advice he gave was to “ruthlessly apply agile principles”. It turns out that everything that you need to do for a
single Scrum team becomes that much more important when you scale. Keep agile principles in mind whenever
you are faced with a problem. These organizations were successful at scaling because they did this.
Also, invest in training and coaching. If you have internal coaches, so much the better, as they will have extra
credibility in your organization.
19

20. Share between teams, and share with others. These organizations shared a product backlog (perhaps with
multiple views into it, as suggested by Mike Cohn), and they had demo days, where they shared their work with
everyone. This is a good time to involve those you separated from previously – invite them to your planning
sessions and demos. Established a shared, aligned sprint length, definition of done, coding standards, and other
processes. In addition to individual Scrum team retrospectives, have a joint retrospective, or share the results of
each team’s retrospective.
You might also consider sharing team members, particularly where you can’t minimize cross team dependencies.
Having the same person on both teams will help provide effective dependency management.
20

21. Choose your ScrumMasters and Product Owners wisely. Assuming your project manager will fill the ScrumMaster
role is a mistake when you’re planning to scale (and maybe in general). A Product Manager is usually a good
choice for a PO, skill set wise, but you have to make sure they’re going to be as available as the team needs them
to be.
Who did these organizations choose as ScrumMasters?
• Software team leads/managers
• Architects
• Testers
• Senior developers
Just like in a one team environment, your ScrumMaster has to be an ambassador of Scrum to the team, but they
also have to be able to resolve more complex dependencies than they otherwise would. Make sure they have the
technical expertise to help. Avoid the ScrumMaster for hire syndrome.
You need a good Product Owner. This is true of course for a single Scrum team, but hyper true for teams that are
scaling. These organizations had an uber product owner who was responsible for the product backlog as a whole,
and individual product owners who could make day-to-day decisions about their subject matter areas. If you
don’t have this, you’ll be blocked often. Have times where all the POs get together to understand priorities and
do team building. Choose POs who have the following characteristics:
•Ability to deal with and involve multiple stakeholders
•Good understanding of the market and the organization
•Speak the same language as the other POs
•Decisive – able to make good quick decisions
•Consistent - i.e. not changing mind back and forth
•Sophisticated communication and influencing skills
•Can represent customers and users of the system/product
•Has the respect of developers
•http://www.offshoreagile.com/resources/articles/right_person_for_the_job/
21

22. A release train based approach is one where the organization recognizes that they are schedule driven. In this
model, the product release dates are fixed, and the content that is ready on the date is released. This requires a
commitment from your product owner team to prioritize feature content and manage the product backlog very
carefully.
These organizations took a release train approach. This gives the teams focus in planning, estimating and
prioritizing.
I could do an entire talk on release trains – I plan to write a blog post on the subject so please visit my blog or see
me after if you’re interested in more information on this
22

23. These organizations both reused existing processes and roles where they could. Of particular importance is the
project management organization. Both of these orgs reused existing project management structures to fulfill the
Scrum of Scrums need. In fact, organization 1 didn’t even use the concept of Scrum of Scrums, they simply re-
structured their weekly project status meetings to fit the new model.
Project Managers are already familiar with dealing with inter-team dependencies and they have the contacts to
help resolve common Scrum team impediments and making sure corporate functions are lined up. They can also
fairly easily reuse whatever senior management reporting structures they have in place with some pretty minor
adjustments. Make use of what you already have – don’t try to re-invent the wheel.
23

24. Don’t try to include everybody. On small teams, or in small companies, it makes sense to include every possible
person who will contribute to your project on your Scrum team. In large organizations, don’t even try. Technical
writers, support specialists, certification engineers, etc. are usually part of a central service function in large
organizations. Those people are working on multiple projects at once and having them be part of your team will
usually make them frustrated because they’ll perceive there to be a great deal of overhead. Follow their
processes for involving them and let your project management organization manage the dependencies.
Separate geographically too. Once again, a practice that matters on single teams, but is intensified on scaled
teams. Geographical distribution is bad for teams in general, which is why Scrum says co-located. But most large
organizations are geographically dispersed. Does that mean that you have to fold up your Scrum tent and go
home? No! Work with geography, not against it. I’m continually surprised by the number of teams that strive for
geographical distribution – preferring to take the approach of taking a few team members from each location to
create several geographically distributed teams. The only reason Organization #1 was successful was because
they formed (cross functional) teams based on geographical lines. Let the project manager (or ScrumMasters)
deal with the inter-team dependencies. Organization #2 had less geographical distribution, and certainly not
enough to form teams on geographical boundaries. Their distributed team members agreed to work on the home
team’s time zone.
And separate the work. Plan the work between teams to minimize cross team dependencies as much as possible,
and to plan the dependencies you want to have.
Tips for choosing how to separate: - corporate organizations that work on many projects, part time people (less
than 50% of their time on your project). Those teams should follow their own processes, whether agile or
otherwise. Have people on your teams assigned to interface with those people. Include tasks in your sprints for
dependency management. Let the PMs help you here too.
24

25. Your team needs to be like a Swiss Army Knife – the team, and the individuals need to be able to do many things.
You might be able to get away with silos in smaller environments, but it won’t scale. People will necessarily have
to re-think their roles sometimes, and break down the barriers between analysts, developers and testers. It also
means that you have to let go of your area of expertise. But, you don’t want architecture to deteriorate either.
Organization 1 addressed this by forming a hybrid between cross functional feature teams, with a few component
based teams (as Mike Cohn suggests in Succeeding With Agile).
25

26. 26

27. This illustrates how organization 2 set up their team structure. Each team has
assigned team members (and roles). The resources at the bottom of the board in the
picture on the far left are shared between teams, or unassigned.
27

28. 28

29. 29

30. 30

31. 31

32. 32

33. 33