Today I am frequently working with larger organisations and continually have to deal with people in different locations across the country or globe. This kind of context brings its own challenges and many people hope to find solutions in tooling and so did I, but hey, did I think wrong!
Before going into running multi-site events, a bit of context on team setup and the need for multi-site events.
Create Single-Site Teams
As I am talking about larger organisations I experienced that there are always enough people on a single site to create single-site teams so that we can have high bandwidth communications within the teams on a daily basis. I do not see any need to break down daily collaboration across sites when having a great CI system and culture in place. Hey, at Google there are 5000+ people across the globe developing on trunk so why wouldn’t it work for you?
The one thing people will need to do is acquire new skills so they can be, or become, a true feature team. Some skills will be mandatory to be acquired before creating the new team structures, others can be learned on the job after the redesign of teams.
Great learning practices:
- 4 levels of skill matrix
- Mob and pair working (not only programming)
- LeSS Multi-Team Scrum Meetings (Refinement, Planning, Review…)
- LeSS practice of Travellers
- LeSS practice of Guardians
- Communities
- …
Multi-team Events are Essential
I do consider multi-team Scrum as essential for this to work as I do not have the illusion to ever have all special skills/expertise duplicated over each team and site. It means that we need to enable the teams to help and learn from each other on a continuous basis, without adding too much complexity or costs or burden on them. The general Scrum events are perfect for that purpose:
- Refinement: sharing insights on product level, architectural level as well as enabling experts to keep an eye things go well and educate others in their domain.
- Planning: multi-team planning part 1 will allow people to discover dependencies between the activities of different teams and enable them to coordinate around them with a purpose to eliminate in the future.
- Review: share progress and learnings on product level so that upcoming work is aligned and focus is kept on the most impactful activities to do.
I would recommend you to attend a LeSS Course if you are not familiar with multi-team Scrum systems. It is not the purpose of this article to get into the basics of these events but to share information on running these events across multiple sites.
Now we know the why and the context, but how do we do multi-team events with teams at different locations without tooling?!
Multi-Site Event Issues
I have tried many cloud based software solutions to enable teams to work across sites and I am confident to say I became a remote facilitation expert. While becoming tool expert as well as remote facilitation expert I learned that using software solutions will
- require a lot more preparation from the facilitator to make it work
- require time from attendees to get familiar with the tool at hand
- slow down the speed and quality of the conversation
- generally need more time for the same outcomes compared to face-to-face
I do collaborate on collecting software solutions that can help, taking into consideration the above consequences. I still design and facilitate a lot of remote workshops and events with the support of software solutions but here I wanted to highlight that you can choose to do things with less tools. At the same time give you some pointers on how to facilitate your general Scrum events.
Basic Needs
With or without software solutions, one basic need that will always be there is very, I mean very very, good and stable internet connection. Transfer of information across sites is in any case a crucial element for CI systems and culture and can not be neglected!
As for any collaboration across borders you want to have a minimum of 5h time overlap between the different locations or collaboration becomes truly ineffective and will lead to a shitload of rework and defects.
Large, movable screen and excellent video conferencing equipment. I prefer video conferencing equipment the remote team can operate to zoom in/out, turn left/right and so on.
Next to the above, you only need the stuff you would also use for face-to-face conversations, whiteboards, whiteboard markers, post-its…
Multi-Site Refinement
In order to keep product level knowledge well spread across all sites, it is crucial to allow team members from different teams to work with each other during refinement sessions. Having teams spread across sites means that some of the refinement actions will be done across sites.
Below you’ll see a very short video of people having a remote refinement session as if it was face-to-face. Let me first highlight some pointers:
- A Movable screen is placed as an extra member in the circle of conversation and not at the front or back or behind people. This changes behavior completely versus a fixed screen on the wall somewhere in the room.
- The Location taking the lead is the one with the most participants of the refinement so that there are heads & hands enough to capture all information given, also from the remote attendees. Doing it the other way around may lead to information loss, as a minority needs to capture the thoughts of a majority.
- Remote people use the video conferencing equipment to zoom in and out from the whiteboard and instruct locals what to change, add, remove and so on. Sharing ideas and designs.
As you can see and feel, this is remote and yet very close to face-to-face communication. I have experienced this as being very effective and with high energy on both locations. People attending these sessions considered the outcomes of these sessions of higher quality than using the tools (which we did before this experiment). Mission achieved!
Multi-Site Planning
Planning is a bit trickier than refinement as there are a lot of refined product backlog items already there to start from. So how do you spread those across locations?
We first made sure top items were printed and ready to be used on all locations involved. After crafting a sprint goal, the site with the least amount of teams started with selecting their items, sharing their selection to the others so that those items are removed from their stack of choice. The last location is the one with the most teams or if outsourcing politics are in play, you might want to consider the HQ going last. You would be surprised what this sequencing does to the general cross site culture of people involved.
Once the items are distributed, all sites have an overview of what is being taken up and where. Teams discuss possible dependencies and move items around as much as they can to keep dependencies in one location.
Crafting sprint goal:
Last location choosing items while having other locations selection on screen:
Discussing dependencies and moving items around when needed:
Final clarification before going into sprint planning part 2 – detailed design:
After this first part teams go into separate rooms for sprint planning part 2 – the low level design and implementation details of the items to complete. If multi-site efforts are still needed they work the same ways as in refinement sessions, see above.
Multi-Site Review
I do like bazaar style review sessions where people wander around and visit the setups they are interested in while providing feedback to one or multiple team members attending the setup. Facilitating a bazaar style review with people on different sites, even with HW involved kan be done with the same materials as above.
You start centrally where everybody joins a video conferencing meeting from their own workstations and where people man the review setups they form small groups that join. Once the opening ceremony is done people go in and out separate video conferencing sessions for each review setup and take over the screen/input or instruct the locals what to do while providing valuable feedback. Of course people go physically to setups that are at their own site and it is best to ask them to do this after the remote sessions so that the chance that remote is mixed with face-to-face is limited and energy is kept high.
Conclusion
Avoid too many different software solutions and keep things simple while simulating a normal face-to-face conversation as much as you can. Getting to familiar to effectively work with one video conferencing tool is already hard enough for some, so don’t add more tooling would be my recommendation.