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 methodologies don’t 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 – then the team goes into storming. Individual personalities emerge. This is a period 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.
Alongside applying agile methodologies in projects, I’ve been studying practices that can help a team shorten the period from forming to performing. It is during the performing stage that most developers, including myself, feel joy from our work. After all, no one likes to be in conflicts and competition.
In his book “Leaders eat last”, Simon Sinek talks about four chemicals in our body that are important for our well-being. Đ•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 haven’t united yet, and these chemicals are out of balance. We do not want to work with others because of the conflicts. That is why during the storming phase, the team might feel unhappy, unsatisfied, and go through a lot of stress.
How does your agile team make decisions?
From my experience as a senior developer and a team leader, I’ve noticed that every time frictions appear in the team, the main problem is that the team doesn’t have clear principles for making decisions.
Story 1: The power of making decisions
A few years back, I was a senior developer in a team of two working on a new greenfield project. As you can imagine, at the beginning of such a project, a lot of technical decisions lie ahead of the team:
Our biggest mistake was that we didn’t have an agreement on how we would make those decisions. So every time we had multiple opinions on a topic, we felt stuck in a never-ending conflict.
We were reaching agreements only when someone was tired of negotiating. Then, the agile team began to grow, and a new architect joined us. We now had a guy who could make those decisions for us! We were efficient discussions, and at the end of a meeting, we usually finish 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. In any team following agile methodologies, there needs to be something to break the tie for such situations. However, 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: Never-ending discussions
In the next team I joined, a similar thing happened. We were a team of 6 people, and this time we engaged in long 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 software development process to one person.
- Software architecture to another person.
- Project demos to another person.
- Testing .. and so on.
The approach of distributing powers might not work for some other teams. 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 unite 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 of 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 decide how you will make decisions as a group. Then, following the agile methodologies, you can start deciding on anything and quickly get out of that phase. This leads to quicker conflict management, 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 agile methodologies don’t contain a team lead role and the official roles in Scrum are: Product Owner, Scrum Master and Developers. The main arguments against the role of a team lead 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 read about an experiment in Google where there is a flat structure and no managers in the engineering organization. They called this “disorg”. At first, they liked the idea of a less structured environment, similar to a university. There, students come together for projects, often under the auspices of an advisor, and none of them feels “managed”. In 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 could learn from and someone who breaks ties.
I’ve decided to do a similar survey among the people in our team. I’ve asked my colleagues:
“What attracts you in 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. My first interviewee also mentioned, “But I don’t want simply to have courses and training, I want to learn from someone directly.“
Power comes with responsibilities
Years back, I took a course on leadership about the 5 bases of power by John French and Bertram Raven:
Formal (given) powers
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 contain the ability to give or withhold rewards based on performance.
Informal (earned) powers
- 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 types of informal powers are earned over time. You need to work some time 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 at the beginning of team formation. During this time, teams need to define their team goals and have someone to break ties. Also, when starting a new project, at first, no one has the knowledge of the project itself, so there is no expert.
Of all the powers, an informal leader at the beginning of a project can most 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 having a formal role for a lead.
How we do it at Dreamix
In our company, each team follows agile methodologies like Scrum and Kanban. Although they don’t have official team lead roles, we think they have organisational benefits. For example, our team 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. You can continue with the second part here, where we dive deeper into best practices on how to make the most out of two essential Scrum elements – Sprint Plannings and Retrospectives. Make sure you also check out our article on the anatomy of a good Scrum team!
