Scrum as the new “Command and Control”

Scrum promises an end to “command and control” management.

But does it really?

Let’s look at this in depth:

1) In the old way everyone had one professional manager they reported to

2) That manager may assign tasks or allow the team members to choose their own

3) That manager probably did some actual work such as creating specifications, estimating tasks, interacting with the BA’s, etc

In the scrum way we have

1) A Product Owner

2) Team members that report to each other

3) Probably still the old manager they had originally

4) The ability to choose your own task, as long as it’s a task that the product owner wants

5) Tons of ad hoc meetings, as well as daily scrums, planning and retrospectives, which consume the resources of the entire team, to replace the abdication of a dedicated professional manager in terms of handling these tasks

So let’s see what have we gotten.

The ability to choose a task that was enumerated and limited by someone else (the Product Owner).

What has stayed the same?

The team still is marching to the drumbeat of another, but this time it’s the Product Owner, as well as everyone else.

What have we lost? The ability to report to just one person.

We now have a new breed of novice level “mini managers” who must now spend countless hours in planning etc meetings that they previously did not have to — time that they could be using to create product.

So now the management of the project has completely (or mostly) been saddled on an already time constrained workforce, for seemingly limited benefit.

If estimates are vague and hard to predict anyway, why force the entire team into all day planning meetings? Why not just have them review and comment on the estimates provided by whomever is the task estimator?

This person (manager) can easily work in smaller increments — avoiding lengthy waterfall planning can be done in a traditional context without moving to a radical “Scrum” approach that seems to ignore the implications of what it recommends.

Additionally now everyone has to report to a committee of the team, product owner, and manager (if any).

As well, especially in a “Scrum” process, one is “commanded” and “controlled” to attend the 3 ceremonies, answer the 3 questions etc. If you don’t do that you’re not “doing Scrum”.

Which is fine, because your company’s job is to deliver product, not “do scrum”.

Management by committee has always been viewed as the hallmark of waste; that’s why government and large beauracracies are so inefficient.

Additionally, how this management by committee should be implemented is left as an “exercise for the user” and little if any guidance on how this should be accomplished.

I will be blogging in the future about Governance in Self Organizing teams.

Rest assured, it brings up many complex and difficult to solve problems.

They are solvable, however, and some of them have been discussed in the seminal paper by Nanoka et al, but ignored by the domestic Scrum industry.

Notably, Nonaka mentions that teams were “hand picked” by management based on their ability to work together, and if any member became too dominant, the teams would be adjusted to balance them out.

Where is this mentioned in the Scrum literature? How many organizations have really thought this through or have enough employees to do such balance without firing and hiring until some sense of balance exists?

Without this approach a “self organizing” team is likely to self organize along factional or other lines. A 4:3 faction ratio, whether it’s junior versus senior, QA versus developer, etc, will result in nearly half the team being tyrannized by a slim majority.

The bottom line: If you are “doing Scrum” — you are doing Command and Control by Committee.

Additionally you are replacing old redundant rituals (“overplanning”) with new redundant rituals (“overmeeting because you didn’t plan enough and everyone is part of all the planning”).

There is a reason that managers were invented in the first place — to fee up the time of the workers from having to manage.

Looking for a better way to manage in my mind makes a lot more sense than looking to foist that critical function onto the workforce, whatever that specialty is.

Of course I believe there should be transparency and trust between those parties — but that doesn’t mean all the management needs to be thrown down to the workforce.

To the extent that it is, I think then the employees should be the owners of the company and truly have the commitment, etc that goes along with that.

But that doesn’t seem to be advocated too much in Scrum land — the employees are saddled by the downsides but limited on the upside.

PostAgilist