How to Make the Most out of Agile Methodologies? (Part 2)

In the first part of this article, we covered essential topics such as team formation and decision-making. We also highlighted the team lead role and its importance despite missing from official Scrum guides. If you’re interested, my colleague Martin Patsov talks about the official Scrum roles and Scrum meetings here. I also shared some real-life stories from my professional experience with agile methodologies to help you avoid making the same mistakes.

Now, we’ll discuss team goals, retrospective meetings and the fine art of finding a balance in agile teams.

Setting a common team goal

While following agile methodologies, many teams decide on a common goal in Sprint planning. Initially, it is all good, but later on, team members don’t act as if it’s a team goal. It is also during the planning session when a team distributes work tasks among the developers.

But what happens when someone finishes a task in one day, and someone else takes need three days for it? 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. Thus, 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. This is the concept of pace alignment.

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:

Unbalanced agile 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 in the promised period. Instead, it is much more valuable to 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:

All of these dysfunctions lead to an unwillingness to work with each other and to help each other. And this is exactly the opposite of what the philosophy behind agile methodologies teaches us! Here is what I did at first:

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 of all the objections that they hear from their clients. Then, they put those objections in the sales pitch and challenge them on their own. This happens before clients even have the chance to touch on them. Otherwise, as soon as the client says it, you cannot challenge it anymore. 

Dealing with different opinions

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 right about something. Then, it turns out that the other idea is better and I have somehow 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 as you do.

Outsiders’ perception of the team

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 by this feedback because it indicates that all the efforts we make on our team formation are fruitful. That is how outsiders should perceive our team: as a unit. Not as a group of people with different seniority and different goals. In a team, if the seniors receive positive feedback and the juniors get more negative or neutral feedback, then there might be an issue in collaboration.

Retrospectives & how to make them more effective

Recently, I was in a team where we couldn’t discuss technical topics during retrospectives. The argument behind it was that “this is not the goal of this meeting”. This statement confused me as I think many teams have a retrospective simply because it is part of agile methodologies. However, the main focus of many retrospective meetings is how we improve the process: what went well and what didn’t. At times, it happens that the team didn’t achieve the Sprint goal. Then, they discuss 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. 

A code-devoted meeting

I think that teams need a meeting 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 to write code 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 on 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’s videos on code design and others.

Many teams just make a list of best agile practices and start to follow them. Butt people often don’t understand why they follow them, or they tend to forget to use them. That’s why our team prefers to keep a list of training materials with the best practices and why they work.

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. 

Conclusion

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.

Today, agile methodologies focus on fixing this issue and staying up to date with the business environment. But for a methodology 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, and having them heard is extremely important. Plus, having someone around to help when things go wrong is an essential aspect of team members’ well-being.

What challenges has 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 methodologies.