House of Agile Quality

Das House of Agile Quality ist ein Rahmenkonzept, das die zentralen Bestandteile für Softwarequalität in agilen Projekten strukturiert. Es besteht aus einem Testfundament, drei Säulen (Rollen, Ansatz, Tools) und einem Dach aus Lean-Quality-Engineering-Methoden. Teams nutzen es als Checkliste, Reifegradmodell und Roadmap für Qualitätsverbesserungen.

Das Wichtigste in Kürze

• Das House of Agile Quality gliedert sich in Fundament, drei Säulen (Rollen, Ansatz, Tools) und ein Dach aus Lean Quality Engineering Methoden, um Qualität im agilen Kontext strukturiert anzugehen.
• Wer eine agile Qualitätstransformation startet, sollte zuerst die Säule Ansatz klären, weil die Wahl des Frameworks (Scrum, SAFe oder andere) direkt bestimmt, welche Rollen und Tools sinnvoll sind.
• Testdatenmanagement wird häufig unterschätzt: Je nach Teststufe braucht es synthetische Daten, anonymisierte Produktivdaten oder einen nächtlich zurückgesetzten Goldmandanten als separate Strategien.
• Die A3-Methode aus dem Lean Management erlaubt es, Verbesserungsideen auf einem einzigen Blatt mit Beobachtung, Aufwand, Nutzen und Verantwortlichen zu beschreiben und in einem Zeitrahmen von etwa acht Wochen umzusetzen.
• Hinter dem Buch stecken sechs bis sieben Jahre Projekterfahrung und iteratives Feedback aus Trainings und Workshops, kein rein theoretisches Konzept.

Was bedeutet das House of Agile Quality?

Das House of Agile Quality ist ein Modell, das beschreibt, wie sich Qualität in agilen Projekten umsetzen lässt. Die Haus-Metapher dient als einfaches Bild, das die einzelnen Bausteine zusammenhält und für jeden verständlich macht.

Das Modell besteht aus fünf Teilen: einem Fundament, drei Säulen und einem Dach. Thomas Karl hat es zusammen mit Nico Lidl entwickelt und in einem Buch beschrieben. Sechs bis sieben Jahre Arbeit liegen zwischen der ersten Idee und der Veröffentlichung, angereichert mit Projekterfahrungen und Feedback aus Trainings und Workshops.

Das Fundament heißt Testfundament. Darin stecken klassische Methoden und Reifegradmodelle, auf denen alles Weitere aufbaut. Zwischen Fundament und Säulen liegt ein Reifegradmodell von 1 bis 5, das als Roadmap dient.

Die drei Säulen tragen die agile Qualität

Auf dem Fundament stehen drei Säulen: Rollen, Ansatz und Tools. Jede deckt einen anderen Bereich der Qualitätsarbeit ab.

Die Säule Rollen behandelt Mitarbeiterbefähigung. Welche neuen Rollen entstehen in einem agilen Vorgehen? Und wie passt man organisatorische Strukturen so an, dass sie wirklich zum agilen Vorgehen passen und nicht nur darübergestülpt sind?

Die Säule Ansatz beginnt mit der Wahl des Frameworks. Scrum, SAFe, LeSS: an dieser Entscheidung hängt viel, denn jedes Framework bringt eigene Rollen und ein eigenes Grundsetup mit. Daraus folgt die Frage, welche Testaufgaben zu welchen Rollen am besten passen. In großen Projekten mit Dutzenden Teams kommt eine zweite Frage dazu: Was lässt sich innerhalb eines Sprints in einem Team testen, und was muss man cross Sprint oder cross Team prüfen, um die Qualität End-to-End sicherzustellen? Auch Change Management und eine einheitliche Sprache gehören hierher. Bei einer Transformation entstehen viele neue Begriffe, und man muss festlegen, was zum Beispiel ein Entwicklertest konkret bedeutet, damit keine Missverständnisse entstehen.

