Eingebaute Qualität

Bei der agilen Qualität geht es darum, in jeder Phase der Softwareentwicklung - von der Ideenfindung bis zur Freigabe - die richtigen Praktiken einzubauen, damit die Qualität eingebaut ist und nicht erst am Ende überprüft wird. Eine “Praxis” bedeutet hier eine kleine, konkrete Einheit von Fähigkeiten, Wissen und Denkweisen. Die Aufteilung der Qualitätsarbeit in diese kleinen Praktiken macht Verbesserungen greifbar, hilft den Teams bei der Aufteilung der Zuständigkeiten nach tatsächlichen Fähigkeiten und bietet Unternehmen eine konkrete Möglichkeit, Qualitätsziele mit Geschäftsergebnissen wie Kostenreduzierung oder schnellerer Lieferung zu verbinden.

Das Wichtigste in Kürze

• Die Aufteilung von Qualitätspraktiken in die kleinstmöglichen Skill-Container macht Verbesserungen für die Teams greifbar genug, um zu handeln, anstatt sich von der Größe des Ganzen lähmen zu lassen.
• Ein einzelner Tester, der mit fünf Entwicklern zusammenarbeitet, wird immer mit der Ausführung in Verzug geraten. Daher ist es eine strukturelle Lösung, den Tester in die Teststrategie zu integrieren und die Ausführung an die Entwickler zu delegieren.
• Agile Frameworks wie Scrum sind Mittel zur Wertschöpfung, nicht das Ziel. Wenn der Rahmen zum Ziel wird, ist das PI-Ereignis wichtiger als sein Zweck.
• Die Grundursache für Qualitätslücken ist das Management, wenn die Akzeptanzkriterien nicht definiert sind, denn ein Tester kann seine Arbeit nicht einteilen, ohne zu wissen, wann das Unternehmen sie abnehmen wird.

Agiles Testen ist einfach richtiges Testen

Agiles Testen unterscheidet sich in keiner Weise vom Testen. Die Prinzipien bleiben dieselben. Was sich ändert, ist der Druck, sie anzuwenden, denn in einer agilen Umgebung kannst du nicht auf ein fertiges Inkrement warten, bevor du anfängst.

Derk-Jan de Grood hat den ersten Teil seiner Karriere im Testen verbracht, bevor er sich der agilen Arbeit zuwandte. Als er wieder in die Rolle des Testmanagers schlüpfte, erwartete er, dass sich alles verändert haben würde. Auf der Managerseite war das nicht der Fall. Die alten Probleme waren immer noch da, wie Schubladen, die sich nacheinander öffnen: die gleichen Probleme, die er schon vor Jahren gesehen hatte, in der gleichen Form.

Die technische Seite ist eine andere Geschichte. Automatisierung, eine CI/CD-Pipeline, die Werkzeuge rund um das Testen, all das hat sich stark verändert. Aber all das ist auch kein “agiles Testen”. Es ist einfach die Art und Weise, wie das Testen heute durchgeführt werden sollte. Betrachte es als Standard, nicht als etwas, das du zusätzlich einbaust, wenn du ein Framework einführst.

Die Überraschung kommt, wenn Organisationen ein großes neues Projekt beginnen und du dir den Plan ansiehst. Manuelles Testen auf funktionaler Ebene, keine Pipeline in Sicht. Die Fähigkeiten sind vorhanden, aber sie werden nicht eingesetzt.

Warum Kompetenz ungenutzt im Regal liegt

Ein Testverfahren zu kennen und es anwenden zu können, sind zwei verschiedene Dinge. Viele Tester kennen die Techniken und wenden sie nie in der Praxis an. Die Kluft hat selten mit Talent zu tun. Es geht darum, ob das Wissen aktiviert wird.

Derk-Jan sieht die Lösung in der Skalierung von Fähigkeiten, nicht in der Skalierung von Frameworks. Die ganze Masse der “guten Softwareentwicklung” ist zu groß, um sie in einem Block zu erfassen. Die Leute sehen es sich an, zucken mit den Schultern und gehen zurück zu ihrem normalen Job, weil der Haufen Arbeit zu groß ist, um ihn anzufassen.

Die gleiche Falle tritt bei Innovationsbudgets auf. Teams bekommen zehn oder zwanzig Prozent Zeit, um “etwas mit Innovation zu machen”, und dann stocken sie, weil niemand weiß, wo er anfangen soll. Die Führungsebene fragt, warum sich nichts verbessert. Die Teams fragen, was sie verbessern sollen. Wenn die Teams schweigen, füllt das Unternehmen die Lücke mit mehr gewöhnlicher Arbeit und die Zeit für Verbesserungen verschwindet still und leise.

Verbesserung in Praktiken aufteilen

