The Scrum Guide almost only talks about collaboration within a single team. If we plan on scaling Scrum over multiple teams, we soon stumble across some things like SAFe or LeSS. Those are scaled systems, which can be very complex and complicated. What is a reasonable way of doing things, if we just want to talk about something like three teams and not the complete company?
Let us assume, that our resources are extremely limited. This situation will probably sound somewhat familiar to many of us. Therefore, we have to find ways to ensure, that multiple teams work together smoothly, with little to no effort.
Basically we have two possible situations: Either all teams work together on a project, which is of course a bit more complex, or the teams work separately on different projects, which is much less work for us to do, but should not mean that there is nothing to do.
Today we will only talk about the simple case and leave the other one – the more complex one – for the next time.
I do not want to play Bullshit-Bingo and talk about »synergies« in epic lengths (the terminology in itself is utterly ruined), but we should think about, how two or three teams can profit from each other, can avoid double work, or which rules do make sense for all of us.
We do not need anything else than a single regularly point of communication, which we might call a »community of practice« although we stray away from current definitions of a CoP.
One hour once in a sprint will most likely do the job. It could be a bit more, if we are just starting, because there might be bit more reason o talk and adapt, but if things are settled you should be fine with an hour in two weeks or something like that.
Make it a rule. Do not start with something like: we will meet and talk, if there is a reason to, because we do not want to have too many meetings. If you think that, you will not meet often enough, and things will get lost. Trust me.
We want to find out, which team is working on which topics – currently and in the near future, because we want to find spots, where we can help each other. That could sound like this:
Team 1 says, that it will be working on functionality A in the near future. Team 2 replies, that they have done something similar in the past and offers, that Team 1 may recycle their work. Developers from each team will sit down later in a small group, view the sources, and one will explain the details to the other.
You could even go further by having one developer of one team helping the other team for one sprint, meaning switching teams temporarily. That is not a big problem for an experienced team. Yes, we want to keep our teams stable, but trust me: switching teams for a single sprint, to help each other will do us no harm, if our teams are properly set.
On the one hand, we use our work twice and avoid double work, on the other hand, we create a knowledge transfer across team boundaries. This helps us avoiding silos.
And you could even go further than that by thinking about combined repositories and something like that, but for the first step we want to keep it as simple as possible.
The second aspect, we want to talk about are common rules. Here, too, we adhere to the principle that less is more. We ask where common rules or standards make sense, but at the same time we also ask what the consequences would be if we do not have them. This should save us from setting up too many rules that hinder rather than benefit us.
We let the teams decide and do not restrict them thematically. We can talk about coding guidelines as well as about series of appointments, that you might want to coordinate with one another. We also allow the scaled level or management to have a say in regulations, because another aspect can be brought into the considerations from a different point of view (e.g. a commercial one), but we ensure that we come to joint decisions and that we are not having a supervisor or superior deciding too much. In that case, we would not need any voting rounds, we would be back to a classic management-superior structure.
Of course I advise you to let those communities of practice (although they are not CoPs, but we call them CoPs anyway) not go unmanaged and without proper moderation. Without anyone helping a bunch of developers sort themselves out, things will get complicated pretty soon.
Another thing, we have to consider, are our ways of communication. If we are in our offices, sometimes that is not a problem, because we are close. But today, when most of us are working from home, things get difficult.
Why is that so important?
Sometimes you just want to talk about the small stuff. You might have just a single question for a specific colleague. It would be just stupid t wait for our next round, because that might be a week or more. Furthermore it is just a single question I am interested in. It is not a topic relevant t everyone. Picking up a telephone is a big step for some of us, mails are not always the best ways to do things. So, what should we do?
We do not want us to annoy each other all the time, but on the other hand we want to have short lines of communication so that you can quickly ask a question.
Group chats are rather difficult. If there is too much going on, it annoys everyone and you turn them off. If nothing is going on, you switch them off because nothing is going on. On the other hand, the option of MS Teams or Skype to write briefly to individual people is often used and a viable option. If we do not have such systems available, Rocket Chat can be used to think of something similar.
Please do not underestimate this aspect of easy communication. This is especially important now, when so many people are working from home. I can see everywhere, that we are currently talking too little. In the teams themselves, too, we often do not talk to each other enough. If we only see each other once a day (and sometimes not even every day) 15 minutes in the morning in the Daily, and then try to tick off all the topics, at some point we will find, that we have gaps. It is precisely then, that we need a substitute for the short meetings at the coffee pot or in the smoking area.
You do not have to do much more if you have largely independent teams. Everything you need here is easy to set up, the administrative effort is limited, but we have nevertheless created a way to benefit from each other and avoid silos.
Core: If we scale Scrum across several (few) teams, but they do not work on joint projects, we should still ensure regular exchange in order to promote both common rules and possible mutual support.
If you need any assistance or want to know more, just speak to me.
