Generally, the term “scaling” applies to having multiple teams working on the same thing. Some nuggets for you right from the start:
Three golden Rules
- No matter which scenario you encounter, there is one golden rule of Agile you always have to heed: Use your primary tool (which is the grey mass between your ears) to find a suitable solution for your specific context. You will have a hard time finding an out-of-the-box solution that really fits you 100%. There is no “one size fits all” when it comes to organizational development.
- Start small and get it right first. Whatever you have when you start scaling will be scaled. That means, if you have a crappy “Scrum But” implementation for one team, you will get to an even crappier “Scrum But” implementation for 20 teams after scaling. If you have a well-working implementation of Scrum for one team, your chances are good to get to a well-working scaled situation.
- Take one step at a time. While there are examples where changing 800 (and more) people at once actually worked, it usually doesn’t. If you have one well-working team, add one to three and get them to work as well. Once they do, add more teams or practices.
Unfortunately, people sometimes mean very different things when they talk about “scaling”. There are different scenarios you might encounter:
- One Team is working on several products at the same time
- There are several sites involved in the development effort, no matter with how many teams (virtual teams)
- There are 2-10 Scrum Teams working on the same product
- There are >10 Scrum Teams working on the same product
- There are 2-10 Teams (with Scrum or without) working on different products, with no dependencies
- There are 2-10 Teams (with Scrum or without) working on different products, with dependencies
- There are >10 Teams (with Scrum or without) working on different products, with dependencies
- The development department is working Agile and now the rest of the organization should align
For all of these eight scenarios, I will give you some explanations and hints how to handle them. If you have additional examples, let me know. I will try to incorporate them.
1. One Team is working on several products at the same time
Personally, I wouldn’t consider this a “scaled” scenario. It is plain multitasking. It is what we usually try to get rid of when we introduce agile methods. While this can be okay in service environments, it is not in development. Your people will lose focus and traction if they have to switch between tasks. The way to do this “properly” is to define several Sprints for one product and only start work on additional products later (e.g. three months product A followed by three months product B).
2. There are several sites involved in the development effort, no matter with how many teams (virtual teams)
Yes, you can work with distributed (separate teams at separate locations) and dispersed (members of one team at separate locations) teams in Scrum. However, this is usually not cost-effective, if not managed properly (also see this for the reasons: http://scrumorakel.de/blog/index.php?/archives/32-The-reasons-why-distributed-teams-are-less-effective.html). If you refrain from just looking at the hourly rates and start calculating coordination time and result quality, chances are that outsourcing doesn’t pay off.
So what you have to do is to reduce the virtual distance. This means you have to make sure infrastructure and technology fit the job and people know each other on a personal level. So, fly everyone to every location once in a while and use a month or two in the beginning of the project to have everybody work together in person. While they are not working together, send ambassadors over to each location and make sure technology is always working with a single click so people have their colleagues at their fingertips. The intensity of your measures depends on the degree of virtual distance you are facing and on the question if you are working distributed or dispersed (dispersed teams need more attention than distributed ones).
3. There are 2-10 Scrum Teams working on the same product
Having more than one team working on a product is what usually is meant by the term “scaling”. Two teams rarely need special attention since people just talk – especially if they are sitting in the same room. Three to ten teams do need your attention in several areas:
- a. Roles
- b. Knowledge sharing
- Meetings
- Artifacts
- Quality
- Architecture
- Development tools
- Coding guidelines
- Team rules / charters
Mind the first golden rule: Use your brain and find your own way!
You will have to decide if your Product Owner (there is one product, so there should be a single Product Owner) can handle 10 teams at once the way he used to. You will also discuss the need for “central” roles or hierarchies (“Chief Product Owner” or “Super Scrum Master”). My personal experience is that you should refrain from such hierarchies if at all possible. They introduce a command and control element you tried to get rid of earlier. Instead, let the teams self-organize around the problems that are introduced with scaling. Quite often, teams will just introduce a community of practice to solve the roles and knowledge-sharing aspects. They will also be able to find the right amount of meetings: Maybe one joint Sprint Planning and joint Sprint Review (instead of 10 individual meetings) is enough for all teams? Maybe you still need separate meetings, but can shorten them? Maybe people want to listen in on their respective Daily Scrums? Maybe they find this unnecessary? One thing is sure, however: There is one Product Increment, so there must be one Product Backlog, a common understanding of quality and an overarching architecture (not necessarily design). This might lead to a need for common development tools and coding guidelines. However, I have seen many teams that did not use the exact same tools or exact same guidelines and still succeeded. In fact, they made a conscious decision for the better – which you should do as well. Let the people having the problems figure out the solutions!
4. There are >10 Scrum Teams working on the same product
For some reason, having more than 10 teams working on the same product seems to be a natural boundary of some sort. In my personal experience, the coping mechanisms described above did not work as well here as they did in smaller scaled environments. On top of that, I experienced a massive performance drop over and over again when more than ten teams were working in the same code base. Communication needs and coordination overhead seems to grow exponentially. Whenever I have the choice, I prefer 7 to 70 teams mingling in the same code base. My honest belief is that 7 teams can accomplish more in the same time than 70 do. If you do it anyway you will have to introduce some sort of structure. The exact nature of that structure is very specific to your context though – I cannot just draw you the silver bullet here. Just make sure to involve the people affected and try to replace controlling hierarchies with servant leaders, coaching the “subordinated” teams instead of incapacitating them. If you try to use defined frameworks for this scaling approach, make sure you don’t apply them without having reflected over every single aspect first. You might do more harm than good.
5. There are 2-10 Teams (with Scrum or without) working on different products, with no dependencies
Well, if they do not have any dependencies, what do you want to scale? If there is actually an answer popping up in your head, try to figure out if this is just a relic from a time when you still could control everything. For example, some customers claim they need a “common architecture” across multiple products. However, when they take a closer look they usually figure out they neither have nor need this.
6. There are 2-10 Teams (with Scrum or without) working on different products, with dependencies
Different products, but dependencies are what I encounter most often. So this is not about managing many teams on one code base, this is about managing interfaces. You probably have been doing this for years already. The difference with Scrum is that you no longer have silo groups of people but rather cross-functional teams. This can mean that every team having to interact with other products is allowed and capable to touch those products - if they make sure they don’t break anything (automated regression testing comes in handy here). Maybe coordination through communities of practice is enough. Maybe you need a “Scrum of Scrums”. Whatever you do, sit down with your teams and figure out what the problem is. Then use your primary tool (remember the grey mass?) to find solutions together with them. Try to keep it simple – scaling several products through several teams is not necessarily rocket science.
7. There are >10 Teams (with Scrum or without) working on different products, with dependencies
Here the same rules apply. Usually, not all (say, 50) teams have dependencies with all other teams. Especially not if they are truly cross-functional. So it is not any more difficult than 6.
I only encounter such huge unmanageable dependencies if there are remains from the past: A joint “framework” team, providing some stuff for all other teams, not letting them change it themselves. A “core product” team, servicing a huge pile of failure from the past, so messy only these few cracks still understand it – kind of. Or some sort of back-end / front-end separation, resulting in teams always waiting for one another, always claiming “we adhered to the interface specification” and still not achieving a truly “done” product increment.
All these issues are symptoms that you didn’t do your homework. You scaled crap. No process on earth can make this work well without getting rid of the root causes first. This, however, is extremely hard work and not part of the “scaling” domain.
8. The development department is working Agile and now the rest of the organization should align
Most often, IT middle management asks this question. They implemented some sort of Water-Scrum-Fall (meaning programming happened in Sprints, but analysis and QA happened in separate phases) and at some point realized that while they could code better, the other processes did not keep up with their pace and quality. This is natural to happen and a good thing! It is not what I would consider “scaling”, but it definitely is worth discussing. Changing parts of the organization is called “organizational development”. You can only succeed here, if all affected parties have an urgency to change and support your solution (in this case: Scrum). If you accomplished this, you have to develop solutions with all affected parties and generate wins that prove you are on the right track. Do this and stick to the golden rules above (and read more about the topic of organizational change, e.g. here or here).
This article is just a brief overview on the topic of scaling, of course. To find appropriate answers for your specific situation, you will probably have to read and learn a lot (also see the reading recommendations below). In general, stick to the golden rules and always solve problems with your solutions rather than introducing some remedy without knowing your problem.
Enjoy the transition!
Reading recommendations:
Maximini – The Scrum Culture: This explains what cultural impact Scrum can have, how this culture can scale and how to apply Kotter’s model on Scrum introductions.
Kotter – Leading Change: Excellent book about how to go about organizational change.
Larman & Vodde - Practices for Scaling Lean & Agile Development: – One of the best books about scaling Scrum. Be aware though that you are reading an opinion, not a silver bullet.
Lojeski & Reilly - Uniting the Virtual Workforce: Everything you ever wanted to know about virtual teams, including the virtual distance model