We Are Bad At Explaining What Agile Is

This is the fifth and final blog post in my series on the current state of Agile. In the first post, I shared my view on the changing sentiment towards Agile and some of my own history and experience with it. I also identified four factors that, in my opinion, contribute to the current state. 

In the second blog post, we looked at the first of these four factors: Agile’s rise in popularity.

In the third blog post, we looked at the second factor: “Agile” has lost its meaning. 

In the fourth blog post, we looked at the third factor: Agile is hard.

This is the last blog post in the series. We will explore the fourth factor: We are bad at explaining what Agile is.

The Mindset Problem

As a community, we Agile folks like to talk about an idealized way of working that makes a whole lot of sense to us. We talk less about the fact that almost all companies struggle to adopt Agile, a lot of them severely. On my non-scientific list of reasons for this failure that I hear from other Agile Coaches “lack of Agile mindset” or “lack of cultural fit” are at the top. People just don’t seem to get it. Or they seem to get it but their actions speak a different language. The way of working we like to talk about seems to make a lot of sense to us but not to others.

Here’s one thing we can do about this: assume that most of the people we work with are inept and will never understand our brilliant methods. When I have a bad day, that’s the option I choose. 

But here’s another option: taking responsibility. Instead of asking “Why don’t people get what we’re trying to teach them?” maybe we should ask “What are we doing so that people don’t get what we’re trying to teach them?” Instead of assuming something is happening to us, we should ask how we are actively creating this problem. 

Over the years, I have investigated which specific ways of conveying Agile ideas work and which ones don’t. My personal metrics (the number of lightbulbs turning on above people’s heads, the number of times someone says “Oh, now I get it!”, etc.) have steadily increased. And, don’t you know it, all of a sudden I don’t have the “lack of Agile mindset” problem anymore. Or at least it has decreased significantly. 

Wrong Focus

Things changed drastically for me when I realized that people don’t care about Agile. They care about their problems being solved. We know this because a lot of us teach this when we talk about Agile product development. Yet we don’t apply the same thinking to explaining Agile.

Whenever I work with a client and the Agile Coaches there tell me that the employees at this particular company simply don’t get it I investigate. It’s helpful to ask “Why don’t they get it?” What’s even more helpful is asking “Why should they get it?” What has been done so that these people have a fair chance of supporting this new way of working? The results are often disappointing: not much was done in this regard. Instead, we see one or more of the following dysfunctions:

• Not explaining what Agile is at all
• Focusing on a specific framework
• Simply referring to the Agile Manifesto

Let’s look at these one by one. 

Not Explaining What Agile Is

This one is simple. You assume Agile is somehow self-explanatory. The often referred to Agile Mindset is somehow already part of people’s brain structure. Or it isn’t, in which case that person is useless and should be shunned. If you can’t follow along, you better educate yourself! Where? The internet, stupid!

Focus on a specific framework

Next one: instead of explaining what Agile is and how specific methods fit into the larger set of ideas we only focus on the mechanics of a single method. 

“We’ll be doing Kanban, so I’ll explain how it works!”

“Management says we need to use Scrum! Here are some Legos.” (Nothing wrong with Legos, I use them myself occasionally.)

If you’ve ever participated in one of those trainings, you know that they are not bad. When they’re done by a member of the big certifying organizations they’re actually very good. They do not, however, answer the fundamental questions people generally have. 

Those include:

1. What is the purpose of Agile?
2. What problem is Agile solving?
3. How do we know when Agile is being used effectively?
4. What is needed for Agile to work effectively?
5. What are basic Agile mechanics that manifest in specific frameworks?
6. What choices do we have when it comes to Agile frameworks?
7. What are the limits of Agile? What does it not do well?

“But hold on,” you say. “The Agile Manifesto answers all questions!” Except it doesn’t. 

Simply Referring to the Agile Manifesto

I think the Agile Manifesto is great. I also think it’s a terrible device for explaining Agile. 

The Agile Manifesto is a collection of belief statements and principles. This is an excellent snapshot of Agile in the year 2001. It doesn’t answer the questions outlined above, maybe with the exception of question five, the basic Agile mechanics. But those mechanics are also not explained in a coherent, easy-to-understand way. Most of all, the Agile Manifesto doesn’t give a clue as to why the signees value the things outlined and why they chose these specific principles and not others. 

“Uncovering better ways of developing software” is not a good answer to the question of why. Who doesn’t want better ways of developing software? Everyone does. What makes the Agile approach so special? Why is it better than other ways of developing software?

When people don’t seem to “get” Agile most Agile Coaches will vaguely refer them to the Agile Manifesto. I’m not offended by the fact that people often simply point to the Agile Manifesto (or as an extension to the Scrum Guide). I’m offended because doing so is an incredibly weak argument. It constitutes an Appeal to Authority. Instead of presenting sound reasons and convincing logic – in other words, things that could actually convince adults – a lot of Agile Coaches point to a document that doesn’t answer basic questions. If someone criticizes Agile, has a hard time understanding it, or *gasp* has a different opinion, it is almost impossible for them to engage in a meaningful conversation. It’s the Agile equivalent of RTFM, only that the manual isn’t an actual manual, it’s a manifesto. 

Again, I think the Agile Manifesto is great. I also believe it wasn’t designed to answer the questions outlined above. It is our job to answer them.

We Can Make It Work

I have experienced several moments of success by shifting the way I introduce Agile and the way I talk to people about it. Let me share a few stories to illustrate what this looks like, to inspire you on your own path, and also to brag about my wonderful achievements (just let me indulge for a moment, I’ll share my disastrous failures soon enough).

1. Years ago I was working with a team that had an established product but struggled to add innovative features. We were using Scrum. The people on the team were still confusing things like “Review” and “Retrospective”. But during a discussion about possible new features, just as I was about to interrupt, a member of the team said “Hold on a minute. We’re assuming that we know what our customers want again. Is there a way to get quicker feedback on this idea? Isn’t that why we’re doing this Agile thing?” A rainbow appeared in the sky and laughing kittens poured down on us. 
2. I sat down with a group of managers who wanted their development teams to use some form of Agile. We took a deep look at Agile, what it’s designed to do, and how this relates to their challenges and their context. The group realized that this wasn’t at all what they needed. Agile simply wouldn’t help them solve the problems they were facing. One disastrous Agile transition averted! 
3. A group of Agile Coaches were struggling with their implementation of scaled Scrum. We went back to their reasons for choosing Scrum in the first place, what Agile is and isn’t, and how this manifests in their environment. As a result, this group was able to see what problems to tackle first and how to communicate the change so that people were eager to make it work. They helped solve problems people cared about.

What You Can Do

I like giving people specific things they can try out right away. This time I won’t. What? No recipe for doing this successfully each and every time? No. I want you to figure this out for yourself. Take some time to reflect on Agile. Find your own answers to the questions outlined above. It’s one of the best things you can do. Better yet, find your own answers and then ask other people what their answers are!

If you still don’t have a clue and need more help, buy the Zombie Scrum book. We wrote a chapter on this which will give you some pointers. My kids need new shoes. Thank you!