Die Säule Tools deckt den technischen und prozessualen Charakter ab. Sie reicht von der Auswahl des Testautomatisierungstools über Testumgebungen und Testdaten bis zur Orchestrierung im Sinne eines DevSecOps-Ansatzes.

Das Dach steht für Prozessqualität, nicht nur Produktqualität

Das Dach des Modells heißt Lean Quality Engineering Methoden. Es trennt zwei Sichten auf Qualität, die in der Praxis oft vermischt werden.

Die eine Sicht ist Produktqualität. Darauf liegt klassischerweise der Fokus, und das können Tester gut. Die andere Sicht ist Prozessqualität, die bei einer agilen Transformation besonders gefragt ist.

Dafür übernimmt das Modell Methoden aus dem Lean Management. Ziel ist, Prozesse nach einer Transformation wieder stabil und auf einen guten Reifegrad zu bringen und kontinuierliche Verbesserung einzubauen.

Wie funktioniert die A3-Methode zur Prozessverbesserung?

Die A3-Methode ist ein Werkzeug zur kontinuierlichen Verbesserung aus dem Lean Management. Sie nutzt ein DIN-A3-Blatt mit festen Boxen, die eine Verbesserungsidee strukturieren.

In den Boxen steht, was die Beobachtung ist, warum die aktuelle Situation nicht optimal ist, wie die Verbesserungsidee aussieht, wie aufwendig sie ist, was sie bringt, welche Rollen beteiligt sind und wie lange die Umsetzung dauert.

Das ausgefüllte Blatt dient als Input für einen Verbesserungsausschuss, der über Kosten, Nutzen und Aufwand entscheidet. Setzt der Ausschuss zu, übernimmt im Idealfall die Person die Umsetzung, die die Idee identifiziert hat, sofern sie in einen Zeitrahmen von etwa acht Wochen passt.

Wie gehst du mit Testdaten in agilen Projekten um?

Beginne mit einem Screening: Auf welcher Ebene führst du deine Tests durch, und welche Arten von Testdaten brauchst du dafür? Brauchst du historische Daten? Müssen Schnittstellendaten angebunden sein?

In der Praxis liegt der Fokus oft zuerst auf der Testautomatisierung. Erst im zweiten Schritt fällt auf, dass die Umgebungen nicht performant genug sind oder die passenden Testdaten fehlen.

Für technische Tests einer einzelnen Funktionalität legst du dir am besten synthetische Testdaten an, gegebenenfalls direkt während der automatisierten Testdurchführung. Für End-to-End-Tests später im Testzyklus gibt es andere Wege.

Diese Wege im Überblick:

Welcher Weg passt, hängt vom konkreten Anwendungsfall ab. Das Prinzip dahinter ist Hilfe zur Selbsthilfe statt einer Patentlösung.

Starte beim Aufbau in der Mitte des Hauses

Wer das Modell anwendet, beginnt typischerweise mit der Säule Ansatz. Zuerst klärst du, mit welcher Methodik du unterwegs bist und welche Rollen es schon gibt, denn ein Scrum-Vorgehen hängt prozess- und rollentechnisch anders zusammen als ein SAFe-Vorgehen.

Im zweiten Schritt schaust du dir die Komplexität der Software an. Eine kleine App stellt andere Anforderungen als ein großes SAP-System, das mit vielem im Unternehmen verbunden ist.

Von der Säule Ansatz hangelst du dich dann im Links-rechts-Vergleich entlang: links die Rollen, um Leute zu befähigen, rechts die Tools, um ihnen das nötige Werkzeug zu geben. Test-Driven Development nützt wenig, wenn die passenden Leute mit dem nötigen Wissen und den Tools fehlen.

Im dritten Schritt gibt es eine Rückkopplung in den Ansatz. Die Prozesse, die ein Standard-Framework mitbringt, werden ergänzend beschrieben. So lassen sich neue Mitarbeiter einarbeiten, und die Prozesse lassen sich kontinuierlich hinterfragen. Das gelingt leichter, wenn man sie zumindest auf High Level skizziert hat.

