Agiles Projektmanagement

Was ist agiles Projektmanagement?

Agiles Projektmanagement ist eine Alternative zu den traditionellen Projektmanagement-Werkzeugen. Und auch eine Alternative zum Ad-hoc-Projektmanagement, bei dem auf jedes Planen verzichtet wird.

Seine Grundlagen sind:

  • die agilen Werte,
  • agile Prinzipien und
  • agile Praktiken

Setzt eine Organisation agiles Projekt­management ein, nutzt sie ein „agiles Vorgehens­modell“. Darin werden verschiedene agile Praktiken zu einer Methode kombiniert.

Das am weitesten verbreitete agile Vorgehens­modell ist Scrum.

Wir wollen hier zwei wichtige Fragen klären:

Worauf kommt es bei agilem Projekt­management wirklich an? Auf das Meistern der agilen Techniken oder Praktiken?
Oder eher das Verständnis der Grund­prinzipien? Und auf Kreativität und Flexibilität im Umgang damit?

Wie funktionieren agile Methoden außerhalb der Software-Programmierung? Bei Digitali­sierungs­projekten, Bürokratie­abbau oder der Produkt­ent­wicklung. In Branchen wie Versicherungen, Handel, Maschinen­bau oder Chemie.

Projekte, die nicht für agile Methoden geeignet sind

Bei manchen Projekten wird das Projektergebnis zum Projektbeginn detailliert festgelegt. Dies geschieht in der frühen Projektphase, der Projektdefinition. Denken Sie an den Hausbau. Zuerst entwickeln Architekt und Fachingenieure einen  Bauplan. Anschließend wird die Ausführung geplant. Der Plan legt fest, welches Gewerk in welchem Zeitabschnitt von wem erstellt wird.

Dabei gibt es eine Reihenfolge, die strikt einzuhalten ist: Das Fundament muss fertig sein, bevor der Rohbau beginnen kann. Der fertige Rohbau ermöglicht den Beginn des Innenausbaus.

Diese Art Projekte hat folgende Merkmale:

  • Das Projektergebnis und seine Eigenschaften können / müssen vor Umsetzungsbeginn beschrieben und festgelegt werden.
  • Die Projektschritte (Gewerke) müssen einer festen Reihenfolge / festen Terminen folgen.
  • Dauer und Aufwand der einzelnen Abschnitte und Aufgaben können mit Hilfe von Erfahrungswerten geschätzt und geplant werden.
  • Die Projektressourcen (Handwerker im Beispiel) müssen Monate vorher wissen, wann sie an der Reihe sind. Nur so können sie ihre Kapazitäten und Aufträge planen.

Projekte, bei denen Agile überlegen ist

Bei einem anderen Projekt-Typ spielen Unsicherheit und Komplexität eine wichtige Rolle. Unsicherheiten über

  • Dauer und Umfang der zu erledigenden Arbeit und der Teilaufgaben.
  • Anforderungen, Erwartungen und Bedürfnisse der Projektkunden und anderer „Stakeholder“.
  • Ideen und Erkenntnisse, die sich im Projektverlauf ergeben werden.

In diese Kategorie fallen die meisten Change-, Entwicklungs- und Innovationsprojekte. Bei ihnen sind frühe, detaillierte Festlegungen weder möglich noch zielführend.

Genau für diesen Projekttyp ist das agile Projektmanagement die Methode der Wahl.

Der Unsicherheit und Komplexität begegnet Agilität mit den Konzepten:

  • Iterativ-inkrementelles Vorgehen (Umsetzung der Anforderungen in Lern- und Feedback-Schleifen)
  • Selbstorganisation, selbstorganisierte Teams (Schnelles Entscheiden, Reagieren und Korrigieren)
  • Agiles Anforderungsmanagement (User Stories statt Lastenhefte)

Gebräuchliche Begriffe im agilen Projektmanagement

Wie jedes Feld hat auch das agile Projektmanagement seine eigenen Begriffe, dabei werden die englischen Ausdrücke benutzt. Sie können sich ein Glossar, ein Begriffsbezeichnis hier herunterladen.

Planbarkeit und seine Grenzen

Umfangreiche Projekte werden klassisch mit Hilfe spezieller Software gesteuert. Nachdem alle Planungsdaten erfasst sind, erzeugt die Software einen Ablaufplan, als Tabelle oder als Diagramme. Üblich sind Balkendiagramme (Gantt-Diagramme) und Netzpläne (PERT-Diagramme).

Die Diagramme zeigen den Projektmitarbeitern, von wann bis wann sie welche Projektaufgaben erledigen sollen. Projektmanagern helfen sie, die fristgerechte Erledigung zu überprüfen.

