Developing and Nurturing Respect in Geographically Distributed Teams

Joseph, a tester, was reading an email from a developer in Germany. He exploded out of his chair, and ran to the product owner. “Those people have no respect for us! How can they ask us to do this?? Don't they realize what they are asking for? Don't they realize how many hours there are in a day? I'll give them a ‘simple request'. This is no simple request! This is way too difficult to do in this iteration. What is their problem?”

The product owner tried to appease Joseph. “You can't test that in this iteration?

“No, I can't. I'm the only tester on this team, which is the first problem. And, we all agreed what we were going to do in this iteration. You agreed on the acceptance criteria for this story. This demand for extra features is not respect for me, for the team, or for our agility. What is going on??”

How Does Your Team Handle New Requests?

This problem might happen to you or your team. Someone who is not local makes a request via email that seems reasonable to the requestor, but might not seem reasonable to the receiver.

There is a problem here. Right now, you don't have enough data to know what kind of a problem it is. First, let's start by learning some answers to these questions:

Is it new work? If so, how did the new work bypass the product owner?
Does the team have a common definition of done and does the work fit the definition of done? I wonder, based on Joseph's reaction to the request.
Is this team a real team with complementary skills, a common purpose, interdependent goals, and who make commitments about the work to each other?

Later, when Joseph was calm enough to investigate, the German developer had committed to someone outside the team. That is not acceptable on any project, and is disrespectful to the rest of the team members on an agile team.

I've seen this on teams new to agile approaches. In this case, the German developer may have felt caught between previous behavior that was expected (personal commitment) and new behavior that might not feel quite right to him yet (team commitment).

Consider How to Manage These Problems

If you see problems such as this on your agile team, start with the basics. Make sure your project has a project charter. Make sure your team agrees on what done means for the project and the iteration using release criteria, and for each story using acceptance criteria.

And, if someone outside the team wants to change any of that, everyone on the team learns how to say with a firm and gentle, “No,” followed by these ideas:

You can't change anyone on our team.
Once we plan for the iteration, we don't change it.
Stories have acceptance criteria and you can't change those stories or criteria.
Once we commit to an iteration, you can't change the release criteria.

And follow up with, “You can only do those things when we plan for the iteration.”

The people on the team might think the problem is about respect. It might be. It might not. Agile changes our behaviors. And sometimes, those behaviors are difficult to maintain.

It's not easy to build and maintain respect on a geographically distributed team.

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.