When you sub-optimize, it’ll bite you in the ass.

by Jurgen de Smet – Certified Creating Agile Organizations Trainer.

A Hard Team Setup Constraint

A client of mine came to me with a problem. They wanted to improve transparency in their product development capabilities, but they were faced with a hard constraint on team structures. They had been reading, discussing and agreeing on their team structures based on the book “Team Topologies” and didn’t want to change them.

This is a classic example of “emotional investment” blocking acceptance to change. Think of it like this: if a coder works on something for four weeks and then receives feedback that would require a complete rewrite, they’ll likely resist the change or ask for more and more details before starting anything. It’s the same for other roles like for example a functional analyst or architect. When you invest so much time and passion into something, it’s hard to accept feedback that requires you to redo most of the work. But what if you received feedback after just an hour or a day of work? Fast feedback is key to being open to change and adaptable as both an individual and an organization.

Unfortunately, my client spent months in their new team structures without fast feedback, making it a hard constraint. Despite discovering improvements in transparency, number of backlogs and team structures through causal loop diagramming exercises, they couldn’t get over the emotional investment effect. 

The constraint remained:

• • 6 Stream Teams each owning their own part of the product and features to build.

• • 1 Platform Team set up to make the life of others easier (at least that was the purpose).

As someone experienced with system dynamics, I didn’t push to change the team structures at first. But I knew that organizational design elements should be aligned for success, so I encouraged my client to consider the benefits of fast feedback loops and open-mindedness to change. 

Purpose & Capabilities

When I teamed up with (executive) management, product management, and some enthusiastic team members, it quickly became apparent that the call for transparency was merely a band-aid solution to a deeper set of needs:

• • The IT R&D department needed to foster a better image within the organization and among its customers.

• • There was a pressing need to get fresh ideas into the hands of users to truly understand their value.

After careful consideration of their existing setup and constraints, we identified a handful of key capabilities that would help achieve these goals:

• • Develop trend data based on outcomes to pinpoint what truly drives business impact.

• • Consolidate all the work of the teams onto a single Product Backlog for better transparency and clear prioritization across all teams.

• • Build expertise in collaborative Refinement sessions with real users.

Learning how to build the right things together with real users and tracking the business impact, while providing a higher level of transparency in what’s going on and why within the IT R&D department were considered the main levers to achieve the needs mentioned above.

For each of these capabilities, we established 2-4 trend metrics to track our progress and guide our actions. Every two weeks, we looked back at these metrics, evaluated our progress, and made necessary adjustments to keep moving forward.

These trends metrics provided 2 things to our group of change agents:

• • More clarity and focus on what aspect of the capabilities we would work on first, and

• • They gave us insights into how our change activities impacted the chosen capabilities so we could learn and adjust where needed.

Over time, when certain aspects of focus were considered good enough, a new focus was set forward by identifying new trend metrics within the capability at hand. And if an entire capability was considered good enough, new capabilities for growth were identified.

Currently, their initial capabilities have been replaced by one focusing on technical health and others focusing on higher quality and quantity user feedback and usage statistics. 

One Product Backlog & Team Structures

While we worked on many elements, I’ll focus on two crucial aspects of their organizational setup: their focus on business outcomes in a single Product Backlog and the hard constraint they set forward on their team’s setup. These structural elements are crucial to the success of an Agile organization, but they can often be at odds with each other. When there’s a conflict between these two elements, it can lead to tension and frustration. To prevent going back all over again, we need to make sure that everyone is on the same page and that the Product Backlog, showing the most important items to deliver value, takes priority. Too often we observe that teams take priority and a Product Backlog is being used to order items according to the available skillsets, thus becoming the new way to do resource management. Shifting focus away from business outcomes all over again. Having the Product Backlog take priority helped to make sure they didn’t fall for that trap.

Yet, having a high focus on business outcomes in their newly created Product Backlog conflicted with their hard constraint of keeping Stream Teams, owning a piece of the puzzle. Their ownership was not in balance with the high-ordered business outcomes to achieve. It became apparent that only a few of the teams were working on the highest-ordered business outcomes. A tension between organisational goals and inconsistent organizational design elements. 

But what happens when tension does arise? Well, that’s when it’s time to reflect and make changes. By encouraging people to adopt a holistic approach to the system, we can generate a more comprehensive perspective, and come up with solutions that optimize the achievement of the predefined goals.

