Laying the Foundation
How do you optimally arrange a distributed Agile team and put in place "best practices"? Agile teams are expected to function as self-organizing entities that find their own rhythm and flow within the constructs of the Agile process. However, a distributed environment requires more structure, management and rules to effectively work. Laying the foundation of your team structure and the rules of engagement is a difficult, but incredibly beneficial first step.
Establishing strong leadership both onshore and offshore is essential for success. Since communication turn-around times can reach up to 24 hours, a distributed Agile environment can't rely upon the standard structure of a single ScrumMaster (i.e., Coach) who leads and guides the team through the process. Within a distributed Agile environment, a manager should designate a "Facilitator" who locally leads the Stand-Ups (Daily Scrums), prevents outside interference and primarily "makes [Agile] work" (Schwaber, 2003). The "Facilitator" should be as experienced as a ScrumMaster or as an Agile technical lead and act as the proxy for the onshore ScrumMaster (or visa-versa where the ScrumMaster is offshore and the "Facilitator" is onshore). They will lead the local Stand-Ups, give guidance to the team and remove roadblocks. Just remember that we are not setting up two Agile teams, but rather one team with a designated onshore ScrumMaster and an offshore "Facilitator" who acts locally on behalf of the ScrumMaster. As Conway's Law states, "The interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it" (Brooks, 1995). Certainly a mouthful, but a notable gem of wisdom: if we treat the social structure of our Agile team as onshore and offshore, our work will negatively reflect this distribution. Instead of two teams marching to two beats, we must strive for one team marching to one beat.
While distance separates the ScrumMaster and the "Facilitator", they must work together to create a cohesive team by promoting communication. As the saying goes it is great to "put a name to the face," so if possible have the onshore and offshore teams initially co-locate. Time spent together is invaluable for learning colleagues' work style and building personal relationships. Schedule events where team members can socialize and build relationships (e.g., working lunches and after-work drinks). Taking the initiative to create strong interpersonal relationships in the early stages of a project is excellent for building a work environment that facilitates growth, efficiency, and self-organization; for example, by discovering the birthdays of all your team members and on their big day send them a birthday e-card or mention it during the Stand-Up. A simple gesture that can have a profound impact.
What is the proper length of an Iteration in a distributed Agile environment? Due to the distributed environment and potential communication issues, it is very important to obtain frequent Product Owner feedback so that the team can adjust and refocus as appropriate. On the one hand, shorter Iterations are conducive to frequent Product Owner feedback but require a greater time commitment due to frequent Planning and Demoing (possibly requiring longer hours for onshore and offshore members). On the other hand, longer Iterations reduce the time-commitment but can exasperate communications issues due to infrequent Product Owner feedback. A reasonable compromise is two-week or three-week Iterations where the team is asked to make at most a bi-weekly time sacrifice. In this way, communication chasms are discovered at worst tri-weekly (but hopefully are found sooner in the more frequent Stand-Up).
However, the time zone differences create a difficulty. No matter the length of the Iterations, when we have the Demo (Sprint Review), Planning and Estimation, and Retrospective with the Product Owner the onshore and offshore teams must be present to listen and to ask questions (by phone, WebEx, or video conference). Their presence and understanding is critical for the success of the Iteration and cannot be substituted with emails or post-meeting written summaries. Unfortunately, this requires the team to make a large time sacrifice once per Iteration by coming in either very early or very late to participate in the Planning, Demo and Retrospective. For example, if working with India with a possible time zone difference of 10 to 12 hours, the onshore team members will have to come in early and the offshore team members will need to stay late (switching the order every few Iterations).
Given the sacrifice the team is making, the manager must be sensitive to the time zone difference. One way to do so is by recognizing team's sacrifice and thanking the team members at the start and conclusion of the meeting. Also, make sure that the offshore team members have transportation to get home from the meeting, and schedule time for a dinner break. Once during a late night (for the offshore team) Demo/Iteration Planning session I ignored the clock and attempted to plow straight on through the agenda. Slowly but surely members of the offshore team started disappearing. I admittedly got a bit irritated and stated that we all need to focus to finish as soon as possible. An onshore member, who had previously worked at the offshore site, discretely took me aside to remind me of the late hour in India and that people were just stepping away to grab dinner and arrange for transportation home. Brought to my senses I apologized and took the lesson to heart.
Finally, while the team should jointly create the high-level feature point estimation with the Product Owner, the actual detailed engineering task breakdown (e.g., creation of Data Access Objects task) can be completed offline and communicated and reviewed via email or during the next Stand-Up. While this is not ideal, it allows a respite from the time commitment. Figure 2 illustrates an example of an onshore and offshore team's time commitment at the end of an Iteration.
The daily Stand-Up meetings should be face-to-face and happen, well, daily. Unfortunately with a distributed Agile team, daily Stand-Ups just aren't practical. During the initial Iteration, the onshore and offshore teams should have local Stand-Ups twice a week led by the ScrumMaster or the "Facilitator", respectively. Joint Stand-Ups (i.e., onshore and offshore present, typically via phone) should occur the other three days of the week, led only by the ScrumMaster. The Joint Stand-Ups will require the onshore and offshore to agree upon a common meeting time. Once a team's rhythm is established the frequency of the Joint Stand-Up meetings can be reduced down to bi-weekly. While we aren't utilizing the powerful communication tool of daily face-to-face Stand-Ups, with a system of partial local and partial Joint Daily Stand-Ups we will see a significant increase in communication with moderate personal sacrifice. Explore allowing flexible work hours, such as the offshore team starting their day at noon. I have had some of the younger team members prefer to work from noon until 8:00-9:00 PM (taking advantage of the active local party scene), but be sure you gain team buy-in before proceeding. Figure 1 illustrates the Joint Stand-Up time commitment (bi- or tri-weekly) where the offshore ends their day with the Stand-Up and the onshore begins their day with the Stand-Up.
The Conversation Cut-Off (Time-Boxing)
Cognition "of the clock" is critical to preventing team burnout. In the Agile process, preserving team members' personal time and quality of life are important. At critical junctures, the team will be required to make sacrifices, but keep those moments as the exception and not the rule. This means that the ScrumMaster should be observant of the team having too many early mornings or late night calls. Individuals, and by extension teams, have a natural desire to do the best they can and often members will slip into making themselves available at anytime and working longer hours to meet deadlines. A work-life balance is necessary for maintaining a high-functioning team. At all costs prevent a "Death March organization, which requires (or strongly encourages) employees to work extensive overtime week after week" (Shore & Warden, 2008). Death Marches may seem beneficial or necessary at first, but in the long run you are merely creating a self-imploding team.
Vigilantly monitor meeting conversations and ensure they do not run on, especially when you have joint meetings with onshore and offshore. Always ask yourself, "Does further discussion at this point bring us closer to a resolution or will it provide more information?" Time-box conversations by either making a decision based on what you currently know and revisiting only when new information presents itself or ask for a specific party to come back with a decision. Never leave the decision timeframe open; set a timeframe of a day or two. This is not only applicable for the Stand-Ups, but also for the Demos and Iteration Planning. If the business has an extended internal discussion in front of the whole team, politely, but firmly, ask the business get back to you within a reasonable timeframe. I have found that a way to help time-box is to setup an agenda with specific discussion times. For example, if the agenda states that the demo of the "Done" functionality is to take from 9:00 AM until 10:00 AM it is easy to say, "time check, we have 15 minutes left" or "time check, we are 15 minutes over and eating into the next section's allotted time." Figure 2 is an example of time-boxing with an agenda.
As a reminder, don't forget the sacrifices the team has made to attend the meeting. A heart felt "Thank You" accompanied by food and drinks go a long way. If within your power, give the team comp days (incentives should be team based). These small tokens of appreciation will earn the respect and gratitude of your team. I've even received a half page long "Thank You" email after giving the team a comp day -- and they were the ones doing the hard work!