Der aus dem Lean Management stammende Fokus auf Prozessqualität und Vermeidung von Verschwendung wird in den IT-Kontext überführt. Prozessqualität wird dabei als „Hidden Champion“ für die Realisierung von Business Agility identifiziert. Schließlich wird die Bedeutung der Rolle des Quality Coach für die erfolgreiche Implementierung der aufgezeigten Lean-Management-Methoden in der skaliert agilen IT-Systementwicklung herausgearbeitet.
Mik Kersten formuliert die Auswirkungen der steigenden Bedeutung von Software und deren Qualität im Geschäftsleben frei übersetzt wie folgt: Diejenigen Unternehmen, welche es schaffen, große skalierte Softwareprojekte erfolgreich auszuliefern, geben den Takt in der Wirtschaftswelt des 21. Jahrhunderts vor [Ker19]. Mit Blick auf die Börsenwerte und den Einfluss der großen Tec-Giganten wie Google, Microsoft, Apple und Co. scheint sich diese These zu bestätigen.
Agile Vorgehensweisen wie Scrum helfen, viele Aspekte der oben genannten Herausforderungen zumindest teilweise für kleinere IT-Applikationen zu lösen. Doch für größere IT-Verfahren mit mehreren Hundert Mitarbeitern wie bei ERP-Systemen ist dies nicht mehr ausreichend. In diesem Umfeld wird meist mit agilen Skalierungsframeworks wie zum Beispiel SAFe© [Chr17], NEXUS© [Bit18] oder LeSS© [Lar17] gearbeitet, um die Komplexität und Größe beherrschbarer zu machen. Die meisten dieser Skalierungsframeworks setzen auf bewährte Methoden aus dem Lean Management, die mal mehr mal weniger an die spezifischen Besonderheiten der Wissensarbeiter in der Softwareentwicklung angepasst sind.
Diese starke Tendenz zur Anwendung von Lean-Management-Methoden und Prinzipien ist auch auf das allgegenwärtige Ziel, „Business Agility“ tatsächlich umzusetzen, ausgelegt. Business Agility und damit verbunden die Reduzierung der Time to Market wird von 56 Prozent der befragten Unternehmen im „Status Quo (Scaled) Agile 2020”-Report der Hochschule Koblenz [Kom20] als Hauptgrund für die Einführung agiler Methoden angegeben. Die Realisierung einer kürzen Time to Market kann dabei auf unterschiedliche Weisen erreicht werden.
Lean-agiles Qualitätsmanagement ist einer der vielversprechendsten und gleichzeitig aktuell noch einer der am wenigsten eingesetzten Wege, um dies zu erreichen. Denn Business Agility ist fundamental von der Fähigkeit abhängig, schnell qualitativ hochwertig zu liefern, schnell auf Änderungen reagieren zu können und dabei stets kundenzentriert zu agieren.
Ein agiler Lösungsansatz – Lernen von den Lean-Meistern: „Go-Look-See and adapt for IT“
Im lean-agilen Qualitätsmanagement lassen sich durch die Kombination von agilen, Lean und Six Sigma Methoden herausragende Ergebnisse erzielen. Dabei können wir in der Softwareentwicklung, wie in Abbildung 1 dargestellt, durch den Transfer und die Adaption von Good Practices aus der Fertigungs- und Automobilindustrie 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.
Abb. 1: Transfer und Adaption von Good Practices aus der Fertigungsindustrie in die Softwareentwicklung
Nachfolgend liegt der Fokus auf den Themenbereichen Produkt- und Prozessqualität und der Vermeidung von Verschwendung. Es wird aufgezeigt, welche Praktiken und Methoden der Fertigungsindustrie in den Kontext der Softwareentwicklung überführt werden können. Denn ein einfaches Kopieren ist aufgrund der großen Unterschiede zwischen Massenfertigung am Fließband und kreativer Wissensarbeit an der CI/CD-Pipeline nicht sinnvoll.
Qualitätssicherung (QS) – Das Zusammenspiel von Produkt- und Prozessqualität
In der IT bezieht sich der Begriff Qualität typischerweise darauf, wie gut das entwickelte Softwareprodukt die Kundenanforderungen erfüllt. QS-Maßnahmen wie funktionale und nicht-funktionale Tests zielen darauf ab, die Umsetzung der Anforderungen und damit die Qualität des Produkts zu validieren. Dabei werden nicht nur die einzelnen Softwarebestandteile, sondern auch ihre Integration zu einem Softwareprodukt betrachtet.
Die Produktqualität, wie sie oben beschrieben ist, ist allerdings nur eine Seite der Medaille. Ein Fokus rein auf Produktqualität reicht nicht aus, um die Kunden auf Dauer zufriedenzustellen. Erst wenn die zweite Seite der Medaille, die Prozessqualität, ebenfalls berücksichtigt wird, erschließt sich das volle Potenzial des Qualitätsmanagements im leanagilen Kontext.
Prozessqualität betrachtet, wie gut die gelebten Prozesse zum Erreichen der Unternehmensziele beitragen. Wenn die Qualität der Prozesse gut ist, führen sie stets zu demselben, angestrebten Ziel – sie treffen immer ins Schwarze. Eine unzureichende Prozessqualität wird hingegen sichtbar in Schwankungen der Ergebnisse. Zwei Faktoren spielen hier eine wichtige Rolle: die Präzision eines Prozesses und seine Genauigkeit. Ein genauer Prozess erreicht zwar immer grob sein Ziel, allerdings nicht reproduzierbar mit demselben Ergebnis. Ein präziser Prozess erreicht zwar immer dasselbe Ergebnis, jedoch nicht unbedingt das Gewünschte. Erst wenn ein Prozess sowohl präzise als auch genau ist, also eine Wiederholgenauigkeit gegeben ist, ist die Prozessqualität akzeptabel und die Softwareentwicklung ein Erfolg.
Erst im Zusammenspiel wird der Wert von Produkt- und Prozessqualität deutlich. Um in einem lean-agilen Kontext schnell hoch-qualitative Softwareprodukte liefern zu können, müssen beide Qualitätsaspekte berücksichtigt und in einer holistischen QS-Vorgehensweise zusammengefasst werden. Im Folgenden wird anhand eines Beispiels näher erläutert, wie das Thema Prozessqualität konkret im IT-Kontext zur Anwendung kommen kann.
Der Kreis der Verschwendungen – ein Anwendungsbeispiel
Um die Prozessqualität zu verbessern, können Methoden des Lean Managements angewandt werden, beispielsweise die Verschwendungsanalyse. Verschwendung im Kontext von Lean bezeichnet nicht-wertschöpfende Tätigkeiten, also Tätigkeiten, die nicht direkt dazu beitragen, dem Kunden einen Mehrwert zu liefern. Diese Tätigkeiten sollten identifiziert und dann eliminiert werden. Dies hat signifikanten Auswirkungen auf die Durchflusseffizienz und fördert das Ziel, die „Time to Market“ zu reduzieren. Gemäß einer Studie von Poppendieck [Pop03] beträgt die Durchflusseffizienz über verschiedene Industrien hinweg nur 15 Prozent, was wiederum bedeutet, dass 85 Prozent der Arbeit im Softwarelebenszyklus als Verschwendung angesehen werden kann.
Abb. 2: TIM WOODS oder die 8 Verschwendungsarten
Im Kreis der Verschwendungen, der in Abbildung 2 skizziert ist, werden verschiedene Arten von Verschwendungen kategorisiert. Diese lassen sich auch auf die Softwareentwicklung übertragen, entweder wie von Mary Poppendieck vorgeschlagen auf IT-System-Ebene oder auf Ebene der IT-Organisation. Wie lässt sich Letzteres nun konkret in IT-Organisationen anwenden? Um dies zu beantworten, wird im Folgenden die Verschwendungsanalyse am Beispiel der Testautomatisierung vorgestellt.
- Überproduktion: Überproduktion wird auch die Mutter aller Verschwendungen genannt. Im Kontext der Testautomatisierung fallen beispielsweise automatisierte Testfälle, die nur einmal durchgeführt werden, unter diese Verschwendungsart.
- Bestände: Als Konsequenz aus der Überproduktion ergeben sich immer größere Bestände, zum Beispiel an automatisierten Testfällen, die zu fehlender Übersicht und größeren Wartungsaufwänden führen, oder auch zu längeren Durchlaufzeiten, weil die großen Bestände das System langsamer machen.
- Bewegung: Diese Verschwendungsart bezieht sich auf die Software-Ingenieure, die sich „in Bewegung“ befinden. Hierunter fällt zum Beispiel der allseits bekannte Klassiker, Informationen mühsam hinterherzulaufen, da es keine ganzheitliche Informationsquelle gibt.
- Warten: Auch das Gegenteil der dritten Verschwendungsart, das Warten, ist Verschwendung. Die Zeit, die ein Software-Ingenieur auf Arbeitsprodukte aus vorhergehenden Schritten, auf Informationen oder auf Freigaben wartet, trägt nicht zum Mehrwert für den Kunden bei.
- Transport: Diese Verschwendungsart ist der dritten ähnlich, nur dass sich hier das Arbeitsprodukt in Bewegung befindet. In der Testautomatisierung passiert dies beispielsweise, wenn Testfälle oder Schritte von A nach B kopiert werden, oder wenn ein komplexer Freigabeprozess durchlaufen werden muss. Auch der Transport von Testdaten auf die unterschiedlichen Testumgebungen fällt unter diese Verschwendungsart.
- Überprozessierung: Diese Verschwendungsart bezieht sich auf die fehlende Balance zwischen Aufwand und Wert eines Prozesses. Dies ist unter anderen der Fall, wenn der Fluss einer CI/CD-Pipeline durch aufwendige manuelle Freigaben unterbrochen wird.
- Fehler: Defects bringen dem Kunden eindeutig keinen Mehrwert und sind daher bekanntermaßen Verschwendung. Sie verursachen im Gegenteil sogar exponentiell steigende zusätzliche Kosten in ihrer Behebung je später sie gefunden werden, wie in der „Rule of Ten“ [Lig09] beschrieben
- Fehlallokation von Potenzial: Zusätzlich zu den sieben genannten Verschwendungsarten gibt es eine letzte, die besonders im skaliert agilen Kontext relevant ist: die Fehlallokation von Potenzial. Dies bezieht sich sowohl auf die Über- als auch die Unterforderung der Mitarbeiter, beispielsweise, wenn ein funktionaler Experte als Entwickler eingesetzt wird. Oftmals wird bei agilen Transformationen nämlich nicht beachtet, dass Mitarbeiter zunächst in der neuen Methodik und den neuen Werkzeugen geschult und in der neuen Organisation abgeholt werden müssen, damit sie ihr Potenzial voll einbringen können.
Der Quality Coach – die Rolle, die alle QS-Maßnahmen zusammenhält
Um aus dem großen Katalog der lean-agilen Methoden die passenden Methoden für die QS eines Unternehmens herauszusuchen und zu einem sinnvollen Paket zu schnüren, bedarf es tiefer Kenntnisse sowohl in den lean-agilen Prozessen als auch in der QS. Zusätzlich wird Erfahrung in den Bereichen Facilitation und Coaching benötigt.
Weiterhin gilt es zu beachten, dass die Rahmenbedingungen für die QS auf den verschiedenen Ebenen eines Unternehmens unterschiedlich sein können. Das agile Skalierungsframework SAFe® beispielsweise unterscheidet vier Ebenen, von der Teamebene, über Programm- hin zu Large Solutionsund Portfolio-Ebene. Da sich diese Ebenen in ihren Aufgaben zum Teil erheblich unterscheiden, ist es sinnvoll, für jede Ebene die Rolle des Quality Coach einzuführen.
Der Quality Coach ist verantwortlich für die Einführung, Begleitung und ständige Weiterentwicklung der lean-agilen QS-Maßnahmen auf seiner Projektebene, für das Coaching der Mitarbeiter in den Teams sowie der Führungsebene. Sein Ziel ist es, dass die richtigen QS-Maßnahmen zur richtigen Zeit eingesetzt werden und der Qualitätsgedanke jederzeit präsent ist. Der Quality Coach sorgt dafür, dass sämtliche Maßnahmen abgestimmt sind und alle Optimierungen in dieselbe Richtung laufen.
Prozessqualität, der „Hidden Champion“ auf dem Weg zu Business Agility
Zusammenfassend bleibt festzuhalten, dass skaliert-agile Projekte oft einhergehen mit komplexen Prozessen und Organisationsstrukturen sowie Hunderten Beteiligten. Speziell die QS sieht sich steigenden Herausforderungen gegenüber, ein übergreifendes, holistisches Qualitätskonzept zu entwickeln, welches sicherstellt, dass die Kunden zum richtigen Zeitpunkt Softwareprodukte erhalten, welche ihren Anforderungen und Wünschen entsprechen.
Lean Quality Management, mit seiner Integration von Methoden aus den Bereichen Lean und Agile, bietet sich für diese Art von Projekten als Lösung an. Speziell der Fokus auf die Verbesserung der Prozessqualität, welcher auf den Erfahrungen der Fertigungsindustrie aufbaut, hilft, die Komplexität der Prozesse zu reduzieren, Verschwendungen zu vermeiden, und somit die Liefergeschwindigkeit und Qualität der entwickelten Softwareprodukte zu steigern und somit Business Agility zu realisieren.
Damit sind die essenziellen Voraussetzungen für eine unternehmensweite Umsetzung von Business Agility erfüllt und die Weichen für eine erfolgreiche Transformation in die digitale Welt gestellt. Lean Agile Quality Management ist also eine entscheidende Fähigkeit, um in der aktuellen und zukünftigen Wirtschaftswelt eine führende Rolle übernehmen zu können.
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
[Ker19]
M. Kersten, Project to Product, IT Revolution PR, 2019
[Kom20]
A. Komus, M. Kuberg, Status Quo (Scaled) Agile 2020 Report, siehe:
https://www.process-and-project.net/studien/studienunterseiten/status-quo-scaled-agile-2020/
[Lar17]
C. Larmann, B. Vodde, Large-Scale Scrum – Scrum erfolgreich skalieren mit LeSS, dpunkt.verlag, 2017
[Lig09]
P. Liggesmeyer, Software-Qualität – Testen, Analysieren und Verifizieren von Software, Springer Spektrum, 2009
[Pop03]
M. und T. Poppendieck, Lean Software Development: An Agile Toolkit for Software Development Managers, Addison-Wesley Professional, 2003
