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??”
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 complimentary skills, a common purpose, interdepent 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. If this team has recently transitioned to agile, 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).
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, you can't change anyone on our team. You can't change what we do in the iteration. You can't change the acceptance criteria for a story. You can't change the release criteria inside the iteration. When we do iteration planning, then things are up for grabs, but not during 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. If you are not sure how to do this, and want to try, participate in our workshop, April 17-18. You won't regret it.
Registration is $1600 per person. Bring a team and receive a generous discount. If you are not sure, sign up and listen to our webinar about geographically distributed teams.
Johanna Travels the World!
I am delivering a number of public workshops this spring. Please do sign up and join me. Registration is limited–first come, first serve.
May 8-9, Manage Your Project Portfolio, Sao Paulo, Brazil. This is the full two-day workshop, in English.
May 28-29 Transitioning to Agile, Stockholm, Sweden. If you want to experience an agile project, learn how to transition and maintain your agility, please join me in this workshop.
May 30, Agile Project Portfolio Management, Stockholm, Sweden. This is a special one-day version of my project portfolio workshop.
I hope to see you at one of these workshops.