Agiles Projektmanagement für non-IT Projekte

„Agile“ laut Wörterbuch

von großer Beweglichkeit zeugend; regsam und wendig

Viele Organisationen sind enttäuscht vom Projektmanagement ihrer Entwicklungsprojekte. Es ist ihnen zu starr, zu langsam und zu bürokratisch. Sie wollen ihre Zeit in die Entwicklung marktfähiger Produkt investieren – und nicht in die Ausarbeitung von Projektplänen, die nach einer Woche schon wieder Makulatur sind.

So schaut man interessiert auf die Softwarebranche. Hier haben sich „agile Methoden“ für die Produktentwicklung fest etabliert: Projekt-Tools wie Scrum und Kanban. Die Erfolgsquote agiler Softwareprojekte beträgt 300% der Erfolgsquote traditioneller Projekte. Die Entwicklungen werden schneller und mit besseren Ergebnissen abgeschlossen.

Aber funktionieren diese Methoden auch für nicht-IT-Projekte? Bei der Entwicklung von Fahrzeugtechnik, Flugzeugcockpits, Reha-Programmen oder Kartoffelchips?

Kartoffelchips
kreativ2

Grundlagen des traditionellen Projektmanagements

Bei vielen Projekten wird das Projektergebnis zum Projektbeginn festgeschrieben. Dies geschieht in der frühen Projektphase, der Projektdefinition. Der Bau eines Hauses ist ein Beispiel. Zuerst entwickeln Architekt und Fachingenieure den detaillierten Bauplan. Anschließend wird die Ausführung geplant, also welches Gewerk in welchem Zeitraum erstellt werden soll.

Dabei gibt es natürlich eine Reihenfolge, die unbedingt einzuhalten ist: Das Fundament muss fertig sein, bevor der Rohbau beginnen kann – und der fertige Rohbau ist Voraussetzung für den Beginn des Innenausbaus.

Halten wir wichtige Merkmale eines solchen Projektes fest:

  • Das Endprodukt und seine gesamten Eigenschaften können vor Umsetzungsbeginn genau beschrieben und festgelegt werden.
  • Die Umsetzung der Projektschritte (Gewerke) muss einer festen Reihenfolge gehorchen.
  • Die Dauer der einzelnen Bauabschnitte und Gewerke kann durch Erfahrungswerte zuverlässig geplant werden.
  • Die Projektressourcen (Handwerker) müssen – für ihre Kapazitäts- und Auftragsplanung – Monate vorher wissen, wann ihr Gewerk an der Reihe ist.

Planung im traditionellen Projektmanagement

Umfangreichere Projekte werden mit Hilfe spezieller Software gesteuert – oder versucht zu steuern. Nachdem alle Planungsdaten eingegeben sind, erzeugt die Software einen Ablaufplan. Diese Diagramme – wie Gantt- oder PERT-Charts – visualisieren den geplanten Ablauf des Projektes.

Die Diagramme zeigen den Projektressourcen, von wann bis wann sie welche Arbeitsschritte erledigen sollen. Projektleitern helfen sie, die fristgerechte Erledigung zu überprüfen. Bei Abweichungen – die so gut wie immer negativ sind – sucht der Projektmanager nach Wegen, die Auswirkungen auf die folgenden Aktivitäten zu minimieren. Ansonsten gibt er die Abweichung in die Planungssoftware ein – und diese berechnet dann den „neuen“ Plan.

Leider ruft der neue Plan meist Konflikte mit anderen Projektressourcen hervor: Verspätet sich der Elektriker mit der Verlegung der Elektroleitungen, können die Putzer und Maler erst später anfangen. Zu ihrem neu berechneten Termin haben sie aber schon einen anderen Auftrag angenommen. Eine Planabweichung kann so einen regelrechten Dominoeffekt erzeugen.

Projektplanung
Die vier besten Tools für mehr Innovationskraft

Wie planbar sind Entwicklungsprojekte?

An dieser Stelle drängen sich drei Fragen auf:

Wir haben am Beispiel der Handwerker beim Hausbau gesehen, dass lineares Projektmanagement von hoher Planbarkeit abhängt. Davon, dass das Projektergebnis bei Umsetzungsbeginn feststeht und genau beschrieben ist. Und dass „das Projekt sich genau an den Plan hält“

Die lineare Planung von Projektanfang bis Projektende wird nötig, wenn die Projektressourcen sehr spezialisiert sind und Terminverpflichtungen ausserhalb des Projektes haben.

