The Agile Community Shat The Bed

Agile isn’t dead, but the agile gold rush is, and it isn’t coming back. There, I said it. In this article I share my observations about why we find ourselves in this mess. I hint at some solutions, but to be clear I’m going to dig into solutions in two follow-up articles.

You likely know me as the co-creator, along with Mark Lines , of the Disciplined Agile (DA) toolkit.? For those of you who have been around awhile, you may also know my work in Agile Modeling , Agile Data , and the Unified Process.? I’ve been an active member of the agile community since the beginning, and at times have been a vocal critic along with many others, of the issues I discuss below.? As you should gather from this article’s title I’m blunt and not shy about using colourful language.

So, how did the agile community, a group of very intelligent people, many of whom were doing their utmost to help others, manage to shit the bed?? As a community, we made these mistakes:

1.??????? Too much agile certification, not enough education

2.??????? Too much framework adoption, not enough improvement

3.??????? Too much fluff, not enough stuff

4.??????? Too much purity, not enough agility

5.??????? Too many fads, not enough grounding

Too Much Agile Certification, Not Enough Education

Let’s begin with the elephant in the room: agile certification. The agile gold rush started with the Certified Scrum Master (CSM) scheme.? People would take a two-day workshop and be declared Scrum Masters (back then ScrumMaster was two words).? Wow, stay awake for two days in a workshop and suddenly you’re a certified master, what’s not to like about that? At one point a Scrum training company certified their dog, it had attended many Scrum training sessions and thus was more than qualified at the time to be awarded the title of CSM. In short, CSM wasn’t earned, it was bought. Eventually the Scrum Alliance upped their game and added a simple test that was sufficiently difficult that house pets would fail it but anyone with a pulse wouldn’t. Sadly, the CSM set the pace for other agile certifications because it became very clear that you could make a lot of money selling light-weight certifications, and do so at scale via Amway-style pyramid schemes. I even ran an agile certification scam myself. ;-)

The people involved with these questionable agile certification schemes had many hollow rationalizations for their behavior:

1. My certification class is three days, not two. So that’s 50% less of a scam?
2. Companies are asking for it, buyer beware. Yes, because these companies trust that an industry recognized certification has been vetted.? Few organizations measure the impact of certifications and few have HR groups that are experts on the multitude of certifications that are out there. The agile community was effectively taking advantage of, rather than helping to address, a significant weakness of their potential customers.
3. Nobody believes you’re an actual master/professional/… Obvious bullshit. If that was true then hiring organizations wouldn’t have been asking for these certifications.? I worked with many organizations over the years, and every time I walked them through the processes that people went through to gain the agile certifications that they required of candidates they were appalled by how they had been misled. When they didn’t believe what I told them, I suggested they verify for themselves. In short, people were clearly being fooled and the people involved clearly looking away. Worse yet, there were tens of thousands of people who took an agile certification class and then quickly turned around and marketed themselves as an agile coach.
4. There’s a test, so the certification is in fact being earned. That depends. If the test is so trivial that it has close to a 100% pass rate, then no.
5. Every other industry does this. There are a handful of domains where there are similar certification scams occurring, but they’re in the minority.
6. That’s the norm in the agile community. Sadly yes. The point is that we could have chosen to do a lot better, but our unmitigated greed won out.

This isn’t to say that certifications aren’t useful. In fact, the earning of a certification can be a valuable part of someone’s overall learning path. Good certifications are earned, and hopefully re-earned over time to ensure you remain up to date, they’re not bought. There are some agile certifications that are in fact earned, for example I believe Scrum.org does a fairly good job of this.

It also isn’t to say that there weren’t some respectable agile certifications being offered. Unfortunately, they were nowhere near as popular because you had to actually earn them rather than buy them. ?There are also a lot of great training offerings out there that have nothing to do with certification, but they’re hard to sell because of the lack of certification. There are many great trainers out there that have had to resort to getting involved in these certification schemes simply because they couldn’t sell their great training without it.

To summarize, one reason why the agile gold rush ended is because organizations have finally learned that most agile certifications aren’t worth the PDF file they’ve been output to.

Too Much Framework Adoption, Not Enough Improvement

For the sake of this argument, wherever I use the term framework you can replace it with method and the point still applies. In short, framework adoption isn’t transformation. Framework adoption, or more accurately selling training and coaching services to support it, is another pillar of the agile gold rush that has crumbled recently. The marketplace has finally acted on a few hard-earned lessons:

