How to Make Agile Work with Distributed Team

How to Make Agile Work with Distributed Team

Can Scrum work when team members work remotely? Read on to learn how to adopt Scrum for agile remote teams!

Challenges

Quite often during Scrum Training students ask whether offshore, remote, or distributed team models work with Scrum. Ideally, Scrum teams should be in one location. It could work for distributed teams, but it is really similar to long distance relationships. I have witnessed successful cases, but it requires all the involved parties to do things differently.

Trust

The first issue with distributed teams, similar to long distance relationships, is trust. Just as if your life partner were not in the same city as you, you would wonder whether he or she is dating someone else. We have similar issues with Scrum. When someone is not at the same office, we have no idea whether they are actually working or not

Building Trust

So the first thing you have to accept is that there is a lack of trust and then try to build it. This can be accomplished through team building activities or joint training. For example, I just helped a client and their vendor to kick-start a challenging project. To build team trust, we included the client, their business unit, internal IT, and the vendor in our Professional Scrum Foundations (scrum.org/PSF) training. With entire team together for the training, they were able to build something together and experience the same challenges. Activities like these can help build a one-team mindset.

Part-time Co-location

Another solution is having the entire team co-locate for the first few Sprints and then breakout to different regions. Alternatively, you can use an alternating travel schedule where some team members go to the other site to work together for 1 or 2 Sprint or even a few days just to build trust and experience any challenges the other team may be facing.

One-team Mindset

Training or co-location exercises are mainly used to help the teams build up a one-team mindset. Even though they are from different locations, different cultures, or different vendors, they are all a part of the Big Product Team.

Transparency - Product Backlog

Again, for a remote distributed team, it is difficult to be transparent about the Product Backlog. Post-it notes are not the best options, so you most likely need to use a tool like Jira, Rally, Visual Studio Team Services Pivotal Tracker, or others. The major purpose is to let the tools to help you keep the transparency high and not spend more time on the tools themselves.

As an example, I know of one case where a team changed the language of their Product Backlog Items from English to Chinese to make sure the remote team clearly understood the requirements.

Transparency - Sprint Backlog

For remote teams, it can be difficult for all members to see the progress. To fix this, you need to have a Group Daily with 1 to a few representatives from all the teams discussing upcoming dependencies and asking for any help they need from other teams. In addition, each team should have their own Group Daily according to their timezone. This is similar to the Nexus Daily Scrum.

Scout

If you have some scouts on your team, have them join in other team’s Daily Scrum from time to time to see how they are doing and find out if they need any help.

Definition of Done

For remote and distributed teams, the Transparency of Increment becomes more critical than ever. The team needs to have an agreed upon definition of quality or else there will be a lot of arguments and fights. Good engineering practice is extremely important, and it is a must to do Continuous Integration (CI) as well as Automatic Unit Testing, Integration Testing, Trunk-based Development, Continuous Delivery, Continuous Deployment (CD), and other software engineering/DevOps best practices.

Team Communication

Interaction and communication become challenging in remote working situations, so we want to use as much technology as possible to help bridge the gap.

• Use instant messaging tools like Slack, Telegram, and Microsoft Team that support API Integration with other tools

• Integrate your Scrum tools with instant messaging tools so everyone will be notified immediately if there are any changes to the Product Backlog or Sprint Backlog so team members can pick up or finish specific tasks or Product Backlog Items

• Integrate your whole Development Pipeline with instant messaging tools so the whole team can know the latest status of build / CI / CD and be notified if someone checks in any code to any branch, if someone adds any tests, or if any changes break the automatic testing

• In what we call ChatOps, encourage the Development Team to communicate as often as possible with the support of tools; talk more in Jenkins rather than in Jira

• It’s helpful if the team can agree on some ground rules for communication, like replying in the thread, tagging someone if you need action from someone, etc.  

• Even if there’s no automation, you can communicate to the other side when the Sprint Backlog or Product Backlog is updated by doing something as simple as sending a screenshot

• Use video chat more often to improve the communication, which lets you observe the body language and facial expressions of the other side to understand their emotions and mood

• Use more collaborative tools for communication and documentation like Google Doc or a wiki tool like Confluence

• Make use of screen sharing feature

• Visualize your thoughts by using a real-time board, diagram, or flowchart

• Keep meetings short

• Be mindful of the language barrier; some team members might have an easier time communicating through writing than through speaking

Sprint Event - Inspect and Adapt

During the events, it may be necessary to make use of the latest technology like video conferencing and instant messaging to make the process less painful. Also, consider the time zone difference to make sure it is not too stressful for any party. Try out something new every single Sprint. if it works, keep doing it; if not, the Scrum Team can brainstorm something else and do things differently.

Consider adopting a Nexus Sprint Retrospective format where all the teams have a joint Retrospective to discuss issues impacting multiple teams, like cross-team communication. Each team will have a breakout session to discuss areas for actionable improvement. The teams can then have a quick get-together to communicate to each other what they would do differently next Sprint.  

Conclusion

Distributed Teams for Scrum can work. I have seen it in action, but it usually requires preparation like on-site training, good use of tools, and frequent video conferencing. Most importantly, you must remember the people aspect of the work. Try to build trust first, understand each other, respect the differences, and come up with ways of working together that are as least painful and most productive and creative as possible.