You are the Scrum Master for a team that is distributed between India and the US. You have two development engineers, the architect and the Product Owner based in Boston, US while three development and three test engineers are based out of Bangalore, India. As the Scrum Master of the team, you are based out of India. You understand the challenges of a distributed team but agreed to go ahead with this team structure due to the skills constraint that your product delivery has to take into consideration.
You have gone through a Scrum Master training and understand the roles and responsibilities of an effective Scrum Master. Even though a distributed structure such as what you have been given is not ideal, you need to do everything to make it work as well as possible. What are some of the things that you would do as a Scrum Master in this case?
Suggested Solution:
Some recommendations for the CHOW
This is clearly not an ideal situation for you as a Scrum Master to be in. You have a 9-member team excluding yourself and the Product Owner with 6 in India and 3 in the US. Before we think of how to deal with the challenges, let us first list the top three challenges:
- The distributed engineering team (dev engineers distributed and all test engineers in India)
- The time-zone difference between India and the US
- Product Owner and Architect based in the US
A somewhat unique situation also arises out of challenges 1 and 3. The team in the US has access to the PO and Architect through the day for clarifications which the team in India does not have, whereas, the team in the US does not have access to the test engineers’ time during their day time which the team in India is fortunate to have. A possible additional challenge (for which there is no explicit information given) relates to whether the Architect is dedicated for the team or is shared with multiple teams, which is often the case. If the person is indeed dedicated to your team, you have one less challenge to deal with.
The first thing to do is to ensure that the team members are all aligned on a common goal. Ensuring team involvement in deciding and agreeing on a common goal at the beginning of every release as well as every sprint is crucial. The second thing to do is to ensure that the team agrees and abides by a common set of norms or a team charter. These two are important for even co-located teams but doubly critical for a distributed team. Some of the norms should address how they will communicate and collaborate with each other, mutual responsiveness, and sensitivity to time-zone differences as well as the need to be flexible and accommodative to team requirements, given the time zone differences. The entire team needs to be involved in both these and should own the goals as well as the team norms / charter.
The time zone difference is the most difficult challenge often – especially given that it is US and India. The saving grace in this case is that Boston is the Eastern time zone so you have some overlap possible with teams in India. You can leverage the fact that teams in the US prefer to start early in the morning while folks in India prefer a later start to the day. This gives an opportunity for some overlap – I have seen many organizations work the 11am to 8pm shift that clearly gives them a 1.5 to 2 hours overlap in working. While a stand-up is ideal for a morning slot, one needs to understand that being together for the stand-up is more important hence a time such as 6 or 7 pm (depending on the time difference) may still be OK. Planning meetings that need to go a little longer may need more flexibility from team members in both locations and could invariably be combined with retro meetings to ensure you do this only once or twice a month based on the sprint duration. Ensuring the PO and Architect participate in the daily stand up and address clarifications the team may have as part of an extension of the stand-up meeting is one of the ways to address the time zone difference and associated delays / bottlenecks.
Even with the PO and Architect attending the daily stand-up, the fact that they are available only for an overlap of 1 or 2 hours in a day is a limitation for the team. One way to deal with this is to ensure we have a surrogate for both these roles in the team in India – with one of the senior developers helping out with design decisions and clarifications (by working closely with the Architect) and either the SM or an Analyst type of person doing a similar role on behalf of the PO. We have recommended to many organizations with distributed teams that they have specific roles created for this purpose, which serves as a footprint for either or both roles. Some of these persons could eventually move into an Architect or PO role in the future.
Lack of test engineers in the US presents a reasonably major challenge. I have seen a number of test engineers in such a situation complain about the quality of code they get from the remote counterparts. The only way you can address this is to increase the responsibility of development engineers in testing their own code so the role of test engineers becomes more of a validation exercise. Another approach is to bring in engineering practices such as Test Driven Development, Acceptance Test Driven Development with test automation – this will eventually enhance the development engineers’ role and reduce the need for test engineers doing low level testing.
One final thought – distributed teams are challenging but if the members have the right mind-set and collaborative behaviour, there is no reason why they can’t be successful. The role of the SM in getting such teams to exhibit the right mind-set cannot be overstated.