Dauert eine Aufgabe länger als geplant,  sucht die Projektleiterin nach Wegen, die Auswirkungen auf die folgenden Aktivitäten und den Gesamtplan zu minimieren. Sie gibt die Verzögerung in die Planungssoftware ein – und die berechnet einen “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 ruft so einen Dominoeffekt hervor.

Anders, wenn ein Haus in Eigenleistung, mit Freunden und Verwandten gebaut wird. Die sind erstens flexibler und zweitens „multifunktional“. Das heißt, der Einzelne kann für mehrere Gewerke eingesetzt werden.

Unter solchen Bedingungen, kann agiles Projektmanagement seine Stärken entfalten.

Aus der Dreigroschenoper

Ja, mach nur einen Plan!
Sei nur ein großes Licht!
Und mach dann noch ’nen zweiten Plan
Gehn tun sie beide nicht.

Kurzer agiler Wissens-Check

Wann funktioniert planungsorientiertes Projektmanagement?

Wir sehen am Beispiel des Hausbaus, dass traditionelle Projekte hohe Planbarkeit verlangen. Das Projektergebnis steht bei Umsetzungsbeginn fest. Es ist detailliert beschrieben.Traditionelles Management bedingt, dass „das Projekt diszipliniert dem Plan folgt“. Überraschungen sind nicht vorgesehen.

Wann ist detaillierte Planung erforderlich?

Klassische Planung ist nötig, wenn wichtige Projektressourcen spezialisiert sind und Terminpflichten außerhalb des Projektes haben.Solche Projektressourcen können, bei Bauprojekten, Handwerker und Subunternehmer sein.Bei Entwicklungsprojekten kann es sich um ein Labor oder eine Testanlage,externe Dienstleister,Experten, die in mehreren Projekten parallel arbeiten oderMitarbeiterinnen, die dem Projekt nur zeitweise zur Verfügung stehenhandeln.

Welche Projekte lassen sich nicht klassisch durchführen?

Projekte, bei denen das Ziel, das Projektergebnis nicht sehr früh konkretisiert und fixiert werden kann. Projekte, bei denen vom Start zum Ziel Überraschungen zu erwarten sind.

Iterativ-inkrementelles Entwickeln

Beim Entwickeln in Inkrementen wird das Produkt gedanklich in Teile (= Inkremente) zerlegt. Die Teile werden einzeln entwickelt und später zusammengefügt.

Wunderbar illustriert wird das durch Jeff Pattons’ Beispiel der Mona Lisa.

Das Zerlegen von Aufgaben in Teilaufgaben ist auch im klassischen Projektmanagement üblich.

In agilen Projekten haben wir zwei Besonderheiten:

Wir arbeiten nicht mit Aufgaben, sondern mit testbaren Produktteilen. Was testfähig bedeutet, hängt vom Projektthema ab.

Entwickelte Teile werden den Projektkunden präsentiert. Ein Bericht genügt nicht. Die Stakeholder sollen Resultate anschauen, anfassen, ausprobieren. Und dann ihre Eindrücke und Bewertungen berichten; genau wie Ideen, die sie dabei haben. Bei abstrakten Projektthemen müssen die entwickelten Inkremente kreativ „erlebbar“ gemacht werden.

Da Vinci hätte einen Kopf der Mona Lisa als Teil des Ganzen gemalt und seinem Auftraggeber gezeigt. Der hätte vielleicht Änderungswünsche gehabt, wie:

  • ein anderes Größenverhältnis zwischen Figur und Hintergrund.
  • eine andere Stimmung durch gedämpfte Farben.
  • ein anderer Gesichtsausdruck.

Es fällt Anwendern schwer, auf Anfrage ihre eigenen Bedürfnisse zu begreifen und in Worte zu fassen.

Einfach ist dagegen, eine Vorlage zu kritisieren und Änderungswünsche zu formulieren. Und im agilen Projekt machen wir das in mehreren Schleifen.

Bei iterativer Vorgehensweise arbeiten wir in mehreren Feedback-Schleifen. Jede Schleife, jede Iteration wird konkreter, detaillierter, hat eine höhere Qualität.

Auch Iterationen sollen nutz-, test-, bewertbar sein.

Am Beispiel der Mona Lisa: Schon die Skizze (Stufe 1) kann ein marktfähiges Produkt sein.

Der Auftraggeber kommentiert die erste Iteration vielleicht so:

  • Die Darstellung soll mehr von der Landschaft zeigen.
  • Die Körperhaltung soll aktiver, dynamischer sein.
  • Der Standpunkt des Betrachters soll tiefer liegen, damit mehr Himmel ins Bild kommt.

Damit sind wir ... an einem guten Punkt zum Mitdenken.

Quiz

In welchen Haupt-Iterationen könnten die folgenden Projekte durchgeführt werden?

  • Ein Change-Projekt, durch das Teams im Vertriebsinnendienst als selbstorganisierte Teams arbeiten.
  • Ein Entwicklungsprojekt für einen neuen, innovativen Prozess zur Personalbeschaffung.

