Agiles Arbeiten: Verbreitete Probleme in der Digitalisierung
In der Wirtschaft dürfte es mittlerweile kaum noch ein Unternehmen geben, das in der Softwareentwicklung nicht auf den agilen Werkzeugkasten setzt. Somit sollten wir uns am Wirtschaftsstandort Deutschland für die Digitalisierung bestens gerüstet sehen. Möglicherweise befinden wir uns aber in einem riskanten Zustand der Selbstzufriedenheit. Denn die agilen Frameworks werden häufig an die Organisationen angepasst, statt die Organisationen an Markterfordernisse anzupassen, die sich immer schneller ändern. Scrum beispielsweise – eigentlich ein Framework für die Entwicklung von Produkten in solchen Umfeldern – bleibt dadurch in der Praxis weitestgehend unwirksam. Aussagen der Art "Es geht ja nicht darum, möglichst schönes Scrum zu machen" oder auch "Scrum hat für uns nicht funktioniert" sind typisch für Umfelder, in denen die erhofften Ergebnisse ausgeblieben sind, weil die Implementierung unzureichend war. Hilfreich für die Suche nach Ursachen ist zunächst der Blick auf ein Verantwortungsmodell.
Agiles Arbeiten und Verantwortung
Agiles Arbeiten bedeutet unter anderem, dass möglichst viele Entscheidungen direkt dort getroffen werden, wo die Wertschöpfung stattfindet. Dazu sind vier Voraussetzungen erforderlich. Die Organisation muss für die entsprechende Beauftragung, das Sollen, sowie die Bevollmächtigung, das Dürfen, sorgen. Die Beauftragten müssen über die entsprechenden Kompetenzen, das Können, verfügen sowie zur Verantwortungsübernahme, das Wollen, bereit sein. Sind diese vier Aspekte gegeben, kann es schließlich zur Übernahme von Verantwortung kommen.
Befragt man Mitarbeiter, woran die Übernahme von Verantwortung am häufigsten scheitert, erhält man auffallend oft die Antwort: "am Dürfen". Im Folgenden schauen wir uns exemplarisch einige typische Problemfelder in Bezug auf agiles Arbeiten an und beginnen dabei mit dem reinen Dürfen.
Problemfeld Nutzerfeedback
Die heutigen Märkte sind voll von Produkten und Dienstleistungen, unter denen wir wählen können. Als Kunden sind wir dementsprechend anspruchsvoll. Für die Entwicklung neuer Produkte ist es deshalb essentiell, möglichst früh und regelmäßig prüfen zu können, ob die Zielgruppe auf das entstehende Produkt wie erhofft reagiert.
Ein Kernaspekt agilen Arbeitens besteht in regelmäßigen Lieferungen, um von den Nutzern Feedback einholen zu können. Scrum sieht hierfür Review-Meetings am Ende eines jeden Sprints vor. Fällt das Feedback der Nutzer anders aus als erwartet, kann das weitere Vorgehen angepasst oder die Arbeit komplett eingestellt werden. Dadurch wird das Risiko, viel Geld für ein nicht marktgängiges Produkt auszugeben, deutlich gesenkt.
In der Praxis findet man häufig Produktentwicklungsteams, die aufgrund von organisatorischen Hürden (Dürfen) nicht an die Anwender herankommen. Diese "Hürden" können Manager sein, die Entwicklern die Fähigkeit absprechen, mit Anwendern in Kontakt zu treten oder dem Team mit Verweis auf die Kosten verbieten, zu Kunden zu fahren. Das können Fachbereiche sein, die die Verantwortung, über Features zu entscheiden, bei sich selbst sehen. Das kann der Vertrieb sein, der es als sein Privileg betrachtet, im direkten Kundenkontakt zu stehen.
Übrig bleiben interne Reviews, in denen das Scrum-Team weitestgehend unter sich bleibt und mit internen Managern einen Pseudo-Erfolg feiert, weil man ja immerhin eine Hand voll User Stories auf die Testumgebung geliefert hat. In einer solchen Situation sollte die Organisation sich klar überlegen, ob die Risiken tragbar sind. Falls nein, sollte alles unternommen werden, dem Team zu ermöglichen, an direktes Kundenfeedback zu kommen.
Problemfeld Produktverantwortung
Von der Entwicklung eines Produktes sind zahlreiche Stakeholder betroffen, die alle ein nachvollziehbares Interesse daran haben, Ideen beisteuern oder auch mit entscheiden, welche davon umgesetzt werden sollen. Mit der ständig wachsenden Liste der zu entwickelnden Dinge steigt auch der Druck auf das Produktentwicklungsteam, möglichst schnell möglichst viel zu liefern. Das Risiko, dass sowohl die Nutzerzentrierung als auch die technische Qualität massiv beeinträchtigt werden und das Vorhaben scheitert, ist sehr groß.
Scrum hat mehrere Mechanismen eingebaut, die diesem verbreiteten Problem entgegenwirken sollen. Ein Product Owner ist verantwortlich für fünf entscheidende Punkte: das Stakeholdermanagement, die Maximierung des "Value", die Priorisierung des Product Backlog, für den Return on investment (ROI) und die Total Cost Of Ownership (TCO). All diese Mechanismen wirken der "Featuritis" entgegen.
Die Developer sind für die technische Qualität (Definition of Done) sowie die Schätzungen verantwortlich. Im Sprint Planning kommt ein Pull-Mechanismus zum Einsatz, der einer Überlastung der Entwickler und der Erosion der technischen Qualität entgegenwirkt.
Wer Verantwortung übernimmt, trifft auch die Entscheidungen. In der Praxis ist es jedoch häufig anders. Sowohl Product Owner als auch Developer sind durch die Organisation häufig nicht ausreichend bevollmächtigt (Dürfen). Den Scrum-Teams werden vom Management Releasepläne aufgezwungen, die darauf abzielen, möglichst viele Features zu einem festgelegten Zeitpunkt zu liefern und nicht auf zufriedene Anwender, maximalen Wert oder angemessene Codequalität.
Jede Organisation muss für sich entscheiden, ob sie Kenngrößen wie Wert für die Zielgruppen, zufriedene Anwender und angemessene Codequalität als wichtig erachtet. Falls ja, empfiehlt es sich, die Entscheidungen in Bezug auf die Produktentwicklung (wirtschaftlich, technisch, prozessual) im Scrum-Team zu zentralisieren. Das ist nur möglich, wenn das Team geeignet besetzt (Können) ist und die Organisation voll hinter dem Team und agilem Arbeiten steht (Sollen und Dürfen).
Problemfeld Ziele
So wichtig Ziele sind, so schwierig ist es, geeignete Zielsysteme aufzusetzen. In der Praxis kommt es vor, dass die Ziele für verschiedene Individuen nicht zueinander passen oder gemeinschaftlich erarbeitete, als sinnvoll erachtete und realistische Ziele schlicht fehlen. Dies führt zu Konflikten und Leistungsverlusten.
Wie wichtig aneinander ausgerichtete Ziele sind, zeigt sich auch in Scrum. Hier findet sich ein kaskadiertes Zielsystem mit dem (strategischen) Produktziel, dem (taktischen) Sprintziel und letztlich den Product Backlog Items, die jeweils darauf abzielen, Wert für die Nutzer zu schaffen.
In der Praxis zeigt sich häufig, dass das mit den Zielen gar nicht so einfach ist. Noch immer werden die Produkte häufig mit übergeordneten, klassisch output-getriebenen Meilensteinplänen gesteuert, die das Arbeiten mit einem Produktziel hinfällig machen. Die Sprints sind dann häufig ebenso output-getrieben, so dass Sprintziele der Art "Ticket A, B, D und G sind fertiggestellt" üblich sind.
In solchen Fällen muss die Organisation zuerst lernen, wie sie zu einer strategischen Ausrichtung und dazu passenden Zielen kommt und wie man dabei Zielkonflikte für die Mitarbeiter vermeidet. Solange sich die Organisation gezwungen sieht, irgendwo steuernd eingreifen zu müssen ("Micromangement"), sind die vorstehenden Aufgaben vermutlich noch nicht zufriedenstellend gelöst.
Problemfeld regelmäßige Lieferung
Die Entwicklung neuer Produkte, speziell wenn Software im Spiel ist, ist teuer und risikobehaftet. Die Risiken sind umso größer, je länger es dauert, bis etwas Gebrauchsfähiges entstanden ist. Das gilt besonders für klassisch durchgeführte Projekte, bei denen nach langer Laufzeit erst ganz am Ende eine Lieferung steht.
Agiles Arbeiten zielt darauf ab, möglichst früh und regelmäßig lauffähige und wertvolle Software zu liefern. Scrum forciert das und verlangt am Ende eines jeden Sprints die Lieferung eines nutz- bzw. auslieferbaren Inkrementes. Dadurch werden verschiedene Risiken auf ein überschaubares Maß reduziert.
Noch immer gibt es jedoch viele Scrum-Implementierungen, in denen es nicht gelingt, am Ende der Sprints eine Lieferung zur Verfügung zu stellen. Die Gründe dafür können vielfältig sein. Möglicherweise hat das Team noch nicht die nötigen technischen Fertigkeiten entwickelt (Können) oder die Organisation hat für das Team noch nicht alle nötigen Rahmenbedingungen geschaffen (Dürfen). Häufig ist auch zu beobachten, dass die Beteiligten es aufgegeben haben, auf eine Verbesserung ihrer Lieferfähigkeit hinzuarbeiten, wenn sie bereits mehrfach an organisatorischen Hürden (wie beispielsweise der Testabteilung oder dem Betrieb) gescheitert sind.
Solange ein Team nicht lieferfähig ist, geht die Organisation extrem hohe Risiken ein. Sollen die Risiken reduziert werden, muss die Organisation mit dem Team zusammenarbeiten und ihm die benötigte Unterstützung zur Verfügung stellen. Dabei kann es genauso um den Aufbau von Wissen innerhalb des Teams (Können) gehen, wie um organisatorische Änderungen (Dürfen).
Problemfeld Produktschnitte
Die meisten Produktschnitte sind kompromissbehaftet, denn es gibt kein Patentrezept für das Schneiden von Produkten.
Recht klein geschnittene Produkte, denen genau ein Scrum-Team zugeordnet ist, folgen der Erkenntnis, dass ein Team eine bestimmte Größe nicht übersteigen sollte. Ein damit häufig einhergehender Nachteil ist, dass einzelne Teams ohne Zulieferung anderer "Produktteams" keinen Value liefern können. Die Product Owner müssen entweder ihre Product Backlogs regelmäßig aufeinander abstimmen, wodurch sie allein keine Produktentscheidungen mehr treffen können, oder die Lieferung von brauchbarer Funktionalität an die Zielgruppe dauert sehr lange, da sich die Teams durch Abhängigkeiten und lange Liegezeiten gegenseitig ausbremsen.
Ein anderes Extrem sind zu groß geschnittene Produkte, in denen alle, die irgendwie etwas mit dem Produkt zu tun haben, sich als ein einziges großes Scrum-Team verstehen. Die Scrum-Events liefern nicht mehr die benötigten Ergebnisse, die Teammitglieder verwenden mehr Zeit auf Meetings als auf das direkte Arbeiten am Produkt und alle haben den Eindruck, dass es irgendwie nicht so richtig vorwärts geht.
Scrum ist ein Framework, um Produkte im regelmäßigen Anwenderkontakt effektiv und effizient zu entwickeln. Teams sollten die übliche Größe nicht überschreiten und über alle Skills verfügen, um spätestens am Ende eines jeden Sprints ein wertvolles Produktinkrement ausliefern und Feedback von den Anwendern einholen zu können. Scrum gibt somit zwar nicht explizit, aber implizit einige Hinweise darauf, wie Produkte geschnitten sein sollten.
Alle Scrum-Teams sollten ihre Produkte, Produktschnitte, ihre interne Strukturierung und ihre Prozesse immer wieder kritisch hinterfragen und gegebenenfalls anpassen (Können und Dürfen).
Problemfeld Abteilungsgrenzen
In der Industrialisierung war es essentiell, Massengüter möglichst günstig herstellen zu können. Sobald ein Produkt definiert war, konnten die Arbeitsabläufe permanent optimiert werden. Spezialisierung, Arbeitsteilung und Fließfertigung garantierten bestmögliche Auslastung und höchstmöglichen Durchsatz. Auch die übrigen Strukturen und Prozesse in den Unternehmen wurden dementsprechend optimiert. Sie wurden aber nicht dazu geschaffen, kreativ und schnell neuartige Produkte am Markt zu verproben. Diese Fähigkeit wird jedoch immer wichtiger.
Scrum als Framework für die Entwicklung neuer Produkte in komplexen Umfeldern setzt auf kleine, interdisziplinär besetzte Teams, die möglichst wenige Abhängigkeiten in andere Organisationsabteilungen aufweisen und in direktem Kundenkontakt stehen. Ziel ist es, mit möglichst geringen Risiken ein Produkt zu entwickeln, das den Anforderungen der Zielgruppe bestmöglich gerecht wird. Während klassisches Effizienzdenken primär Kosteneinsparungen zum Ziel hat, zielt agiles Arbeiten darauf ab, das Verhältnis aus Kosten und Einnahmen zu optimieren (Return on investment).
In der Praxis können die wenigsten Scrum-Teams so arbeiten, wie es gedacht ist. Ganze Abteilungen (Fachbereiche, Business- Analysten, Vertrieb, Testing Department, …) sehen sich durch interdisziplinär besetzte Teams mit direktem Kundenkontakt in ihrem Selbstverständnis bedroht. Wer sich bislang, beispielsweise in Bezug auf Strategie oder Businessmetriken, nicht "in die Karten schauen lassen" musste, wird sich mit der Transparenz, die für agile Teams selbstverständlich ist, genauso schwer tun wie mit den Entscheidungen, die ein Product Owner trifft. Oft genug stehen darüber hinaus Zielvereinbarungen und Bonussysteme einer marktorientierten Produktentwicklung im Wege.
All das führt zu zahlreichen Widerständen und Anpassungen. Die Testabteilung legt nachvollziehbar dar, dass sie nach jedem Sprint Ende-zu-Ende-Tests schreiben sollte. Der Fachbereich verlangt, dass er darüber entscheiden darf, wann etwas fertig ist und an die Kunden geliefert werden kann. Zahlreiche Manager versuchen, ihre Ideen durchzusetzen, da sie die Wahrscheinlichkeit steigern wollen, ihre Jahresziele zu erreichen. Agiles Arbeiten ist in einem solchen Umfeld zumindest stark behindert (Dürfen).
Agiles Arbeiten ist ohne Beauftragung (Sollen) und Bevollmächtigung (Dürfen) nicht möglich. Eine Organisation, die ihre Innovationskraft stärken möchte, muss das durch aktive Unterstützung zum Ausdruck bringen. Sowohl das Sollen als auch das Dürfen muss immer wieder neu verpackt auf verschiedenen Kanälen kommuniziert werden.
Problemfeld Aufbau agiler Kompetenz
Es ist extrem herausfordernd, in den heutigen Märkten zu bestehen. Es gilt, neue Erkenntnisse schnell und gezielt (statt ad hoc und unstrukturiert) in die Produktentwicklung einfließen zu lassen. Der Scrum-Guide liefert dazu auf wenigen Seiten die essentiellen Eckpfeiler. Den Organisationen fehlt jedoch das Wissen darüber, wie man das Werkzeug in der Praxis einsetzt und dadurch die Erfolgsaussichten steigert.
In der Praxis werden Scrum Master häufig als Moderatoren, Dienstmädchen und Feelgood-Manager verstanden.
Der Scrum Master hat Scrum am besten verinnerlicht und weiß, wie man das Framework zielgerichtet einsetzt. Das betrifft einerseits die Zusammenarbeit innerhalb des Scrum-Teams, andererseits dessen Zusammenarbeit mit den Stakeholdern und die Einbettung in die Organisation. In der Praxis werden Scrum Master häufig als Moderatoren, Dienstmädchen und Feelgood-Manager verstanden. Da dies offensichtlich keine Vollzeitstelle ist, müssen sie zwei bis vier Produktentwicklungsteams übernehmen und können schließlich keine Wirkung mehr entfalten (Dürfen). Andererseits stellen starke Scrum Master häufig frustriert fest, dass die Organisationen gar nicht agil arbeiten möchten (Wollen) und ihn in der Folge nicht seine Arbeit machen lassen (Dürfen).
Organisationen, die agil arbeiten möchten, müssen dazu sehr viele Dinge ändern. Da agiles Arbeiten für viele Organisationen absolutes Neuland ist, müssen sie sich klar dafür oder dagegen entscheiden (Sollen), das nötige Wissen ins Haus holen (Können), sich auf einen lang anhaltenden Änderungsprozess einstellen (Wollen) und denjenigen, die agil arbeiten wollen, die dazu benötigte Vollmacht erteilen (Dürfen).
Problemfeld Hybridmodelle
Aus dem Vermengen tradierter Projektsteuerung mit agilen Vorgehensmodellen resultieren unlösbare Konflikte. Denn die Aktivitäten eines Projektleiters kollidieren unmittelbar mit den drei Verantwortlichkeiten eines Scrum-Teams. So wird beispielsweise ein Projektleiter an anderen Zielen (wie Output) gemessen als ein Product Owner (beispielsweise Outcome und ROI). Zudem ist im klassischen Projektmanagement der Scope, in der agilen Produktentwicklung eine angemessene Qualität, unverhandelbar.
Scrum als Framework beschreibt, wie man nutzerorientierte Produkte in komplexen Umfeldern entwickeln und dabei die Risiken minimieren kann. Dabei geht es sowohl um Effektivität ("die richtigen Dinge…") als auch Effizienz ("…richtig tun").
In der Praxis finden sich zahllose Hybridmodelle. Ein vermeintliches Scrum-Team entwickelt, die Testabteilung testet, ausschließlich der Vertrieb steht im Kundenkontakt und der Projektleiter berichtet dem Lenkungsausschuss den Projektstatus in Form von Gantt-Diagrammen und Status-Ampeln. Durch die klaren Verantwortlichkeiten in Scrum sind Konflikte vorprogrammiert.
Jede Organisation sollte sich klar entweder für klassisches Projektmanagement oder agile Produktentwicklung entscheiden (Sollen). Im Falle agiler Vorgehensmodelle ist die Auswahl geeigneter Mitarbeiter genauso essentiell wie deren beständige Weiterentwicklung (Wollen und Können). Sofern es um mehr als ein einziges Produkt geht, sollte sowohl die Ablauforganisation als auch die Aufbauorganisation (Dürfen) maßgeblich von Menschen entwickelt werden, die über profunde Kenntnisse in Bezug auf agiles Arbeiten verfügen.
Problemfeld Skalierung
Die Unternehmen stehen insbesondere unter den Auswirkungen der jüngsten Pandemie unter großem Druck, die Digitalisierungsversäumnisse der Vergangenheit möglichst schnell nachzuholen. Intuitiv wird versucht, die "Kapa" zu erhöhen, um mit mehr Menschen mehr Ergebnis zu generieren.
Für skalierte Umfelder gibt es keine Patentrezepte. Für zu große Produktteams gilt die Empfehlung, sich selbst aufzuteilen, die Entwickler in mehreren einzelnen Teams zu organisieren und dabei an einem zentralen Product Owner, Product Goal und Product Backlog festzuhalten. Ab drei Scrum-Teams empfiehlt sich zudem Nexus als Skalierungsframework.
In der Praxis liefern skalierte Umgebungen selten den erhofften Nutzen. Während die Kosten hoch sind und die Ergebnisse weit hinter den Erwartungen zurückbleiben, werden gewaltige, kaum mehr beherrschbare Probleme sichtbar. Denn die Skalierung erfolgt typischerweise in einem Stadium, in dem weder die Teams noch deren Umfeld die nötige Reife (Mindset, Technisch, Fachlich, Prozessual) aufweisen. Die zahlreichen vorher schon vorhandenen Probleme treten jetzt unübersehbar in den Vordergrund und die organisatorische Komplexität nimmt weiter zu.
Da eine Skalierung immer Performanz kostet, sollte zuerst geprüft werden, ob die Skalierung wirtschaftlich überhaupt sinnvoll ist (Sollen). Sehr viele Ziele lassen sich mit kleinen, gut ausgebildeten Teams deutlich besser erreichen als mit unreifen großen. Falls eine Skalierung dennoch geboten scheint, sollte zuerst geprüft werden, ob eine Skalierung überhaupt Aussicht auf Erfolg hat (Können), denn agiles Arbeiten lässt sich nicht von heute auf morgen erlernen. Eine begonnene Skalierung sollte anhand zuvor festgelegter Kernmetriken rechtzeitig abgebrochen werden, wenn die Metriken nicht den Sollwerten entsprechen.
Eine Organisation, die die Erfolgsaussichten steigern möchte, sollte zuerst darauf setzen, kompetente agile Teams und eine dazu passende Umgebung auszubilden (Sollen, Dürfen, Können und Wollen).
Zusammenfassung
Der Wirtschaftsstandort Deutschland kann in der Digitalisierung aufholen, wenn die Rahmenbedingungen für wirksames agiles Arbeiten geschaffen werden. Ob sich die erhofften Ergebnisse einstellen können, hängt wesentlich davon ab, ob die Scrum-Teams Verantwortung übernehmen Sollen, Dürfen, Können und Wollen. Anhand der vorstehenden Beispiele wird klar, dass dafür organisatorische Änderungen nötig sind. Wirksames agiles Arbeiten ist daher nur dann möglich, wenn auch im Management das nötige Sollen, Dürfen, Können und Wollen vorhanden ist.
