In my daily work as a consultant Agile Coach / Scrum Master and also a Scrum Trainer, I regularly get asked this one question: Can Distributed Scrum really work? Recently, I had the great pleasure to discuss this same topic with a group of highly respected Agile Coaches and Scrum Masters and the outcome of that discussion might just surprise you!

Outsourcing

Outsourcing some, or all, of a software companies requirements has been de rigueur for some years now. There have been many reasons for this but the one most often quoted, cost, is a very poor reason indeed. Companies driven to use outsourcing based on cost alone are more likely to commit the most common mistakes of outsourcing. Mistakes that can, and do, end up costing far more than using in-house developers.

The biggest mistake you can commit when outsourcing is a management style that I often hear referred to as “Over the wall”. This is where an organization, lets call them ‘Company A’, spends a great deal of time and effort writing a Requirements Document and then hands it off to ‘Company B’ who will do the work. ‘Company A’ then walks away and leaves ‘Company B’ to it.  At some point in the future, ‘Company B’ will provide ‘Company A’ with a product that matches the specification in the Requirements Document. Well, that’s the theory.

In practice, it rarely turns out this way. Requirements are unclear or misinterpreted. ‘Company A’ has little interest in supporting ‘Company B’ because they’ve already invested all their time up-front doing the Requirements Document and they’re paying ‘Company B’ to complete the contract, not waste time asking questions.

I could wax lyrical about the myriad problems that the approach causes but I think the doom spiral is clear to see. It shows why many outsourced contracts can be delivered late, with decreased functionality and poor quality. But can Scrum improve matters?

Scrum Primer Reminder

Before considering whether Scrum can help when outsourcing projects, here’s a quick reminder of the roles in Scrum (excerpts taken from the October 2011 edition of the Scrum Guide):

• Product Owner

  One person, not a committee. Responsible for maximizing the value of the product and the work of the Development Team. Sole person responsible for managing the Product Backlog. (which includes ensuring the Development Team understands items in the Product Backlog to the level needed).  For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

• Scrum Master

  The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

• Development Team

  The Development Team consists of professionals who do the work. Development Teams are structured and empowered by the organization to organize and manage their own work. Development Teams are cross-functional.

Scrum works well when team members are co-located. This is primarily because it makes communication easier and also because it’s easier to establish trust. Is it possible to get the same level of communication and trust when working with outsourced teams?

Distributed Scrum

In considering Distributed Scrum, the primary consideration tends to be how the Scrum team(s) get divided, if at all. There are a number of approaches but here are the main ones:

• Scrum Team outsourced. The entire Scrum Team is outsourced.
• Development outsourced. The Scrum Master and the Product Owner are located in-house.
• Development and Scrum Master outsourced. Just the Product Owner remains located in-house.
• Development and Product Owner outsourced. The Scrum Master remains located in-house.
• Product Owner and Scrum Master outsourced. The Development Team remain in-house.
• Development Team is partially outsourced.

These options were discussed with my fellow Agile Coaches and Scrum Masters. Here’s a summary of how our discussion went:

• Outsourcing the entire Scrum Team is the equivalent of “Over the wall” and so it was not considered further.
• Outsourcing the Product Owner was considered a very poor choice and, when considering what the Product Owners role is (see above), it’s easy to understand why. This removed a further two options from consideration.
• Outsourcing the Development Team seemed like a natural fit. However, outsourcing part of the Development Team seemed wrong. It would prove almost impossible for the Development Team to self-manage under these circumstances and would likely encourage an “us and them” culture, eroding trust. This latter option was not considered further.
• Outsourcing the Scrum Master raised some healthy debate but the consensus view was that it was Ok and actually advisable if the entire Development Team were outsourced.

We agreed that the best way to split a Scrum Team when outsourcing was for the Product Owner to remain in-house. The remainder of the Scrum Team (Scrum Master and Development Team) could then be outsourced.

Other Factors Affecting Distributed Scrum

It’s not just the geographic location of Scrum Team members that affects a successful outsourcing exercise. During further debate, and no little research after the meeting, it was considered that the following were also vital:

• Communication

  Using email on its own simply isn’t good enough. Invest in really good quality video and telephone connections. You’ll want as many of your meetings conducted via video as possible and yes – this definitely includes the Daily Standup. Also, you’ll need desk sharing tools so all participants can show what’s on their computer.

• Initial On-Site Visit

  Start the project off by inviting the entire outsourced team in-house, and have them go through one or two sprints with your in-house teams. This will forge bonds between the teams, build trust and make communication much easier when the outsourced teams return home.

• Regular Product Owner Visits

  When the outsourced team have returned home, maintain that all-important human contact by having the Product Owner visit the outsourced team regularly. By regularly, we mean every sprint, or perhaps every month. You get even more out of these visits if they’re timed to coincide with the Sprint Review, Sprint Retrospective and Sprint Planning meetings.

Don’t forget to factor in the cost of the above recommendations and remember that the video, telephone and desk sharing equipment costs need to be reflected both in-house and at the outsource location.

Conclusion

We concluded that Distributed Scrum certainly can work but, it requires more cost than initially meets the eye. As well as the additional financial outlay, it’s important to consider the extra effort demanded of the Product Owner and the extra challenges presented to successful communication.

These factors should be considered when comparing an in-house solution to an outsourced solution. If you are looking at an outsourced solution because you need to buy in technical skills that you cannot acquire locally, I strongly urge you to factor in the costs of the recommended approach. Failing to do so will make your Distributed Scrum far more challenging than it needs to be.