Agiles Projektmanagement und iterativ-inkrementelles Vorgehen

Keine Überraschung hier: Iterativ-inkrementell kombiniert die beiden vorherigen Ansätze. Einzelne Teile des Gesamtvorhabens werden in Qualitätsstufen entwickelt; bis das Gesamtpaket in der gewünschten Qualität umgesetzt ist. In Scrum-Projekten wird am Ende eines Sprints ein testbares Ergebnis geliefert. Mindestens eins, das dem Team und den Projektkunden zu neuen Einsichten oder Ideen verhilft.

Anforderungen in sinnvolle Teile und Qualitätsstufen zu zerlegen ist plausibel. Es bei verschiedenen Projektthemen elegant zu nutzen, lernen Agilisten mit der Zeit und zunehmender Routine.

Was sind die Vorteile des iterativ-inkrementellen Vorgehens?

Beim rein inkrementellen Projektablauf muss das Endprodukt schon zu Beginn definiert sein.

Beim iterativen Ablauf können wir 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 ob wir das Gelernte nutzen, um den bestehenden 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 alternative Varianten entwickeln und testen.

Um Agiles Projektmanagement erfolgreich zu nutzen ...

  • sollten Sie prüfen, ob die Arbeitsmethodik (agil, hybrid, traditionell) der Engpass zu mehr Projekt-Performance ist. Oft sind es andere Probleme, die (vorher) gelöst werden müssen. Die beiden häufigsten Probleme: Verzettelung, zu viele Projekte parallel in Bearbeitung und die Art, wie in der Organisation benötigte Entscheidungen getroffen werden.
  • sollten Teams die Freiheit haben, das Agile-Vokabular an den eigenen Sprachgebrauch anzupassen.
  • ist es unerläßlich, die Anwender kompetent auszubilden, in einem ein- bis zweitägigen Training oder Seminar in agilem Projektmanagement.
  • müssen Team und Entscheider agile Methoden verstehen – aber nicht dogmatisch nutzen. Das sichern Sie am besten durch ein Agiles Coaching nach dem Training.
  • müssen die Anwender wissen, dass Agilität nicht nur Scrum ist. Die Prinzipien sind wichtiger als Werkzeuge oder Methoden.

Agile Methoden setzen sich durch

Das bestätigt eine Forrester-Studie schon 2013:

„Agilität […] setzt sich außerhalb der Software-Entwicklung durch. Manche Unternehmen setzen Agile in Bereichen ein, wie:

  • Portfolio-Management
  • Projektmanagement
  • Lieferanten-Management
  • Beschaffung […]“

Für agil durchgeführte Projekte sind zahlreiche Vorteile belegt. Dazu gehören Geschwindigkeit, Kosteneinsparungen, Produktivität, höhere Anwender-/Kundenorientierung.

Agiles Projektmanagement liefert unter anderem in diesen Branchen

  • Automobilindustrie
  • Automobilzulieferer
  • Dienstleistungen
  • Finanzen und Versicherungen
  • Einzelhandel
  • Maschinenbau
  • Chemieindustrie
  • Lebensmittelindustrie
  • Medizintechnik
  • Kunststoffverarbeitung
  • Metallverarbeitung
  • Spielwaren
  • Pharmazie

Das agile Manifest

Im agilen Manifest sind die 4 fundamentalen Werte des agilen Projektmanagements und des agilen Arbeitens definiert. Das Format ist eine Gegenüberstellung von klassischen PM-Paradigmen und den agilen Positionen.

Dabei geht es nicht um Schwarz-Weiß-Denken. Klassische Paradigmen, wie standardisierte Prozesse, einheitliche Werkzeuge oder detaillierte Dokumentation, sollen nicht abgeschafft werden. Sie sollen im agilen Projekt lediglich die agilen Paradigmen nicht dominieren.

Die richtige Balance ändert sich von Projekt zu Projekt, auch abhängig von den Fähigkeiten der Teams und den Rahmenbedingungen der Organisation.

Menschen und Interaktion vor Prozesse und Werkzeuge

  • Definierte Prozesse und einheitliche Werkzeuge sind perfekt für sich wiederholende Abläufe. Ist das Ziel jedoch, etwas Neues, Innovatives zu entwickeln, schränken sie oft zu sehr ein oder funktionieren nicht.
  • Im agilen Projektmanagement sind die Erfolgstreiber:
  • menschlicher Einfallsreichtum, menschliche Vorstellungskraft und
  • flexible, motivierte Teamarbeit.
  • Die damit verbundenen Freiräume für Teams und Einzelne ermöglichen die Leistungen, die erfolgreiche agile Projekte ausmachen.


Funktionierendes Produkt vor umfassende Dokumentation