1. Agilists over-promised and under delivered. Twice as much in half the time? 10x productivity improvement?? Really?? Those are great anecdotes, and I have in fact run into organizations that were so messed up that significant improvement was reasonable. But few organizations are in that shape when they are then pretty much any strategy will help reduce organizational incompetence. Most organizations spent a lot of time and money on framework adoption only to gain incremental improvement at best.
2. The frameworks weren’t a good fit in many cases. Every framework works well in certain contexts, one size does not fit all. Just because a framework worked for someone else that doesn’t mean it is right for you, no matter how cool the poster is. A given framework may be a reasonable fit for one part of your organization, but certainly not your entire organization. That framework may be a reasonable fit for you today, but as your situation evolves there needs to be a coherent strategy to evolve your way of working (WoW) along with it.
3. Agile likely wasn’t a good fit anyway. At the height of the agile gold rush the leadership team in many organizations decided that they needed to “get us some of that agile stuff.” They didn’t really know what agile was, why they needed it, or what they would do with it once they had it, but they wanted it now. It was an easy sell to convince these marks, oops I mean customers, that adopting an agile framework was the fastest way to become agile.
4. Agilists, like the leadership who hired them, didn’t have a change management background. Anyone embarking on anything that smells of an organizational transformation, or even the adoption of a framework, should have a background in change management. There are lots of great change management sources out there, including the fantastic work around lean change management by Jeff Anderson and Jason Little, as well as the more robust material of Prosci. To be blunt, organizations led by senior managers without significant change management experience were hiring agile coaches who also had little background in change management and things generally went poorly from there. And I’m more than happy to let the agile transformation failure rate speak for itself.

Luckily many in the agile community didn’t sign onto the framework adoption release trainwreck. They helped people learn how to improve on a personal level and how to collaboratively improve at the team level.? Some of the more senior and experienced agile coaches helped people learn how to collaboratively improve across teams.? ??

To summarize, another reason why the agile gold rush has ended is that organizations have learned that there is more to improvement than simply installing agile frameworks.?

?

Too Much Fluff, Not Enough Stuff

First, a shoutout to the folks who organize the No Fluff, Just Stuff conferences which influenced my wording of this point. Too many agile coaches took the first value of the Manifesto for Agile Software Development , individuals and interactions over processes and tools, to the extreme. They choose to focus on the “softer”, people-oriented side of agility rather than the “harder”, technical side. As a result, we ended up with teams of people who struggled, oops I mean they failed fast a lot, but at least they felt good about themselves. Nice for them, not so great for the organizations that paid their salaries.?

The agile community has many platitudes to justify this focus on fluff:

1. Soft skills are important. This is certainly true, and arguably more important than hard skills in the long run. But, in the short run you need the skills to do your job today, and that includes hard skills. People need training and coaching in both.
2. You can pick up hard skills on the job. Yes, but you need help doing so. If my organization has hired an agile coach to help my team become agile, then my expectation is that the coach has the background to do so.? They need to know their stuff, not just the fluff.
3. Hard skills are easy to learn.? Really?? Then get of your ass and learn them. FFS.
4. You can learn hard skills via training. Yes, training can provide a great start to your learning journey.? But, for every agile training workshop in technical skills such as TDD there’s easily one hundred workshops overviewing an agile framework such as Scrum or SAFe.
5. Coaches don’t provide solutions, they help the team discover.? Complete fracking BS. Good coaches make suggestions.? Good coaches know multiple ways to address a problem.? Good coaches have years of actual experience in what they’re coaching.? Good coaches almost have almost always been educated in what they’re coaching.? And yes, good coaches also help the team to discover. Several times I ran into software development teams being coached by someone who had never written a line of code in their life. Who the hell hired that person? This is like hiring someone to coach your kid in hockey who doesn’t know how to skate.? Just like a non-skating hockey coach is a spectacularly obvious mistake, so is a non-coding software development coach.?

An unfortunate side effect of focusing on fluff over stuff was the large number of “agile teams” that suffered from team cynicism. The focus of the coaching they received was on agile ceremonies because that’s what you get when the coach doesn’t have a background in actual stuff. Then when the coach is gone, agile is abandoned because there wasn’t any real meat to what they learned. And by the way, renaming ceremonies to events doesn’t make them stuff, it’s just more marketing BS.?

