Schlagwort: Projektmanagement

Der Weg zur Agilität / die Autonomie des Lernens

Der Weg zur Agilität / die Autonomie des Lernens

Die Retrospektive ist ein unverzichtbarer Bestandteil agiler Vorgehensweise. Im klassischen Projektmanagement gibt es schon die „lessons learned“. Wenn ohnehin iterativ gearbeitet wird (siehe vorangegangener Beitrag) ist es scheinbar ein Leichtes regelmäßig nach Abschluss einer Iteration einen Lernschritt einzufügen und zu fragen: „Was war gut?“, „Was können wir verbessern?“. Aus den Ergebnissen der zweiten Frage lassen sich Experimente definieren, die während der nächsten Iteration durchgeführt und danach geprüft werden. Hat sich ein Experiment bewährt, wird es in den Ablauf übernommen. Das hört sich leicht an, ist es aber nicht. Es ist wesentlich, dass sich jene Menschen die Fragen nach den Verbesserungen stellen, die die Arbeit getan haben. Insbesondere die Entscheidung über das Experiment muss von den Arbeitenden getroffen werden. Die hierfür notwendige Entscheidungsfreiheit ist die erste wirklich große Hürde auf dem Weg zur Agilität. Wird den Menschen zugestanden, dass sie Abläufe ändern, oder schreiten Prozess- und Qualitäts-Einheiten bzw. Vorgesetzte ein? Wenn diese Autonomie nicht gewährt wird, kann man echte Agilität vergessen. Die Vision eines Hochleistungs-Teams bleibt dann Illusion. Es ist sogar noch schlimmer. Pseudo-Retrospekiven, in denen Ansätze zur Verbesserung gefunden werden, die danach nicht umgesetzt werden können, sind außerordentlich demotivierend. Dann ist es sogar besser, auf die Retrospektiven ganz zu verzichten. Die Autonomie des Lernens ist die notwendigste Bedingung für Agilität.  
Der Weg zur Agilität / erste Schritte

Der Weg zur Agilität / erste Schritte

Viele Unternehmen sind heute immer noch in einer Weise organisiert, dass das Wasserfallmodell als der passendere Ansatz erscheint. Das Problem dabei ist, dass der Wasserfall noch nie funktioniert hat, und über Jahre hinweg ein totes Pferd trainiert wurde. Die gute Nachricht: lautet: Agile Elemente lassen sich auch in Unternehmen einsetzen, die auf den ersten Blick alles andere als agil sind. Insbesondere die Prinzipien
  • Iteration,
  • lebendige, sortierte Listen statt epischer Dokumente
  • sowie vergleichendes „Schätzen“ statt Raten
