On 26th April I attended That Crazy Agile Thing. During the course of the event time was set aside for three open space sessions prior to which attendees were given the opportunity to suggest a topic upon which they would lead a wider discussion. One of my colleagues suggested that I recommend a topic for discussion – working with an offshore model.
In the lead up to the session I gave some thought as to how to set the scene. This made me think about the problems I was currently encountering and had previously encountered. As I thought more about these issues and considered how I had/was addressing them, I recalled that I had encountered similar problems when working with distributed teams across the U.K. (Leeds and London) not just when resources were offshore. I therefore decided to update the open space session topic to cover any aspect of distributed teams.
I opened the session as a forum for people to discuss the issues they were facing with distributed teams, encouraging others who had faced similar problems to share their experiences of what worked and didn’t work for them. Below are some of those issues and ideas of how they could be addressed. This is by no means a definitive list of the issues that could be faced or ways that they could be resolved, but is intended to be starting point for anyone that is working with distributed teams and how the impact of them could be minimised.
Time difference(s)
Most commonly seen where there is a offshore model in place, distributed teams may find that they are working at different times of the day/night with limited crossover. This can inhibit collaboration and team unity. There is also a chance that a team member could become impeded while they await a response from a team member in another time zone.
Even when a team is co-located, organisations that have ‘core working hours’ may find some employees like to come into work early and go home early, while others will get in late and work late. The key thing whatever the situation is to ensure that maximum value is obtained when everyone is in the office.
In order to ensure maximum value, identify the common working hours of team members. This will allow for the scheduling of the Scrum ceremonies and/or refinement/prioritisation sessions, promoting collaboration and unity. It should also be possible to identify future dates where some flexility will be required from the team, i.e. identifying release dates so could those offshore work a later shift pattern, with those onshore working an earlier pattern so that everyone is in at the same time?
Where extended hours are being worked by team members, be it working early or late, you need to ensure that they can get to/from work safely and that there is enough coffee and pizza to keep them going.
Logistics of Sprint ceremonies
As briefly noted above, the timing of Sprint ceremonies may be restricted to common working hours. This may have an impact on the amount of time available for them to be held. A way to overcome this is to split the Sprint Review, Retrospective and Planning sessions over two days.
When holding these sessions in a co-located environment all team members are able to interact and see the reactions and body language of others. This is immediately lost when people are in different rooms. Video conferencing or a communication service such as Google Hangouts does allow the team to see each other and improve collaboration, although nothing beats everyone being in the same room.
Unfortunately, the common scenario is for team members in each location to be sat round a spider phone. This should be used as a last resort as it can be all too easy for team members to remain quite. The use of mute should only be used where there is other background noise and should be forbidden during discussions. Using mute as a tool to limit discussions to those in one location can harm trust and team cohesion.
Visibility of work
When teams are spread across multiple locations, the value and use of physical boards is limited. I still believe that there is benefit from these as they radiate information to those in and around each office as to the current state of the development. Unfortunately where team are not co-located, there is the need for someone other than the person completing the work to keep the board up to date.
Ensuring that user stories are regularly commented to highlight and share progress is extremely valuable and ensures visability. Tools such as Slack, also allow team members to continually collaborate despite being spread across multiple locations.
Documentation
One thing that often happens with distributed teams is that the amount of documentation produced will increase. This can take the form of increased numbers of:
- emails
- comments on user stories
- specifications attached to user stories
- wiki pages
Although there will be some use and value of this documentation, it can lead to a reduction in the number of conversations. Team members can mistake the increase in the amount of documentation as confirmation that the problem trying to be solved is fully thought through. Rather than having a conversation to confirm their understanding about what has been written in a user story, it is often developed based upon an interpretation of what has been written.
Teams need to encourage communication and potentially build it into their working agreements, i.e. before development begins on any user story a 3 Amigo’s session will take place with interested parties, but must include representation from Product Owner/Business Analyst, a developer and a tester.
Access to PO
Access to a Product Owner can be difficult not only for distributed teams, but those that are co-located where a Product Owner is not dedicated full-time and/or doesn’t sit with the team.
If a Product Owner is not dedicated and/or available, can the Business Analyst answer queries from the Development Team? Alternatively, can a set time each day (most likely around the time of the Daily Scrum) be made where the Product Owner can answer questions?
Building trust
Probably the most difficult thing to do when working with distributed teams is to build a relationship and trust with people in a different office with whom you are unable to interact with. It is commonly the case that most communications will be via telephone and, as noted above, when you cannot see a persons body language and their reactions it can be difficult to judge what people are really thinking/saying.
In order to help build trust, it is important that there is not a blame culture if and when things go wrong, within a delivery. If this happens, any trust that has been built may be lost and the team may develop a ‘them and us’ mentality, which will inhibit collaboration.
Cultural differences
There were a wide variety of cultural differences that were discussed. These included:-
- Awareness of public holidays in different countries (and the areas within those countries)
- Times of day that the team may be unavailable
- Highlighting the importance of accurate reporting even if it is bad news
- Ensure that saying ‘yes’ really does mean ‘yes’
- ‘Burning the midnight oil’ to ensure work is completed within a Sprint/to a deadline
The first two items are relatively easy to address through conversation. Understanding team availability in the short and long term helps with daily and Sprint planning, identify when Sprint ceremonies could occur and when there may be peaks and troughs in velocity due to planned leave/national holidays.
The next three items are more difficult to overcome, but they can be overcome, often as trust is built. The identification and sharing of issues and impediments by team members is key, otherwise the Scrum Master cannot do anything about them and the team will continually struggle. Often you will find that the offshore partner will have an onshore presence and that person is likely to hold the key to unlocking the accurate reporting door. In the first instance it may be necessary to work with them as a conduit in order to build trust with the team. Over time, as trust is built, team members should start to feel more comfortable about raising issues directly.
In some cultures, team members will not openly disagree with things that are said or suggested. In order to ensure that ‘yes’ does mean ‘yes’, there are a few options. You could try open ended questions in order to get the team talking. Alternatively, if it is a question where there are several options, ask them to state the option any why they selected it. Or, if it has to be a yes/no question, you could repeat the question as its opposite, where a ‘no’ response should be given. If you get a yes response to both questions, you know that the questions have not been understood.
Finally, you need to ensure that your team members do not burn themselves out. There can be a culture where team members will come in early, go home late and work weekends. Yes, there may be times where this is needed, however, this should be the exception rather than the rule.
Thanks, great article.
I’m glad that you liked it.