After a bit of experience with scrum, one of the things I"ve come to appreciate is that it's not a one-size-fits-all methodology. I think the spirit of scrum (break work into chunks, have working code at each stake in the ground, define a project in terms of user stories, etc) is more important than the letter of the law, and being able to tailor the process to your current reality is more valuable than dogmatic adherence to some prescription.

Excellent point!

Scrum is by and for management, not developers. Want your devs in at 9am? No problem, hold the standup then. Want to easily replace your dev team with an outsourced one? No problem, a Scrum team is a black box as far as the rest of the organization is concerned, one with a well-documented interface. Etc, etc.

Ir's insidious because it tricks devs into thinking it's for them.

What does management want anyway? Do they want a black box with a well defined interface? What other options do they get?

It seems to me that this question depends very much on the kinds of commitments management is making. Which in turn depends on whom they are making them to. If it's to a customer that has some hard requirements, enumerated in a contract, and providing those is the source of money, then management's focus is (and should be) executing those requirements. Which would seem to imply that a black box is just fine.

The problem is not the desire for a black box approach, but that boxes fail. Management is risk averse (and their risk aversion is what keeps your paycheck coming, in theory).

(Actually, black boxes are creeping into software development all of the time. For example, there's no reason to not have fast PSD-to-HTML turn-around anymore. That process has been black-boxed. Not shrink-wrapped, but black-boxed. Yes, there are still quality variations, questionable use of excessive markup, etc, but its not bad.)

Anyway, I just question your tacit assumption that management wanting a black box with a well defined interface is a bad thing. It seems like a reasonable goal.

It's not healthy for the organization as a whole if the only point of contact between "the business" and the developers is enshrined in the Product Owner. It is however very amenable to empire building and short-term cost savings, both of which are examples of a manager favouring their own interests over that of the organization. In short, Scrum is most useful for those for whom a dysfunctional organization is their goal. That the turkeys (devs) are voting for Christmas themselves is the icing on the cake.

It is a compromise. Like any long-term compromise, it is gradually bent into a shape mostly determined by whoever has the better bargaining position.

Um, one of the first rules of scrum is that management is not invited to the Standup. Scrum is a process for a team to communicate effectively with each other and their customers.

I think you're being a bit generous. The consultants who sell "Agile" to dysfunctional organizations are the same ones who sold every fad methodology that preceded it to those same dysfunctional organizations.

This is a really interesting insight. I have seen so many instances of prescriptive Scrum with no explanation as to why that it's appropriate, i.e. Cargo Culting.

Most of the software industry is built on cargo cult.

    I've done a bunch of reading about Scrum

Without trying to be inflammatory, this is no way qualifies you to speak with any authority on Scrum, or indeed any topic where your experience amounts to nothing more than a bunch of reading.

That is not to say that you don't make any valid points. I think the fundamental tenets could be relaxed over time, but I guess with some organisations when you start removing some of the restrictions you'll eventually remove more and more until you're back where you started.