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

I agree, but I have seen an implementation of a middle ground (Scaled Agile for Enterprises, SAFE) that combined the worst of both worlds, with quarterly, one-week, all-hands-on-deck mammoth PI (product increment) planning sessions down to the story point (whatever unit that was, apparently it has magical self-calibrating properties) that were thrown out of the window 4 weeks into the PI.

If your high level story is to "implement a button that cancels the order when cliked", for instance, then this can be broken down into several taks, the first of which may be about reasearch and investigation.

Even during the implementation phase you might hit an unexpected issue that will need to be investigated and researched.

If you're trying to fix a bug then investigation and research may be the bulk of your time.

The point is that tasks/tickets/stories and what you're spending your time on don't have to be only about typing code and it's perfectly normal to report as such.

Regarding estimates, the issue in the real world is that estimates on incomplete data very often end up as commitments when told to project management. This is quite orthogonal with Scrum and is part and parcel of working on any project.

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.

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.

Probably because it's almost impossible (and probably co-incidental when it does happen) to align all software engineers on a team to a common outcome at all times. Nor should you.