Outcome Goals Constrained By Team Setup

In fact, after just four sprints working with a more outcome-driven Product Backlog, all involved realized that the real issue to significantly improve their customer value delivery capability was with their team setup. Luckily, the teams were already skilled in different areas, so we just needed to change organizational policies and allow them to work on everything required to deliver a significant outcome to users. No more team code ownership, no more individual goals – everything is shared amongst the teams.

From sprint 5 onward: the Stream Teams were replaced with Product Teams. This change within their organizational design led to some pretty amazing benefits! 

• • For one, multiple teams started working together towards a single business outcome, resulting in larger outcomes being delivered much faster to their users. 

• • This quicker delivery allowed them to work with their outcome-based trend data in a more effective way. 

• • Plus, paying back technical debt became easier with the help of multiple teams working together. 

• • And let’s not forget about the overall increase in product quality!

Structural Refactoring and Product Quality

Let me elaborate on paying technical debt and increasing product quality. Before the change each team was owning a specific piece of the product and thus engaging in structural refactoring was not possible, teams stayed on the surface, refactoring small parts and leaving the biggest causes of technical debt in place. Having multiple or even all teams working together on the entire product increases the overall capacity to structurally refactor while still delivering new functionality to their users. Not only capacity was a driving factor, but also the feeling of all teams working together increased the teams’ courage to take on structural refactoring. While in the past a single team was scared to be blamed for messing up when trying a significant structural refactoring, now all teams are involved and not a single team can be blamed. Not to underestimate the benefits of changing team structures!

Fast forward a year later and they had acquired a whole new set of capabilities in their organization, shifting their focus to other exciting points. This included increasing the quantity and quality of user feedback, as well as taking better care of their product by collecting usage statistics. And of course, they continued to strive for excellence in collaborative refinement.

Summarizing

Despite a rough start, I am pleased to say that their journey to becoming more Agile has been a triumph. A key factor in their success has been ensuring that their organizational design aligns with their goals and desired capabilities. This has involved eliminating any conflicts along the way.

As described in the book Creating Agile Organizations, their original Stream Teams can be thought of as “Efficient Islands”. All were very busy with their part of the product, not even aware of the effect it had on delivering significant value in the hands of their users. However, by connecting these teams through a single Product Backlog, it became clear to everyone involved that they needed to transition to an “Efficient Ocean” model (See figure 1). Improving their collective capability to deliver the highest customer value, every single sprint over and over again, while stepping out of their comfort zone and learning new things. Slowing down to speed up. 

This change has been instrumental in their success, and they continue to work towards improving their collaborative practices and gathering more user feedback.

Figure 1 – Flow – Resource Efficiency

Learning became a top priority for the team, and they invested a lot of time in it. They had to learn about different parts of the product, how to collaborate across teams, how to develop features more quickly, and how to analyze outcome-based data. In fact, learning became just as important as creating new features, slowly moving up from the efficient ocean.

How did they do it? Here are some techniques they used:

• • Multi-team refinement sessions were instrumental to share product knowledge amongst different teams, 

• • while multi-team sprint planning sessions provided a great opportunity for the teams to design their cross-team collaboration efforts.

• • Learning katas (practising new skills in a simulated environment) were initiated, at first to improve on refinement practices, and later on coding practices (TDD, Mob programming…).

• • Every single sprint, during sprint planning, the teams planned for a one-hour internal knowledge transfer session and

Even now, more than a year later, they still have regular internal knowledge transfer sessions and learning katas every few sprints, and they even expanded having an active book club on top of what was there already.

Assessing Impact

To measure the impact of these changes, they looked at their cumulative lead time trend, which was a reactive or lag metric. Even though it took some time to see the effects of their efforts, the results were significant as you can see in figure 2.

Blue line: small initiatives / Orange line: large initiatives / Grey line: overall / Time starts when the first backlog item of an initiative is being worked on, keeps growing till the entire initiative is running in production, all measures are summed resulting in a cumulative view of days of initiatives started yet not delivered into the hands of users.

Figure 2. Cumulative lead time trend

And the journey continued beyond achieving flow. They didn’t settle for just that – they aimed to optimize the efficiency of their processes, minimize variability, and improve their resource efficiency. It was a never-ending quest for improvement and growth, guided by the path in Figure 3,  as outlined in the book Creating Agile Organizations.

Figure 3. Improvement path