Quality Storming is a workshop format for analyzing and improving how software gets built. People from every role stick events on a wall together, find the danger points in the process and agree on concrete measures. The method combines event storming with HACCP, a food safety system developed for NASA that systematically identifies the critical control points in a production process.
Key Takeaways
- Quality Storming applies HACCP, a principle from food safety, to software through event storming, so teams can examine their whole development process for weak points across teams and roles.
- A strip of masking tape stretched across the room, from where a bug entered the product to where the customer found it, makes a quality problem physically tangible and has more impact than any slide.
- Managers and the people who report to them should not attend a Quality Storming workshop together, because the HiPPO effect stops anyone from naming the real problems in the process.
- The goal of Quality Storming is not to find bugs but to uncover the conditions in the process that let bugs arise, because preventing a bug is cheaper than detecting it.
- To keep improvements from fizzling out after the workshop, volunteers set measurable three-month goals on the spot and agree on the next concrete step.
Quality Storming: Food Safety Meets Software Development
Teams use Quality Storming to take apart their own software development process. The thinking behind it is simple: a good process makes a good product. Instead of testing more and more at the end, Quality Storming looks at where bugs come from in the first place and how to catch them earlier.
The format was created by Georg Haupt, a trained chef who later moved into IT as a test and quality manager. He brought together two worlds that seem to have nothing in common: food processing and agile software development with its sticky notes on the wall.
Where the Method Comes From: HACCP and the Space Program
It all started with NASA’s Mercury and Apollo programs. On a short flight into space, an astronaut didn’t need to eat. Once missions lasted several days, though, astronauts had to be fed without getting sick from spoiled or contaminated food.
NASA’s engineers knew nothing about food processing. So they brought in experts from the food industry and developed a procedure to make sure the food was free of contamination. The result was Hazard Analysis and Critical Control Points, or HACCP.
The World Health Organization later adopted HACCP. Since 2006, every food business in the EU has been required to work according to it. Chefs learn it from day one of their training.
The core of HACCP is to control the entire production process, from the milk in the cow to the cream on the cake, and to pinpoint every place where the product could become contaminated. The familiar cold chain grew out of this way of thinking. At each hazard point you ask: what can we do to make sure nothing goes wrong here?
Hollandaise sauce shows the principle. It contains raw egg, and raw egg is risky. So the kitchen works with defined temperatures and makes sure the sauce isn’t kept warm longer than allowed. Skip that control, and your guests may end up with salmonella.
From Event Storming to Quality Storming
In IT, Georg came across event storming, a technique from domain-driven design. You stick notes on the wall and describe the workflows of a future piece of software as events: what has to happen before, what happens after, what the user needs. The result is the design of the software.
Georg instinctively carried the idea over to quality work. He took the event storming principle, loosened its strict rules and used it to analyze how software gets built, across teams and roles. That is how Quality Storming came about, although at first he didn’t realize he had invented a format of his own.
The difference comes down to what ends up on the wall. Event storming models how the product should behave. Quality Storming maps how the team actually builds it.
How a Quality Storming Workshop Works
The workshop happens in an empty room. No chairs, at most a table for the materials, otherwise just bare walls. Everyone works standing up.
The facilitator writes a start event on a large sticky note and puts it on one wall, something like “The idea for a piece of software is born.” The end event goes on the opposite wall, for example “The customer uses the new feature.” The whole process takes shape in between.
Participants then place events in chronological order between start and end. Requirements get gathered, reviews happen, code gets written, test cases get designed, automation gets built. Everyone adds their own view, because the room is full of different roles: testers, developers, business analysts, support staff, Scrum roles. Anyone who has something to say about the process.
Just putting the events in order is a real hurdle for many teams. Do we derive test cases before or after we define the acceptance criteria? Does review A come before pair programming session B? That argument is exactly what the format wants, because it forces people to talk. My neighbor needs something from me, I need something from someone else, and often neither of us knows it.
A workshop like this usually takes about four hours, or a whole morning for bigger topics. By the end, the real development process is on the wall. That means the process as people actually live it, not the one written down somewhere. The two almost never match.
“What should go up there is the actual process, the way people live it. And that’s rarely the way it’s written down anywhere. But that’s the whole point.”
(Georg Haupt)
Three Ways to Work with the Process
Once the process is on the wall, there are several ways to use it. It is never about pointing fingers. It is always about the process.
Option one: make the bug tangible. Take a sample bug from the last iteration and mark, in big letters, where it was found, usually at the customer. Then run a strip of masking tape across the room at head height, back to the point where the bug entered the product. The tape stays in everyone’s way for the entire workshop. Whoever moves around has to duck under it. The group’s task: how do we make this tape shorter? What did we do between the moment the bug was introduced and the moment it was found, and why didn’t any of it catch the bug?
The physical experience sticks. By evening, you feel that bug in your back. If someone accidentally tears the tape down, there’s a fun penalty, such as buying a crate of beer. In the kitchen, Georg says, there are no second chances at these points: a guest who got salmonella won’t come back.
Option two: find the root cause. Here you mark where a bug was introduced and analyze everything that happened before it. What made it easy for the bug to slip in? Common causes are too much information at once, high complexity, three tasks at the same time, constant interruptions from someone opening the door. Root cause analysis is now part of the ISTQB Foundation Level as well. The Pareto principle helps: 20 percent of the causes account for 80 percent of the bugs.
Option three: targeted process improvement. While the group is still building the timeline, the facilitator watches for friction. Where do people argue? Where is something missing? Each of these spots gets a lightning bolt on a large sticky note. By the end, there are often five or six lightning bolts along the process.
Turning Lightning Bolts into Concrete Measures
Each lightning bolt gets a flipchart underneath it, and the group works there. First they define the preconditions for the events around the bolt: which information and which tools are needed before an event is really complete? Then they name the actors, people as well as machines, who are involved or should be.
Next, volunteers step forward to keep working on a lightning bolt. They define a 50 percent solution with goals for the next three months and a first step. At the end, the flipchart shows the goals, the names of the people responsible and a date for the first measurement.
The selection takes care of itself. Lightning bolts nobody volunteers for are left alone. The ones that attract volunteers have the energy they need. They turn into follow-up workshops, led by the people who stepped forward.
Choosing the Scope: Put the Pain in the Middle
A Quality Storming session starts with a specific pain, not with an appetite for analysis. Put that pain point in the middle of the process you look at, not at the beginning and not at the end.
Set the boundaries of the timeline around the pain. If requirements arrive finished and you don’t need to look at the requirements phase, start with “The requirement is written” instead of “The idea is born.” What matters is leaving room for what comes before and after.
Keep the scope on the small side, and agree on the focus with a few of the people involved beforehand. Nothing is set in stone, though. If the group suddenly throws itself at a different area, say, how customers report bugs after release, then that is obviously the real pain point.
For a first session, a playful practice process that has nothing to do with the company works well. Planning a wedding, a divorce or, for a group of Star Wars fans, the conquest of the Death Star. The humor lowers the barrier, and the method sinks in faster.
Why Managers and Employees Should Be Kept Separate
Quality Storming works with managers and it works with employees, but only when the two groups are kept apart. Mix them, and you get the HiPPO effect right away, the Highest Paid Person’s Opinion: the boss says “That’s how we do it,” everyone nods, even though things really work differently. The workshop is then worthless, because the actual process on the wall is wrong.
The exception is managers who hold back so much that nobody sees them as the boss anymore. Few can do that. Where it works, it’s not a problem.
Quality Is Built Before Anyone Tests
The real value of the format is the change of perspective. Many teams focus heavily on testing. The smarter move is to do things that keep bugs from arising at all. Quality Storming makes the weak spots in the process visible, to the eye and to the body, and it often exposes problems nobody had ever noticed.
The moments of insight about communication matter just as much. When testers and developers understand for the first time what the business analysts actually do, the analysts become people with faces you can go to. Those connections outlast the workshop. Weeks later, teams are still talking to each other about subject matter that has long since stopped having anything to do with Quality Storming.
For that to happen, two things are needed: good facilitation and real collaboration. Where people won’t talk openly about their processes, or where there are political rifts, even the best format won’t help. Where people do engage, they take a critical look at their own processes, and very few do that voluntarily.
What IT Can Learn from the Kitchen: Preparation and Connection
Two lessons from the kitchen carry straight over into software work. The first: 80 percent of the work is preparation. In the kitchen, that is called mise en place, everything in its place. Test automation is about 80 percent preparation too, and only 20 percent is actually writing the scripts. The script is almost a by-product of good preparation.
The second lesson is about connection. A chef can run the salad station well without looking left or right. That doesn’t work in IT. Testers need to understand what others do: something about architecture, something about coding, something about how the product is used. These connections cross hierarchies and departments, and often company boundaries too. Without them, you can’t do the job properly.
Frequently Asked Questions
Why isn’t it enough to simply test more at the end of development?
Testing finds bugs; it doesn’t prevent them. Many teams still focus on testing, even though prevention is cheaper than detection. If you look at the manufacturing process instead, you can see the conditions under which defects arise in the first place. Such an analysis regularly reveals weak points that no one had noticed before and, as a side benefit, fosters collaboration across functional boundaries.
What can be applied from the food industry’s HACCP principle to other manufacturing processes?
HACCP examines a product’s entire journey (from milk straight from the cow to the whipped cream on the cake) and identifies every point where it could become contaminated. At each of these points, the question is: What are we doing to ensure nothing goes wrong here? The cold chain stems from this way of thinking. Applied to software, this means: identifying hazard points in the process rather than counting errors in the finished product.
How does Quality Storming differ from Event Storming in Domain-Driven Design?
Event Storming is used to define the workflows of a future software application through events, which ultimately result in its design. Quality Storming adopts the principle of sticky notes on the wall, relaxes the strict rules, and focuses on the software development process. The focus is therefore on analyzing how the team works, not on how the product is supposed to function later on.
Who should participate in a workshop to analyze the development process?
Anyone who has something to say about the process: testers, developers, business analysts, support staff, and the Scrum roles. The workshop is conducted standing up, in an empty room without chairs, typically lasting about four hours, or a full morning for larger topics. The mix of participants is the real key, because often no one knows what their neighbor in the process needs from them.
How can you visualize the path a bug takes through the development process?
With a piece of masking tape stretched across the room at head height. It connects the point where a bug was found (usually at the customer’s site) with the point where it entered the product. The tape hangs in the way throughout the entire workshop; everyone has to walk under it. The group’s guiding question is: How can we make this tape shorter?
How do you prevent improvement ideas from a workshop from fizzling out afterward?
Commitment is established right there in the room. For each identified weak point, volunteers step forward, define a 50-percent solution with goals for the next three months and a first concrete step. By the end, the flip chart lists the goals, the names of those responsible, and a date for the first measurement. Topics without volunteers are left unaddressed; they lack momentum.
Should managers and their employees participate in such a workshop together?
Better not. If both are in the same room, the HiPPO effect kicks in, the Highest Paid Person’s Opinion: if the boss says things work this way or that way, everyone nods in agreement, even though the reality is different. This distorts the actual process and renders the workshop worthless. The exception is managers who step back so far that they are no longer perceived as superiors.
How do you introduce a team to this kind of format when they’ve never experienced it before?
Through a playful practice exercise that has nothing to do with the company: planning a wedding, a divorce, or (in a Star Wars-loving group) the conquest of the Death Star. Humor lowers the barrier to entry, and the method is mastered more quickly. Afterward, it’s time to tackle the real process, whose pain point should lie at the center of the section under consideration.
