Agile (is dead|sucks|is (🐂|)💩|is irresponsible|is a bad idea)

You get a regex... and you get a regex...

The Simpsons copyright ©20th Century Studios - Fair use

Another significant theme to emerge from from my April 1st AgileAI experiment was an indication of the backlash against Agile itself and its use in the software industry.

I’m seeing this with increasing regularity in forums such as Reddit and on social media. Here are two recent examples from LinkedIn:

From Ivett Ördög:

Declaring that "Agile is dead" evokes emotions. On one hand it evokes anger from those who experienced their first productive times in teams that declared themselves agile, and desperation in those who made a career out of teaching agile. On the other hand it evokes a sense of relief in those whose current lived experience is that of frustration, stress and potentially failure, and that lived experience is valid even if what they do is not what I would call agile.

Teams should always feel like they are the most weirdly effective team they have ever experienced.

And that... that is my mission! I want to help teams not just be effective, but also feel proud of what they can achieve. If we call that agile or not, that is beside the point.

And from Klaus Leopold:

The current economic situation is challenging, and many companies are laying off employees, including numerous external consultants and Agile coaches. Here’s why I believe this is happening.

❌ Insignificant Contributions: Many Agile coaches provide good tips on how to draw colorful posters but do not significantly contribute to value creation and are, therefore, among the first to be dismissed.

❌ Obsolete Roles: Individuals who hold positions dependent on outdated methods are often let go.

He goes on to draw conclusions from those points:

👉 Focus on selling value, not time: Companies are seeking value, and aligning with this need is essential.

👉 Results over methods: Concentrating on delivering measurable outcomes instead of "installing" methods is more important than ever.

👉 Do not cling to outdated (Agile) methods: Times are changing, and what companies were willing to invest in 10 or 20 years ago, they no longer need today.

In Ivette’s case, I’ve experienced multiple times what she states as the goal of her work from this point forward: teams that are not just effective, but proud of what they could achieve. That’s what led me into coaching teams in the first place!

With Klaus, note that he uses the term “outdated” a couple of times, with specific mention of the timeframe of 10-20 years ago.

Well, what I’ve experienced that was effective and made teams proud of their achievements was an approach that would still be recognizable to those who released it to the world 25 years ago in 1999. It was Extreme Programming (XP). And, yes, here goes Dave talking about XP yet again! 😂

To be clear, what I do now in 2024 would still be recognized as XP with the following exceptions:

• Working as an Ensemble has replaced Pair Programming in many instances;

• The original System Metaphor practice has been replaced by, at the very least, Ubiquitous Language from Domain-Driven Design (DDD), if not completely by DDD;

• The Planning Game for releases has been significantly augmented with the Product Discovery and Story Mapping practices from Jeff Patton, among others;

• Estimation with Ideal Days or Story Points as described in early XP literature has been replaced with simply counting User Stories completed for lower-level tactical use and Probabilistic Forecasting for higher-level estimation;

• The concept of Small Releases is still good, but Continuous Delivery is even better when it can be practiced;

• Limiting iterations (sprints in Scrum) to 1 week in order to truly expose the impediments to delivery, or eliminating iterations altogether and working in a continuous flow mode.

Otherwise, the XP values and practices still apply today as well as they did in 1999.

So why am I telling you this? Well, the backlash I see against “Agile” is typified by the statements in the butt-ugly regex in the title of this post. The cases where that backlash occurs are almost always where groups that say they’re using Agile actually mean they’re using Scrum. In most of those situations, they aren’t using Scrum very well, or certainly aren’t following the spirit of the process.

On the AgileAI.ca site, I responded with this message when someone complained about how terrible Agile is:

Sigh. I'm sorry the world has been so mean to you. If by 'agile' you mean terribly implemented Scrum, then yeah I can see how it would suck to you.

And I meant it. As a coach, I’ve witnessed terribly implemented Scrum numerous times and have, in some cases, been able to help teams clean up the mess by sprinkling in some XP!

