Scaling scrum teams
Growing
I would say that there is a tipping point in every organisation; that point where your product or company starts to get some traction and demand rapidly starts to increase. There is a point where you need to seriously start to consider about scaling scrum teams structure. If you don’t, you will find you will grow very quickly and you will get to a point where your team organisation will prevent further growth, hinder innovation, reduce efficiency and your ability to deliver quickly.
I have seen it before, company’s that have scaled too big and not thought about how their teams might function in the future, and their ability to adapt to change and with the company growth. These teams get bogged down with dependencies, internal politics and generally poor communication between them. They find themselves in a ‘silo’ structure, fighting for resource and capacity.Take the example below, this is probably quite familiar to a lot of you:
Here you have business teams that are split based on product, and they usually have their own visions and goals and don’t really communicate or collaborate with other product managers for the most part. You then find that development teams are split into component teams… because originally it was thought to be a good idea to put people with the same skill sets into the same teams; and why not — its done with most other business functions such as operations, finance, HR.
What you quickly come to realize that actually this is not very effective. You have product managers on business side fighting for development resource. To make it worse, teams are split into components, so if you have a feature that requires cross component development you are often waiting on a dependency; web team can’t start until server infrastructure is there and so on. You also find that you lack feature or domain specialists because everyone works on everything; so often the detailed knowledge is not there in the development team or its held with one person. And we all know what happens when that person leaves.
Business
Another point you might notice in the previous paragraph is the use of the term ‘business side’. This is another issue I see where is business side and development side, us an them. This is a fundamental flaw, everyone should be working together and these kind of invisible walls should be knocked down.
So the above is fine if you are a very small company, but as you scale and get bigger this team architecture is only going to cause you pain in the long term; and to fix becomes so expensive later in your company life cycle.
Using Scrum Teams
So you have taken the plunge and implemented scrum. You have your cross functional, autonomous scrum teams, working on loosely coupled features. When working on individual features that are not dependent on each other this is great. Each team can deliver frequent value with their dedicated resource and not have to worry too much about what everyone else is doing.
As we all know though, this is often not the case. What happens when your company is going large strategic programs where all teams must work together, or you have some feature teams that are working on functions that are all close together. A lot of co-ordination needs to be done between the product owners to ensure that everyone is in line, each knows whats in their scope and ensure everything is being done at the right time. In scaled agile framework you would have a program manager leading the project; but co-ordination still needs to be there.
How do we manage this?
Product Management Team
You implement a scaled product management scrum team. You take the concept of a scrum team and apply it to a team of product owners:
In this example, you have a Chief Product Owner who leads the team with regards to high level priorities, and the other product owners form the scrum team. You can apply the same artifacts of scrum, to ensure everyone is in line:
- Planning
- Review
- Retrospectives
- Daily Stand ups
Scaling
So how does this look for your company?
In the example above you can see that your teams now scale very well. Everyone is in communication and its easy to ensure all efforts are coordinated. This model is also future proof, so you can ‘plug; a new scrum team into this model, or take it out and put in another one.
Some examples from my experience where this works well:
- If you are a company that offers different products; so under the same umbrella or group — but these products are completely independent. You can apply this model to each product.
- If you are a company with one product, but different business units that are loosely coupled, you apply this model to each business unit (for example: payments team, finance team, player account team…).
You do not even have to stop there, this model is scaleble going up; so one tier above the Product Management Scrum Team you can apply a Program Management Scrum Team to ensure larger business strategies are in line.
Summary
Scaling scrum teams.
We all have problems with team structure and company architecture, and to be honest there is no silver bullet or out of the box framework that can help all teams; but I have found the above the most useful. It’s easy to adapt and change to fit your needs, and its future proof for any changes that may come your way in the future.
Most of us have probably been in the situation of seeing company restructures, takeovers and organisational changes. companies launching or acquiring new products — I have found for the most part, this ‘plug & play’ approach works quite well.
Social Media
Please check me out on social media:
