The 3C's of a great Scrum meeting comes down to communication, communication, and communication. This becomes more pronounced as a team becomes distributed. Distribution can be on the other side of the floor or the other side of the globe. Balance in communications methods is the key

Agile processes are successfully executed based upon a strong Scrum process, the team focal point for daily interactions. The key concept behind the Scrum is to have a self-organizing group that can come together, understand what has been accomplished and focus on what still needs to get done.

The concept is simple; however the process gets complicated when applied to a distributed or global Agile project in which parts of the team are physically local and part of the team is geographically in another time zone or venue. This article will present a "day in the life"; of a typical Scrum meeting that has been successfully used with corporate IT projects as well as county government projects. The article will discuss how US and Indian Scrum teams interact within the context of an Agile project.

The Right Balance Between Formal and Informal Communication Methods
Co-located team members meet more or less impromptu. A point not generally noticed is that visual cues enable each person to determine when (or when not) to interrupt the other team members. The visual cues provide the flow for a team in reading each other and the status of the project. This preserves the rhythm of everyone's work while maximizing the personal communication and reducing delays.

The absence of the visual cues in distributed teams causes the situation to be more complex. A completely free-flow policy about making telephone calls, for example, may seem to maximize personal communication and reduce delays but unintended interruptions of the work rhythm for the recipients of such calls may overshadow the benefits quite soon. The absence of the visual cues may also place strains on the cordial relationships among the team members.

The situation thus calls for some structure around this type of communication while preserving the low-ceremony paradigm of the agile approach.

In our experience, this is achieved by reserving a certain "band" of time during the day when people can freely call each other on the phone or instant messenger. The overlap of a set of core hours is the key idea. Outside of this band, unscheduled calls are to be avoided and discouraged. When expectations are thus set, each team member soon tends to organize his/her schedule around this band so as to minimize interruptions.

For India-US teams, for example, such bands typically would be in the range of 5:30 PM to 8:30 PM IST which corresponds to a convenient time for the US time (depending on the US time zones, of course) while not being inconvenient to the offshore team. With a time difference of 9.5 to 10.5 hours, depending upon the time change in the US, the band becomes a key enabler for communications.

On a related note, the practice of working "overnight" either by the onshore members or the offshore ones to maximize their common work time with non- collocated team members is uniformly harmful. This “solution” typically comes up in the context of looming milestones for code deliveries and impatience with the communication gaps during the related discussions.

But this practice soon puts the overnighters out of touch with their collocated colleagues and managers. The productivity during these off hours is generally much less than during the regular hours. We recommend using this practice rarely, if at all. The need for doing this generally indicates a weakness in other areas and should be addressed accordingly. The same is the case with staying late at work into the evening.

On occasion, there is a need for offshore members to be on call with the client personnel too. Such meetings are typically required when, for example, the testing team offshore needs access to a client' testing environment onshore and so some infrastructure-related discussions may be necessary. Another example would be the occasion when senior onshore members are on leave. In our experience, the clients have invariably helped in this area and have made themselves available during the standard band.

Scrum meetings in distributed settings are more like the conversations between a bench of people and the field players, to use a comparison with sports teams. On collocated teams, cross-communication among members in these meetings in a collocated setting is generally quite useful. In a distributed setting, since these meeting are held using conference calls, cross-communication among members may be confusing.

Over the phone, these meetings tend to degenerate into status-reading by the senior offshore manager/team lead and others remain mute spectators. Engaging everyone' active participation is that much more difficult. Care needs to be taken to actively ensure that each member talks about his/her area of the work. There is a need for more structure in these meetings. How much structure is sufficient without rendering the meetings into a high-ceremony event?

Placing a time limit on the meetings' duration, ensuring the discussions between any two persons (whether manager-to-manager or architect-to-designer) do not dominate the meeting, and finding a way to move from person to person (passing the "token") are some of the ways to address this challenge.

