It’s been a long time since I wrote the last (technical) entry. The reason for that is that my work changed a lot: I switched from a software project to product development, my role changed from developer/architect to project lead something. Finally, I ended up as Product Owner in a team developing a great software product (I will come back to the product in following posts).
No doubt: Scrum comes with a lot of great ideas! They are even applicable on a product development process. But on the other hand, there are some strange terms and metaphors which may lead to misunderstandings (at least they were misunderstood in the two or three teams that I was part of) in the Scrum process. Taking these terms/metaphors too literally may be contra-productive. Let me point this out:
The first term is the self-organizing Development Team. What I witnessed as misunderstood is the term “self-organizing”. I survived development processes where “self-organizing” was interpreted as “each decision must be taken unanimously”. It ended up in endless discussions without any result. It felt like (and it was as productive as) the UN Security Council. In contrast to this, 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.
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. That is as true as a partitioning a marathon run into 422 consecutive sprints of 100 meters will make you run the marathon faster. You’ll end up in hospital.
By the way: I found this item on a flipchart in a meeting room right after a Sprint Retro.
I prefer “iteration” over “Sprint”. Am I too old-fashioned?
The next point is the term Scrum itself. A Scrum is a situation in a Rugby match where 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 (or who pushes me)? I really don’t like this metaphor.
Last point: The Scrum Guide states that Scrum is a framework for developing and sustaining 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.