A Story of Communication

We had a pretty good offshore team! Our team members who have been on rotation to the remote site all came back very impressed. The offshore team was talented, knowledgeable, and smart. One had to wonder how come our client didn't think very highly of them!
During one sprint, our offshore team had signed up for a story that was prominent on the client's radar. They started by reviewing the story notes, huddling on the technical design, and coding away the solution.
Meanwhile, the client team was happily receiving updates during standup, and sending messages of support and encouragement.
Soon, the team started getting some feedback from the solution they implemented. The results weren't promising. It seems they were heading to a dead end. The team convened and decided on an alternate approach. Diligently, they started fixing the problems right away.
The fix took a longer than anticipated, but the team can now see the end in site. They doubled down their efforts to get the story done.
On another continent, the client was getting super nervous. The sprint was drawing to a close, and they still had a story in flight. It would look bad on their reports if we missed this story. They started inquiring whether we think we'll be done on time.
Our BA initiated many conversations with the offshore team. Trying to understand what's holding them back. The team explained where they are, and the message went back to the client: we'll get it done on time.
The team ended getting the story done in time, but with elevated levels of stress. They felt the client didn't allow them enough breathing room to get their tasks finished, and caused them to waste time and energy on useless meetings, instead of the needed focus on the task at hand.
The client, on the other hand, was displaying signs of loss of confidence, and even began to wonder whether the offshore team was incompetent.

What went wrong?
You may have concluded while reading this story that:

• The offshore team was not being transparent enough, by not sharing their status earlier with the client.
• The client wasn't proactive enough, by asking more probing questions.
• The offshore team was just trying to save face: why send a message of being late, while they could, soon enough, they believed, send the message: "we are done."
• The client wasn't supportive enough. They should have offered to help sooner.
• It's all because of cultural differences.

The answer is a little bit of all of the above. A direct consequence of working in a distributed setting is a lower quality of communication. None of us is perfect. We are bound to make mistakes, and something will always get lost in translation.

What's the way out?
It's easy enough to say "over-communicate," but that doesn't give enough guidance as to what we should do. Here are some concrete advice that may help:

• Build trust with the offshore team. Make sure you are seen as an ally. If the offshore team perceives they have lost your trust, they will be that much less likely to share potentially bad news.
• Seek opportunities for communication outside normal work sessions. It's amazing how much work related knowledge you can attain during a non-work setting. You get better context, better understanding of the team dynamics, and learn better ways to communicate fruitfully.
• Spend face time with the offshore team. Connections you build on a personal level will help immensely when you're physically present.
• At the same time, avoid at all cost attempting to micro-manage remotely. Not only you'll lose trust, you'll also slow the team down, introduce process friction, and become a bottleneck.

A better process flow in a distributed setting starts with building awareness of the situation. Start with the mindset that you are already losing information, and build mechanisms to counter.

How to Make Feature Teams Work for You

Let's say that I'm a CTO, and my IT program management is a mess. I can't allocate budget based on business priorities and company-wide initiatives. So I decide to unify all my IT force into a single pool of resources, and divide them into short-lived feature teams, formed around my current priorities. As my priorities change, I dissolve some teams and form others. And it is like a dream come true: now I can allocate my budget easily, have predictability into my spend, and avoid wasting money into projects that are not aligned with my goals. Or is it?

Let’s look at this a bit in detail. Feature teams will either work on existing assets, or develop new ones, and perhaps decommission old ones in the process. Now, what will be the state of these assets while feature teams work on delivering to their respective initiatives?

Consider the following analogy. Let's say that every one of my IT assets, be it an application or a backend service, is an airplane. Some teams are building new airplanes. Other teams are adding capabilities to existing airplanes. Some airplanes are in-flight, delivering business value. Some airplanes require more maintenance than others. But each one has its specialized flying instructions and maintenance procedures. Consider my feature teams to be the flying and maintenance crews. Based on my business priorities, I assign crews to airplanes; building new ones, adding capabilities to existing ones, or decommissioning and replacing some, or part thereof, with others, or parts thereof. All the while keeping all airplanes flying.

No, wait, who is keeping the airplanes flying? That is not a business imperative of any of the feature teams. An implicit assumption, maybe? Is there a separate maintenance crew to keep all airplanes flying? How are we going to ensure that that feature teams will respect the flying procedure of each airplane?

And how are we going to ensure that feature teams will not step on each other's toes? How do we ensure that the flying integrity of each airplane is not compromised?

If someone would tell me that this is similar to the model popularized by Spotify, then I would respectfully beg to differ. And in short, we can't simply wish for all the benefits of feature teams, while ignoring all the challenges above.

Let's agree on one thing first: I should be able to shift some of my budget and resources to respond to my current priorities. And at the same time, I should keep all my assets healthy, and all my airplanes in a perfect flying condition.

How can achieve both these goals?

It is imperative that I keep a focused, long lived team around every one of my assets. The size of this team will depend on the complexity of each asset. We can even have a team be responsible for multiple assets.
In addition to these asset teams, we can still have our feature teams. But if a feature team would like to modify an asset to deliver a business need, they will have to embed into, or extend, the core asset team. This extended team will have to work in harmony to preserve the integrity of the asset, ensure the compatibility of the new implementation with the existing architecture, and alignment with the long term goals for that asset. Any changes will need to be approved by the core team. If they need to change multiple assets, then they'll have to divide up, or work on one at a time. There could be multiple feature teams extending the same core team for one asset. If this is the case, or if there is an asset that undergoes continuous changes by multiple feature teams, consider expanding this asset's core team.

This way, you'll ensure that all your airplanes are in a sound flying condition, and that none will go crashing on you, because of the lack of maintenance, or because different crews trying to pull them in different directions.