Built-in Quality heißt, in jeder Phase der agilen Softwareentwicklung die passenden Praktiken zu verankern, vom Verfeinern der Idee bis zum Release, sodass Qualität Teil der Arbeit ist und nicht erst am Ende geprüft wird. Eine “Praktik” ist dabei eine kleine, konkrete Einheit aus Können, Wissen und Haltung. Wer die Qualitätsarbeit in solche kleinen Praktiken zerlegt, macht Verbesserung greifbar, verteilt Zuständigkeiten nach tatsächlichen Fähigkeiten und verbindet Qualitätsziele konkret mit Geschäftszielen wie Kostensenkung oder schnellerer Lieferung.
Das Wichtigste in Kürze
- Wer Qualitätspraktiken in möglichst kleine Einheiten zerlegt, macht Verbesserung so greifbar, dass Teams tatsächlich loslegen, statt vor der Größe des Ganzen zu erstarren.
- Ein einzelner Tester gegenüber fünf Entwicklern kommt mit der Testdurchführung nie hinterher. Ihn zur Teststrategie zu holen und die Durchführung an die Entwickler abzugeben, ist deshalb eine strukturelle Lösung und kein Kompromiss.
- Agile Frameworks wie Scrum sind Mittel, um Wert zu liefern, nicht das Ziel. Wird das Framework zum Ziel, zählt das PI-Event mehr als sein Zweck.
- Das Management verursacht Qualitätslücken, wenn Abnahmekriterien offen bleiben: Ein Tester kann seine Arbeit nicht zuschneiden, solange er nicht weiß, wann die Organisation abnimmt.
Agiles Testen ist einfach gutes Testen
Agiles Testen unterscheidet sich im Kern nicht vom Testen überhaupt, und auch Built-in Quality ist keine agile Sonderdisziplin. Die Prinzipien bleiben gleich. Was sich ändert, ist der Druck, sie anzuwenden: In einem agilen Umfeld kannst du nicht abwarten, bis ein fertiges Inkrement vor dir liegt.
Derk-Jan de Grood hat den ersten Teil seiner Laufbahn im Testen verbracht und sich dann stärker der agilen Arbeit zugewandt. Als er später wieder als Interims-Testmanager einstieg, rechnete er damit, dass sich alles verändert hat. Auf der Managementseite war das nicht so. Die alten Probleme waren noch da, und sie tauchten auf wie Schubladen im Gedächtnis, die eine nach der anderen aufgehen: dieselben Themen wie vor Jahren, in derselben Form.
Technisch sieht es anders aus. Automatisierung, CI/CD-Pipeline, das ganze Werkzeug rund ums Testen: Da hat sich viel getan. Aber auch das ist kein “agiles Testen”. So wird heute einfach getestet. Behandle es als Standard und nicht als Extra, das du beim Einführen eines Frameworks dranschraubst.
Die Überraschung kommt, wenn eine Organisation ein großes neues Projekt startet und du dir den Plan ansiehst. Manuelles Testen auf funktionaler Ebene, keine Pipeline in Sicht. Das Können ist da, es wird nur nicht genutzt.
Warum Kompetenz ungenutzt im Regal liegt
Ein Testverfahren zu kennen und es anwenden zu dürfen, sind zwei Paar Schuhe. Viele Tester kennen die Verfahren und setzen sie in der echten Arbeit nie ein. Am Talent liegt das selten. Es geht darum, ob das Wissen überhaupt abgerufen wird.
Derk-Jan setzt deshalb beim Skalieren von Fähigkeiten an, nicht beim Skalieren von Frameworks. “Gute Softwareentwicklung” als Ganzes ist zu groß, um sie auf einmal zu greifen. Die Leute schauen sich den Berg an, zucken mit den Schultern und machen mit ihrem normalen Job weiter, weil ihnen der Haufen Arbeit zu groß vorkommt.
Dieselbe Falle zeigt sich bei Innovationsbudgets. Teams bekommen zehn oder zwanzig Prozent ihrer Zeit, um “etwas mit Innovation zu machen”, und kommen dann nicht vom Fleck, weil niemand weiß, wo anfangen. Das Management fragt, warum sich nichts verbessert. Die Teams fragen, was sie denn verbessern sollen. Bleiben die Teams stumm, füllt das Business die Lücke mit mehr Tagesgeschäft, und die Verbesserungszeit verschwindet leise.
Built-in Quality beginnt mit kleinen Praktiken
Eine Praktik ist der kleinste Baustein aus Können, Wissen und Haltung, den du brauchst, um eine bestimmte Aufgabe gut zu erledigen. Mit dieser Einheit wird Verbesserung machbar.
Für einen Tester kann so ein Baustein “Testverfahren anwenden” sein. CI/CD ist ein anderer, Testautomatisierung noch einer. Jeder ist klein genug, um ihn zu benennen, zu besprechen und anzupacken. Derk-Jan kommt auf irgendwas zwischen hundert und hundertfünfzig davon.
Ist die Arbeit so aufgeteilt, kann ein Team tatsächlich tauschen. Du kannst das hier, ich kann das da, wollen wir Wissen austauschen? Daraus werden Lunch Sessions, Brown-Paper-Sessions, Lesezeit oder Mob Programming. Verbesserung ist dann kein abstrakter Auftrag mehr, sondern ein konkreter Tausch von Fähigkeiten.
Nach oben funktioniert das genauso. Statt einem Team zu sagen “macht mal Innovation”, lässt du es auswählen: Nehmen wir uns CI/CD vor, Testautomatisierung oder schärfen wir dieses eine Tool? Greifbar schlägt vage, jedes Mal.
Warum geteilte Verantwortung für Qualität scheitert
Wenn alle für Qualität verantwortlich sind, aber niemand ein Stück davon wirklich besitzt, rutscht die Qualität weg. Ein Entwickler will programmieren. Verlangst du von derselben Person, auch UI-Design, Testdaten und Automatisierung als einen ungeteilten Klumpen zu übernehmen, bekommst du Achselzucken statt Ergebnisse.
Die Aufteilung in Praktiken schließt diese Lücke. Du kannst eine schärfere Frage stellen: Wer hat die Fähigkeit dafür, und wer will darin besser werden? Auf diese Frage gibt es eine Antwort. Auf “Wem gehört die Qualität?” meistens nicht.
Das strenge multidisziplinäre Team, in dem alle Entwickler sind und eigene Tester nicht vorgesehen, hat seinen Reiz verloren. Besser ist ein Team, das alle nötigen Fähigkeiten und alles nötige Wissen selbst mitbringt und trotzdem Spezialisierung zulässt. Spezialisten können sich zusätzlich teamübergreifend in einer Gilde oder einem Chapter treffen und dort dasselbe Tauschspiel spielen.
Vom Wiederholungstest zur Teststrategie
Ein Tester, der in Wiederholungstests untergeht, sollte eine Ebene nach oben gehen, Richtung Teststrategie, statt zu versuchen, gegen die Entwickler anzutesten. Fünf Entwickler produzieren immer schneller, als ein Tester prüfen kann.
Derk-Jan erzählt von einem kleinen Team, in dem sich ein einzelner Tester gegen den Output von fünf Programmierern aufrieb. Das Team setzte sich zusammen und verteilte die Arbeit neu: Welche Tests macht der Tester, welche können die Entwickler übernehmen? Das Ergebnis stand in einer einfachen Tabelle. Damit hatte der Tester endlich Luft, strategisch zu denken.
Mit diesem Schritt führt ein Tester zwei Gespräche. Eines mit der Organisation: Sind das die Tests, die ihr wirklich von mir wollt? Eines mit dem Team: Das hier muss alles getestet werden, allein schaffe ich das nicht, helft mir bei diesem Teil oder holt mir einen weiteren Tester. Qualität wird wieder Teamsache, die Verantwortung ist geteilt, und jeder bringt sein Spezialgebiet ein.
Das lässt sich verallgemeinern. Wer im Kreislauf aus Wiederholen, Nachtesten und Frust feststeckt, kommt selten weiter, indem er noch härter testet. Geh eine Ebene höher und finde heraus, wer sonst noch helfen kann.
Agilität überlebt den Agile-Hype
Agile als Etikett mag seinen Höhepunkt überschritten haben, Agilität nicht. Die Frameworks waren eine Zeit lang cool, einfach weil sie Frameworks waren. Mit einem PI-Event hat man wegen seiner Größe angegeben, nicht wegen seines Zwecks: wie viele Leute, wie groß, wie beeindruckend, egal wozu.
Derk-Jan sieht sich heute weniger als Experte für agile Transformation und mehr als Experte für Wertschöpfung. Agile war nie das Ziel. Es ist ein Vehikel für ein anderes Ziel: Menschen mehr Verantwortung und Selbstvertrauen geben und Entscheidungen weiter unten in der Organisation treffen lassen.
Dieser Perspektivwechsel beginnt mit einer Frage, und es ist die schwierigste: Warum wollt ihr das überhaupt? Ein Manager antwortet oft mit “schneller releasen” und “Kosten sparen”, oder schlimmer, er macht Agile, weil es gerade Hype ist. Ohne echtes Warum ist der Rest Theater.
Geschäftsziele mit Praktiken verbinden
Die Praktiken verbinden ein vages Geschäftsziel mit konkretem Handeln im Team. Genau diese Brücke fehlt den meisten Transformationen.
Wenn die Praktiken zusammen gute Softwareentwicklung ausmachen, kannst du bei jeder einzelnen fragen: Senkt sie Kosten, beschleunigt sie die Lieferung, reduziert sie Rückläufer oder Qualitätsmängel? Derk-Jan hat die Liste sogar von einer KI nach Wirkung sortieren lassen und dabei festgehalten, dass ein Experte das Ergebnis immer noch besser beurteilt.
So kann ein Team dem Business in dessen Sprache antworten. Das Business will Kosten senken. Das Team sagt: Dann arbeiten wir an genau diesen Praktiken, weil sie die Qualität verbessern und diesem Ziel dienen. Du arbeitest weiter agil und entwickelst weiter ordentlich, verkaufst es aber über das Ergebnis, das das Business haben wollte, und nicht über den Namen des Frameworks.
Frameworks sind ein Jenga-Turm
Scrum ist eine Sammlung von Praktiken, die für manche Teams funktioniert haben, kein Gesetz. Jedes Team und jede Organisation ist anders, also suchst du dir aus, was für dich passt, und probierst es aus. Ob sich ein Daily Stand-up oder ein Kanban-Board in deinem Kontext lohnt, weißt du vorher nicht.
Derk-Jan erklärt das mit einem Jenga-Turm. Scrum gibt dir Leitplanken: fünfzehn Minuten Stand-up, ein Team von bis zu neun Leuten, jeden Tag. Geht die Welt unter, wenn das Stand-up zwanzig Minuten dauert? Nein. Ist es eine Katastrophe, wenn ein Tag ausfällt? Wahrscheinlich nicht. Jede Regel, die du lockerst, ist ein Block, den du aus dem Turm ziehst.
“Solange dein Turm nicht umfällt, ist alles gut. Aber wenn du zu viel herausnimmst und nicht weißt, was du tust, kann er fallen.”
(Derk-Jan de Grood)
Der Turm hält, solange du Blöcke mit Urteilsvermögen ziehst. Er fällt, wenn du so viel herausnimmst, dass nichts mehr das Gerüst trägt. Also: das Framework anpassen, es nicht anbeten und es nicht blind entkernen.
Wo Qualität zuerst verloren geht
Am häufigsten geht Qualität im Management verloren, und das ist kein bequemer Sündenbock. Führungskräfte müssen qualitätsbewusst sein, denn sie entscheiden, welche Praktiken zählen und wann etwas als fertig gilt.
Die Abnahme ist ein konkretes Beispiel. Derk-Jan arbeitete mit einem Kunden, bei dem unklar blieb, wann die Arbeit tatsächlich abgenommen wird, verschüttet unter Diskussionen und Verträgen. Wenn du nicht weißt, wann abgenommen wird, weißt du auch nicht, was du testen musst. Usability-Tests, Anwendertests, die angepassten Geschäftsprozesse, in Scope oder out of Scope, wer testet das alles: Nichts davon ließ sich beantworten. Für eine Organisation, die damit neu ist, kostet das Klären richtig Zeit. Für eine, die häufig releast, ist es vielleicht gar kein Thema.
Das zweite Hindernis liegt im Team: schlecht gemachte Grundlagen. Steht CI/CD nicht sauber, fang dort an. Manche Organisationen sind allerdings so im Tagesgeschäft gefangen, dass sie gar nicht in Verbesserung investieren können, weil jede Minute ins Testen und Nachtesten geht. Genau dieses Team muss eine Ebene höher gehen und sich Hilfe holen, bevor die Wiederholung es zermürbt.
Häufig gestellte Fragen
Unterscheidet sich agiles Testen grundlegend vom Testen in einem traditionellen Projekt?
Nein. Die Prinzipien bleiben dieselben; was sich ändert, ist der Druck, sie anzuwenden, denn bei einer agilen Arbeitsweise gibt es kein fertiges Inkrement, auf das man warten kann. Automatisierung, CI/CD-Pipelines und die Test-Tools haben sich stark weiterentwickelt, aber so sollte das Testen heute einfach ablaufen, und es ist kein Extra, das man erst anbringt, wenn man ein Framework einführt.
Warum führt spezielle Innovationszeit so oft zu keiner Verbesserung?
Weil niemand weiß, wo man anfangen soll. Teams bekommen zehn oder zwanzig Prozent ihrer Zeit, um „etwas mit Innovation zu machen“, und kommen nicht weiter, da die gesamte Bandbreite guter Softwareentwicklung zu groß ist, um sie als Ganzes zu erfassen. Das Management fragt, warum sich nichts verbessert, das Team fragt, was es verbessern soll, und während beide schweigen, füllt das Unternehmen die Zeit still und leise mit gewöhnlicher Arbeit auf.
Was ist die kleinste sinnvolle Einheit, um die Arbeitsweise eines Teams zu verbessern?
Eine Praxis: der kleinste Baustein aus Fähigkeiten, Wissen und Denkweise, der nötig ist, um eine Aufgabe gut zu erledigen. Der Einsatz von Testverfahren ist eine, CI/CD eine andere, Testautomatisierung wieder eine andere. Die vollständige Liste umfasst etwa hundert bis hundertfünfzig Punkte. Wenn man sie so klein aufteilt, lassen sich die Fähigkeiten zwischen den Leuten durch Lunch Sessions, Brown-Paper-Sessions, Lesen oder Mob Programming austauschen.
Warum scheitert „Jeder ist für die Qualität verantwortlich“ in der Praxis so oft?
Weil Verantwortung ohne einen eigenen Aufgabenbereich nichts lässt, wofür man sich verantwortlich fühlen kann. Ein Entwickler will programmieren, und wenn man derselben Person UI-Design, Testdaten und Testautomatisierung als einen ungeteilten Klumpen übergibt, führt das zu Achselzucken, nicht zu Ergebnissen. Teilt man die Arbeit in Praktiken auf, lautet die Frage: Wer hat die Kompetenz dafür und wer will sich darin verbessern? Auf diese Frage gibt es eine Antwort.
Was sollte ein Tester tun, wenn das erneute Testen nie endet?
Beweg dich eine Ebene höher, hin zur Teststrategie, anstatt zu versuchen, die Entwickler beim Testen zu übertrumpfen. Fünf Entwickler werden ihre Arbeit immer schneller erledigen, als ein Tester sie prüfen kann. Ein Team teilte die Arbeit in einer einfachen Tabelle auf: Welche Tests führt der Tester durch, welche übernehmen die Entwickler? Dadurch hatte der Tester die Freiheit, die Organisation zu fragen, ob dies die richtigen Tests sind, und das Team um Hilfe beim Rest zu bitten.
Musst du dich genau an die Scrum-Regeln halten, wie sie geschrieben stehen?
Nein. Scrum ist eine Sammlung von Praktiken, die für manche Teams funktioniert haben, kein Gesetz. Stell dir einen Jenga-Turm vor: ein 15-minütiges Stand-up, ein Team mit bis zu neun Mitgliedern, jeden Tag. Wenn du 20 Minuten brauchst, ziehst du einen Block heraus, wenn du einen Tag auslässt, ziehst du einen weiteren. Der Turm hält, solange du Blöcke mit Bedacht entfernst, und fällt um, wenn du so viele herausnimmst, dass nichts mehr ihn stützt.
Wie setzt man ein Unternehmensziel wie Kostensenkung in konkrete Teamarbeit um?
Durch Praktiken. Frag bei jeder einzelnen, ob sie Kosten senkt, die Lieferung beschleunigt oder Rückläufer und Qualitätsmängel reduziert, und arbeite dann an denjenigen, die dem vom Unternehmen genannten Ziel dienen. Das Team betreibt weiterhin ordentliche Entwicklung, verkauft diese aber über das vom Unternehmen geforderte Ergebnis statt über den Namen des Frameworks. Das Sortieren von Praktiken nach ihrer Effektivität lässt sich mit KI vorbereiten, auch wenn ein Experte das Ergebnis besser beurteilen kann.
Ist schlechte Qualität hauptsächlich ein Problem des Teams oder ein Problem des Managements?
Meistens das Management, und das nicht als bequemer Sündenbock: Führungskräfte entscheiden, welche Praktiken zählen und wann etwas als fertig gilt. Bei einem Kunden blieb die Abnahme unklar, begraben unter Diskussionen und Verträgen. Wenn man nicht weiß, wann die Arbeit abgenommen wird, kann man nicht wissen, was getestet werden muss: Gebrauchstauglichkeitstests, Anwendertests, angepasste Geschäftsprozesse, ob im Umfang enthalten oder nicht, und wer dafür zuständig ist.
