Distributed? Yes. Alone? No.

Distributed? Yes. Alone? No.

As I've sent these Pragmatic Managers about geographically distributed teams and received these responses from many of you, I keep hearing one theme: “I thought I was the only one dealing with this issue.”

You are not alone.

Many of you have sent emails and asked questions. I answered those privately, but here, I'll repeat a few of those questions and answer them.

Question 1: “How do we maintain the high level of communication that is the very spirit of agile?”

Answer: Build in infrastructure and set an example. If you are too many time zones away, you are not going to have high levels of communication. You are going to have handoffs. Where you do have the possibility of real-time communication, you need Instant Messaging among team members, an inexpensive and high-availability phone, and real-time High Definition video available that works. No scrimping on infrastructure.

And, if you are the one person who knows that agile requires constant communication, set the example. Initiate conversations, ask questions, be visible (even at a distance). Help people see they can swarm around a feature. This is one of the reasons I like kanban so much for a distributed team—it shows them visually that they must limit their work-in-progress.

Question 2: “How do I get other developers involved in the discussion?”

Several of you asked this question. When I probed, you were managers and Scrum Masters. This is a Bad Idea.

As a manager, you have title-based authority, you hold the purse strings, you probably conduct performance reviews, and you want people to think of you as an equal member of the team.

They won't. The other developers will defer to you. Well, unless they are me. Thank goodness they are not me. Most people have more self-preservation in the organization than I do. You are asking people to behave as if you are peers, but you are not a peer. I've written about this before. (See Functional Managers Acting as Scrum Masters: Not a Good Idea.)

Facilitation Guidelines

For those of you are not managers, here are some facilitation guidelines:

  1. Let people know in advance what you want to talk about. That way they have time to think in advance.
  2. During the conversation, let them think. Not all conversation happens out loud. Some people think in their heads. Those people are called introverts. Software development is full of them.
  3. Remember the Rule of Three: If you don't have three options for a solution to a problem, you don't understand it well enough yet. You might need to explore it more. Maybe it's time to spike instead of talk.

By the way, this works for testers and writers and UI designers, not just developers.

Most teams are not collocated—they are distributed. You are not alone. Together, we can get this right.

Related 2012 Newsletters

I wrote these newsletters in preparation for a workshop Shane Hastie and I delivered in 2012. That was a tremendous success and led to my work with Mark Kilby on From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver.

The newsletter series:

Useful Links

Johanna
Vol 9, #11

© 2012 Johanna Rothman

Leave a Reply

Scroll to Top