Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

Imo the fundamental failure of Scrum as a planning methodology stems from the fact that it gives user requirements ('user stories') to developers and expects them to translate them to a technical implementation almost as an afterthought that's barely acknowledged in the framework.

Most of us work on huge codebases with tons of baggage and hundreds or thousands of engineer-years invested into it.

Implementing a feature into such codebase requires a combination of architecting, reading the code and experimenting - making the change is usually easy compared to that.

Scrum has no proper way of handling these activities.

- Figuring out how to do the feature is usually part of the 'planning' and 'grooming' activities which are 'invisible work' with timeboxed team meeting slots allocated to it, even though a well-thought out implementation can save tons of time

- Just plunging in and doing it means that a large uncertainty exists as to how much effort said feature wil take. This can either lead to time overruns or padded estimates (or both)

Scrum just doesnt' offer anything valuable imo. Its just feelgood management consulting ceremonies devs would rather do without. And I haven't even touched on the tyrannical micromanagement dark patterns it enables.

Scrum serves two primary purposes:

1. To force a check in so that everyone keeps the manager up to date. This is annoying for people who already do that as a matter of course, but not everyone is that disciplined.

2. To demonstrate velocity to the higher ups. We can't get away from the fact that upper management needs reassurance that we're not just fucking around. With these bullshit numbers we can make them feel better, and that's just all around a good thing that helps preserve harmony.

The moment you try to explain scrum as an efficiency tool, you're on shaky ground. It's a tool to counterbalance human nature.

> "If failure cannot be attributed to Scrum, then neither can success."

I don't think this is true, given the "Get out of jail" arguments he is attacking. A proper tool used in its intended way for its intended purpose is intrinsically useful. You can say the same about any tool: If you use a hammer to cut a cake, the resulting mess is your fault. A broken hammer is not an error with hammer as a concept. If you successfully hammer in a nail, the hammer played a crucial part in the success. I can't think of an instance where failure would be the hammer's fault.

If you think the hammer is to blame for not being suited to cut cakes, well, that changes things.

Am I missing something?

(I am only talking about the quoted truism. I am not qualified to talk about scrum.)

When I hear and read about Scrum, I'm always reminded about the Simple Sabotage Field Manual by the CIA.

How can we be sure that Scrum isn't yet another tool by a foreign adversary to sabotage Western companies?

If I recall, one of the creators of scrum boiled it down to two elements: a cycle and a reflection on that cycle. All scrum types revolve around that in different ways, and it seems most orgs fail to understand this.

The biggest tool of scrum is having cycles, and then reflecting on the cycle in order to move it in the right direction, but most of the time there are still quarterly planning and bad adherence to the sprint planning (bringing in new work in the middle etc), which defeat the purpose of scrum to begin with. Additionally, scrum should be owned by the contributing team and that almost never happens, as it is controlled top-down by managers and leadership.

I'm surprised no one yet - either in the comments or the article - has talked about the most important and powerful part of Scrum: having a singular sprint goal aligned with a higher level product goal that the entire team is dedicated to.

That it's also the most difficult or commonly ignored part of Scrum might also be relevant.

Scrum is alright but shouldn't be taken to the extreme. We went from Waterfall Model, planning absolutely everything up-front, to the opposite extreme of planning nothing up-front. Somehow people think that's totally normal and still think process is everything.

I've been around the tech industry long enough to see companies dogmatically pursuing certain ideas only to switch to the opposite ideas later... And, at all times, everyone is 100% sure that this way is the only way it should be done. Nobody ever gets any credit for saying "Hang on, maybe we should find a middle ground."

The root problem is that most humans are a mix of crazy and stupid. We go from one crazy extreme to the opposite crazy extreme.

This feels like a rant that does not make any substantive points and ends up looking like an example of what it sets out to criticise.

> Sprints seem to put people on the wrong foot as if we should rush to complete everything in the Sprint...

This is arguing about semantics. If you don't like the term, use another one or explain it better to your team. The important thing is to understand the point, which is to have short development cycles with working software at the end.

In context, the term "sprint" does not refer to any sense of rushing but rather of uninterrupted focus. Of course you plan and reflect before and after, but once you've started you go the distance (which is short!) until the end.

> Lots of talk about how to do better Scrum, while Scrum should be in the background.

That's not inherent to Scrum. On the other hand, continuous improvements have to require an amount of discussion on what works and what doesn't in order to adapt and improve. You need to find the right balance.

> The Sprint Review is mainly misunderstood, as the label is confusingly similar to Sprint Retrospective, and people mistakenly believe it's a Sprint Demo...

