Co-Located Teams are Basically an Unrealistic Dream

Matthew Caine Uncategorized 2 Comments

One of my favourite clients is the global digital communications department of a large engineering company.

The management, product owners, UX and project managers are all based at the company’s headquarters in Zurich, Switzerland. Whereas, the five development teams are all in Poland.

Clearly a department that consists of remote and virtual teams. Co-location, a so-called prerequisite of Agility, was not possible and in fact, this is the reality for most teams.

So, with this remote and virtual set of teams, over a period of time it became obvious that there were issues. The project managers began blaming the teams in Poland and the Polish teams blamed the product owners in Zurich.

As a result frustration started to rise. The planning meetings descended into farce and the review meetings often consisted of developers showing documentation and designs, as opposed to the functioning software. Thus frustrating the Product Owners, who the development teams blamed for their ills.

Slowly things got even worse. When critical production issues occurred it was often the low point. The Polish teams would claim that they were doing everything they could yet the Zurich teams remained highly frustrated with them. The Polish team started to ask for more plans yet the Zurich teams expected more engagement and the spiral continued downwards.

Clearly there were some fundamental issues.

There was little trust. There were serious “them-and-us” attitudes. The blame game was being played all the time. Knowledge was not being exchanged. And when one team could not be blamed they would blame it on the process. A “hero” culture also started to emerge, where individuals will take over to solve issues alone, rather as a team, ultimately leading to burn-out and little know-how transfer.

A Viscous Cycle

Some activists would claim that a well-executed retrospective would help. Clearly it would. But the level of trust was so low that in addition something tougher needed to be done.

So we brought together all the key players from Zürich and Poland (including our heroes).

Yes we ran a retrospective but those of you who are experienced, will recognise the usual patterns and groupings that emerged, namely: Communication, planning, process, lack of role XYZ etc

As written above we needed something more powerful to create our “ah-ha” moments that made the people sit back and realise that they were all responsible.

We needed some way to demonstrate clear lack of collaboration and communication.

So we needed to embarrass them.

It is Embarrassing

So this is what we did.

First we explained the responsibilities of the roles we had. For example ScrumMaster, Product Owner UX, Architect etc.

We then listed the projects that were being worked on, including the products in maintenance.

We then asked the team in Zürich to add the names of the people who they believed were fulfilling those roles on each project. We asked the same of the other teams from Poland.

The clever bit is that we asked them to do this at the same time without talking to each other and without exchanging opinion. Once the teams were ready they revealed who they thought were actively fulfilling those roles in each project at that moment in time.

Immediately, for everyone to see, it was clear that there were misunderstandings with regards to who was responsible for architecture and product ownership on more than one project.

We also saw where there were gaps and clearly the wrong person filling the roles.

However, there was worse.

In the room was a lady responsible for UX. In fact she was the only person doing UX. She was based in Zürich. Yet her name never appeared on any of the teams presented by Poland. It turned out that they didn’t know what she did.

At all.

But only by demonstrating these misunderstanding through their own efforts was it clear to the teams that there were real issues.

They could see it. They could understand it. It was transparent for all to see.

Communication Breakdown

So it was clear that due to the lack of a solid foundation of the roles and responsibilities and people assigned to those roles, that the rest was going to be shaky.

And so it proved.

There was very little proactive knowledge sharing. The teams were both guilty of withholding information. That information was not just about the work itself but also for example, planning details.

Although the teams often came together physically the sense of community after the event often collapsed rapidly into a “them-and-us”, finger-pointing and blaming relationship.

No Coffee Talk

There was little sense of community across the two geographical regions. Clearly there can be no coffee talk or water dispenser catch up or passing in the corridors. So each group of individuals did not know what the other was doing. Especially in their private lives or at the weekend or in the evening.

The sense of victimisation would rise as the finger pointing increased, and hero culture took over as those with the knowledge kept it for themselves so that they could become seen as the hero when they fixed the issue that only they could, funnily enough, fix.

Yet once the problems of roles and responsibilities were resolved and the people assigned correctly and transparently for all to see, the sense of belonging increased. There was more focus for each individual team to engage with only its team members. There was less reliance on heroes. And during later retrospectives the excuse of “process” became less and less profound. In fact their Agile skills started to increase as they gained trust in one another and saw their results.

In fact, the Agile process helped to maintain communication and thus a sense of community because it required frequent interaction.

All of this slowly resulted in things just getting done without management being involved to expedite decisions or actions.

This resulted in management having more time to focus on the long-term and strategic aims of the department. Which then resulted in more interesting work coming down to the teams.

Essentially the poisonous downward spiral had become a very interesting upward spiral.

And surely that is where we should all be heading, remote or not

What Next?

Want to Watch Our Online Training Videos?

We have over 1hr of video on this subject.

Want to Check Your Understanding?

Test your knowledge with our fun quiz

Need our Help?

Our half day workshops can help you solve your issues with this topic

Comments 2

  1. Good example. One point I didn’t get: title says “Co-Located Teams are Basically an Unrealistic Dream” so did you mix the teams after having that evidence or was it just enough by knowing each other better?

    1. Post

      Hi Stefan, thank you for your comment. Actually, I have a couple of examples, both of which were easier to implement after the teams realised they were communicating and collaborating like divorced couples (communicating a lot, but not at all collaborating) because they were not co-located.

      1) Here, 2 developers were at the vendor, but the testers and PO were at the client. So we moved our two developers to the client site for six months. Afterwards their testers came to our offices for six months. This helped both parties to understand one another’s cultures and helped each other to see and appreciate each other’s organisational weaknesses and challenges.
      2) The POs and project managers (yes, PMs!) were in Zurich the developers and testers in Krakow. Here there was no option to mix the teams. But knowing that they were not working well together helped. But occasionally both sides still needed to be reminded when “them-and-us” surfaced (which it did, every 3 months or so). It was then always good to replay back to the accusing team how they were behaving so that they realised they were also part of the problem.

      So basically, awareness is key. Once the teams get it, it can be used again and again as the anchor to re-adjust behaviour.

      Have I been able to answer your question? Let me know – thank you.

      Warmest regards

Leave a Reply

Your email address will not be published. Required fields are marked *