The most common way to fail in introducing Scrum is to call it Scrum, but to bastardize it beyond recognition. It can happen out of ignorance as well as with evil intent of proving Scrum to be a bad idea.
Typically the argument goes like one of the following statements:
- We cannot abandon the control, we have, and let Teams self-organize, Product Owners prioritize and ScrumMasters rule the process, it would be to risky.
- We are very different here, it would be very sub-optimal to use a standard pattern.
- We are so busy, that we cannot possibly spend all the required time on planning, retrospectives and such, we have to move faster.
- We don’t have the luxury of keeping teams together so we reallocate people as needs arises.
Plus a host of other reasons why this or the other thing in Scrum cannot be done or achieved.
Of these, the first one is often very subtly presented as management’s need to preserve the possibility of acting in a crisis or when a change in priorities occur. Behind the curtains it is often just a storefront for preserving existing power structures.
In companies dominated by the neo-Taylorist paradigm of expert driven large upfront planning, we often find a very deep hierarchy and people with very detailed areas of responsibility. People tend to cling to these areas as status is perceived to follow the expert role and the associated power over certain things.
Introducing Scum (or other Agile disciplines) tend to challenge those power structures, so people often resist out of self-preservation and get various foreign elements embedded in the so-called Scrum. This could be:
- Keeping a Project Manager around the project with some reporting responsibility, that typically should rest with the Product Owner.
- Having eternal Architects, test managers and such that should approve of various technical solution.
- Maintaining distinct roles and individual measurement, evaluation and compensation in the Team.
- Separating the responsibility for the flow of money and value from the Product Owner.
- Keeping a parallel reporting (and sometimes command) structure going, resulting in twice the overhead plus confusion.
So in a way people are setting up a straw man called Scrum, who is to blame when something goes wrong. But it ain’t Scrum.
So why does it happen? I think there is sufficient pressure on, that people feel they must “do Scrum”, so they try to do something, that ruffle as few feathers as possible, or they perceive that it only has something to with the tactical level (the Team and execution of jobs) and the upper echelons can keep doing what they do today.
So a bullet proof way of failing at introducing Scrum is to treat it like a Baseball game, where you don’t have a bat, so just take a broomstick, you don’t have a ball, so wrap up an old sock, you don’t really have a team just take who is available and finally change the bases so it doesn’t upset the guy with the lawn mower. You will probably quickly get to the conclusion that Baseball is a rather stupid game.
