{"id":485199,"date":"2026-06-26T14:42:18","date_gmt":"2026-06-26T14:42:18","guid":{"rendered":"https:\/\/savepearlharbor.com\/?p=485199"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=485199","title":{"rendered":"The Value of Complaining Properly"},"content":{"rendered":"
\n

How we turned unresolved problems into one of our most valuable efficiency boosts<\/em><\/p>\n

At the end of 2023, just after we\u2019d 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\u2019t 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.<\/p>\n

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\u2019t doing very well at finding solutions.\u00a0<\/p>\n

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\u2019d talk about exactly the same issues. During the course of the sprint, nothing changed.\u00a0<\/p>\n

Scrum defines the purpose of retrospective as \u201cto plan ways to increase quality and effectiveness.\u201d That wasn\u2019t what we got out of them. We just did a lot of complaining.\u00a0<\/p>\n

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\u2019t have a process to resolve any of the complaints, nothing changed.<\/p>\n

We realised that if we were going to spend time complaining, we should at least do it constructively.<\/p>\n

Why our retrospectives weren\u2019t working<\/h3>\n

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.<\/p>\n

    \n
  1. \n

    We had to dig up problems from across the sprint because there was no shared space to capture them as they happened.<\/p>\n<\/li>\n

  2. \n

    Once someone raised an issue, nothing was done about it. There was no plan for resolving the problem.<\/p>\n<\/li>\n<\/ol>\n

    We were using retrospectives as a rage room: a place to vent and then move on, with no follow up or resolution.\u00a0<\/p>\n

    Meanwhile, genuinely suboptimal processes weren\u2019t 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\u2019t share knowledge properly; critical information lived in individuals\u2019 heads rather than in accessible documentation. But because our retrospectives weren\u2019t being run properly, we never dealt with these problems.\u00a0<\/p>\n

    Building a productive way to complain<\/h3>\n

    Once we\u2019d identified why the retrospectives weren\u2019t working, we set about fixing them.\u00a0<\/p>\n

    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.<\/p>\n

    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.\u00a0<\/p>\n

    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.\u00a0<\/p>\n

    Here are four real examples of how complaining with purpose changed things for us.<\/p>\n

    1. A bot for scheduling on-call shifts<\/h4>\n

    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\u2019re part of the job; not the most popular one, perhaps, but essential for a product as complex and critical as ours.\u00a0<\/p>\n

    But we didn\u2019t 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.\u00a0<\/p>\n

    We built a bot. The bot now handles the rota (using a database instead of Excel) and sends notifications to the team channel.<\/p>\n

    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.<\/p>\n

    <\/figure>\n

    2. Balancing the workload<\/h4>\n

    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.<\/p>\n

    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.<\/p>\n

    <\/figure>\n

    3. Fixing the grooming<\/h4>\n

    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.<\/p>\n

    4. A platform for any question (even the small ones)<\/h4>\n

    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.<\/p>\n

    It wasn\u2019t until our retrospectives became a safe space\u2014allowing him to finally vent about how inconvenient this was\u2014that 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.<\/p>\n

    How complaining improved our working life<\/h3>\n

    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.<\/p>\n

    <\/figure>\n

    A note on severity levels: our production incident prioritisation runs from SEV-1 (highest) to SEV-4 (lowest).<\/em><\/p>\n