Ist es also möglich UND erforderlich, ein Entwicklungsprojekt top-down zu planen?

Für die große Mehrzahl der innovativen Projekte wird man diese Frage nicht bejahen. Die Gründe liegen in ihrer Unsicherheit und Dynamik, ihrem oft hohen Anteil an Generalisten im Projekt und der Tatsache, dass das Problem „Multitasking“ meist hausgemacht ist.

Wir Menschen haben ein Bedürfnis nach maximaler Sicherheit und Kontrolle. Das ist sehr hilfreich, um den Status Quo zu verteidigen – kann aber völlig kontra-produktiv sein, wenn es darum geht, die Zukunft zu gestalten.

Risikomanagement

„Der Bär, den du sieht, ist nicht derjenige, der dich fressen wird,“ sagt ein altes französisches Sprichwort. Darwin schrieb: „Nicht die stärksten oder intelligentesten Spezies überleben, sondern diejenigen, die sich am besten an veränderte Bedingungen anpassen können.“ Für das Management bedeutet dies: Wir brauchen zeitnahe Informationen über veränderte Bedingungen und die Flexibilität unsere Pläne jederzeit zu ändern.

Dynamik und Unsicherheit

Das Entwicklungsziel ist in der Regel dynamisch. Es verändert sich beispielsweise im Projektverlauf abhängig von Ergebnissen von Experimenten, neuen Informationen oder Prioritäten.

Damit wird auch der Umsetzungsplan dynamisch.

Spezialisten oder Generalisten

In vielen Entwicklungsprojekten haben die Projektmitarbeiter – zumindest teilweise – überlappende Kompetenzen. Das bedeutet, in Entwicklungsprojekten können wir statt Übergabepunkten auch Phasen der Zusammenarbeit haben.

Multitasking vs. Monotasking

Die Anzahl aktiver Projekte eines Projektmitarbeiters und deren Priorisierung ist letztlich eine Frage von Prioritäten und Entscheidungen. Es ist nachgewiesen, dass höhere Auslastung oft zu weniger Durchsatz führt.

ad-hoc

ist lateinisch für „spontan, aus dem Augenblick heraus“.

Der abgeleitete Begriff „Adhokratie“ bezeichnet einen Gegenentwurf zur Bürokratie. Also eine Organisationsform maximaler Flexibilität und Spontaneität.

Planlos durchs Projekt: Ist Ad-hoc-kratie die Lösung?

In manchen Entwicklungsorganisationen läßt sich folgende Historie feststellen:

  1. Die Organisation ist noch sehr klein. Die Ad-hoc-Vorgehensweise ohne große Planung funktioniert und die Organisation innoviert sehr erfolgreich.
  2. Die Organisation ist stark gewachsen. Die Koordination wird schwieriger. Eine professioneller werdende Unternehmensführung versucht Unsicherheit zu reduzieren und verlangt Pläne, Prognosen und deren Einhaltung.
  3. Als Lösung werden die Entwickler in linearem Projektmanagement geschult, eine Planungssoftware wird angeschafft.
  4. Eine Verbesserung bleibt aus. Die Methoden werden als unzureichend bewertet. Planung und Kontrolle werden verfeinert und intensiviert.
  5. Die Projektmitarbeiter verbringen immer mehr Zeit mit den Projektwerkzeugen statt mit dem Projektgegenstand. Die Frustration wächst, die Projekte werden immer länger und die Erfolgsquote immer geringer.
  6. Rückkehr zur Adhokratie.
  7. Erneute Erkenntnis, dass sich so keine Ergebnisse erzielen lassen, die den Entwicklungsaufwand rechtfertigen.

Agiles Projektmanagement mit Scrum: Koordination UND Flexibilität

Agiles Projektmanagement überwindet den Widerspruch, das kaum Planbare planen zu müssen. Agilität sucht im Projektverlauf aktiv nach weiteren Erkenntnissen, die das Produkt verbessern. Agile Entwicklung mit Scrum verläuft in Iterationen – sich wiederholenden Schleifen von Lernen und Umsetzen. Im agilen Projekt werden sich überlappende Fähigkeiten genutzt – statt das Spezialistentum zu fördern. Statt hierarchisch-zentraler Steuerung und Kontrolle haben wir sich selbst steuernde Teams. Und Mechanismen, die für Transparenz und hohes Engagement sorgen.

