«The (E-2-E) pain that I’m used to!?»
Geht es nur mir so, oder ist euch auch schon aufgefallen, dass trotz erfolgreicher Sprint-Demos in den Teams die Qualität, der von SAFe postulierten End-2-End Solution nicht stimmt? Wem nützen denn die kürzeren Iterationen, wenn die Lieferungen nicht der geforderten Qualität entsprechen und entsprechend «buggy» ausgeliefert werden?
Irgendwie werde ich das Gefühl nicht los, dass wir in den klassischen Wasserfall-Projekten mit ähnlichen Herausforderungen konfrontiert waren. Die Situation hat sich durch die höhere Komplexität und die kürzere Lieferkadenz sogar noch verschärft. Der Systemintegration fehlt es an der notwendigen Aufmerksamkeit und für die End-2-End Tests scheint niemand verantwortlich zu sein.
Mir kommt dabei spontan der Song „the pain that I’m used to“ von Depeche Mode aus dem Jahre 2005 in den Sinn. Wir haben uns zwar an gewisse Schmerzen gewöhnt, können diese aber je länger je weniger ertragen. Im ersten Teil dieser Blog-Serie wurde uns von unserem Silvio Moser aufgezeigt, wie SAFe funktioniert und dass Built-in Quality eine Grundvoraussetzung ist. In diesem zweiten Teil gehe ich den reellen Herausforderungen aus der Praxis auf den Grund und zeige eine Ursache, warum Testing in SAFe eine Herausforderung ist und wie dieses Dilemma gelöst werden kann.
Fehlende Produkt-Sicht (Solution-Integration)
Die Schmerz-Symptome
Auch wenn viele der agilen Teams mittlerweile interdisziplinär aufgestellt sind und dem Prinzip der 3 Amigos folgen, sind ihre Stories abgeschlossen, wenn die Definition of Done erreicht und die Demo erfolgreich verlaufen ist. Hand aufs Herz: Eine User Story entspricht aber nicht unbedingt dem Feature, welches von einem Agile Release Train in einem Product Increment als Solution geliefert werden sollte. Die Lieferungen der einzelnen Teams müssen die einzelnen Inkremente in einer Landing-Page, einer App oder einem Portal End-2-End getestet werden, damit der Kunde die Funktion auch aufrufen und nutzen kann.
Die Auswirkungen
Die Integration von Teilsystemen zu einem Produkt oder Teil eines Produktes stellte die Entwicklung schon lange vor SAFe vor eine ziemliche Herausforderung. Durch die kürzeren Iterationen werden diese zusätzlich verschärft.
In der Praxis sehe ich seit Jahren in verschiedenen Unternehmen, dass der Systemintegration nicht die notwendige Aufmerksamkeit geschenkt wird. Oft ist dies der Evolution einer Produktentwicklung zuzuschreiben. Schritt für Schritt wird die Integration von Teilsystemen in enger Zusammenarbeit mit den verschiedenen Entwicklungsteams ausprobiert, daraus gelernt und entsprechend aufgebaut. Dieses Trial and Error Verfahren ist bei einer Erstentwicklung legitim, sollte aber schnellstmöglich einem systematischen Vorgehen weichen.
Die Folgen reichen von ungenügender Regressionstestabdeckung bis hin zu frustrierten Testern. Täglich den gleichen Workflow drei bis viermal zu testen, weil irgendwo im System eine mögliche Lösung implementiert wurde, ist demotivierend. Eine Automatisierung auf End-2-End Ebene für neue Features ist bei diesem Vorgehen unrealistisch, weil sich die Testobjekte durch vermeintliche Korrekturen ständig verändern. Schlussendlich leidet die Produktqualität und die Kunden sind unzufrieden.
Der Mehraufwand dieses Vorgehens scheint in klassischen Projekten besser weggesteckt werden zu können. Dort sind genügend Ressourcen vorhanden und insbesondere der Faktor Zeit ist nicht so knapp, wie es in der agilen Entwicklung der Fall ist. Die Kosten einer unsystematischen Systemintegration sind jedoch, wie oben erwähnt, immens hoch.
Die grosse Frage, die sich auch nicht erst seit dem Scaled Agile Framework stellt, ist: «Wer ist für die Produkt- oder Solution-Integration verantwortlich?»
Das Rezept
SAFe liefert einen sehr guten Ansatz und definiert das «System-Team», welches die folgenden Aktivitäten auf Solution-Ebene sicherstellt:
- Aufbau und Wartung der agilen Entwicklungsumgebung inklusive Tool-Unterstützung
- Integration der Lieferungen aus dem Team und Sicherstellung der End-2-End Tests
- Unterstützung bei Deployments und den Release-on-Demands
- Testen der nicht-funktionalen Anforderungen auf der integrierten Solution
«Agile Teams sind keine eigenständigen Einheiten, sie sind Teil des Agile Release Trains und kollektiv für die Lieferung von grösseren Systemen oder Lösungen in erwarteter Qualität verantwortlich.»SAFe über System Teams
Die vorgeschlagene Lösung mit dem System-Team kümmert sich also um das Thema der Integration. Die Frage betreffend technischer Befähigung der einzelnen Teams wäre also geklärt. Die Verantwortung der Produkt- / Solution-Qualität liegt aber immer noch bei den Teams und eine praktikable Umsetzung der End-2-End Sicht scheint mit diesem Ansatz unbeantwortet.
Die Therapie
Aus meiner Erfahrung bringt ein Austausch zwischen dem System- und den Entwicklungsteams einen immensen Vorteil, weil es einen dedizierten Fokus auf die Solution richtet. Ökonomisch gesehen ist ein System-Team innert kurzer Zeit eine kosteneinsparende Investition. Die Qualität steigt, Fehlerkorrekturkosten sinken und die Kunden sind zufrieden. Wenn sich das System-Team aus Mitgliedern der einzelnen Entwicklungsteams formiert, wird die Produktsicht in die Entwicklungsteams gebracht und vermittelt ein zusätzliches Verständnis des Grossen und Ganzen, was aus Erfahrung folgende Auswirkungen hat:- Steigerung der Motivation der System-Team Mitgliedern durch klarere Ziele,
- Verbesserung der Systemarchitektur für eine effizientere End-2-End Test-Automatisierung,
- Förderung der Built-In Quality durch die Horizonterweiterung der Teams auf das Produkt und (last but not least)
- die Kunden sind glücklich mit dem gelieferten Produkt.
