Managing Product Development

In their  comments to my post, Agile and Remote People: Part 1, Telecommuting, Matt, Lisa, Pete, Abby all had great rebuttals. They successfully make their remote teams work. They have successfully built trust. They use a variety of communications tools that allow their team members to work together.

Good for them. (I mean it. I am not being sarcastic. I’ll let you know when I am.)

Matt, in my conversation with him, and Lisa in her post, both mention open IRC chats. Some teams I’ve worked with have open Skype windows all the time. Matt says that people are supposed to answer their emails in 5 minutes–that’s the expectation about responsiveness.

Maybe I’m just too old for this. Maybe I have a short attention span. Maybe I have ADHD. I can ignore a low-pitched buzz of activity around me, as in a team room. I can’t ignore icons bouncing on my dock. I interrupt whatever I’m doing to service those interruptions. I would not be successful with the tools and operating agreements that Matt and Lisa discuss. (I didn’t talk to Abby either. Sorry, ladies.)

On the other hand, I don’t think I’m that unusual. I suspect a significant portion of the people in the field can’t deal with visual interruptions, even though they can filter out sound interruptions.

Aside from technology allowing people to work together across the space-time contiuum, what would have to be true for the team? What would the team look like? Here’s what I’ve seen (more on that later), and what Matt described:

1. A high degree of trust among the team members. Matt doesn’t even participate in iteration planning or estimation meetings.
2. A high degree of flexibility in how to complete work.
3. Agreement on what done means, for each task, user story, iteration, release.
4. Commitment to each other about the work. (Yes, I know this is vague. I don’t know how to be more specific yet.)
5. I am sure there other characteristics of the team and I don’t know what they are.

The reason it’s important to think about what characteristics of a team could make true geographically dispersed agile possible, is because it’s so difficult to do well. I worked with two teams. Their velocity was noticeably lower when they were remote, and remarkably higher when they worked together. Same people, same project, different outcomes when they worked together and when they worked apart. Looking back, they did not have strong enough commitments to each other when they were apart. They easily turned their attention to another task, when another team member had a request. Their most common complaint was “I can’t finish anything when I’m not at work.”

Maybe their stories were too big (probably). Maybe their estimates were too far off. Maybe they didn’t know how to work as several people swarming around a feature when they were remote. But I can tell you that their velocity was significantly lower when they were apart than when they were together.

So, for those of you who are considering an agile remote team, especially where everyone is remote, please think long and hard about whether you have the experience, the individual, and team capability to do this. I believe my commenters, when they said they made it work for them. And, I have hard data from clients (no, I can’t share it, that would be a violation of my NDAs) that they can’t make it work.

Tweet This Post

A twitter follower was concerned with a piece of my post, Do What’s Effective For You, when I spoke of team bits. Was I saying you could not telecommute and do agile?

First, let me explain what a team bit is. A team bit is a person or a group of people grouped by geography and functional specialty. I see this most often where testers are remote from the developers. The worst occurrence is when there is a single tester separated by many time zones and understanding from the product developers (developers, product owner, business analysts, anyone who can explain how the product is supposed to work.) A team bit is always remote from the rest of the team. A team bit has no one to talk to on-site. A team bit is out of time sync with the rest of the team. There is no way for this bit to build trust with the rest of the team.

In my experience, team bits don’t work. They don’t work well for agile, although the problem becomes transparent. Team bits don’t work well for any other lifecycle, but you might not be able to tell. George Dinwiddie is collecting data at StudiesofColocation.

So, where does that leave us for telecommuters? If the people only telecommute one or two days a week and the iteration is at least two weeks long, and if everyone telecommutes on the same day, overall velocity will likely slow down, unless the team is ultra-high performing. Of course, if it’s just one day a week, you might not be able to tell. If it’s just two days a week, you might live with a slight velocity reduction in exchange for happier people.

If that’s what you mean by telecommuting, agile and telecommuting can work. But you have to limit the the number of days per iteration. Otherwise, the reduction in velocity is palpable.

The next post in this series will be about remote feature-based teams.

Tweet This Post

I have an article on Computerworld.com, Three Tips to Managing Across the Globe. Please leave comments here (because you can’t leave comments there.)

Tweet This Post

If you’re like me, you work with people all over the world, never mind all over the country. I generally ask, “When is a good time to call?” before I call someone. However, some people don’t remember to ask. Or, they may remember to ask, but then forget to think about the time when they pick up the phone.

This morning, I was abruptly awoken when someone called me at 5am local time. It was 8am their time.

They were right to call. We could not have handled the problem over email. However, they still had to wait until my brain caught up with my voice. Thank goodness we don’t have video phones.

The phone has substantive bandwidth to discuss complex problems. So use it. Just remember to ask what time is good to call :-)

Tweet This Post