Often our projects are too big to have a single team working on them. Therefore, we have to find a way of several teams working together. In our example, we have agreed on scrum. What is now our first step?
First of all: You have probably already read a thing or two about how to best scale Scrum, and you have probably also come across SAFe. For 4 – 8 teams or anything on this scale, this is too big and too complex. SAFe means turning the entire organization inside out – keep your hands off it. When we talk about very large and very complex projects with multiple hierarchical levels, SAFe might get interesting. Of course, if that is your job, we can talk to each other, but for today we will look at the simple cases.
We start by avoiding the biggest mistake: Neither our teams, nor their competences or subjects are written in stone and signed with the blood of a virgin. Organizations tend to sticking with what they have and combine that. We – on the other hand – step back and ask ourselves, how the teams are actually mixed and woven.
We try to get the picture, how dependencies look like. The more dependencies we have, the more complex they are, the more difficult and unreliable everything will get. So, we ask ourselves how we can largely decouple the teams from one another. If we ignore this very important first step, we might end up in dependency hell because we have to pass tasks from one team to another in every sprint.
Our ideal is, that our teams can develop features independently of each other – so we are talking about feature teams. These teams are staffed in such a way, that they have all the necessary skills, so we have, for example, someone for databases, someone for frontend, architect, etc. The architecture of our product supports independent work from one another. Sounds wonderful in theory, and is also our goal in practice. We will never fully achieve it, but that is the path we are going to take.
The opposite of this – and this is what we find in many organizations – are component teams. We can freely call them specialist teams. So, in one team are all of our database people, in the next all infrastructure people, etc.
The component team model means that each feature has to go through several teams, which means that the dependencies become very complex and that the development becomes very fragile.
What do we mean with that? An example: First of all, the infrastructure has to set up a server, on which an operating system is installed, followed by a database, that has to be configured. This is filled with data, that is read out and evaluated. We have thus formed a chain. If the first link in this chain cannot keep its promise and is not finished after a sprint, all other elements of the chain are affected, so the dominoes fall one after the other.
If you somehow get the chance, avoid these chains of dependency. So, we come back to decoupling our teams and thus possibly also to the team cut. If we avoid that and say that it is too much of a hassle for us now, the trouble that we have to go through later will be even greater. Believe me: you are better off biting the bullet now and rethinking the team cut (if necessary) than going into dependency hell later.
How to resolve the dependencies between component teams is probably a topic for another post, because it is not that easy. If in doubt, speak to me and we will talk to each other.
Perhaps one or the other of you will now say, that we are creating silos on this path, and you are even right about that. So, we also have to be careful to avoid them.
We assume that we have to be careful with money too. Therefore, we do not have a Chief Product Owner (we will look at what that is another time), we do not have a dedicated Scrum Master for a scaled level. We have a handful of teams, each team has a Product Owner and two teams share a Scrum Master.
Yes, I know, the Scrum Guide wants it differently, but in the real world many teams have to share Scrum Masters.
We will start by speaking at the developer level. Each team sends one or a maximum of two representatives, and we clarify the similarities. First of all, these are technical questions about architecture, development environment, deployment chain, etc., from which we make rules for our entire construct. The participants carry these rules and insights into their own teams. The whole round is moderated by one of the Scrum Masters.
In addition, of course, we also have organizational and process issues such as a joint definition of done or joint exchange rounds and much more. For this we come together with product owners, scrum masters and individual developers so that we can all hear voices.
This is going to be a relatively large round. If we assume six teams, we have 6 x 3 people in it. So, I urgently advise you to prepare proposals. This can be done in smaller groups.
One of the Scrum Masters will moderate again.
Before we actually start, we work out a team approach, responsibilities, and common rules. For the actual work on the project, we should create a joint overarching backlog that the Product Owners fill and prioritize together. Here we are at headline level. The entries here may become epics when given to the teams.
This one scaled level of the Product Owners can certainly operate in a Kanban light mode. So, we have a board and the things that are worked on in a team are in progress. We agree here on which team will take on which feature (so we are at this level). The PO in question takes the feature into his team, breaks it down into individual requirements together with his developers and fills the team backlog.
If we canot manage a clean separation and have to work with two teams on a feature, it is up to these two teams to coordinate with each other. Nobody else has to interfere. Lots of cooks spoil the broth – we know that. Two teams always find a solution to complement each other. It can look like things are handed over at specific times. But it can also look like individual colleagues temporarily support another team in order to contribute the necessary skills. You are completely free to choose your methods. However, be careful not to have too much fluctuation. Our teams are and will remain stable. Borrowing a colleague for a short period of time is okay, but we do not do this all the time. Our goal is still to avoid dependencies between the teams.
After each sprint, we should plan a joint review in addition to the reviews of the teams, which is less for approval than for information, so that everyone knows what has happened in the project.
In addition to the retrospectives in the teams, we also need a form of collective retrospect in which we address topics that affect us all. A simple way to do this is to come together again in a larger group (the Scrum Masters and one from each team after the retros in the individual teams) and consider the things that have arisen in the individual retros, but which affect us all. This round is also moderated by one of the Scrum Masters.
Ultimately, we still have to make sure that we guarantee the professional exchange between the teams. We have an exchange with the product owners by working on the common backlog. In addition, I advise you to introduce a developer group. This is not supposed to be a classic community of practice, even if we can call it that for me. This is about developers talking to each other about all the things that affect them all. That can be architecture topics, that can be mutual training. This is one of our ways to avoid the silos.
Core: If we scale Scrum across several (few) teams, we first make sure that the teams are largely decoupled. Then we work out common rules. A common backlog feeds the backlogs of the individual teams, which can act largely independently of one another.
If you need any assistance or want to know more, just speak to me.
