Organisationen: Traditionell vs. Agil

Organisationen: Traditionell vs. agil

In Verbindung mit der digitalen Transformation liest man häufig auch von der Notwendigkeit einer Transformation der eigenen Organisation. Ziel ist eine agile Organisation.

Was ist darunter zu verstehen? Was unterscheidet traditionelle Organisationsformen und Methoden von agilen? Wie unterscheidet sich die Arbeit insbesondere bei der Produktentwicklung und einführung, z. B. für eine Software? Wie unterscheidet sich im Fall von Software der spätere IT-Betrieb?

In diesem Artikel möchte ich auf diese Fragen eingehen und die Stärken und Schwächen beleuchten, aber auch die Herausforderungen, die sich nach meiner Erfahrung durch agile Methoden für Organisationen ergeben.

Traditionelle Modelle

Wasserfallmodell

Abbildung 1 Schema des Wasserfallmodells nach Paul Hoadley, Paul Smith und Shmuel Csaba Otto Traian, CC BY-SA 3.0

An der Abarbeitung einer Phase sind häufig, ähnlich wie bei Gewerken bei einem Hausbau, spezialisierte Mitarbeiter beteiligt:

• bei den Beschreibungen der Anforderungen, häufig in Form eines Lastenhefts, Mitarbeiter und spätere Anwender aus den betroffenen operativen Bereichen ggf. unterstützt durch Arbeitskreise und Berater,
• im Entwurf IT-Architekten, die zumeist ein Pflichtenheft und einen Architekturentwurf erstellen, auf dessen Basis häufig ein Festpreisangebot abgegeben und Werkvertrag mit dem implementierenden Dienstleister geschlossen wird,
• in der Implementation Entwickler, die die Lösung auf Basis des Pflichtenhefts und ggf. ergänzenden Informationen der IT-Architekten programmieren,
• in der Überprüfung Tester des implementierenden Dienstleisters mit nachfolgenden Integrations- und Abnahmetests durch den Auftraggeber, an dem dann die Mitarbeiter beteiligt sind, die die Anforderungen beschrieben haben. 

Übergreifend koordiniert werden diese Phasen und Mitarbeiter durch einen Projektleiter. Erfolgt die Implementation durch Entwickler des eigenen Unternehmens, so sind die Mitarbeiter häufig in einer Matrix organisiert und temporär dem Projektleiter fachlich zugeordnet. 

Klassischer IT-Betrieb

 Der klassische IT-Betrieb folgt häufig den Grundsätzen von ITIL. ITIL ist eine Sammlung von Best-Practice-Ansätzen und beschreibt Prozesse, Funktionen und Rollen zum Betrieb von IT-Infrastruktur.

 Im klassischen IT-Betrieb hat der zuverlässige und störungsfreie Betrieb die oberste Priorität. Viele Organisationen setzen dabei ITIL dahingehend um, dass die Entwicklung und der IT-Betrieb organisatorisch und disziplinarisch voneinander getrennt sind. Neue Softwarereleases werden in geplanten Zyklen nach eigenen Tests durch Mitarbeiter des IT-Betriebs in produktiven Umgebungen bereitgestellt. Je nach Organisation wird monatlich oder einmal im Quartal ein neues Release bereitgestellt. In Abstimmung mit dem oder den Projektleitern wird festgelegt, welche Funktionen (Features) in ein Release aufgenommen werden. Die Erstellung des Release folgt zumeist dem Wasserfallmodell.

Agile Modelle 

Scrum / Kanban 

