Quality Storming

Quality Storming is a workshop format for analyzing and improving software development processes. Participants from all roles stick events on a wall together, uncover danger points and derive concrete measures. The method combines event storming with HACCP, a NASA food safety concept that seamlessly identifies critical control points in the manufacturing process.

Key Takeaways

• Quality Storming combines the HACCP principle of food technology with Event Storming to analyze the entire software development process for weak points across teams and roles.
• A strip of masking tape that traces the path of an error through the room from its origin to its discovery by the customer makes quality problems physically tangible and has a greater impact than any film.
• Managers and their employees should not attend quality storming workshops together, because the hippo effect means that nobody names the real process problems.
• The aim of quality storming is not to find errors, but to uncover conditions in the process that cause errors to occur in the first place, because prevention is cheaper than detection.
• To ensure that improvement measures do not fizzle out after the workshop, volunteers define measurable goals for three months directly on site and determine the next concrete steps.

Quality Storming combines food safety with software development

Quality Storming is a workshop format that teams use to analyze their own software development process. The basic idea behind it is simple: a good process makes a good product. Instead of testing more and more at the end, the method looks at where errors occur in the first place and how to catch them earlier.

The format was developed by Georg Haupt, who trained as a chef and later worked in IT as a test and quality manager. He has brought together two worlds that at first glance seem to have nothing to do with each other: food processing and Agile software development with its notes on the wall.

Where the method comes from: HACCP from space travel

The origins lie in NASA’s Mercury and Apollo programs. For the short flight into space, astronauts did not need to eat anything. However, as soon as the missions lasted several days, the astronauts had to be fed without getting sick from spoiled or contaminated food.

NASA engineers had no idea about food processing. So they brought in experts from the food industry and developed a process to ensure that the food was free of contamination. This resulted in Hazard Analysis Critical Control Points, or HACCP for short.

HACCP was later adopted by the World Health Organization. Since 2006, working according to HACCP has been mandatory for food processing companies in all EU countries. Chefs learn it from scratch.

The core of HACCP is that the entire production process, from the milk from the cow to the cream on the cake, is checked and the points at which the product could be contaminated are identified. The well-known cold chain comes from this way of thinking. The question is asked at every danger point: What can we do to ensure that nothing happens here?

An example from the kitchen illustrates the principle. A hollandaise sauce contains raw egg, and raw egg is delicate. So you work with defined temperatures and make sure that the egg is not kept warm for longer than permitted. If you don’t check this, you run the risk of guests getting salmonella.

From event storming to quality storming

In IT, Georg learned about event storming, a format from domain-driven design. It involves sticking notes on the wall and defining the action sequences of future software via events: what needs to happen beforehand, what needs to happen afterwards, what the user needs. The end result is the design of the software.

Georg instinctively transferred this idea to quality work. He took the principle of event storming, relaxed the strict rules and used it to analyze the software production process across teams and roles. This is how Quality Storming came about, without him initially realizing that he had invented his own format.

How a quality storming workshop works

The workshop takes place in an empty room. No chairs, at most a table for the material, otherwise just empty walls. Work is done standing up.

The moderator writes a start event on a large post-it and hangs it on a wall, for example “The idea for a software is born”. The end event is placed on the opposite wall, for example “The new feature is used by the customer”. The entire process is created in between.

The participants now stick events in chronological order between the start and end. Requirements are collected, reviews are carried out, code is written, test cases are designed, automations are built. Everyone contributes their point of view, as there are people from different roles in the room: Testers, developers, business analysts, support staff, scrum roles. Everyone who has something to say about the process.

Even sorting things out is a real hurdle for many teams. Does the test case survey take place before or after the definition of acceptance criteria? Does review A come before pair coding B? This discussion is exactly what is wanted, because it forces those involved to talk. My neighbor needs something from me, I need something from someone else, and often neither knows about the other.

A workshop like this usually lasts around four hours, or even a whole morning for larger topics. At the end, the real production process hangs on the wall. Important: It is about the actual process as it is lived, not the one that is documented somewhere. The two almost always differ.

The actual process as it is lived should be attached to it. And this is rarely the way it is written down somewhere. But that’s the point.

• Georg Haupt

Three ways of working with the process

If the process is on the wall, there are several ways to use it. It’s never about fingerpointing, but always about the process itself.

