Testing Agility

Ein arbeitsorganisatorischer Ansatz in der VUKA-Welt

Seit die agile Transformation in den meisten Softwareentwicklungsprojekten angekommen ist, haben sich Firmen darauf fokussiert, agile Prinzipien mithilfe von etablierten Softwareentwicklungsmethoden wie Scrum, SAFe oder Kanban zu implementieren. All diese Frameworks konzentrieren sich auf die Zusammenarbeit der Menschen untereinander, den Arbeitsprozess und den Mindchange in der Organisation. Auf das Thema Qualität wird meist nur implizit Bezug genommen. Genau dieser Bereich der ganzheitlichen Qualitätsoptimierung und speziell die notwendige Neuorientierung in Bezug auf „Menschen und Rollen“ soll in diesem Artikel genauer betrachtet werden.

Thomas Karl

Author

Nico Liedl

Author

27.11.2020
Lesezeit: 15 Minuten
94 Views

Um in einem agilen Umfeld grundsätzliche Leitlinien zu etablieren, haben wir das in Abbildung 1 dargestellte „House of agile Testing“ (im Folgenden HoaT) entwickelt. Es setzt sich aus fünf Teilbereichen zusammen. Die Basis bilden die Test Basics. Ohne diese methodischen Ansätze und die damit verbundenen Arbeitsweisen können in der Qualitätssicherung nicht die gewünschten Ergebnisse erzielt werden. Darauf bauen die drei Säulen Menschen und Rollen, Ansatz und Tools auf. Wenn diese drei Säulen aufgebaut sind und eine gewisse Reife aufweisen, wird das Haus mit Lean Agile Quality Engineering-Methoden vervollständigt, um auch komplexere Methoden und Techniken einzuführen.

Abb. 1: „House of Agile Testing“

Zuletzt sind wir in unserem Artikel „Qualitätssicherung im Kontext von großen agilen Softwareentwicklungsprojekten” [KaLi18] und in unseren zahlreichen Messevorträgen wie beispielsweise dem German Testing Day und der OOP auf das HoaT eingegangen. In einem weiteren Artikel haben wir uns speziell auf den effizienten Einsatz von Tools und der Testautomatisierung konzentriert [KaLi20]. Diese erfolgreiche Reihe möchten wir hier fortsetzen und uns mit den Herausforderungen und Belangen der ersten Säule beschäftigen.

Überblick über die drei Säulen des HoaT

Der Schwerpunkt unseres Artikels liegt damit auf der Säule 1 „Menschen und Rollen“. In dieser Säule gilt es, Fragen bezüglich der künftig notwendigen Rollen zu beantworten. Die Ausgestaltung hängt von der gewählten agilen Softwareentwicklungs- beziehungsweise Skalierungsmethode ab und auch davon, ob 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 agilen Rollen. Insbesondere ist zu klären, in welchem Umfang und welcher Tiefe technisches Wissen auf- und ausgebaut werden muss. Erst nach dieser Klärung werden die organisatorischen Strukturen weiterentwickelt und letztlich die neuen oder angepassten Rollen in der Organisation etabliert.

Die Säule 2 „Ansatz“ beinhaltet die Frage nach dem Testansatz, der sich aus dem gewählten Liefervorgehen ableitet. Insbesondere bei der Einführung von Agilität in Großprojekten, die Teil von komplexen IT-Systemlandschaften sind, wird zu Beginn einer agilen Transformation ein hybrider Ansatz verfolgt. Die Software wird dann oftmals in Sprints entwickelt, aber erst nach mehreren Monaten im Rahmen eines „normalen“ Release live gesetzt. Bei solchen Vorgehensweisen ist zu klären, welche Inhalte innerhalb der Sprints getestet werden können und welche Teile der Software nachgelagert geprüft werden müssen.

Die letzte Säule 3 beinhaltet die technischen und prozessualen Fragen der Toolauswahl. Es ist zu klären, welche Testautomatisierungstools am besten den gewählten Entwicklungsansatz unterstützen und ob bestehende eigenentwickelte Testautomatisierungstools weiterverwendet werden können. Gleichzeitig muss betrachtet werden, welche und wie viele Testumgebungen benötigt und wie diese mit Testdaten versorgt werden. Für ein effizientes Liefer- und Testvorgehen ist dann insbesondere die Einbettung der einzelnen Tools und Umgebungen in eine End-to-End-Tool-Pipeline zu beachten.