I can certainly start by saying that, in XP, there are fewer defined meetings than in Scrum. Part of the reason for that is the notion of being colocated as a group so that communication and collaboration is “organic” rather than requiring a scheduled meeting. That’s more difficult now with the move to remote work, but certainly not impossible. For example, I’ve worked in situations where we left a call open all day as a virtual team room so people could attend when they wanted to be able to have the conversations they might have if they were physically together.

XP’s Planning Game also provides a structured approach to determining what work is needed and when, whereas Scrum is silent on the topic. I have yet to see the approach of “throw ‘stuff’ in a backlog and refine it as you go” be effective. I have, however, seen Release Planning from XP provide clarity and focus at the team and organizational levels. The caveat, of course, is that any plan is just a snapshot of what we know at that time and it will change!

It’s worth noting that XP doesn’t have anything resembling a ScrumMaster role, although there is a Coach. The XP Coach, as I recall, was intended from the start to be temporary, intended to help get the team off the ground and keep them on track with the process and practices until they could fly on their own. When I first applied XP with a group, I was a developer and thus became a player/coach. I now many others from that time who did the same. As the teams became comfortable with the process, I became player more than coach.

Another complaint I heard on AgileAI.ca and have read elsewhere is about how rigid Scrum is. I don’t disagree, but I have to laugh at the statement because Scrum’s whole purpose is to provide a means to empirically assess what works best for an individual team (Inspect) and adjust how they work (Adapt) into an approach that’s most effective for that group of people on their work in that domain! I’ve often said that, if you’re doing Scrum the exact same way you did it a year or even 6 months earlier, then you aren’t actually doing Scrum!

So, the rigidity people experience with Scrum is more likely the rigidity of the people who are handling the process for the team. That could be the ScrumMaster or a coach who doesn’t understand Inspect & Adapt who’s working with the group. It could also be the influence of the organization in which the team resides.

But rigidity isn’t necessarily a bad thing when you’re starting a new way of working. My introduction to XP was through the book Extreme Programming Installed, by Ron Jeffries, Chet Hendrickson and Ann Anderson. That book’s approach can be summarized as, “Here’s what XP is, and here’s how we applied it”. That resonated with me better than the original Extreme Programming Explained’s more theoretical view, but that’s more my preference than a general view. There is plenty of excellent material in the latter book as well!

After learning about XP in 2000 and trying some of it’s practices, it wasn’t until 2001 before I had the chance to really apply the whole approach. When I did, with buy-in from both the business people involved and the IT folks, it was a resounding success. We didn’t start by immediately discarding practices that we didn’t like, but instead tried to do XP quite literally by the book. We did have to make allowances for such issues as having an odd number of developers, so we couldn’t pair program all the time, but in general that was the only significant deviation.

Over time, though, we recognized where we could improve how we worked together and adjusted. The code, for example, already had decent naming that reflected the business domain, so we didn’t need to continue using a System Metaphor. We had a weekly meeting that existed before starting to use XP, so we didn’t always need to have a daily standup (though that isn’t an original XP practice). We would simply have conversations when necessary, which was aided by the fact that we were already colocated. Any time we thought about deviating from the XP practices, we’d look at the Agile principles and figure out how to change how we worked while still adhering to them.

Even back then, though, there were complaints about XP and Scrum not working for teams. In many cases those teams either weren’t or weren’t allowed to actually use the practices from XP or Scrum! Ron Jeffries, the original XP Coach, wrote a fantastic article describing that problem called, “We Tried Baseball and It Didn’t Work”. I recommend reading it - it’s as pertinent now as it was nearly 20 years ago.

---

So, for those who are currently feeling that Agile as we know it in 2024 should be abandoned, I truly understand how you feel. What passes for Agile today is the type of rigid, process-centric approach that led to the creation of lightweight methods in the 1990s and Agile itself in 2001. I, too, want that to change!

I would suggest that you visit or revisit Extreme Programming to find out what we really meant by “agile methods” when the term was coined. It was about effective software development, not just a management approach!

I’d also suggest this recent talk from Amitai Schleier called “Not So Extreme Programming” that may help you get past XP’s choice of name.

We already have the alternative to 2024’s version of Agile. Many of us have been practicing it all along. I suggest that you look into it as well.