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.
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.
- What is the purpose of Agile?
- What problem is Agile solving?
- How do we know when Agile is being used effectively?
- What is needed for Agile to work effectively?
- What are basic Agile mechanics that manifest in specific frameworks?
- What choices do we have when it comes to Agile frameworks?
- 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).
- 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.
- 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!
- 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!
Agile Is Hard
This is the fourth 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.
This is the fourth blog post in the series. We will look at the third factor: Agile is hard.
A Reason for Change
In May 2018, my wife, my then one-year-old son, and I were spending time in Canada and the US. We went out for breakfast in Philadelphia, PA, with my wife’s family and some friends. One of them remarked on the fact that I had just finished a huge breakfast burrito by saying “I can’t believe you ate that entire thing!” At that precise moment, the waiter showed up with my full stack of peanut butter caramel pancakes that I had asked him to serve after the breakfast burrito. I ate that too. It’s not like I had a light lunch after that breakfast, or a light dinner after lunch.
Lying in bed that night, I thought about how unhealthy my behavior was. I decided that things had to change.
That wasn’t my first commitment to weight loss. Far from it. I had actually been trying to lose weight for about a decade. It never worked. I had read all kinds of books and really knew quite a lot about nutrition. I had tried all kinds of diets and different kinds of workouts. When I had lost a few pounds they quickly came back. During that time in North America, I decided that, once home, I would try one final time to lose weight. Otherwise, I would resign myself to just being “the chubby dad”.
Over the course of the next year and a half, I lost more than 50 pounds of body fat and have successfully kept it off ever since. In a way, my weight loss was super easy: I consumed less calories than my body burned. That’s it. And that’s also what I had tried – and failed – to do countless times before. So what changed? My relationship to food. I had a long, hard, and painful look at my underlying beliefs and how they influenced my behavior. For the first time, they didn’t always pull me back into old habits.
Agile Is Easy for Some and Hard for Many
My process of weight loss was remarkably similar to the Agile transitions I tend to see with my clients: Something that seems very easy at first glance becomes exceedingly hard for most people.
I have two sons now. If you have been paying attention, that is one more than I had in 2018. The older one is six, the younger one four. Watching them eat is absolutely fascinating to me. For one, they don’t overeat. Even if there’s something they really enjoy, they stop when they’re full. I have never heard them say “Oh man, I really shouldn’t have eaten the whole thing.” It simply doesn’t happen. They are also incredibly active, running and jumping around all day long until they go to bed (where they move around some more until they finally fall asleep). Due to these factors, it is very easy for my sons to stay lean. They simply haven’t developed unhealthy habits. Maintaining their current amount of body fat is almost effortless.
In the same way, I occasionally encounter Agile teams that make the whole process look like child’s play. Deploy to production multiple times a day, inspect live product data during the Sprint Review, make strategic product decisions together, talk to actual customers constantly. Why wouldn’t you?
These teams usually started out small and without a lot of organizational barriers around them. Direct customer interaction was there from the start. They focused on test automatization and flexible architecture from the get-go. They adapted their own process. Slowly scaling that approach, and improving it along the way, made staying agile almost effortless. For them, Agile is easy.
But most of my clients? They struggle just as much as I was struggling trying to lose weight. And just like my old habits kept pulling me back, my client’s habits are doing the same. For them, Agile is hard.
One approach that has influenced me more than others is Robert Keagan’s “Immunity to Change”. Here’s a short summary:
We often set out to achieve specific goals. After a while, we discover that we are not achieving those goals, even though we might care deeply about them. When we stop to investigate what is going on, we discover that our actions are not in line with what we are trying to accomplish. We might act in a way that is actually opposed to what we say we want to achieve. Immunity to Change helps us look at our actions and derive so-called competing commitments from them. Those are hidden goals that we have and that guide our actions but that we are not consciously aware of. These competing commitments make us work against our actual goals. We subconsciously follow these competing commitments because we have deeply held values and beliefs that inform our actions on a deeper level than our espoused goals.
In my case, I seemed to value staying lean and eating a healthy diet. But over time, I discovered that I had tons of competing commitments. For example, I noticed that I would always finish food on the table even after I was clearly full. The thought of wasting food bothered me so much that I would rather endanger my health than throw it out. Nowadays, I know that there are other options, like eating it the next day or giving it to someone else. But those options would never occur to me back then. I was essentially blind to them. And so I would eat way too much even though I didn’t want to.
I also noticed that parties and family gatherings were always really tricky for me. Those were moments when I would overeat like mad. There is a Liberating Structure in development inspired by Immunity to Change. It’s called Talking With Pixies [the link is going to open a Word document]. There was a moment in our Liberating Structures User Group in Hamburg when we were using it and two guys were giving voice to the silent competing commitment in my head. I had told them about my issues with declining food that someone else had prepared. Behind my back those two guys were going at it, saying things like “Do you really want to break someone’s heart by rejecting food they lovingly made? What kind of person are you? Just take a bite!” I laughed but I actually wanted to cry. It was a painfully accurate manifestation of the actual voice in my head.
Gaining awareness of those competing commitments helped me tremendously. Whenever I encountered a tricky situation I was able to identify what was going on. “Yup, that’s the voice. I would rather gain weight than endanger a relationship by declining food.” And suddenly, I had a choice. I could act on my first impulse or I could choose something else. Increasingly, I started choosing something else.
What Makes Agile So Hard
My clients make a commitment to Agile. But they are full of competing commitments. And that is the thing that makes Agile really hard. Sure, they want all the benefits of working that way. But that usually means they have to let go of old behavior, values, and beliefs. And those are not only ingrained in people’s minds, they manifest in the company’s structures. Making Agile work would mean a tremendous change. Often, those companies are not ready for that change.
Let me illustrate what I mean. While there’s an overt commitment to Agile within an organization, the dominating paradigm optimizes structures and behaviors for predictability and efficiency. Agile optimizes for flexibility and effectiveness. And this causes friction. Without the existing paradigm, Agile would be easy. With the existing paradigm in place, it becomes hard.
If your company is struggling with Agile, I can practically guarantee that it is related to at least one of the following points:
- Frequently producing working and fully integrated increments within a short time frame
- Transitioning from individual siloed experts or component teams to cross-functional teams
- Limiting work in progress, prioritizing opportunities or work items as a consequence of the limitation, and then actually sticking to prioritization
- Confusion regarding roles and decision-making authority caused by the (theoretically) increased autonomy of Agile teams
- Putting Agile teams in direct, frequent contact with customers or markets (note that I’m not talking about internal customers here, see our post on Stakeholders)
Why do I know that you are struggling with these issues? Because they are typical of organizations that try some form of Agile but actually optimize for predictability and efficiency. Are people within the system aware of this? Most likely not. But the structures and habits reflect the values and beliefs. When you are “certain” about what you want to release you neither have to be in touch with customers nor release often. Customer Distance doesn’t matter. You can ship large batches infrequently and don’t need to worry about dynamic reprioritization. Just cram as much as possible into the next release and then repeat the cycle. Make sure your experts are busy at least 100% of the time. Hand them fragmented pieces of user requirements but never give them any end-to-end responsibility.
This won’t work well with Agile. But these are solvable challenges! Trivial even for a few companies. What is interesting is what makes them so challenging for most organizations. And that is where the competing commitments come into play. While there might be a goal to change the paradigm, people will get pulled into old behavior all the time. Or they won’t change organizational structures that inhibit agility, because they are unable to see how these structures are optimized for something else.
People engaging in these behaviors are trying to be successful. However, that behavior is not aligned with the organization’s commitment to Agile. And that is precisely what makes Agile so hard. Not building it from the ground up – which is often relatively easy – but changing from one paradigm to another.
The False Allure of Agile
Getting started seems so easy: just pick an Agile framework and get going. The Scrum Guide is only 13 pages long! Kanban only has six practices!
It’s as easy as losing weight. Just eat less and move more! Have more vegetables and fruits!
There’s a quote that I used to share that has been removed from the Scrum Guide:
- Simple to understand
- Difficult to master
Whenever I introduced Scrum to a group, this is what I would show them. I wanted them to prepare for the way ahead. I wanted them to know that it wouldn’t be easy and that struggling didn’t necessarily mean they were doing anything wrong. The same applies to Kanban, of course. Yes, it’s an evolutionary approach. No, that doesn’t make it easier. Maybe easier to get started, but probably not easier to make a significant change in the long run.
As Agile Coaches we should give the people we work with a realistic expectation of what they are getting into. Otherwise, we get what we see now: people questioning whether Agile has ever worked anywhere.
The journey is tough. But we can help people by being honest about what awaits them. We can help them by figuring out what success they are striving for at the moment, how that is reflected in their values and structures, and what would need to change for Agile to work. We can help them identify competing commitments and prepare them for the fact that there will be forces working against their success.
If we don’t, we will turn into the equivalent of the diet industry that has been selling magazines, ebooks, supplements, videos, and false hopes for decades. We are advertising the next flashy approach that doesn’t solve the underlying problem and leaves people dissatisfied, only to start selling the next thing. Come to think of it, maybe that is what we are doing already.
This is the third 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.
This is the third blog post in the series and we will be exploring the second factor: “Agile” has lost its meaning.
A New Client
I had worked as an internal Agile Coach for several companies before I went on to become a consultant at Holisticon in 2016. One of my first clients wanted to go all-in on Agile. They assured me that they were truly committed multiple times. I was excited.
When I start to work with a new client I try to orient myself within the system first. If I’m working with a team, for example, I try to get a picture of the value stream as a whole and how that team is positioned within it. How far away is the team from customers? How far does the Definition of Done stretch?
This particular team was part of the “build” unit. It was sandwiched between “plan” and “test and run”. There were clear handoffs between those units. The team was essentially following a Waterfall approach by pulling work from a pre-existing requirements document, that had been created years ago, and then handing big batches over to a testing department.
A structure like this is typical of a plan-first approach to software development. Functional silos are established to optimize for efficiency and optimal resource allocation.
While this kind of structure might work for problems that can be analyzed upfront, it causes problems when you try to cram Agile into it. Due to the compartmentalization, it’s pretty much impossible to get quick customer feedback and deliver potentially shippable increments this way.
But the client was committed to going full Agile. They had said so multiple times. And so I started my work. I reached out to people up and down the value stream. The folks from the “plan” unit were very interested in seeing earlier results, gaining more transparency regarding the current development status, and being able to adjust things along the way. One person told me “Listen, just between us, I can never remember what I put into these requirement documents two years ago or why things are even in there in the first place. At that time, it seemed like a good idea but now I’m not so sure at all.” We established regular contact between business people and developers. Things were going great.
The people from the “test and run” unit were more skeptical. They weren’t really equipped to process small batches and give quick feedback. The person there told me they would discuss my request to collaborate more directly internally and then get back to me. And so I waited.
A few days later, the people who had hired me called me into their office. They wanted to know what the hell I had been doing. Had I talked to people in other units without consulting them first?
Without knowing, I had committed a major infraction: I had talked to a member of another unit directly. This was against protocol. The right way to do it would have been to talk to them first so that they could talk to the other person’s manager. Only then would I possibly be allowed to contact that person and schedule a meeting, most likely supervised by someone higher up the chain. And what was I doing talking to “test and run” anyway? They had hired me to work within “build”!
I was baffled. Lost for words. As much as I wanted to blame them, I also realized that I had never shared with them what I was trying to accomplish. As a sort of explanation, I started drawing their value stream. I explained how Agile is about shortening feedback loops, getting closer to customers, delivering more value, being able to respond to change. Wasn’t this what they wanted? You know, Agile..?
Their response? No, that is absolutely not what we want. We want Agile! You know, taking items from a requirements document and translating them to user stories. Measuring velocity. Indicating if we’re still working according to plan. And if we are not, correcting course so that we stay within the plan! Agile!
My jaw dropped. In that one moment, I suddenly understood that my idea of what Agile is, what success looks like, and what needs to be done to get there, varied fundamentally from other people’s ideas. All the people involved in this situation used the word “Agile” but our definitions of it were not even close to the same. In many ways, they were polar opposites!
One could argue at length about which definition of Agile is more accurate or more helpful. The bottom line is that all of us had made implicit assumptions based on our own understanding. Neither of us had bothered to check with the other party whether our expectations aligned. I vowed never to make that mistake again.
(Spoiler alert: I made that mistake again. Multiple times.)
Now being sensitized to this issue I saw it popping up all around me. Not only while working with clients but also while working with other Agile Coaches. The term Agile had so many different interpretations and value statements attached to it that it led to countless misunderstandings. And in my opinion, this contributes enormously to the current wave of disappointment. When we are not aligned on what it is that we are trying to achieve, how can we be successful? How can we work together?
The fact that the term Agile has lost its meaning was yet another thing pointed out by Craig Larman when I visited his LeSS training in 2017. He started the training by giving his definition of the term and the associated goals that derive from that definition. It turned out to be so fundamental that we constantly referred back to it during those three days. Most of the arguments were settled by asking whether a certain approach would be consistent with the goals derived from that definition or not. It made debating so much easier because the argument never turned into an Agile vs. Non-Agile battle.
Similar to Agile’s rise in popularity and its movement through the hype cycle, the lack of clarity regarding its definition is not specific to Agile. I recently encountered the term “Concept Creep”, which is used in psychology and captures this dynamic really well: A term initially has a very specific meaning, but as its use enters the mainstream it becomes increasingly vague.
The same thing that is happening to Agile is happening to OKRs. This is not theoretical. I see it with my clients all the time: 30 Objectives with hundreds of output-focused Key Results. We used to call it a roadmap, now it’s OKRs. Nothing has changed.
Or take the term “Minimum Viable Product” (MVP) that was popularized by Eric Ries in his book “The Lean Startup”. Anyone who has actually read this book knows that he talks about the MVP as something that enables a company to go through the Build-Measure-Learn loop as quickly as possible: “The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.” Nowadays, for basically all organizations that I see, the term MVP means slightly reducing the scope of a product that gets shipped in its entirety to customers in one big batch without any prior interaction, just like before. The “learning” is delayed until everything is developed, tested, and delivered.
There are two expectations of Agile I see most frequently that cause the most disappointment: increased efficiency and increased human connection. Let me give you a quick summary of what these two are and why they frequently turn into a problem.
The hope for increased efficiency is very popular in organizations that are plan-driven. They look for a way to use the same resources but generate more output. This is supposed to help them deliver on their plans faster. What it really does is cause Zombie Agile. Christiaan, Barry, and I go into more detail in our book about Zombie Scrum. Here’s an excerpt that explains the concept of the efficiency mindset.
The second expectation is one of increased human connection. Agile is supposed to make the people in an organization feel better. Any kind of asymmetry like status, power, and expertise is seen as something that needs to be abolished. Everybody talks all day long but no one actually gets any work done. Christiaan, Barry, and I started calling this “Happy Clappy Scrum”. Since the two of them are not showing any initiative to make this the topic of our second book, I’m running with it and stealing all the thunder. More about this soon.
From my own example, the other examples from the industry, and the two popular expectations of Agile I outlined, I hope it has become clear that we always need to clarify what we mean when we say Agile.
Here are questions I use with my clients when they say they want to become more agile:
- What problem is Agile going to solve for them?
- How will they know when their problem is solved?
- What does it look like when their Agile transformation is “done”?
- Is there any way for them to measure that success?
- How close to that state are they?
- How much are they willing to invest in order to get closer?
- What is Agile not?
If you’re active in some kind of Agile environment, I invite you to explore these questions with other people. I really believe we need to move from a binary “Agile is there or it isn’t” definition of success to one that makes transparent what we are actually trying to achieve.
We cannot assume that other people mean the same thing we do when they use the word Agile. Clarifying what we mean helps us reach a consensus on what it is that we’re actually working towards. It helps us work together. It diminishes the tendency to distinguish between Agile and non-Agile people. We all just want to be successful together, now let’s select the appropriate methods!
Once we have a shared definition of success we can get to work. Or we can decide that Agile isn’t for us. The company I mentioned in the beginning and I parted ways. We gave each other the “It’s not you, it’s me” speech and waved goodbye. Not much has changed there since then.
Sometimes the change needed to make Agile work is too high. Agile is really hard! And that will be the topic of the next post.
This is the second 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 this blog post, I explore the first of these four factors: Agile’s current popularity.
This is going to start out depressing. But I promise towards the end it will turn around!
Fighting the Enemy
My parents weren’t hippies. But I was raised in a very progressive environment with a clear ambition to change the status quo. We said no to nuclear power. We ate organic when that was barely a thing. And we were definitely feminists. At the same time, my parents were adapting to the fact that their generation hadn’t managed to overturn capitalism and eradicate social injustice. Love wasn’t all you needed. The system was stronger than expected.
I grew older. Most people do, I guess. One fateful day, my brother introduced me to Rage Against the Machine. Zac de la Rocha screaming “Waaaake up!” blasted out of the speakers and my eleven-year-old brain was changed forever. To me, Rage Against the Machine is the thread that weaves protest and counter-culture through the Nineties. Nowadays, ticket prices to their stadium shows are so high that the underprivileged people they have been fighting for can’t afford to see them live. They didn’t manage to change the system. The machine is still chugging along. It just incorporated their rebellion and managed to sell it for a profit.
When I started using Agile around 2010, the enemy we were fighting was Waterfall software development. To me, it seemed like Agile was the new right thing that was going to supersede the old wrong thing. We were going to transform the world of work forever!
That was what I believed until I had to work with actual project managers. The people I met were pragmatic and intelligent. And most of all, they made actual software appear despite all Agile claims to the contrary. They knew about the shortcomings of a plan-first approach, knew how to mitigate some of the issues they were seeing, and were generally very open to any new input. They were infuriatingly different from the enemy I had envisioned.
These people cared about results. And so they were curious to learn about Agile. They pointed out that few of the ideas being passed around in the Agile community were entirely new. They had seen new methods come and go. Agile was just one more thing. Interesting, and possibly useful, but not as groundbreaking as people made it out to be.
By this time I realized that “Agile will transform the world of work forever!” wasn’t quite as simple as I had once believed. There had been other approaches before Agile that were supposed to change everything. They didn’t. There was Total Quality Management. There was Business Process Reengineering. There was Lean. Now there’s Agile.
It feels incredibly ironic that Agile, for a lot of people, is now becoming the enemy. We were the underdogs. We were going to fight the oppression, just like my parents and Rage Against the Machine.
Now we have become the new norm, the old wrong thing that will be superseded by the new right thing. People are rebelling against us just like we were rebelling against the enemy of Waterfall development.
What can explain how we went from being the underdogs to being the establishment within a decade?
The Hype Cycle
In 2017 I went to the Certified LeSS Practitioner training with Craig Larman, who has been in the game a lot longer than me. One of the things he talked about was how Agile is currently going through the The Gartner Hype Cycle, which is often used to “represent the maturity, adoption, and social application of specific technologies”. It seems to apply well to Agile.
Additionally, as many people have pointed out, Agile has already been added to the extensive lists of approaches that are considered management fads. Sadly, Agile ticks most of the boxes and I can’t help but feel a sinking feeling in my gut when I read about it.
Now we are left with the deeper question of why organizations are drawn to these fads. They seem trapped in a cycle of clinging to ideas, not seeing the expected benefits, and then moving on to the next thing. As a consultant I get to see many different organizations from the inside. There are things few people talk about openly. These include:
- Most organizations are significantly less professional than the image they project towards the outside will have you believe. The employees believe that other organizations have found the answers while their own struggles. They are constantly looking for something that will finally give them orientation and guidance so they can catch up.
- An organization will never be “done”. There will always be more problems. Organizations will never reach the point when everything has been figured out and simply locks into place. Management implicitly assume that a change initiative will finally provide the solution and put a definitive end to at least one specific problem, if not to all. As this doesn’t happen there is always a need for new approaches that will finally usher in the elusive era of done-ness.
- In most organizations, it’s dangerous to admit that there are things you don’t know and you don’t have control over. It’s your job to be in control and have a plan. As a result, people look for something that has already proven itself and seemingly works well elsewhere. But since they’re acting under pressure, they do not take the time to study the approach in enough detail. The implementation fails. People blame the method. They look for something new.
For now, let’s assume these three things are true. To me, this explains pretty well why certain approaches suddenly become popular, fall out of favor, and get replaced by something new.
With its rise in popularity, Agile could never deliver on all the things people expect of it. Nothing that is caught in that hype cycle can ever fulfill all hopes. In a way, it simply has to fail because the expectations projected onto it are so high and become more absurd as popularity increases.
It’s Not Just Agile
If Agile itself was the problem and simply didn’t work, this dynamic would be specific to Agile. It’s not. We have some recent examples of the same thing happening to other approaches as soon as they become popular.
I started trying out Objectives and Key Results about five years ago. Not many people had heard of them, so I wasn’t surprised to see that using them effectively was difficult for my clients. But then two years ago everyone started asking about OKRs. All implementations I’ve seen so far had nothing to do with even the most basic ideas behind OKRs. Just like Agile.
OKRs have become popular and the same thing that is happening to Agile is happening to OKRs. Christina Wodtke is one of the most influential people when it comes to OKRs. Read her post on the topic in which she outlines the exact same thing.
Remember that my impetus for writing this series of blog posts was the increasing number of people doubting whether Agile has ever been fully used anywhere. I’m fairly certain this, again, is something that happens to any approach that reaches a certain threshold of popularity. Let me give you another recent example.
Teresa Torres publishes some great work on the topic of Product Discovery. Here’s a quote from one of her recent posts:
“Product thought leaders talk about an ideal way of working. Nobody actually works that way.”
I can’t tell you how many times I hear this sentiment on Twitter and LinkedIn. And I hate it.
I realize that many product people have never worked in a product trio, don’t have access to customers, aren’t given time to test their ideas, and are working in what Marty Cagan calls “features teams” or “delivery teams”.
And just the same, many people do work in product trios, interview customers, test their ideas, and work on empowered product teams.
Both are true. The reason why it’s so hard for the first group to believe that the second group exists is because they’ve never seen it.
But just because you’ve never seen it or experienced it, that doesn’t mean it doesn’t exist. Especially when your experience only spans a half a dozen or so different workplaces.
The Good News
Realizing that Agile is not the “one true way” and will not transform the world of work forever might be disheartening at first. But remember, I promised to turn this blog post around towards the end.
My parents’ generation didn’t change the world, eradicate social injustice, or put an end to war. Neither did Rage Against The Machine. But so many of the topics I was exposed to in my youth are part of public discourse now. It took longer than expected and didn’t exactly go as planned. But there has been progress.
Agile might come and go. But if we widen our view, we can see that it is part of a larger dynamic. Doing so helps us stay open to new ideas, new developments. Agile might morph into something that’s possibly even better. The next step on the ladder. This is something we may miss if we believe Agile is the only thing that really works.
And we shouldn’t discount the change we have already affected. More people are working in cross-functional teams. Deployment times have gone down considerably. The number of releases a year has gone up. New organizational structures are openly discussed and tried out. There is increased talk about psychological safety and values.
Sure, we didn’t break the entire system. But we put a noticeable dent in it. Let’s stay open to what’s possible. Let’s make more dents!
This blog post is the first in a planned series on the current state of Agile. In it, I look into the changing dynamics of how Agile is being perceived in the world of work based on my own experience and history of working with it. This lays the groundwork for exploring the problems we are facing in more depth and looking at options we have for making Agile work more effectively.
Agile Finds Me
My journey with Agile started in 2010. I was in the middle of my 18-month training to become a project manager. My first project went poorly, and I was seriously reconsidering my career choice. By sheer luck, I happened to read an interesting article about “Agile project management”. That same day, one of my colleagues from a different division showed up late for our scheduled lunch. He said, “Sorry, I had to attend our Daily Scrum.” My eyes widened. After a lot of prodding, he promised to introduce me to the external consultant they had hired to help them become a Scrum team. A few days later, I found myself in the office with a charismatic guy slightly older than myself explaining what Agile was and what a Scrum Master does. I remember walking away from that meeting, literally shaking with excitement with a singular thought stuck in my head: “That’s what I want to do!”
By no means was I one of the pioneers of Agile. But back then most people hadn’t heard of it. The ones who were exposed to Agile thinking usually reacted by saying how it might work for really small startups. No professional company would ever do anything like that. “A hacker’s dream,” as one of my project management colleagues called it.
Agile Grows Up
The work back then was about establishing Agile as a legitimate approach to developing products. The company I worked for saw good results. Most of the developers were happy and said they would never go back to the previous way of working. The guy who first introduced me to Agile and then mentored me played a big role. The team he worked with shipped a piece of software with zero defects in production. Not only that, the people who had to use it actually liked using it. That achievement alone was so shockingly different and completely unheard of that even the CEO took notice.
Agile delivered results. It felt new and we were going to transform the world of work. But then something shifted. Slowly but surely Agile crossed the chasm and made it into the mainstream. When people asked what I was doing for work I started getting reactions like “Oh, yeah. I know what that is. Our company is trying to do something like that right now.” And then, much to my bewilderment, nine times out of ten, the next sentence would be “It’s not working very well.”
Suddenly, Agile was everywhere. And people were struggling. They didn’t have the positive experience I was fortunate enough to have. Christiaan Verwijs, Barry Overeem, and I published our Zombie Scrum Survival Guide to do our part to help. Our main goal was to show what healthy Agile (or Scrum in particular) looks like and how so many companies go astray. We tried to put a humorous spin on the situation and used the metaphor of zombification because people seemed to react well to it.
We fixed the problem and rectified Agile. Everybody is happy.
Agile Goes Off the Rails
Okay, actually kind of the opposite happened. It seems like something is shifting again. I hear fewer voices saying “Agile isn’t working for us.” Now people say “I don’t think Agile has ever worked, anywhere.” Whoof! Like Agile is some textbook theory that only exists in a fantasy world. Like people sitting at a desk made it up and are now trying to sell an idea that has no connection to the real world whatsoever. How did we let this happen?
It seems like the reaction from the Agile community is to explain how these people are wrong and misguided. “They just don’t get it, otherwise, they’d be on our side.” Unfortunately, this doesn’t seem to help very much. It just widens the chasm between believers and non-believers. And it steals our focus from the more important fact that, in the end, all of us just want to be successful.
Let us first acknowledge that these experiences are real. People are genuinely struggling. They’re being subjected to something that they find unhelpful at best, and at worst very harmful. If you’re reading this and have been part of some form of Agile transformation that makes you question your sanity, I am deeply sorry. We haven’t done a good job of transmitting the actual intention of our approach. You should come to work in the morning and enjoy a process that lets you do your best. A process should be there to serve you, not the other way around.
What’s to Come
In a series of blog posts, I would like to offer my perspective on the situation and some underlying reasons. As I see it, there are at least four things that contribute to Agile’s apparent failure:
- Agile is popular
- The term “Agile” has lost its meaning
- Agile is hard
- We are bad at explaining Agile
There is obviously no easy fix for this. I’m also not arrogant enough to believe that I can turn this dynamic around by myself. However, I’ve learned in my work that transparency is a great first step. Let us look at what is happening, make sense of it, and then explore ways of improving the situation together. There’s still hope!