Säule 1 „Menschen und Rollen“ – Ein arbeitsorganisatorischer Ansatz in der VUKA-Welt

Wir leben in einer Welt, die sich ständig verändert sowohl im Kleinen als auch im Großen, für den Bereich der Softwareentwicklung trifft dies noch mehr zu als für viele andere. In der Literatur hat sich der Begriff VUKA-Welt dafür etabliert. VUKA steht für Volatilität, Unsicherheit, Komplexität und Ambiguität. Agile Arbeitsweisen werden oftmals als pauschale Musterlösung für die Herausforderungen der heutigen VUKA-Welt genannt. Aber auch hier gilt, „One fits all“-Lösungen passen nicht in diese Zeit, wie sie aber auch noch nie für die Arbeit mit Menschen gepasst haben. Auch im „Agilen Modus“ ist es entscheidend, befriedigende Lösungen hinsichtlich der Strukturierung der Belegschaft, der Motivation der Mitarbeiter, der langfristigen Personalentwicklung und in Zeiten des Fachkräftemangels nicht zuletzt der Mitarbeiterbindung zu finden.

Themen, die klassischerweise bei der Personalabteilung (HR) angesiedelt sind, müssen im Kontext einer agilen Transformation zwingend mitberücksichtigt werden. Eine enge Kooperation zwischen der Personalabteilung und beispielsweise dem Testmanager mit Personalverantwortung ist also nötig. Daher ist die Säule 1 ein ganz zentraler Erfolgsfaktor der agilen Transformation, denn diese Art von Änderungen in der Organisation sowie im Skill- und Mindset der Mitarbeiter bedarf eines organisatorischen Change.

Wir sehen innerhalb der Säule 1 dabei drei wesentliche Bereiche, erstens das neue Rollenmodell, zweitens die kontinuierliche Mitarbeiterqualifikation und drittens die zugehörige Weiterentwicklung der organisatorischen Strukturen. Diese drei Kernbereiche werden nachfolgend näher betrachtet.

Neue Rollen

Die Definition der Rollen über das gesamte Projekt hinweg wird maßgeblich dadurch entschieden, welches Framework (beispielsweise SAFe, SCRUM, Nexus, …) eingesetzt wird. Diese geben ein gewisses Setup vor und definieren im Vornherein, welche Rollen empfohlen werden und in Teilen auch wie diese ausgestaltet sind. In den wenigsten Fällen geht es darum, ein gesamtes neues Team oder gar die ganze Mannschaft neu aufzubauen. Meist werden die Mitarbeiter initial aus vorhandenen Teams zusammengestellt und teilweise in das agile Setup überführt. Dabei ist es wichtig von der ersten Kommunikation an, die Leute möglichst aktiv mit einzubeziehen. Gegebenenfalls ist es sinnvoll, konkrete Wünsche einzufordern, um den Leuten klar zu machen, dass sie gefragt sind, wo sie ihre Stärken und Schwächen sehen und wohin sie sich entwickeln möchten.

Die Besetzung der Teams, aber auch die Schaffung von neuen Rollen ist im Folgenden einer der wichtigen Erfolgsfaktoren. Die Teams sich selbst zu überlassen und ihre Qualitätsstrukturen vollständig allein zu strukturieren, mag sich in der Anfangszeit besonders „agile“ anhören. Nur leider kommt es spätestens bei der Skalierung dieses Ansatzes im Rahmen der späten Integration des Gesamtsystems dazu, dass der Bedarf besteht, eine übergreifende Struktur zu haben. Nur eine gemeinsame Vision mit gemeinsamen Zielen kann die gesamte Organisation auf einen Nenner bringen. Die Rolle eines Lead Quality Engineer, der als Architekt der Gesamtstruktur gesehen wird, kann dieses Ziel anstreben und die Mannschaft dahingehend coachen.

Innerhalb der Teams ist es genauso nötig, eine Position zu definieren, die den Qualitätsmaßnahmen im Team verpflichtet ist und das Team in dieser Hinsicht challenged. Wir nennen diese Rolle Quality Engineers, welche eher technisch, als SDET (Software developing Engineer in Test) oder eher fachlich, als In-Sprint Quality Spezialist oder UAT-Spezialist definiert werden. Es ist sinnvoll, eine Person mit Spezialwissen im Team zu haben, die optimalerweise in beiden Bereichen Stärken hat. Im Rahmen des T-shaped-Modells lässt sich über die Projektlaufzeit ein Fähigkeitsprofil über das Team hinweg darstellen. Mit diesem Wissen kann sich die Teamentwicklung immer weiter an das individuelle Ideal annähern.

