Distributed Scrum
David Starr is Chief Software Craftsman for Scrum.org where he focuses on improving the profession of software development. He also founded the online technical community, ElegantCode.com.
July 2012
Distributed teams often struggle with consistent, timely, and effective communication. Understand how Scrum offers a container in which different types of distributed teams can improve and succeed.
The Scrum framework says nothing about distributed development teams. Scrum does not require all members of a Scrum Team or even members of a Development Team to work in the same room, building, city, or time zone. Scrum Teams do actively expose impediments to increasing productivity, and when communication is an impediment, Scrum makes that very visible.
When team members don’t physically work together, communications within the team are necessarily more complex and so too is the software created by that team. In 1968, Melvin Conway wrote:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Conway’s Law has proven more than an adage; it is a measurable dynamic within software development teams. One study demonstrated the effect of Conway’s Law by measuring the effect team distribution can have on system architecture. When team members are distributed, software developers tend to create more abstraction layers in code in an attempt to insulate themselves from each other[1].
Overview
Seeing the Team in Code
Stella is a developer in a Scrum Team that consistently delivers the work they have forecast for each Sprint. Her team has a reputation for creating high quality software, even if their code is a bit difficult to understand when others read it.
She works at home and in a different time zone than the rest of her team. They use email, an expensive requirements management system, and occasionally video conferencing to discuss their work throughout each Sprint. They use Scrum as prescribed with a Daily Scrum scheduled to accommodate everyone’s schedule. She attends planning meetings and the Daily Scrum via telephone without seeing the faces of her teammates when they speak. She also does not hear the conversations occurring before and after each Daily Scrum.
With good intention, Stella creates an abstraction layer in her code so her work is more easily isolated and tested. Her new abstraction separates her implementation from the interface she has declared and made available to other members of her team. This type of pluggable system leads to cleanly decoupled system architectures, she asserts. “The use of interfaces as an implementation boundary is simply good object oriented design,” she reminds herself. Her new plugin model will allow her to work just in her section of the code and not interfere with teammates working in other areas.
As Conway’s Law predicted, the code now reflects her communication with her team: loosely coupled. Her design replaces the conversations she might have had with her team and the system becomes needlessly complex. This needless complexity is a mirror of her relationships with other members of her Development Team. These decisions will ultimately cost her company money as there are more lines of code to own, more levels of indirection for future developers to understand, and more tests to prove the functionality of the abstraction works properly.
Stella has done nothing wrong. In fact, she has successfully taken advantage of good object oriented design practices to isolate a problem area in the system. Unfortunately, the problem she isolated was her own communication challenges and the solution permits even less frequent communication. Sadly, the system she changed when addressing the problem was the software. A more effective way to deal with this issue may have been to simplify the communications with her Development Team.
When team members don’t sit together they tend to replace easy verbal exchanges with harder and more formal conversations. Rather than quick, efficient discussions about small, tactical decisions, subjects queue up and wait to be discussed later. Often, later never comes. Less person-to-person communication means pushing the communication down into other things, like specifications, work tickets, or even code. ISomeInterfaces exist to cover the dysfunctions of the teams creating them.
The Unintentional Complexity of Team Distribution
Decisions made outside a Scrum Team are those most likely to increase complexity. Software development teams are rarely simple in their composition or tasking, and Scrum provides a boundary within which the Scrum Team maneuvers and works to reduce complexity. Despite this, the complexity of actually writing code and delivering software sometimes pales in comparison to that of organizational culture and processes put in Development Team’s way.
Accordingly, the decision to compose a Scrum Team of members who live in different time zones is rarely made by those doing the work. Decisions to create a distributed Scrum Team likely come from leaders who may be assembling a highly skilled team of specialists, or (more likely) trying to lower production costs by engaging off-site contractors to develop software for less money. While these models may reduce the initial cost of software development, they typically fail to account for the cost of ongoing maintenance and of the complexity added to accommodate the Development Team’s struggling communications.
No matter how or why distributed teams are created, they are a reality and show no sign of going away. Even in distributed team situations, Scrum remains an excellent framework for managing the planning and execution of delivering a software product. Team members simply must be more diligent about improving existing communication channels and guarding against sub-optimizations like those described in the above example.
The Distributed Reality
Distributed teams can provide opportunities to hire the right person for the job regardless of where they live, or for some people to live where they choose rather than where their company is headquartered. Although arguing against distributed teams is easy, the economics of outsourcing, in-sourcing, near-sourcing, and rural-sourcing remain compelling for many organizations.
The Scrum Guide, published at Scrum.org, codifies Scrum and is the set of rules for applying the Scrum framework. While the Scrum Guide is silent on the issue of distributed teams and provides no guidance especially aimed at them, Scrum will make very obvious the communication lags and wastes that exist in teams whose members can’t speak to each other without an electronic device bridging the gap.
Trust Matters
Much of what humans say to each other is communicated through body language. The information gathered by observing someone during a design discussion can be as valuable as the information that gets written on the whiteboard. Because of this, much of the focus in bridging the gap between distributed workers involves overcoming the body language barrier.
Steve McConnell wrote, "The half-life of trust is about 6 weeks." [2] This recognizes that developers working and collaborating together each day evolve a level of mutual trust. The amount of trust varies as in any relationship, but the potential for trust is highest when teammates see and work with each other often.
When teammates stop seeing each other daily and don’t work in close proximity to each other for about six weeks, the level of trust in the relationship is about ½ what is was before. The remaining short tail of trust diminishes rapidly as more time elapses.
It isn’t that the people involved don’t have positive mutual regard or respect, but trust and team effectiveness are lost. Without trust, collaboration decreases and boundaries between teammates increase. Those boundaries are often reflected in the code.
Cameras, teleconferencing, Instant Messenger, video chat, screen sharing, and other collaboration tools help bridge the gap between teammates, and tools like these must be as ubiquitous as air for distributed teams to be highly productive. Frequent video communication can go a long way toward rebuilding stores of trust.
Whatever tools are used, distributed teams can increase their effectiveness by exploiting opportunities for high-fidelity communication. In short, live voice is preferred to Instant Messenger, which is preferred to email and so on. Decreasing time between interactions is even better.
Degrees of Separation
There are numerous ways team members find themselves separated from one another, and there are commonly recurring patterns of team distribution. Like patterns found in other environments (like software design), patterns of team distribution may occur intentionally or accidentally. Accidental patterns occur as an unconscious response to existing pressure and intentional patterns are implemented deliberately to control complexity.
The distributed Scrum patterns described here may be prescribed or unintentional. They may be inspired by decisions made outside the Scrum Team or they may result from the Scrum Team’s self-organization around a particular problem. Regardless of why they come to exist, the following distribution patterns are common in the wild.
Remote Development Teams work together, but are physically separated from the rest of the company.
In the Remote Team Member pattern, a single member of the team works in a different location than the rest of the team of which he or she is a part.
In a Distributed Team, individual team members find themselves working together toward the same goal, but each from a unique location.
The Remote Development Team
Some Development Teams find themselves geographically separated from their larger parent organization, or even worse, their Product Owners. This is common when one company acquires another or when two companies merge. If the Development Team must be remote, Scrum is an ideal way to manage the work and communication of that team with the broader organization. Many teams are successful with this formula today.
Although situations vary, remote Development Teams frequently feel disenfranchised, undervalued, and cut off from the main organization. Members of the remote team can feel ignored and alienated by the parent company, which may (often unintentionally) consider the team less important than those located at company headquarters.
These remote Development Teams repeatedly find reasons, excuses, and opportunities not to integrate their work with that of other teams. It becomes easy to explain away why this Sprint’s integration isn’t important, necessary, or possible. Resentment grows causing the Development Team to view requests to integrate code with the broader organization “unreasonable”, “out of touch with our reality”, “unnecessary”, or “insensitive to our needs”.
Whether none or all of these impressions is true is irrelevant. The remote Development Team needs to feel heard and understood, while understanding its own value in the broader organization. It is easy to forget one is part of something greater than oneself when serving in a remote post.
A Scrum Master working in a different location than the Development Team is a recipe for failure. Scrum Masters cannot effectively perform the duties of coaching, facilitating effective Scrum events, and stewarding Scrum itself from a distance. Distance between a Development Team and Scrum Master impedes communication and introduces too much risk into the Scrum Team. Familiarity is required for trust and high mutual trust is fundamental to Scrum’s success.
Scrum Masters work in the same location as their Development Teams.
For a Development Team to serve its Product Owner well also requires unimpeded and clear communication. The Product Owner must be available to the Development Team throughout each Sprint to answer questions and provide feedback on works in progress. While this frequent interaction is possible in remote situations, a reliable method for maintaining this communication must be established.
An absent Product Owner is one of the most destructive forces a Scrum Team can experience. A neglected Development Team is forced to make decisions regarding functionality and priority. This group is often the least capable of making good choices regarding functionality as they are typically less informed about the customer’s needs than the Product Owner.
Product Owners give attention and feedback to the Development Team throughout the Sprint.
Unfortunately, absent or rarely available Product Owners are a common dysfunction in Scrum Teams, even in collocated environments. For Scrum to realize its potential the Scrum Team must function as a cohesive, trusting and collaborative unit and that requires regular attention from a dedicated Product Owner.
The Remote Team Member
Some developers are segregated from their teammates who are themselves collocated and working together in a shared location. The classic example is the work-at-home developer who dutifully works with a team from her home office. Although reasons vary for this arrangement, it is increasingly common.
Alistair Cockburn coined the term Osmotic Communication[3] to identify a type of intrinsic communication within the team room.
Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work.
Osmotic Communication is not restricted to software development teams. Visitors to a newsroom in a large newspaper or media outlet will often find exactly this dynamic at play. Even detective squad rooms in police departments around the world use team rooms to increase collective understanding when investigating crimes.
The loss of Osmotic Communication is the loss of situational awareness within the team. When a software developer isn’t aware of changes being made to the software by his teammates as the changes are being made, there is a loss of cohesion and shared context within the team. The un-interrupted, focused, and remote team member doesn’t hear the gold in the air of the team room. This leaves her out of ad-hoc discussions regarding design and other decisions occurring fluidly throughout a given day.
The trend to deliver software more quickly with less time between releases requires even higher situational awareness within the Development Team. For the remote team member without a presence in the team room, situational awareness is simply lost.
Tele-presence solutions are becoming more common to address this problem. Simple tele-presence solutions may be built using an inexpensive laptop, camera, and speakers. Positioning this system in the team room can provide an open channel of communication for the remote developer who can simply leave the channel open throughout the day.
Video and teleconferencing help bridge the body language barrier.
Signs the remote developer is struggling to actually be a part of the team include:
Using typewritten communications like email or Instant Messenger to discuss complex issues.
Defining fixed interfaces as contracts in the code rather than having regular discussions with other developers.
Wanting a private, or personal, code branch in version control.
When bridging the gap between a remote developer and the rest of the team, periodic visits are very helpful. Video calls are better than telephone calls. Telephone calls are better than typing, and relying on email is a disaster waiting to happen.
The Distributed Team
In a truly distributed Scrum Team individuals work together to deliver the same Sprint Goal, and each team member works in a different location. The arch-typical example is an open source project with contributors living in various locations around the world. Although the communication issues are significant, this model has demonstrable validity. Communication in a team like this is necessarily challenged, but is becoming more common as technology continues to reduce the body language barrier.
When team members sit in different locations, screen sharing software is essential to having effective conversations about design and code. Regarding code, unless both parties in a conversation see the same thing, the discussion includes too many assumptions. Luckily, screen sharing software is readily available and highly effective. Team members who aren’t in the same room should find themselves sharing screens with their teammates several times a day.
Screen sharing can be a very effective pairing and collaboration tool.
Finding excuses to examine code, backlog items, or other artifacts together is a great way to keep situational awareness in distributed teams high. Another effective technique is adding a simple verification rule for any item delivered as part of the Sprint. The two-part rule is:
Each item must be verified in an integration environment to be considered done.The person doing the verification may not be the person who did the work.
Development Teams adopting this simple rule find a greater collective understanding of the work being done throughout the team.
Author’s NoteI worked with a development team whose members worked in the same building, but in different offices. It was a point of pride for the company to provide private offices for all employees. The Development Team eventually decided to create a virtual team room into which each team member could appear using a camera, microphone, and speakers. The virtual team room remained open at all times and team members would drop into the room when working on the product they shared.After a short time, the team came to appreciate this virtual room. They began using screen sharing software to view each other’s screens rather than walking down the hall, because they found it to be faster. The team began using the virtual team room all day, even though they were sitting in offices separated only by a few inches of wall space.Eventually, one of the team members tried not coming into the office for a few days and working from home. During Sprint Retrospective, the Development Team agreed the virtual team room made it irrelevant whether a person was a few doors down on the hallway, or at home. The virtual team room proved itself more valuable than individual offices.
Tools and Practices
Much ado is made of agile teams using low-tech and hi-fidelity tools to manage their work. When the complexity of geographic distribution or multiple Development Teams is added to the mix, analog index cards and markers simply don’t scale as well as a software based solution. This has led to a glut of work management tools designed especially for Scrum or “agile” teams, with many tool vendors essentially promising “our tool will make you agile”.
Confusing Tools with Practices
Of course, no tool can cause a team to “be agile”. Genuine agility comes from the culture, attitudes, and behaviors of the people making and delivering the software. Because of this, the agile manifesto[4] expresses a value for “Individuals and interactions over processes and tools”.
A common saying in the agile community is “People over process and process over tools.”
A common saying of pragmatists is, “The tools set the rules.”
Both of these adages speak to the relationship people have with software used to communicate, collaborate, and manage work. Work tracking tools are meant to decrease complexity in communication and understanding, yet the exact opposite outcome can happen. It isn’t uncommon for people to fall into the rut of unnecessarily reporting a defect instead of fixing it, for example.
Authors NoteA great resource for those considering the balance between tools, processes, and practices is Kent Beck’s whitepaper, Tools for Agility. The paper is as insightful today as it was when Mr. Beck wrote it in 2008.
Scrum Masters and Development Team members are prone to lament, “The tool is out of date,” when data in the work or feature tracking system is not current. This disregards what you may know intuitively:
The goal is to keep the team current, not the tool. Sometimes the tool can help with this.
Scrum is specifically designed to increase the situational awareness in the Scrum Team. Scrum is silent about the format for requirements, minute keeping, work breakdowns, estimation units, or time tracking. Teams may find these things useful and they can work within the context of Scrum. But teams using these additional practices are doing so in addition to Scrum, not because of it.
Supporting Practices with Tools
Any tool used by a Scrum Team is hopefully chosen to support a practice selected prior to the tool. That is, healthy Scrum Teams improve deliberately. Doing so means choosing a new practice or technique to try because the team wants to improve in a certain area. Using a tool to support the new practice can come after the fundamentals are tried. In short:
Choose great people first. As a self-organizing team, they select their own practices, and finally choose a tool to support the practice they have chosen. Value people over process and process over tools.
(For more information about the tools to support your practices available in Visual Studio Online, see Get Started.)
How team members work together has undeniable and obvious effects on the software they create. When communication is easy and effective, the resulting software design reflects it. Conversely, when teams struggle to communicate internally or with those whom they are serving, the software the team produces will reflect the impedance the team experiences.
The regular inspection and adaptation cycles of Scrum go a long way toward helping teams in distributed situations. The prescribed events in Scrum force communication to occur, but don’t necessarily impact the form the communication takes.
A collocated team room remains the lowest tech, highest fidelity, and most effective way a team can collaboratively create complex software. But, remote teams are here to stay. Whether motivated by personal situations, economic benefit, or lack of foresight, more and more Scrum Teams find themselves working in situations where team members aren’t together physically.
Attending to a team’s communication over physical boundaries will pay dividends in higher quality, less confusion, faster throughput, and happier individuals. When careful consideration is given to tools and practices within the team, distribution can work well. It can even work very well.
References
Herbsleb, 1999 Architectures, coordination, and distance: Conway's law and beyond. IEEE Software, 7
McConnell, S. (2009). Travel Restrictions and Offshore Development.
Cockburn, A. (2008). Osmotic Communication.
various. Agile Manifesto.