According to current surveys, Agile software development is now implemented by a majority of organizations and Scrum is the project management framework the most widely used in these companies. The reality of the Scrum implementation could always been discussed, but one of the main characteristic of Scrum teams is that they are (or should be) self-organized. Gone are the days where a project manager would assign work and have make decisions for the team.
The side effect of this situation is that team members are now responsible to assign between themselves the workload and they are also the first one that will need to deal with conflicts between team members. The former project manager authority and responsibilities are now spread amongst the Scrum team. But do Agile developers really want this?
The ScrumMaster is there to remove impediments and smooth the relationship between team members, but he has no special authority in the team. I don’t think that self-organization will create more conflicting situations than traditional project management, but I don’t think it will solve all people issue either. Self-organization relies on the ability of team members to communicate and negotiate the workload, the task assignments and the technical or personal conflicts that they might have. The transition from a hierarchical team organization to a flat relationship where everybody participates is not easy and faces many challenges.
Software developers have in majority an introverted personality type and this is not the best asset to interact with colleagues, sometimes even just to express needs or feelings. This might be eased if there is some friendship feelings between team members that enhance confidence to speak, but this is not the case in conflict situations. Self-organization might end us as just being organized by the most vocal members of the team and those are not necessarily the best one. It is the role of the ScrumMaster to prevent this situation.
Another implied hypothesis of self-organization is that all team members have an equal weight in decisions. This could not be the case when you have teams that mix internal employees and contractors. If external members are a minority, employees will often want to take the most interesting part of the work for themselves either with the noble intent to keep the core application knowledge internally or sometimes with a little jealousy to see freelance people earning more than their own salary. In this case, the participation of some members of the team to its organization will be limited.
If a Scrum team could be self-organized, this is rarely the case of the entire organization that hosts it. Team members might still have different titles or functions in the organizational charts that could impact the power relationships between team members. This is especially true when project managers are used as ScrumMaster in a company that transition to Agile. Developers might still consider them as managers and expect a top-down supply of solutions for the team problems.
Self-organization also implies a culture that allows individual responsibility, affirmation and positive contradiction. This is not always the case in all organizations or countries. In some places seniority is still a strong value and open conflict is something that should be avoid at all costs. I remember an Agile coach explaining the problem to implement Scrum in the Korean subsidiary of his company. He mentioned as an example the planning poker activity where younger employees feel harder to argue against the estimation of senior team members. It is also psychologically difficult to think that somebody arguing against one of your idea is not arguing against you.
Besides these human factors associated with self-organization, the team is now responsible for rising up the issue with non-performing members. This is the case of people that are either technically limited or that have a difficult personality to work with. Team members have now to negotiate with these people to try to use them as best as the can or initiate the process that will remove them from the team. As we might have wished sometime to have the power to fire somebody we were working with, having to do it for real is something completely different, as the Monty Python would say. If Agile is supposed to reveal issues faster than traditional projects that had a longer delivery timeframe, the creation of technical debt is not always obviously visible. Some initially working code might then reduce strongly the team velocity if some bad decisions were made at the beginning and heavy refactoring is needed. Pair programming is a practice that could help preventing this to happen.
The self-organization of Scrum gives more power to team members, but with the power also comes the responsibility. The transition from traditional project management is not easy and this organization might not be the best for all people or culture, local or organizational. I am not sure that all Agile developers want to bear some management responsibilities. Being Agile, doesn’t mean that development managers have to stop working to maintain healthy relationships between team members. Like the ScrumMaster, but from outside the team, they still have to be ready to provide support and actions to keep the project on track, walking on the thin line between letting the team grown and preventing issues to deteriorate too seriously.
Further reading
* Agile Coaching Tip: The Quiet Power of Silence
* Empowerment: The Missing Ingredient for Scrum Teams
* How to Make Your Culture Work with Agile, Kanban & Software Craftsmanship
You’ve identified many issues with the self organize team theory.
How is the scrum master, who is usually just a typical engineer with no special training or people skills, supposed to solve these issues?
I talk about these subjects in my post “Scrum as the new Command and Control”
Jordan