Zusätzlich müssen alle Beteiligten regelmäßig abgeholt und darüber am Veränderungsprozess beteiligt werden. Nur so werden neue Rollen zum Leben erweckt und nachhaltig weiterentwickelt. Wichtig ist auch, dass man eine solche Struktur nicht an Tag 0 einführt. Auch hier ist es nötig, iterativ vorzugehen und schrittweise eine Maßnahme nach der anderen intensiv anzugehen. Begleitet von einem zielführenden Changemanagement-Prozess wird über einen längeren Zeitraum hinweg eine Qualitätsstruktur entstehen, die sich mit den entsprechenden Spezialisten selbst trägt und weiterentwickelt.

Abbildung 2 zeigt beispielhaft verschiedenste Rollen, die innerhalb sowie außerhalb des Sprints Qualitäts-Ownership übernehmen müssen und unterschiedlichste Fähigkeiten mitbringen. Diese müssen nicht zwingend von einzelnen Personen oder Personengruppen ausgefüllt werden. Es ist genauso möglich, dass mehrere Rollen von einzelnen Personen ausgefüllt werden. Die Rollen mit „In-Sprint Qualitäts-Fokus“ haben wir bereits eingangs beleuchtet. Je nach Ausbildung, Projektsetup und Relevanz empfehlen wir, zusätzlich zu betrachten, welche Rollen mit „Cross-Sprint Qualitäts-Fokus“ nötig sind oder mit der Zeit nötig werden. Dabei geht es darum, Spezialrollen oder übergreifende Fähigkeiten auszulagern, um eine gewisse Ausrichtung über das Gesamtprojekt zu erreichen. Dieser Bereich wird im Abschnitt „Weiterentwicklung der organisatorischen Strukturen“ genauer betrachtet.

Abb. 2: Unterschiedliche Rollen im Umfeld von Quality Engineering

Abbildung 3 zeigt verschiedene klassische Wissensgebiete und den jeweiligen Fokus, den die Rollen ausfüllen können. Damit wird auch sichtbar, welche Themen bei den QS-Rollen liegen können. Der Idee des T-shaped-Skill-Modells folgend, sollte entsprechend der Abbildung ein Basiswissen in den abgebildeten Kategorien vorliegen und je nach Rolle ein dazu passendes Expertenwissen im Kernaufgabengebiet.

Abb. 3: Verschiedenste Wissensgebiete als Teil des T-shaped-Modells und der dazugehörige Fokus der beschriebenen Rollen

Kontinuierliche Mitarbeiter-Qualifikation

Die kontinuierliche Weiterentwicklung der Mitarbeiter ist ein zentraler Erfolgsfaktor für Unternehmen in der heutigen Zeit und gewinnt insbesondere in der Wissensarbeit weiter stark an Bedeutung. Es gibt eine Vielzahl von unterschiedlichsten Modellen, Vorgehensweisen und good Practices in diesem Bereich.

Nachfolgend wird exemplarisch ein Ansatz vorgestellt, den wir für pragmatisch und relativ unkompliziert in der Anwendung halten und den wir bereits mehrfach erfolgreich in Transformationsprojekten eingesetzt haben. Dabei handelt es sich um das „Agile Coaching Competency Framework“ des Agile Coaching Institute [ACI]. Einen vergleichbaren Ansatz stellt die „Skill- bzw. Teamkompetenzmatrix“ aus der Management 3.0-Methoden-Werkzeugkiste dar, die wir ebenfalls bereits mehrfach erfolgreich eingesetzt haben.

Es sei noch daraufhin gewiesen, dass sich beide Modelle ausschließlich auf die Entwicklung von Wissen und Fähigkeiten fokussieren, die Karriereentwicklung wird hier nicht betrachtet. Eine enge Kooperation mit der Personalabteilung, um die unterschiedlichen Fähigkeiten und Rollen auf das Karrieremodell und Incentive System zu mappen, ist zwingend notwendig.

Abb. 4: Agile Coaching Competency Framework [ACI]

Das Agile Coaching Competency Framework, welches in Abbildung 4 dargestellt ist, ist originär dazu gedacht, die Kernfähigkeiten von gutem agilem Coaching darzustellen und zu clustern. Dabei wird explizit darauf hingewiesen, dass ein Coach nicht in allen Bereichen über Expertenwissen verfügen kann. Innerhalb eines agilen Teams sollten aber alle Bereiche abgedeckt sein. Das Framework ist in vier Sektoren aufgeteilt, um Wissen und Erfahrungen zu clustern:

