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.
>> a well-thought out implementation can save tons of time
I think there is a bias for many developers to feel like they are not doing anything unless their actively producing/editing code.
Once I realized that I could just state in a standup that I was 'investigating' and 'researching' the best approach to XYZ then I felt a lot less resistance to the process.
You can tell that, but if you are 'researching' during the implementation phase, how the hell did you give an estimate on the task? I'm not blaming you, I'm just pointing out Scrum is ridiculous
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.
You could do the reverse, timeboxing it. Goal being to avoid spending excessive time on the task.
Having a well defined amount of time for a research task makes sense, the business decides how much they want to spend.
I'm against estimating every task, but I definitely provide a ballpark idea when a project will be delivered. Keeping a research task in check is important for myself too, otherwise I can go on for weeks.
> Scrum has no proper way of handling these activities.
That's not true.
A high-level user story will indeed require investigation, architecting, perhaps experimentation. So create tasks for each step and add them to the backlog!
The 'planning' part in Scrum is mostly planning the sprint, i.e. what the team is going to work on during the next incremental period based on the tasks in the backlog. This is very different from thinking about how designing a feature, which is an activity that should be treated as a task.
Working in short "sprints" also helps in the investigation and architecting phases, because the format is aimed at forcing small, incremental progress when a potential common pitfall of investigation and architecting is spending a lot of time dreaming up something and writing extensive documentation, which will end up being useless or performing poorly in the real world [1]. But you can use "sprints" along perhaps modeling tools to split this into shorter architecting-experimentation-refining cyles.
Again, the common issue here is the superficial, literal reading of Scrum without thinking of the deeper point, which is what matters.
[1] Remember the Agile Manifesto's point about "working software over comprehensive documentation" because of that.
This is why any feature that is not simple should have a "Feature X Proposal" which is a task that is created in the planning. Development is only done in the subsequent sprints after "Feature X Proposal" has been completed, discussed and reviewed by the team.
I've always wondered that - why the pathological aversion to "solutioning" in Scrum / Agile? Any solution is going to invovle compromise of some sort, it's daft to hand over the "user story" and pretend that it's all going to be ok.
In my experience at $OLDJOB, working under Scrum, there were two types of user stories that came in. The first would be issues from the QA team that absolutely had to be fixed. The other were commands from On High that absolutely had to be implemented.
Not much room for compromise (from the story, at least) in either case.
> 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.
Those time-boxed meetings aren't where you come up with the well-thought out implementation plan. They're where the work is prioritized, the well-thought out implementation plan is communicated with the team, and the work size is estimated.
> 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)
At the start of a project where you're going something different from what you have done before (and with software, if you're not doing something different... why aren't you just using the software you've already written to do the job? ;-), and needs/circumstances change faster than you can complete projects anyway, so unless you can predict those changes (in which case, you have the wrong job ;-), even if the task was without any novelty, there is intrinsically a lot of uncertainty.
Recognizing that the uncertainty is intrinsic, the agile approach to manage it is to break down the work into lots of smaller chunks with well defined checkpoints. This allows for many opportunities for course corrections in response to changing needs/circumstances and/or learnings about the size of the work. It's basically just a standard pid controller dealing with a noisy system.
You're right though: another approach is to spend a great deal more time up front making a detailed estimate of the work... although that doesn't control for uncertainty about changing needs/circumstances, which will often change during the time you make your detailed estimate. ;-) There's also the matter then of estimating how much time it will take to estimate the work... since until that part is complete you would have increasing uncertainty. Now you can estimate how much effort the estimate will take to complete. That's a smaller task that will take less time to complete, so there's less uncertainty about changing needs/circumstances while you're coming up with an estimate of effort for the estimate. Also, if you estimate how much effort it will take for you to estimate the effort to make the estimate. Once you observe how far off the mark you are estimating how much effort it will take for you to estimate the effort to make the estimate, you'll have more information to calibrate your estimates with, so you can use that to have a more accurate estimate of the effort to make the estimate...
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.
(I promise I know the below is an idealist stance)
I disagree; there's nothing saying the manager has to be there. In a properly run team/project with good ticket discipline, managers should get their status updates from the ticketing system.
Standups, applied properly, are an infra-team communication tool. They're a formal structure to encourage communications, and raise issues early. They're not a replacement for the informal comms that all good teams do, just a check.
Similarly, velocity should only be used by the team - your sprint commit is the output, and the expectation you set for outside stakeholders, and velocity is a tool to help you get better at that expectation setting.
Yep, I'm aware of how it "should" be. And for smaller companies it's absolutely feasible. But the larger you get, the more layers between people, the less personal connection there is, and so you need formal practices like this to act as grease (and OMG the stuff we have now is SOOOOO much better than the crap of the 90s, even if imperfect).
At the end of the day, you take some kind of procedure, modify it to your company's culture, and try to make it work. There's no silver bullet, or even a bronze bullet.
My firm introduced Scrum in 2023 and it's so clearly about #2.
* The sector of the business I'm in is 90% about integration with third-party services. How many sprints does it take to walk through their certification process? Depends how many cycles the third-party wants, how fast they respond, etc. So we end up checking in tasks representing "2 weeks of work" that really mean nothing so the points can be made up.
* The long-established policy (pre-scrum) involves several phases (development, another developer reviews, QA, final review by project manager). Any one can be a bottleneck. So if Frank in QA has enough points for his sprint, Dev Steve probably can't take on any more tasks even if he has capacity.
* This also works on a time scale; you're often going to end up with "last Thursday of the sprint, there's nothing left in the queue, and we have to twiddle our thumbs or possibly start some experimenting on next sprint's work" -- it's hardly a smooth process of "just keep pulling tasks".
* The primary outcome of all the meetings is that they complain "we're delivering 80% of our estimate one sprint, and 115% the next sprint, how can we be more predictable?"
Bearing in mind the number of points have nothing to do with actual achievements and business value; a huge spec uplift on the #1 partner can end up as fewer points than just endless weeks of dragon-chasing for a partner that will never deliver a dime of revenue.
> "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.)
Scrum isn’t so much a tool but an ill defined framework. The Get out of Jail Free Card the author refers to is abusing this lack of definition to brush off any failed attempts at applying the framework. The author continues to imply if there’s so many failures to apply the framework, that’s probably a failure inherent to the framework itself, at least as it is deployed today.
The assumption is that Scrum is suited for exactly zero things, so if you apply it to anything and fail, it's your fault: you should not be applying it to anything! Even though we the Scrum Masters tell you that you should... excuse us for a second while we're retreating to the motte to continue the argument.
the same way we can be, reasonable, sure that other tools, like knifes and saws, when used for their intended tasks and in the intended way, are just tools.
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.
My understanding is that it was always about creating a kind of protocol for engineers to collaborate better. and scrum just packaged those concepts so they could be implemented by anybody. The bureaucracy happens because it's usually not owned by the contributing team and instead orgs like to synchronize all their teams into one unified process, so it inevitably becomes "corporatized".
That's the theory. In practice it became a way to cargo cult those things with bureaucratic rituals.
This was completely the fault of scrum for being highly proscriptive about the process. It's like teaching somebody to program with rote learning or something. It just fundamentally doesn't work because the core of the process requires human ingenuity, creativity and freedom to work and by having a rote process those things are inhibited.
In my experience, the reflection at the end of each cycle is a useful way to make the team feel empowered and in control of their destiny, while all that happens in reality is that they complain to each other once a sprint and the damage is safely contained without bothering management.
Also, what is so bad about quarterly planning? Not everything ships immediately - this shows a very strong web app bias.
Yeah that happens but that same meeting can be used to address that and get the team back on productive conversations. The team needs to align with the goals though and often this is not properly communicated and everyone is pulling in their own direction.
Quarterly planning sets quarter level expectations but each cycle is meant to set bi-monthly expectations for the purpose of changing directions if needed. They are at odds with each other, if you do sprints properly, quarterly planning will almost always change, and if you try to adhere to the quarter estimates then sprints are not needed other than to micromanage that quarterly commitment.
If doing scrum, you don't do the long term estimating. You have goals but they're not slotted into a timeline, instead they are iterated on sprint by sprint until it's done. You can do projections but even those have to be taken lightly because the point of sprints is to change direction if needed.
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.
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.
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.
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.
Combining the worst of both worlds is definitely a nutty thing to do! You need to use critical thinking and analysis when coming up with new processes. It's definitely possible to make use of the best of both worlds. Though you still need to synthesize and re-evaluate the whole.
Though two wrongs don't make a right, two rights can sometimes make a wrong when combined.
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.
I agree. And it's worth remembering that Scrum is a starting point. The entire point is to adapt the process such that it fits the team/product/organisation, through retrospectives.
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?
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.
In my experience Scrum is the worst enabler for micromanagers
- PO suddenly wants to do something yesterday - they just give their task top priority so you're forced to do it
- PO want the button to have that exact shade of teal - they won't accept the story until it looks exactly like what they wanted
- You want to clean up the messy code you're touching - just make a story for it and watch the PO rank it to the bottom (essentially meaning it'll never get fixed) - since it has no 'business value'
This leads to demoralized devs working on crap codebases they're not allowed to fix.
> - PO suddenly wants to do something yesterday - they just give their task top priority so you're forced to do it
That's fine. It's their role to prioritise features. BUT within the framework this should apply to the planning for the next sprint as the point is not to interrupt the current sprint unless there is an overwhelming reason.
> PO want the button to have that exact shade of teal - they won't accept the story until it looks exactly like what they wanted
Nothing wrong with that. It comes down to explicit and clear feature specification.
> You want to clean up the messy code you're touching - just make a story for it and watch the PO rank it to the bottom (essentially meaning it'll never get fixed) - since it has no 'business value'
This situation applies whatever the framework you're using. You need to sell what you want to do by explaining the value, or you do it step by step under the radar. There should also be someone with clear authority over the codebase who can make these decisions and sell them/negotiate with project management. Again this is not Scrum, but software development in general...
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.
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.
Scrum works in some way. Its rituals take some time, even if you consider all of them pointless, there is some time left to deliver value. Crappy car also works if you can use it and drive to designated place.
The question should be "Is there, for every situation, something clearly better than Scrum?".
The same that it takes to prove that TDD doesn't produce more value than other development techniques. Both have moving bars whete proponents just claim "you are not doing it right" in the face of any criticism.
"You're not doing it right" can be its own criticism though. If you're not doing X right then maybe that means it's too hard to use X in a way that adds value.
X can be useful for one person in one situation and not useful in another, neither of which shows that it's intrinsically useful or intrinsically flawed. It just depends. Our holy wars to prove the might of our favorite tools and techniques are never going to give any universal truths.
Worked at a web property that took scrum, used it and found it lacking in certain cases for development. They Extend it And called the new creation beyond scrum, abbreviated as BS snickers.
Unrelated to the shortcomings
we found that Scrumm with the timeboxing concept did not work for infrastructure teams.
You cannot just time box most Infrastructure task and just ship whatever you have when you exceeded your initially planned timeframe.
We came up with Kanban as a way to document progress. The swimming lanes together with a limit on things that can be simultaneously in flight served to mirror reality as an operational team much better than pure Scrum.
Different paths for different styles of work. In my experience you have teams who can have a pulse with the incoming work, more often development, so being able to limit the disruption makes scrum easier to work with.
On the other hand, if you have a team who is going to be working on more "at the time" needs, Kanban lets the disruption get absorbed in real time while the team gets to focus on the WIP pipe. I've seen it used most successfully in teams that have smaller, more isolated tasks to deliver that are able to be isolated to the scope of the team. Intra-team coordination with Kanban is more difficult than scrum (but doable) as long as the working model is understood on all sides.
My preference is to operate more in a Kanban model but when working with other groups who operate with scrum you need to tweak things to integrate.
It also isn't a system that, once picked, you're stuck with. I had a team who did scrum for a few weeks, twice a year during organizational planning so we are kept in rhythm with the rest of the company. Once we had a good enough idea in how we were going to move forward, we switched to kanban to manage our work until the next Co. planning cycle.
There's no true Scotsman when it comes to planning and agile and you'll never find a definitive correct answer that can be broadly adopted. Being open to change to make it work with your org and the people you work with is going to get you closer than blindly following any strict dogma.
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.
This. Scrum is just a way of operationalizing the basic principles behind the Agile Manifesto while putting them in a way that can be communicated and understood outside of dev/product organizations. No Scrum Master/Agile Coach/Product Owner, etc. worth his/her salt will tell you to slavishly stick to every piece of Scrum as long as you get the basics (see the manifesto) right.
It is, however, a somewhat useful tool for helping you get this running in the first place (especially in organizations where there is a lot of chaos to begin with, i.e., upper management regularly changing the product scope and release timeline based on the color of their coffees, etc.).
> Scrum is just a way of operationalizing the basic principles behind the Agile Manifesto while putting them in a way that can be communicated and understood outside of dev/product organizations.
Scrum in practice is processes and tools over individuals and interactions.
> No Scrum Master/Agile Coach/Product Owner, etc. worth his/her salt will tell you to slavishly stick to every piece of Scrum as long as you get the basics (see the manifesto) right.
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"...
Politics is just deciding what to do with shared resources, an ideology informs people’s choices about what to do with shared resources, managing people doesn’t really have anything to do with scum or politics, I think you’re missing the mark.
More to the point, you’re picking something more divisive than scrum and adding your thoughts about the divisive topic to add to a discussion about scrum, it doesn’t add to the conversation it just ratchets up the conflict. Take it to Facebook.
People aren’t a resource, they are the ones sharing the resources. You’re conflating a capitalist business structure with politics, they aren’t related.
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.
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.