self-organised teams ; title names vs stakeholders' interference
I had a debate recently about what is the most important action to favour self-organisation in a scrum team :
- either by removing any titles to members of the development team ;
- prevent stakeholders from interferering negatively with the development team.
No titles for the development team members because the team is accountable for what it has defined it will do during the sprint as a whole. Although we generally see that in a team, certain members have more experience in certain fields rather than others. I personaly tend to think that how the teamp members call themselves is down to the team members. Naturely, certain team mebers will have a tendency to pick items according to their personal strenghs. And, it is down to the teram itself to decide how to share knowledge across the team to increase each others' compétences. So title names or no title ames is not really critical.
However, getting stakeholders interfere and influencing the development team, this seems to me it will have a very negative impact on its' ability to self-organise.
Some tend to think that no title for the development team members is more important.
I would like to have your point-of-view.
Patrick
Like anything, it depends. The thing to focus on would depend on what is preventing the self-organization of the team. However, if both were present in a team, I would probably focus on the stakeholders interfering with the team first. It's possible for a team to have titles within the Development Team, yet be a self-organizing team.
Titles only become a problem when individuals on the team cling to the titles. For example, when individuals refuse or begrudgingly accept work that isn't associated with their title or when individuals believe that their title gives them superiority over others. Finer grained roles and titles are a reality in many organizations and are associated with pay scales and career development, and that's a hard thing to change in some organizations. It's easier (but still not easy) to change behaviors and mindset within the Development Team.
Stakeholders, on the other hand, can interfere with the Development Team's way of working in many ways. Getting stakeholders to understand the team's methods and way of working and how that is beneficial to them can help the team focus on delivering value, often quickly and with high quality.
I had a debate recently about what is the most important action to favour self-organisation in a scrum team :
- either by removing any titles to members of the development team ;
- prevent stakeholders from interferering negatively with the development team.
Perhaps the most important action is to challenge false choices. Both of the actions you mention, and more, would lie within the gift of a self-organizing team.
Thank you for your inputs and your thoughts ovder that matter.
In my opinion, titles would be the last thing I would worry about. If you look at the Scrum Guide's section that describes the Scrum Master you will notice that no where does it say anything about helping the team to stop recognizing job titles. That is because there is nothing in successful self-organized teams that depends on not recognizing job titles. Yes the Guide does state that Scrum does not recognize titles within the Development Team but it never says anything about removing them. That statement is more to emphasize that the team is not a group of individuals limited to a single job, it is a group of skilled individuals that are willing and able to do anything that is needed in order to incrementally deliver potentially releasable units of value.
The real key is to help everyone understand that every member of the team is accountable for the work being done by anyone on the team. For that to be successful, you have to focus on helping the team build trust and group accountability.
Stakeholder interference can be an issue that can cripple a team. But it can also be used to the team's advantage if the entire team thinks as one. As a Scrum Master helping the stakeholders understand how to best interact with the team is important but be careful that you don't cause the stakeholders to pull away from the team entirely.
If you read through the Scrum Guide section on the Scrum Master paying particular attention to the responsibilities that the Scrum Master has to others you will see a list of items that are targeted towards helping a team become better at self-organization and helping an organization to allow self-organizing teams to develop.