Scrum Hacks: How to work with distributed teams

"To thrive in chaos and adapt to change, requires the mental preparedness to modify one’s thoughts at a moment’s notice. Remember, the only easy day, was Yesterday" - Forbes.com

Overview

The night of December 7th was the coldest night of that winter, at least for those Marines’. The mission was simple; bring about 4,000 of the strongest men northward from the southeastern tip of the reservoir, to secure the exit of the 10,000 Marines trapped in the Chosin Reservoir valley. 

However, the situation was soon about to turn dire and chaotic, as the Chinese forces, blew up a crucial bridge over a treacherous mountain pass, cutting off the planned evacuation route. Now the captain had only 2 options. Either retreat and put the entire battalion in jeopardy or bring in the Agility, to thrive in this complex situation whilst accomplishing the mission. What would you do? 

The situation of a Scrum Master working with a multi-tech stack, distributed (non-collocated/geographically independent) feature team, is somewhat similar (if not that complex), to the above-mentioned extract from one of the most harrowing battles of the Korean War.

What is a distributed feature team?

As mentioned in the Agile manifesto ‘Individuals and interactions over processes and tools’; agile development was originally imagined for clustered teams, or teams physically located together in the same office. The key idea behind this was that to establish trust and handle effective communication, the team members needed to have a face to face conversation. However, with time & evolving technological improvement plus heavy offshoring strategies; most businesses have a few–or several–distributed teams. 

The major advantage being reduced cost, strong and varied talent pool with round the clock project delivery facilities. Depending on how the talent pool is identified, team members can be working on different floors in the same building, working within the same city and different buildings, working in different cities in the same country, or working in different cities around the globe (or a combination of all the above). 

Don’t forget that work from home is also a very common option these days. This distributed team also needs to work on a common goal, thereby as a distributed feature team, accountable for implementing a functional necessity, such as a use case or user story, from end-to-end. This is most commonly referred to as implementing a vertical slice of the solution, for a single line of business. 

The inverted pyramid depiction of a distributed team

What is a multi-tech stack team?

Imagine an independent dev team (there may be some overlapping between teams), wherein a bunch of peers, all experts in their own area and language (call it .NET, PL/SQL & Java …), all working towards a common requirement which produces working software at the end of the iteration? You have probably got the hang of a multi-tech stack team now.

Although there is a lot of push to move towards a full stack ‘product team’, it’s sometimes inevitable that (based on the current architecture/legacy application), you will still end up teams working in this multi-tech stack mode. The risk of running such teams is chances of having UX misalignment, the emergence of tech silos, lack of shared vision, and all of this leading to some form of demotivation and limited productivity.

However, given that many companies still run in this mode, what’s the effective way to tackle this situation? If you are still interested, please read on. 

What are the common challenges seen in this set up?

There appears to be more distributed Scrum Teams. In many circumstances, there are more difficulties, but Scrum can still function. Have the Scrum Team examine and alter what works and what doesn't, and coach them to detect and implement solutions.

• Collaboration between team members: For any non-collocated team, one of the first problems is ‘us’ versus ‘them’. The problem here is that this mindset causes collaboration to get worse over time. When things go wrong, the two ‘sides’ blame each other.  

• Varying time zones: This can be a huge challenge, especially for teams with a bigger time difference. For e.g., distributed across India and US (California) time zones; especially if it’s new product development with higher complexity.

• Need for investment in collaboration tools: Investment in top-notch collaboration services, bandwidth, and communication tools locally and in each remote location

• Facilitation of Scrum events and other meetings: In a lot of cases, the ‘development team’ is remote from the product owner. The key person to enlighten the remote team is the product owner. He/She speaks to the users and understands everything about the product. And what often happens is that PO’s also the busiest person in the whole company. He’s always out and has a challenge squeezing in the meetings needed to transfer knowledge.

• Getting to know one another:  A major challenge that he distributed team member’s face, is getting to know one another. It’s pretty easier for any collocated team get to know one another through small talk, probably when they meet up for lunch in the corner of their office canteen.

How a Scrum Master can help overcome the challenges of a distributed team

Distributed teams advantages & best practices to improve productivity

Having seen the challenges, one can get easily put off with the concept of distributed feature teams. However, this concept surely comes with its PROs. To start with, it made perfect sense having dedicated groups of people autonomously (resource-wise) “working on the same thing”. The concept as such is a powerful one. Let’s look in detail what benefits this brings in.

First let’s look at some obvious advantages, as mentioned below:

• Lower development costs: Predominantly as a result of the wage differential between countries and sometimes even cities within the same country. 

• Strong talent pool: We all know that talent is easily retained by not requiring an undesired relocation. A lot of companies struggle to find the right talent in the required locations, especially if we are looking at co-located teams. The constraints can vary from salaries, technical competencies, etc. However, having a working distributed team structure helps overcome this challenge. In simple terms, it gives the organization unlimited access to a larger pool of skilled people.

• Improved time to market: If done successfully (with a strong PO), there is an opportunity for quick delivery when the team is disciplined enough in terms of development standards, automated regression tests, and sophisticated configuration management. The idea being globally distributed sub-team will do their work during their day time, then hand-off the work to a team that is several time zones away, thereby producing outputs round the clock. 

• It’s the future: I genuinely think that this shared set up will be quite common in a few years. Certainly, there are difficulties, and they are still figuring a lot of it out, but it’s enjoyable and a huge opportunity to be able to be part of this change and experiment.

In order to achieve the above-mentioned benefits, the teams need to have some best practices put in. Some common best practices are presented in the below best practices cycle: 

 Distributed team- Best practices cycle

Key Takeaways:

• Positive Team Culture & Rapport – As a scrum master, you would want to promote a culture which is based on respect and collaboration, a culture where people want to work with one another even when they are very far apart.

• Convince management in investing in cutting edge collaboration tools which will help the teams to communicate, integrate code & deliver software at a faster pace. Remember the phrase ‘The most efficient and effective method of conveying information to and with a development team is high-bandwidth conversation’. 

• Most importantly, try and avoid having Scrum events on Mondays and Fridays, especially if the time difference is more.

Thanks for your patience and wish you all the very best in your Agile journey. In case you want me to write about any specific topic, please feel free to comment below, and I’ll be more than happy to add them to my ‘Blog Backlog’.

Hope to see you soon, with more such interesting topics.

Get ahead. Get Agile Certified!