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.
Faux pas
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.)
Concept Creep
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.
Uncovering Expectations
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.
Defining Success
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.