lassen sich umsetzen, ohne eine Neuorganisation zu erzwingen. Wenn nach diesen Prinzipien gearbeitet wird, ist schon viel gewonnen. Noch besser wird es, wenn mann*frau die Menschen in echten Teams arbeiten lässt, das wird aber Gegenstand  des nächsten Artikels werden. Iteration Das Ergebnis eines Projektes ist zu Beginn ein Fantasie-Gebilde. So schön die Fantasie ausgemalt ist, so präzise sie beschrieben sein mag, es bleibt Fantasie. Nicht selten gibt es eine Enttäuschung, wenn nach langer hoffnungsvoller Wartezeit das vermeintlich fertige Produkt in Augenschein genommen wird. Dagegen hilft nur eines: So früh wie möglich ein Muster bauen und dieses dann in vielen Iterationen fertigstellen. Damit steigt die Wahrscheinlichkeit, dass am Ende sinnvolles herauskommt. Das gilt im Übrigen für fast alle Arten von Projekt-Ergebnissen. Lebendige, sortierte Listen statt epischer Dokumente Wann sind Anforderungen bekannt?Wenn das Prinzip der Iteration eingeführt ist, sollten als Nächstes die häufig zu Beginn des Projektes erstellten, epischen Dokumente abgeschafft werden. In schnell wandelnden Zeiten ist der Inhalt von Dokumenten, die in monatelanger Kleinarbeit erstellt wurden, bereits veraltet bevor das fertige Dokument überhaupt zum ersten Mal gelesen wird. (siehe Cartoon „Was fertig wirklich bedeutet“). Dazu kommen noch neue Anforderungen, die es aus vielfältigen Gründen nicht mehr in die Dokumente schaffen. Nebenstehende Grafik zeigt die Antworten einer Studie aus dem Jahr 2008 auf die Frage „Wieviel Prozent der Anforderungen zu Beginn des Projektes bekannt waren“1. Projekte, in denen alle Anforderungen bekannt waren, stellen eher die Ausnahme dar. Ein signifikanter Teil der Anforderungen wird erst während der Projektlaufzeit bekannt. Statt dicke Dokumente mühsam weiter zu pflegen und seitenlange Versions-Tabellen zu erstellen, kann man gleich in Listenform arbeiten. Wenn die Liste noch eine für den Kunden relevante Sortierung bekommt (z.B. nach Wert, Anwendernutzen o.Ä.) ist auch sofort klar, was in der nächsten Iteration umgesetzt wird. Vergleichen statt Raten Eine Gesamtschätzung auf Basis eines umfangreichen Anforderungsdokumentes ist in den meisten Fällen eine bessere Rate-Aktion. Etwas Unbekanntes zu schätzen ist Menschen ohnehin kaum möglich. Letztendlich versuchen wir immer zu vergleichen. Wir suchen instinktiv bekannte Größen, mit denen wir das Unbekannte vergleichen können. Dieses Prinzip lässt sich in iterativ arbeitenden Projekten mit Anforderungslisten elegant umsetzen. Neue noch nicht geschätzte Listeneinträge werden einfach mit den bereits umgesetzten Anforderungen verglichen. Wenn dieses drei methodischen Prinzipien umgesetzt werden, sind immerhin die ersten Schritte in Richtung Agilität getan. Den Geist des agilen Manifests umzusetzen erfordert dann noch vieles mehr. Dafür zählen hier noch keine Ausreden, diese drei Schritte können auch in großen, starren Organisationen gegangen werden. Der nächste Schritt ist dann das zyklische Lernen bzw. die Autonomie des Lernens.  
  1. Technical Report der Uni Magedburg: “Einfluss agiler Praktiken auf Teammerkmale und Erfolg von Softwareentwicklungsprojekten” von Sven Lindenhahn, Sebastian Günther, Eberhard Huber 5. Dezember 2008 []
Das wundersame Projekt-Wachstum

Das wundersame Projekt-Wachstum

projekt_cartoon_024_extrawurstEs ist schon etliche Jahre her, E-Commerce steckte noch in den Kinderschuhen. Das Projekt rankte sich um einen B2B Shop der ersten Generation. Das Kernproblem des Shops war, dass die technischen Betriebskosten deutlich höher waren als die Erlöse, die mit dem Shop erzielt wurden. Genau genommen waren die Betriebskosten sogar höher als der Umsatz, der mit dem Shop gemacht wurde. Das Projektziel für einen Neubau des Shops war demzufolge glasklar formuliert: Reduzierung der Betriebskosten auf eine Maximalsumme von x DM (der Euro war damals noch nicht eingeführt). Aufgrund neuer Technologien, die zur Entstehungszeit des Altsystems noch nicht verfügbar waren, wäre das Ziel ganz leicht erreichen zu gewesen. Selbst bei voller Berücksichtigung der Entwicklungskosten des neuen Systems wäre ein ROI in wenigen Monaten erzielt worden. Ein kleines schnelles Projekt, das sich in wenigen Monaten bezahlt macht! Was will man mehr. Das „Mehr“ könnte darin bestehen, dass in einem neuen prestigeträchtigen Arbeitsgebiet Meriten zu verdienen sind, das Projekt könnte zum strategischen Vorreiter für alles Mögliche dienen – und so geschah es. Aus der Ein-Satz-Formulierung des Projektzieles entstand ein mehrseitiges Elaborat, in dem eine rosige Zukunft des gesamten Unternehmens skizziert wurde. Mit dem Elaborat wuchs das Projektteam, aus einem Team in operativer Größe wurde eine Gruppe, die sich ein eigenes Organigramm geben musste. Projektleiter und Teilprojektleiter wurden installiert. Die Vision des Zielsystems wurde immer größer, komplizierter und am Ende völlig unverständlich. Immer neue Fragen wurden aufgeworfen, die einfache Fragestellung entwickelte sich so lange, bis sie den Anschein von Komplexität hatte. Epilog 1 Das Ende der Geschichte, es wurde ein System gebaut, das noch mehr Betriebskosten verursachte als das alte. Umsatzsteigerungen wurden nicht erzielt. Die Maßnahmen, die eventuell den Umsatz erhöht hätten, waren der Kompliziertheit des Projektes zum Opfer gefallen. Epilog 2 Das Aufblasen von kleinen effizienten Vorhaben zu monströsen Projekten, die vor allem viele Manager-Sessel und Gremien generieren, kann in unseren heutigen, aufgeklärten Zeiten natürlich nicht mehr vorkommen. 😉  
Komplexität – Blogparade PM Camp Berlin 2015