Sektor 1: „Agile & Lean Practitioner“ repräsentiert das Wissen und Erfahrung hinsichtlich lean-agiler Methoden aller Art.
Sektor 2 ist unterteilt in die beiden Blöcke „Teaching“ und „Mentoring“. Beides sind Methoden, um Inhalte – sprich fachliches Wissen – zu vermitteln.
Auf der gegenüberliegenden Seite ist im Sektor 3 das Prozesswissen abgebildet mit der Unterteilung in „Coaching“ und „Facilitating“.
In Sektor 4 werden schließlich die drei Bereiche „Technical Mastery“, „Business Mastery“ und „Transformation Mastery“ unterschieden.

Dabei sind unter anderem folgende Fragen relevant:

Technical Mastery: Verfügt eine Person oder das Team über ausreichend technisches Wissen, beispielsweise Front- und Backend-Programmierkenntnisse oder Performanz- und Securitytesting-Wissen?
Business Mastery: Ist das fachliche Wissen über die Geschäftsabläufe und das fachliche Produktwissen in ausreichendem Maße vorhanden?
Transformation Mastery: Wie ausgeprägt ist das Wissen hinsichtlich Change Management, Kommunikation usw.

Basierend auf unserer Praxiserfahrung hat es sich bewährt, das Wissensniveau in jedem der Bereiche von Abbildung 4 zwischen 1 und 10 zu bewerten1. Die Bewertung wird in regelmäßigen Abständen wiederholt, die Ziele des Mitarbeiters und der Organisation jeweils dagegengehalten. So kann man schnell einen einfachen Weiterentwicklungsplan erstellen und die Fortschritte sichtbar machen, denn Fortbildungsmaßnahmen unterschiedlichster Art lassen sich auch hervorragend den jeweiligen Bereichen zuordnen.

Das „Agile Coaching Competency Framework“ wird also in zweierlei Hinsicht verwendet. Zum einen, um die verschiedenen Fähigkeitsniveaus der Teammitglieder in den unterschiedlichen Bereichen zu erfassen und dieses einerseits als Ausgangspunkt für die individuelle Weiterentwicklung der Mitarbeiter zu verwenden. Andererseits aber auch, um den Fähigkeitenpool des Teams als Gesamtes weiterzuentwickeln und dadurch sicherzustellen, dass das Team über Expertise auf dem jeweils benötigten Niveau verfügt.
Abbildung 5 gibt einen Eindruck davon, wie wir im Rahmen eines Teamworkshops zu Beginn einer Agilen Transformation dieses Konzept im Rahmen einer Teamaufstellung anwenden.

Abb. 5: Self-Assessment im Team mithilfe des Agile Coaching Competency Framework als Ausgangspunkt für die Weiterentwicklung

Zum anderen dient das Framework aber natürlich auch dazu, die Fähigkeiten der Coaches zu erfassen und so ein optimales fachliches Mapping zwischen Person/Team und Coach sicherzustellen. Natürlich muss zwingend darauf geachtet werden, dass der Faktor Mensch, also die zwischenmenschliche Verbindung zwischen Coach und Person/ Team, auch passt.
Wichtig ist anzumerken, dass die kontinuierliche Mitarbeiterweiterentwicklung immer maßgeschneidert auf die jeweilige Unternehmenssituation und Personalausstattung, im engen Schulterschluss zwischen der Personal- und den Fachabteilungen stattfindet.

1) Natürlich kann anstatt der Einteilung 1 bis 10 alternativ bspw. auch das Shu – Ha – Ri Model (Lehrling, Geselle, Meister) angewendet werden. Im Sinne einer engeren Verzahnung mit einem strukturierten Fortbildungsplan ist erfahrungsgemäß die Abstufung 1 bis 10 besser geeignet.

Weiterentwicklung der organisatorischen Strukturen

Je größer die Organisation ist und je mehr Teams oder gar Programmteile in einem Projekt in Verbindung stehen, umso wichtiger wird es auch, die organisatorischen Strukturen aktiv aus der QS-Brille zu entwickeln.
Das ist immer abhängig von der jeweiligen Projektsituation.

Folgende Aspekte können hier Einfluss nehmen:

