Komplexität
Innerhalb der letzten Jahrzehnte hat die Komplexität in der Wirtschaftswelt stark zugenommen. Die Globalisierung, die Digitalisierung, und die gestiegenen Bedürfnisse aller Verbraucher, aber besonders der jungen Generationen (Generation Y und Generation Z/Digital Natives) verlangen vielen Unternehmen drastische Änderungen ab. Viele Unternehmen sind dazu gezwungen ihre klassischen Geschäftsmodelle zu wandeln, eine digitale Transformation zu vollziehen und digitale Geschäftsmodelle zu entwickeln. Diese digitalen Geschäftsmodelle werden immer mit Hilfe von neuen Softwarelösungen realisiert. Softwaresysteme sind hoch komplexe Systeme, die ab einer gewissen Größe nicht mehr planbar sind. Softwareentwicklung gehört, ganz im Gegenteil zu klassischen planbaren Entwicklungsprozessen, zu den komplexen Entwicklungsprozessen die nur schlecht bis nicht planbar und sehr unberechenbar sind, weil sie so dynamische Ergebnisse in Form von komplexer Software erzeugen und die Ergebnisse frei definiert werden können. Diese Gestaltungsfreiheit und die Möglichkeit, dass in der Softwareentwicklung alles möglich ist und Software sogar jederzeit modular und erweiterbar ist, schafft noch zusätzliche Komplexität in diesen komplexen Systemen.
Um den Unterschied zwischen Kompliziertheit und Komplexität zu verstehen, kann man sich sehr leicht der Physik bedienen. Ein (einfaches/mathematisches) Pendel ist ein wunderschönes einfaches und beschreibbares System. Dieses System zu berechnen und das Verhalten vorherzusagen, ist jedoch bereits etwas komplizierter. Denn dazu braucht es das 2. Newtenschen Gesetz und dies hat die Menschheit bzw. Isaac Newton erst im Jahre 1687 entwickelt.
Schließt man an dieses einfache aber kompliziert zu berechnende System an die Masse ein weiters Pendel mit einer weiteren Masse an, so entsteht ein Doppelpendel dessen Bewegungen nicht mehr einfach beschreibbar oder vorhersagbar sind. Ein komplexes, chaotisches (nicht lineares) System entsteht. Dieses System bzw. sein Verhalten ist sehr komplex und nicht mehr berechenbar. Die Änderung war leicht möglich, die Beherrschung und Berechnung des Systems ist jedoch nicht möglich. Bei zwei drei oder noch mehr Pendel in einer Kette können selbst kleinste Störungen völlig andere Ergebnisse liefern.
Software zu Codieren ist im Kleinen gesehen nur eine komplizierte Angelegenheit, man braucht genügend technisches Backgroundwissen über Syntax, und Methoden und Werkzeuge der Softwareentwicklung um den komplizierten Code lesen und verstehen zu können. Das Verhältnis kompliziert zu komplex ändert sich jedoch, wenn das System wächst und man es als Ganzes betrachtet, bzw. ausführt und sein Verhalten beschreiben möchte. Auch die Software-Entwicklung ist eine komplexe Aufgabe, weil es dazu nötig ist das Verhalten des Systems zu beschreiben, zu Kommunizieren und mit allerhand Methoden, Werkzeugen und Prozessen die Software zu designen, und zu erstellen.
Seit dem letzten Jahrhundert verändert sich unsere Welt und die Wirtschaft immer mehr von einer komplizierten hin zu einer komplexen Welt. Dinge wie die Globalisierung und die damit einhergehende Markverdichtung, das Internet, die Digitalisierung und Industrie 4.0, und die gestiegenen Bedürfnisse junger Generationen (Generation Y und Digital Natives) führen zu einer Steigerung dieser Komplexität. Heutzutage ist es kaum mehr möglich, durch eine Blue-Ocean-Strategie (und die Entwicklung von Weltneuheiten) groß zu werden. Die meisten bereits existierenden Unternehmen müssen durch ein einfacheres und besser zu verwendendes Produkt mit mehr Zusatz-Features ihre Konkurrenten vom Markt verdrängen. Das Internet gibt dem Konsumenten die macht Produkte und deren Eigenschaften zu vergleichen der Druck auf die Produktentwicklung steigt dadurch.
Komplexität beherrschen
Um die Komplexität nun Herr zu werden und sich am Markt durchzusetzen ist es notwendig die Aufgabe herunterzubrechen und in kleine Einheiten und Aufgaben zu zerlegen und umzusetzen und diese Umsetzung zu managen. Die einzelnen Einheiten sind, jedes für sich zwar kompliziert aber nicht mehr komplex. Dazu wurde seit jeher klassisches Projektmanagement verwendet. Im Vergleich zum klassischen Projektmanagement hat die agile Vorgehensweise bzw. das agile Projektmanagement aber zahlreiche Vorteile. Im Folgenden wird auf die Unterschiede zwischen klassischen und agilen Projektmanagement genauer eingegangen, aber gleich mal vorweg kann gesagt werden, dass Komplexität für Einzelpersonen schwer bis gar nicht zu beherrschen ist und am Stück auch nicht planbar ist. Klassisches Projektmanagement geht davon aus, dass ein Projektmanager, den Überblick über ein Projekt behalten kann, und das Projekt zu Beginn gleich geplant werden kann, es werden zwar auch Aufgaben in kleinere Pakete heruntergebrochen, aber nicht auf veränderbare Situationen eigegangen. Agiles Projektmanagement auf der anderen Seite erhebt diesen Anspruch gleich gar nicht, es werden immer nur Mikroprojekte geplant, dessen Komplexität beherrschbar bleibt, und auf Veränderungen in den Bedürfnissen der Anwender und des Marktes kann reagiert werden.
Agiles Projektmanagement
Als Alistair Cockburn, der als einer der Initiatoren der agilen Softwareentwicklung gilt, gefragt wurde was agil bedeutet, antwortete er: Agilität heißt „Deliver VALUE to customers FASTER. Minimize BUREACRACY” Es geht also darum schnell Mehrwert für den User zu erzeugen und Dokumentationen und andere Arten von Bürokratie zu minimieren. Agiles Projektmanagement entstand in den 90er Jahren als alternative explorative Herangehensweise zu dokumentationsreichen und plangesteuerten Ansätzen des bisherigen standardisierten Projektmanagements. Es geht also um das hinterfragen des klassischen Projektmanagements und seiner Rollen, Prozesse und Projektpläne im Besonderen des Wasserfall-Modells. Agiles Projektmanagement versucht durch leichtgewichtige Prozesse und flexiblere Rollen die alten schwergewichtigen, steifen und unflexiblen Prozesse zu ersetzen. Um dies zu erreichen entstand in den 90er Jahren das agile Manifest, welches aus 12 Grundprinzipien besteht. Dabei stellt das agile Projektmanagement das Spannungsdreieck auf den Kopf. Statt einen fixen Umfang mit variabler Zeit, Kosten und Qualität zu vereinbaren, wird beim agilen Projektmanagement Zeit Kosten und Qualität fixiert und der Umfang variabel gehalten. Es darf bei agilen Umsetzungsprojekten also kein Kompromiss hinsichtlich der Qualität gemacht werden. Jedes Delivery muss von hoher Qualität sein. Bei dieser Qualität geht es jedoch nicht rein um Fehlerfreiheit – nein es geht darum, dass Stakeholder einbezogen werden, und jene Anforderungen entwickelt werden, die den Anwender am meisten Mehrwert bieten. Dies geschieht in evolutionären Entwicklungsschritten, was wiederum bedeutet, dass die Qualität der Architektur der Umsetzung so flexibel und erweiterbar sein muss, dass zusätzlichen Anforderungen einfach zur Lösung hinzugefügt werden können.
Was ist agiles Projektmanagement?
Um diese Frage zu beantworten ist es notwendig sich vom klassischen plangesteuerten Projektmanagement insbesondere des Wasserfallmodells abzugrenzen.
Abgrenzung zum Wasserfallmodell
Im plangetriebenen Ökosystem werden Arbeiten und neue Produkte in Projekten erzeugt. Diese Projekte starten meistens mit einer Idee für ein (verbessertes) Produkt, welches die Bedürfnisse der Kunden/Anwender adressiert. Wenn das Projekte gut geplant und ausgeführt wird, so die Hoffnung, wird das Ergebnis sein, dass wir mehr glückliche Kunden durch unser neues Produkt erzeugen was wiederum zu mehr Umsatz und Gewinn führt. Um dieses Ziel zu erreichen wird gleich zu Beginn bzw. vor Beginn der Umsetzung ein detaillierter Plan mit allen Entwicklungs- und Design- und Umsetzungsschritten erstellt. Um diesen Plan in die Tat umzusetzen sind eine reihe an Experten mit den jeweiligen Projektschritten betraut. So könnte zum Beispiel
- ein Business-Experte damit beauftragt werden die Anforderungen des Systems zu beschreiben,
- ein Designer kann dann ein System planen, welches diese Anforderungen erfüllt,
- ein Umsetzungsteam aus Softwareentwicklern kann dann das designte System nach diesen Anforderungen umsetzen,
- die Arbeit des Umsetzungsteams kann dann von einem neuralen Tester abgenommen werden und somit die Qualität sichergestellt werden,
- und letzten Endes kann ein Administrator damit beauftragt werden das fertige Produkt zusammenzustellen und den User zur Verfügung zu stellen.
So strukturiert und einfach wie das jetzt klingt ist es leider aber nicht. Es stellt sich schnell heraus, dass dieser Ansatz nur dann gut funktioniert, wenn ALLES (alle Anforderungen, alle Umsetzungsschwierigkeiten etc.) von Anfang an bekannt sind. Es also keine Überraschungen im Zuge der Umsetzung auf uns warten, und wir genau wissen wo und was unser Ziel ist. In komplexen Ökosystemen und bei komplexen Aufgaben wie wir sie in der IT antreffen ist dies nur sehr selten der Fall. Wenn man diese komplexen Probleme mit plangetriebenen Ansätzen versucht zu lösen, stößt man schnell an seine Grenzen und steht vor großen Problemen.
So ist die plangetriebene Umsetzungsstrategie, die wir bei Wasserfall-Umsetzungen wählen eine heikle Angelegenheit. Die kosten werden zu beginn mit dem Umsetzungsplan geplant, und sind relativ leicht zu berechnen. Es werden einfach die Aufwandschätzungen verwendet und die Aufwände des Umsetzungsteam werden monatlich aufkumuliert und steigen mit der Dauer des Projekts. Zusätzlich werden noch Lizenzkosten, und Materialkosten für Hardware etc. berücksichtigt. Diese Kosten fallen dann auch stetig Woche für Woche an, die Wertschöpfung jedoch entsteht erst zum absolut spätesten Zeitpunkt nämlich zu Projektende. Wenn alles (trotz der komplexen Aufgabe) nach Plan verläuft, und die Kunden leiben was wir produziert haben, werden wir Erfolgreich sein und Umsatz und Gewinn generieren und letzten Endes mehr herausbekommen als wir investiert haben. Es liegt auf der Hand, dass diese plangetriebene Herangehensweise, mit Big-Bang-Delivery-Strategie und wenig bis kein Feedback vom Kunden jede Menge an Risiko beherbergt. Wir sammeln Quasi durchgehend über die Zeit hinweg das Risiko und stocken es bis zum Schluss auf.
- So könnte es sich zu guter Letzt, wenn wir Akzeptanztests mit Echtusern machen herausstellen, dass unser Produkt nicht die Anforderungen der User erfüllt, oder das Problem der User nicht zur Gänze löst.
- Es könnte auch sein, dass wir erst viel zu spät feststellen, dass wir nicht die richtigen Mitarbeiter, mit den richtigen Skills im Projekt hatten und somit die Umsetzung ineffizient und schlecht umgesetzt wurde.
- Es könnte auch sein, dass wir erst spät im Projekt feststellen, dass unsere Annahmen zu Beginn was Umfang und Kosten angingen falsch waren und bei Weiten zu gering geschätzt wurden.
- Auch könnte es sein, dass wir ganz am Schluss des Projekts, wenn wir die Integration der einzelnen Produktbausteine durchführen feststellen, dass die Architektur und die Technische Umsetzung nie ausreichend geplant wurde, und das System somit nicht skaliert und die Performance erreicht, die wir eigentlich brauchen oder Sicherheitsaspekte außeracht gelassen wurden und es Sicherheitsprobleme gibt.
Diese Risiken können wir zwar während des Projekts tracken, überwachen und sogar adressieren, aber wir werden erst zu guter Letzt, wenn das Produkt wirklich integriert wird feststellen ob unsere Annahmen der Realität entsprechen und ob wir alles dabei durchdacht haben.
Ein anderer nicht intuitiver Aspekt des Wasserfallmodells und des plangetriebenen Ansatzes ist es, dass gleich zu Beginn des Projekts, tonnenweise Entscheidungen getroffen werden, und das zu einem Zeitpunkt, zu dem so gut wie nichts über das Projekt und das Produkt bekannt ist und noch keinerlei Wissensgewinn stattgefunden hat. Es wird gleich am Anfang entschieden
- was zu tun ist,
- wie es zu tun ist,
- wer dies in welcher Reihenfolge umsetzt
- und wie lange man für diese Umsetzungen benötigt.
Und das alles in einer Phase des Projekts in dem der geringste Anteil an Wissen über das Projekts erzeugt wurde. Auf diese Planung wird dann, zu allem Übel auch noch ein Vertrag aufgesetzt, und das Umsetzungsteam und der Auftragnehmer verpflichtet sich in diesem Vertrag zur Umsetzung nach dem Plan. Da kann ja dann nichts mehr schief gehen oder?
Eine weitere negative Eigenschaft von Wasserfall-Projekten ist, dass sie sehr lange laufen. Je länger jedoch ein Projekt läuft, desto höher ist die Wahrscheinlichkeit, dass diese verzögert werden. Mitarbeiter werden des Öfteren kurz vom Projekt abgezogen, weil etwas „Wichtiges“ dazwischengekommen ist und ihre Expertise wo anders kurz gebraucht wird. Dies führt üblicherweise dazu, dass das Umsetzungsteam und der Projektleiter nun Ausreden hat warum Deadlines nicht eingehalten werden können und mehr Budget für die Umsetzung benötigt wird. Wenn Deadlines verschoben und Budgets aufgestockt werden, führt dies wiederum sehr oft dazu, dass zusätzliche Anforderungen und Features in das Projekt mit aufgenommen werden. Dieser Requirement-Creep führt wiederum zu steigender Komplexität des Produkts und verlängern das Projekt noch mehr. Dies führt zu steigenden Kosten, verringerter Chance auf Gewinne und steigenden Risiko.
Aufgrund der Tatsache, dass beim Wasserfallmodell Aufgaben von Fachexperten seriell abgearbeitet werden, wird automatisch auf eine laufende Übergabe von Wissen zwischen den verschiedenen Experten vom Wasserfallmodell verlangt. Diese Wissensübergaben werden, sobald jemand seinen Teil des Projekts erledigt hat notwendig, und führen dazu, dass ständig Wissen über das Produkt und das Projekt verloren geht und neu generiert werden muss. Umso mehr Übergaben es in einem Projekt gibt, umso weniger effizient wird Wissen übergeben, und umso mehr Wissen geht ständig verloren. Einige Studien sprechen daher von bis zu 50% Wissensverlust bei Übergaben, welche durch Kommunikation wieder gut gemacht werden muss.
Eine sehr ineffiziente Methode, welche noch kostspieliger wird, weil der gesamte Prozess von einem Projektmanager geplant und koordiniert werden muss, und es noch weitere Rollen wie eine Changerequest-Manager oder übergeordneten Portfolio-Manager gibt, die ebenfalls überwachende und koordinierende Aufgaben im Projekt übernehmen.
Agiles Projektmanagement
Agiles Projektmanagement oder adaptive und iterativ, inkrementelle Umsetzungsmethoden starten von der gleichen Ausgangslage wie pangetriebene Modelle. Zu Beginn entsteht eine Idee eine Vision eines neuen Produkts oder Services welches die Bedürfnisse der Kunden adressiert und ein Problem der Anwender löst. Dieses Produkt oder dieser Service sollte dann ebenfalls gewinnbringend an den Kunden geliefert werden und das Investment sollte sich über die Gewinne wieder amortisieren. So wie beim Wasserfallmodell auch arbeiten verschiedenste Experten am Projekt mit. Aber anstatt sequenziell und separat am Projekt zu arbeiten, arbeiten sie gemeinsam in einem interdisziplinären Team, dass spart die Übergabe von einem zum nächsten Experten und verringert den Wissensverlust. Dieses Team ist gemeinsam für den Erfolg und Misserfolg des Projekts verantwortlich. Sie arbeiten zusammen und feiern zusammen ihre Erfolge. Im Gegensatz zum klassischen Projektmanagement sind sie Selbstorganisiert, das heißt sie entscheiden gemeinsam als Team wie sie sich koordinieren und welche Themen als nächstes bearbeitet werden und so planen und setzen sie gemeinsam das Projekt und lernen zusammen. Dabei setzten sie vor allem auf die Qualität des Produkts oder des Service ein augenmerkt. Es gibt keine Kompromisse hinsichtlich der Qualität.
Anstatt alles im Voraus zu planen werden beim agilen Projektmanagement nur kleine Entwicklungsschritte geplant. Dabei wird aber vor allem auf eines geachtet, dass alle ein klares Bild von der Vision des Projektes haben und alle Schritte direkt in Richtung des gemeinsamen Ziels hin gemacht werden. Nach jedem dieser kleinen Entwicklungsschritte wird etwas Mehrwert direkt den Kunden und dem User geliefert. Dieser kann sogleich Feedback geben und dieses Feedback kann wiederum gleich in den nächsten Entwicklungsschritt und somit das Produkt einfließen.
Das Entwicklungsteam akzeptiert dabei, dass es eventuell einen Fehler bei diesem Schritt gemacht hat und eventuell das Problem nicht richtig verstanden hat und adaptiert sich auf die veränderten Bedingungen. So wird das Team Schritt für Schritt besser und effizienter, und es wird schrittweise Mehrwert geschaffen die der Kunde und der User angreifen kann. Auf diesem Wege werden der Wissengewinn und das Lernen maximiert und konstant an einem verbesserten Produkt gearbeitet. Einerseits kann nach jedem Entwicklungsschritt Feedback von Usern und Stakeholdern eingeholt werden, oder andererseits sogar das Produkt gelaucht werden und Kennzahlen gemessen werden.
Eines der wichtigsten Dinge im agilen Projektmanagement ist, dass sich das selbstorganisierte Team ständig drei Fragen stellt:
- Bauen wir das richtige Produkt?
- Bauen wir das Produkt richtig?
- Können wir irgendetwas machen um unsere Arbeit konstant zu verbessern?
Diese Fragen führen dazu, dass Risiken minimiert werden und Lessons Learned am Weg zur Entstehung des neuen Produkts gemacht und gleich wieder verwertet werden, anstatt wie beim klassischen Projektmanagement erst am Ende eine Lessons-Leaned-Session abzuhalten.
Oft entstehen so in agilen Projekten am Weg der Entwicklung ganz andere Produkte, als das Team am Anfang geplant hat. Diese Produkte erfüllen aber ihren Zweck, nämlich glückliche Kunden zu erzeugen und gewinne einzufahren.
Durch diesen iterativ inkrementellen Ansatz lernt das Team Schritt für Schritt aber sehr schnell:
- ob sie das richtige Produkt bauen, welches dem User den benötigten Nutzen liefert,
- ob die beteiligten Personen die notwendigen Skills für die Aufgaben haben
- und durch die ständigen Deliveries lernen sie von beginn an die technischen Herausforderungen kennen und können
- jederzeit einen Schlussstrich ziehen und den Kostenanfall beenden.
Dadurch dass das Team konstant bleibt, es aber ständig neue Produktinkremente veröffentlicht lässt sich das Risiko auf ein absolutes Minimum reduzieren. Es wird schließlich auch von Iteration zu Iteration Mehrwert erzeugt und dieser sichtbar gemacht. Aufgrund der Tatsache, dass das Team ständig am Feature mit dem höchsten Mehrwert arbeitet und sich das Team ständig verbessert und die Effizienz steigert, führt dazu, dass die Leistungen des Teams Optimal eingesetzt werden.
Gegenüberstellung klassisches Projektmanagement zu agilen Projektmanagement
| Klassisches Projektmanagement | Agiles Projektmanagement |
|
|
Inspirationen und Fachlektüre:
Dieser Artikel gehört zur Artikelreihe „Methoden und Werkzeuge für die Digitalisierung“
Folgen Sie uns jetzt im Social Media:
https://www.facebook.com/Digitalisierung Täglich zwischen 20 und 100 Beiträge aus über 200 verschiedenen Fachquellen
https://www.facebook.com/DerDigitalisierungsCoach/ Der DigitalisierungsCoach auf Facebook, Infos, Termine und mehr.
https://twitter.com/DavidTheil
Zum Autor:
David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.
https://www.xing.com/profile/David_Theil
https://www.linkedin.com/in/david-theil-1a4190148/
https://www.linkedin.com/groups/8678887
https://medium.com/@david.theil
https://twitter.com/DavidTheil
DigitalisierungsCoach 
Kommentar verfassen