After many discussions with students and other Agile practitioners, I came to the realization that the concept of self-organization in Scrum is widely misunderstood. And the whole point of Agile and Scrum is to create self-organizing teams that can solve complex problems on their own.
How can we build the right culture if the essential concepts are not implemented as they should?
Let’s create a better awareness around this topic and dispel some myths about self-organization in a Scrum Team. In this video, I’m talking about the role of a Scrum Master in creating autonomous teams.
We’ll uncover what an impediment is and what it isn’t. We’ll talk about one of the misunderstood stances of a Scrum Master – the Hero. And, as always, we’ll review a real-life situation to illustrate the points discussed.
Misconceptions about self-organization
There are many different ways of how self-organization as a concept is being misinterpreted. Let me run through some of the major ones.
Zero boundaries
Firstly, there is a notion that when a team is self-organized, they can do whatever and no one can stop them. That is 100% incorrect (at least when we talk about Scrum).
When there is self-organization, there have to be some boundaries. In Scrum these boundaries are created by the clear purpose and accountabilities of each role and other elements of Scrum.
The Development Team is responsible for delivering a Done Increment at least once a Sprint. They can do whatever, as long as they focus on achieving that purpose.
Tech side only
Secondly, an organization assumes that the Development Team should only self-organize around how they do their work on the technical side. Meaning, they decide how to implement the solutions, but cannot decide anything else that is dictated by the organization instead. This might include their internal processes, their communication with others, dependency management, bug and tech debt management, and more.
However, for the team to be truly self-organized, they need more control over the way they do things not only on the technical level but on the people and process side. Otherwise, their self-organization will be very limited and they won’t be able to achieve the same results as a team.
Scrum Master owns the process
The Scrum Master for promoting and supporting Scrum as defined in the Scrum Guide. That often leads to Scrum Masters completely taking over the ownership of the process and deciding what and how should be done under the Scrum umbrella.
However, that is not the way the role has been intended to work. While Scrum Master should focus on helping everyone implement Scrum as it is defined in the Scrum Guide, the ownership should stay with the team (the Scrum Team for that matter).
A Scrum Master cannot play a role of a Scrum Police if they want to let their team to self-organize.
In conclusion
Self-organization is a complex concept and it can be difficult to get right from the start. Any Scrum Master should always ask him or herself: how can I help my team succeed while allowing them to self-organize?
For more insights on this topic, read my other articles: “Ruinous empathy of a Scrum Master” and “Scrum Master Don’ts“, or check out my online PSM 1 Certification.
Have you faced (or are currently facing) a situation where you are not sure whether you should jump in a solve a problem for your team or let them figure it out on their own?
Share your stories in the comments below about self-organization in Scrum.
