Authors I Michael Luhmann & Kersten Martin Meyer
The new age of working & the challenge for distributed teams in Scrum
Every organisation is faced with the challenge to deal with distributed teams in today’s environment.
Especially due to the pandemic where a changing way of working multi-site development has become more the norm rather than the exception. Having an entire team – especially on a large project – in one single location is a luxury and no longer enjoyed by every project, even though this is one of the key success factors in Scrum. With distributed teams being the reality, you will learn in 3 minutes how to scale and work in such a situation and still be successful in an agile perspective.
What typical kind of issues arise when having distributed teams?
- Communication
One of the golden rules from the Agile Manifesto is that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” While collocated teams face each other in the daily touchpoints, distributed teams only face their screens and microphones. The main challenge for the team lies in scheduling meetings or informal sessions, especially when dealing with cross-border projects in different time zones.
- People feel isolated
Research has shown that many individual team members start to feel fungible being isolated and only having contact by email or calls. When team members start to think that their contribution and added value to the project don’t really matter, the whole team morale will decline substantially.
- Product delivery issues
In practice, when e.g. the UX designer is working remote, he won’t be able to commit to an exhaustive design session to layout the UI in every detail. At this point, the actual iterative process gets either chopped or broken up in email chains. In the end, the design process laying out the whole features and functionalities will be served piecemeal with the risk that the team members will lose the context of the design implementation. Also, for specifying the logic of the interface, it seems to be an insurmountable challenge to document the assumptions about the implementation of the application to a level, that would fulfil the principles of working agile.
- Missing trust within a Scrum team
When the daily interaction with the team members is only limited to calls and chats without any real-life coffee sessions, they don’t feel like they truly know each other. The naive vision of only implementing agile principles in a rigid team will not change this. The essence of agile being self-organised won’t work or will be limited, if the team members don’t know each other.
How can I solve the four identified issues?
- Structure the meeting sequence to the needs of the team
While having the right tools for communication and video calls on hand to allow the team to see each other, it is equally important to use them wisely. Rather than following a scripted, typical meeting plan, the responsibility of the Product Owner and Scrum Master lies in balancing the need for communication and the focus time for work. Therefore, it is essential for the whole team when having meetings scheduled to setup a clear agenda, preferably with speaking slots for each individual. Even skipping one of the ceremonies is sometimes effective to spare up some working time. Agile is not about following everything out of a rule book, it’s about suiting the individual needs of the team and navigate into the right direction.
“Agile is not about following everything out of a rule book, it’s about suiting the individual needs of the team and navigate into the right direction.”
- Boost the team spirit / building rapport
A highly motivated team is the prerequisite for delivering a successful product. Finding ways to mitigate people feeling isolated and boosting the overall team spirit is the duty of every Product Owner and Scrum Master.
By using social facilitation, team members are going to feel valued and part of the team. One way to implement social facilitation is to emphasise the performance of an individual in the sprint review. Acknowledging milestones reached in front of all stakeholders is a good way to strengthen the team spirit.
Another way to establish personal ties is to setup a time slot where the agenda is simply to get to know each other. Try to create a culture of using video chats for spontaneous casual conversations or even try to implement selected meet & greets each quarter, if possible. Or, implement a separate channel for sharing interests, your latest activities, or just photos of your pets. In the end, agile delivery is a culture and not a process. With these kinds of practices, the team is going to feel more bonded and the sense of isolation melts away.
“Agile delivery is a culture and not a process.“
- Enforce continuous integration
Especially when you have distributed developers it is indispensable to derive the user stories based on the end-to-end customer journey along with the vision of the product to understand the interaction model of the user with the application. Having the developer assigned to one specific topic and being placed on a single code base helps the team to stay on the mainline and follow the vision of the product more easily, regardless of their office location.
For UX designer working remotely, it becomes helpful to send out the designs in separate storyboards, which illustrate the interaction between the end user and the product. Based on the narrative sketches, the developer and Product Owner can write down the user stories without losing track of the feature. Additionally, click dummies, mock-ups and wireframes add more direction to the design implementation and reduce the risk of different interpretations. Often, telling a story by adding context to the static images sharpens the awareness for the product vision.
- Use the right tools for an effective communication
Using instant messaging tools like Slack, Teams or Skype (not to forget the importance of using the camera, otherwise people start to hide or drift off on other topics) provide convenient, quick ways to get in touch with one another and to share files in an efficient manner without setting up formal meeting schedules. Sharing important documents e.g. with Dropbox or SharePoint in a secure location keeps the team organised and informed. Tools like Mural or Miro allow the team to create content together collaboratively in real time for retrospectives. Trello or Confluence / Jira can help the team to assign tasks and manage their workspace.
Reasons why distributed teams make sense
Apart from all the challenges mentioned before, geographically distributed agile teams also have their advantages. Individuals can be more productive having the choice to work in their own environment and therefore being more motivated.
Especially in some cases, the virtual interaction with sharing documents and presentations can be more efficient than using the traditional whiteboard, paper or face-to-face conversations. Having everything digital available post-meeting is always better than having to remember what has been proposed or agreed.
Moreover, hiring a geographically distributed team allows the access to a greater pool of talents, learning from cultural diversity and entering new markets. The Agile Manifesto promotes the adaptability towards change and this adaptability should also be part of the chosen environment of an individual.
Geographically distributed agile teams may encounter more challenges than collocated ones. But this shouldn’t discourage companies to hire such teams as they can benefit from highly self-organised individuals. When managed well, these challenges can be turned into opportunities so that such teams can even outperform classic on-site collocated setup teams.
At ::projective, we are used to working with distributed teams and love to chat more about this. Don’t hesitate to reach out to one of our experts if you would like to know more on this topic.