Improvement opportunities usually show up as friction points in day to day work. These opportunities are sometimes hard to spot across teams. It is hard to know if they are worth investing in. And yet, they may or may not be sticky in a team’s behaviour patterns. Worse, it may not help you make an impact on your business or customer outcomes.

This talk will explore how to spot opportunities using Team Topologies principles. Based on patterns seen across clients, we will explore what could be your sniff test to understand which ones could pilot well? If they don’t pilot well, what to do next? We will explore these together to enrich the discussion.

Key takeaways for participants:

Gain understanding of Team Topologies principles
Learn how to apply fast flow principles to find improvement hot spots
Prioritise improvements, based on strategic focus, customer opportunity & fast flow potential (incl. team cognitive load) and learning potential from the pilot
Understand considerations for rolling back improvement pilots

Talk plan for the session:

00:00 Problem statement: Teams are stuck in their work with business outcomes slow to achieve, they want to improve but don’t know where to start. They have some improvements to look at but not sure if they are the right ones

00:02 Story about a team stuck: This team in a financial services company wanted to digitise its customer services journey. The leader had a goal to reduce costs and hired a strategy consulting firm who did their roadmap. This is the first time they were made responsible for a digital product. Where do they start? So many things to start, upskill and explore

00:05 Team Topologies foundations: Team Topologies book by Matthew Skelton and Manuel Pais is to help business and technology teams organise for fast flow.

Team topologies provides:
Language for dealing with flow, boundaries, architecture, dynamics
Heuristics (clues) for organising teams and software
A focus on fast flow as a key driver

The "flow of change" is the work/changes needed for a product or service on an ongoing basis.

A fast flow aims for the following:
Untangle business concepts
Adjust team and system boundaries for flow
Minimise hand-offs
Remove blocking dependencies
Move decision-making to teams

To support this we have 4 fundamental team topologies:
Stream-aligned team: a team aligned to a single, valuable stream of work
Enabling team: composed of specialists in a given technical (or product) domain, and they help bridge this capability gap.
Complicated-subsystem team: responsible for building and maintaining a part of the system that depends heavily on specialist knowledge.
Platform team: provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services

And 3 main team interaction modes:
Collaboration: working closely together with another team
X-as-a-Service: consuming or providing something with minimal collaboration
Facilitating: helping (or being helped by) another team to clear impediments

00:10 Applying Team Topologies foundations to our team’s context: Team Topologies principles and interactions could help to sense major friction points between teams as well as within a teams boundary of flow.

Untangle business concepts. A user needs-based mapping revealed 2 separate domains - “customer registration of services” and a “manage services portal”.

We then found several friction points in the “customer registration of services” domain that was hindering their flow:

“Hand-offs” examples.
Long wait times for customers to register and developers to make a change due to no adoption of APIs that were available from data systems to complete the customer journey. Multiple business services relied on these data API services.

“Adjust team and system boundaries for flow” examples.
Customer account software had grown too large for one team and had a strong change coupling with this new product team; It would benefit from making available documentation and/or APIs so that in the future both teams could release independently

“Blocking dependencies” examples.
There were no APIs available for developers from risk calculation engines (owned by a different team) that the digital product could use to deliver the flow independently
The delivery pipeline was reliant on big integration work with minimal automated testing and deployment across teams before a release could be made available in production. The delivery cadence was very slow.

“Partial decision-making” examples.
There were too many unknowns on customer desirability of features and the team couldn’t learn and make the decisions on what to build
A large amount of time was devoted to roadmap planning for 12 months without alignment on the biggest risk for business and customer success. This risk is that the team might work on features that may or may not lead to customer adoption

The “manage service portal” domain of flow shared roughly 80% of these problems.

All these signals surfaced with Team Topologies sensing.

00:15 Identifying a pilot opportunity: With a number of these opportunities maybe at the same time, the big question is which one to pursue first. The key criteria to decide is usually based on which one will protect our customer's interest the most at a point in time or will provide the business with a high-leverage opportunity. This is based on your product strategy.

For this financial services business, the key problem that the business was trying to solve was:

1. Improving customer adoption of online services to release capacity in customer services teams for more complex issues
2. Create a long-term capability in teams and systems to release faster

The 1st criterion was given higher weightage and hence the teams decided to pilot the improvements on the “customer registration” domain as it was going to release more capacity for the customer services team.

We piloted:
We dived deep into collaborating with the risk calculation engine team to re-architect the right interaction mode so that the digital product team could use their service on a self-service basis. However, this was a big change for them
Long-lived team with customer discovery responsibility. A new team with developers, UX, PMs and domain experts (BAs) started collaborating for the first time. They started piloting customer discovery practices e.g., testing prototypes with customers. That way teams had the independence to decide which feature to start building based on customer feedback.

The ultimate goal of these pilots was to deliver a production version of the customer journey and to improve customer adoption of online services.

00:20 Learning journey for the team and rolling back pilots: Each pilot also means this is an opportunity for each team member to learn new skills. A good enabling team, that can coach the pilot team, can improve the chances of teams growing in the right direction.

So what happened: Although the teams learnt a lot in the first 2 months they hardly made progress due to the low maturity of services from platform teams they were dependent on e.g. risk calculation engine team. Hence they were not able to release any production service to their customers.

The teams learnt in the first 2 months that the 2nd criterion was more important to select pilots i.e. create a long-term capability in teams and systems to release faster.

This led to pivoting on focusing on various platforms and enabling teams
Continuous delivery improvements e.g., automated testing, deployment, automated security and compliance standards and checks
Data APIs platform team
Customer account enabling team

Rolling back pilots can be expensive but make it inexpensive
The teams involved especially in collaborating on re-architecting suffered fatigue as collaboration lasted for 2 months
Not everything that they learnt was throw-away. Some of the patterns the teams uncovered helped in recovering legacy knowledge of systems that was better documented and surfaced now than before
Teams with developers, UX, PMs and domain experts (BAs) had just started collaborating on customer discovery. They spent a lot of time sharing insights they learnt with the stakeholders
They validated that customers valued a simpler registration journey, especially with pre-filled data. They could use this in the next iteration of the journey
Business stakeholders found this information useful and it improved trust with this new team

00:25 Conclusion: Key conclusions for teams to help them transform and improve their journeys and organisations.

Team Topologies foundations can help you sense big opportunities that will improve flow and deliver value for your business
To help prioritise your improvements effort, choose a criteria that will have a multiplier effect on helping teams to deliver fast
At the outset, clarify goals that help you assess pilots’ progress towards your ultimate business objectives
These goals and communication cadence should at the same time allow for changing course soon enough (3 months or sooner) so that opportunity cost and loss in team morale is minimised

00:30 Reflection and questions from audience