How you can maintain shared context and flow with a distributed team

It can be hard to maintain shared context with a distributed team, and people often give up. But it is possible. With remote working becoming the norm, some teams may have struggled to adapt. This article outlines how one team at Adaptive has navigated this and:

• Overcame the challenges of delivering to a startup and their first client
• Solved the challenges through:
  • Improving the delivery process
  • Maximizing the use of tools such as shared story maps and virtual whiteboards
• Benefited from:
  • Enhanced clarity and shared understanding
  • More predictable delivery
  • An efficient. focused and happy team
• Satisfied the startup client.

The project – setting the scene

This is the story of our experience working with a startup, and their first client. The delivery team had members in Barcelona and London. As for the startup client’s product owner, he was London-based. This combination presented a number of challenges.

Challenges

Delivering to a startup

Having consulted to a few startups, all have had a few things in common. They have demanding visionaries and need coaching on what a sustainable development process looks like. A recurring challenge is guiding them towards iterative delivery. This startup in particular, was seeking thought leadership and technical expertise to deliver a world-class product at scale.

Working with a distributed team

A non-co-located team made it hard to align on the vision. It also made it difficult to build team cohesion. A London-based product owner meant challenges for the Barcelona team. They received information second hand causing gaps in clarity. The alignment of the product with the vision suffered as a result.

Serving multiple product owners

Delivery for a single product owner is hard enough. Delivering to a startup’s first client added further complexity. The end client became more involved in shaping the product vision. This started to cause a clash of priorities between the two parties. On one hand the startup’s vision extended to features beyond their first client’s needs. On the other, the end client’s features focused only on their users. The startup began to feel that the focus on the short term was holding them back. The challenge became balancing the future with the end client’s priorities.

Turning things around

It is important to note our team had first enjoyed several key successes. These included a proof of concept phase, and a round of hardening. These resulted in extending the startup’s runway.

One of the team’s strengths was its commitment to continuous improvement. Despite early success, we continued to find areas for improvement. Over a six-month period, we introduced several solutions. These aimed to improve how the team worked, and included a fresh way to plan with key stakeholders.

Solutions

Separate demos to the startup and the end client

During a demo, the team got caught in the middle of conflicting priorities. The end client voiced criticism to the team, who didn’t define those priorities. This highlighted the need for a separate demo. That way, the startup could own their priority choices in front of their client.

Review priorities with the end client

The startup and their end client had challenges with maintaining a dialogue. That was the suspected cause for the situation described above. So we introduced a review meeting for the key stakeholders to clarify and agree priorities prior to development.

Having separate boards for product and development

The team had been working in Kanban fashion. Although this worked for a time, product complexity and growth in the team’s size changed that. This spawned the creation of separate boards for both product and development. Having these boards allowed distinct tracking of new and current features. This encouraged the product team to focus on defining what came next. Moreover, it let the development team concentrate on delivery.

Product Board

Stages: To Analyse/Design > Context-sharing Workshop > Process Storming > Designing > Analysing/Story Refinement > Ready for Review

Development board

Stages: Ready for Dev > Blocked > Re-Opened > In Progress > Ready for Testing > In Testing > Testing Passed > Done

For our boards, we use JIRA by Atlassian

Introducing a shared story map

Having a product board was great at tracking what needed to get done. The development board was effective at showing what is in flight. Yet there was something missing. It was hard for the team to see how features related to each other.

The team and startup both had access to the story map. It became the primary tool used for sprint planning. It mapped dependencies and showed a four-week development horizon. We found that the story map was crucial for maintaining shared context during development.

For our story maps, we use draw.io

Context-sharing workshops and virtual whiteboards

We introduced a context-sharing workshop involving the startup. Their product owner explained the business context behind a feature. And a key member of each team (developer, business analyst, tester) listened in. A business analyst led the meeting using a virtual whiteboard. They used a feature canvas to align on what was being built, why we were building it, and how the feature might be used.

For our virtual whiteboard and feature canvas, we use Miro.

The results are in

It’s important to recognise that each project and team is unique. Adaptive’s thinking is that there is no silver bullet nor one-size-fits-all approach. We believe it is up to the team whether they use a tool/method or not. Since each project context differs, results may vary. That said, numerous Adaptive projects have applied the tools mentioned above. They have each been tried and tested in real-world projects.

Given the starting point, the results showed significant improvement. We’ll next take a look at a few of the quantitative and qualitative outcomes.

Results

Clarity of vision and shared context

