Almost three years ago, I wrote a post about how agile development teams can prioritize and handle tech debt in a productive way. (”Prioritering av teknisk skuld? Testa kvalitetsbarometern!”). Since then, a lot of people have read what I wrote and more teams have discovered better ways of discussing and handling tech debt.

I recently lead a department at a large, well-known company (Let’s call it TheMusicGiant), an organization and a product that many people have heard of, but also a company that not so many have any insight into. Do they have tech debt issues like everyone else? In spite of the fact that they are so successful and famous? Of course they do!

In my role as a tech leader and senior manager, my closest staff was a group of managers who in turn lead a number of software development teams. One of those teams develop mobile apps.

My good friend Rifat, who is the manager for that team, read my article and mentioned to me that he was going to try my model together with his team.

I should mention right away that everything described here is how I perceived what happened and how I remember what people said. If anything is incorrect, it’s all my fault.

At first

Team members were a bit reluctant. Even though they felt stuck in less productive discussions and even though they had rather different opinions on what constitutes tech debt – and of course what parts of their own code base that should be considered debt-ridden – they were still not really sure that a model or method from someone outside the team could be helpful.

but then

Rifat talked to the team. He told them he would like to improve the tech debt work; the discussions as well as the prioritization and the actual work in the code base. He also told them that he wanted to look at my model together with all of them, get their input, discuss it, perhaps modify it, then try it.

Rifat is a really good manager and also a senior mobile developer himself. On top of that, he is also appreciated by other teams and managers. All of this of course helps a lot when trying to introduce new models or new ways of thinking in a team.

So what did they do?

During their discussions, the team felt that they needed to change some of the wording in my original model in order for it to match their reality, to better understand it and to align better within the team – which is exactly how it should work.

They also added one question around ”How comfortable are we with [some code part]”, which I think is excellent. It’s exactly the kind of team adaptation that I would suggest when using this model.

What they told me afterwards

It seemed to me that the team members came out of the discussions happy and visibly more aligned – and also eager to get started on handling their tech debt. That last part is perhaps the most interesting one, since it is very common for development teams to try to stay away from handling tech debt. I was of course really glad to see that, but I also wanted to find out exactly what made them happy and aligned. So I asked.

Below is my interpretation of what they said, not their exact words – simply because I don’t remember the wording.

Why we like it, you ask?

From now on, we will spend a lot less time in fruitless discussions.

We have a simple but effective model for what to discuss and how to prioritize things.

The team is more aligned, which has also improved team dynamics.

It’s just more professional to do things this way.

The discussions were interesting and we actually had some fun, too.

So, in summary

To me, it sounds like the results above are well worth the time that the team spent on learning and adapting the model – which was around 2-4 hours.

Nice, huh?

—————————————-

My blog (most of it in Swedish) contains more articles on leadership, teams, recruitment, ways of working and other related matters.

Good luck!

/Björn