Scrum isn’t agility. It’s bureaucracy dressed in a hoodie. It’s easy to dunk on Scrum. I’ve done it plenty. But saying “this sucks” is cheap. Offering alternatives is the hard part. Here’s what I’ve learned after years of living inside engineering processes that worked—and a lot that didn’t: 🔄 Principles over process The best teams align on goals, keep updates short, and spend time together solving problems—not reciting status. 🧩 Flow > sprints Sprints create artificial deadlines and fake velocity. Continuous flow, clear visibility of work, and limiting WIP beats the burndown chart every time. 🎯 Outcomes > points Story points don’t matter. Customer adoption, uptime, and cycle time do. Impact beats points every time. 🛠 Habits, not rituals Shipping is a habit. Reflection is a habit. The power comes from consistency and intention—not from a calendar invite. Scrum makes people feel safe because it’s a box to check. But process is a comfort blanket, not a cure. If your team can’t function without heavy rituals, you don’t need more Scrum—you need more trust. #EngineeringLeadership #Agile #ProductDevelopment #TeamCulture #Leadership
A team that doesn't trust each other will hide behind process and rigid rituals. It's the difference between *doing* and *being* agile.
Well said. All the agile frameworks, mindsets, processes, systems, and rituals are fundamentally based on trust. No mater what rulebook a team or program or org follows, without trust they will eventually corrode like iron. Implementing a framework won't necessarily make a team faster, but definitely shouldn't make them slower. You have very aptly said that it has to be a habit, not only for the devs, but also for the stakeholders.
The artificial deadlines of sprints were what always turned me off. There are always real deadlines in projects (or should be), and I'd rather be looking at those than trying to cram something in during a two-week window.
I see Agile and Scrum as "a" path towards what you envision. Every team will need their own path and hopefully they can find it sooner than later. As always, experience helps!
Scrum is about all the bullets on your list. Still many teams end up doing the less preferred. Scrum is heavily goal/outcome focused. Yet most "scrum teams" do not set a goal. And if they do it is to resolve these tickets. And all the problems you bring up comes from that initial mistake. If you are not intending to be innovative, collaborative as a team then scrum is not the right tool.
As someone who's seen Scrum done well and (often) done poorly, I can say this with absolute confidence: if Scrum is about the process, you're doing it poorly. The main point of Scrum is the bias for continual improvement, and that means improving how each team does Scrum too. For some teams, two week sprints with daily stand-ups are great. For most teams, they're not. Some teams touch base twice a week and the sprints last a month. Every team is different, so Scrum should look different for every team too. One thing that's absolutely essential is regular retrospectives, assessments and correction. This is true if you're using Scrum or not! If you're not regularly evaluating what's going right, what's not and if the team isn't a part of that process then you're letting inefficiency creep into the team's work flow. The biggest reason I've seen Scrum done badly is that retrospectives are either done away with entirely or they're only the domain of the team leadership, except sort of "suggestion box" to delude the leadership into thinking they're getting real input from the team. Hint: suggestion boxes don't work. Anonymous surveys (or something equivalent) where your team is expected to give you input gets far better results.
The Flow vs sprint thing is nonsense.
I'm not sure what alternative you're offering since those are pretty much the bullet list that a Deloitte would tell you when trying to sell you their Scrum consulting. I think, like a lot of devs, there's a huge push to "back off and let me do my job", but not all devs have the habits, the ability to produce outcomes and the discipline to get things done without some level of pressure. On the flip side, a lot of managers have anxiety that they will not produce results and will literally look over devs shoulders to make sure they do the work. Scrum is one tradeoff to deal with this difficulty. What devs complain about is often a managerial perversion, like: Standups are not meant to be status meetings, but, managers want status and looking at tickets moving in Jira doesn't seem to be enough. Pointing is supposed to allow longer-term planning/status without impacting the team delivery, but because it's a metric, it gets treated like all available "productivity" datapoints. If you have a process that deals with managerial anxiety ("Trust me, I'm an engineer" doesn't work) I'm sure you could make $$$ in consulting!
I think Scrum is great when done well but it's easy not to do it well.
I agree 100% with everything you said. Understanding bottlenecks with in the SDLC, using stand ups to discuss blockers and not updates, leaving engineers to develop and build rather than be in meetings that are redundant. As a scrum master I use my technical understandings and to build AGILITY within the team. Understanding lead time and solving for bottlenecks with limited engagement with the engineers has allowed my teams to deliver consistently with limited to no roll backs.