**Variant one: make the error noticeable ** Take an example error from the last iteration and mark the place where it was found in large letters, usually at the customer’s premises. Then stick masking tape across the room, at head height, up to the point where the error was found in the product. This tape hangs in the way throughout the workshop. Anyone who moves has to get under it. The group’s task: How can we shorten this ribbon? What did we do between creation and discovery that prevented the error from being discovered?

This physical experience works. You feel the mistake in the small of your back in the evening. If someone accidentally tears the tape, there’s a funny punishment, like a crate of beer. In the kitchen, says Georg, there are no second chances in these places: a guest with salmonella won’t come back.

**Variant two: look for the root cause Here you mark where a mistake occurred and analyze everything that happened before it. What caused the error to occur? Common causes are too much information at once, high complexity, three tasks at the same time, constant interruptions due to the door opening. This root cause analysis is now also anchored in the ISTQB Foundation Level. The Pareto principle helps here: 20 percent of the causes are responsible for 80 percent of the errors.

**Variant three: Targeted process improvement ** Even while the group is recording the stream, the moderator looks for discrepancies. Where is there discussion? Where is something missing? Such points are marked with a lightning bolt on a large post-it. In the end, there are often five or six flashes in the process.

Lightning bolts become concrete measures

A flipchart on which the group works is placed under each flash. They define the preconditions for the events surrounding the flash: What information, what tools are necessary for an event to be truly complete? Then they name the players, people and machines, who are or should be involved.

Then volunteers come forward who want to continue working on a Blitz. They define a 50 percent solution with goals for the next three months and a first step. At the end, the flipchart lists the goals, the names of those responsible and a date for the first measurement.

The selection takes care of itself. Flashes for which no one comes forward are left behind. Flashes for which volunteers are found have the necessary momentum. They become follow-up workshops, led by the people who have registered.

Choosing the right section: the pain belongs in the middle

A quality storming does not start out of a desire to analyze, but out of a specific pain. It is precisely this pain point that you should place in the middle of the process under consideration, not at the beginning and not at the end.

You set the boundaries of the stream around the pain. When the requirements are finished and you don’t need to illuminate the requirements phase, you start with “The requirement is written” instead of “The idea is born”. The important thing is that you leave room for what comes before and after.

Don’t make the section too large. Discuss the focus with some of those involved beforehand. At the same time, nothing is set in stone. If the group suddenly jumps to another area, such as how the customer reports errors afterwards, then that is obviously the real pain point.

To get started, we recommend a playful exercise that has nothing to do with the company. Planning a wedding, a divorce or, in a group with an affinity for Star Wars, conquering the Death Star. The humor lowers the hurdle and the method sits faster.

It’s better not to mix management and employees

Quality Storming works with managers and employees, but only if they are kept separate. A mixture immediately creates the HiPPO effect, the Highest Paid Person’s Opinion: if the boss says, “That’s the way we do it”, everyone nods, even though in reality it works differently. This makes the whole workshop worthless because the actual process is falsified.

The exception is managers who take themselves so far back that they are no longer perceived as superiors. Few can do that. Where they succeed, it is not a problem.

Quality is created before testing takes place

The real value of the format lies in the change of perspective. Many teams focus heavily on testing. It is smarter to do things so that errors do not occur in the first place. Quality Storming makes the weak points in the process visible, visually and physically, and often exposes problems that no one has ever noticed.

Just as important are the “aha” moments in communication. When testers and developers understand for the first time what the business analysts are actually doing, a contact person with a face is created. Such connections last beyond the workshop. Weeks later, teams are still talking to each other about technical topics that have long since ceased to have anything to do with quality storming.

Two things are needed for this to succeed: good moderation and genuine collaboration. Where people do not talk openly about their processes or there are political divides, the best format is useless. Where they do get involved, they critically scrutinize their own processes, and very few do this voluntarily.

What the kitchen has over IT: Preparation and networking

Two lessons from the kitchen apply directly to software work. The first: 80 percent of the work is preparation. In the kitchen, this is called mise en place. In test automation, too, around 80 percent is preparation, and only 20 percent is actually creating the scripts. The script is almost a waste product of good preparation.

The second lesson is networking. A chef can make a good salad without looking left and right. This is not possible in IT. Testers need to understand what others are doing: something about architecture, something about coding, something about how the product is used. This networking extends beyond hierarchical and departmental boundaries, often even beyond the company. Without it, the work cannot be done properly.