How To Reinvent the Scrum Process for Modern Distributed Teams
Ranjit Atwal, Senior Research Director at Gartner, believes that “A hybrid workforce is the future of work, with both remote and on-site part of the same solution to optimize the employer’s workforce needs.”
Hey there! This blog is almost about 4100+ words long & not everyone likes to read that much. We understand that.
This is precisely why we made a podcast on the topic. Mitul Makadia, CEO & Founder of Maruti Techlabs, talks to Bikshita Bhattacharyya about his Agile implementation, strategy, and process during the nascent stages of the company.
He walks us through the challenges he faced, how the business benefited from scaling Agile, and how important is the scrum master in making Agile a success at the organizational level. Here is a small snippet from that episode. Check it out!
Gartner forecasts that 51% of all knowledge workers worldwide are expected to work remotely by the end of 2021. Remote working varies considerably depending on the IT adoption, culture, and mix of industries globally.
Scrum is the most reliable methodology for software development that many organizations across the world apply today. However, working with Scrum requires co-located teams for better productivity and communication.
But at the same time, business needs and unforeseen circumstances (rise of COVID-19) have forced the companies to have them distributed globally. Many studies have proved that the distributed workers are highly productive and have higher satisfaction levels.
So the question is, how are distributed agile teams and Scrum compatible? Does agile work with the distributed team, and can Scrum Master work remotely? The answer to this question is a distributed scrum team. So, let’s figure it out! We have presented an ultimate guide to understanding what a distributed scrum team is and how it works.
What is a Distributed Scrum Team?
A distributed scrum team refers to a team where individuals work in the same team on the same project but are located in different locations physically. The distributed scrum team also refers to virtual teams or remote teams, which means that being a distributed team member, you can work from your desired location and collaborate with other team members located at some different location.
For example, you are the head of the marketing team living in London, collaborating with an SMM specialist located in India and a video manager who lives in California.
Note that in the above image, the team members located at the exact location physically, i.e., Team A and Team B, are called co-located teams and not distributed teams.
Generally, remotely distributed teams have constraints on ad hoc collaboration and informal communication. Therefore, they have to be more disciplined about all the agile rules and rituals to find new opportunities to collaborate. Fortunately, most scrum rituals and tools can be adapted to remote environments (including sprints and scrum ceremonies).
A widespread practice called the “Two Pizza Rule” states that two pizzas should feed a team. That means these teams should have up to 7 to 10 members. This rule is recommended for Agile-focused teams; however, it is wise to have smaller teams with 5-6 members for distributed agile methodology.
What is a Scrum Team?
It is a group of people, usually five to nine members, working together to supply the required product increments. Scrum is the ultimate weapon for high-level communication among team members so that they can follow the common goal, follow the same rules, and demonstrate respect to each other.
What are the Challenges for Distributed Teams?
Managing the challenges of a virtual team is not easy. Despite all the benefits, there are many challenges faced by agile distributed teams while working remotely. For example:
- Managing different time zones between the distributed team members
- Building strong connections with everyone who is not in the same office
- Accepting each other among different development cultures
- Arranging meets and get-togethers when both teams are online at the same time for a few hours
The list of challenges is quite long but let us see some common challenges and solutions whenever necessary.
1. Different time zone
Usually, distributed teams have team members located at different time zones. It means scheduling meetings and communicating are pretty tricky for everyone.
Solution: In this situation, you can contact each other via email. Send your questions to your team members and ask them to answer and solutions.
2. Lack of communication
Communicating with your team members across the globe is challenging. This lack of communication is mainly due to different time zones and often causes a delay in work. Without informal hallway chats and impromptu personal meetings, distributed teams need to communicate more at times.
Solution: You can establish the right communication channel that helps everyone get the correct information at the right time. It is essential to provide the guidelines and working of these channels and ensure that everyone understands it for a smooth workflow. Also, you can adapt the video conferencing calls whenever needed at a particular time zone for bridging the communication gap.
3. Adopt the company culture
Adopting the company culture is the biggest hurdle to face by the distributed agile team members. The distributed team members will have different communication styles, contexts, values, and work ethics, which make their culture differ entirely.
Solution: As the distributed scrum team members usually do not follow the company rules and regulations, identifying their activities and behavior is essential to success with the distributed teams. As face-to-face interaction helps them get lined up with the company culture, you can plan a gathering for all the remote team members once every few months.
4. Lacking in building a solid relationship
It is vital to build cordial relationships with your team members and boost the same. But as the communication is less frequent among the team members in the distributed team set-up, the relationship becomes even more complex. Therefore, the lack of solid relationships is one of the most critical challenges of a virtual team.
Solution: The best method to solve this problem is to become more vulnerable, which will help your team members to share their issues with you without any hesitation.
As communication is the heart of any Scrum Framework, special responsibilities should have been taken to beat these scrum challenges while working in a distributed agile environment.
Therefore, all the distributed scrum team members should have access to powerful communication tools like video conferencing, webcam, etc., to break down barriers. You can use fantastic software like Zoom, Slack, Jira, Confluence, and Trello to improve the remote team’s collaboration.
Tips to Manage and Build an Effective Distributed Team
Any distributed team for software development should follow the Scrum principle for clear communication, transparency, and dedication towards continuous improvements of the final results. Some of the distributed teams best practices are:
- Focus on results
- Use the right software
- Study and compare other distributed agile industries
- Follow the structure for daily and weekly meetings
When all these steps are followed, the distributed scrum team can better process the product, and all the operations can run smoothly. Apart from this, the other two essential ways that one has to follow while building and managing the Scrum in software engineering are:
- It would help if you did reality checks of transparency and communication at the proper time.
- Experimenting on different exercises and activities that would be relevant to a distributed agile environment.
Below are the three essential tips for managing the distributed teams in agile:
1. Fix a flexible structure for work
It is difficult to find a proper structure among the chaos when your team is working remotely. Flexibility does involve not only the time of work but also the other operations of the product development. Scrum helps the developers write only the meta-information about the product and fill the blank space with the content suitable for the product.
When we talk about the flexibility of the team members, the following has to be discussed:
- The flow of meetings: The answer for the questions like when meetings will take place, the meeting agenda, and who needs to be present are found.
- Expectations: It is needed when working with a large team, and the developers have to mention what they are achieving and what they expect from one another. It is a group activity where the interactions and transparency between the distributed scrum team are improved.
- Which agile tool to be used: Here, the techniques like writing a DoD, a DoR, team contract, etc., are included.
2. Build trust among distributed agile team
Building transparency between the distributed scrum team members is challenging as the team is divided and lacks trust. Hence, building a foundation for trust becomes crucial for effective collaboration. Trust is the critical factor that needs to be built on both sides, i.e., the technical team with the client or the entire business on the client-side.
Businesses and developers have to collaborate efficiently and effectively to build trust between teams located in different locations. An agile demand management team usually takes responsibility for bringing all the stakeholders on the same page.
3. Reality check in distributed scrum team:
- Does a manager communicate the feedback directly?
- Are sprint retrospectives conducted regularly after every sprint cycle? How does the team react to it?
- Are the impediments taken into consideration by the rest of the team and Scrum Master?
Tips for building trust among scrum team members:
- Agreeing with the suggestions that are in good intentions for the success of the project. The members should take responsibility for their actions and not blame others if a specific product increment fails.
- Setting up the ground rule that everyone has to follow like:
- How to communicate with each other during urgent issues?
- Setting a time window when no one should be disturbed for non-urgent communications.
- Introducing different forms of communication and understanding that suits the best as a team.
4. Building self-regulation and self-reliance
Everyone in the distributed scrum team should take responsibility and ownership of their work as a self-managing team. It requires maturity and taking the leadership of their task and later expanding it to the whole team.
Self-management, self-reliance, and trust are all interconnected qualities among the team members. They are directly proportional to each other, and therefore, if one of the factors increases, the other two automatically increase.
What should you look out for?
- Is the goal being delivered at the end of the distributed agile development?
- How is the team accountable for their work and action?
- Do distributed team members share their responsibilities and help each other to fulfill the common goal?
- Can distributed teams describe their current goal and what tasks they are performing to accomplish them?
- Are the members of the team giving feedback to one another?
- Do people trust each other with responsibilities?
Tips to increase the self-reliance in the team
- Set up the ground rules for the team to collaborate. It becomes easier for everyone to understand their limits and let them know their tasks and expectations.
- Writing down the final goal and the expected task that everyone has to complete. Telling the team members to hold them accountable for their work.
- Find the solution to the problem that arises for the distributed team. Some issues like members attending meetings late often should be handled with care, and the whole team should find a solution together.
Do you wonder what one needs to avoid doing to become a good scrum master? Mitul Makadia does a deep dive on certain limits that every scrum master should take into account while leading his/her team on the path of a successful project. Take a look at the video below👇
Distributed Team Models
There are a total of three different models for distributed teams. Let us discuss them in detail below:
1. Isolated Scrum
In this scrum model, the team members are isolated geographically. Therefore, only the on-site team will follow the Scrum model while the distributed agile team may not. The responsibilities and velocity of the distributed team are significantly less compared with the scrum team responsibilities. Hence, the overall momentum of the group becomes less. Therefore, this scrum model is not recommended for distributed agile teams.
2. Distributed Scrum of Scrum
This Scrum distributed model in agile includes the work partitioned across the cross-functional, isolated scrum team by eliminating the dependencies between the isolated scrum team. Isolated scrum teams are interlinked by Scrum of Scrum agenda where the Scrum Master from the isolated team meets regularly to exchange the updates of their scrum team.
Read Also: What is Scrum of Scrums?
3. Integrated Scrum
The integrated scrum model has fully distributed teams with members of each team located at multiple locations around the world. Because of the distributed nature of this model, the scrum challenges like communication and execution may arise. Still, you can also resolve them by having daily scrum meetings.
The integrated scrum model is a recommended model for experienced scrum teams at multiple locations.
Totally Integrated Scrum
There are three major roles in Scrum – Team, Product Owner, and Scrum Master. In an integrated distributed scrum model, special efforts must be made for all these roles in different locations to work as a single integrated team.
- Team Engagement Model
Even though the distributed team members reside at different locations, they should be managed individually. There shouldn’t be any discrimination between the on-site team members and virtual team members.
Special efforts should be made to ensure that the on-site and the distributed team members get a chance to work on all the technical and functional areas of the project. It will help to retain the knowledge within the team if the team at one location is down.
- Product Owner
It is always wise to have one product owner for the scrum team located at different locations. Some groups have a “proxy” product owner (the one who is representing the role of the product owner in his absence), but at times, a proxy product owner does not have the depth of knowledge as an actual product owner.
Also, it might create confusion, and sometimes, the decisions made by the proxy product owner need to be reversed after the discussion with the actual product owner. The distributed team can have domain experts who can guide the rest of the team members without a product owner, but overall there should be only one authority who can make the final decisions.
In distributed teams, there are fewer overlapping hours between teams at different locations. So the product owner needs to make their time available for the question-answer during the overlapping hours.
- Scrum Master
In the Scrum distributed team model, the scrum master is more challenging and needs to be involved more in the team’s daily activity. As there are more challenges due to the nature of the distributed team, the scrum master has to spare more time to resolve its impacts.
In the distributed team model, the scrum master is located at any one of the locations and should be available with the team at different locations in overlapping hours. In this situation, the scrum master will help other team members with certain types of issues. But most of the time, when the distributed team is not working, he may not be available to help them with their day-to-day problems.
It is good to have a Secondary Scrum Master at the virtual location, to avoid this situation. One of the team members from the distributed team can play the role of Secondary Scrum Master. The secondary scrum master cannot replace the professional scrum master, but he will undoubtedly help the team solve their day-to-day issues.
How Can We Reinvent the Scrum Retrospective Process for the Modern Distributed Team?
One of the primary challenges of the distributed team is that the team members are separated by space and time. Scrum Model assumes everyone is co-located and all communication can happen in real-time. Let us discuss some of these scrum rituals and how we can reinvent them.
1. Get rid of daily meets for regular standup
The regular standup protocol requires the team members to meet daily at the beginning of the day and figure out what they did yesterday and what they will be doing today.
In distributed teams, all team members cannot meet at one time as one part of the team may be at the end of the day while the other will be at the beginning or middle of the day. A benefit of a distributed scrum team is that the work can continue even with the timezone difference rather than the limited typical eight hours work. To take advantage of this, you have to create a facility for distributed agile team members to complete their updates at the end of the day to hand over to those beginning their workday.
In the modern scrum process, the daily standup process is replaced by an asynchronous hand-off ritual at the end of the workday without involving any meetings. The critical task for every member in the distributed team is to report on their work progress and what the next team person needs to do, along with other relevant information.
Tools like Notion and Slack, which involve add-ons like GeekBot, can easily do this task and help you with asynchronous updates. The most significant thing to remember is that you must do the updates in reverse chronological order.
Apart from this, every distributed team member should assign action times whenever necessary to the other team members. A tool like Todoist and Asana works well in this case.
When everyone is physically located at a different place and works as a distributed scrum team, asynchronously updating everyone’s progress helps the team’s product owner and scrum master change their priorities as required and not wait till the next day’s daily standup.
2. Deconstruct sprint planning into sequential steps
The traditional sprint planning is a monolithic event where everyone in the team gets together and reviews every story and then plays story point poker to estimate. More often than not, many team members are experts in certain portions of the project, and other members are not yet expert enough to estimate correctly.
When it comes to the distributed scrum team, you have to think of sprint planning differently. Modern sprint planning can no longer be one event or meeting.
- The scrum master must create a description of each story that can be studied by the team on their own asynchronously.
- Everyone in the scrum team should not have been estimating and playing story point poker. Only those who are knowledgeable enough about the given story should estimate it.
- The sprint planning task and other estimations can be spread flexibly over a few days, even if completed during the previous sprint.
- The estimates gathered are then published and consumed asynchronously. The estimated owners incorporate updates based on the feedback by the rest of the team.
- Finally, the sprint backlog is created by the scrum master using all the above data.
3. Dodging delays from dependencies by having a backup backlog
In a distributed team, dependencies can kill productivity and also cause delays in the final output. Sprint planning needs to plan the dependencies among the stories in the sprint backlog so that the team members can sequence their work in the correct order.
When you are working on a story, there are times when you get stuck in the middle and need someone to unblock you. The traditional scrum rituals assume you can just walk and talk to anyone. But now, the person you need to speak with to get their performance measurement must be part of how to unblock from your work is remotely located on the other side of the world. It is not a good idea to start with a new story and leave the unfinished one unsolved.
To avoid the loss of productivity, the team should create a new secondary sprint backlog of tasks that can come into the picture when anyone is stuck. Remember that the secondary backlog never consists of the actual stories. It contains tasks like technical debt, unit testing, bug fixing, documentation, performance audit, etc. Also, the backup backlog must only have tasks that can take anywhere from a few minutes to a maximum of 4 hours.
4. Making the sprint backlog dynamic
When working with the traditional scrum process, the sprint backlog doesn’t change during the sprint. But practically, the distributed team is constantly dealing with the changing business circumstances and the challenges among the team. The modern team has to be more flexible in comparison to the traditional scrum team.
The product owner and the scrum master must continuously refine the product and sprint backlog during the sprint. The team needs to constantly estimate or re-estimate stories to adapt to the changes in the circumstances.
But in this case, if your sprint backlog is dynamic and can accept the changes right away, it can reduce all the scrum challenges easily and quickly. Client change launch dates, suggested changes in UI or functionality, unexpected technical problems, Covid hits, etc., are easily tackled when scrum master can dynamically manage the sprint backlog.
5. Improving self-sustainability at the individual level
The traditional responsibility of the product owner and the scrum master involves adopting the new model. In a conventional scrum team, the scrum master is like a hub. But in a distributed team, the scrum master is not available for a large portion of the working hours for the distributed agile system. For this situation, there are two solutions:
a] Team members must be self-organized and self-sustainable to solve the problems on their own when the scrum master is not available to help with their impediments. However, the result of this depends on the maturity of the team.
b] A scrum master can be identified for a specific time zone in a large enough distributed scrum team. The scrum master must synchronize their work just like any other team member would.
The distributed team member must learn to depend less on the product owner and scrum master for their day-to-day operations.
6. Evaluating scrum teams
Traditional scrum models analyze the performance of the scrum teams depending on the velocity and burndown. But with a distributed scrum team, the team’s performance is not just measured on the number of stories and completion of story points.
How well your team collaborates and communicates with each other is the success factor for distributed agile. As discussed earlier, dynamic sprint backlog and secondary backlog require changes in how velocity is measured and burndown charts are initiated. The performance measurement must be part of how distributed team members manage their productivity, problem-solving ability, and adaptability to changing circumstances.
Did you find the video snippet on How to balance team efficiency with individual learnings in an agile environment? to be insightful? We have a ~22 min video where Mitul Makadia gets into the weeds, and we discuss about Implementing & Scaling Agile to streamline Software Development. Take a look –
Conclusion
The new era of distributed scrum teams requires us to rethink and upgrade the decades-old scrum process. It is necessary to reinvent every step of the traditional scrum process to be asynchronous and hence deconstructed. Each distributed team member must learn to work together across the time zones and manage their work dependencies with other team members who are not easily reachable.
They must be able to adapt to the changing circumstance every day by being flexible with their work. Enabling the agile team with the right tools can go a long way in making asynchronous communication much easier and effective.
Even though only a single team member is working remotely, the team should adopt the distributed scrum methodology to share work between different locations, communicate effectively, and achieve the organization’s common goal.
With the growth of distributed teams and workplaces, it is important to have a clear and concise scrum guide for distributed agile, processes, and different scrum frameworks. You can choose different scaled agile frameworks like Scrum, SAFe or LeSS, whichever works best for your business.
Apart from the above, the product manager and scrum masters also need to change how they hire and evaluate the team members. In the distributed scrum team, looking for collaboration and communication skills results in a better performing team and satisfying results at the end of the day.
We understand how important it is to work in modern methodologies where requirements and technology evolve rapidly. At Maruti Techlabs, we follow Agile, Lean, and DevOps best practices to create a superior prototype through effective collaboration and rapid execution.
Building future-proof software is key to the success of your business. We work with you to develop solutions that provide your company’s customers with a seamless experience by ensuring a customized fit.
Whether you are a start-up or an enterprise, get in touch with us for a free consultation and see how you can benefit from our product development services.
