Scrum requires a self-organized team to deliver "done" increments at the end of each Sprint. This peculiarity sometimes raises criticisms and questions when it is discussed in trainings or when coaching the clients: how can a team work without a leader? How are we going to do our job, if no one tells us what or how to do it?
Lire la Version Française - Podcast en Français
The Scrum Guide states that:
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”
Self-organization will lead to performing Scrum Teams; the Scrum Master has to ensure that Self-organization is understood and correctly used. He helps each individual to contribute to this objective.
I believe that to allow a team to self-organize, you need a mix of faith, trust and courage:
- Faith in Scrum: thanks to high frequency of inspections and adaptations, people will be engaged in improving their way of working
- Trust others: their good faith! Because every human being that has a clear goal wants to do his or her best to accomplish it
- Courage to let it go: let people take the time needed to experiment and understand. Being available to each other to help each other, to point out any behavior that does not favor self-organization
During years of teamwork, I observed the following unbalanced accountabilities. This list is not meant to be exhaustive or in a particular order. I'm interested to know if someone has lived the same or similar situations.
Unbalanced Accountability #1 – The Product Owner is the King
The Product Owner dictates the law, not compromising with the 
Development Team and forcing to deliver Increments with fixed scope at the end of each Sprint.
The strong position held by the Product Owner, pushes the DevTeam to deliver quantity, quality is a subject little discussed.
High chances are that, without any improvement, the Scrum Team will create technical debt, the Development Team will suffer of low morale and turnover.
It’s difficult to Self-organize in this case, the Product Owner is going beyond his accountability of Optimizing Value, the Development Team and the Scrum Master haven’t enough strength to counterbalance the situation.
Unbalanced Accountability #2 – The Development Team Dictatorship
In highly technical environments, where Software and System Architects have a lot of power and collaboration between business and IT is low, I’ve seen Development Teams working on beautiful technical products, but are they creating value?
The Product Owner is often a Software or System Architect, very focused on making the Product right and writing technical specifications for the Development Team. The Product Owner is more the Development Team Chief than a Value optimizer.
In this configuration the balance is all on the Development Team side inhibiting the possibility of creating a Self-Organizing Scrum Team.
Unbalanced Accountability #3 – The Scrum Master is the Project Manager
This is particularly familiar to me, because I’ve been this kind of Scrum Master in my first experiences, I’m sorry for the team (if you’re reading)!
As Project Managers, people are accountable to respect Schedule, Time and Budget. Command and Control is very common and, most of all, all the decisions are taken or validated by one person, the Scrum Master/Project Manager.
In this situation, if the Scrum Master/Project Manager is absent, some decisions may be taken, most of the time the preferred solution is to wait for the Project Manager to be back!
In this case, the team isn’t self-organizing because of the Scrum Master misunderstanding of his role of Servant Leader.
Unbalanced Accountability #4 – The Organization is the Boss, no one decides
Maybe one of the worst situations. The Scrum Team is victim of the fragmented responsibilities in the Organization and the complexity of the hierarchical chain of command.
As a consequence, the Product Owner has no authority and legitimacy about the Product and decisions are often overridden by someone else.
The Development Team self-organization is undermined by a multitude of silos. Organizational complexity is so high that no-one can decide anything before the functional managers validations.
In this case, company culture and Scrum misunderstanding may be the impediments to self-organizing teams.
How to overcome Unbalanced Accountabilities?
Self-organization works if every individual understands his accountabilities, is engaged in respecting them and pretend the same from the colleagues.
The Scrum Guide beautifully and clearly defines three simple accountabilities, for each role:
- Product Owner: optimizes the Value of the Product
- Development Team: delivers “Done” Increments at each Sprint
- Scrum Master: removes Impediments
Personally, I first had to well understand the meaning of the Scrum Master's accountability. I suggest that you take the time to think about the deep meaning of each role's accountability.
I recommend reading some books that helped me in the journey:
- The Five Dysfunctions of a Team, Patrick Lencioni (highly performing teams)
- Drive, Dan Pink (What truly motivates people?)
- Scrum, a Pocket Guide, Gunther Verheyen (Scrum Values, Scrum Accountabilities, Self-Organization)
- Coaching Agile Teams, Lyssa Adkins (How a Project Manager can become a Coach?)
Conclusions
Uncertainty and complexity are everywhere in our lives, personal and professional. This requires more collaboration and freedom to experiment new solutions.
Self-organization is the best way of working in complex environments. You’ll have better chances of self-organize as a team if:
- Roles are clearly and simply defined, the Scrum Guide is helping a lot on that
- Roles are understood and respected by all in the team and the organization
- People are made accountable for their roles and keep others accountable for theirs
- People have understood the Scrum Values and created a trusted environment ideal to learn fast
- Inspection and adaptation of the Scrum Team way of working is made at high frequency (Sprint Retrospectives)
Enjoy the journey!