In Scrum, als Beispiel für ein verbreitetes agiles Modell, finden sich ebenfalls die Tätigkeiten der Anforderungsdefinition, des Entwurfes, der Implementation und der Überprüfung. Allerdings durchläuft nicht das gesamte zu erstellende Gewerk einmal diese Phasen wie im Wasserfallmodell in einem Stück, sondern die gesamte Anforderung wird in mehreren Schritten, sogenannten Sprints realisiert. Das zu erstellende Gewerk, bzw. die zu erstellende Softwarelösung wird als Produkt betrachtet, für das ein Produktmanager fachliche Verantwortung und Budgetverantwortung übernimmt. Scrum kennt hierfür die Rolle des Product Owners. Zu Beginn eines Projekts erstellt er gemeinsam mit den Anforderern (Stakeholdern) das sogenannte Product Backlog, eine grobe Liste der Features, die zu realisieren sind. Der Product Owner kommunizierte auch mit Stakeholdern, die nicht nur fachliche Anforderungen an das Produkt haben, sondern in jeglicher Hinsicht Einfluss auf das Produkt und das Projekt nehmen.

 Die Features werden priorisiert. Häufig bestimmt das verfügbare Budget, welche der gewünschten Features tatsächlich in der Produktversion 1.0 verfügbar sein werden.

 Im Anschluss startet dann der Sprint-Zyklus, wie in Abbildung 2 gezeigt.

Die Sprints sind vergleichbar mit einem Teilprojekt. An einem Sprint arbeitet ein interdisziplinäres Team von späteren Nutzern, Architekten, Entwicklern und Testern. Dem Team steht ein sogenannter Scrum Master zur Seite. Dieser leitet das Team nicht in fachlicher oder disziplinarischer Hinsicht, sondern unterstützt es bei der Anwendung der Scrum-Methodik. Er hält dem Team auch „den Rücken frei“, indem er sich um administrative Angelegenheiten kümmert und dort, wo Engpässe oder Hindernisse (Impediments) entstehen, sich Team-intern und -extern um eine Lösung bemüht. Typisch für die Methode Scrum ist, dass sich das Team täglich zu einem kurzen Meeting (nach der reinen Lehre im Stehen) trifft und jedes Teammitglied kurz den aktuellen Status und eventuelle Hindernisse schildert.

Am Ende eines jeden Sprints steht ein auslieferungsfähiges Produkt (Produktinkrement) zur Verfügung, das die geplanten Features aufweist. Dieses wird dem Product Owner präsentiert, der auch während des Sprints ein häufiges Feedback erhält. Der Product Owner holt sich von den Anwendern und eventuellen weiteren Stakeholdern ein Feedback (Sprint Demo oder Sprint Review), das in die Verbesserung des Produkts in nachfolgenden Sprints einfließt. Zur Verbesserung der Zusammenarbeit des Teams bespricht sich dieses ebenfalls am Ende eines Sprints (Sprint Retrospektive, Lessons learned).

Zur Steuerung der Aufgaben des Teams wird Scrum häufig mit Kanban kombiniert. Dieser ursprünglich aus der Automobilfertigung stammende Ansatz wurde auf die Softwareentwicklung übertragen. Die einzelnen Aufgaben werden dabei auf Kanban-Karten notiert und durchlaufen die Softwareproduktion. Als einzelne Produktionsbereiche gelten dabei zumeist Design, Test-Preparation, Development, Test und Deployment. Die Produktion erfolgt typisch für Kanban nach dem Pull-Prinzip. Nachfolgende Produktionsbereiche fordern bei freien Kapazitäten beim vorausgehenden Produktionsbereich neue Aufgaben an. Ein Prinzip von Kanban ist, den Fluss der Arbeit zu visualisieren. So ist auf dem Kanban-Board erkennbar, wie vielen Aufgaben in welchem Produktionsbereich stecken (WiP/Work in Progress). So werden Engpässe in einzelnen Bereichen leichter erkennbar, wodurch der Prozess der Realisierung der Features optimiert werden kann. 

Neben Features werden auch Bugs auf Kanban-Karten notiert und durchlaufen ebenso den gesamten Prozess.

Continuous Integration, Continuous Delivery und DevOps

