Case Study: Efficient Software Delivery with Team Topologies

I would like to share some insights from a few years back where we rearchitected our existing front-end team into an efficient software delivery machine - using learnings from #TeamTopologies. (Read here for their core ideas.)

The tipping point came when we had to start building a new end-user experience as a greenfield project: web app, iOS app, Android app, and CMS.

To understand the degree of change we undertook, and the positive impact #TeamTopologies had on our thinking, I'd like to outline our initial team state.

Initial State

How does one descriptively do justice to the pure chaos that manifests when organisational architecture, cognitive load, context switching and communication patterns are left to chance and fall prey to entropy? Expectations for new Engineers were to download all (literally) repos from GitHub and get up to speed. Documentation was scarce or non-existent, prioritisation outsourced to the "The Loudest Voice in the Room” and deployments manual. It's important to note that intentions were good, but rapid growth had stretched everything too far.

The below diagram shows how the organisational architecture had translated to our front-end system architecture:

Above is the unenviable mandate for our single full-stack front-end team who managed new features and maintenance on 4 web apps (offering nearly identical functionality but designed for different devices and browsers) plus multiple REST APIs and a CMS (Content Management System) that influenced the display of content on the web apps. Capabilities were isolated by having different departments for Business Analysis, Project Management and Quality Assurance - thus entrenching an "us versus them" tribal mindset that was extremely challenging to manage. It's self-evident to see how DevX and quality of delivery suffered - and I would be remiss not to mention Conway.

End State

It's important to ensure I credit Team Topologies, as it provided us with a commonsense framework we could adapt, gain buy-in for and rapidly land. The diagrams I've created make use of their designs based on Team Types and Interaction Modes - see their GitHub repo here.

We had to move forward rapidly, but in a positive and consultative manner, to ensure we earned buy-in from all stakeholders. Our change management plan identified 5 key areas to start:

1. We Pivoted to Teams with a Specialisation Focus

We purposely aligned teams into areas of speciality as we wanted to ensure our team structure mirrored our software architecture:

1. App development (React Native) became a Stream-Aligned Team.
2. Web app development (React.js) became a Stream-Aligned Team.
3. Back-end development (REST APIs) became a Platform Team.

This reduced the cognitive load of engineers and teams by having a speciality focus as a move away from generalisation (e.g.: Full-Stack Engineer) to specialisation (e.g.: Back-End Engineer).

All discussions and ceremonies became more focused, with an additional positive impact on our Engineers' Career Pathways through transparency, focus, clarification and alignment. This had a net positive impact on our retention rate, with no engineers leaving the team. This was a substantial shift from our previous trend of frequently losing multiple engineers.

2. We Defined Interaction Modes

It was important for us to ensure that interaction and communication patterns and responsibilities were understood and clarified as this would complement the architectures we had chosen:

1. Our Platform Team had a clear mandate to provide Software as a Service (XaaS) to the Stream Aligned Teams. This shaped our communication patterns by clarifying what dependencies the Stream-Aligned Teams would have on the Platform Team in advance, with a net benefit of the Platform Team learning to ask the right questions in advance for current and future requirements.
2. Our Stream-Aligned Teams naturally fell into the collaboration pattern as they worked towards common goals (end-user experience, retention, interaction funnels etc.). This also impacted the structure of our GitHub repos where web and app teams accessed repos for common code but maintained the integrity of their own.

3. We Created Cross-Functional Teams

As mentioned previously, we had departments for Business Analysis, Project Management, DevOps and Quality Assurance which had entrenched an "us versus them" tribal mindset conflated with different priority messaging landing on the engineering teams. This was a true anti-pattern.

Each stream-aligned and platform team was equipped with engineers (typically a senior, 2 intermediates and a junior), a QA engineer, and shared BA, DevOps and PM resources dedicated to the front-end teams. Team morale, communication and thinking around how we approached each challenge changed overnight.

In conjunction, I intentionally drove initiatives to diversify our teams so that we could enrich our skill sets through the advantages that diversification brings.

4. We Identified Enabling Teams

We reached out to and received buy-in from Learning & Development and various domain experts to act as consultative "Enabling Teams" to accelerate, upskill and act as an "antenna" by identifying optimisation areas within each team. This worked remarkably well and ensured we were also ready with resources to upskill and unblock teams.

5. We Focused Support Roles

We equipped the teams with dedicated and focused resources for Team Leaders, Business Analysis, and Project Management, thus limiting context switching and cognitive load for these areas which previously worked across company-wide projects.

Our end state Team Topology is depicted below in Diagram 2:

Principles

We also agreed on a set of cultural principles to act as our North Star. These principles helped drive consistent behavioral patterns which in turn complemented and helped maintain the above topology. Here are some of them below:

1. Have a "common language" for Teams' use of software management and communication tools, allowing easy interchange between teams and transparency of WIP and reporting through a single source of truth. (In this case: Jira, Confluence, Slack).
2. Implement and nurture a culture of transparency and usefulness to ourselves, our colleagues and team.
3. Equip each Team with a single overriding purpose that they actively work towards. Each action should be in alignment towards this, which can be shared as a vision.
4. Conceptualise the Team as the single fundamental means of delivery over an individual within the Team. The same went for resolving production issues.
5. Through our knowledge sharing culture, allow Teams to identify and design features based on the degree of volatility.
6. Actively and regularly seek feedback from our client and incorporate this back into the design, through standard weekly review sessions. (This involved everyone from senior stakeholders to junior engineers congregating around a giant TV that displayed the web and app screens while we discussed WIP and work still to be done.)

In summary, this was a rewarding initiative and the learnings still help shape my organisational architectural thinking today. Please find references below and leave a comment if you have any questions. There is no single right way of doing things, and change is inevitable, but it certainly helps to have a defined framework that delivers outcomes not just for the company, but for the people that pitch up everyday to drive it forward.

References