UPDATE: I received great feedback about this issue from several people, a common theme was that I should provide an example of "stuff over fluff." So I wrote an article for Architecture & Governance magazine entitled Agile Needs More Architecture "Stuff" to provide such an example.

To summarize, another reason why the agile goldrush ended is that organizations found that their investment in agile training and coaching wasn’t providing their staff with the full range of skills and knowledge required to do their jobs. Employers want you to produce value, and often to do so in a reasonably short period of time. In most cases they simply weren’t getting that from their investment in agile.

??

Too Much Purity, Not Enough Agility

Another challenge within the agile community are agile purists, people who have a defined vision of what they want agile to be and not to be. Very often this purity is driven by “thought leaders” who were protecting their agile certification scheme by having their disciples strictly repeat their blessed doctrine. While their ideas often work quite well in certain contexts, they never work in all contexts nor do they completely address the range of what practitioners actually need to do.?

Here’s just some of the pure nonsense that we’ve been subjected to over the years:

1. There is no up-front planning or modeling in agile. But we do need to write some initial user stories, do some rough sizing of them, and often provide a reasonable estimate of when we’ll start delivering value into production. We do that during “Sprint zero”.
2. Sprint zero isn’t agile. Agilists work iteratively, not in phases!? Sprint zero is heresy! Clearly agile teams form instantly, everyone knows and agrees on what needs to happen, and start coding on day one.? Right.
3. User stories aren’t requirements. User stories are a reminder to have a conversation with our customers. We’re not doing just-in-time (JIT) analysis on requirements, no, not at all!
4. Agile teams must be co-located. Up until March 2020 the agile purists couldn’t shut their yaps about this, even though it was very easy to observe geographically distributed agile teams outside of the pure agile fantasy world. Suddenly, by April 2020, these same people were pitching how they could coach remote agile teams. Their unmitigated hypocrisy was truly offensive.
5. Agile teams don’t write documentation. Just ignore the hundreds of blog postings trying to explain the second value of the manifesto, working software over comprehensive documentation, explaining this fundamental and easily observable concept. And please don’t observe that supporting documentation required to maintain and support your software over time.
6. Agile teams don’t model. But we do write user stories, create design sketches, and sketch on whiteboards a lot. That’s agile modeling folks. Oh, and then there’s the canvases and maps that we often create too, both of which are types of model.
7. Scrum, but. For several years the refrain “Scrum, but” meant you weren’t really doing Scrum, which was evil because you had to follow Scrum to the letter. And this wasn’t just a Scrum thing, the SAFe folks had a “reduce process variation” euphemism that was a fancier way of saying “SAFe, but.” Eventually “Scrum, but” evolved into “Scrum, and” once everyone recognized that Scrum on its own wasn’t sufficient. You still needed to do Scrum to the letter, but it was okay to fill in the gaping holes with other techniques. A shoutout to Craig Larman for being honest and clear enough to simply tell people “That’s not LeSS”.
8. Management is the enemy. Sigh. In many ways the agile movement was a pushback against traditional project management and the management techniques associated with large software development. Unfortunately, the agile community, for the most part, threw out the baby with the bathwater by ignoring the wealth of management ideas. For example, how many agile teams have you seen that could have used some of the discipline of better risk management, or better change management, or even, egads, better governance?
9. The method wars. For some reason purists seem to love arguing about how their framework can beat up your framework. Arguments over Scrum vs. Kanban, SAFe vs. LeSS, and so on filled the discussion forums for years. In practice, you want to apply the right strategy for the context that you face, one framework does not fit all. An interesting point that Mark Lines often makes is that true agile teams often improve away from the overhead ceremonies, oops I mean events, and evolve into a lean/Kanban approach.
10. That’s not agile. Agile purism led to the rejection of older, proven traditional ideas. For example, the Scrum community loved to bash RUP, even though it contained a lot of great techniques. This was a great marketing strategy for Scrum, but led to the agile community doing a lot of work to reinvent or to relearn those techniques. Karma, being the bitch that it is, now sees Scrum on the receiving end of similar bashing. We never learn.

As Mark Lines regularly points out, true agilists strive to be pragmatic, not pure.? Pragmatists apply the best strategy that they know for the situation that they face, regardless of the labels placed on that technique by others. It isn’t about applying “agile” techniques.? It’s about being effective, about learning, and about improving.? That’s actual agility, and it’s never pure.

