Scrum has helped a tremendous number of organizations, getting out of their dysfunctional type of working in silos. Whereas a military way of drawing up an organization like in the beginning of the industrial age has become popular (its easy to engineer, seems clear to run, and seems to give those with power even more power), it also proved to fail on a regular basis. With Scrum we wanted to gain back focus and collaboration.

The Scrum Model seems Promising in the Beginning

In a dysfunctional world it seemed promising, someone suddenly really taking care for the prosperity of a product, for its vision and purpose, instead of just having so called “requirements” been thrown over the fence. A true team engaged to build the product was inspiring. Not just silos handing over interim artifacts and pushing away overall responsibility. And having somebody, who really cared about issues with courage sounded powerful. Not just a top-down instance, always careful not risking their own options on the career ladder. Product Owner, Development team and ScrumMaster – the three amigos forming a real Scrum team for better outcome.

Scrum Model hits Organizational Reality

Well, that was the shiny part of the story, but quite often is just a dream. Sure, a typical start with Scrum in a dysfunctional organization might have been already happy about the three roles taking care for their part. While still backed by a culture of power, separation of concerns and hierarchy, what might then have lead into a trap of focusing too much on the roles alone, with a quite limited focus on what the actual purpose was.

We know these kind of statements to well, from what we hear around organizations running Scrum

  • “Product Owners are pushing us too much work at the desk. And they are always concerned about our velocity not going up.”
  • “Product Owners are “chickens” at our daily meeting and are therefore not allowed to speak.”
  • “Product Owners are not invited to our retrospective. This is a team only meeting.”
  • “This is not your job as a ScrumMasters, let me talk to your boss.”
  • “Hi ScrumMaster, could you please tell us, what to work upon next? Is it allowed to do this or that in Scrum?”
  • “The team is not taking over their self-organizing duty and performance sucks. We’ll have to tell them to work harder.”
  • “This guy on the team seems not like a team player, lets get somebody else from the other department.”

Of course this list can go on and on. And it just tries to outline the one-way street a well-intentioned approach, getting started with Scrum might have taken. What felt like a relief from the old dysfunctional organization, might still just be an illusion, having not more achieved than just spent too much money for training or coaching.

Scrum Roles are not the Purpose

Now let’s get it clear. While Scrum can help a lot – bringing it on board via an educated approach, Scrum itself is not the purpose. Despite initial euphoria, many team members usually do not care much about the Scrum methodology itself. They are interested in doing a better job. They want to have time to focus on the needed level of quality. And they want to create something, which makes sense for them, but more important for somebody else. Stakeholders and especially clients don’t care either, whether you are doing Scrum. What they need is deliverables with impact. What they value is, having their most important business risks addressed. What they love is systems / organizations, they can rely on.

We don't need Product Owners and ScrumMasters. We need Scrum Master-Y via great Product Owner-Ship and powerful Team-Work

So without derogating the potentials of the Scrum framework, the real objective around Scrum should be Scrum Mastery, to be achieved via great Product Ownership and powerful Teamwork! It is not about the roles of ScrumMasters, not about Product Owners and not about single Teams. Clarity about roles can help a lot. But sticking to roles does not make your collaboration more powerful. Hence your products and services won’t gain a lot neither. Maybe this might be even taken as a little hint towards Holacracy.

If you feel, your Scrum still shows quite a bit of organizational dysfunctions, maybe check back the boundaries of the implemented model themselves. And please let me know, about your path to ScrumMastery. How could you get out of the trap of the roles? How is your Scrum organization making progress? And can your stakeholders really sense a type of hyper-collaboration effort, leading to impressive impact?


Mike Leber
Share This