Discussion-Driven Development

One of the essential activities that a team has to do in their day-to-day work is to learn. Continuous learning is what makes a team progress and improve in what they do, which improves the quality of the products they are able to produce. Without this learning, progress slows down and we stagnate in the value we can bring.

However, learning comes with certain problems that we have to learn to manage. One of them is analysis paralysis and that's what we're going to talk about in this article.

Learning Leads to Discussions

As we have discussed, encouraging continuous learning in a team is essential and healthy to improve quality and increase the value it brings. However, collaborative learning in a team inevitably leads to debate.

When different team members and different profiles learn and immerse themselves in a new topic, it's natural for discussions to arise about each other's point of view. Different people understand the same topic in different ways, and while they may essentially have the same thing in their heads, there are always nuances to discuss.

I've seen this recently in several teams that we train at Mercadona Tech. We're introducing architectural changes and new concepts that will undoubtedly improve the way we build software. However, this is sometimes leading us to what I call Discussion-Driven Development. We often spend more time philosophizing about how to build software than actually building it.

Is it bad then to debate these issues?

Not at all, however, we have to learn how to manage these situations so as not to block ourselves with endless debates and focus on what is really important: providing value to our users with the highest possible quality.

How to manage Discussion-Driven Development

In the last year we have learned a lot, we have been trained in many new topics and, as you might expect, we have discussed a lot.

And to solve the possible problems, we have tried different approaches and iterated the way in which we debate our doubts and the differences we have between us so as not to beat around the bush. Here are a few:

Consensus-Driven Development

One of the first things we implemented was learning not to argue in the middle of a development. When we were pairing, it happened to us many times that we started to debate about what was the best way to implement something. We debated about the nuances that each of us understood about the pattern or design of the day and spent the precious time we had to dedicate to our users in discussing.

So we decided to stop, which required a lot of discipline and willpower.

To help us, we implemented a way to manage these issues: every time a design question arises, and as long as it can be postponed and does not compromise the mid-term, we let the person with the keyboard in the pairing decide the solution and we write down the doubt as an issue in the repository. That way we don't get blocked, we push forward and make a defer commitment of the decision.

Then, when a few issues accumulate, we have a small session where we discuss all these doubts and reach a consensus as a team on how to manage each one. As a result, we write ADRs (as concise and to the point as possible) about the decision and context so that it doesn't come up again.

In this way we manage to reach an agreement, but without stopping to discuss every half hour while providing value to our users.

Continuous training

Another dynamic that we actively apply to reach consensus is active training sessions. This one that we have recently implemented involves getting together as a team once a week with a topic to discuss and a part of the code where to apply it.

For example, we may want to address the issue of how to inject certain parts of the infrastructure into our use cases. So, we choose a series of training content (can be videos, articles, book chapters) and consume them before the session. In addition, a designated coordinator of the session chooses an area of the code where it would be interesting to discuss and apply what has been learned to refactor or implement the new solution.

In this way we achieve several things. The first is for the team to be trained on something new, something that's great. Then, we get different points of view to be discussed and to reach consensus on this in the process. And finally, and most importantly, we get the new learning to be applied in a practical way in the project. Grounding the concepts and validating, going down to the mud, the benefits it brings. Three birds with one stone.

Cross pairing

And finally, but the most recommended, is cross pairing (pairing between teams). There's no better way to learn than to learn from your peers. That's why one of the recommendations I always make when choosing stack or technology is that you choose what your friends use, in case of any doubt or problem, having them at hand will always avoid blockages and headaches.

With cross pairing you achieve the same, you learn how other teams work, they teach you the details and problems they have faced and the solutions they have come up with after a lot of iteration. You save yourself the whole process of headaches and hitting yourself against things you don't know and you also provide them with something very valuable: a fresh point of view that can challenge them of how they do things, something super healthy. So it's a win-win.

Learnings and consensus

As you can see, learning new things as a team is vital to keep moving forward. And if you know how to manage that learning so that instead of slowing you down, it gives you a boost forward, you will be able to add tremendous value to your product and your users, offering overwhelming quality.

So now you know, let's learn and discuss (but only what is just and necessary!).