Can Agile Frameworks Inhibit Your Agility?

That Bacon Guy

The featured image of bacon, I admit, is sorta click bait. Because it’s, well, bacon! But there is a connection (sort of). 

Many people will have heard of “The Six Degrees of Separation“. Back in my day it was popular to do this with Kevin Bacon. You would play this game by picking any actor and then trying to link that person to Kevin Bacon based on who they worked with in films. The game was to identify the films & actors linking your actor to Kevin. The number of actors between your person and Kevin was called the “Bacon Number”. 

At some point I think people started saying that every actor was separated by, at most, 6 people from having worked directly with Kevin Bacon. Thus the “Six Degrees of Kevin Bacon“. Similar to the Six Degrees of Separation from you to any other person on Earth.

So there, the bacon/Bacon connection. 

Our highest priority is to satisfy the customer

I’m sure I’ve read that somewhere before…

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agile Manifesto

Indeed I have, many times in fact. Let’s explore my theory that frameworks might hinder satisfying this priority.

A childhood game remembered

Do you remember playing the Telephone Game? Perhaps as a child or in an Agile introductory class?

  1. The first person whispers a phrase or short story to the 2nd person.
  2. The 2nd person then whispers the same phrase or story to the next person.
  3. This process continues, repeating the whisper down the line until you reach the last person.
  4. That person then says out loud what they heard.
  5. The first person then says what they told the 2nd person.
  6. Vary the game with more and fewer people.

Are you amazed at how much the phrase or story has changed the more times it is repeated?

The same phenomenon can happen in professional settings as well, especially if you are using more than one “proxy” layer between the team and the customer. 

Frameworks distance teams from customers

The two most popular Agile Frameworks are Scrum and SAFe. Both utilize at least one proxy to represent the customer within the team, program, solution and/or portfolio (depending on framework & configuration). In both frameworks, the proxy closest to the team is the Product Owner.

When teams are using Scrum the situation is often simpler with at least 1 person between the team and the customer. It’s pretty rare to encounter this configuration, most groups and organizations I’ve seen or heard of also add a Program and potentially a Portfolio layer as well. So, at best, we can say that Scrum introduces at least 1 layer between the team and the customer, potentially more.

With SAFe it’s a different story and depends on configuration chosen. To these illustrations, taken straight from the Scale Agile Framework website, I’ve add a customers icon. Surprisingly, or maybe not, the Customer is not directly represented on any of their configurations. I’ve also added red circles around potential and/or probable proxies between the teams and the customers. 

In its simplest configuration, Essential SAFe, there are typically 3 proxy layers between the team and the customer. Full SAFe has potentially 5 or more layers.

SAFe configurations illustrating customer proxy layers

Similar to the Bacon Number, I’d like to introduce you to the Agile Number. The Agile Number is the number of proxies, or layers, between the development team and the customer. This is the number of people or groups that information and/or feedback needs to flow through before it reaches the teams.

Lower Your Agile Number To Increase Agility

Think back to the Telephone Game referenced above. Each retelling of the original phrase or story likely distorts the message either a little or a lot. The more times the story is told, interpreted and then repeated, more and more error is added to the original message. And that’s if the story is heard and immediately retold. Introducing time delays would make the final message even worse.

So you might think, let’s write it down. Sure, we can do that. Perhaps as a set of requirements documents. Oops, we’re back to Traditional gated development! We need to be more “Agile” than that so we’ll write Epics and Features and Stories and such. Here’s the thing though with written requirements, written words can be misinterpreted even worse than verbal communication!

From cakewrecks.com

The instructions were the write “Best Wishes Suzanne” and underneath that “We will miss you”.

The misinterpretation, from just one layer of documentation, is hilarious and informative.

Each proxy or layer between the customer and the team introduces risk of misunderstanding and misinterpretation. And it will also likely introduce delays but that’s not the subject of this post.

A Leading Indicator?

Thinking back to the Agile Principle identified above, namely that our highest priority is to satisfy the customer, it is obvious that the more proxies and layers between customer and team, the higher the risk of poor customer satisfaction. We simply introduce too much risk of missing the mark on their actual needs.

I’m thinking that the Agile Number might even be a leading indicator of agility. In a full SAFe configuration we might have something like the below. Of course this is exaggerated somewhat but the point here is to think about your situation, what layers and/or proxies do you have between your teams and the customers?

  1. Customer request -> Epic Owners -> Solution Management -> Business Owners -> Product Management -> Product Owner -> Team
  2. The team does some work and delivers the request
  3. Customer Feedback -> Epic Owners -> Solution Management -> Business Owners -> Product Management -> Product Owner -> Team
  4. Team acts on the feedback

Was any level of agility achieved? Does your environment encourage or discourage agility in its current configuration? Is your Agile Number too high?

Wrapping Up

I wish I could say that I came up with the comparison to the Kevin Bacon game we used to play in the 1980s. But thankfully I know Guy Maslen, an Agile Coach in New Zealand, who introduced me to this concept. He definitely deserves the credit for creating the analogy and the term Agile Number.

In general I’m a big fan of Scrum, especially as scaffolding and learning for teams new to Agile. It introduces them to many new practices and patterns that will help them to increase their agility by shortening Traditional feedback response times. Scrum teaches them to think small batch. It teaches them to inspect and adapt their ways of work. And the Agile Number can be relatively low. All good things.

I’m not a fan of SAFe and its associated Agile Number is another reason why. 

If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.

Until next time!

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Prev
If You’re Not Doing Iterative Work, Why Are You Still Using Scrum?

If You’re Not Doing Iterative Work, Why Are You Still Using Scrum?

Scrum can be a very effective framework when used for product development

Next
Concerning Partial Credit – A Scrum Tale

Concerning Partial Credit – A Scrum Tale

Once a Sprint has been planned, the Story Points, if they ever had any meaning,

You May Also Like
Total
0
Share