Auf der Basis von agilen Methoden wie Scrum und Extreme Programming haben sich Konzepte etabliert, die eine kurzfristige und doch hohen Qualitätsansprüchen genügende Bereitstellung von Software ermöglichen. Das Konzept der Continuous Integration beschreibt Prozesse, Grundsätze und Anforderungen an Werkzeuge, um fortlaufend und mit einem hohen Automatisierungsgrad qualitativ hochwertige Software zu erstellen. Automatisiert meint dabei nicht, dass die Programmierung selbst automatisiert erfolgt. Diese Tätigkeit obliegt nach wie vor Entwicklern. Die Continuous Integration automatisiert jedoch den Prozess, der aus dem Quellcode eine neue Programmversion des Softwareprodukts baut (Software Build).

Ein wesentliches Element sind dabei automatisierte Tests, sogenannte Unittests. Als Grundlage für einen Unittest dienen Business Cases, die durch den jeweiligen Fachbereich beschrieben werden. Ein Business Case beschreibt einen konkreten Geschäftsvorfall, beispielsweise: 

Der Mitarbeiter Müller aus der Niederlassung 0815 erfasst am 15.01.2016 für die Sendung 4711 eine Retoure an den Versender aufgrund einer Annahmeverweigerung durch den Empfänger. Erwartet wird dabei, dass der Mitarbeiter durch die Software einen Fehlerhinweis erhält, da in der Datenbank bereits dokumentiert ist, dass die Zustellung der Sendung am 14.01.2016 erfolgte. 

Der Entwickler verwendet den Business Case, um ein kleines Testprogramm zu schreiben. Dieses ruft die Softwarefunktion oder Methode (z. B. eine API-Funktion) auf, die durch den Test überprüft werden soll und durch den beschriebenen Business Case genutzt wird. Dabei nutzt er die konkreten Informationen aus dem Business Case als Parameter für den Funktionsaufruf. Da der Business Case auch das erwartete Ergebnis definiert, kann das Testprogramm dieses mit der tatsächlichen Rückgabe der getesteten Funktion vergleichen. Stimmen erwartetes und tatsächliches Ergebnis überein, so ist der Test erfolgreich, andernfalls fehlerhaft. 

Während der automatischen Erstellung eines Software Builds werden alle Unittests durchlaufen. Nur wenn alle Unittests erfolgreich abgeschlossen werden konnten, steht eine neue ausführbare Programmversion zur Verfügung.

Das Konzept der Continuous Delivery führt den Prozess der Continuous Integration fort und beschreibt Techniken und Prozesse, wie neue Programmversionen in kurzen Zyklen für die stabile produktive Nutzung bereitgestellt werden. Der klassische Scrum-Ansatz von 14-tägigen Sprintzyklen wird dabei häufig aufgeweicht, insofern dass produktiv genutzte Softwareversionen nicht erst am Ende eines Sprints bereitgestellt werden.

Zur Umsetzung von Continuous Delivery beschreibt der DevOps-Ansatz eine entsprechende Philosophie und einen organisatorischen Rahmen. Der Kern liegt darin, wie die Zusammenarbeit zwischen den Entwicklern (Dev) und dem IT-Betrieb (Ops) verbessert werden kann. In klassischen Organisationen sind diese beiden Abteilungen voneinander getrennt und verfolgen kollidierende Ziele: die Entwickler möchten möglichst kurzfristig und häufig neue Programmversionen an den Endanwender ausliefern, um Bugfixes und neue Funktionen bereitzustellen; der IT-Betrieb möchte möglichst selten Änderungen an der produktiven Umgebung, da jede Änderung das potentielle Risiko trägt, den IT-Betrieb zu stören. Der DevOps-Ansatz fördert dabei eine Kultur, die die Zusammenarbeit zum Nutzen des Endanwenders verbessert, ohne Risiken für den stabilen IT-Betrieb zu erhöhen. Das Softwarearchitekturmodell der Microservices legt dabei eine technische Grundlage, um auftretende Fehler und Störungen im Betrieb zu begrenzen und optimal zu behandeln. 