To summarize, another reason why the agile gold rush ended is that organizations have learned that a hybrid strategy comprised of agile, lean, and traditional strategies applied in context is what they require to be successful. They’re no longer interested in the drivel spewed by agile purists.

?

Too Many Fads, Not Enough Grounding

For the sake of this discussion, ideas became fads within the agile community when they met the following criteria: They were easily described; they sounded cool; they were easy to follow (at least on the surface); and they were shared widely by conference speakers and bloggers. To be clear, many of these fads were great ideas when applied in the right context. When taken too far, which they often were, they proved to be damaging in practice. When taken individually, each fad wasn’t a big deal. But taken as a whole, they added up and they exacerbated some of the other problems discussed early.

Here is just a few of the many agile fads that have come, and in some cases gone, over the years:

1. The Nokia test. The Nokia test was a straightforward assessment that you could do to measure how agile you were in the mid-to-late 00s. Many of you may not remember the Nokia test, or Nokia for that matter, and that’s ok.
2. Spotify names.? The Spotify method became popular in the mid-teens, for two reasons. First, it had cool names for things such as squads, tribes, and guild. Second, it was promoted heavily to decision makers by one of the leading management consulting firms. ?Interestingly enough, what most people consider to be the Spotify method has long been evolved away from by Spotify. But at least the names were cool for awhile.
3. Big A agile versus little a agile. Who gives a flying frack about that sort of thing anyway? Oh yeah, the agile purists.
4. Failing fast. Failing fast is certainly better than failing slowly, but it’s still failing.? And yes, all the platitudes that it’s really about learning are really cute. Failing fast certainly has its place, but there are other, often faster and cheaper, ways to learn. Teams could have reduced their failures through better risk management (evil though it may be) and greater investment in technical skills (stuff rather than fluff). A subtle problem with failing fast was that it provided air cover to “agile coaches” who were short on experience. A more experienced coach can steer you towards strategies that are more likely to work for you.
5. Games. Gamification also has its place, particularly in training settings and user interface (UI) design. In training, games are great ways to help people learn principles, concepts, and soft skills from each other. As I discussed earlier, agile practitioners also need to learn about stuff, and games aren’t as easily applied there. Many times I ran into people who would tell me about this fantastic agile training they had taken, how they played games and learned a bunch of great ideas, only to go back to work and not know how to apply those ideas in practice. Game-based learning is very impactful, but not always sufficient.
6. Chickens and pigs. Luckily this analogy, promoted in the early days of agile by the Scrum community, that has been purged from our lexicon. It was just rude and demeaning from day one. However, I must give a shoutout to Michael Vizdos ’ awesome chicken and pig cartoons that helped people to learn important agile concepts. In many ways Mike paved the road for the Comic Agilé folks who are also doing an incredible job.
7. The wisdom of crowds. This is a business fad that the agile community latched on to for awhile.? The idea is that a group of people will come up with better ideas than a single person, even an expert. In many cases this is true. But when expertise is really required, it certainly isn’t. For example, if you’ve had a headache for several weeks, where would you go to for advice? Your local pub filled with the usual crowd or to a brain specialist?
8. Foosball tables. This is something that the agile community picked up from tech startups.? Back in the day when people were still going into the office you needed a foosball table (or something similar like an arcade machine) in your kitchen area or you simply weren’t cool enough to be agile. Whatever.

To summarize, another reason why the agile gold rush ended is that agile quickly became associated with fads. This was particularly challenging because in the early days agile itself was labelled a passing fad and we had to do a lot of hard work to show otherwise.

?

Agile Isn’t Dead, But the Agile Gold Rush Is

The agile gold rush is over and it isn’t coming back. We, the agile community, shat the bed with too much agile certification; too much framework adoption; too much fluff; too much purity; and too many fads. Executives are clearly frustrated with agile, having seen little return on investment (ROI) after sometimes spending millions on agile training and coaching. Is it any surprise they’re not signing up for more of the same?

Further Reading:

In the second article in this "agile scatological" series, How Agilists Can Move Forward After Shatting the Bed , I share my thoughts about how people can move forward from this mess we've created.? It certainly isn’t more of the same.? For now, I hope that this article engenders an interesting conversation.

In the third article, The Future of Agile Isn't Shit , I work through how I see the agile movement itself evolving. Once again, it certainly isn't more of the same.

Acknowledgement: I would like to thank Mark Lines for his insightful feedback that went into this article.?He'd be a great person to bring into an organization that is hoping to understand what happened and more importantly how to move forward.