This is again arguing semantics and also saying that the team does not understand what they are doing. Hardly a problem that can be attributed to Scrum.

> The Product Owner rarely owns anything and mostly accepts requests from the Product Manager or other stakeholders.

Perhaps the product manager is the right person to fill the role of "Product Owner", then? The role does not have to be a dedicated person...

I don't want to give the impression that Scrum has a "get out of jail free card" here. Most criticisms of Scrum are very superficial and do not actually criticise the essence of Scrum so of course the response is indeed often simply that "you're doing it wrong"...

Scrum is not a panacea, on the other hand one should always try to understand the essence of any framework, the point, instead of being hung up on details and semantics. A good starting point is to read the Agile Manifesto and to think about the point.

"If Scrum doesn't work, it's because you're not doing it right." Seems like a form of https://en.wikipedia.org/wiki/No_true_Scotsman

I thought scrum is a stick management uses to threat the working people with.

I'm sure this happens because my senses haven't been dulled down enough to just shrug and gloss over these, but the AI-generated filler image after the first full paragraph just jars me out of the reading groove and makes me just drop the article. It feels derisive.

How is this better than just grabbing a photo of an actual get out of jail free-card from somewhere?

https://commons.wikimedia.org/wiki/File:Get_Out_of_Jail_Free...

(CC-BY)

I would add to his initial list -

4. You didn’t scrum hard enough!

More meetings! More discussions about god knows what, more retros that achieve nothing. More meta-discussion around process while less work than ever gets done!

At its best, Scrum can be a tool to limit manager micromanagement (only at the level of a whole sprint), while also empowering the team to work the way it considers most effective because everything Scrum suggests as defaults (like what meetings to have and what their goal is) can be changed by the dev team.

In practice management doesn't give a iota about what Scrum says their role is and everything becomes discussions about what Scrum does or doesn't say.

All that said, Scrum also completely ignores design work.

The main reason why scrum is broken is because companies completely fail to adopt the foundation over which is built, that is the Agile manifesto (and they claim to be agile!): https://agilemanifesto.org/

The first line states: Individuals and interactions over processes and tools

But whenever scrum is involved, process is given priority.

Anyway, design your process for your needs.

I had a knee-jerk reaction ready to dismiss this post, but it actually makes a good point and it makes it well.

I view the arguments about dev process to be similar to arguments about parenting. There is some consensus that having some structure is generally better than having none, and the specific merits of different structure and process are subjective.

i.e. Having parents is generally better than having none.

Real scrum has never been tried.

What evidence would it take to conclude Scrum didn't work?

Scrum is a developer empowerment tool that turned into a micromanagememt tool. A stupendous own goal for the software development community.

If someone worked with both Scrum and Kanban, can you tell us which one feels better for a team? I only experienced Scrum.

Writing about Scrum, regardless if it's praise, complaints, references, howtos or just plain descriptions without referencing the agile manifesto is kinda... missing the point? The content of the article is good, but perhaps quoting the founding principles of agile would make it even better? Implementing Scrum (including org-specific adaptations) without understanding the idea behind 'agile' is what a PHB does.

https://agilemanifesto.org/

Yawn. Scrum is a standard that eliminates the need for figuring out and agreeing about a bunch of things. This has great value in the real world. What would the author do instead? Is scrum “perfect”? No. Does it solve all problems? No of course not. But it’s not meant to. It’s an abstraction layer on top of the complex mess that is software development and team coordination. Blaming the abstraction layer when something goes wrong is typically a strawman. Like blaming the REST API when it’s actually the database that’s slow.

There are projects where scrum doesn't make much sense. You wouldn't want to build a house in an agile way. It is also essential to have the customer comnit to the agile way of working. A project with a fixed deadline, fixed scope and fixed budget doesn't become a scrum project just because you introduce sprints, dailies, reviews, scrum masters and product owners. Framing the misuse of a framework as a "get out of jail free card against criticism" misses the point.

It's a planning tool that is useful in situations where people otherwise have a hard time planning things. This is very common in the industry. Software engineers are poor at estimating their work. Managers in turn tend to have a poor grasp of how hard or easy things are. Scrum is a tool you can use to get some sensible decision making in place.

I'm actually not a huge fan of scrum and the mindless activism around it but it's probably not worse than most alternatives. Including the default herd of cats type situation that lots of people seem to default to, which is definitely not great. I default to vaguely Kanban; regardless of the process of others around me. When in a scrum environment, I just just make sure that my TODOs are aligned and prioritized correctly. When not, same.

