Self Organizing Teams

I have been working in an agile way ever since I started working, I have mostly used scrum and in scrum there is a lot of focus on having self organizing and self sustaining teams. This is stressed even more by the fact that in scrum you don't have the role of team lead. This means that a team should have all the skills required to do its work from start to finish. Theory is one thing, but how does this go in practice?

As a first remark I want to say that I have been in scrum teams where the scrum master acted as a team lead as well. I am not a fan of this as the goal of a scrum master is to be an independent an non-biassed person who is there to guide the team. Moreover it is nowhere written that there should be a dedicated scrum master and taking turns in fulfilling this role is possible as well.

I do believe that having a self-sufficient and self-organizing team is the way to go. There is nothing more annoying and discouraging than having to wait for other people to solve your problems or being forced to do certain things that don't make sense. That being said, I must admit that in most cases, teams never reach this stage, even if they are given the freedom to do so. There are however two aspects to the statement of a self-organizing team.

First, you have everything related with taking ownership of the application and code you are responsible for. Does the team have the skill and independence to deploy and maintain the application? This is everything that is involved in the day to day tasks. The biggest hurdle here is often company organization, where they tend to take ownership away from development teams and put them in specialized teams. This is by no means the only possible problem, a team should also have the maturity to be willing to learn new technologies that are required and take up the ownership, especially when things go bad.

Second, you have the focus on the ever improving goal of agile. The retrospective is the agile ceremony that drives this. A true self-organizing team will come up with new ways of working to improve their efficiency. They are willing to take up tasks to work on the process and not just on the code. The entire team should share a desire to always improve and move forward. I can not deny that I have seen teams where a lot of people where happy with the status quo. Sometimes it even felt as if a problem was not being addressed, or not tried to be solved because people could use it as an excuse.

For a team to become truly self-organizing there first must be a lot of trust. You need to trust on each other that when things go bad, you are there to help one another. You also need to trust each other in that sense that you know that you all want to do the best thing possible. Write the best code, with the highest value for the user, and improving efficiency of both the application and the entire pipeline. Such trust is only created over time, which can be a challenge as I have seen teams where people leave regularly. I am also partly guilty of this as I tend to switch jobs every 2 years. With such a variable team landscape the hiring process becomes even more important. You have to make sure you hire people that match together and have the same mindset.

The mindset needs to match that of the other members of the team. You can't have a single person who constantly aims to improve while the others prefer to stay where they are. The opposite is not a good thing either, having a single person who always is against any change. It goes further than that however, there should also be a match on the usage of technology, code styles, etc. There doesn't need to be an exact match, but there should be a sufficient match to allow everyone to be comfortable with the way of working and with the same views allow them to work together on trying out new things.

If the team is not on the same level, they tend to want to move in different directions, which typically means that you are moving nowhere and just tend to stay where you are. In such cases, a self-organizing team doesn't work, you can't just let the members agree on something. You need someone to take a leading role and decide which way to go. Nevertheless there should be some support of the team, and evaluating the changes is important, like it always is in a continually improving system.