Vergleich der Modelle 

Welches Vorgehensmodell für welches Projekt besonders geeignet ist, um zuverlässig und kosteneffizient die Projektziele zu erreichen, hängt insbesondere von der Komplexität des Projekts ab und der an dem Projekt beteiligten Persönlichkeiten. 

Der Komplexitätsforscher Ralph Douglas Stacey hat für zunehmende Komplexität zwei Treiber identifiziert: Uneinigkeit und Unsicherheit. Übertragen auf ein IT-Projekt bedeutet das, dass wenn Einigkeit zu Vorgehen, Ressourcen und Budget besteht und man genau weiß, was man möchte und keine offenen Punkte bestehen, das Projekt als einfach eingestuft werden kann. In Projekten, in denen Uneinigkeit und Unsicherheit höher ist, steigt die Komplexität bis hin zu chaotisch, wobei chaotisch in diesem Fall nicht negativ zu deuten ist. Welche Komplexität ein Projekt besitzt, wird durch das Projekt selbst, seine Rahmenbedingungen und die Beteiligten bestimmt. Eine hohe Komplexität lässt sich nicht immer vermeiden. Die Unsicherheit wird häufig dadurch getrieben, indem zwar eine Vision von dem finalen Produkt existiert, aber der konkrete Weg zur Realisierung unklar ist und mitunter auch experimentell vorgegangen werden muss. Der Umfang oder die Dauer des Projekts gilt nach diesem Modell nicht als Treiber für Komplexität. Demnach kann der Bau einer großen Anlage, der mehrere Monate in Anspruch nimmt, als kompliziert eingestuft werden, sofern die Faktoren Uneinigkeit und Unsicherheit gering sind

Das Wasserfallmodell ist insbesondere für Projekte geeignet, die den Komplexitätsgrad einfach oder kompliziert haben, agile Methoden für komplex und chaotisch.

Die Erfahrungen mit agilen Methoden haben gezeigt, dass sich damit kurze bis sehr kurze Produktzyklen mit einer dennoch hohen Qualität realisieren lassen. Sie empfehlen sich, wenn nicht im Detail frühzeitig geplant werden kann, wie das zu erstellende Produkt final aussehen soll (hohe Unsicherheit). Dies wird auch durch den Vergleich der Wertschöpfungskurven der beiden Modelle deutlich (Abbildung 4).

Die graue Linie gibt den Verlauf bei einem klassischen Vorgehensmodell wieder, die orange bei einem agilen Vorgehen. Aufgrund der häufigen Iterationen z. B. in Form von Sprints, entsteht bei der Anwendung von agilen Methoden bereits früh ein erstes Produktinkrement, z. B. in Form eines Klick-Dummys. Die Iterationen ermöglichen es auch, für jede Iteration/jeden Sprint die Anforderungen nachzujustieren. Bei Abschluss des Projekts erhält man so ein Produkt, das den Anforderungen entspricht, die erst zuletzt festgeschrieben wurden. So können praktische Erfahrungen berücksichtigt werden, die während des Projektverlaufs gewonnen wurden. In der Grafik entspricht daher das Produkt den Anforderungen, die zum Zeitpunkt tx definiert wurden.

Klassische Vorgehensmodelle beginnen mit einer längeren Analyse- und Planungsphase. Dazu werden früh im Projekt, in der Grafik zum Zeitpunkt t1, die Anforderungen festgeschrieben, z. B. in Form eines Pflichtenhefts. Entsprechend entspricht das fertige Produkt am Ende des Projekts den Anforderungen zum Zeitpunkt t1. 