Eine Praxis ist die kleinste Menge an Fähigkeiten, Wissen und Denkweisen, die du brauchst, um eine bestimmte Aufgabe gut zu erledigen. Das ist die Einheit, die die Verbesserung praktikabel macht.

Für einen Tester könnte eine solche Praxis die “Anwendung von Testverfahren” sein. CI/CD ist ein anderer. Testautomatisierung ist ein weiterer. Jeder dieser Container ist klein genug, um ihn zu benennen, zu diskutieren und aufzugreifen. Derk-Jan zählt irgendwo zwischen hundert und hundertfünfzig davon.

Wenn die Arbeit auf diese Weise aufgeteilt ist, kann ein Team tatsächlich tauschen. Du hast diese Fähigkeiten, ich habe jene, sollen wir Wissen austauschen? Das öffnet die Tür für Lunch Sessions, Brown Paper Sessions, Lesen oder Mobbing. Die Verbesserung hört auf, ein abstrakter Auftrag zu sein und wird zu einem konkreten Austausch von Fähigkeiten.

Der gleiche Schritt funktioniert auch nach oben. Anstatt einem Team zu sagen, es solle “innovativ sein”, kannst du es sich aussuchen lassen: Sollen wir CI/CD machen, sollen wir Testautomatisierung machen, sollen wir dieses eine Tool schärfen. Konkretes ist immer besser als Vages.

Geteilte Verantwortung für Qualität hat ein Problem mit dem Eigentum

Wenn jeder für die Qualität verantwortlich ist, aber niemand einen Teil davon besitzt, geht die Qualität verloren. Ein Entwickler will programmieren. Wenn man von ihm verlangt, dass er auch für den UI-Entwurf, die Testdaten und die Testautomatisierung verantwortlich ist, zuckt er nur mit den Schultern und erzielt keine Ergebnisse.

Die Aufteilung der Arbeit in Praktiken behebt die Kluft zwischen den Verantwortlichkeiten. Du kannst eine schärfere Frage stellen: Wer hat die Fähigkeiten dafür und wer will besser darin werden? Auf diese Frage gibt es eine Antwort. auf die Frage “Wem gehört die Qualität?” gibt es normalerweise keine.

Das strenge multidisziplinäre Team, in dem jeder ein Entwickler ist und separate Tester nicht erlaubt sind, hat seinen Reiz verloren. Das bessere Ziel ist ein autarkes Team, das über alle erforderlichen Fähigkeiten und Kenntnisse verfügt, aber trotzdem eine Spezialisierung zulässt. Spezialisten können sich auch teamübergreifend in einer Gilde oder einem Chapter treffen und dort das gleiche Spiel zum Austausch von Fertigkeiten betreiben.

Wie ein Tester vom Laufen zur Strategie kommt

Ein Tester, der in Wiederholungstests ertrinkt, sollte sich eine Ebene höher bewegen, in Richtung Teststrategie, anstatt zu versuchen, die Entwickler zu übertrumpfen. Fünf Entwickler werden ihre Arbeit immer schneller machen, als ein Tester sie überprüfen kann.

Derk-Jan beschreibt ein kleines Team, in dem sich ein einzelner Tester gegen den Output von fünf Programmierern abmühte. Das Team setzte sich zusammen und teilte die Arbeit auf: Welche Tests soll der Tester durchführen, welche Tests können die Entwickler übernehmen. Sie legten das in einer einfachen Tabelle fest. Das gab dem Tester den nötigen Freiraum, um strategisch zu denken.

Durch diese Verschiebung hat ein Tester zwei Möglichkeiten, sich zu unterhalten. Eines mit der Organisation: Sind das die Tests, die ich machen soll? Eine mit dem Team: Hier ist alles, was getestet werden muss. Ich kann das nicht allein machen, hilf mir bei diesem Teil oder gib mir einen anderen Tester. Qualität wird wieder zu einer Teamaufgabe, bei der die Verantwortung geteilt wird und jeder sein Spezialgebiet einbringt.

Die Lektion lässt sich verallgemeinern. Wenn du nicht weiterkommst, weil du immer wieder dieselbe Schleife testest und frustriert bist, ist die Antwort selten, dass du härter testest. Geh eine Stufe höher und finde heraus, wer noch helfen kann.

Agilität überlebt den Agile-Hype

Agilität als Etikett mag seinen Höhepunkt bestanden haben, aber Agilität nicht. Die Frameworks waren einst um ihrer selbst willen cool. Eine PI-Veranstaltung wurde eher wegen ihrer Größe als wegen ihres Zwecks angepriesen: wie viele Leute, wie groß, wie beeindruckend, ganz egal warum.

