How to Deal With Uneven Agile Adoption Rates

The more digital the product, the more effective agile will be.
Kevin Miller & Tommy van Schaik
Expert Contributors
May 25, 2021
Updated: July 13, 2021
Kevin Miller & Tommy van Schaik
Expert Contributors
May 25, 2021
Updated: July 13, 2021

Welcome to part two of our advice series exploring how to avoid wagile scenarios (or recover from them if they sneak up on you).

Simply put, wagile is the worst. It’s a mashup of the agile and waterfall methodologies, and many think this hybrid approach provides the best of both worlds. In reality, it creates chaos and confusion, which — to put it bluntly — ruins effective project management. If you have a wagile scenario to share, please send it to [email protected], and we’ll take a look.

Missed the First Installment? Catch Up Here.Why Fake Agile Sows Chaos and Confusion on Project Management Teams

 

Mixing Methodologies

Hi Kevin and Tommy,

My question is related to the rate of agile adoption in different teams. I work for a large organization in the automotive industry with multiple product groups. Some of the larger agile teams are organized as SAFe agile release trains, while others use agile team practices (Scrum and occasionally Kanban). 

We noticed a significant difference in the agile adoption rate between the different product groups. Some of them are at a high maturity level and improving rapidly, while others seem to show slower progression — we update a maturity radar chart every three months. How can we make sure all of our teams increase adoption and velocity and become more effective?

Cheers,

Gardu

 

Tailor Agile Adoption to the Product’s Digital Components

Hi Gardu,

Measuring agile maturity between different teams is as much of a challenge as measuring the effectiveness of more classical team compositions.

First, it’s important to realize that the adoption and effectiveness of agile practices depends heavily on the products the teams are working on. Some teams will be slower in their adoption simply because agile is less applicable to them. In a large and complex organization like yours, it is likely that many different teams are working on many different products. The nature of these products have a high impact on the effectiveness of agile. In general, one could say, “The more digital the product, the more effective agile will be.”

agile-effectiveness
The nature of the product vs. the applicability of agile.

When you look at classical examples of successful agile implementations (Spotify, Netflix, banks, insurance companies, etc.), you’ll see they all have an end-product that leans heavily to the right — and is based one ones and zeros.

The reason for this lies in so-called “emergent architecture,” which is the amount of architecture you need up front to ensure you end up with a sustainable product in the end. For example:

  • Most SaaS companies probably give some thought to the architecture of their software early on, but most of the architecture will be created as they are programming.

  • If you are creating something more on the left side of the scale — let’s say an airplane — all of the components need to fit perfectly, and they cannot be manipulated while the airplane is being put together because the cost of changing components mid-build would be devastating. That’s why these types of products require up-front architecture. 

On a graph, it looks like this: 

architecture-maturity-vs-product-development
Graph: The maturity of architecture vs. product development.

Some companies have become adept at dealing with products that have large up-front architecture, and they have perfected the art of breaking them down into smaller components, some of which are more suitable to being created in an emergent-architecture approach (e.g. the software used in the aircraft). 

When a large and complex product consists of both physical and digital components, it is critical for organizations to tailor their agile implementation to only the digital components of the product and not the entire product, since implementing agile on the physical components leads to becoming wagile!

different-evaluations
Teams might evaluate the same metric differently.

Since the product matters when analyzing agile adoption in teams, it’s hard to compare progress between different teams. We can, however, apply a relative performance measurement to each of the teams by comparing them against themselves.

Much like relative estimation and velocity used in agile’s planning poker process, we can apply the same thought process to the relative performance measurement. 

team-progress

The radar charts you are using are excellent for this; it is good to assess relative team performance over time. Keep in mind that the specific metrics measured by the five points of these spiderwebs can vary between organizations, departments and teams. It's the conceptual practice that matters here.

team-regression

 

4 Tips for Assessing the Adoption Rate of Teams

In our experience, there are a few key things to keep in mind when helping multiple teams effectively adopt an agile methodology without straying into wagile territory: 

  1. Don’t tie the performance of a team to their adoption of agile.

  2. The applicability of agile depends in large part on the nature of the product.

  3. Measure the agile adoption rate of a team with a relative performance matrix.

  4. Comparing agile adoption rates between different teams is tricky and can lead to distorted conclusions.

Good luck!

Expert Contributors

Built In’s expert contributor network publishes thoughtful, solutions-oriented stories written by innovative tech professionals. It is the tech industry’s definitive destination for sharing compelling, first-person accounts of problem-solving on the road to innovation.

Learn More

Great Companies Need Great People. That's Where We Come In.

Recruit With Us