Verteilung der Teams (inhouse, nearshore, offshore),
Fähigkeiten in den Teams/Komplexität von Tools,
Anzahl verwendeter Architekturen (Web, Rich Client, Microservices, …),
Lieferart (CI/CD, Release, Hybride Modelle, …).

Die Frage ist immer, was möchte man wie erreichen oder abbilden. Normalerweise muss man das auch erst im Laufe der Zeit lernen und sich dann aktiv in den Bereich entwickeln, der am besten zur Gesamtsituation passt. Eine regelmäßige Überprüfung des eingeschlagenen Wegs ist hier zu empfehlen.

Das Modell „Role Model Canvas“ (RMC) kann zusätzlichen Input generieren, der einen besseren Einblick in die Gesamtorganisation ermöglicht. Mithilfe dessen wird die Verteilung von Verantwortlichkeiten und Aufgaben über das Projekt sichtbar. In unserem Verständnis sollte man dieses Modell um eine detaillierte Betrachtung der Qualitätsaktivitäten über das gesamte Projekt erweitern. Gerade in Bezug auf die Weitergabe und Verteilung von Kompetenzen vom Management auf die Teams über Teams hinweg oder gar der Eigenwahrnehmung von einzelnen Mitarbeitern ist das RMC eine sinnvolle Methode. In Verbindung mit dem „Delegation Poker“ wird plastisch sichtbar, wie unterschiedlich meist die Sicht auf Zuständigkeiten ist oder gar, ob Verantwortungslücken entstanden sind. Es bietet spielerisch ein Analysewerkzeug, die Problemfelder sichtbar zu machen und im gleichen Zug zu behandeln. Eine regelmäßige Betrachtung des aktuellen Stands mit allen Beteiligten, oder in Kleingruppen, hilft, die Organisation in Bezug auf die neuen Rollen und Verantwortlichkeiten stetig zu fordern und weiterzuentwickeln.

Als Ergebnis einer derartigen Analyse kann sichtbar werden, inwiefern Rollen aus dem „Cross-Sprint Qualitäts-Fokus“ (siehe Abbildung 2) nötig sind. Aufgaben können beispielsweise ineffizient innerhalb der Teams durchgeführt werden, weil sich mehrere Rollen oder Teams für Aufgaben verantwortlich fühlen (siehe Abbildung 3). Rollen, wie Automation-Architekt, Regression/Release/ Integration/UAT-Tester, Test-Architekt oder Test-Manager können dann ausgelagert werden, um im Projekt einheitliche Strukturen zu fördern und die Gesamtqualität final aus einem Guss sicherzustellen.

Ein weiterer Erfolgsfaktor für eine gute Qualitätssicht über das gesamte Projekt ist, auch ein Qualitäts-Ownership in den Rollen zu wecken, die initial nicht direkt mit Test und Qualitätssicherung zu tun hatten. Das geht über den Product Owner, der bei der Beschreibung der Anforderung wachsam ist, über den Entwickler, der das Shift-left-Vorgehen durch frühe Tests fördert, bis hin zu den Projektverantwortlichen, die übergreifend ein Mindset fördern, dass eine gute Qualität vor der reinen Ablieferung von Features steht.

Fazit

Zusammenfassend bleibt festzuhalten, dass alle Maßnahmen und Aktivitäten innerhalb der Säule 1 (Rollen) im höchsten Maße in Abhängigkeit zu den Entscheidungen innerhalb aller Bestandteile des HoaT (Ansatz, Tools und unterstützende Maßnahmen) sind. Darüber hinaus müssen alle Maßnahmen aus Säule 1 zwingend im engen Schulterschluss mit den Personalverantwortlichen, der HR-Abteilung und der Geschäftsleitung getroffen werden. Alle diese Maßnahmen zahlen unmittelbar auf die Motivation, Qualifizierung und Zufriedenheit der Mitarbeiter ein. Mitarbeiter stellen dabei in unserer heutigen VUKA-Welt insbesondere im Bereich der Wissensarbeit das wertvollste Gut dar!

Festzuhalten ist, dass Qualität zukünftig neu erfunden werden muss. Nur mit einem ganzheitlichen Denken und einer Umgestaltung der Arbeitsabläufe in der Softwareentwicklung ist das möglich. Aus Softwaretestern von gestern müssen innovationsorientierte, neugierige Qualitätsingenieure werden, die Freude daran haben, die Grenzen automatisierter Testabläufe mit Analytics und KI laufend weiter zu stecken.