Scrum with Distributed Teams and Outsourcing 

Outsourcing is a very popular and profitable way of augmenting the work force. It worked with relative level of success using waterfall methodology, however the out-sourcing model fails in a Scrum implementation.

Why is that?

One of the core tenets of Scrum is a co-located, self-organizing and self-managing teams. How do you ensure a high performing self organizing and managing team when the members are geographically separated and have never met each other face to face?

At the heart of it outsourcing is cost saving function. Waterfall with its centralized management made it easier to move a function (Quality Assurance or Testing) of project delivery to a separate country or location. This will not work in Scrum team scenario.

Current State of Outsourcing in Agile 

Here are four models I have seen in outsourcing with organizations attempting distributed Scrum.

1. The testing team is off shore and the coding happens onshore
2. Development is onshore (NYC), testing offshore (Bangalore) and the scrum master in London. Logic being the ScrumMaster would have time overlap with both team to “manage” them.
3. Team members are peppered all of the globe i.e. coders in US and Ukraine, one UI in Canada and the testing happening in India.
4. Whole team is in one country but members are distributed all over the world.

Do you see any problem in successfully leveraging the Scrum Framework in any of these scenarios?

Here is the problem with these attempts of doing Scrum for distributed teams.

Scenario A

1. The team will find it hard if not almost impossible to function as a self-organizing team. The team dynamics and communication will be fragmented. The dominant team will be the client (team with the budget) and the offshore team will be “told what to work on”
2. Depending on the time difference between the two geographies there is never a good time to have meetings.
   1. During the “Scrum Planning Meeting” the off-shore team generally relegates the planning to the onshore team with the intent that the will “tell us what we should work on”. Same thing happens for the Product Backlog Refinement meeting.
   2. Daily Standup can be a sore point on which team starts the day early or which team stays late. The compromise being we will email out daily status to the ScrumMaster who can update the team.

Scenario B

1. This is nothing but waterfall with an Agile lipstick. The ScrumMaster is acting as the Project Manager and is acting a a go between the two teams.
2. There are two distinct teams with low level of expectation of being self organizing and self managing

Scenario C

1. This is a common scenario for a lot of organizations (even if all team members are in one location, people may be working from home).  Again, the team will struggle to be a self organizing and self managing team.
2. The efficacy of communication amongst the team will not be the most efficient, requiring the ScrumMaster to step in as a pseudo manager.

Scenario D

1. If the team is in the same city, I would strongly suggest all team members at least meet face to face for the Sprint Planning, Sprint Retrospective and Sprint Review Meetings (all three meetings can be accomplished on the same day for a two-week sprint if the schedule is planned properly). Also, I would recommend the team meet at least once a week for the Product Backlog Refinement meeting.
2. In case the team members are not in the same city but in a time zone overlap, nario I will suggest that voice video be the prime mode of communication.

Bottom line, is that all these are half way measures to use Scrum given the organizational reality. Any Agile implementation requires the realignment and refocus of organization to leverage the benefits of the methodology or Framework.

Before embarking on an Agile implementation, the organization leadership should understand core values and principles of Agile as well as be cognizant of their responsibilities to make it successful within the organization.

This includes

• Changing their mindset on how the organization will operate and deliver project.
• Fostering trust between the team and the organization.
• Empowering not only the Product Owner but also the teams
• The Scrum Masters should have direct access to decision makers
• Have an overall plan to move away from silo’ed skillsets to a full stack developer environment.
• The organization should leverage technology not only in tracking their progress but also for their communications, i.e. voice video.

The hardest thing in Agile implementation is the change of attitude and change of culture within the organization. This is where an empowered knowledgeable ScrumMaster or a Coach will really help an organization.

To learn more click here for the Certified ScrumMaster Workshop