In Produktinkrementen und/oder -iterationen manifestierte Anforderungen sind Grundlage für weiteres Verbessern. Oft haben sie auch schon einen wirtschaftlichen Wert.

Detaillierte Dokumentation dagegen friert den Status ein. Um das bestmögliche Projektergebnis zu erzeugen, brauchen die Entwickler Freiheit und Flexibilität weit in das Projekt hinein.


Zusammenarbeit mit Kunden vor Vertragsverhandlungen

Bei klassischen Auftragsprojekten wird über Pflichtenhefte, Lastenhefte und Spezifikationen das zu liefernde Produkt in Verhandlungen genau definiert. Das soll Risiken und Nachteile für beide Parteien reduzieren. Ganz besonders geht es um das Risiko von Nachforderungen. Jede Partei versucht, sich für den Fall einer gerichtlichen Auseinandersetzung eine starke Position zu verschaffen.

Das ganze Verfahren ist sehr aufwändig. Wenn neue Erkenntnisse im Projektverlauf zu Änderungen des Projektziels führen, entstehen trotzdem neue Unsicherheiten.

Eine agile Zusammenarbeit zwischen Auftragnehmer und Auftraggeber geht dagegen in Schritten vor. Das kann etwa so gestaltet sein:

Beide Parteien einigen sich darauf, das Projekt mit agilem Projektmanagement durchzuführen. Sie legen zu Beginn jeder Arbeitsphase die Vergütung und eine Liste priorisierter Teil- und Zwischenergebnisse fest. Neben den praktischen Ergebnissen der Phase hat an deren Ende:

  • der Auftragnehmer bessere Informationen zum Aufwand und
  • der Auftraggeber bessere Informationen über Resultate, die er nach einem definierten Zeitraum und für ein definiertes Budget erwarten kann.

Auf der Grundlage werden wieder eine priorisierte Liste und ein Budget für die nächste Phase vereinbart.


Auf Veränderung reagieren vor Planbefolgung

Im agilen Projektmanagement wird das Projektergebnis in Lernschleifen entwickelt.

Dieses Prinzip bedingt bereits, dass Ergebnisse und Erkenntnisse einer Arbeitsphase Einfluss haben auf:

  • die Ziele und damit
  • die Aktivitäten folgender Arbeitsphasen.

Während Änderungen von Anforderungen in klassischen Projekten ein Störfaktor sind, sind sie für das agile Mindset positiv.

Sie sind eine Gelegenheit, die Bedürfnisse der Projekt-Stakeholder noch besser zu bedienen.

Beim Wechsel von traditionellen Methoden zum agilen Projektmanagement erfordert dies ein neues „mindset“. Ist der Übergang geschafft, wird das neue Paradigma als befreiend erlebt.

12 Agile Prinzipien

Aus den 4 agilen Werten werden 12 agile Prinzipien abgeleitet. Die Prinzipien beschreiben, wie die Werte in agilen Projekten auf der Verhaltensebene umgesetzt werden.

Jedes der Prinzipien kann einer der folgenden Kategorien zugeordnet werden:

  • Erfüllung der Kundenbedürfnisse,
  • Ergebnisqualität,
  • Teamarbeit und
  • Projektsteuerung.

Agile Praktiken

Agile Praktiken konkretisieren die agilen Prinzipien hin zu Handlungsanweisungen. Ein Beispiel:

Aus dem 12. agilen Prinzip leitet sich, zum Beispiel, die agile Praktik der Retrospektiv-Besprechungen ab. Diese werden, beispielsweise bei Scrum, nach jeder Arbeitsphase, jedem Sprint als Teambesprechung abgehalten.

In den Retrospektiven (kurz: Retros) suchen die Entwickler nach Wegen, die Geschwindigkeit zu erhöhen. Also in den nächsten Arbeitsphasen ein größeres Volumen an Teil- und Zwischenergebnissen zu entwickeln.

Agiles PM für nicht-IT-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,
  • gekoppelte Dienstleistungen,
  • das Marketing-Konzept,
  • das Supply-Chain-Konzept (Materialflüsse in-bound und out-bound) oder
  • die benötigten Produktionstechnologie und -technik.

Wenn aber die verbreiteten Fehler bei Entscheidungen unter Unsicherheit ab morgen nach dem Kanban-Prinzip gemacht werden, ersetzen Sie lediglich die bisherigen Probleme durch andere.

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.

Erforderliche Anpassungen

Die stetige Verbreitung des agilen Projektmanagements außerhalb 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.

SolidCreativity's Pascal Jarry zu den agilen Anfängen

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 Methoden 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 Veröffentlichungen geschrieben, dann Bücher. Wir probierten aus, und wir passten an. Wir waren ohnehin agil – aber in diesem 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 entwickelnden und innovierenden Organisationen zugänglich, mit dem Fokus auf non-IT Projekte.”