My main criticism of scrum is that it leads to consensus based decision making where consensus drowns out expertise. If not managed properly, it promotes a culture of mediocrity. You get people in junior management roles (which is what the PO role typically is) overruling experts around them. Easy things become hard, and hard things become impossible. Sometimes you just need to let the experts to do their thing without micromanaging them.

Another problem is that it drives teams to iterate rather slowly (weeks); which creates issues if you want to be more agile and e.g. practice continuous deployment, which I would argue should be the default these days. This is something that can be managed by a good team but it needs active managing. I tend to completely decouple planning from releases. We release regularly and we only release good stuff. Anything not making the cut goes to the next release. This happens regardless of any sprint plannings and what not.

Yet another problem is that doing scrum in large organizations creates all sorts of process bottlenecks. Orchestrating large amounts of teams is a non trivial problem that scrum does not provide solutions for. Naive versions of this (synchronized sprints, scrum of scrums, etc.) naturally lead to waterfall style development cycles where nothing happens quickly anymore. This too can be managed but I've seen a few places where this became a ritualistic mess that involved lots of wasted time, people in pointless roles without having much impact, etc. You get teams working around each other, doing conflicting things, and worse.

I don't think Google, Meta, MS, Apple, or similarly large software development organizations talk a lot about their internal processes. But my impression is that they mostly don't seem to be doing scrum; or at least they don't talk a lot about doing that. Correct me if I'm wrong. The above might be why.

Same logic with communism - all the ones that ended in oppressive dictatorships, mass executions or starvation weren't "real communism" or weren't "implemented right"...

if scrum isn't working, you're clearly not having enough meetings!

Part of the joy of a dysfunctional organization is how that dysfunction shows in how they adopt processes.

If you're an experienced scrum practitioner and you don't have criticisms of scrum, that's unusual enough I find it hard to take you seriously. Like any tool, even if you love the tool, if you don't have any criticism of it, my first instinct is to think you haven't really used it that much.

The source of the "Get Out of Jail Free Card" is that there is no belief in a "one-size fits all" agile methodology. If you don't adapt ("continuously change") Scrum to fit your organization & team, it's very unlikely you'll succeed. Similarly, if you only adopt portions of the methodology without a lot of deliberation (and experimentation), it's very unlikely you'll succeed. Scrum (and one could say the same thing about any methodology) is a very delicate balance of tensions between various trade-offs. Organizational have their own unique tensions, and you have to adjust your methodology's trade-offs to fit your organization to establish that balance. It's even harder than it sounds, because organizations have such massive inertia. Changing organizational behaviours is difficult and slow. My observation has been that when you bring a new methodology (any methodology!) into an organization, you're typically going to find that at least initially, the methodology changes more than the organization. I usually find that for a large enough organization, barring some massive disruption to the organization (like mass layoffs or mass hiring), if they're really committed to making a change, a year into the adoption of a new methodology, more often than not, they're still in a "fake it 'til you make it" stage. People will be using the vocabulary/colloquialisms/etc. of the new methodology, but the actual execution will largely resemble the methodology, such as it was, prior to the introduction of the new one. That's actually what progress looks like! Slowly but surely, behaviours will start to change to more closely match the way people are talking/thinking about the new methodology, but it's going to be brutally slow. There's an old expression in the Scrum world, that if you manage to be successful without making any adaptations to Scrum, you almost certainly were successful before you adopted Scrum, and you would probably have been successful even if you had never adopted Scrum. Not that Scrum can't be helpful, but it's just so unlikely to arrive into your organization already fit for purpose. At that point, empirical analysis of the methodology is more an empirical analysis of the organization and/or the old methodology than the new methodology.

So yeah, when I read someone saying that Scrum has a 'Get Out of Jail Free Card', particularly if that seems based on their anecdotal experiences with it, rather than some kind of broad survey of outcomes, that seems more reflective of their context than of Scrum. My expectation is that their context is shaping how they perceive Scrum, or any new methodology. If "Methodology X" had been adopted instead, it's quite likely there'd have been a similar perception of "Methodology X" if it had been adopted instead.

Now, it's possible to read this and say I'm just reinforcing the article's notion that you can't evaluate methodologies. I'm not saying that. You can evaluate methodologies, but it's hard to construct a meaningful evaluation. You'd either need an insane amount of controls, or you'd need a broad enough sample set that organizational noise balances out enough that you can get a read on the signal. Most of us aren't in a position to do that. Even if we were to do this and we found a signal, there's enough variance from one context to another that any particular organization might observe wildly different outcomes.

tl;dr: While development methodologies can have impact, they are far from the most important driver of outcomes. So yeah, a good or bad outcome is far more likely to be driven by other factors. That you must control for other factors isn't a "get out of jail" free card. It's just scientific reality.