One solution is to start with 2-week Sprints, and focus initially on mastering the ability to deliver increments of potentially shippable product (possibly very small ones) by the end of a Sprint. A number of Sprints' worth of inspect-and-adapt may be required for the team to achieve this, but once they have succeeded, they can shift to a longer Sprint length, and be able to deliver larger, more satisfying increments of functionality.
If the Product Owner is in one location and the team is in the other, the ScrumMaster should be located where the team is. While an onshore ScrumMaster may be able to help an offshore team with some types of issues, he or she will unfortunately be entirely absent from the realities of the team's day-to-day worklife, and thus they will be far less useful to the team. The critical ScrumMaster duties of coaching the team, helping remove impediments, and protecting the team from disruption will essentially be absent if the ScrumMaster is located far from the team.
If the team itself is divided between multiple locations, there should be a primary ScrumMaster designated for the team overall, but it will probably be helpful for each location to have a team-member playing the role of "local" ScrumMaster during that location's working hours.
To begin with, team members will typically need to spend periods of time working side-by-side with each other, especially at the beginning of the project. An excellent practice is for the team to be colocated for the entire first Sprint of the project, and ideally the first two or three Sprints. This allows the individual developers to build working relationships with each other, as well as trust and visibility into each others' skills, strengths and weaknesses. In addition, the team will develop a set of working agreements and set standards for their "definition of done," quality, coding conventions and other development practices, tools, escalation, overlapping work hours, and other necessities.
In addition to colocating the team for the first Sprint or more, the distributed teams that succeed with Scrum typically have some sort of "ambassadorship" practice, where team-members are constantly traveling to the other location for periods of time working side-by-side with their distant colleagues. When these "ambassadors" return home, they bring with them knowledge and values that will inform the work of their local colleagues, and they will also be able to function as points of contact for their remote colleagues when issues arise. This ambassadorship is ideally a continuous practice, with one team member placed at the other location at all times, in rotation.
The immediate objection to this constant travel is "it will cost money and time!" The simple response: Yes, but it is cheaper than the alternative, which is getting much less business value from the project. Without face-to-face contact and high-quality working relationships, the team will produce either less software, lower quality software, or functionality that's less right for the customer needs – or all three. A team of 6 developers with a generous travel budget will probably produce much more business value than a team of 7 developers with no travel budget.
A common dysfunction when the team itself is split between two locations and are not properly bonded is that "one team" actually operates as two teams. Team-members may form "cliques" by location, and miscommunication or miscoordination between the locations may give rise to mistrust and conflict. It is also possible that if a portion of the team is located onshore, they will be in closer communication with the Product Owner, and as a result they will have an information advantage over the offshore developers. While one would hope that this could benefit the entire team, it can sometimes do the opposite, driving a wedge between the two groups of developers, with the offshore group being seen by onshore as clueless and always a step behind, and the onshore group being seen by offshore as hoarding knowledge and looking out only for themselves.
Rather than trying to work as a single team, it may be more effective to form into separate Scrum teams, one per location, and as loosely coupled with each other as possible. Each team should be fully cross-functional, and should be responsible for producing entire pieces of functionality, not simply doing a particular activity (coding, testing, etc.).
For teams that are split between multiple locations, it is very important that all team members have the same development environment (same IDE's, plug-ins, code quality checking configurations, etc.), and work on shared DTAP (Development Test Acceptance and Production) servers; this removes ambiguities and reduces problems caused by inconsistencies between the locations.
As is true for colocated Scrum teams, the practice of Continuous Integration is extremely helpful. In Continuous Integration, new or changed code is integrated early and often; commits trigger an automated build-and-test cycle, allowing integration problems to be detected and corrected immediately. By doing this frequently and with small increments of change, problems can be found when they are smaller and more manageable, so less time overall is spent in the finding-and-fixing activities. It is important of course to have the discipline to immediately resolve the issues, and many teams agree on conventions, such as "you can't leave the office with a bad build unfixed"; the last thing the developers on the other side of the globe want is to start their day with this problem. Continuous Integration also enables a less rigid and more emergent approach to defining and building interfaces; with more confidence in their ability to find and fix problems quickly, teams can be more dynamic in the way they work, and work together more smoothly.
It is important that the required knowledge, capabilities, and skill levels are evenly distributed across both locations; an imbalance will possibly result in less value produced each Sprint. For example, having senior architects and designers onshore and junior developers offshore will likely result in a lot less software being produced, and a much more dysfunctional relationship between the two locations, than if a more experienced team was recruited offshore. In the event there are skills or capabilities which cannot be shared across both locations, this should be made clear and visible to all stakeholders as a possible impediment.
When deciding who works on what during a Sprint, it's important that team members from one side not take all the work in a particular area on a regular basis; for example, onshore team members always taking UI tasks, while offshore team members always working on back-end services. While this may sound like a simpler approach initially, it generally results in silos that undermine the "shared responsibility and ownership" mindset of the team.
When the team is physically split, real-time communication tools becomes critically important. At a minimum, teams require the following:
- Instant Messaging client (not only for communication and easy transfer of text, but also for indicating their presence online to other team members)
- Comfortable, high-quality headset and VOIP client, to make conversations with remote team-mates quick, easy, and free (with "always on" as an option)
- Webcam and Skype, for instant videoconferencing
- Shared digital whiteboard, for design and architecture discussions
- Desktop sharing solution (for example, a VNC client)
- Team wiki (with not only project details but also personal info about each team member)
- Shared bug tracker
- Team calendar, showing release dates, Sprint dates, local holidays, and vacation plans
- Team mailing list, to which all key emails are cc:ed.
- Build status alerting device (such as Nabaztag) at all distributed locations
(The upcoming Scrum Technical Practices Primer will provide more in-depth explanation and guidance around the tools, practices, and techniques referenced in this section.)
One approach that can help is to split the longest of the meetings – Sprint Planning – into 3 shorter sessions over the span of two days, as follows:
- Sprint Planning Part 1 - (1 hour timeboxed) - Weds 8am New York / 6:30pm India. Product Owner walks the team through the items at the top of the Product Backlog, team asks questions, clarifies their understanding, and make suggestions.
- Sprint Planning Part 2a - (2-3 hours) - Thurs India workday hours. Team starts doing an initial analysis, task breakdown, and estimation of the items at the top of the Product Backlog. They come up with a list of questions for the Product Owner.
- Sprint Planning Part 2b - (1 hour timeboxed) - Thurs 8am New York / 6:30pm India. Team and Product Owner discuss the team's open questions, and the team decides their commitment for the Sprint
- Work begins - Friday India workday hours.
On the days when the team will be staying late for the evening meetings, it is important that they maintain a reasonable workday by coming into the office later in the day than they would normally; a recurring schedule of 12-hour days will very quickly start to exhaust the team, and cause productivity and morale to drop, and mistake rates to go up.
Sprint Planning part 2 is typically also be used for design discussions, to review of major component changes, and other issues. This allows everyone to express their thoughts, and also helps in establishing a clearer vision for the implementation, which should result in more consistent quality from everyone.
Lastly, many teams find it very helpful to budget a generous amount of time during the Sprint for doing Product Backlog Refinement (aka Grooming) with the Product Owner. Together, they look ahead to upcoming Product Backlog items, gain a clearer understanding of them, split larger Product Backlog items in smaller pieces, and prepare them to be considered in the next Sprint Planning meeting; the more time spent on these activities, the more easily and quickly the next Sprint Planning will go.
If the team itself is in different locations, the ideal is to hold the Daily Scrum Meeting live via webcam each day, at a working hour that overlaps for both teams; this is feasible between Europe and India, or West Coast USA and China. If there is no working hour that overlaps, here are several options to try:
- Hold the Daily Scrum meeting live via webcam or conference call each day at an hour that is inconvenient for one side or the other. It is very important to rotate the burden of the inconvenience from one side to the other every week or two. The main downside of this approach is the daily outside-regular-work-hours for one part of the team; this will likely add stress, hurt morale, and reduce productivity over time. If this option is chosen, be mindful of different cultures' meal-schedules; for example, in the US, it is common to eat dinner around 7 or 8pm, while in India, it is more typical for dinner to take place at 9 or 10pm.)
- Hold the Daily Scrum meeting live in each location at a time that's convenient for that location, but have one team member write a summary of the updates, and email them to a team-member in the other location, to read aloud at the start of their Daily Scrum meeting.
- Hold the Daily Scrum meeting using recorded reports. The team members in each location will do their Daily Scrum meeting at a time that is convenient for them. At the start of the meeting, they will use a cameraphone to record video of their updates, and the video will be emailed to the teammates in the other time zone, and played at their next Daily Scrum meeting. Repeat in reverse.
It is very important that the Sprint Review be planned for a time when the entire team – including all onshore and offshore members – can participate together. All members of the team should feel like full participants in the Sprint Review, and should be able to hear first-hand the comments about has been produced, share their own opinions, and join in the discussion. Ideally, the demoing of the new functionality should be done by team members from both the onshore and offshore locations. Having the onshore team demo everything can often create negative feelings for the offshore team members, who may feel like they're not receiving recognition for their work or are being treated like "second-class" team-members.
As in colocated Scrum projects, the Retrospective should include the Product Owner; many dysfunctions will play out between the Product Owner and the team, and excluding the Product Owner from the Retrospective will significantly hinder improvement. In addition, it's very important for the Retrospective to be visual (via videoconference); the subtle cues of facial expression and body language become even more important in difficult conversations.
With distributed Scrum teams, aim to share a common vision and break the work into small packages that are easier to inspect and adapt, thus reducing confusion and finding misunderstandings sooner. Product Backlog Items should be short and easy to understand, with clear conditions of satisfaction attached. Pictures in the form of sketches, diagrams and simple mockups can convey a lot of information quickly. While User Stories are a popular and effective format for articulating Product Backlog items, lightweight use cases can also work well. Some teams find that having a demo server where the Product Owner can review functionality on a daily basis can help keep everyone in sync and aligned, and surface misunderstandings sooner.
There are difference approaches to managing the various Scrum artifacts. If the team is colocated, and the Product Owner is in a different location, paper may still be the best choice for the Sprint artifacts (for example, the Sprint Backlog and Sprint Burndown Chart used by the team to manage their work during the Sprint), but some type of electronic tool may be necessary for storing the Product Backlog; for example, using a Wiki or a Google docs spreadsheet may be a simple, very low-cost solution. If the team itself is distributed, or if multiple teams in different locations are working together, a more elaborate electronic Scrum information tool will likely be necessary. In every case, though, the thinking should be driven by the dictum "try the simplest thing that could possibly work, and inspect and adapt". For example, many teams find it helpful to document their agreements with the Product Owner (for example, from a conference call) with some type of written confirmation. A fast, simple way to do this would be to send the Product Owner an email with the subject line "agreements – conf call – aug 11," with a very brief, bullet-pointed list in the body; the email would be cc:ed to a team blog, so everyone could refer back to it.
The first is enabling and encouraging informal, lateral communication between members of different teams. This is often overlooked, but it is one of the most powerful tools for day-to-day effectiveness. When a team or team-member is blocked by another team, their first step should be to reach out to someone on that team, and this should be made as easy as possible. There should be a project-wide Wiki set up, that everyone on the project has access to. Under each team is listed team-member contact info (including email but also IM, VOIP and mobile phone numbers, plus typical working hours and urgent question contact hours translated into the various teams' timezones) as well their particular domains or areas of expertise.
The second technique is Scrum of Scrums. This is a practice where a representative of each team (selected by their team-mates) meets with the other teams' representatives on a regular schedule (typically 2-3 times per week, but it could be daily if necessary) to update each other on progress, surface and resolve inter-team blocks and dependencies, make cross-team technical decisions, and otherwise provide a forum for cross-project visibility and impediment resolution. When teams are in significantly different timezones, it is important that the Scrum of Scrums meeting time be rotated, so that the pain of late-night calls is shared among all the participants; having a subset of the group perpetually more inconvenienced than others can breed resentment that will often start to manifest in other kinds of dysfunction.
The third technique is to establish cross-geographic "communities of practice," to enable team members with particular specialties (for example, architecture) to work across team boundaries and together guide the overall direction and evolution of the project. These groups inspect and adapt to find the right composition and meeting frequency.