Wie die NASA mich für eine Qualitätsworkshop-Methode inspirierte

Wie viel Zeit vergeht zwischen dem Entstehen und dem Entdecken eines Fehlers? Anders gefragt: Wie viel Zeit und Geld verbrennen wir durch zu spät entdeckte Fehler? Wie können wir uns vor Augen führen, wo genau unser Entwicklungsprozess qualitativ verbessert werden kann? Wir finden gemeinsam in einem einfachen Workshop heraus, wo in Ihrem Prozess die Fehler entstehen und wo genau sie dann entdeckt werden. Inspiriert von der NASA-Vorgehensweise für Lebensmittel-Hygiene der Astronautenkost, kombiniert mit einer Abwandlung der Eventstorming-Methode wird all dies spürbar und sichtbar gemacht.

Auf Basis dieser Erkenntnisse können treffende Maßnahmen ergriffen werden, um die Qualität nachhaltig zu verbessern: Damit der Kunde das Produkt bekommt, das er erwartet. Aber gehen wir zu den Anfängen.

Die NASA und HACCP

Im Jahre 1958 startete das NASA Mercury-Programm mit dem Ziel, den ersten Menschen ins All zu bringen. Schon damals nutzte die NASA iterative Prozesse, um sich zeitgleich zu entwickeln und zu lernen. Dies war notwendig und gleichzeitig absolutes Neuland, da die Qualitätssicherung damals stark an übliche industrielle Standards geknüpft war. Im Juli 1960 wurde dann das Apollo-Programm ins Leben gerufen – obwohl Mercury bis dato keine sichtbaren Erfolge vorzeigen konnte. Letztendlich gipfelte das Vorhaben mit Apollo 11 in der ersten Mondlandung. Was die NASA bis zu dem Zeitpunkt nicht konnte, war der (sichere) Umgang mit Lebensmitteln. Ein hohes Risiko für die Besatzung: Ein Worst-Case-Szenario war die Erkrankung von Astronauten durch eine Lebensmittelvergiftung. Es gab bisher aber nur Fehlervermeidungsmethoden aus dem Maschinenbau. Daher durchgeführt sterben NASA im Jahr 1960 in Zusammenarbeit mit einigen lebensmittelverarbeitenden Betrieben Richtlinien zur Hygiene und Qualitätssicherung bei der Herstellung, Lagerung und Verarbeitung von Lebensmitteln. Diese Richtlinien wurden 1963 als „Codex Alimentarius“ von der Ernährungs- und Landwirtschaftsorganisation der Vereinten Nationen (FAO) und der Weltgesundheitsorganisation (WHO) herausgegeben und seitdem immer weiterentwickelt und weiterentwickelt. HACCP bedeutet Diese Richtlinien wurden 1963 als „Codex Alimentarius“ von der Ernährungs- und Landwirtschaftsorganisation der Vereinten Nationen (FAO) und der Weltgesundheitsorganisation (WHO) herausgegeben und seitdem immer weiterentwickelt und weiterentwickelt. HACCP bedeutet Diese Richtlinien wurden 1963 als „Codex Alimentarius“ von der Ernährungs- und Landwirtschaftsorganisation der Vereinten Nationen (FAO) und der Weltgesundheitsorganisation (WHO) herausgegeben und seitdem immer weiterentwickelt und weiterentwickelt. HACCP bedeutetGefahrenanalyse Kritische Kontrollpunkte ( siehe Kasten 1 ) _ _ _. Diese Prinzipien sind seit 2006 in der EU geführt für alle lebensmittelverarbeitenden Betriebe, wobei es egal ist, ob eine Tiefkühlpizza für den Massenmarkt, einen Imbissbetrieb oder ein 3-Sterne-Restaurant ist. Als gelernter Koch habe ich selbstverständlich diese Vorgehensweisen sehr früh verinnerlicht und angewendet. Alle Herstellungsprozesse werden anhand der HACCP-Regeln untersucht und mögliche Gefahrenpunkte erfasst – Begonnen bei der Zulieferung. Die zentralen Fragen sind dabei immer: Welche Arten von Kontaminationen sind möglich? Was sind die Gefahrenpunkte, wo kann die Kontamination stattfinden? Wo und wie kann dies geprüft und verhindert werden?
Dies WIRD anhand von Rückstellproben und Checklisten dokumentiert, nach klaren Regeln und für alle sichtbar. Dann werden geeignete Maßnahmen getroffen, um die optimale Qualität und Sicherheit von Lebensmitteln zu gewährleisten. Die Vorgehensweise einer professionellen Küche ist der Entwicklung von Software nicht unähnlich. So ist auch Kochen ein sehr iterativer Prozess, der sich durch permanente Qualitätskontrolle auszeichnet (Stichwort: „Naschen“) und in seinem Prozess ständig hinterfragt wird. Der „Mein Produkt“-Gedanke verpflichtet sich alle, auf Qualität zu achten, und der Servicegedanke ist essenziell. Und auch in der Küche hat jeder eine klare Aufgabe und Rolle im Team und es wird sich gegenseitig unterstützt. Das „Mise en Place“ – auch das Vor- und Nachbereiten – ist auch beim Softwaretesten rund 70 Prozent der Arbeit.

