Thanks for your comment, Cliff! You’re certainly right in that Scrum will not fit every situation — we mustn’t fall into the golden hammer anti-pattern. It seems you have had especially bad experiences with Scrum and I don’t blame you. Sadly, bad Scrum implementations (and for that matter: totally misconstrued understandings of agility) seem to be the norm today :(. This is exactly why we need to teach people, why things like Scrum or other frameworks and methods emerged and where they came from.
I think the founders of Scrum never anticipated that their idea would once be used (or rather abused) in the majority of big corporations today. And there first shot at describing a framework to guide people, though already very good, was not perfect. Luckily the updated the framewok, their analogies to explain it and their tips on where to use it over the years. I have also grown pretty unsatisfied with some of the terms (like “Sprint” or “Scrum Master”). But who could blame these guys not having seen all these possible misinterpretations coming twenty years ago?
You describe the Daily Scrum as interrupting and not very valuable to your work. I have heard this many times over the years in companies of all sizes and industries! The root cause was seldomly a bad fit of Scrum to the domain or team, but almost always a lacking understanding of agility and of Scrum.
Yes, team members might not be interested what everyone else is working on. The question is: should they? If you only look at their work packages, they might not need to know; but Scrum is about the value produced, not the work packages finished. An understanding of what the team (and ultimately the company) as a whole is trying to achieve is important for an agile developer to adjust their approach at implementing a solution. Furthermore, in most situations today we aim to increase flexibility and resilience (“agility”) in the face of a VUCA environment; collaborating as a team increases this agility. Yes, this increase in business agility costs some efficiency (both on the individual developer’s level as well as on team and company levels), but in many industries today, we value agility more than efficiency.
A common misconception of the Daily Scrum is that you should report to the team what you did yesterday. This is wrong and inefficient (without increasing agility ;)). The goal of the Daily Scrum is an “inspect & adapt” on an operational level in order to be able to adjust your sprint plan at the earliest possible moment. If teams let the opportunity to check the validity of their planning and adjust accordingly pass during Daily Scrum, then I hear your pain in that it doesn’t make any sense.
You’re also right in that an agile team can (and will) define it’s own process. Experienced teams will have no problem designing their own agile processes and frameworks — though quite a number of experienced agile teams stick with the Scrum framework. But Scrum really shines with people getting started with the concept of “agility” (be it managers or developers) — it gives them some guide rails to focus on their work and understanding how the ideas of an agile mindset can materialize in day-to-day work. Any team demonstrating agile thinking is free (and in fact will never be held back) from altering their framework. However, most teams try to break the rules before they even understand agility — that we must always be aware of!
Fascinating about Scrum is also how little it tells developers how to do their work. Scrum is a “framework” in the best sense: it doesn’t prescribe any processes or tools. Scrum merely provides a team with a bunch of checkpoints to measure important data and a time-slot to do something with these observations. Everything else is left to the team. Of course you can remove these checkpoints and live happily for a while, but if you don’t measure these data points and act accordingly otherwise, you will find yourself in less than desirable situations. Nobody would rip their speedometer out of a car just to not be nagged about speeding anymore — it certainly wouldn’t stop the cops from pulling you over ;).
In summary I see part of your point. Scrum is implemented badly in many corporations today. Experienced agile teams can find other ways to ensure business value focus and agility. Let’s fight this wrong understanding (and sometimes outright abuse) of agility together!