Die Veränderung ist nicht immer einfach. Aber die Ergebnisse überzeugen und sind die Hürden einmal überwunden, will kaum jemand zurück in die Zeit vor Agile.

scrum-agile

Agile Produktentwicklung mit SCRUM geht iterativ-inkrementell vor. Was bedeutet das?

Bei einer inkrementellen (oder inkrementalen) Vorgehensweise wird das Produkt zerlegt und stückweise entwickelt. Wunderbar illustriert wird das durch Jeff Pattons‘ Beispiel der Mona Lisa.

agile_inkrementell

Die Zerlegung von Aufgaben in Teilaufgaben ist natürlich auch im linearen Projektmanagement üblich. Bei SCRUM haben wir aber zwei Besonderheiten:

  1. Wir arbeiten nicht mit Aufgaben- sondern mit test-fähigen Produktinkrementen.
  2. Die Inkremente werden den Projektkunden präsentiert – und diese geben ihr Feedback dazu.

Mit inkrementeller Vorgehensweise hätte da Vinci also seinem Auftraggeber den fertig gemalten Kopf der Mona Lisa gezeigt. Dieser hätte für sich damit eine genauere Vorstellung des Gesamtgemäldes entwickeln können. Eventuell hätte er festgestellt, dass der Maler seine Erwartungen nicht richtig verstanden hat – oder dass seine Vorstellung sich geändert hat. So hätte da Vinci den oberen Teil entweder überarbeitet – oder er hätte noch einmal ganz von vorne angefangen, bevor er mit dem Malen des Oberkörpers begonnen hätte. In jedem Fall wäre eine weitere Verschwendung von Zeit und Material vermieden worden.

Inkrementell hätten wir also geklärt. Und was ist „iterativ“?

Bei einer iterativen Vorgehensweise erledigen wir eine Aufgabe in mehreren Schleifen. Dabei nimmt die „Auflösung“ oder die Perfektion mit jeder Schleife zu. Wie oben beschrieben: ein wichtiger Aspekt ist, dass jede Iteration schon ein eingeschränkt nutzbares Produkt darstellt. Am Beispiel unseres Kunstwerks: Schon die Skizze (Stufe 1) könnte ein marktfähiges Produkt sein.

agile_iterativ

Worin liegen die Vorteile einer iterativen Vorgehensweise im Projekt?

Beim rein inkrementellen Projektablauf muss das Endprodukt schon zu Beginn definiert sein. Beim iterativen Ablauf können wir bereits auf Grundlage einer relativ vagen Idee beginnen zu arbeiten. Wir machen etwas und holen Feedback dazu ein. Wir überlegen dann, ob wir darauf aufbauend weiter machen – oder das Gelernte nutzen, um den vorhandenen Teil noch einmal anders neu zu machen oder ihn zu verändern. Ein großer Vorteil: Da wir nicht gleich den gesamten Entwicklungsaufwand betreiben, können wir kostengünstig alternative Varianten entwickeln und testen.

Agile iteratif incremental

Wie kam die Agilität von der Software zur Hardware?

Die agile Produktentwicklung wurde nicht am grünen Tisch entwickelt. Sie ist die Formalisierung von Praktiken, die in den achtziger Jahren bei sich selbst organisierenden Teams beobachtet wurde. Pascal Jarry ist einer der Pioniere, die das Potential der agilen Methoden für die industrielle Produktentwicklung entdeckte. Zuvor leitete er zwanzig Jahre lang auf drei Kontinenten die Entwicklung von Videospielen. Er erinnert sich: „Auf internationalen Konferenzen der Videospieleindustrie tauschten wir Entwicklungsleiter uns aus. Alle hatten dasselbe Problem: unsere Entwicklungsteams waren immer größer geworden. Wir versuchten die Arbeit immer mehr zu professionalisieren und die Teams verloren dabei ihre Kreativität, ihre Motivation und ihre Effektivität.
Die gängigen Methoden verlangten nach mehr Disziplin und Kontrolle. Leider an den falschen Stellen. Wir waren dabei, das System bürokratisch gegen die Wand zu fahren. Wir tauschten unsere Erfahrungen und „best practices“ aus. Dann experimentierten wir mit den Methoden und trafen uns wieder zum Abgleich. Es wurden Papiere geschrieben, dann Bücher. Wir probierten aus, und wir passten an. Wir waren alle ohnehin agil – aber in dem Prozess wurden wir „Agile“.
Die Prinzipien und Werkzeuge der Agilität etablierten sich also in der Softwareentwicklung. Ab 2004, mit meinem eigenen Unternehmen, machte ich diese Werkzeuge allen kreativen und innovierenden Organisationen zugänglich.“