Qualitätsworkshops in der Softwareentwicklung

Wenn es überhaupt Workshops für die Qualität gibt, dann drehen sie sich meistens um Wissensvermittlung oder den Austausch über dynamische Testmethoden. Hilfreich ist dabei natürlich der Fundus aller ISTQB®-Trainings. Meiner Erfahrung nach hat dies aber nie ausgereicht. Zum einen, weil der Praxisbezug häufig fehlt, zum anderen, weil das Testen immer nachgelagert ist: Erst werden die Bugs eingebaut und danach können die Kolleginnen und Kollegen beim Testen versuchen, diese zu finden.
Dieser Ansatz erfordert sich schon immer falsch an. Schon der 1904 geborene rumänisch-amerikanische Wirtschaftsingenieur und Wegbereiter des Qualitätsmanagements Joseph M. Juran stellte fest, dass 85 Prozent der Fehler den Prozessen geschuldet sind. Als gelernter Koch begann ich instinktiv, Methoden der Lebensmittelhygiene auf das Softwaretesten zu übertragen: den Entwicklungsprozess entscheidend verändern – mit Methoden aus der Gastronomie. Meine ersten Prozessanalysen waren aber eher an der Technik orientiert, so wurden Datenfluss, Deployprozess und Ähnliches analysiert. Bis ich mit einer gemischten Gruppe aus Codern, Architekten, Requirements-Verantwortlichen, Produktmanagement und Testern gemeinsam begonnen habe, den Herstellungsprozess zu dokumentieren.
Mit den von mir verinnerlichten Methoden des HACCP haben wir gemeinsam den Prozess analysiert und verbessert. Und plötzlich wurde über mögliche Fehlerquellen im Prozess geredet. Gemeinsam wurden nun Ideen entwickelt, wie diese Fehler verhindert werden können. Einige Jahre später habe ich dann die Requirements-Engineering-Methode Event Storming kennengelernt (siehe Abbildung 1) . Meine Idee war jetzt, diese sehr kommunikative Methode und das starke analytische Vorgehen von HACCP zu kombinieren. Entstanden ist das Quality Storming – mit dem alleinigen Fokus auf Finden von Schwachstellen und Fehlern.

Was ist Quality Storming?

Hier findet ein teamübergreifender Workshop statt, mit dem Ziel, den IST-Prozess gemeinsam zu verstehen. Wir lokalisieren Fehlerquellen, decken Testprobleme auf und bessern nach. Dabei lernen wir auch etwas über die gegenseitigen Bedürfnisse und Erwartungen der anderen.
Bisher habe ich drei verschiedene Varianten von Quality Storming durchgeführt. Alle haben ein gemeinsames Grund-Setup (siehe Kasten 2) , je nach Ziel oder Teamgeist können die Varianten angewendet werden. Am allerwichtigsten ist eine gute Moderation. Die Qualität der Ergebnisse lebt von der guten Qualität der Moderation und der Zusammenarbeit.

Der Ablauf des Grund-Setups: Der Moderator erstellt ein Startevent und klebt es an die Wand. Im Gegensatz dazu startete hier der Prozess und verläuft dann nach rechts an den Wänden des Raumes entlang. Das Prozessende WIRD von der Moderation mit Einem Endevent gekennzeichnet.
Die Teilnehmer beschriften jetzt Klebezettel mit ihren Events, die chronologisch zwischen Start- und Endevent liegen. Die Klebezettel müssen die gleiche Farbe haben. Ein Event sollte im Format „Nomen + Verb“ geschrieben sein, beispielsweise „Anforderung“, „Unitests durchgeführt“, „Regressionstest gestartet“ oder „Fehlerreport geschrieben“. Achtung, es sollte möglichst immer der aktuelle „empfundene“ IST-Prozess dargestellt werden – nicht der gewünschte oder angestrebte Prozess, der in der Praxis nicht gelebt WIRD. Dieser mit den Zetteln sichtbar gemachte Prozess WIRD auch Stream genannt.
Ein Workshop kann mit Pausen wahrscheinlich bis zu vier Stunden dauern. Im Vordergrund steht hierbei die Kommunikation, das gemeinsame Verständnis für den Prozess und das Aufdecken von prozessualen Missverständnissen. Schon das Grund-Setup ist für viele eine Herausforderung. Denn hier kommt es auf die Reife der Organisation an: Es geht um die Suche nach Fehlern, nicht nach Schuldigen, es geht um Lösungen, nicht um Urteile. Herrscht ein grundsätzliches Klima von Offenheit, Vertrauen, Wohlwollen und gemeinsamer Ausrichtung, fällt es leichter, den Prozess gemeinsam festzulegen. Fehlt dies, ist eine gute, erfahrene Moderation noch wichtiger als ohnehin! Erfahrenere und reifere Organisationen können darüber hinaus den Workshop zielgerichteter gestalten und dafür diese nun folgenden Variationen anwenden.

Variante 1: Hotspots analysieren

