A friend of mine asked me recently whether she should get a Scrum certification. And I had to think about it for a second — because I realized that in a lot of companies, the word "Scrum" has become basically toxic. "Agile" too. She then asked me a bunch of follow-up questions about why and I realized that the story of what happened and what came next is surprisingly complicated.

So here it is.

Watch this video on YouTube (opens in a new tab)

How Did Scrum Become a Dirty Word?

Part of it is on people like me.

I spent years — a lot of years — teaching Scrum, facilitating agile transformations, helping organizations to fix their delivery problems under the banner of Scrum. And in some cases helped. But in a whole lot of other cases, it just totally whiffed. The transformation didn't stick. The improvements didn't materialize. People got disillusioned. (BTW, I still help companies to fix their delivery problems...I just try not to say the word "Scrum" or "Agile". It's easier that way.)

Part of the problem was how people were taught Scrum and how they talked about it. They focused on the ceremonies — the daily standup, the sprint planning, the retrospective, etc. — rather than focusing on delivery. So Scrum got famous for a whole bunch of meetings that didn't add much in the way of value. Getting good at doing the dance steps of Scrum won't help and didn't help anyone to get better at anything.

And while everyone was getting excellent at having meetings and doing the dance steps, they somehow just plain didn't notice that software delivery is ultimately about people. Getting people to change is hard. Getting corporate cultures to change is even harder. You can teach people new meetings, but you can't just flip a switch and make an organization think differently about how work gets done. You also can't just flip a switch and get people to play nice and communicate really well. That stuff takes years, and most transformations didn't have that kind of patience.

Plus, throughout all of this — it's worth remembering that software development and software delivery is hard. Scrum and Agile became toxic through broken promises and disillusionment.

Inspect Without the Ability to Adapt

But here's the part that I think did the most damage.

In a lot of organizations, Scrum introduced the "inspect" part without the ability to "adapt." So basically what teams got was a big ol' mirror that said you suck, every two weeks, without the organizational support or the authority to actually do anything about it.

That's demoralizing.

And after enough sprints of being told things aren't working and not being able to fix them, people stopped wanting to look in the mirror. (Can you blame them?)

The retrospective is supposed to be the place where you identify what's not working and make changes. But "make changes" requires authority. It requires organizational support. It requires a management chain that's willing to hear uncomfortable things and act on them. Most teams didn't have that. They had the mirror. But they didn't have the tools. (Bonus 'disillusionment points' if the retrospectives showed teams that it was their bosses who were getting in their own way.)

Scrum Isn't Evil. It's Just a Little Mismatched.

Now look — I don't think any of that was really Scrum's fault. Scrum and Agile literally changed the world of software development. There is so much wisdom tucked away in the Scrum Framework.

But let's face it: Scrum has gotten a little — okay, a lot — long in the tooth. After twenty-plus years, it doesn't totally match the way we work anymore.

The stuff that Scrum was trying to address — "waterfall," delusional project plans, giant bricks of requirements documents that no one ever actually looked at, Rational Rose — those have largely been defeated. And now the things that Scrum traditionally railed against and talked about just don't seem all that relevant anymore. The boogeyman isn't there being evil anymore. For the most part, we're not trying to write giant bricks of requirements documents and we're not trying to put project plans into contracts.

So what happened next?

Nothing in Particular

A bunch of organizations looked at Scrum, said nope, and pivoted to what I call "nothing in particular."

I've started calling this vibe-process, because that's basically what it is. No structure, no practices, no feedback loops. Just vibes. "We do what works for us." Sounds great, right? Until you ask a follow-up question like what does that actually mean? — and you get a shrug.

You hear things like "well, we're agile-ish" or "we do a modified version of Scrum" or "we take the best parts of different frameworks." And what that usually means is they don't follow any particular process at all.

I actually wrote about this ten years ago. In 2016, the biggest enemy of Scrum wasn't Waterfall — it was "nothing in particular." And now, a decade later, the exact same villain won again. Same opponent, different era.

The Thing Everyone Missed: Focus on "Done"

The gigantic thing that seems to be basically hiding in plain sight is our real, underlying goal: deliver done software. That's it. Everyone misses it. We're not here for Scrum. We're being paid to deliver stuff.

Not started software. Not almost-done software. Not it-works-on-my-machine software. Done. Working. Shippable.

And most teams never really got that right, even when they were doing Scrum. The organizations who missed this "done" thing with Scrum are almost certainly still missing this crucial detail. They just stopped having the meetings that reminded them they weren't getting it right.

If your team can't tell you what "done" means for a piece of work — like, actually articulate it — that's your first problem to solve. And if it's not done? It's inventory, not progress. It's sitting on a shelf somewhere taking up space and attention and creating the illusion of productivity without actually delivering value to anyone.

(This connects directly to the multitasking problem I wrote about in The Priority Doom Loop. When teams are juggling too many things at once, nothing finishes. Everything is "in progress." Activity is not completion.)

Bad Signal Turned Into No Signal

In the land of "nothing in particular," the big thing that changed from Scrum to "not Scrum" was the inspect and adapt cycle.

Those Scrum ceremonies — the retrospectives, the sprint reviews, the daily scrum meeting — they were supposed to be showing you things. Uncomfortable things. People were stuck. Nothing was finishing. The work you thought was done wasn't done. And yeah, the signal was noisy, and it was often bad. But it was signal.

And now a lot of teams have quietly dropped the inspect and adapt ceremonies too — not just the sprints but the retros, the reviews, the stop-and-look-around moments. So bad signal turned into no signal. And that's not "post-Scrum." That's just flying blind.

The signal might have made you feel bad — especially if you didn't have the organizational ability to fix it. Whatever the reason, you went from having "some signal" to having "no signal." Teams just simply stopped looking, stopped listening, and hoped for the best.

So What Actually Stays?

OK, so if Scrum is toxic and vibe-process isn't working, what do you actually need?

I think it comes down to being able to answer five questions and getting serious about two disciplines. It's surprisingly simple.

Five Questions That Actually Matter

Even if you're doing the "nothing in particular" style of project management, here's how you can still be successful. Put another way — here are the five questions you need to be able to answer:

1. What are we going to work on? Is there a prioritized list somewhere, or is it just whoever yells loudest gets their thing built next?

2. Are we working on the right things? This is different from question one. Question one is about the list. Question two is about whether the stuff on that list actually matters — or whether you're building features nobody asked for.

3. What are we working on right now? Can you see what's in flight, how much is in progress, and whether anyone's stuck? If you can't see it, you can't manage it.

4. Are we getting anything done? Not are people busy — are things finishing? Because there's a massive difference between activity and completion. And honestly, most teams can't answer this question with data.

5. Are we on track? / When will it be done? Can you forecast when things will actually be done using real data, or are you just guessing and hoping for the best?

If you can answer those five questions, congratulations — you've got a process. Call it whatever you want. Call it "pumpkin spice latte." It doesn't matter. You've got the core of a project management process.

Get Serious About "Done"

Done means done, working, and shippable. Not almost done. Not "it's in QA." Not "it works on my machine." Actually done.

This was the most important idea in Scrum, and it's the one most teams never actually internalized. And here's the thing that makes it matter so much: if it's not done, it's inventory, not progress. It's sitting on a shelf somewhere taking up space and attention and creating the illusion of productivity without actually delivering value to anyone.

Stop Starting, Start Finishing

Multitasking is the enemy of getting things done. Every time you add another thing in progress, everything in progress takes longer. This isn't opinion — it's math. (I walk through the Weinberg numbers and the kanban board math in the Priority Doom Loop post.)

Limit your work in progress. Put a cap on how many things can be in flight at the same time. And I know that sounds simple — and it is simple — but it's also the single most effective thing you can do to improve your delivery speed without changing anything else.

Or put another way: the fastest way to go faster is to do fewer things at once. Not work harder. Not work longer. Just do fewer things at the same time and finish them.

The Quick Test

Here's the quick test. Can you tell me right now how long your average work item takes from start to finish?

If you can't answer that, you might be doing vibe-process.

And that's the difference between "post-Scrum" and "no-process." Post-Scrum teams kept the signal and dropped the ceremony. Vibe-process teams dropped everything.

The good news? The fix is surprisingly simple. Answer the five questions. Get serious about done. Stop multitasking. You don't need Scrum. You don't need a certification. You just need to pay attention.

-Ben

If your organization is stuck in vibe-process — no signal, no priorities, nothing finishing — that's the kind of problem I help teams diagnose and fix. Let's talk.