Context-sharing workshops have been crucial to improving clarity of the vision. Having each team member be present ensured an even spread of first-hand knowledge. Another massive boon was the use of a virtual whiteboard. Using these has really eased the transition to remote working. It helped everyone be on the same page with regard to features.

Maintaining shared context for scope was just as important as it was for features. With multiple feature team squads, it was easy to get lost in the JIRA board. Having a shared story map helped the team know where their piece of the puzzle fit. At meetings, it assisted with anchoring the context and goal of the meeting.

Requirements clarity

Context workshops helped the team create a virtuous circle. They involved the client product owner more in validating spikes. The team met as many times as needed to ensure requirements were ready to be picked up by a developer. And discussions using the “three amigo*” approach helped align the team. This resulted in:

– Producing higher quality requirements
– Less effort clarifying user stories
– Less rework
– Quicker value generation
– More frequent feedback cycles

* the “three amigos” approach consists of having three people with different perspectives, such as a developer, a tester and a product owner, review requirements together to generate complete and deliverable specifications

More predictable development

With more well-defined user stories, the team started honing their efficiency. As we aimed to improve, our emphasis on tracking metrics increased. There are a number of metrics and some are better than others for a given purpose. For tracking efficiency, the team began to pay attention to cycle time.

“Cycle time is a measure of the elapsed time when work starts on an item (story, task, bug etc.) until it’s ready for delivery. Cycle time tells how long (in calendar time) it takes to complete a task.”

– Agile & Lean Metrics: Cycle Time, Sami Linnanvuo, CEO Screenful, 2015

Cycle time improved by 78% once the solutions were in place. Starting with 23 days, it went down to 5 days. For those who don’t know, JIRA tracks this in their control chart report. You can see the team’s results below.

“Metrics are just one part in building a team’s culture. They give quantitative insight into the team’s performance and provide measurable goals for the team. While they’re important, don’t get obsessed. Listening to the team’s feedback during retrospectives is equally important in growing trust across the team, quality in the product, and development speed through the release process. Use both the quantitative and qualitative feedback to drive change.”

– Five agile metrics you won’t hate, Dan Radigan, Atlassian

Team satisfaction

It is important to recognise the positive impact on the team. On one side, the startup perceived that the team was working well. On the other, the team desired to improve a few key areas; the main ones being clarity and context. And the root cause was not meeting with the client product owner enough as a team. Once addressed, it led to more teamwork. Each team member felt more ownership, and gained more trust in the process.

Another factor which improved team satisfaction was flow. The product owner liked to discuss features when there was a lot on the team’s plate. Having a separate product board, acted like a shield for the team. I often bore the shield and discussed features with the product owner. This replaced the direct discussions the product owner was having with the team. The discussion then led to updating the board and its priorities. Having this process in place led to far fewer breaks in the team’s focus.

Client satisfaction

The startup listened and followed our guidance. But, there were times when we faced resistance to change. Where the startup saw a working process, we found one that needed improvement. At this point, we decided to inject more tools from Adaptive’s toolbox. The startup at first thought that the suggestions wouldn’t suit a startup. But with our track record, the startup gave us a chance to apply them. The outcome: a successful 4-6 months of implementing process improvements.

A few of the key results from the startup’s perspective:

-Improved clarity over what the team was working on
-More frequent updates and communication
-Better alignment of priorities
-Improved efficiency despite the transition to remote working
-More focused delivery and fewer distractions

“When we started this project we were looking at shoestring development – individuals who coalesced around the product, together with outsourcing. It soon became clear that these people couldn’t build the robust, scalable solution we envisaged, so we turned to Adaptive. From the beginning, as they helped us structure a real project out of a vision and from there build a top-class app they have been a very real partner. It’s taken time but we are on the verge of releasing v1 of a uniquely powerful product which we hope will have huge potential in financial markets and beyond.”

– CEO FinTech startup

To sum up

On this project we have applied several solutions: separate product/development boards, shared story maps, and virtual whiteboards. It could be argued some of these solutions might be needed less with co-located teams. However, we’ve found that distributed teams work better with a more explicit structure in place.

We’ve created a proven and repeatable process that helps teams maintain shared context. It’s a process that is well-suited to distributed teams. And has the flexibility to deliver to startups and their clients.

Adaptive’s key to success is through its people. We treat our teams right, and understand that people are key for delivering great software solutions for their clients. The thinking is: when the team works well, they’ll be more effective. This approach has really instilled a culture of trust within teams. And has helped to foster continuous improvement. The end result: satisfied clients and even happier teams.