It’s easy to blame someone that is not present.
We usually see that between departments like product and support, or even between cross-functional teams not interacting much together.
Blame is a defensive mechanism that activates itself when a human feels threatened himself, or his social group, as a way to protect from harm and danger.
While this behavior was quite useful to survive as tribes in the forest, delivering Quality at Speed software requires a strong end-to-end collaboration.
Quality Engineering Retrospective is a methodology to leverage for building high performing organizations based on continuous improvement and healthy confrontation.
Follow the QE Unit for more Quality Engineering from the community.
What is Quality Engineering Retrospective
A retrospective is a method to step back from previous activities for collaboratively identifying actionable improvements.
The process can be executed regularly, after each delivery iteration, but also after specific events like a critical incident or major project launch.
Retrospectives are efficient when the issues are clearly identified, root causes drilled-down, and structuring action plans defined.
Easy to say, hard to do for a team.
It’s not easy for people to admit mistakes, failures; these types of behavior are associated with termination, shame and a sentiment of failure.
That’s why teams need psychological safety to transparently share what went wrong, if they miss something, to define the correct plans and improve as an organization.
Quality Engineering Retrospective is a specific types of retrospective with specific attributes to improve collaboration and the type of solution found:
- Start with a silent retrospective to help more introverts profiles
- Materializes facts in a single way, avoiding centering on people
- Confront issues to build up trust to share problems between people
- Have transversal stakeholders presence and buy-in
- Focus on an improvement action plan with the big picture.
Here’s an example of the output of a retrospective:
Action items must be set into tasks management to ensure their follow-up, and the good practice is also to review on a monthly basis retrospective action plans,
A good dose of humility at a personal and organizational culture level is required to perform efficient retrospectives, but is what makes the difference in the long run.
It’s about maintaining a continuous flow of Quality at Speed software.
Why using Quality Engineering Retrospective in Quality Engineering?
Failures of technological systems cannot be completely avoided. They can be reduced and quickly recovered with practices like Site Reliability Engineering (SRE).
Additionally, the acceleration of software delivery is a requirement for companies with the pressure of the digital transformation, but also increases the risk of disruption.
In this ecosystem of increasing cycles of changes, the capability of an organization to continuously improve is necessary for survival to deliver Quality at Speed.
How does Quality Engineering Retrospective contribute to Quality?
It is frustrating to make the same mistake twice, even more when it directly impacts your company’s value proposition.
Performing retrospective enables to identify structuring issues in the entire lifecycle that can prevent the issues encountered, but also future ones to happen with the same causes.
The formalization of the timeline, issues and action plans is also helpful to spread good practices and learnings among the organization.
Quality Engineering Retrospective contributes to Quality being:
- Result-driven with a timeline and focus on building an improvement plan
- Systematic applied to multiple cases like iteration, incident or launch
- Scalable to many teams and context, also sharing outputs among teams.
How does Quality Engineering Retrospective contribute to Speed?
Organizations with velocity have the common trait of being lean, with a strong focus, low rework, and no extra weight, iterating with more speed than the competition.
The continuous implementation of retrospective action plan increases speed by removing costly reworks, slowly recovered incidents, and inefficient processes.
Retrospectives are an effective way to reduce the existing complexity but also to contain the one that naturally accumulates over time and with more software changes.
Quality Engineering Retrospective contributes to Speed with:
- Focus on identifying issues and associated improvement plans
- Rhythm being performed at defined frequency or after specific events
- Asynchronicity allowing to contribute and share with multiple actors
- Visibility sharing the summary and action plans in the organization.
How to start with Quality Engineering Retrospective in QE?
The implementation of retrospective must be gradual to accommodate the organizational culture jointly with the improvements of the methodology.
Keep in mind the following principles for QE Retrospectives:
- Get executive buy-in
- Propose, then validate plans
- Force divergent points at first
- Focus on the improvement action plan
- Perform retrospective when it’s still fresh
- Everybody has a say, everybody has a voice.
The following process can be used for performing a QE retrospective:
- Identify teams to start with
- Align the team with the methodology
- Nominate a facilitator
- Schedule and prepare the retrospective
- Animate the workshop with focus
- Consolidate outputs in action plan
- Share and communicate results
This process can be extended to multiple teams over time, starting with the one with more stakes and openness to such a process.
The step 5 of workshop animation is most important to detail here, being the pivotal moment where issues are identified and improvements plans generated.
The preparation would have gathered as much detail about the subject as possible: timeline, triggering events, customer impacts, facts, logs, communication, metrics.
The workshop can then be animated in the following way:
- The facilitator shares customer impacts, timeline, and facts
- Participants have 10 minutes to enrich, comment or react
- A silent retrospective lasts 5 minutes to collect root causes inputs
- Each participant vote for 3 root causes
- The facilitator animates a “5 Why” session on root causes
- A silent retrospective lasts 10 minutes to collect improvements
- Each participant vote for 3 most important improvements
- The facilitator summarizes the improvements action plan
- The facilitator send the meeting notes and create action items
- The facilitator communicates the retrospective in the organization.
Here are questions you can use during the process to initiate discussions:
- How did we know about the problem?
- Could we have discovered the problem sooner?
- Was the right team contacted?
- Did we have sufficient information to resolve the incident?
- What are the limiting factors, due to manual process or other?
- Were there gaps between planned and performed actions?
Using the silent part only for preparation and confronting the issues with the participants is what enables to drive continuous improvement of the organization.
Quality Engineering Retrospective within MAMOS
Learning is growing, and organizations in search of continuous reinvention through software must master learning to thrive with Quality at Speed software.
Being good at one point in time is not sufficient; companies need to improve their value proposition with a continuous flow of valuable software changes.
Quality Engineering Retrospective is a methodology part of the Quality Engineering Framework, MAMOS, increasing Quality and Speed through improvements.
“Let the improvement of yourself keep you so busy that you have no time to criticize others.”
― Roy T. Bennett, The Light in the Heart
That’s Quality Engineering.
References
Christina Guida (2018), How and Why to Hold “Blameless Retrospectives”, New Relic.
Noor-ul-Anam Ruqayya, What Are Blameless Postmortems? (Do They Work? How?). Blameless.
Incident Management at Atlassian, Blameless Postmortem. Atlassian.
J. Paul Reed, “Blameless” postmortems don’t work. Here’s what does. Techbeacon.
Gareth Davies, 21 Ideas To Get Quiet Teams Talking In Sprint Retrospectives. The Digital Project Manager.