Tools sind mehr als Testautomatisierung

Tools werden oft mit Automatisierung gleichgesetzt, doch das Modell unterscheidet mehrere Kategorien. Den Einstieg bildet die Testautomatisierung, eng verbunden mit dem Testdatenmanagement.

Seit der Veröffentlichung hat das Thema AI-Tools stark an Bedeutung gewonnen. Die Frage lautet, wie sich solche Tools in den Qualitätsprozess integrieren und nutzen lassen. Hinzu kommt das Thema Robotik im Sinne der DevOps-Orchestrierung.

Im vertieften Kapitel zum Performance Engineering hat Sven Löfke seine Expertise eingebracht. Dort geht es um die verschiedenen Last- und Performance-Test-Tools und um den Unterschied zwischen einem Stresstest und einem reinen Load-Test.

Das Ziel ist eine automatisierte End-to-End-Pipeline, auf der berechtigterweise DevOps-Pipeline steht und nicht zwanzig manuelle Schritte dazwischenstecken. Dafür lohnt es sich, die Bandbreite der Tools bewusst groß zu halten und zu prüfen, an welcher Stelle welches Werkzeug am besten passt.

Lean Six Sigma liefert weitere Methoden fürs Dach

Neben der A3-Methode stecken weitere Lean-Methoden im Dach des Modells. Eine stammt aus der Lean-Six-Sigma-Welt: Voice of Customer.

Voice of Customer passt zur Kundenzentriertheit im agilen Vorgehen. Es dient dazu, Critical-to-Quality-Kennzahlen für einen Prozess zu definieren. Gerade bei mehreren Teams oder firmenübergreifender Arbeit klärt der Ansatz zuerst, wer eigentlich der Kunde ist, also der nächste Prozessschritt.

Daraus leiten sich die kritischen Faktoren ab, die sich messen lassen und über die sich der Gesamtprozess optimieren lässt. Hinzu kommt eine DMAIC-Vorgehensweise zur Prozessverbesserung, die als größere Variante des PDCA-Zyklus funktioniert.

Geschichten machen aus dem Fachbuch mehr als Theorie

Vor jedem Bereich des Hauses steht eine kleine Geschichte, mit Humor und Ironie erzählt. Sie greifen typische Situationen auf, in die man bei Verbesserungs- oder Transformationsthemen geraten kann.

Diese Geschichten lockern den Stoff auf und schaffen Wiedererkennung. Wer eine Situation aus der eigenen Praxis erkennt, kann den Inhalt leichter auf den eigenen Kontext übertragen.

Das Buch erklärt zuerst das Konzept mit seinen fünf Bestandteilen und liefert dann einen Deep Dive zum Performance Engineering. Bewusst beschreibt es nicht jeden Bestandteil bis ins letzte Detail, sondern gibt Absprungpunkte mit, etwa Literaturverweise oder den Hinweis auf die A3-Methode zum tieferen Einstieg.

Unser Fokus war, wirklich Hands-on-Sachen zu beschreiben und nicht irgendwas theoretisch Abstrahiertes, womit man in der Praxis erst drei Wochen überlegen muss, wie man das in den eigenen Projektkontext überführt.

Thomas Karl

Wie geht es mit dem Modell weiter?

Das größte Folgethema ist AI. Dazu ist ein White Paper geplant, das beschreibt, wie sich AI-Tools im Kontext agiler Softwareentwicklung nutzen lassen, um kurze Sprints zu unterstützen.

Auch das Thema Testdaten wird tiefer behandelt, weil es an Dringlichkeit gewonnen hat. Ein Blog zum Buch ist gestartet, der nächste Artikel widmet sich den Rollen.

Im Mittelpunkt steht dort der Transformationscharakter: der Weg von einem Status quo, egal ob klassische Wasserfallwelt oder ad-hoc-agiles Vorgehen, hin zu einem reifen Zustand. Dazu sollen Trainings- und Mitarbeiterentwicklungspfade aufgezeigt werden.