Root Cause Analysis

Imagine a junior developer who is new to the company and, on the last day of the first Sprint they participated in, finds a meeting on their agenda to discuss the root cause of bugs that occurred. Having never participated in such a meeting before, they felt anxious, thinking it might be something like trying to find someone to blame or pointing fingers at their mistakes, considering that as a newcomer still learning to program, they could become the scapegoat.

When the meeting time arrived, they took a deep breath and entered the room. The Quality Analytics professional greeted everyone and shared their screen displaying graphs and tables with quality metrics. The QA began the meeting by explaining that the objective was to examine the root cause of bugs from a learning perspective and understand why they occurred, questioning the "whys" to learn and prevent similar issues in the near future. The junior developer breathed a sigh of relief and began to understand the importance of this process.

Through analysis of the bugs that were addressed, including which environment they occurred in—whether staging or production—the effort required to implement corrections, and examination of the root cause, opportunities were identified to create action plans for improving unit tests, developing additional test scenarios for better coverage, and gaining insights regarding bug descriptions in cards, application architecture, among other areas.

As the meeting concluded, the QA thanked everyone for their efforts, summarizing the learnings and points of improvement, with plans to analyze in future meetings whether the proposed improvements prevented the recurrence of similar bugs.

Consequently, the junior developer left the meeting satisfied with the results, taking important notes that helped them understand the team's improvement opportunities, process adherence, and ideas to bring to the next Root Cause Analysis meeting.

Within this context, have you conducted or do you currently conduct this type of meeting with your team?

Português:

Imagine um dev júnior novo na empresa e no último dia da primeira Sprint que ele participou encontra em sua agenda uma reunião para discutir sobre a causa raiz dos bugs que ocorreram. Como nunca tinha participado de uma, sentiu uma ansiedade por achar que poderia ser algo do tipo de tentar achar culpado ou apontar o dedo de seus erros, considerando que por ser novato e ainda aprendendo a programar poderia ser o bode expiatório.

Chegou o horário da reunião, ele respirou fundo e entrou na sala. O Quality Analytics cumprimenta a todos e compartilha a tela com alguns gráficos, tabelas com métricas de qualidade. O QA começa a reunião explicando que o objetivo desta é olhar no ponto de vista da causa raiz dos bugs e entender porque este ocorreu, questionar os porquês para aprender e prevenir os mesmos em um futuro próximo. O dev júnior respirou aliviado e começou a entender a importância que esta tem. 

Com análise dos bugs trabalhados, qual ambiente que aconteceu se foi o homologação ou produção, esforço para efetuar a correção, falar sobre a causa raiz, foi vista a oportunidade de criar planos de ação para melhorar alguns testes unitários, criação de cenários de testes a mais para uma melhor cobertura e alguns insights de descrição no card sobre as informações do bug, na arquitetura da aplicação, entre outros.

Com a reunião finalizada, o QA agradece pelo esforço de todos, concluindo com os aprendizados e pontos de evolução, para as próximas reuniões analisarem se com as melhorias propostas se os bugs encontrados não ocorrerão mais.

Nisso, o dev júnior satisfeito com os resultados, saiu da reunião com algumas anotações importantes que entendeu pontos de evolução da equipe, aderência ao processo e com ideias para levar para a próxima reunião de Root Cause Analysis.

Dentro deste contexto, você fez ou faz esta reunião com o seu time?