Every time this topic comes up on HN it devolves into "if you think it's bad you are not doing it correctly". Perhaps everyone is indeed doing it wrong, but when 90+% of the intended audience is "doing it wrong" it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
> it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
The system is simple; the implementation is often shallow and ritualistic, imitating the how without understanding the why. But the way that the question was asked leaves a lot of room for interpretation. I think it is important to consider a technique as it was intended vs as it is implemented. It would be the same for TDD, or pair programming, or object-oriented design patterns, and so on.
When implemented properly, scrum is beneficial, because it makes it easier for the information to flow through the team and for the team to adjust to the reality. When implemented poorly, it is a hurdle, because it degenerates into a bunch of pointless rituals.
The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too. What would be really interesting is a scrum variety that is easy for people to follow without losing effectiveness.
> The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too.
Yes, but do people then go around saying "this dieting thing is totally dumb and a complete waste of time", "I just don't get why anyone would go on a diet", etc.? And how do those who have managed to stick to a diet and think they have benefited from it look at such people? Because this is the attitude that I think I am seeing in many comments in this thread.
Scrum is not dieting, it is just a particular diet. Dieting is agile. And it turns out that Scrum, like all faddy diets, only works for a very small percentage of teams, probably due to their particular character.
That character of enjoying being micro-managed as far as I can tell.
> That character of enjoying being micro-managed as far as I can tell.
We still haven't established what is it about scrum that makes you say micromanagement. Do you regard all prescriptive statements as micromanagement? Is a software framework, such as Ruby on Rails, or Laravel, or Django micromanagement? Are code reviews micromanagement? Is version control with git micromanagement?
Which is the point I hoped I had made, In fact when I was young I worked on a project for BS5750 (aka ISO 9000) and the v senior guy at BSI mentioned that very thing to me.
To add onto this: the argument of "you're doing it wrong" would never pass a usability or safety test, but this gets conveniently glossed over whenever the Scrum debate comes. Trying to wave the point away just makes matters worse. If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.
By admitting it is both right and wrong, and it entirely depends on the context and purpose whether one should decide it is "right" or whether it is "wrong".
Kids are using electrical plugs wrong when they stick a pointy object in it. That doesn't mean electrical plugs without child safety close to the ground aren't potential hazards.
Kids damaging their hands doing control-stick spinning minigames using a N64 controller without gloves are "doing it wrong", they could just wear gloves. Still, Nintendo lost that case, and such minigames were deemed problematic.
People browsing a website where the links turn invisible, the mouse doesn't turn into a pointer, the browser doesn't show it is loading and no loading icon is shown, are "doing it wrong" for not just waiting 10 seconds for the page to load. Despite that, UX practices rightly condemn this kind of behavior: at least add an "alive" indicator.
To some degree, you have to make things "stupid proof". That's part of this field. If for some reason, Scrum allows managers more power to micromanage, that's a potential hazard which has to be admitted. That's the problem with the "you're doing it wrong" argument. It doesn't acknowledge potential hazards. Instead, it tries to circumvent that discussion and blindly assumes that developers both can and should "just fix it" when managers are doing it wrong. There's no discussion to be had when everything goes back to "you're using the tool wrong", even if that tool is designed poorly.
What's worse, go and be the guy telling managers that Scrum should be getting them out of a job. The only people I see doing that are the people not dependent on managers, e.g. Uncle Bob and Allen Hobub, and anonymous reactions here. When you're the one who might lose their job making that statement, suddenly, suffering under misimplemented Scrum and whining about it on the internet doesn't seem so weird anymore.
Scrum requires some premises that many businesses have problems adapting to if they've had a micro managed process before.
Scrum is, for better or worse, an all or nothing if it is to reach its full potential. Once you have "real" Scrum, you can start adapting the overall process through retrospective. But if you start your scrum adventure with "Scrum but..." then it's not going to deliver of the promises.
It is not just micromanagement, it is also the rest of the business culture. Ego-less development and placing the team over the individual can great for productivity. These productivity gains accrue to the profit of the wider company and _might_ partially flow back to the team, possibly as a bonus or possibly as promotions. However, effacing yourself for the team is unlikely to result in the kind of visibility needed for career progression and with software salaries being what they are that can mean a difference of hundreds of thousands in income over the years.
In a way, scrum and its team-based mechanics form a kind of prisoners dilemma where the first team member to claim credit will gain much more of the value generated than their peers. These incentives need to be taken into account in any framework based on teams cooperating, because they have the potential to rapidly poison any team where people are jockeying for promotion.
The problem is often not scrum but the organization. Any organization can misuse any framework for micro management. Scrum is only successful when it empowers developers. If scrum doesn't empower you, then do something else or try to figure out what's stopping you from being empowered.
The difference between scrum and agile as I see it is that scrum is proscriptive enough that you can tell it doesn't work.
Agile is vague and handwavey enough that you can never really be sure that you're doing it or not. I think that was by design - a badly written rulebook won't spread as easily as a religion you can project your own hopes and dreams on to.
