Btw, that book is a good book on the idea of what scrum could be . See below for my actual experiences with it
bad management can defeat the best system, no question
If you read below, I believe this has happened repeatedly and more often than not.
Pros: Avoids the pretend estimation that scrum does. Avoids the random deadlines causing overwork (and decreased productivity)
Cons: Still obsesses about velocity and metrics…which is often more about how big a component is rather than true performance of the team
Rant about my experiences (aka, Scrum’s Cons):
I’m not arguing with the contention management can ruin anything. I’m saying it happens a lot with scrum in particular. It’s arcane and ritualistic in ways that don’t necessarily yield useful results, and not due to bad heart’s on anyone’s behalf
Scrum in theory gives a lot more authority to team members. In practice, it’s commonly used to squeeze things into many short deadlines which are surprisingly short for the things that are happening, often causing a lot of long hours and hero crap that shoots project quality to hell. It’s a hot mess of jocular culture, bad statistics, management getting frustrated, and long nights for programmers. This isn’t because management is a dick. This is because management is told to do a lot of weird mode switching that is hard for them to do reliably
SCRUM intentionally has a lot of very sports culture metaphors and short term deadlines that are artificial (the use of “commitments” in particular implies a lot of certainty and personal failing around something that’s just work being done with sometimes complications), and has a lot of “GOTTA MAKE IT FOR THE TEAM BRO”. Timeboxing is used to make urgency. Urgency is used to try to constantly stress the team into sacrificing for the team. This is a sure way to burn people out.
The “bargain” of the team will meet what it says it will for that 2 week period is constantly pushed by management at many organizations, and is often violated by adding elaborated requirements on top of the known requirements at the beginning of a sprint. That said, even the KNOWN requirements are estimated in a boneheaded manner using points from planning poker or point estimate numbers of hours, rather than ranges like we’ve known are needed for good estimation for decades (and with the uncertainty we have in most software projects, the ranges upper end exceeds a single sprint duration). Management takes the scrum “commitments” and turns them into certainties they often plan on definitely having around. This makes failing it worse than it’s “supposed to be” in scrum…
Note, in a normal healthy systems, people EXPECT requirements to crystalize and elaborate as people gain more time with the product. But not in scrum. We only update stuff and the time requirements between the sprints, cause we made commitments. Oh, but we could fail those commitments…but doesn’t that just sound horrible to do? Yeah, it does. So we work longer hours…or get called out as “not a team player” for you know, having families and stuff.
The product owner role in particular is often abused. It’s a non-engineer managing engineers, and as always happens at that interface, they end up disempowering engineering leaders who say ‘No, we have to do X and Y and Z in that order due to how the way this technical stuff works’. So you end up with a lot of overly simplistic under designed systems designed to tick off the ticket super quickly so often, and you have only a guy who literally can go “I didn’t know better” to “make accountable”
Product Owners almost certainly ends up drifting over to a low guy at the management spectrum, rather than top guy in the engineering system. They’re not blamed for longterm engineering failures…cause they’re not an engineer, who end up getting blamed…even though they often repeatedly said X will happen if we don’t Y. POs have little power in the way of stability requirements, it’s all about new feature delivery.
I’ve seen 2 SCRUM teams work, I’ve seen 4 that were dysfunctional. All but one of them had someone who went to ‘actual scrum training’. The 2 that worked were for short projects as well.
I don’t even want to talk about Veolcity, which is one of the most boneheaded metrics ever and is trivially game able anyone who wants to LARP Office Space instead of get work done.
Velocity fails the “Surely we can manage with less people” test: It’s putting a big number up on a wall instead and burning everything at that altar
Bad systems are bad systems. I’m going to call it: SCRUM is bad, people dislike SCRUM for good reasons, many people who like SCRUM like it because they were doign something even worse before, not because it’s good. The scrum book isn’t a bad read, but the system in practice is not great usually.
SCRUM not a stable system, it’s easy to screw up, it’s got a ton of terminology that makes it more likely to be cargo culted than really implemented as desired, and I’m not sure the ‘golden plan’ put forth in the books really even works super well, as normal humans suck at doing it (and the point estimates really makes me thing it’s rotten at the core).
It constantly locks time, turns estimation into fortune telling, and therefore sacrifices everything else, including employee health and wellness, to get its goals…which it doesn’t even deliver very well for that long…