Resolving challenges in a distributed Scrum model

Co-location has its perks. Everybody knows what everyone else is doing, sprints and demos are easier. So are the retros. Communication happens effortlessly, and everything is easy to manage, for both the product owner and the development team.

But we have already established why distributed scrum teams are essential for enterprises. So you cannot play safe and insist on co-location anymore. Enterprises have to take the plunge into working with distributed scrum teams. And yes, it’s fraught with challenges. But there are also ways to resolve those challenges and ensure success of these distributed teams.

We take a look at the various challenges, and how to get past them:

Information Exchange: When the product owner and the development team are co-located, the exchange of information is very smooth, and not always formal. A lot of information is passed on in an informal manner, in chats or general conversation. These could be termed as Coffee Machine Thoughts, and are not always documented.

Now with a product team working out of a remote location, this exchange of information goes completely missing. Not everything gets discussed on the conference call, and offshore teams might miss out on minor, but critical, information.

How to Solve It: The first step is to acknowledge that there’s an offshore team working towards the same goals. All the dev teams, onshore and offshore, and the PO have to be brought onto a single communication platform (Slack works great at ). The PO should also take care to share all pieces of information, like user survey, feedback, etc, with the teams, on this inclusive communication platform.

Visibility: With offshore teams, visibility of work is an issue. While a co-located team can catch up with each other on the state of work (though that’s not really an optimal way), it’s not possible for offshore teams. Time zone difference can also crop up, when the offshore team and the PO cannot find a suitable time for a demo.

How to Solve It: Recorded videos are a great way to solve the demo problem. A complete screencast of demos can be shared between the PO and the teams. This means everyone can check out the demo, even if it’s not in real time. Also, videos are a great way to avoid unnecessary documentation. All information, like technical diagrams, images, demos can be captured in a video, instead of trying to explain it in a 100 page technical document. There are also project management tools like JIRA that are suited to the scrum way of working, and can be used to ensure collaboration and visibility.

Managing time zones are one of the most critical balancing acts to get right, when working with offshore teams. The benefit here is that there is round the clock work on the project, with one team starting work even as another team is wrapping up for the day. But there are certain obvious problems here:

Depending on the time difference between the remote teams, it might be difficult to come together for con-calls and demos
With the PO and dev team in separate locations, it might be difficult to clarify certain points as and when they arise

How to Solve It: Here are a few things you can do to resolve the time zone issue:

• Appoint a proxy PO in the offshore team, who works closely with the onsite PO, and understands both the business and tech aspects of the project. Any adhoc issues for the offshore team can be then handled by the proxy PO.
• It is also advisable for both teams to build their schedules in a manner that ensures a few overlapping hours of work. This makes it easy and discuss sprint objectives and catch up on progress and problems at both ends.

Collaborating, especially on a tech project, can be difficult if onshore and offshore teams do not share a similar infrastructure. There are times when a piece of tech, or software is working great at one end, but the other team is unable to view/use it. The onsite team might be working on high-end systems, good internet bandwidth, and a closer source code repository. On the other hand, the offshore team might be working in the exact opposite conditions.

And this is will lead to greater challenges in the future.

How to Solve It: The only way is to make sure that both onshore and offshore teams are working in similar development environments. The obvious thing is for the team with lower quality infrastructure to upgrade to a better setup.

Difference in Skill Set: Offshore teams, especially those in Asian or Eastern European countries are comprised of young people. So someone with 5 years of experience could be collaborating with someone on the onsite team with 20 years of experience. So there is obviously a skill gap that you will run into.

How to Solve It: Firstly, a common coding guideline should be agreed upon by both teams. There should also be some initial training and coaching when the offshore team is being on-boarded on the project. Regular peer code reviews are also a great way to ensure quality and pull up the skill sets of the offshore team. Even if the roles are reversed, the issue of skill gap can always be resolved in this manner.

Trust Issues: In the distributed scrum model, an offshore team is an unknown entity at the start of the project. So there is obviously not a lot of trust to begin with. But persistent trust issues are a problem because any work done by the offshore team is suspect. Instead of getting work done faster, product owner is always trying to quality check the offshore team. This also impacts effective flow of communication.

How to Solve It: The key is to start small. Start off the offshore team with tasks that are not too complex. The PO and the onsite team should slowly get them acquainted to the code base, the product domain, and the engineering practices. As the offshore team starts committing and delivering, the trust starts growing. This, along with the constant communication and setting up matching infrastructure, will lead to rising trust.

Work Culture: The work culture in the East is very hierarchical, while in the West, even if corporate hierarchy exists, interactions are very informal. So an offshore team from the East  can find it difficult to talk or discuss with an onsite team or scrum master (SM) from the West, on an equal footing. This might run the risk of some potential issues not getting raised at all.

How to Solve It: Both teams should be sensitive to, and acknowledge, these differences in work culture. POs and SM in the West should try to ensure a peer culture when onboarding offshore teams from the East. It is also important to have SMs who will work well with both the onshore and offshore teams, and be instrumental in building camaraderie.

Language Barriers: People think better in their native languages. But when working within a distributed scrum model, it’s imperative to at leadst have a common language. A PO and an onsite team in France working with an offshore team from India, will have to fall back on English to be able to collaborate. But there’ll always be some things that could have been better communicated and understood had they used their native languages.

How to Solve It: It is wise to invest in some kind of training and coaching, to resolve some of the articulation issues. This is more important when the teams do not have a common language to fall back on.

Holidays: Holidays for the onsite and offshore team are never going to match. The onsite team may be working on a day when the offshore team is off celebrating something.

How to Solve It: There is nothing much to solve here, except being cognizant and respectful of cultural holidays, and plan the work accordingly.

At Srijan , this is how we have been working with enterprises, building experienced scrum teams that can remotely plug into your projects. Challenges come up, but we have devised ways to resolve them, and deliver value to our clients, with the distributed scrum model.

You can also check out our webinar session on finding success with a distributed workforce, with Harrison Dahme from Pantheon.

If you are looking to plug a distributed team into your enterprise, scrum teams could be just the thing you need. And in case your enterprise is just transitioning to agile, we have curated 6 of the best blog posts by agile coaches, to guide you through a smooth transition.