4 min. reading time

No doubt: Scrum comes with a lot of great ideas – and even better: They are applicable on a product development process. But on the other hand, there are some strange terms and metaphors which may lead to misunderstandings in the Scrum process – at least they were misunderstood in the teams that I was part of.

Taking these terms/metaphors too literally may be contra-productive. Let me point this out:

The self-organizing team

The first term is the “self-organizing development team”. What I witnessed as misunderstood is the term "self-organizing". I survived development processes which interpreted "self-organizing" as "each decision must be taken unanimously". It ended up in endless discussions without any result. It felt like the UN Security Council and wasn’t productive at all.

In contrast, I think the "team" metaphor is excellent. The DFB (German Football Association) states that it is an important skill for team coaches to identify the team leaders and to build team hierarchies. The Scrum Guide says the same in other words:

"Development teams are structured […] to […] manage their own work".

They are structured! “Equal rights for everyone” is definitely a structure, but I don’t think it’s always the best structure for a development team.

A sprint has nothing to do with running

The second term is the metaphor “sprint”. A sprint (in sports) is breath-taking and exhausting. I don't want my team to be exhausted. The metaphor suggests that Scrum will raise your development speed – and that is sometimes the expectation of stakeholders or Scrum team members as well. But this expectation is as true as partitioning a marathon run into 422 consecutive sprints of 100 meters will make you run faster. This won’t work. Instead, you'll end up in hospital.

By the way: I found this item on a flipchart in a meeting room right after a sprint retrospective:

too-much-tasks-for-a-sprint


Not a good feedback, don’t you think? 
I prefer “iteration” over “sprint”. Am I too old-fashioned?

Do I have to kick my co-workers?

The next point is the term “Scrum” itself. A scrum is a situation in a Rugby match in which the players of the two teams "close up with their opponents so that the heads of the front rows are interlocked" – and then they push and shove and kick in order to get the ball. In a Scrum product development, who is the opponent team? Which person do I have to kick and who pushes me? I really don't like this metaphor.

Am I really developing a product?

Last point: The Scrum Guide states that Scrum is a framework for developing and maintaining complex products. It defines the role Product Owner. So, if you apply Scrum on your software development process, please ask yourself: Am I developing a product? If not, what are the consequences if applying Scrum?

So, Scrum enthusiasts and doubters, I herewith invite you to “close up with me so that our heads are interlocked” ;) In other words: I’m looking forward to your comments.

Comments