Derk-Jan bezeichnet sich heute weniger als Experte für die agile Transformation als vielmehr als Experte für die Bereitstellung von Werten. Agilität war nie das Ziel. Es ist ein Mittel, um ein anderes Ziel zu erreichen: Menschen mehr Verantwortung und Selbstvertrauen zu geben und Entscheidungen in der Organisation nach unten zu verlagern.

Diese Neuausrichtung beginnt mit einer Frage, und das ist die schwierigste: Warum willst du das überhaupt tun? Ein Manager antwortet oft mit “schneller veröffentlichen” und “Kosten sparen”, oder schlimmer noch, er macht agil, weil es ein Hype ist. Ohne ein echtes Warum ist der Rest nur Theater.

Verbinde die Geschäftsziele mit den Praktiken

Die Praktiken sind das Bindeglied zwischen den vagen Geschäftszielen und dem konkreten Handeln des Teams. Das ist die Brücke, die bei den meisten Umstrukturierungen fehlt.

Wenn die Praktiken zusammen eine gute Softwareentwicklung ausmachen, kannst du für jede einzelne die Frage stellen: Reduziert sie die Kosten, beschleunigt sie die Lieferung, verringert sie die Rückläufer oder den Fehlerzustand der Qualität? Derk-Jan hat die Liste sogar durch eine KI laufen lassen, um die Praktiken nach ihrer Effektivität zu sortieren, wobei er feststellte, dass ein Experte das Ergebnis immer noch besser beurteilt.

Auf diese Weise kann ein Team dem Unternehmen in seinem Sinne antworten. Das Unternehmen will eine Kostensenkung. Das Team antwortet: Dann werden wir an diesen bestimmten Praktiken arbeiten, weil sie die Qualität verbessern und diesem Ziel dienen. Du arbeitest immer noch agil und entwickelst richtig, aber du verkaufst es über das Ergebnis, nach dem das Unternehmen gefragt hat, und nicht über den Namen des Frameworks.

Frameworks sind ein Jenga-Turm

Scrum ist eine Reihe von Praktiken, die sich für einige Teams bewährt haben, kein Gesetz. Jedes Team und jede Organisation ist anders, also wählst du aus, was für dich funktioniert und probierst es aus. Du kannst nicht im Voraus wissen, ob sich ein tägliches Stand-up oder ein Kanban-Board für deinen Kontext auszahlt.

Derk-Jan benutzt einen Jenga-Turm, um das zu vermitteln. Scrum gibt dir Richtlinien an die Hand: ein fünfzehnminütiges Stand-up, ein Team von bis zu neun Personen, jeden Tag. Bricht die Welt zusammen, wenn das Stand-up zwanzig Minuten dauert? Nein. Ist es eine Katastrophe, wenn du einen Tag auslässt? Wahrscheinlich nicht. Jede Regel, die du lockerst, ist ein Block, der aus dem Turm gezogen wird.

Solange dein Turm nicht zusammenfällt, ist alles in Ordnung. Aber wenn du zu viel herausnimmst, weißt du nicht, was du tust, und er könnte fallen. Derk-Jan de Grood

Der Turm hält, wenn du mit Bedacht Blöcke entfernst. Er fällt, wenn du so viel herausnimmst, dass nichts mehr die Struktur stützt. Stimme das Gerüst ab, bete es nicht an und entkerne es nicht blindlings.

Wo Qualität zuerst verloren geht

Das Management ist der häufigste Ort, an dem Qualität verloren geht, und zwar nicht als einfacher Sündenbock. Führungskräfte müssen qualitätsbewusst sein, denn sie entscheiden, welche Praktiken zählen und wann etwas als erledigt gilt.

Die Abnahme ist ein konkretes Beispiel. Derk-Jan arbeitete mit einem Kunden zusammen, bei dem es unklar blieb, wann die Arbeit tatsächlich abgenommen wird, da sie unter Diskussionen und Verträgen begraben war. Wenn du nicht weißt, wann du abnehmen wirst, kannst du nicht wissen, was du testen musst. Gebrauchstauglichkeitstests, Benutzertests, die angepassten Geschäftsprozesse, in scope oder out of scope, wer das alles testet, all das konnte nicht beantwortet werden. Für ein Unternehmen, das neu in diesem Bereich ist, braucht es viel Zeit, um das zu klären. Für ein Unternehmen, das häufig neue Produkte herausgibt, ist das vielleicht gar kein Problem.

Das zweite Hindernis liegt im Team selbst: Die Grundlagen werden schlecht gemacht. Wenn CI/CD nicht richtig eingeführt ist, solltest du dort ansetzen. Aber manche Unternehmen sind mit der normalen Arbeit so überfordert, dass sie gar nicht in Verbesserungen investieren können, weil jede Minute für das Testen und erneute Testen draufgeht. Das ist genau das Team, das eine Ebene höher gehen und sich Hilfe holen muss, bevor die Wiederholungen es zermürben.