The flawed rhetoric about “Scrum” and “Organizational Dysfunction”

One of the most bizarre, yet highly touted, “features” of Scrum is that it “exposes Organizational Dysfunction”.

Not mere team based, project based, or even departmental dysfunction, but Organizational Dysfunction … enterprise wide.

Now this is crazy on so many levels that I thought I would blog about it.

1) While solving dysfunction, on whatever level (personal / team / project / department / organization) may be a good idea, it should be something that is undertaken independently of whatever methodology. Certainly this process should begin at least some time *before* switching to a new methodology/management style.

2) Scrum makes their methodology DEPENDENT on solving this dysfunction; if you don’t solve it, Scrum won’t work.

Well, that’s just great. Maybe that explains the 75% failure rate of scrum. And how long does it take to solve this dysfunction? 2 Years is often quoted.

So Scrum is going to help you get your product out quickly, just as soon as you spend 2 years and countless dollars eradicating dysfunction.

Moreover Scrum views this as a feature; since it doesn’t work until you fix everything… it forces you to fix it. That’s fine if they want to sell it as a slow moving, self help process that will cost a large corporation untold millions in direct costs and lost productivity while making this huge transition. But they don’t seem to talk about that aspect too much, at least not concretely.

3) People want to use a methodology to get their product done in the most practical way; the methodology needs to work in whatever environment is there, not simply require an “ideal” environment first be created.

Even if Scrum was the self help program they claim it is, and even if the corporations were willing to go along with that aspect, Scrum should STILL be able to work around the dysfunction (however high it is) during this construction period. But even this bit of common sense seems to be lacking in the official Scrum playbook.

4) People want to use Scrum/etc to help their product execution issues; saying that they have to “solve all their organizational problems” seems like bait and switch. The customer wants a tool and they are selling a self-help program, except, the things you need self-help on, they don’t even address. You have to do that (all important) part yourself, with essentially zero guidance.

5) Scrum itself gives no guidance on how such dysfunction should be eradicated, how long it will take, or what it will cost. Therefore organizations are being asked to leap into the unknown, based merely on faith, when even the Scrum “framework” itself covers no mechanism to solve the dysfunctions that are “surfaced” by Scrum.

6) Scrum requires the team to be able to Solve the aforementioned problems — things the team has no training in and are arguably well beyond the scope of software engineering in any case. This is left as an exercise for the user.

7) Software Engineers should not be in charge of solving organizational level dysfunctions

8 ) There is no real reason an entire company should change it’s entire corporate structure just to suit the needs of one department, whether it’s IT or any other.

9) I have never seen any concrete evidence of any Scrum Master solving “organizational” dysfunction. The most I have seen is them confronting team level or departmental level dysfunction, nothing about this mythical “organizational” dysfunction.

10) At the end of the day no (other) tool, software or methodology “framework” requires you to spend years eradicating “organizational” dysfunction before you can (possibly) reap benefits.

If someone said you should spend 2 years testing out Java, Ruby, Haskell, TFS, SVN, Lean, Kanban or whatever, making sure your organization is dysfunction free, few would go for that proposition.

But in Scrum Land, that’s just accepted as part of the territory without any question.

My personal opinion is it’s a convenient cover story to string along corporations for years while they make this “transition” and then have plausable deniability when things don’t work out for the company — hey “Scrum works” you just didn’t eradicate enough dysfunction — at least they got 2 years of invoices….

The Scrum marketers make many bold and in some case ludicrous assertions; all of these bear greater scrutiny than they have been subjected to to date, and I hope this post is a step in that direction.

PostAgilist