Quality Storming ist ein Workshop-Format zur Analyse und Verbesserung von Software-Entwicklungsprozessen. Teilnehmer aus allen Rollen kleben gemeinsam Events an eine Wand, decken Gefahrenpunkte auf und leiten konkrete Maßnahmen ab. Die Methode verbindet Event Storming mit HACCP, einem Lebensmittelsicherheitskonzept der NASA, das lückenlos kritische Kontrollpunkte im Herstellungsprozess identifiziert.
Das Wichtigste in Kürze
- Quality Storming verbindet das lebensmitteltechnische HACCP-Prinzip mit Event Storming, um den gesamten Softwareentwicklungsprozess team- und rollenübergreifend auf Schwachstellen zu analysieren.
- Ein Kreppband-Strang, der den Weg eines Fehlers vom Entstehungsort bis zur Entdeckung beim Kunden durch den Raum zieht, macht Qualitätsprobleme körperlich spürbar und erzeugt mehr Wirkung als jede Folie.
- Führungskräfte und ihre Mitarbeitenden sollten Quality-Storming-Workshops nicht gemeinsam besuchen, weil der Hippo-Effekt dazu führt, dass niemand die echten Prozessprobleme benennt.
- Das Ziel von Quality Storming ist nicht, Fehler zu finden, sondern Bedingungen im Prozess aufzudecken, die Fehler überhaupt erst entstehen lassen, weil Vermeiden billiger ist als Entdecken.
- Damit Verbesserungsmaßnahmen nach dem Workshop nicht verpuffen, definieren Freiwillige direkt vor Ort messbare Ziele für drei Monate und legen die nächsten konkreten Schritte fest.
Quality Storming verbindet Lebensmittelsicherheit mit Softwareentwicklung
Quality Storming ist ein Workshop-Format, mit dem Teams ihren eigenen Softwareentwicklungsprozess analysieren. Der Grundgedanke dahinter ist einfach: Ein guter Prozess macht ein gutes Produkt. Statt am Ende immer mehr zu testen, schaut die Methode darauf, wo Fehler überhaupt entstehen und wie man sie früher abfängt.
Entwickelt hat das Format Georg Haupt, gelernter Koch und später in der IT als Test- und Quality-Manager unterwegs. Er hat zwei Welten zusammengebracht, die auf den ersten Blick nichts miteinander zu tun haben: die Lebensmittelverarbeitung und die agile Softwareentwicklung mit ihren Zetteln an der Wand.
Woher die Methode kommt: HACCP aus der Raumfahrt
Der Ursprung liegt im Mercury- und Apollo-Programm der NASA. Für den kurzen Flug ins All brauchte ein Astronaut noch nichts zu essen. Sobald die Missionen aber mehrere Tage dauerten, mussten die Astronauten verpflegt werden, ohne durch verdorbene oder kontaminierte Lebensmittel krank zu werden.
Die NASA-Ingenieure hatten von Lebensmittelverarbeitung keine Ahnung. Also holte man Fachleute aus der Lebensmittelindustrie und entwickelte ein Verfahren, das sicherstellen sollte, dass die Nahrung kontaminierungsfrei ist. Daraus entstand Hazard Analysis Critical Control Points, kurz HACCP.
HACCP wurde später von der Weltgesundheitsorganisation übernommen. Seit 2006 ist das Arbeiten nach HACCP in allen EU-Staaten für lebensmittelverarbeitende Betriebe verpflichtend. Köche lernen es von der Pike auf.
Der Kern von HACCP: Man kontrolliert den gesamten Herstellungsprozess, von der Milch aus der Kuh bis zur Sahne auf der Torte, und identifiziert die Stellen, an denen das Produkt kontaminiert werden könnte. Die bekannte Kühlkette stammt aus diesem Denken. An jedem Gefahrenpunkt fragt man: Was können wir tun, damit hier nichts passiert?
Ein Beispiel aus der Küche zeigt das Prinzip. Eine Sauce Hollandaise enthält rohes Ei, und rohes Ei ist heikel. Also arbeitet man mit definierten Temperaturen und stellt sicher, dass das Ei nicht länger als erlaubt warmgehalten wird. Wer das nicht kontrolliert, riskiert, dass Gäste Salmonellen bekommen.
Vom Event Storming zum Quality Storming
In der IT lernte Georg das Event Storming kennen, ein Format aus dem Domain Driven Design. Dort klebt man Zettel an die Wand und definiert die Handlungsabläufe einer künftigen Software über Events: Was muss vorher passieren, was nachher, was braucht der User. Am Ende entsteht daraus das Design der Software.
Georg übertrug diese Idee instinktiv auf die Qualitätsarbeit. Er nahm das Prinzip des Event Storming, lockerte die strengen Regeln und nutzte es, um den Herstellungsprozess der Software team- und rollenübergreifend zu analysieren. So entstand Quality Storming, ohne dass ihm zunächst klar war, dass er ein eigenes Format erfunden hatte.
Wie ein Quality-Storming-Workshop abläuft
Der Workshop findet in einem leeren Raum statt. Keine Stühle, höchstens ein Tisch für das Material, ansonsten nur freie Wände. Gearbeitet wird im Stehen.
Die Moderation schreibt ein Start-Event auf ein großes Post-it und hängt es an eine Wand, etwa “Die Idee für eine Software ist geboren”. An die gegenüberliegende Wand kommt das End-Event, zum Beispiel “Das neue Feature wird vom Kunden genutzt”. Dazwischen entsteht der gesamte Prozess.
Die Teilnehmenden kleben nun Events in chronologischer Reihenfolge zwischen Start und Ende. Requirements werden erhoben, Reviews durchgeführt, Code geschrieben, Testfälle designt, Automatisierungen gebaut. Jeder bringt seine Sicht ein, denn im Raum stehen Menschen aus verschiedenen Rollen: Tester, Entwickler, Business-Analysten, Support-Mitarbeiter, Scrum-Rollen. Alle, die etwas zum Prozess sagen können.
Schon das Sortieren ist für viele Teams eine echte Hürde. Findet die Testfallerhebung vor oder nach der Definition der Akzeptanzkriterien statt? Kommt Review A vor Pair Coding B? Genau diese Diskussion ist gewollt, denn sie zwingt die Beteiligten zum Reden. Mein Nachbar braucht etwas von mir, ich brauche etwas von jemand anderem, und oft weiß keiner vom anderen.
Ein solcher Workshop dauert in der Regel etwa vier Stunden, bei größeren Themen auch einen ganzen Vormittag. Am Ende hängt der reale Herstellungsprozess an der Wand. Wichtig: Es geht um den Ist-Prozess, wie er gelebt wird, nicht um den, der irgendwo dokumentiert steht. Die beiden weichen fast immer voneinander ab.
Es soll der Ist-Prozess, wie er gelebt wird, da dranhängen. Und der ist selten so, wie er irgendwo festgeschrieben ist. Aber darum geht es ja. — Georg Haupt
Drei Varianten, mit dem Prozess zu arbeiten
Steht der Prozess an der Wand, gibt es mehrere Wege, ihn zu nutzen. Es geht nie um Fingerpointing, sondern immer um den Prozess selbst.
Variante eins: den Fehler spürbar machen. Man nimmt einen Beispielfehler aus der letzten Iteration und markiert groß die Stelle, an der er gefunden wurde, meist beim Kunden. Dann klebt man ein Kreppband quer durch den Raum, auf Kopfhöhe, bis zu der Stelle, an der der Fehler ins Produkt gekommen ist. Dieses Band hängt den ganzen Workshop über im Weg. Wer sich bewegt, muss darunter durchsteigen. Die Aufgabe der Gruppe: Wie kriegen wir dieses Band kürzer? Was haben wir zwischen Entstehung und Fund getan, das den Fehler nicht entdeckt hat?
Diese körperliche Erfahrung wirkt. Du spürst den Fehler abends im Kreuz. Reißt jemand das Band versehentlich herunter, gibt es eine spaßige Strafe, etwa einen Kasten Bier. In der Küche, sagt Georg, gibt es an diesen Stellen keine zweite Chance: Ein Gast mit Salmonellen kommt nicht wieder.
Variante zwei: die Grundursache suchen. Hier markiert man, wo ein Fehler entstanden ist, und analysiert alles, was davor passierte. Was hat den Fehler im Entstehen begünstigt? Häufige Ursachen sind zu viele Informationen auf einmal, hohe Komplexität, drei Aufgaben gleichzeitig, ständige Unterbrechungen durch die Tür, die aufgeht. Diese Grundursachenforschung ist mittlerweile auch im ISTQB Foundation Level verankert. Hier hilft das Pareto-Prinzip: 20 Prozent der Ursachen sind für 80 Prozent der Fehler verantwortlich.
Variante drei: gezielte Prozessverbesserung. Schon während die Gruppe den Stream klebt, achtet die Moderation auf Unstimmigkeiten. Wo wird diskutiert? Wo fehlt etwas? Solche Stellen markiert man mit einem Blitz auf einem großen Post-it. Am Ende hängen oft fünf oder sechs Blitze im Prozess.
Aus Blitzen werden konkrete Maßnahmen
Unter jeden Blitz kommt ein Flipchart, auf dem die Gruppe arbeitet. Sie definiert für die Events rund um den Blitz die Vorbedingungen: Welche Informationen, welche Tools sind nötig, damit ein Event wirklich abgeschlossen ist? Danach benennt sie die Akteure, Menschen wie Maschinen, die beteiligt sind oder beteiligt sein sollten.
Dann melden sich Freiwillige, die an einem Blitz weiterarbeiten wollen. Sie definieren eine 50-Prozent-Lösung mit Zielen für die nächsten drei Monate und einen ersten Schritt. Auf dem Flipchart stehen am Ende die Ziele, die Namen der Verantwortlichen und ein Datum für die erste Messung.
Die Auswahl regelt sich von selbst. Blitze, für die sich niemand meldet, bleiben liegen. Blitze, für die sich Freiwillige finden, haben den nötigen Elan. Aus ihnen werden Folge-Workshops, geleitet von den Menschen, die sich gemeldet haben.
Den richtigen Ausschnitt wählen: der Schmerz gehört in die Mitte
Ein Quality Storming startet nicht aus Lust am Analysieren, sondern aus einem konkreten Schmerz. Genau diesen Schmerzpunkt solltest du in die Mitte des betrachteten Prozesses legen, nicht an den Anfang und nicht ans Ende.
Die Grenzen des Streams setzt du um den Schmerz herum. Wenn die Requirements fertig kommen und du die Anforderungsphase nicht beleuchten musst, startest du eben mit “Das Requirement ist geschrieben” statt mit “Die Idee ist geboren”. Wichtig ist, dass du Luft lässt für das, was davor und danach liegt.
Mach den Ausschnitt lieber nicht zu groß. Sprich den Fokus vorher mit einigen Beteiligten ab. Gleichzeitig ist nichts in Stein gemeißelt. Wenn sich die Gruppe plötzlich auf einen anderen Bereich stürzt, etwa darauf, wie der Kunde danach Fehler meldet, dann ist das offenbar der eigentliche Schmerzpunkt.
Für den Einstieg empfiehlt sich ein spielerischer Übungsprozess, der nichts mit der Firma zu tun hat. Die Planung einer Hochzeit, einer Scheidung oder, in einer Star-Wars-affinen Gruppe, die Eroberung des Todessterns. Der Humor senkt die Hürde, und die Methode sitzt schneller.
Management und Mitarbeiter besser nicht mischen
Quality Storming funktioniert mit Führungskräften und mit Mitarbeitern, aber nur sauber getrennt. Eine Mischung erzeugt sofort den HiPPO-Effekt, die Highest Paid Person’s Opinion: Wenn der Chef sagt, “Das machen wir doch so”, nicken alle, obwohl es in Wahrheit anders läuft. Damit ist der ganze Workshop wertlos, weil der Ist-Prozess verfälscht wird.
Die Ausnahme sind Führungskräfte, die sich so weit zurücknehmen, dass sie nicht mehr als Vorgesetzte wahrgenommen werden. Das können wenige. Wo es gelingt, ist es kein Problem.
Qualität entsteht, bevor getestet wird
Der eigentliche Wert des Formats liegt im Perspektivwechsel. Viele Teams fokussieren stark auf das Testen. Klüger ist es, Dinge zu tun, damit Fehler gar nicht erst entstehen. Quality Storming macht die schwachen Stellen im Prozess sichtbar, optisch und körperlich, und legt damit oft Probleme offen, die nie jemandem aufgefallen sind.
Genauso wichtig sind die Aha-Momente in der Kommunikation. Wenn Tester und Entwickler zum ersten Mal verstehen, was die Business-Analysten eigentlich tun, entsteht ein Ansprechpartner mit Gesicht. Solche Verbindungen halten über den Workshop hinaus. Teams reden Wochen später noch miteinander, über fachliche Themen, die mit dem Quality Storming längst nichts mehr zu tun haben.
Damit das gelingt, braucht es zwei Dinge: gute Moderation und echte Kollaboration. Wo Menschen nicht offen über ihre Prozesse reden oder politische Gräben bestehen, nützt das beste Format nichts. Wo sie sich darauf einlassen, hinterfragen sie ihre eigenen Prozesse kritisch, und das tun die wenigsten freiwillig.
Was die Küche der IT voraushat: Vorbereitung und Vernetzung
Zwei Lektionen aus der Küche tragen direkt in die Softwarearbeit. Die erste: 80 Prozent der Arbeit ist Vorbereitung. In der Küche heißt das Mise en place, alles am Platz. Auch in der Testautomatisierung sind rund 80 Prozent Vorbereitung, und nur 20 Prozent ist das eigentliche Erstellen der Skripte. Das Skript ist fast ein Abfallprodukt guter Vorbereitung.
Die zweite Lektion ist die Vernetzung. Ein Koch kann seinen Salatposten gut machen, ohne nach links und rechts zu schauen. In der IT geht das nicht. Tester müssen verstehen, was andere tun: etwas über Architektur, etwas über Coding, etwas darüber, wie das Produkt angewendet wird. Diese Vernetzung reicht über Hierarchie- und Abteilungsgrenzen hinaus, oft auch über die Firma hinaus. Ohne sie lässt sich die Arbeit nicht vernünftig machen.
