Another
common question at my classes - "Our teams are distributed and remote. Can Scrum work for us?"
Before I answer that specific question, let me quote something recently that struck me -
When we're trying to make distributed work as well as co-located teams, why aren't the teams co-located? Is it to save money?
Henry Ford said that if he listened to what customers said they wanted, he would have given them faster horses. That's partly because customers will ask for what they think will solve their problem, but our job is to try to solve the problem. And if it's a complex problem, then our job is to plan on making multiple passes at a solution, evaluating the results each step of the way.
So, most of the time teams are distributed because they are outsourcing because management saw it as a strategic way to save money. Traditional management doesn't understand agile, how it works and how good it can be. It's often seen as a cost-cutting approach, as well. And you can imagine the frustration, and confusion, when management expects to add another layer of cost savings (agile) on top of outsourcing, when in actuality they are mostly in conflict. Perhaps a first step is to run an experiment with a team or teams fully co-located and measure their productivity.
Sadly, every time I've asked either how the company is measuring the cost savings, or how they even measure productivity of the teams, there's no answer. This might be a good opportunity to start.
As far as making your distributed team work. Did you ever have a long distance relationship? How well did that long-distance relationship work? For those whom it did work out for, what did they do? Most often they said, "This isn't working. We either move to the same city or call it quits." Okay, but in lieu of that, how much were you on the phone? How much did you visit each other?
Keep in mind, a lot of the following involve changing behavior, culture, how we work, opinions and raising the bar. Having said that small bit...
Best practices from a number of agile leaders from companies include:
- Most importantly, you must travel, at least yearly. Preferably quarterly. Both ways. One company measure the productivity increase at 50% after a 3 week visit by just a few people from the offshore team.
- Video chat. Given all the options and low cost, this should be a given. Have a webcam in all the meetings, and each team member should have one and ability for others to know when they're available. And get a good, hi def camera.
- Screen sharing. Expect developers to pull up the code with remote team members when discussing questions and issues. There are even people who pair program remotely most of the day.
- Collaborative design tools like Cacoo, and estimate together using planningpoker.com or everyone hitting the number key for their vote at the same time when conferencing.
- Dedicated desk or person place. Some teams keep a computer and webcam running for the remote person. If you need to talk, just walk over to them as if they were there.
- Rolling video cart with multi-account video chat and large flat screen to have others join your team's meeting where ever it is. Cheaper than you think to build one yourself, and there are sites out there that provide the specs and how-to.
- You must have the all the meetings together, as much as possible. To show respect for the other team members, alternate who (onshore or offshore) has to be joining at odd hours.
