Have you ever been in a project where Scrum is done by the book but you feel that your team can be more productive? From my point of view, agile practices do not describe techniques to help with team formation. However, team formation is crucial for the success of the project. To get the most out of agile, you need a well-formed team. Therefore, I want to share with you what I experienced and learned in the past few years.
Team Formation Stages
Every team goes through several stages based on Tuckman’s model:
- Forming – this is the initial stage of the team where a group of people is being told what is required from them.
- Storming – and then the team goes into storming. Individual personalities emerge. This is a period, which is marked by conflict and competition. It can either break or make a team.
- Norming – if the team passes through the storm, the next phase for a team is where conflicts are being resolved and some unity in the team starts to form. The performance of the team starts to increase.
- Performing – This stage is where people feel happy and appreciated. The team managed to establish consensus and cooperation. They are organized and well-functioning.
I’ve been studying practices that can help a team go from forming to performing as soon as possible, as this is the stage where I and probably many other developers feel joy from my work. Noone likes to be in conflicts and competition.
In his book “Leaders eat last”, Simon Sinek shares about the 4 chemicals in our body which are important for our wellbeing. Еndorphins and dopamine are chemicals that drive us to satisfy our personal needs. Serotonin and oxytocin are the hormones that encourage us to work together with others. During the storming phase, when the competition and conflicts are high, people are not united, and these chemicals are out of balance. We do not want to work with others because of the conflicts. That is why during this stage the team might feel unhappy, unsatisfied, and go through a lot of stress. In the next few sections I will share some real-life challenges that I encountered as a senior developer and team lead and how they were resolved at the end.
How Does Your Team Make Decisions?
I notice that every time when there are some frictions in the team, the main problem is that the team doesn’t know how they make decisions. I can share two stories from my personal experience.
Story 1: I was in a team a few years back where I was a senior developer. It was a greenfield project and we were just two people in the team at the start. As you can imagine in the beginning of such a project there are a lot of technical decisions that should be made. Our biggest mistake was that we didn’t have an agreement on how we would take those decisions. So every time we had a different opinion on a topic, we were stuck in a never-ending conflict. We reached an agreement only when someone got tired of negotiating. What happened afterwards is that the team started to grow and a new team member joined as an architect. So basically, we now had a guy to make decisions! We were having efficient discussions and at the end of a meeting we usually finished it with a final decision. We were still sharing our ideas and discussing them, but when we went into ineffective bikeshedding, we managed to stop and reach a decision.
This analysis paralysis usually happens when you have some of the best people in a team and they all feel very responsible for the project. So, when such a devoted person believes that the team is about to make a wrong decision, they do their best to prevent it and long discussions emerge. There needs to be something to break the tie for such situations but I figured this out a year later when I joined another team. Back then, I couldn’t fully grasp why when an architect joined the team, things got better.
Story 2: In the next team I joined, the same thing happened. We were a team of 6 people and this time we engaged in longer discussions and decisions seemed so far away. Discussions were even longer and decisions were even harder to make. What happened this time? We made a decision on how to make decisions. We reached the following structure that worked for us:
- For minor things we don’t involve more than two people. It can be decided between the developer and the reviewer of a task.
- For bigger topics we might involve more people and discuss them at the retrospective meeting or if it’s urgent we organize an on-demand meeting and we hear the opinion of everyone involved and do voting. The important thing here is that we decided to add a tie breaker here as well. We agreed that the responsible person for a given aspect of our work has the power to overrule voting decisions if he/she decides it’s better for the team.
So we distributed and gave the power to overrule:
- Matters related to our development process to one person.
- Matters related to architecture to another person.
- Matters related to our demos to another person.
- Matters related to testing .. and so on.
This approach might not work for some other team. The team should follow the agile practices for this and iterate. Try to make decisions in some way and see if it works, if it doesn’t work, try something else.The best thing about this is that the people know how to make decisions and they are united around this. So if someone overrules your idea, you don’t feel bad because you already agreed to this approach and you know it’s for the best.
Another benefit from this approach we took was that we distributed the decision making process among team members and this made them much more engaged and responsible for the success of the project. During the storming phase, in my opinion, it is most important to first conclude how you will make decisions as a group. From there you can start deciding on anything and quickly get out of that phase. Conflicts get resolved fast and you enter the norming phase where you establish the norms on how you work together. Here it’s important to mention that every project is different and creates a different environment. Even if we have the same beliefs coming from our company culture, we still need to make norms because the environment changed.
Agile Doesn’t Describe a Lead role: Now What?
Since there is no lead role described in the agile methodologies, this role is also lacking as officially defined in some teams. The main arguments against defining this role that I’ve heard are:
- People will stop feeling the group responsibilities and become less proactive
- The lead will become a bottleneck and he or she will have to decide on everything
Although these things might happen, they do not happen solely because a person in the team has the explicit title lead.
In the second chapter of the book “Trillion Dollar Coach”, I’ve read about an experiment in Google where there is a flat structure and no managers in the engineering organization. They called this “disorg”. They liked the idea in the beginning to have this less structured environment of a university where students come together for projects, often under the auspices of an advisor and none are “managed”. At the end, they decided to ask the software engineers if they wanted a manager. And the answer was “yes”. Their arguments in favour of that were that they wanted someone they can learn from and someone who breaks ties.
I’ve decided to make a similar survey among the people in our team. I’ve asked them, what attracts you to a team and why would you want to work there? 80% of them said that they would go to a team where there is someone they can learn from. The first team member that I interviewed mentioned also – but I don’t want simply to have courses and training, I want to learn from someone directly.
Years back I took a course on leadership where I learned about the 5 bases of power described by John French and Bertram Raven:
- Formal powers – the powers that can be given
- Legitimate power – This power comes from the title
- Reward power – utilized by supervisors to motivate a response from an employee
- Coercive power – this is the opposite of the previous power. Both reward and coercive are defined by the ability to give or withhold rewards based on performance.
- Informal powers – the powers that are earned
- Expert power – This power comes from the advanced knowledge and expertise in a project, a given field or some other speciality. This power comes from education and experience.
- Referent power – (also called personal power) is based on admiration and respect and is individually earned from others over time. People with natural charisma, energy, and stamina have this power easier. People like to listen to them.
Both informal powers are earned over time. You need to work sometime with a person to find out that he is an expert or to feel his charisma to start listening to him. But as it seems, we need leadership most in the beginning of team formation, where we need to define our team goals and have someone to break ties. Also, when we start on a new project, no one has the knowledge of the project itself, so there is no expert in that. From all the powers, an informal lead in the beginning of a project can mostly benefit from the reference power, built up in previous projects. Having a formal lead will give him the chance to prove his informal leadership skills to the team without burning out. Without the informal powers, people will stop listening to you anyway. So there is no risk at all to have a formal role for a lead.
In our company the leads are responsible for people’s development and we do regular one-on-one meetings where we can serve the team in the best way possible. Having a lead role also makes the people in that role study and apply best practices in ensuring the team’s happiness and at the same time the quality and the performance of the team. Of course, formal titles come with formal expectations and norms but most importantly, each team member knows that the lead is responsible for certain project tasks and this is what really makes a difference.
I hope that my experience in teams helps you be a better team member or a better lead. Either way, I now know the importance of leads and the massive effects this role has on the whole team’s performance. Stay tuned for the next part to dive deeper into best practices on how to make the most out of two essential Scrum elements – Sprint Plannings and Retrospectives.