In vielen kleineren Unternehmen, IT-Beratungen, Abteilungen und Teams ist das Thema "Agilität" bereits fest etabliert. Vor allem in größeren Unternehmen, vom Mittelständler bis zum Weltkonzern, hadert die Unternehmensführung teils noch mit der Implementierung agiler Methoden. Denn je mehr Mitarbeiter involviert sind und je stärker die Wechselwirkungen, welche sich mit anderen Abteilungen ergeben, desto komplexer gestaltet sich der Wandel hin zur agilen Kultur. Die Resultate der agilen Teams betreffen auch alle anderen Fachbereiche - denn beispielsweise sind Forschung und Entwicklung, Personal oder auch Marketing von der Verfügbarkeit einer IT-Lösung abhängig. CIOs sowie die höhere Management-Ebene müssen den "Tunnelblick" über die IT hinweg öffnen und sich auf einen Kulturwandel im gesamten Unternehmen einstellen.
Foto: qoppi - shutterstock.com
Agile Methoden in der Softwareentwicklung
Aber alles von Beginn an: Noch vor fünfzehn Jahren hätte kaum jemand damit gerechnet, wie die Arbeitswelt sich in der IT-Branche verändern würde. Während die vorab definierte Softwarearchitektur damals noch wie eine "Bibel" war, an die sich Entwickler streng halten mussten, entsteht Software heute in einem agilen Prozess. Dieser ermöglicht es, ein Produkt zu entwickeln, das den Bedürfnissen der Anwender im hier und jetzt wirklich gerecht wird. Denn sonst kann es vorkommen, dass nach langem Spezifizieren und Festlegen ein Produkt entsteht, welches gestern noch gewollt und gebraucht wurde; welches aber bei der Fertigstellung schon wieder überholt ist.
Agile Methoden wie Scrum und Kanban stellen Softwareentwicklern ein Modell bereit, mit dem sie ihre Fortschritte in hoher Granularität überprüfen, evaluieren und anpassen können. Dabei handelt es sich keinesfalls um bloße Deregulation oder "geplantes Chaos". Die agilen Methoden unterscheiden sich von bestimmten Ansätzen her, haben jedoch die folgenden Punkte gemeinsam: Sie sind "lean" (schlank) und "agil" (wendig); setzen ein "Pull-System" voraus, bei dem jedes Team-Mitglied sich neue Aufgaben selbstständig abholt; begrenzen die Anzahl der aktuell zu bearbeitenden Aufgaben; fokussieren sich darauf, release-fähige Software-Inkremente in vordefinierten Arbeitsschritten ("Sprints") auszuliefern; basieren auf selbstorganisierten Teams mit flachen Hierarchien; evaluieren den Releaseplan anhand der Auswertung empirischer Daten wie beispielsweise der durchschnittlichen Teamgeschwindigkeit. Damit handelt es sich bei den agilen Methoden um eine hochstrukturierte, aber gleichzeitig elastische Vorgehensweise.
Vorteile agiler Methoden in der Unternehmens-IT
Agilität ist in Zeiten der rasanten Entwicklung von IT-Systemen eine bloße Notwendigkeit. Gemäß dem Moore'schen Gesetz steigt nicht nur die Leistungsfähigkeit der Schaltkreise laufend, sondern auch die Anforderungen an die Software-Frameworks. Zudem treten gerade in jüngerer Zeit immer neue Anbieter von disruptiver Software-as-a-Service (SaaS) auf. Dies bedeutet, dass eine Software-Lösung, die gestern noch mit hohem Aufwand selbst entwickelt werden musste, heute schon zu einem Bruchteil der Kosten eingekauft werden kann. Es muss daher stets von neuem hinterfragt werden, welche Art von Funktionalität entwickelt, in welche Schnittstelle sie eingebettet und welche Anforderungen von ihr erfüllt werden soll. Wer auf die zukünftigen Paradigmenwechsel in der IT-Branche gewappnet sein und ihr Potenzial voll ausschöpfen will, kommt um agile Methoden daher eigentlich nicht mehr herum.
Die Vorteile dieser Vorgehensweise liegen auf Hand: Das Risiko, dass ein Projekt fehlschlägt, verringert sich enorm. Denn regelmäßige Abnahmen und Tests, wie sie die agilen Methoden vorschreiben, sorgen für eine hohe Transparenz im Projektverlauf. Hierdurch sind Entscheider immer im Bilde, ob sie die Anforderungen an das Projekt modifizieren und Ressourcen hinzufügen beziehungsweise abziehen sollen. Insbesondere verringert sich die Time-to-Market des Projekts, denn noch während der Entwicklung können Anwender schon auf fertiggestellte Teilfunktionen zurückgreifen. Das fertige Produkt ist stabil, vielfach getestet und entspricht den aktuellen Anforderungen, die sich aus der IT-Landschaft und den Wünschen der Anwender ergeben.
Erprobte Modelle für die Skalierung von Agilität
Die agilen Methoden der ersten Generation wie Scrum und Kanban waren vor allem auf die Implementierung in überschaubaren Teams gemünzt. Die Methode Scrum kennt lediglich drei feste Rollen für die Beteiligten (Product Owner, Scrum Master, Team Member). Während es noch ersichtlich ist, dass solche relativ autonomen Strukturen auf diesem Basisniveau gut funktionieren können, stellt sich die Frage nach der Praktikabilität auf dem Niveau von mehreren hundert oder sogar tausend Mitarbeitern. In der Praxis haben sich hierfür bereits einige übergeordnete Modelle bewährt, die im Folgenden kurz vorgestellt werden.
Nexus Framework: Das Nexus Framework stellt eine Art "Exoskelett" dar, das zwischen drei bis neun Scrum-Teams vermittelt. Es gibt nur ein gemeinsames Backlog, auf dessen Basis ein integriertes Inkrement erstellt wird. Um Abhängigkeiten so gering wie möglich zu halten, wird das Nexus Backlog in so kleine Teile wie möglich aufgeteilt und diejenigen, welche die größte Abhängigkeit erzeugen, priorisiert behandelt.
Large Scale Scrum (LeSS): Der LeSS-Ansatz bildet die Scrum-Methode auf größere Organisationen ab, indem das Entwicklungs-Team einfach "vergrößert" wird. Ganze Teams nehmen die Rolle ein, die zuvor der einzelne Mitarbeiter hatte. Grundsätzlich gibt es nur einen Product Owner, egal wie groß das Team ist. Bei der Sprint-Planung sind alle Teams anwesend, unter Umständen auch nur Stellvertreter. Hier werden die einzelnen Aufgaben nach der Reihenfolge des Backlogs unter den Teams verteilt. In sehr großen Projekten lässt sich die starke Zuspitzung auf einen Product Owner vermeiden, indem die Funktionalität des Produkts auf verschiedene Bereiche mit einem jeweils eigenen Product Owner aufgeteilt wird. Somit lässt sich eine mittlere Ebene hinzufügen.
Scaled Agile Framework (SAFe): Dieses Modell unterscheidet die drei Ebenen Portfolio, Programm und Team. Auf der Portfolio-Ebene sind alle strategischen Themen wie Investment und Governance angesiedelt. Auf der mittleren Programm-Ebene sorgt der "Agile Release Train" für eine enge Verzahnung von strategischer und operativer Ebene, beispielsweise bei der Frage, wann ein Produkt oder einer seiner Bestandteile bereit für die Auslieferung sind. Auf der Team-Ebene finden schließlich die bekannten Methoden ihren Niederschlag.
An dieser Stelle kann nur ein grober Überblick über Vielzahl der einzelnen Methoden gegeben werden. Weitere Angebote sind der Agile Scaling Cycle oder die Spotify-Methode. Es ist je nach Anwendungsfall zu entscheiden, welches Framework am besten zu den Anforderungen des Unternehmens passt. SAFe beispielsweise setzt auf einer sehr hohen Ebene an und ist dann erforderlich, wenn die Software- und IT-Entwicklung tatsächlich auch eine strategische Bedeutung für das Unternehmen einnimmt. Je nach Organisationsanforderungen und -kultur sind die diejenigen Frameworks einzurichten, die am besten zu ihnen passen. Prinzipiell gilt die Faustregel: So viel Freiheit wie möglich, so wenig Regeln wie nötig. Zumeist kann der Idealfall aber aufgrund von externen Faktoren nicht umgesetzt werden, weshalb Modelle mit komplexeren Regelwerken auch ihre Berechtigung haben. Skalierung findet zudem auf der horizontalen (mehr Teams, Mitarbeiter, etc.) wie auch vertikalen Ebene (mehr Aufgaben, Verantwortung, Vertiefung in der Wertschöpfungskette, etc.) statt. Externe Berater können in diesem Thema sehr hilfreich sein, um den Bedarf zu klären und das jeweilige Modell zu finden und implementieren.
Ein Wertewandel im gesamten Unternehmen ist erforderlich
Wollen Unternehmen einen Wandel zur umfänglichen Agilität hin gestalten, stehen sie bereits auf dieser Ebene vor einer Herausforderung. Denn Agilität ist nicht einfach ein "weiteres Werkzeug", das einfach so eingekauft und als "Plug & Play"-Ansatz eingestöpselt wird, sondern erfordert einen grundlegenden Kulturwandel. Der agile Wandel setzt voraus, dass Vorgesetzte Verantwortung an ihre Mitarbeiter abgeben und die Mitarbeiter wiederum bereit sind, die Verantwortung aufzunehmen. Aus vormaligen Einzelkämpfern werden Teamplayer, die ihren selbst geschriebenen Code zur Disposition und freien Verfügung des Teams stellen.
Die agile Transformation findet zwischen zwei Gegenpolen statt: Strikte Logik auf der einen und Kreativität auf der anderen Seite. Weder das eine, noch das andere Prinzip darf völlig dominieren, was eine ständige Abwägung nach beiden Seiten hin erfordert. Der Weg zur agilen Organisation ist daher selbst wieder agil: Wie die Organisation am Ende aussieht und funktioniert, entwickelt sich im Prozess und steht erst am Ende der Entwicklung fest. Wer diesen Weg konsequent geht, wird am Ende auch die Vorteile agiler Methoden genießen können: Die Funktionalitäten der IT-Produkte entsprechen stets den aktuellen Bedürfnissen.