Hier werden agile Methoden bereits erfolgreich für das Projektmanagement in der Produktentwicklung eingesetzt:

  • Automobilindustrie
  • Automobilzulieferer
  • Maschinenbau
  • Chemieindustrie
  • Lebensmittelindustrie
  • Medizintechnik
  • Kunststoffverarbeitung
  • Metallverarbeitung
  • Spielwaren
  • Pharmazie
shutterstock_194994401

Anpassung der agilen Methoden für nicht-IT-Projekte

Die stetige Verbreitung des agilen Projektmanagements ausserhalb der Softwareentwicklung zeigt, daß Agilität und auch Scrum auch dort funktionieren. Als dritter Weg zwischen linearer top-down Planung und der Adhokratie löst Agilität die jeweiligen Probleme der beiden anderen Wege.

Allerdings kann die Einführung von agilem Projektmanagement auch scheitern. Dies geschieht regelmäßig, wenn agile Methoden oder Prinzipien per Gebrauchsanleitung implementiert werden. Zum Beispiel wurde in der Entwicklungsabteilung eines Automotive-Zulieferers SCRUM eingeführt. Die Mitarbeiter (m/w) wurden trainiert. Scrum-Master und Product-Owner wurden ausgewählt und in ihre Rollen eingewiesen. Bei der Erstellung des Product-Backlogs wurde es schon schwierig … und mit Beginn der Sprints setzte komplette Konfusion ein.

Später stellte sich heraus, dass ein Product-Backlog in Form von User-Stories und die Entwicklung in Iterationen für die Projektaufgabe absolut unpassend waren. Ein neuer Berater erkannte das Problem. Er half dem Entwicklungsteam, es zu verstehen und einzuordnen. Gemeinsam wurden die agilen Werkzeuge angepasst – worauf sich die erhofften Resultate endlich einstellten.

Was im ersten Anlauf nicht berücksichtigt wurde:

Nicht-Softwareprodukte zu entwickeln ist anders! Weiter unten beschreiben wir einige der wesentlichen Unterschiede. Eine eins-zu-eins Übertragung agiler Methoden von Software auf physische oder kombinierte Produkte ist sehr oft nicht angeraten.

Die Unterschiede beziehen sich sowohl auf die Entwicklungsaufgabe, als auch das Entwicklungsumfeld. Deshalb ist immer sorgfältig zu prüfen, welche agilen Elemente

  • übernommen werden,
  • angepasst werden oder
  • weggelassen werden.

Am besten in Zusammenarbeit mit Experten, die sowohl mit agilen Werkzeugen als auch mit industrieller Forschung und Entwicklung vertraut sind.

Dann bringt die Verwendung agiler Methoden (fast) allen Entwicklungsorganisationen erhebliche Vorteile.

Für eine erfolgreiche Nutzung der agilen Methoden in der Produktentwicklung …

  • sollten wir Agile gut kennen – aber nicht dogmatisch sein. Wichtige Aspekte sollten wir nutzen und den Rest an die Situation anpassen.
  • passen wir die Sprache der Agilität an die Sprache der Organisation an.
  • ist es unerläßlich, die Anwender gründlich in den relevanten agilen Methoden zu schulen.
  • müssen die Anwender wissen, dass Agilität nicht nur Scrum ist. Der Organisation sollte ein echter agiler Ansatz vorgestellt werden – und nicht nur die einzelnen Werkzeuge.
speed of agility

Agile setzt sich durch … auch ausserhalb der Software-Entwicklung

Das bestätigt auch eine Forrester-Studie aus 2013:

„Agilität wird nicht nur eingesetzt von weltweit führenden Unternehmen – sondern setzt sich ausserhalb der Software-Entwicklung durch … . Manche Unternehmen setzte Agile in Bereichen ein wie: Portfolio Management, Projektmanagement, Lieferantenmanagement, Beschaffung …“

Entwicklungsorganisationen, die Agile einsetzen, stellen folgende Verbesserungen fest:

  • Produktivitätssteigerungen
  • Kosteneinsparungen
  • Höhere Motivation der Projektteams

Die Verbesserungen wurden in diversen Studien nachgewiesen. Aber: es gibt keine Garantien für den Einzelfall. Die Erfahrung zeigt, dass die Qualität und Gründlichkeit der Einführung die größten Auswirkungen auf den Erfolg hat.