Komplexität – Blogparade PM Camp Berlin 2015

Die Kollegen vom PM Camp Berlin haben zur Blogparade aufgerufen. Ihr diesjähriges Motto lautet Komplexität – reduzieren oder erhöhen? Wenn ich mich dem Thema Komplexität annähere, ist mein erster Gedanke Komplexität überhaupt zu erkennen. Um sie zu erkennen muss zuerst der Begriff klar sein:1
Komplexität bezeichnet allgemein die Eigenschaft eines Systems oder Modells, dessen Gesamtverhalten man selbst dann nicht eindeutig beschreiben kann, wenn man vollständige Informationen über seine Einzelkomponenten und ihre Wechselwirkungen besitzt. Der Begriff leitet sich ab von lateinisch complexum, Partizip Perfekt von complecti ‚umschlingen‘, ‚umfassen‘ oder ‚zusammenfassen‘. Dabei handelt es sich um ein Kompositum aus der Präposition lateinisch cum ‚mit‘, oder ‚zusammen mit‘ und plectere ‚flechten‘ oder ‚ineinander fügen‘ im Sinne von ‚verflochten‘, ‚verwoben‘.
Es geht also um Systeme, die eine Vielzahl von miteinander wechselwirkenden Einzelkomponenten enthalten. Wenn die Komponenten und / oder Wechselwirkungen nicht bekannt sind, heißt das noch nicht, dass das System komplex ist. Es ist erst dann komplex wenn auch mit vollständigem Wissen eine Beschreibung oder Vorhersage des Verhaltens nicht möglich ist. Unwissenheit macht also noch keine Komplexität. Zu Beginn jedes Projektes besteht die Hauptaufgabe darin Unbekanntes aufzufinden. Erst im Laufe des Projektes kann zwischen Kompliziertheit und Komplexität unterschieden werden. Um nicht gleich vom Schlimmsten auszugehen, könnten mann/frau mit der Annahme beginnen, dass es “nur” kompliziert werden wird. An dieser Stelle möchte ich noch auf einen älteren Text verweisen, in dem ich auf die Unterscheidung zwischen kompliziert und komplex eingehe: Komplexität wird überbewertet Meines Erachtens wird zu oft mit zu hohem Einsatz gegen nicht vorhandene Komplexität gekämpft. Wenn es dann mal wirklich komplex wird, helfen ohnehin nur Vereinfachung bzw. schlanke Methoden und Werkzeuge. Wenn der Komplexität mit komplizierten Methoden begegnet wird, kommen nur weitere Variablen ins Spiel, die das System noch unvorhersehbarer machen. In diesem Zusammenhang fällt mir eine historische Science-Fiction Geschichte von Stanislaw Lem2 ein. In der Geschichte Ananke3 beschreibt er den Absturz eines neuen Raumschiff-Typs. Die Ursache für den Absturz liegt im Hauptcomputer, der versucht die Situation mittels umfassender Abfragen aller technischen Parameter in den Griff zu bekommen und sich dabei selbst die Rechenkapazität beschneidet, bis er nicht mehr in der Lage ist, in Echtzeit zu reagieren.4 Als die Protagonisten der Geschichte den Unfall analysieren wird ein Vergleich mit einem General gezogen, der immer mehr Soldaten als Melder und Kundschafter abstellt, um besser informiert zu sein und am Ende nicht mehr genügend Truppen zum Kämpfen hat und dadurch die Schlacht verliert. Ich denke wir sollten in komplexen Kontexten diesen Fehler nicht begehen sondern mehr Mut zur Lücke zeigen. Auf dem PM Camp Berlin von 10. bis 12. September 2015 besteht die Gelegenheit sich diesen Mut zu holen.

 

  1. Wikipedia Komplexität []
  2. Stanislaw Lem: Pilot Pirx, Erzählungen []
  3. Wikipedia: Pilot Pirx, Ananke []
  4. Ein derartiger Effekt trat z.B. durch einen Fehler im Handbuch auch bei der Mondladung von Apollo 11 auf. []
© pentaeder 2019 / 2020