Erst die Menschen, dann die Methode Agile Entwicklung mit Scrum im Konzern
Agile Entwicklung ist inzwischen auch in den IT-Abteilungen deutscher Konzerne angekommen. Was vielerorts als Graswurzelbewegung begann, hat sich zum Erfolgsprojekt entwickelt. Was Unternehmen über Scrum im Konzernumfeld wissen sollten.
Anbieter zum Thema

Für Start-Ups und KMUs ist agile Entwicklung eine etablierte Art und Weise, komplexe Projekte zum Erfolg zu führen. Ganz anders im Konzernumfeld: Aufgrund gewachsener Organisationsstrukturen wird es oft zur Herausforderung, agile Methoden einzusetzen und langfristig zu etablieren. „Wenn du es vergeigen willst, führ es als Methode ein! Willst du erfolgreich sein, begeistere die Menschen“, heißt es.
Schaffen Verantwortliche die notwendigen Freiräume, können agile Methoden Dinge bewirken, die herkömmliches Projekt-Management nicht erreicht: Zum Beispiel den Turnaround eines verloren geglaubten Projektes, ungewöhnlich hohe Effizienzsteigerungen oder eine höhere Qualität des im Projekt entstandenen Produktes. Die Spielregeln für Scrum sind die gleichen, die Rahmenbedingungen und Erfolgsfaktoren unterscheiden sich allerdings wesentlich.
Individuelle Regelungen sind das A und O
Gerade Softwareprojekte werden oft konzernweit aufgesetzt, was schnell zu einer Flut an Abstimmungsbedarf führt. Sich innerhalb der einzelnen Bereiche, Marken und Gesellschaften auf einen gemeinsamen Prozess zu verständigen, ist ohnehin schon schwer genug.
Für agile Projekte stellen sich hier zusätzliche Herausforderungen: Häufig ist es die Aufgabe von Steuerkreisen, die gewünschten Einigungen über die Instanzen hinweg zu erzielen. Aus Sicht der agilen Entwicklungen gilt es, innerhalb dieser Steuerkreise Prozessgestalter – und letztlich Product Owner – zu finden, die ihre Verantwortung auch Instanz übergreifend ausüben. Für eine bestimmte Lieferstufe hat dann beispielsweise eine Marke oder Gesellschaft den Hut auf.
Über den eigentlichen Scrum-Prozess hinaus sind eine Menge Regelungen notwendig, die der Scrum Guide nicht abdeckt und die in einem Start-Up im gleichen Ausmaß wohl unnötig wären. Hier bildet Scrum den Container für weitere Techniken, Methoden und Praktiken. Es muss dabei immer ein geschützter Raum für die Methode geschaffen werden, sonst bleibt der agile Nutzen aus.
Warum Scrum scheitert
Scrum ist kein optionales Angebot an Einzelpraktiken, sondern entfaltet seine volle Effektivitätssteigerung nur im Zusammenspiel aller definierten Elemente. Das Weglassen einzelner Bausteine ist einer der häufigsten Gründe, warum eine Scrum-Einführung scheitert.
Diese Harmonisierung ist eine wichtige Voraussetzung für ein agiles Projekt. Wenn ein entsprechendes Commitment aus dem Steuerkreis heraus nicht gegeben werden kann, fehlen automatisch wichtige Rahmenbedingungen. Das Projekt ist einfach nicht agil abzuwickeln; denn es wäre von Anfang an zum Scheitern verurteilt.
Scrum ist „in“, also gibt es seitens der Verantwortlichen Tendenzen, alles agil abzubilden. Das funktioniert jedoch nur, wenn sich auf Nutzerseite ein Gestalter findet, der bereit ist, das Mandat zu übernehmen. Daraus resultiert dann auch gleich die nächste Frage: Bekommt dieser Gestalter von seinen Vorgesetzten auch die Zeit und die Ressourcen, das agile Projekt zu betreuen?
Gestalter aus dem Fachbereich gefragt
In vielen Fällen verfügen die Fachbereiche lediglich über hauchdünne Kapazitäten für einzelne Projekte. Oftmals setzt sich schon mit Projektstart eine Self-fulfilling Prophecy in Gang: Das Projekt wird zwar komplett ausformuliert und zum Kick-off gebracht, dann ist drei Jahre lang „Sendepause“ und bei Lieferung gibt es ein riesiges Gap zwischen den aktuellen Anforderungen, dem Bestellten und dem Gelieferten. Dieser Umstand treibt die kurzfristige Arbeitsauslastung der Projektteams kurz vor Schluss exponentiell in die Höhe, da oft nur unter Einsatz von Überstunden und Wochenendarbeit nachzubessern ist – wenn überhaupt.
Eine der wichtigsten Rahmenparameter lautet also: die Beteiligung der Auftraggeber-Seite sicherstellen. Es ist viel erfolgversprechender, von Anfang an nur die Projekte zu starten, die eine ausreichende Betreuung aus dem Fachbereich haben und bei dem der entsprechende Verantwortliche auch bereit ist, Teil des Projektteams zu werden. Damit einher geht ein Umdenken der Fachbereiche: Sie müssen lernen, initiale Anforderungsumfänge flexibel zu verhandeln.
Der Erfolg eines Projektes liegt nicht darin, dass stur alle 1001 Anforderungen, die für das erste Jahr der Laufzeit beschrieben wurden, erfüllt sind. Vielmehr zählt der zentrale Business-Wert: An diesem als Produktvision formulierten Wert muss sich jede Einzelanforderung messen lassen – sie wird entweder priorisiert und umgesetzt oder kann sogar aus dem Anforderungskatalog gestrichen werden, wenn die Priorität zu gering ist.
Der Mensch macht den Unterschied
Um auf Änderungen des Marktes reagieren zu können, bedeutet „agile“ auch, einen dauerhaften Planungsprozess zu durchlaufen, stets mit dem Blick auf das nächst Wichtige. Die offene Nutzen-Kommunikation befähigt die Teams, dem Auftraggeber aktiv Feedback zu geben, beispielsweise zu überflüssigen Details oder Fehlern in der Anforderung. Im Gegensatz zum klassischen Projekt-Management, wo Teams lediglich eine ausführende Rolle übernehmen, leisten sie im Scrum als Gestalter ihren Beitrag zu einer schlanken und hochwertigen Lösung.
Scrum ist letztlich auch nur ein Prozess, auch wenn sich dahinter die Option verbirgt, agil zu werden. Im Zentrum steht die Interaktion von Menschen – und im besten Fall echter Teams. Das ritualisierte Abspulen von Scrum macht noch kein agiles Projekt aus. Es geht um Werte wie Transparenz, Authentizität, Vertrauen und Verantwortung. Eben jene Werte, die auch im Team Building eine zentrale Rolle spielen. Eine Vielzahl von Scrum-Teams hat darüber hinaus nicht mit der Methode zu kämpfen, sondern mit dem Rollenverständnis.
Scrum suggeriert: Es ist einfach. Allerdings reicht es eben doch nicht, den Scrum Guide mal nebenbei in einer halben Stunde zu lesen und sich dazu ein Youtube-Video anzuschauen. Denn die Schlüsselfragen sind dort nicht beantwortet: Wie führe ich Scrum ein und wie bekomme ich das mit den Werten und dem Team Building hin?
Für das Konzernumfeld spielt in diesem Kontext stark die Zusammenarbeit mit Lieferanten hinein: Trotz Gewerken und rechtlicher Rahmenbedingungen müssen die Projektverantwortlichen einen Weg finden, ein Auftraggeber-/Auftragnehmer-Verhältnis zu etablieren und funktionierende Teams zu bauen. Das muss jedes Unternehmen individuell für sich ausgestalten. Wer das nicht tut, wird bei einer Scrum-Einführung scheitern.
Wahre Wunder
Funktioniert das Team, lassen sich mit agiler Entwicklung wahre Wunder wirken. Beispielsweise spart ein über lange Jahre gut eingespieltes Entwickler-Team aus dem Automobil-Umfeld fortan komplette zwei Wochen Testing im Ausland: Nach Umstellung auf Scrum ist die Qualität seiner Arbeit so stark gestiegen, dass die Tester keinen einzigen Fehler entdeckten.
Solche Ergebnisse sind nicht nur ein eindeutiger Effizienzgewinn, sie motivieren auch ungemein. Damit es zu solchen Erfolgen kommt, muss das Umfeld stimmen, in dem das Team arbeitet.
Das sind die Voraussetzungen
Zunächst die Ausbildung: Alle Teammitglieder müssen hervorragend in der agilen Methode geschult sein. Dazu kommt im besten Fall noch einmal die eingehende Betreuung durch einen zertifizierten Scrum-Master in den ersten Phasen des Projektes. Volkswagen hat dazu beispielsweise über 150 Scrum Professionals in 2016 ausgebildet, die agile Projekte in allen Phasen betreuen.
Außerdem müssen alle Teammitglieder im selben Boot fahren. Einer der größten Fehler, den Verantwortliche bei der Scrum-Einführung machen können, ist die Methode Top-Down einzuführen. So laufen sie Gefahr, dass das Team nach dem Überwinden kritischer Phasen sofort wieder in alte Muster zurück fällt.
Räumliche Trennung ist gerade für die ersten Phasen eines Projektes Gift. Menschen müssen miteinander sprechen, gerade wenn es auf wirkliche Teamarbeit ankommt. Das gilt besonders für Teams, die nur über einen begrenzten Zeitraum eng zusammenarbeiten. Wenn das nicht möglich ist, sollte wenigstens eine sehr gute Collaboration-Infrastruktur vorhanden sein.
Fehler zulassen und daraus lernen
Scrum fordert lückenlose Transparenz, sonst funktioniert die Methode nicht. Das impliziert zwingend eine offene Fehlerkultur, und genau an dieser Stelle ist das Management gefragt: Es muss die Bedingungen dafür schaffen, dass Fehler schnell auf den Tisch kommen und zu einer frühen Entscheidung führen. Herkömmliches Projekt-Management im Konzernumfeld setzt stark auf späte Controls und sucht nach „Schuldigen“.
In Scrum führt das zu nichts. Es geht vielmehr darum, die Verantwortlichen für Qualität, Architektur usw. früh in das Anforderungs-Management zu integrieren und ihre kritischen Themen als Akzeptanzkriterien für ein auslieferbares Produkt zu definieren. Während des gesamten Projektes gilt es, frühzeitig Fehler auszumachen und in einem kontinuierlichen Verbesserungsprozess im Team zu klären, wie es immer noch ein Stück besser geht.
Die Erfolgsaussichten sind dann um ein vielfaches größer. Effizienz erfordert unter diesen Vorzeichen allerdings auch klare Entscheidungen: Performt ein Team nach sechs Sprints beispielsweise nicht, müssen die Verantwortlichen auch den Schneid haben, das Projekt neu aufzusetzen oder sogar abzubrechen.
Der Kulturwandel braucht Zeit
Transparenz und Offenheit einer Scrum-Kultur lassen sich im Konzernumfeld nicht einfach einimpfen. Wie das Entwickeln einer jeden Unternehmenskultur braucht es Zeit, bis der Wandel nicht nur in kleinen Einheiten sondern in der gesamten Organisation zu spüren ist – je nach Struktur und Status zehn bis fünfzehn Jahre.
Start-Ups haben es da leicht: Das Scrum-Team ist häufig schon beim Einstellungsprozess neuer Mitarbeiter dabei. Wer nicht scrumt, darf dann schnell wieder gehen. Das funktioniert im Konzern natürlich nicht.
Scrum ist auf das Erschaffen und den Erhalt komplexer Produkte ausgelegt. Es bringt allerdings immer ein gewisses Risiko mit sich, komplexe Probleme zu lösen. Verteilt auf alle Schultern lässt sich die Verantwortung dafür viel besser übernehmen. Das ist ein wichtiger Change-Prozess mit vielen Chancen für alle Beteiligten.
Das Management ins Boot holen
Agile Entwicklung muss immer heißen: Die Beteiligten wollen! Das gilt auch für das Management. Da kann es konzernweit eine noch so gut vernetzte Entwickler-Community mit höchster Transparenz geben: Sind die Führungskräfte, die ja immerhin Ergebnisverantwortung haben, nicht entsprechend eingebunden, tun sich mitunter Gräben zwischen „alter und neuer Welt“ auf.
Offene Kommunikation ist der Schlüssel zum besseren Verständnis. Es geht schließlich nicht nur darum, eine Duldung von Scrum zu erreichen, sondern eine komplette Akzeptanz. Agile Entwicklung kann nur dann erfolgreich sein, wenn Manager mit den richtigen Mindsets gute Rahmenbedingungen dafür schaffen.
* Stefan Waschk ist Scrum-Experte und einer der Initiatoren der agilen Entwicklung bei Volkswagen. Was 2009 in kleinen Projekten begann, hat sich heute zu einer lebendigen Community entwickelt. Allein mehr als 150 Scrum Professionals sind heute im „agilen“ Einsatz.
(ID:44404810)