Of course, Scrum basics remain the same. Scrum meetings should be limited to a discussion on the status and should avoid getting into technical and functional discussions of issues. Generally, these Scrum meetings will end with identification of the need for follow-up discussions on technical and functional areas among the related team members. As pointed out, this is best done by designating a certain time band for these discussions. Unlike the Scrum meetings, these follow-up calls can be almost completely informal, save for the time limit aspects.

Upfront determination of templates–for key documents and other artifacts, related to exchange of clarifications, for example–is not necessarily high-ceremony overload. In a setting where most of the communication is phone-, messenger-, or email-based, this upfront determination works to alleviate the gaps to a large degree. Videoconferencing is good as a periodic communications mechanism to establish an initial "Hi." Over time, the tool can be a distraction and should be leveraged cautiously.

Periodic Visits to the Onshore Team by Offshore Team Members
Even with all the above, the difference between the perceptions of non-collocated teams tends to increase as the time progresses and given a certain duration, tends to become pronounced enough to be disruptive.

In our experience, this duration is around eight to 12 weeks. One would presume that this duration would be variable–initial low activity phases may seem to require less communication than the later high activity ones and hence a longer duration for noticeable communication divergence. However, the reality is to the contrary. Initial stages of a project may be low activity in the sense of participation by fewer members of the teams.

But these stages tend to be more communication-intensive since the emphasis is on transfer of critical business logic and requirements-related discussions. Later stages, while less focused on this type of exchange of information, have greater team participation and hence more communication channels. These effects tend to balance each other such that the critical duration seems to hover around the magic eight to 12 weeks throughout the project life cycle. This is the duration at which visits from offshore team to onshore will have the maximum positive effect.

In our experience, teams need a structured approach for periodic visits by the offshore members to the onshore location, to meet with the key onshore team members as well as the business users. The roles that need to visit must be carefully determined in view of the nature of the project. In general, though, the project manager, the offshore technical team lead (or designer point-person), and the test team lead are the main roles that must visit the client at suitable designated frequencies.

Depending on the nature of the project, the release manager may be another role that might add value to these visits. Facilitated by the onshore team members, offshore visitors tend to assimilate rather well and quickly into the overall project team. In our experience, cultural aspects have not been a negative factor during these visits.

Planned in advance, the budgetary impact of these visits is relatively low. Typically, less than one percent of the project budget is needed to fly key team members from the offshore to the onshore sites. There may be a need for onshore team members to visit the offshore teams–or example, when the onshore teams are engaging in a distributed team model for the first time. These visits go a long way in avoiding later interpersonal frustrations (e.g., "I can't understand how 'they' can mess up such a simple thing" that take so much of time to resolve later.

In this article, we have discussed how a Scrum process can successfully be applied in a distributed manner. Some key principles must be applied to cause a good chance for success. In the end, it comes down to the 3C#39;s: communicate, communicate, and communicate. From what we have seen and experienced, Thomas Friedman is right, the "World is Flat."

About the Authors
Steve Mahoney, CTO at CEI, has over 17 years experience working in all facets of the software development lifecycle and software/consulting company business processes. Steve has been with CEI since 1999.He leads strategic technology briefings, workshops and engagements for executives and he is responsible for architecture definition and scoping on professional services engagements and working with field-level strategic consultants.

Chuck Fredrick, CTO of Douglas County, CO Government. Chuck has 14+ years experience in Software Engineering, leading all functions of the software development process using a variety of development methodologies. Chuck joined Douglas County, CO government in January 2006, and serves as the Chief Technology Officer, where he has responsibility for Enterprise Architecture, Software Engineering, Quality Assurance, and technical strategy.

Sudhir Chanpuriya has over 14 years of experience in software projects across the full spectrum ofSDLC. He is currently working with CEI as a Senior Project Manager. Previously, Sudhir worked as Assistant General Manager (IT) for Reserve Bank of India, later moving on to project management positions in software services companies. He has extensive experience in managing small to large projects, especially those operating under geographically distributed model, using Agile as well as traditional methodologies.