Teamwork means pulling in the same direction!

Teamwork means pulling in the same direction!

Distributed Agile teams can be afflicted by a number of procedural issues that can impact the effectiveness of a team. While the root cause of most of procedural issues is either communication or culture (or both), in some cases it is expeditious to solve the current symptom then to circle back and tackle the potentially larger problem. There are no problems that, with a bit of creativity, a team can’t solve. Three relatively common procedural problems that distributed Agile teams encounter include: the failure of face-to-face communication methods due to scaling, workload imbalances between members and location-related status. Teams with any of these issues that don’t deal with them quickly will have major delivery issues.

Distance is one of the twin banes of intimate communication (culture is the other) as we have described in past Daily Process Thoughts. Distributed Agile teams with communication problems will fail, or at least will be horribly inefficient.  The majority of Agile techniques work best when team members communicate directly with each other either individually or in group sessions. As noted in Distributed Agile: Communication, communication is a major challenge in distributed Agile. When an organization wants to use Agile techniques, but can’t use the most efficient mechanisms for communization, their choices range from throwing up their hands and not using Agile to an equally controversial approach of using some paper-based communications tools to supplement face-to-face strategies or near face-to-face, like video or teleconferencing. Most practitioners of Agile have a significant aversion to documentation of any sort.  An example of how one very distributed team I observed (seven team members each in a different country and only two in the same time zone) solved the problem was to use multiple communication techniques. The team used a combination of diagraming, published notes/meeting minutes and an occasional video to capture decisions.  This solution also allowed team members that were struggling with accents or language to consume team interactions in multiple ways. In the team’s opinion, they adopted an approach that created just enough documentation to help them work (and they really liked doing the videos).

Everyone on a team is expected to pull their own weight.  Agile teams are no different.  Workload imbalances will cause bottlenecks and animosity between members (listen for comments like “why do I have to do everything?”).  Workload balancing on distributed Agile teams is complicated by distance and the probability that work is offset by time (India is starting when Los Angeles is ending their day). The complexity of the work flow requires that everyone pay close attention in daily standups as tasks are taken and completed so everyone stays on task.  As a self-managing team, all team members need to coach their peers to stay involved, even if their personal specialty (e.g. testing or architecture) is not needed at full capacity. Scrum Masters or coaches should help make sure all team members understand their role in managing the team and point it out if workload seems to be unbalanced. Techniques for visually tracking the flow of work, such as Kanban, are effective means of monitoring the balance of work across the team. Teams ignore imbalances at their own risk.

A final example of a practice that can harm a distributed Agile team is when a team falls prey to location status bias.  Location status bias is when members in remote locations are treated like “helpers” or second-class team members. It is very difficult to develop a team with esprit de corps if some members are treated like “helpers.”  This is important because if a team does not pull together and in the same direction they will not deliver as much value as possible. Coaches and Scrum Masters must spend time ensuring that team members view fellow team members as valuable and as equals. Start by taking the time needed to make sure that team members get to know each other. Try to get people physically together, or try virtual team events/games that require cooperative efforts between team locations. Another idea is to develop an Agile team charter that includes explicit statements on team norms and values. Statements of values and norms developed by the team give the team a tool to police their own behavior. Distributed Agile teams that have two classes of membership will quickly evolve into separate camps that will find it hard to work together.

The three common procedural problems that distributed Agile teams can experience will cause significant problems if they are not addressed. On a positive note, each of these issues can be solved through active coaching. Start by holding a team retrospective. One of the nice things about retrospectives is that you do not have to wait for the end of sprint (or the end of anything). Take an hour or two and start by getting the team to talk about the problems.  If you are facilitating the impromptu retrospective, help the team move from talking to finding a potential solution that they can execute. Have the team try the solution and then reconvene, discuss and refine.  Teams rarely run into an intractable problem if they are allowed to solve the problem themselves, but if they do, then is the time to seek outside help. Start by trying to solve the problem rather than getting someone else to solve it for you.