Die Ursprünge des HoaT reichen ins Jahr 2010 zurück, als die „agile Reise“ von Accenture bei der Bundesagentur für Arbeit (BA) begann. Ebenso wie sich dieses IT-Verfahren und die meisten IT-Abteilungen der Welt weiterentwickelt haben und neue beziehungsweise komplexere Herausforderungen dazu kamen, hat sich auch das HoaT weiterentwickelt. Dabei berücksichtigt das HoaT V2.0 insbesondere die Herausforderungen der Skalierung, die zunehmende Bedeutung des Lean Management, der kontinuierlichen Verbesserung und die permanente Weiterentwicklung der Mitarbeiter insbesondere auch nach der Transformation.
Im ersten Abschnitt des Artikels wird daher das theoretische Fundament gelegt und die Evolution des HoaT beschrieben, um dann im zweiten Teil den Bezug zum eingangs genannten Praxisprojekt und den dort gesammelten Erfahrungen herzustellen.
Das HoaT V2.0 als theoretisches Fundament
Im Rahmen einer agilen Transformation müssen wie bei jedem größeren Veränderungsprojekt initial einige Fragen beantwortet werden. Dies ist wichtig, um ein einheitliches Verständnis aller Beteiligten bezüglich der Transformation zu schaffen und somit auch die Grundlage für eine erfolgreiche Veränderung zu legen. Erfahrungsgemäß sollten mindestens die folgenden Fragen beantwortet werden:
- Was wollen wir erreichen? – Welches geschäftspolitische Ziel wird mit der agilen Transformation verfolgt?
- Welches agile Framework ist für unser Unternehmen am besten geeignet? – Damit verbunden ist auch die Frage, welche Tools wir benötigen.
- Was benötigen unsere Mitarbeiter, um die gesetzten Ziele und Erwartungen erreichen zu können?
- Was benötigt unsere Organisation (als Ganzes betrachtet), um die gesetzten Ziele und Erwartungen erreichen und dauerhaft in die Organisationsstruktur und -kultur aufnehmen zu können?
Das Fundament des Hauses bilden die Test Basics, also die Grundlagen des Testens und der Qualitätssicherung. Dies beinhaltet sowohl ein fundamentales Verständnis des Testprozesses als auch die methodischen Grundlagen, wie beispielsweise das Wissen über Testfallentwurfsmethoden, Review Techniken und Defekt-Management (vgl. IST-QB CTFL Syllabus).
Abb. 1: Evolution des House of agile Testing
Die Säulen des Hauses definieren die Arbeitsweise/Prozesse des Tests in einem agilen Umfeld. Abbildung 1 stellt die Inhalte der drei Säulen eine Detailstufe tiefer dar. In weiteren Artikeln gehen wir detailliert auf die einzelnen Säulen ein, diese sind zum Teil erschienen:
- Tools und unterstützende Maßnahmen [KaLi18],
- Rollen [KaLi20], oder erscheinen zukünftig in weiteren Artikeln:
- Ansatz,
- Lean Quality Engineering.
Nachstehend wird daher nur kurz auf die wesentlichen Inhalte der Säulen eingegangen. In der 1. Säule – „Rollen“ gilt es, Fragen bezüglich der künftig notwendigen Rollen zu beantworten. Dies hängt einerseits von der gewählten agilen Softwareentwicklungsbeziehungsweise Skalierungsmethode ab, andererseits aber auch von der Frage, ob gegebenenfalls Spezialrollen für den Test benötigt werden. Direkt damit verbunden ist die Frage nach dem notwendigen technischen Wissen und Verständnis in den einzelnen Rollen. Insbesondere ist hier auch die Frage zu klären, inwiefern und in welchem Umfang technisches Wissen auf- und ausgebaut werden muss, um das notwendige Skillset, dasmit den jeweiligen Rollen verbunden ist, im Unternehmen sicherzustellen. Wenn die beiden vorangegangen Fragen geklärt sind, gilt es schließlich, die organisatorischen Strukturen weiterzuentwickeln und letztlich die neuen beziehungsweise angepassten Rollen im Organigramm der Organisation einzubauen und abzubilden.
Die 2. Säule – „Ansatz“ beinhaltet die Frage nach dem Lieferansatz und der damit direkt verbundenen Frage: „wann, was, getestet werden muss“. Insbesondere bei der Einführung von Agilität auf großen Entwicklungsprojekten, die Teil von komplexen IT-Systemlandschaften sind, findet man in der Anfangsphase ein hybrides Vorgehen vor. Die Software wird dann oftmals in Sprints entwickelt, aber erst nach wenigen Monaten im Rahmen eines Releases live gesetzt. Bei dieser Vorgehensweise gilt es zu klären, welche Inhalte innerhalb der Sprints und welche in einem aus- und nachgelagerten Test geprüft werden müssen.
Eine weitere Möglichkeit besteht darin, dem Big-Bang-Vorgehen zu folgen. Im Rahmen einer Implementation Roadmap wird die gesamte Mannschaft im neuen Vorgehen geschult und dann direkt in allen Bereichen in das neue Vorgehen überführt. Es kommt am Ende darauf an, welches Vorgehen zu welchem Projektzeitpunkt sinnvoll ist. Gerade weil wir uns auf den Bereich der QS konzentrieren, stellt die Wahl des richtigen Ansatzes eine besondere Herausforderung dar, denn oftmals ist es schwierig, aus diesem Bereich heraus Veränderungen zu motivieren.
Die 3. Säule – „Tools“ beinhaltet schließlich die technischen und prozessualen Fragen der Toolauswahl. Eine frühe Ausrichtung in Richtung DevSecOps kann die nötige Entwicklung in die zukünftige Automatisierung des Projekts fördern. Es gilt zu klären, welche Testautomatisierungstools den gewählten Entwicklungsansatz am besten unterstützen, ob sie in einer zukünftigen Toolchain zusammenpassen und sich immer weiter kombinieren lassen. Genauso gilt es hier, den übergreifende Architectural Runway im Blick zu behalten. Jegliche Weiterentwicklung wirkt sich schließlich auf die Qualitätsmaßnahmen aus, daher sollen diese auch Wirkung auf die zukünftige Ausgestaltung der Architekturbestandteile haben. Darüber hinaus müssen Testumgebungen und der Umgang mit Testdaten frühzeitig in die Planung aufgenommen und schließlich angestrebt werden. Ziel muss sein, die einzelnen Tools und Umgebungen in eine End-to-End-Tool-Pipeline einzubetten.
Das Dach des Hauses bilden die Lean Quality Engineering-Methoden. Hier sind schließlich die komplexeren Methoden und Techniken anzusiedeln, die sich als Teil oder rund um die agile Softwareentwicklung herausgebildet haben. Dazu zählen beispielsweise fortgeschrittene Testmethoden wie das Behaviour-Driven Development [Fer14], proaktive Ansätze des Quality Engineering, zum Beispiel Performance Engineering statt nur Performance Test, aber auch der gesamte Bereich des Lean Quality Engineering.
Im lean-agilen Qualitätsmanagement lassen sich durch die Kombination von agilen, lean und Six Sigma Methoden beeindruckende Resultate erzielen. Dabei können wir in der Softwareentwicklung durch den Transfer und die Adaption von Good Practices aus der Fertigungsindustrie extrem viel lernen. Das Spektrum reicht von einer kundenzentrierten Arbeitsweise auf Basis von Value Streams, über die Visualisierung und die kontinuierliche Verbesserung bis hin zu einem dedizierten Prozessfokus und der Vermeidung von Verschwendung. Insbesondere die Themenbereiche Prozessqualität und Vermeidung von Verschwendung sind im skalierten Umfeld von besonderer Bedeutung. Dabei gilt es zu berücksichtigen, dass ein simples Kopieren der Methoden aufgrund der großen Unterschiede zwischen Massenfertigung am Fließband und kreativer Wissensarbeit an der CI/CD-Pipeline nicht sinnvoll ist.
Neben der testspezifischen Betrachtung der Inhalte stellen ein auf die agile Transformation angepasstes Veränderungsmanagement und eine gezielte Organisationsentwicklung einen weiteren Erfolgsfaktor dar, beides sind integrale Bestandteile des HoaT V2.0 [Kai17].
Kasten 1: Das Umfeld virtueller Arbeitsmarkt (VAM)
Praxisprojekt „virtueller Arbeitsmarkt”
Nachfolgend wird nun die Umsetzung des beschriebenen Konzepts bei der Bundesagentur für Arbeit (BA) beschrieben.
Seit dem Jahr 2010 begleitet Accenture gemeinsam mit dem Kunden die agile Reise. Man sammelte viele Erfahrungen, die im weiteren Verlauf des Artikels näher betrachtet werden sollen. Die vorgestellte Theorie wird anhand von Beispielen aus dem Praxisprojekt vorgestellt.
Im Rahmen der bekannten agilen Skalierungsframeworks wie SAFe© [Chr17], NEXUS© [Bit18] oder LeSS© [Lar17] werden viele der im Folgenden beschriebenen Best Practices eingesetzt. Zum Start der Transformation in der damaligen Wasserfallwelt hatte der Test seinen etablierten Stand. Der Change-Prozess hin zum agilen Vorgehen schürte bei den Testern Ängste und Ungewissheiten. Unklare Rollen, Angst vor Auflösung des Testteams, auch die Zusammenarbeit zwischen Entwicklung und Test und der damit verbundenen Auflösung der Silos bargen die Herausforderung, Tester dazu zu motivieren, in die agile Welt zu transferieren. Das Skillprofil des Testers wandelt sich seit den Anfängen der Agilisierung stark in Richtung eines agilen Quality Engineer. Der damit verbundene Mindchange, der im ersten Teil theoretisch beschrieben ist, stellt in der Praxis die größte Herausforderung dar. Abbildung 2 zeigt den traditionellen Ansatz des Testings sinnbildlich. Die Testaktivitäten konzentrieren sich auf die Testphase im Softwareentwicklungszyklus.
Abb. 2: Traditionelles Testvorgehen
Im Folgenden werden exemplarische Praxisbeispiele für die 3 Säulen des HoaT aus dem Beispiel bei der BA beschrieben.
Rollen
Säule 1 im HoaT stellt eine große Herausforderung dar, weil es sich erstens um einen sehr langwierigen Prozess handelt, Rollen zu definieren und abzustimmen, und sich zweitens die Rahmenbedingungen durch immer wiederkehrende Teamveränderungen ändern. Eine Maßnahme, die uns bei dem Beispielprojekt längerfristig begleitet und einen gewissen Rahmen für die Weiterentwicklung verschafft hat, ist das Role Model Canvas (RMC). Im Rahmen dessen werden die Verantwortlichkeiten auf den verschiedensten Ebenen abgebildet und für die jeweiligen Personengruppen organisiert. Sei es innerhalb der Teams, über Entwicklungsteams oder zuliefernde Teams hinweg oder auch vom Management in die Teams. Das RMC stellt das aktuell vorherrschende Rollenverständnis und im Ergebnis dann das zukünftige Zielbild dar. Durch die klare Kommunikation über die gesamte Mannschaft kann man schließlich alle weiteren organisatorischen Weiterentwicklungen daraufhin ausrichten.
Für die Ausgestaltung der neu gewonnenen geteilten Verantwortungen in den Testrollen wurde eine Test Community of Practice (Test-CoP) eingeführt. Diese entwickelte sich zu einem der zentralen Bestandteile, die zum nachhaltigen Erfolg geführt hat. Im Rahmen dieser CoP werden die Teams aktiv in die Weiterentwicklung des Testvorgehens und Methodiken eingebunden und damit Anregungen und Ideen teamübergreifend diskutiert, verfeinert und eingeführt. Damit erreicht man, dass gute Ansätze aus den Teams auf dem gesamten Projekt Anwendung finden und ein übergreifendes Qualitätsverständnis und Qualitätsniveau gehalten werden kann.
Als Beispiel aus der Säule „Ansatz“ ist die Strukturierung der organisatorischen Teamstruktur und deren Aufgabenbereiche zu nennen. Diese Fragestellungen gilt es, im Laufe der Organisationsentwicklung zu klären. Über die Jahre hinweg wurde das klassische Testteam immer weiter in die agilen Teams überführt. Der Effekt war der, dass Testaktivitäten relativ schlecht abgestimmt einerseits in den agilen Teams (ET) und andererseits im Testteam (TEST) durchgeführt wurden. In einem weiteren Schritt galt es, klare Strukturen vorzugeben, wo und wann welche Testaktivitäten durchgeführt werden. Dem Team muss bewusst werden, dass es allein für die Qualität seiner Anwendungsbereiche verantwortlich ist und kein weiteres Team ein „Sicherheitsnetz aufspannen wird“.
Unter diesen Voraussetzungen entstand ein selbstverantwortetes Qualitätsverständnis der Teams, welches die Identifikation mit dem Produkt stärkt. Das Testteam ist weiterhin als wichtiges QS-Bindeglied zum hybriden Vorgehen der BA nötig. Es stellt die Verbindung zu den Schnittstellenpartnern her und kümmert sich um die Release abschließende QS. Dazu werden abschließende QS-Maßnahmen durchgeführt, die erst kurz vor dem Go-Live relevant werden. Die Teams können sich dadurch besser auf die Weiterentwicklung des Folgereleases konzentrieren. Abbildung 3 stellt die Aufteilung zwischen den Entwicklungsteams (ET) und dem Testteam und ihren zeitlichen Ablauf dar.
Abb. 3: Organisatorische Teamstruktur und Aufgabenbereiche
Ein Beispiel der Säule Tools aus dem HoaT ist die Umsetzung der aus der Literatur bekannten Testautomatisierungs-Pyramide [Coh09] und der damit verbundenen Umsetzung vollumfänglicher Testautomatisierung. Wie soll es möglich sein, alle Testaktivitäten aus der „alten Welt“ in nur einem Sprint für das „potentially shippable product“ unterzubekommen? Viele Projekte kennen sowohl das Problem als auch die Pyramide. Die zentrale Herausforderung ist jedoch die Umsetzung.
Das Prinzip des „shift left“ (siehe Abb. 4) gibt klare Strukturen vor, wie Testaktivitäten sinnvoll aneinandergereiht werden, um mit einer vorgegebenen Sprintlänge alle nötigen Testaktivitäten umsetzen zu können. Bezug nehmend auf Abbildung 2 werden damit die Testaktivitäten zum frühestmöglichen Zeitpunkt durchgeführt. Umsetzbar ist das durch ein klares Engagement zur Testautomatisierung. Auf dem Beispielprojekt wurde so über die Jahre eine Testautomatisierungsquote von 95 Prozent über alle Teststufen erreicht.
Abb. 4: Zielbild „shift left“
Fazit
Die genannten Beispiele geben einen Einblick, welche Bestandteile in den vielen Jahren in die Qualität eingezahlt haben. Aus Sicht von Accenture ist der VAM eines der am weitesten entwickelten agilen Projekte. Der nächste logische Schritt ist, eine konsequente Umsetzung des projektübergreifenden Lean Agile Quality Management- Ansatzes zu verfolgen. Dafür benötigt man eine übergreifende Vision und eine damit einhergehende stetige Weiterentwicklung der Vision und der daraus abgeleiteten Mission. Die genannten Werkzeuge werden auch weiterhin dazu beitragen, wobei die Marschrichtung regelmäßig überarbeitet werden muss.
Genauso muss das HoaT-Konzept stetig kritisch betrachtet und weiterentwickelt werden. Verschiedenste Projekte ermöglichen es uns, am „Puls der Zeit“ diese Weiterentwicklungen in der Praxis stetig voranzutreiben und so das HoaT kontinuierlich weiterzuentwickeln, um neuste Trends einzubauen.
Referenzen
[Bit18]
K. Bittner, P. Kong, D. West, Mit dem Nexus Framework Scrum skalieren – Kontinuierliche Bereitstellung eines integrierten Produkts mit mehreren Scrum-Teams, dpunkt.verlag, 2018
[Chr17]
M. Christoph, SAFe – Das Scaled Agile Framework. Lean und Agile in großen Unternehmen skalieren, dpunkt.verlag, 2017
[Coh09]
M. Cohn, Succeeding with Agile, Software Development Using Scrum, Pearson Education, 2009
[Fer14]
J. Ferguson, BDD in Action, Manning, 2014
[Kai17]
S. Kainzbauer, W. Brandhuber, Eine Einführung in die Agile Organisationsentwicklung, Sigs Datacom eBook, 2017, siehe:
https://www.sigs-datacom.de/wissen/ebooks/wissen-titel/agile-organisationsentwicklung.html
[KaLi18]
Th. Karl, N. Liedl, Qualitätssicherung im Kontext von großen agilen Softwareentwicklungsprojekten, in: German Testing Magazin, 2/2018, siehe:
https://www.accenture.com/t00010101T000000Z__w__/de-de/_acnmedia/PDF-94/Accenture-Qualitatssicherung.pdf#zoom=50
[KaLi20]
Th. Karl, N. Liedl, House of Agile Testing – Säule 1: Rollen, in: German Testing Magazin, 2/2020
[Lar17]
C. Larmann, B. Vodde, Large-Scale Scrum – Scrum erfolgreich skalieren mit LeSS, dpunkt.verlag, 2017