Entwicklungsprojekte mit Phasenmodellen organisieren

In vielen Organisationen werden Entwicklungsprojekte mit einem Phasenmodell, wie Stagegate®, organisiert. Dabei wird der Prozess von der Produktidee zur Markteinführung in mehrere Phasen unterteilt. An „Gates“, also virtuellen Toren überprüft ein Entscheidungsgremium, ob das Projekt die Voraussetzungen für die nächste Phase erfüllt. Von dieser Überprüfung hängt die Allokation weiterer Ressourcen ab. Die Gate-Entscheidungen legen fest, ob das Projekt weiter verfolgt oder vorzeitig beendet wird.

Phasenmodell

Dr. Robert G. Cooper, der Stagegate®-Entwickler, veröffentlichte 2014 im Magazin „Research-Technology Management“ den Artikel „What’s next?: After Stage-Gate“. Er erkennt darin an, dass sein Prozess heute um agile Instrumente ergänzt werden sollte. Zwischen den Gates, innerhalb der Entwicklungsphasen, empfiehlt er die Verwendung agil-adaptiver Methoden.

Phasenmodell3

Das ist sicherlich eine Möglichkeit. Allerdings gibt es wesentlich mehr Punkte zu berücksichtigen. Beispielsweise:

  • Wie werden Aufgaben und Kompetenzen zwischen Gatekeepern und Product-Owner koordiniert?
  • Oft läßt sich beobachten, dass nominierte Gatekeeper wenig involviert und risiko-avers sind. Ein agiles Team dagegen hat einen starken Vorwärtsdrang. Wie wird damit umgegangen?
  • Ein typisches Entwicklungsprojekt besteht aus diversen Schichten (technische Produktentwicklung, Produktionstechnologie, Supply Chain, Marketing, Serviceplan …). Wie läuft die Synchronisierung, wenn es gleichzeitig agile Sprints und Gate Reviews gibt?

Die Antwort fällt leichter, wenn das zu integrierende Stage-Gate®-Modell eine der „leichteren“ Varianten ist.

Was macht industrielle F+E anders … und wie können wir trotzdem agil sein?

Die Schichten industrieller F+E-Projekte

Bei den meisten Software-Entwicklungen besteht das Endresultat aus zwei Schichten: Programmcode und Datenbanken. Mit der Erstellung des Codes und der Datenbanken ist das Produkt gleichzeitig entwickelt und produziert. Industrielle Entwicklung ist meist vielschichter. Das Ergebnis eines Entwicklungsprojektes kann aus diversen „Modulen“ bestehen. Die Module interagieren sowohl im fertigen Produkt als auch während der Entwicklung miteinander.
Dadurch ist der Koordinationsbedarf zwischen den verschiedenen „Entwicklungssträngen“ oft viel größer als bei Softwareprodukten. Solche Schichten, oder Entwicklungsstränge können sein:

  • das technisch-physische Produkt,
  • ein funktional-ästhetischen Produktdesign,
  • ein Verpackungsdesign,
  • assoziierte Dienstleistungen,
  • das Marketing-Konzept,
  • das Supply-Chain-Konzept (Materialflüsse in-bound und out-bound) oder
  • die benötigten Produktionstechnologie und -technik.
thumbs up 2

Mit der Anzahl der Produktschichten und Entwicklungsstränge steigt der Abstimmungsbedarf. Oft macht es Sinn, in verschiedenen Entwicklungssträngen verschiedene Projektmanagement-Werkzeuge einzusetzen: Die technische Entwicklung setzt Scrum ein, Supply-Chain und Marketing-Entwicklung profitieren von Kanban, die Designentwicklung funktioniert organisationsbedingt nur mit Adhoc-kratie – als Beispiel.

Dabei ist zu klären, wie und wann Koordination und Integration stattfinden: z. B. in festen Zyklen, wenn ein Projektstrang einen Meilenstein erreicht hat, wenn alle betroffenen Stränge fertig sind … . Alles Fragen, die sich bei Softwareprojekten kaum stellen.

Es handelt sich dabei nicht um Argumente, nicht auf Agilität zu setzen. Ganz im Gegenteil: je komplexer das Projekt, umso mehr kann es durch agile bottom-up Koordination profitieren. Es geht nur darum, dass agile Werkzeuge differenzierter und „stärker adaptiert“ zum Einsatz kommen sollten, als im Standard-Softwareprojekt.