MMS • RSS
- There are common patterns that impact individuals, teams and organisations as they try to adopt agile approaches while working remotely
- Remote agile teams do work, however they need a framework to assist them
- There is a framework which can be used, exploring six elements that need to be addressed – Culture, Communication, Leadership, Teams and tools, Organization, Product
- A useful framework needs to provide more than just practices – crossing distance and culture requires teams adopting different behaviors in order to build psychological safety
InfoQ contributors and distributed team experts Hugo Messer, John Okoro and Savita Pahuja have expanded on their articles and minibook on working effectively in distributed teams and published a book titled Distributed Agile Framework. They present a framework for distributed organisations and teams who want to use an agile approach to delivering customer value.
The framework explores six aspects that impact individuals, teams and organisations when working remotely:
- Teams and tools
For each aspect they supply a set of questions to explore, virtues to nurture and aspire towards and practices they have found helpful.
The authors spoke to InfoQ about their motivation for writing the book and the important points it covers.
InfoQ: Why did you write this book – what is the problem you set out to solve?
John Okoro: We noticed that there was a gap in terms of guidance for distributed Agile teams. It also happens that a large number of Agile teams are distributed.
Hugo was already working on distributed agile blogs, models and mini books. When we met and discussed the topic, we figured out the common interest and experience on this topic. That’s how we decided to write a book.
Savita Pahuja: We always wanted to share with the community our experience as well as experience of other people working in this space that’s why we have many practices shared by people in the community.
Hugo Messer: A few years back, I ran a podcast around distributed agile. The interviews with Savita and John inspired me and later, in our discussions, the idea of writing a book about it popped up. We initially started with 4 authors, but one was too busy to continue the effort. The initial idea came up as we saw ‘distributed’ was never answered fully within the agile community. Most frameworks touch upon it, but always look at distribution through their framework-lense. We thought it would be interesting to help address the specific challenges that come up when working distributed. We spoke to many people who struggled with it throughout the years. In my own company, Bridge, I have always had challenges with the distribution across Europe, Ukraine and India. With the book, we mean to help provide people solutions to these challenges.
InfoQ: Why do organisations adopt a distributed team model, especially when most software development groups are adopting agile approaches which seem to be biased towards collocated teams?
Okoro: Collocated teams are the best approach. But the practical fact is that more often than not, Agile teams are in different locations. Some nearshore, some offshore, some in different offices in the same country, some in different countries. Jeff Sutherland discusses hyperproductive distributed Scrum teams that are not geographically collocated. This becomes even more important when we take into account large scale / Agile scaling. These types of teams are almost always located at different locations.
So while having a collocated team is ideal, in practice it is often not the case, and Agile practitioners, and development teams need to know how to work in a frequently distributed world. We created this book to help provide this type of practical guidance, along with stories from other practitioners, virtues, questions, and practices.
Messer: As John wrote, reality shows that organizations today need to source talent from across the globe, especially in IT roles. It is true that agile works best in collocated teams; And in a distributed organization, that’s also what can be established. While teams may be on different locations, the teams itself are often collocated. The orchestration of work between the teams can be done in a distributed fashion. A product owner can for example be based in the head office in the US. Teams may be located in India and South America. In a more scaled approach, the Chief Product owner may be in the US and local product owners collocated with the different teams. This is one way to organize agile teams in a distributed setup.
InfoQ: What are common patterns for remote work?
Okoro: In Agile teams some common patterns are:
- Client Product Owners at a separate location from Agile ScrumMasters and development teams that are distributed at multiple locations worldwide. If not handled well, this can be an “anit-pattern” as it may reduce customer collaboration because of limited communication with the Product Owner.
- Individual distributed team members, each working at a different location; in this pattern tools become even more important to create a sense of “teamness” or “ba” and to allow the distributed teams to collaborate effectively.
- Another pattern is positioning distributed teams, so that work can continue round the clock. For example a Scrum team in Thailand, another one in Eastern Europe, and another in the US. These teams can align stand-ups or use tools like Slack for stand-ups, and continue work on their products 24/7.
- Virtual cross functional teams at multiple locations is another pattern, that we consider to be a virtue. This means each location has multiple roles: ScrumMaster, Product Owner, Developers… at each location.
- Related to number 4 above, one more pattern is a distributed Agile Product team that is made up of multiple collocated team locations. So each location has the benefits of a collocated team, but the entire team is distributed across multiple locations. So the the entire Product team still has to keep in mind the practices, virtues, and questions like those we cover in our book for distrubuted Agile teams in order to be most effective.
InfoQ: What are the biggest challenges faced by remote workers?
Pahuja: The biggest challenge for remote teams is to not have alignment with respect to vision, goals or strategy with rest of the organisation. There are many root causes of not having the alignment. Some of them are:
- Lack of communication – By human nature, people like to talk more to the people who are in near proximity compare to the people on other building or city. Because of not having ease of communication with people not in the same place, creates misalignment and misunderstandings and we all know that misunderstandings disrupt high performing team culture which in turns hampers the product delivery.
This problem is common across many organisations. Hence, we recommend to fix this problem by increasing communication. The best way is to flying people time to time to increase face time. Secondly, always have discussions on video conferencing. Other than that improve transparency by using digital tools.
- Leadership support – Leaders should lead by example whether its a colocated team or a distributed team but in case of distributed teams, its become more important to focus good leaders working as lead by example so that they have good alignment across multiple locations. Once top is aligned, teams get along.
- Cultural differences – Even when team members are open to communicate and understand others, if they don’t understand how to communicate as per others’ cultural norms, they just end up in having conflicts or disrespect for each other. We suggest teams should use tools like culture map or team map to understand their distributed team members in the beginning of the product development so that they can have constructive communication.
What are the challenges that organisations face when setting up remote teams?
Pahuja: In the beginning of the product development, organising teams with respect to product features and required skill sets is challenging particularly when people are in different locations. The common challenges, organisations face are:
- Availability of all required skill sets in one location
- What should the configuration of team. In which location product owner , scrum master and other team members should be placed.
- How team members in different locations would be aligned on vision, roadmap and features
- What would communication channels and regular communication, collaboration look like?
From our experience, multisite small co-located teams work better than totally distributed teams but in that case decision shouldn’t be made based entirely based on the available skill set on different locations. Create small multi site teams and help them grow skills to work on end to end features to avoid lots of dependencies on people who are not sitting with them.
Messer: Savita described the patterns organizations face when setting up teams. One underlying ‘current’, mentioned above already, are the cultural differences. We see that in many cross cultural teams, culture is something which influences the way we communicate and collaborate, but it’s not always visible. We are all born with certain habits and behaviors. The culture we’re born in has a large influence on these. Once we start interacting with people who live in another culture and have very different habits, we face challenges. While on a human level, we’d think that we’re the same and we are aligned, on a deeper level, we’re often not. If I am from a low context culture (like the Dutch culture), I am used to getting things presented in a clear, direct way. If a colleague who reports to me, has a question or a better idea of doing something, he’ll simply share that with me. Now when I’m living in a high context culture, with a lot of hierarchy, The colleague will be sensitive to the power distance with me. So instead of sharing his question or idea, he might choose not to, because he feels he may hurt my position or feelings. Me being from a low context culture, I could become frustrated because the colleague seems to be hiding things and seems to be ‘not proactive’ or ‘not open’.
In a cross cultural, distributed setting, we have few chances of addressing these cultural misunderstandings. So we need to pay specific attention to address them. To have open discussions with colleagues of how culture influences our collaboration. And what we can do about them.
How do remote teams build trust and psychological safety?
Pahuja: Building trust is not easy in remote teams. As per normal human behaviour, people don’t trust others with whom they haven’t spend enough facetime and seen others behaving in different situations.
So, organisations should provide them enough facetime. One of the powerful way of doing this is in the beginning of the product planning, let people fly from different locations in one location for initial discussions and continue this in regular intervals later on. Otherwise try to do all the discussions over the video conference.
Psychological safety can’t be created without creating a culture of accepting failure as an opportunity to improve. The same culture should be created by the leaders in all the locations by sharing same message and leading by example.
InfoQ: What advice do you have for the manager considering setting up a remote team?
Okoro: Start by bringing the team together to meet face to face at least once. This is a good way to build relationships, and helps to establish strong distributed teams. Second make sure to have the right tools to enable remote collaboration. Tools like shared Scrum / Kanban boards, video conferencing, telepresence, wikis and others help to span the distance between team members. Finally having working agreements, and shared team and leadership values in place helps to further improve collaboration between team members. Our book covers many other questions, values, and practices that are beneficial for distributed Agile teams.
InfoQ: What advice do you have for the individual considering working remotely?
Okoro: First establish trust and a relationship with your organization / team. It is generally difficult to start your first day and ask to work remotely if you are not already known by the team (unless that was your pre-arranged working arrangement. Also make sure that you can be an effective part of the team working remotely. If everyone else is co-located, and you are the only remote team member, you may find it a challenge to stay engaged with your team. On the other hand if the whole team is in different remote locations, support may already be in place to be effective working remotely.
It is also key to make sure to check-in frequently. Ideally for a Scrum team this may be during daily stand-ups. For a Kanban team possibly during weekly stand-ups. But it is essential to make sure that you stay connected to the rest of the team, and don’t find yourself in isolation. This can take extra effort on the part of the remote team member, so it is good to be prepared for this ahead of time.
A referral link to our ebook is here.
About the Book Authors
Savita Pahuja has expertise in Scrum, Lean, kanbanareas and other visual discovery methods. She started her journey in IT industry as a developer and contributed the organization in agile adoption. Then she moved into agile world as a consultant and trainer. Since then she has been working with different clients for agile adoption and giving trainings on scrum and kanban.
Hugo Messer has been building and managing teams around the world for over 10 years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. He’s the owner of Bridge Global, a global software powerhouse and ekipa.co, the education platform for distributed teams.
John Okoro is the creator of Auspicious Agile and Head of Agile Practice at Orbium. He has founded Agile services practices for Rally Software in Asia and for a US management consultancy. With nearly a decade using Agile methods, John is an expert at using Agile practices and methods at Enterprise scale and in large and distributed organisations. John is a frequent speaker at Agile and industry conferences and has contributed to InfoQ on DevOps.