How we turned unresolved problems into one of our most valuable efficiency boosts

At the end of 2023, just after we’d been through a successful Agile transformation, we realised we had a problem with complaints. Not that we had too many of them, but that they weren’t changing anything. We were failing to make proper use of a Scrum ceremony called the sprint retrospective, one of the key meetings in the Scrum framework.

Used properly, sprint retrospectives are a powerful method of voicing problems and, crucially, finding their solutions. We were good at voicing problems. But we weren’t doing very well at finding solutions.

We were running retrospectives that were, in theory, useful. But in practice, they felt pointless. We spent an hour venting and getting cross about problems, and then at the next retrospective we’d talk about exactly the same issues. During the course of the sprint, nothing changed.

Scrum defines the purpose of retrospective as “to plan ways to increase quality and effectiveness.” That wasn’t what we got out of them. We just did a lot of complaining.

We complained about the quality of requests coming in from other teams, the missing context needed to analyse them and how much time it was costing the team to produce answers. We complained about who was responsible for tasks not reaching the release. And sometimes we even found someone to blame. But because we didn’t have a process to resolve any of the complaints, nothing changed.

We realised that if we were going to spend time complaining, we should at least do it constructively.

Why our retrospectives weren’t working

A few years ago, our retros felt like a rushed therapy session. In an hour, we tried to recall everything that had annoyed us over the past two weeks. It was hard for two reasons.

We had to dig up problems from across the sprint because there was no shared space to capture them as they happened.
Once someone raised an issue, nothing was done about it. There was no plan for resolving the problem.

We were using retrospectives as a rage room: a place to vent and then move on, with no follow up or resolution.

Meanwhile, genuinely suboptimal processes weren’t discussed, such as the way we operated load distribution. In theory, we were meant to share responsibility for release outcomes. What actually happened is the QA engineer organised the release process on their own. I know this because I spent hours doing it. And we didn’t share knowledge properly; critical information lived in individuals’ heads rather than in accessible documentation. But because our retrospectives weren’t being run properly, we never dealt with these problems.

Building a productive way to complain

Once we’d identified why the retrospectives weren’t working, we set about fixing them.

Instead of trying to remember problems at the end of a sprint, we started logging issues as they happened. We created a shared board in Miro so when we got to the retro, we already had a ready backlog of pain points, wins and open questions.

We created a resolution template so every complaint ended with an action item and an owner, rather than being left as a complaint. By making someone responsible we turned it into a problem looking for a solution, rather than an open-ended complaint.

And we stopped looking for who was at fault and started looking for the bottleneck in the process. Mediation replaced blame, which made it easier for people to raise concerns.

Here are four real examples of how complaining with purpose changed things for us.

1. A bot for scheduling on-call shifts

On-call duties are an important part of how our team operates. They include monitoring overnight test runs and fixing flaky tests, answering questions from internal stakeholders and helping to localise production incidents. They’re part of the job; not the most popular one, perhaps, but essential for a product as complex and critical as ours.

But we didn’t manage them very well. We tracked the rotation in an Excel spreadsheet, filling in weekends and public holidays by hand. Everyone hated it. We started griping about updating the spreadsheet, but instead of the griping becoming a problem in itself, we turned it into a solution.

We built a bot. The bot now handles the rota (using a database instead of Excel) and sends notifications to the team channel.

The bot then spread to other teams and became a popular internal product. It no longer just allocates shifts; it accounts for holidays and removed any unfairness associated with a human picking the rota uses a random draw when someone needs to cover unexpectedly. And you cannot argue with randomness.

2. Balancing the workload

Our release procedure involves more than ten mandatory steps, covering formal sign-offs and quality acceptance testing in the staging environment. The whole process takes up to three or four hours per release. Historically, it all fell on QA. For everyone apart from the QA engineers, this was helpfully convenient. For the QA engineers, it was not.

We wrote out the procedure step by step and began sharing release ownership with the development team, using the same bot we used for the on-call rota. We increased the release frequency from once a sprint (every two weeks), to weekly, which cuts the volume of work to be done in one hit. And if nothing else, we have a much happier bunch of QA engineers.

3. Fixing the grooming

We used to repeatedly blow sprints because of poorly defined requirements and mid-sprint rethinking of tasks. After several retrospective discussions, we overhauled our grooming sessions (another Scrum ceremony) to include deep task analysis and mandatory acceptance criteria. In parallel, we introduced shift-left practices in analysis and testing. The result was more predictable sprints: well-defined tasks generate fewer questions during implementation.

4. A platform for any question (even the small ones)

One of our developers kept coming to QA to get an authorisation token for developing and testing internal services. It disrupted both sides every time; he had to come to us, and we had to stop what we were doing to help him. Yet, no one stopped to ask how we could improve the situation.

It wasn’t until our retrospectives became a safe space—allowing him to finally vent about how inconvenient this was—that things changed. The team immediately suggested a few simple ways for him to generate the token himself. As a result, he got the autonomy he needed, and we eliminated an unnecessary context switch for both sides.

How complaining improved our working life

First, the team became a more comfortable place to work. Second, our incident numbers dropped by 76%. In two years of active process work, we cut the number of production incidents from 87 to 21, while both system complexity and release frequency continued to grow.

A note on severity levels: our production incident prioritisation runs from SEV-1 (highest) to SEV-4 (lowest).

2022–2023: 87 incidents. The starting point. Mostly low-severity noise (55 SEV-4 incidents) with a significant number of SEV-3 (32 incidents).
2023–2024: 45 incidents. First results. The total count dropped by nearly half. We started filtering requirements more carefully at the input stage.
2024–2025: 21 incidents. Another drop of more than 50%. Critical incidents (SEV-1/2) are now counted in single digits.

It wasn’t always easy. Motivating the team took effort. There were moments when people wanted to abandon the whole thing and return to the old, comfortable chaos. But we persisted, and eventually the new process became a habit.

The three most useful things we learned

Talk about difficulties. As in any relationship, things tend to get resolved when you name them clearly and calmly.
Don’t let problems accumulate. Log them as they arise. Better still, set up a shared space where the whole team can capture issues in real time and keep them until the next retro.
Automate whatever annoys you. If a process can be handed to a bot, hand it to a bot.

Complaining is a powerful tool when it’s used properly, but it’s a starting point. It’s what you do with the complaints that makes the difference.

If you want to go deeper, I recommend Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

Ksyusha Ivannikova is a QA Lead at EXANTE

The Value of Complaining Properly