Reinventing Scrum for the Distributed Remote Team
by Gowri Sivaprasad, VP of Engineering and India Country Head, YML
February 22, 2021
The standard scrum process created many decades ago was designed for a team that sits next to each other. This assumption underlies many of the rituals and terminologies used in the scrum process. For example, the term “daily standup meeting” presupposes that the team can just stand up and meet. As companies became global, teams became distributed across locations, countries and timezones.
Since Covid, many teams have also become fully remote, with everyone working from home. Distributed remote teams are still using the same scrum process that was never meant for the conditions and constraints they face today, especially when work and personal life are getting blended throughout the day.
At YML, our teams face the same challenges. When we all started working from home, and our teams became even more dispersed, the teams following the traditional scrum process (and everyone involved) experienced pain points.
We asked ourselves: How can we reinvent the scrum process for the modern distributed remote team?
The primary challenge is that the team members are separated by space and time. Scrum process assumes everyone is colocated and all communication can happen in real time.
The solution themes offered in this article are about:
- making everything as asynchronous as possible
- deconstructing monolithic events
- creating new types of artifacts
- shifting from self-organized teams to self-organized individuals
Let us examine some of the common scrum rituals and how we can reinvent them.
The team structure assumed in this article has members in various locations in the US and in India, separated by anywhere from 9 to 12 hours of time difference; all team members are remote and working from home with flexible schedules. It could also be assumed that the global project consists of multiple smaller scrum teams working towards a single objective.
At YML, many of our teams are spread in the same way and face the same challenges detailed in this article. We implement many of these solutions in our teams.
Eliminate meetings to create an asynchronous daily standup
The regular standup protocol requires everyone on the team meet in person — at the beginning of the day — and list what they did yesterday, what they will do today and any impediments. In our distributed remote team, the entire team cannot meet at one time without it being the end of the day for one set of people and beginning or middle of the day for others. An advantage of a distributed scrum team is that work can continue through the timezones rather than limited to a typical eight hour work day. But to take advantage of this, we need to better facilitate those team members completing their work day to be able to hand updates over to those beginning their work day.
In the new scrum process, the daily standup ritual is replaced by an asynchronous hand-off ritual at the end of everyone’s work day (or at designated time slots if there are too many timezones involved), without any meetings involved. The distributed team should work like a relay race team where the baton is handed off for the next person to continue the race. The key task of every team member is to report on what they completed or progressed, what the next person needs to do during their day, and any other relevant information. Tools where we can easily share pages or updates, like Notion or a dedicated Slack channel, work best. Many YML team do this. There are also Slack add-ons like GeekBot that help with asynchronous updates. The updates must always be made in a reverse chronological order. In addition, every team member must be able to assign action items or to-do list items to others in the team. A tool like Todoist or Asana will work well. The team must also have an easy-to-use tool where the prioritized sprint backlog and stories are available.
A team member beginning their day must first review the updates from others and any action items assigned to them. They will derive their work items based on these two inputs and the sprint backlog. At the end of their day, they will update on their progress and action items.
When everyone is remote and work timings are not uniform, team members updating their progress asynchronously helps the scrum masters and managers of the team better risk manage and dynamically change the priorities as required, rather than wait till the next day’s daily stand up.
Other sprint rituals like Sprint Review and Retro must also be run asynchronously in a similar fashion.
Deconstruct the monolithic sprint planning into a sequence of steps
The typical sprint planning process is a monolithic event where everyone in the team sits together to review every epic and story, and then play story point poker to estimate. Beyond the usual assumption of a co-located team, this also presupposes that everyone in the team knows all the stories and everyone can estimate all of them. This is rarely true in the real world. More often than not, team members specialize in certain portions of the project and there are new team members who are not yet experienced enough to estimate correctly.
In the distributed remote world, we need to think of sprint planning differently. The new sprint planning can no longer be one event or one meeting.
- First, the product owner must create detailed descriptions of each epic and story that can be studied by the team on their own, asynchronously.
- Second, we shouldn’t have everyone in the team estimating and playing storypoint poker. Only those who are most knowledgeable about the given epic/story should estimate. Whoever is estimating must factor in the diversity of skills in the team. If a smaller group or a subset of the team needs to discuss as part of the estimations, it is much easier and faster than the entire global team trying to find a time slot that they will meet for a few hours. This is something we implement in multiple YML teams, where individuals or a small group own the estimates for each epic.
- Third, the estimations and other sprint planning tasks (like capacity mapping) can be spread flexibly over a few days, even done or completed during the previous sprint.
- Fourth, the estimates are then published and consumed asynchronously. Any updates based on reviews by the rest of team are incorporated by the estimate owners.
- Finally, a sprint backlog is created by the scrum master using all this data.
Avoid delays from dependencies with a secondary backlog
In a distributed remote team, dependencies can kill productivity and cause delays. Sprint planning needs to forecast and plan for all dependencies among the stories in the sprint backlog, so that the team can sequence the work in the right order. The sprint backlog thus becomes more like a directed graph than a list.
When you are working on a story, quite often you can get stuck in the middle and need help or someone to unblock you. The traditional scrum process assumes you can just walk over and talk to someone. But now the person(s) you need to talk to get unblocked are remote and perhaps in calls or in the other side of the world. So you may have to wait potentially for hours or even days. It is not always a good idea to start on a brand new story at that point — lest they get left unfinished when the dependency is resolved.
To not lose productivity, the team should create a new secondary sprint backlog of tasks that can be dipped into when anyone is stuck.
The secondary backlog never contains actual stories. It contains tasks like bugfixes, technical debt, unit testing, documentation, estimating future sprint stories, performance audit and so on. Also, the secondary backlog must only contain tasks that take anywhere from a few minutes to a maximum of 4 hours.
If you get stuck and need to wait, you pick up tasks from this secondary backlog. The main goal for the secondary backlog is to fill Waiting Time to ensure everyone has a handy list of useful things to do when you have a few minutes to a few hours on your hands. Explicitly creating and updating this backlog will allow the team to complete many tasks that usually don’t get enough attention.
The secondary sprint backlog is a new artifact that must be planned, produced as part of the sprint planning process, and tracked in a tool as output of the sprint.
Make Sprint Backlogs Dynamic
In the traditional scrum process, the Sprint backlog doesn’t change during the sprint. But in reality, distributed remote teams are dealing with changing business circumstances or unforseen challenges within the team. The modern team has to be more flexible. During the sprint, the product owner needs to continually refine the product and sprint backlog, and the team needs to continually estimate or re-estimate stories to adapt to the changing circumstances.
At YML, we often see teams facing changed circumstances during the sprint. Clients change launch dates, priorities change, clients review a build and want to change some UI or functionality, Covid hits, team members have extended network outage all day, unexpected technical problems crop up when merging code, new phones get launched that we need to test right away. We have seen all these and many more.
Many of our teams change the sprint backlog during the sprint. A mini-sprint planning exercise is done and a new backlog is derived. We also ensure that the Product and Engineering teams are always in sync and can react to changes fast.
Improve self-organization at the individual level
The traditional roles of scrum master and product owner must also adapt in the new model. In the traditional scrum team, the scrum master is like a hub. But in the modern team, the scrum master is not available for a large portion of the working time of a distributed remote team. There are two possible solutions.
- First, the team members must become more self-organized and solve problems on their own when the scrum master is not around to help remove their impediments. This depends on the maturity of the team.
- Second, in large enough distributed scrum teams, a scrum master can be identified for each major time zone. The scrum masters must synchronize their work just like any other team member would.
YML teams have implemented both solutions in different teams.
The distributed remote team must learn to depend less on the scrum master for day-to-day operations. Tools that allow the team to better hand off information and communicate, that allow the team to independently make decisions, track action items, dependencies and raise risks are required to help orchestrate the daily scrum operations.
Sprint Retro is traditionally run once at the end of the sprint. In the new model, as part of their daily hand off updates, the team member can (and should) also add any feedback or learnings on what is working well and not working well. This data can be used by the scrum master every day to enable changes that will help the team. It is equivalent to running a retro every day of the sprint. Learning and adapting every day is a key expectation from any distributed remote team.
Evaluate Scrum Teams for more than just Velocity
Traditional scrum model evaluates performance of scrum teams on velocity and burndown. With a distributed remote team, the team’s performance cannot just be measured on the number and rate of stories or storypoints completed. How well the team collaborated and communicated is a critical success factor. Dynamic sprint backlogs and secondary backlogs require changes in the way velocity is measured and how burndown charts are created. How well the team member was able to self-manage, problem solve and be adaptable to changing circumstances must be part of how their performance is measured.
Summary
The new world of remote distributed teams requires us to rethink the decades old scrum process. We need to reinvent every step of the process to be asynchronous and hence deconstructed. Each member of the team must learn to better hand-off work across timezones, and manage dependencies when dealing with other members who will not be easily reachable. They must remain flexible and adapt to changing circumstances every day. Enabling the team with the right tools will go a long way in making asynchronous communication easier.
Team managers and HR also need to change the way they hire and evaluate scrum team members. In a distributed remote team, looking for and coaching for collaboration and communication skills will yield a better performing team, and a happier team at the end of the day.
About the author: Gowri Sivaprasad
Gowri is a technology professional with more than 27 years of experience building software products. He is truly multi-cultural, having spent equal parts of his career in the US and India. He has strong experience in building and scaling engineering teams in both countries and shipping world-class products.
At YML, Gowri is the Engineering leader and also heads our strong team in Bangalore, India. Prior to YML, he worked at companies like Rsam, Amber Road, Oracle and Sun Microsystems where he led global R&D organizations and scaled teams from zero to 500. He brings his experience working with global customers, combined with a strong blend of software and business leadership, to build high impact digital experiences for YML’s clients.
Gowri is a geek-at-heart, and passionate about bringing to life world-class engineering practices to build great software. He is a stickler for elegant software designs and loves digging into code. He lives in Bangalore with his wife and two children. In his spare time, he is a classical pianist and an avid reader of business books and biographies.
