Setting a Common Team Goal
Many teams decide on a common goal in the sprint planning but do not act as it’s a team goal.
When a team plans to do some job, they also distribute the work during the planning session. But what happens when someone does a task for one day and someone does a task for three days? Usually, a senior developer can finish a task faster than a less experienced team member. То me, a team should have consistency in the time it takes to finalize a task. In my opinion, it’s better if a more experienced team member spends a day with the less experienced person, so both can finish their tasks in 2 days.
- For a period of 6 days in the first scenario, the first team member will finish six tasks, and the second will finish two tasks. In total – 8 tasks.
- In the second scenario, for 6 days the less experienced person will finish three tasks, and the senior will finish three tasks. In total – 6 tasks.
So looking at it simply and based on calculations, it’s better for experienced people to work as independently as possible. But in reality, we have the following issues with this approach:
- First, the team members will grow much slower, and their performance won’t increase over time.
- Second, they start to feel unhappy. Because serotonin and oxytocin in their bodies start to go off balance as they are left on their own (see Part one for reference). When a stakeholder asks why a given task is taking so long, you can imagine what happens with the happiness levels.
- Another aspect is that the stakeholders of the project also become unhappy. Usually, if there are 4 tasks that are finished fast and only one task that takes longer, we will most likely notice this one troubling task and focus on why it hasn’t been delivered.
Unbalanced Teams & How to Synchronize Them
Another benefit of pace alignment is that we have better predictability. When we estimate a story, it doesn’t depend on who will work on this story to be finished in the promised period. Instead, it is much more valuable that we finish the tasks consistently as a team.
Teams that make promises as a group but execute them individually have a disbalance. Usually, this kind of disbalance points to some of the five dysfunctions in a team: Absence of Trust, Fear of conflict, Lack of commitment, Avoidance of accountability, Inattention to results.
All of these dysfunctions lead to unwillingness to work with each other and to help each other.
I was avoiding conflicts as I thought it’s a bad thing. But then I found out that there is a way to have a healthy conflict. Actually, healthy conflicts are a way of collaboration. I noticed that when you challenge someone’s opinion, they start to close and automatically go into defensive mode. There is a technique I learned from sales training which tells you that you should never challenge a client’s opinion exactly because of this. So what salespeople do is that they make a list with all the objections that they hear from their clients. Then, they put those objections in the sales pitch and challenge them on their own before the client has the chance to say them himself/ herself. Otherwise, as soon as the client says it, you cannot challenge it anymore.
If I have a different opinion, I shouldn’t state that the other person is wrong but instead try to guide him/ her to the problem that I see. I try to engage them in my context and try to step into their shoes and understand their hidden context. Oftentimes it happens that I think I am correct but it turns out that the other idea is better and I have missed key aspects of the problem. So whenever you have a situation where you don’t agree with someone, try to understand why the other person is not thinking the same way as you do.
This year our team received the following positive feedback from a partner: “We did not feel any difference in the seniority level.”. I was super happy and excited from this feedback because it indicates that all the efforts we make on our team formation are fruitful. That is how a team should be perceived from the outside. As a unit. Not as a group of people with different seniority and different goals. If in a team the seniors have positive feedback and the less experienced people have more negative or neutral feedback, then there might be an issue in collaboration.
Retrospective Meetings and How to Make Them More Effective
Recently, I worked in a team where it was forbidden to discuss technical topics at the retrospective meeting as “this was not the goal of this meeting”. I was so confused about this statement. The way I see it, the retrospective meetings in many teams are just done, because they are part of the agile methodology. The main focus of many retrospective meetings is how we improve the process: what went well and what didn’t. If the sprint goal was not achieved, the discussions are in the direction of whether the estimation was wrong or if the tasks weren’t clear enough. None of those leads to improvements in how the team collaborates or writes code.
In my opinion, a team needs a meeting on which to decide how they write code. From our technical discussions during retrospective meetings, we make norms on how we write code. Because when developers have different opinions on how the code should be written, on every code review these differences lead to slower performance. All team members should strive to minimize the time we spend on fixing issues during code reviews and fixing issues in general. That is why in retrospectives we also discuss code review comments and we agree what resources everyone in the team should cover. In fact, we have a list of resources that every newcomer should read and watch. Some of them include Uncle Bob’s training on clean code. Victor Rentea’s lecture on clean architecture, Venkat Subramaniam videos on code design and others. Many teams just make a list of best practices that they follow, but people often do not understand why we follow them, or they tend to forget to use them. That’s why we prefer to make a list of training materials that explain the best practices and why they are important.
One technique that I find very useful for retrospective meetings is the Five Whys. The idea is that you don’t just scratch the surface of the problems, but you try to dig deeper. With this technique, you can identify some root causes of the challenges the team faces.
I’ve taken the courses of Uncle Bob on agile methodologies. They emerged because the waterfall model didn’t work well and software development needed a paradigm shift. Teams in the past were going into analysis paralysis with all the UML diagrams, planning for months while in the meantime the environment was changing. The primary focus of the agile methodologies is to fix this issue and stay up to date with the business environment. But for a methodology or a process to work, it’s equally important to focus on the people, not only on the business issues. Taking care of their growth, having someone they can learn from, having them heard, making sure that there is someone to help when things go wrong are very important aspects. What challenges have your team faced? Please share how you resolved them as a team so we can all learn from each other, grow as professionals and make the most of agile practices.