I’ve spent a significant portion of my career working in companies that are at least partially remote/distributed. One of them was globally distributed, with no central headquarters at all. Everyone worked from their homes. When I founded VividCortex, I wanted to blend the best of both worlds, and to my credit, some of what I did has been an improvement. There are still downsides, though, and in this post, I want to explore how distributed teams can address a basic human need: seeing each other in-person.
I have a lot more thoughts about many aspects of remote/distributed work and the culture that develops with them, which I hope I can share in other blog posts someday when I get time. If you’re curious about whether I think remote/distributed teams have advantages, and whether being in an office has advantages, and whether the first or the second one is better, and whether people with clear and universal answers are wrong, the answers are "Yes, yes, yes, and yes." Beyond that, I will not go in this post, because I want to focus on the topic.
I am sitting in my office building, working with my team. My all team members are co-located and working towards the deliverable. My manager is the person who is collating the requirements from the client. The details are then shared with team and all blindly start working towards that deliverable.
This was the peculiar nature of teams working in the offshore centers and working towards the project goal. Most of the team members are not even sure about the project’s final goal and are just concentrated on the module assigned to them.
Now let’s switch and jump to today’s world of “global co-worker.” Teams sitting in Bangalore (India) are working with teams placed in San Jose (US). These teams are connecting on a daily basis, avoiding any rework, any confusion and hitting hard the product release to market. Welcome to the world of distributed teams. With Agile as a preferred way of executing projects and teams seated at different geographies, the concept of distributed Agile has gained a good pace. Now we are not bothered about where the team is, all we are worried about is information reaching the team on time using several tools available at disposal along with conflicts and dependencies getting resolved on time. Let’s talk about what are the ways by which we can scale the Agile and can easily execute multiple teams not co-located. In this post, I will be talking about the concept of Scrum of Scrums and how it can help us.
Anytime we develop a group of Scrum team members to work towards a common goal it is necessary to follow the Group Development Process.. In distributed models, the first and foremost thing which a coach needs to sort is – how the grooming will happen for teams? We cannot have a dedicated product owner (PO) for each team as we can scale the projects to any level. So the concept of proxy product owner is very popular in today’s project execution model. We can have either PO directly talking to few teams and for some we can have proxy PO reaching out to teams after coordinating requirements with PO.
With this model, teams can connect with either the PO or proxy PO for all queries related to the feature. But still, we have one more challenge: how the teams which are not located in the same building or in same country and working in different time zones can coordinate and work on inter-team dependencies. Well for this, we have to come up for a time frame which suits all teams in all geographies and have a meeting called Scrum of Scrums. In this meeting, the Scrum Master will represent the teams and will talk about following points:
In case the Scrum Master is not available for a meeting, any senior team member can represent the team on his/her behalf.
The above picture depicts how the teams are placed at located at different locations and how all teams are working together towards common product and coordinating using Scrum of Scrums. It is very important that this meeting should be attended by all teams’ Scrum Master.