Hierbei wird schon während des Grund-Setups von der Moderation darauf geachtet, wo es Unstimmigkeiten oder Diskussionen gibt. Diese Stellen (Hotspots, siehe Abbildung 2 ) werden jetzt mit einem Blitz per Klebezettel in einer anderen Farbe markiert. Wenn der klassische Prozess inklusive Hotspots an der Wand ist, werden diese von den Teilnehmern besucht. Zu den fraglichen Events werden nun die nötigen Vorbedingungen definiert und auf Klebezetteln in einer anderen Farbe dazu geklebt.

Alle beteiligten Akteure (siehe Abbildung 3) werden ebenfalls bekannt gemacht.

Die Frage an alle ist nun: „Was can wir tun, um den Blitz gemeinsam aufzulösen?“ Dabei wird geklärt, welche Faktoren und Vorbedingungen (siehe Abbildung 4) nötig sind, um den Konflikt (siehe Abbildung 5) aufzulösen.

Wen müssen wir eventuell noch mit ins Boot holen, von wem brauchen wir Hilfe oder Informationen? (siehe Abbildung 6) Diese Methode sorgt für ein übergreifendes Prozessverständnis: Welche Maßnahmen und Ideen braucht es zur Prozessverbesserung? Wo entstehen Engpässe? Basiert der Blitz vielleicht auch nur auf einem Missverständnis? Durch die direkte Kommunikation kann ein einheitlicher Wortschatz, idealerweise eine domänenspezifische Sprache geschaffen werden, die Eindeutigkeit fördert. Es entsteht ein qualitativer, konstruktiver Blick auf die QS-Tätigkeiten.

Variante 2: Fehlerprozessverbesserung

Die Erfahrung lehrt uns: Je mehr Zeit zwischen Machen eines Fehlers und Wahrnehmung eines Fehlers liegt, umso geringer ist die innere Akzeptanz für die Verantwortung. Um dem entgegenzutreten, ist Variante 2 hilfreich. Der Ablauf kurz skizziert: Ein aufgetretener und gefundener Fehler wird in den Eventstream eingepflegt. Nun wird im Stream vom Team markiert: Wo wurde (im Prozess) der Bug eingebaut? Wann haben wir (danach) getestet? Und wann wurde der Fehler entdeckt bzw. gemeldet?
Ein rotes Band quer durch den Raum verbindet die Punkte

• „Machen des Fehlers“ und
• „Entdecken des Fehlers“.

Manchmal geht es sogar quer durch den Raum. Dies lässt Fehler auch körperlich spürbar werden, da die Stelle das Band den Rest des Workshops im Blick und im Weg haben. Gemeinsam geht es nun an die Fragen: Was can wir tun, um das Band künftiger zu bekommen? Wann hätten wir den Fehler im Test finden sollen? Auch hierbei ist eine Moderation unumgänglich. Die Ideen und Maßnahmen werden gegebenenfalls direkt in den Stream als neue oder veränderte Prozessschritte eingepflegt. Hier bietet es sich an, eine neue Farbe für die Zettel zu nutzen.

Variante 3: Fehlervermeidung

Sehr nah am HACCP WIRD der Prozess analysiert, um das Entstehen von Fehlern von vornherein zu vermeiden. Auch diese Variante baut auf das Grund-Setup auf. Vom Moderator WIRD dann ein gefundener Fehler in die Eventleiste eingepflegt. Im Stream WIRD markiert, wo der Fehler im Prozess entstanden ist. Das Team klärt folgende Fragen: Welche Faktoren haben den Fehler im Entstehen? Welche Maßnahmen können im Vorwege helfen, diese Art Fehler zu vermeiden? Wie in Variante 1 ist es auch hier hilfreich, die Vorbedingungen, Akteure und Probleme deutlich zu machen. Und Achtung! Die Variante 3 birgt einen großen Nährboden für Fingerpointing. Es ist aber niemalsdas Ziel, Verantwortliche oder gar Sündenböcke zu ermitteln. Der Fokus liegt immer auf der Aufklärung der Kausalitäten und Abläufe, es geht um das Identifizieren von Möglichkeiten Fehlerherden und sterben Vorbedingungen dieser Fehlerentstehung.

Auch online möglich

Selbstverständlich können alle diese Workshops auch als Online-Variante durchgeführt werden. Hier posten wir unsere Zettel einfach gemeinsam auf eine virtuelle Timeline in einem Arbeitsboard – und das rote Band aus Variante 2 spannt sich darüber (siehe Abbildung 7) . Auch hier ist eine gute und erfahrene Moderation hilfreich.

Fazit

Alles in allem habe ich mit Quality Storming viele gute Ergebnisse erzielt, um die Hygiene ihrer Entwicklungsprozesse entscheidend verbessern zu können. Der Fokus sollte immer auf der Kommunikation liegen – das Verstehen der Anforderungen der anderen Prozessbeteiligten hilft allen, den Prozess an sich besser zu leben oder zu verbessern.
Ist es nicht spannend, dass permanente Temperaturkontrollen von Tiefkühlpizza die gleichen Ziele haben wie Softwaretests in der Entwicklung: die Qualität des Produkts! Und das alles vielleicht nur, weil die NASA jemanden auf den Mond schießen wollte …