Die Vorteile der klassischen Methoden werden häufig in einer vermeintlichen Kostensicherheit gesehen: Da zum Zeitpunkt t1 der Funktionsumfang festgeschrieben wird, kann ein Dienstleister den Aufwand zur Umsetzung schätzen und ist in der Lage ein Festpreis anzubieten. Dieser Festpreis wird jedoch in der Praxis nicht selten überschritten, da zum Zeitpunkt t1 Anforderungen übersehen wurden, noch nicht bekannt waren oder erst durch den Fortschritt der Zeit im Projekt hinzukamen. Diese Änderungen erhöhen dann in Form von Projektnachträgen die Kosten. 

Kostensicherheit kann in agilen Projekten durch den „Design-to-Budget“-Ansatz sichergestellt werden. Vor jeder Iteration/jedem Sprint definiert der Product Owner ein Budget und stimmt mit dem Team/dem Dienstleister ab, welche Features in diesem Rahmen realisiert werden können. Dies fördert eine Kosten-Nutzen-Abwägung einzelner Funktionen und berücksichtigt das Pareto-Prinzip. Dieses besagt, dass 80 % des Ergebnisses mit 20 % des Gesamtaufwands erreicht werden, wohingegen die verbleibenden 20 % der Ergebnisse 80 % der Kosten verschlingen. Durch eine zielgerichtete Kosten-Nutzen-Abwägung wird häufig deutlich, dass nicht immer eine 100 %-Lösung erforderlich ist, die alle Anforderungen berücksichtigt. Das trägt direkt dazu bei, dass ein Produkt früher verfügbar ist und zu geringeren Kosten. Dabei ist nicht ausgeschlossen, dass zu einem späteren Zeitpunkt weitere Anforderungen umgesetzt werden, die dann jedoch die Erfahrungen berücksichtigen können, die durch die zwischenzeitliche Nutzung des Produkts gewonnen wurden.

Eine Herausforderung in der Anwendung von agilen Methoden besteht jedoch in dem höheren erforderlichen Reifegrad der beteiligten Personen und Organisationen. So hat bei Scrum das Team eine höhere Freiheit in der Umsetzung aber damit auch eine höhere Verantwortung. Außerdem organisiert sich das Team selbst. Beides setzt voraus, dass die Teammitglieder hierzu bereit sind. 

Außerdem erfordert Scrum auch von dem Auftraggeber/dem Investor eine höhere Risikobereitschaft, da nicht vor Start eines Projekts exakt definiert ist, zu welchen Kosten und in welcher Zeit das Produkt erstellt werden kann. 

Fazit 

Grundsätzlich besteht nicht in jedem Projekt die Pflicht, dieses nach agilen Methoden zu bearbeiten. Aufgabenstellungen, die den Komplexitätsgrad einfach bis kompliziert haben, können erfolgreich mit einer klassischen Planung und Durchführung gelöst werden.

Die digitale Transformation stellt Organisationen vor Herausforderungen – bietet aber auch die Chance, neben neuen Technologien einen Wandel der Unternehmenskultur hin zu einer agilen Organisation zu vollziehen. Die meisten externen IT-Dienstleister und einige unternehmensinterne IT-Abteilungen arbeiten bereits mit agilen Methoden. Das vollständige Potential können agile Methoden jedoch nur entfalten, wenn der gesamte Prozess zur Entwicklung und Einführung eines neuen Produkts agile Methoden nutzt – nicht nur der Teil, der durch die IT bearbeitet wird. 

Dabei lassen sich Organisationen nicht per Schalter auf agil umstellen – dies ist ein Reifeprozess. Mitarbeiter und Manager benötigen Zeit, um Vertrauen in agile Methoden zu fassen und Praxis und Sicherheit in der Anwendung zu gewinnen. In diesem Prozess können sie zumindest anfänglich durch einen externen Berater unterstützt werden, der in der Anwendung agiler Methoden erfahren ist.

Sie wollen auf meine Erfahrung zurückgreifen? 

Dann freue ich mich auf Ihren Kontakt.