pmStudent

Projects At Work just released a new report called “Distributed Agile Teams”.

The whole report is interesting but I want to focus on a particular question.

21. What is the greatest challenge of working with a distributed agile team?

“Poor Communication” was the biggest challenge by far. Go figure!

Now I’ll be the first to admit that co-located teams is an optimal situation if you can get it. There is nothing like face-to-face interaction between team members. At the same time, there are some strategies for dealing with distributed teams that I believe many teams are not taking advantage of.

There are two root causes cited in the study I want to discuss: cultural/language issues and tools issues.

Cross-Cultural Teams

I have experienced first-hand the frustration of assuming communication has been smooth with someone who does not have the same language as you for their first language, only to find out it wasn’t.

This is where I think several options are available to ensure understanding across the entire team. This isn’t really limited to cultural differences within a team, miscommunications and different interpretations happen all the time regardless.

Make It Objective

It’s important to make sure you are using some kind of documentation that makes it clear what is being delivered. Good software requirements work, user stories, use cases, behavior-driven development, etc.

Regardless of the project, I’ve seen requirements that can be interpreted 57 different ways, and those are not good requirements. If you had to have been there when they were written and be told what the intent was, they are not good requirements.
Something I’ve started looking into heavily for my domain is behavior-driven development. It’s sort of like what I’ve known as test-driven development in the past, but much more user-focused. I like it. Aside from being very focused on the end user, it also makes it pretty darn clear what the functionality of the system is supposed to be. There is very little room for interpretation.

Make It Visual

The best way to communicate a concept clearly is through visuals, in my opinion.

This is why I love the kanban board. The whole team can see what’s going on at any given time. There are many online options available for distributed teams.

A picture is worth a thousand words, and it’s true. A diagram can convey a level of understanding that you just can’t get from words alone. Even when speaking to one another about parts and pieces of a system, our hands wave about wildly to illustrate specific points. At some point one of us usually says “Let’s go find a whiteboard, this is going to be much better if we can draw it.”

Well you can do the same with virtual teams too. Screen sharing and whiteboard tools are everywhere, free and paid. For my team members who are offsite, I love to use the desktop screen sharing application while on the phone with them. Either of us can convey understanding and have in-depth discussions this way as if we were in the same room.

Sometimes, the desktop sharing actually makes it seem better than being in the same room. You don’t have to lean over someone else’s shoulder or stare at a projector screen. You have the other person’s desktop right there in front of you.

Independent Validation

Having someone else on the team independently validate the work of other team members after development is finished is critical.

Why?

Not only for quality. No, this really helps teams gel in my experience. They get to know how their team members work better. They share tips and advice. They encourage each other. You know you’ve reached a good spot with independent validation as a part of your teams’ culture when people start actively seeking review from each other. That means they truly value each other’s opinions and communication is going to be enhanced as a result. It needs to be really easy to pick up the phone and just talk!

Tools For Distributed Teams

I think there is a lot of reliance on the wrong kind of tools out there for distributed teams.  Task assignments shouldn’t be done through a software tool. In fact with something like kanban or some implementations of agile, it’s not even necessary. Self-organizing teams pull their own work out of the backlog.

Direct communication where possible is best, and so I really don’t believe in many of the tools out there today that get all whiz-bang about task assignments and capturing estimates in the tools, etc.

I’d rather have a simple kanban board, screen sharing software, a phone, and instant messaging. You can do time-boxed Agile just fine with a kanban board.

How do you think communication can be improved among distributed Agile teams?

A project manager was struggling deeply with his project.

He was doing everything he had been taught to manage projects effectively, and yet it seemed as if more time was being spent on rework and just getting things done.

A fellow colleague was doing well. Her projects were not only going well, but she and her team seemed much less stressed.

"I'm in trouble here, I need to know your secret. Can we chat?" he asked.

"Of course," she replied.

The struggling project manager laid out his problems, one after the other.

"I'm working my tail off, and so is my team. Yet every day is like putting out one fire after another. We are always re-working something because it wasn't what the customer really wanted. And all of our tasks seem to take so long, especially when I compare my team to yours. Heck, even updating a document seems to be a monumental effort. My team is very skilled, just as good as yours. What am I doing wrong?"

"You want to know what I think?" she asked.

"Yes! Tell me!" he replied with exasperation.

"You are focused on getting work done."

"Aaaaand? Isn't that what I am supposed to do, get things done?"

"No. That shouldn't be your goal. You should be adding value." she replied.

"Oh come on! What's the difference?" he whined.

"Work which does not add value is wasted, and non-valuable work usually ends up causing even more waste work. Stop looking at what your team is doing as a collection of tasks. Start questioning what is adding value from the customer's perspective. If it doesn't add value, why are you doing it?

Also, start seeking out waste and eliminating it. Time lags between steps on an individual feature or item is a form of waste. It takes your team longer to update documentation because they have to go back and remember what they did with their code in order to make the updates. The longer it takes for anything to go from initial design to being delivered to the customer, the more waste you incur and the less value your customer gets."

"I never thought of it that way" he said.

"Think about it. Observe your processes in action and you'll start to see what I mean. Well, I've got to run, but it's been nice talking with you." she said with a wave as she walked away.

He thought about her words for a moment. Immediately, his mind was inundated with examples from what his team had been doing just in the last week which fit her definition of waste perfectly.

"Oh crap" he thought. "We have got to do something about this. Now!"

I've realized something lately.

Or rather, been reminded of it.

Sub-Optimization Sucks

The only way to acheive a truely lean organization or even a lean project is for the entire value stream to be bought into lean thinking.

Because of this fact, senior leadership in any organization must be fully supportive and invested in moving an organization to lean and agile thinking and process.

My teams are gaining clear benefits from the methods we've implemented with Kanban. However, because we are the only teams running this way, the benefits are also very limited.

Blocked

For example, in some cases my team members need external validation from other teams before we can move a particular feature forward in the value stream.

When those external parties are not bought into lean thinking (single-piece flow, limited WIP, continous deployment) they can very quickly become a block, causing a bottleneck in the value stream.

Pushing For Change

So, I am trying to develop interest from the other teams we interface with. Who knows, maybe I'll be successful in 'converting' them. Perhaps not.

Even better, I'm formulating plans for a method of convincing senior leadership that for our next program, a lean/agile approach is superior to our waterfall SDLC.

We'll see.  Wish me luck.

"Do you know of any material, studies or other which covers agile project management but with geographically disparate participants. I have a couple of projects where this is difficult - design team in Bay Area, coders in Malaysia, China, India and Pakistan, customers/user reps across dozens of countries and project team in Singapore... timezones are killing me!"

In terms of Agile, I don't know of any training specifically for remote teams. 

I do have some personal experience with it though. I currently manage 2 teams of which some members are remotely located. 

I think Kanban does a lot for this scenario, primarily because it enables some self-organization that I think doesn't necessarily happen easily with something like straight forward scrum. The best thing is that you can use the kanban board even while not doing strict Kanban..and use it with any methodology, such as scrum or even waterfall. 

It allows my team to conduct our daily stand-up and update the kanban board - even when I'm not able to be there. And yet I am able to see what updates were made later and still have a good view of what is going on with each project. 

My recommendation to you would be to first learn about kanban if you don't already know much about it, then look into the many hosted electronic kanban boards for use on your teams. I personally love leankitkanban - but agilezen and others are very good too.