When I started my career it was normal to work in a highly hierarchical company, where you boss tells you what you need to do, what you need to focus and when you need to stop everything to work on something else that is more important to him. If you started to work in IT around the same time then me, you know very well what I am talking about. And I suppose you also got so excited as me when you started hearing about self-organizing teams, flat hierarchy, and similars. But, like everything in life, this brought us a lot of improvements but also new problems emerged.
In a self-organizing team you have the freedom and ownership to drive your product forward. The developer team can define the technical stack that will be used, the product manager can make the prioritization of the backlog according to her/his judgment of the facts, and the dev team will decide the best way to implement each story. Moreover, vacation schedule is also organized by the team, any problem is to be solved in the team, and so on.
What’s the problem on that? In my opinion, the main problem can be summarized in one word: maturity. And when I am talking about maturity, I am not talking about the years of experience, but about the team maturity which depends on the development of the maturity skill altogether.
I will start with a simple example. It is summertime, the busiest time for a vacation. And all of a sudden you realized that almost the whole team is gone for a vacation together. How come? Well, they all have kids and this is really hard not to take a vacation on those times if you have kids, since they are out of school. Was it planned to minimize the impact of this shortage of working hours on the product? No! And this is one aspect of the team maturity I am talking about. When you have a mature self-organizing team, there will be a plan, maybe a decrease in the overlapping time, in a way to allow all to enjoy the vacation with their kids but also not to compromise the product goals.
For me, the most negative impact we can have is in the decision making process. In a non-mature team, imagine you have a strong opinion person. The kind of person that will not give up a discussion until her/his solution is the chosen one. This person can be extremely skill and expert, but maybe the quiet guy from the team had a better solution but it was suppressed in the decision process. It can also happen that the team will decide to change a technology they have or to adopt a new one because they are excited about it, but the time impact it will cause is not discussed with the product manager before. Yeah, the product manager does not decide on technology or solution to be adopted, but the consequences it can bring have to be discussed with the PM who is the person that has the background information to analyze if it can be done at this moment, for example.
I have worked with Scrum Masters that were so good on identifying this problem and did a great job on supporting the team to grow together and active a good maturity working level. On the other hand, I also worked with Scrum Masters that did not have the same approach, and I, as a PM, tried to help on this. For me it is hard to ignore this, but It can also happen that the team will not accept this kind of inputs coming from a PM. It already happened to me, one person thought I was doing it because I wanted to manage them. Since this episode I became more cautious on doing that and trying to work closer to the Scrum Master instead.
I have some many examples on this topic that I could go on and on, but you would stop reading too fast. I think you could get my point on that, though. Maybe I will need to make another post on this topic in the future. 🙂