Wenn es doch ein agiles Projekt sein muss …

Wie geht?

Im P4-Framework wird das Projekt durch die Entwicklung einer Produkt- oder Applikationsversion ersetzt. Die unterschiedliche Bezeichnung soll dazu führen, dass Entwicklungsvorhaben inhaltlich zusammenhängen und nicht mit mehr oder weniger beliebigen, und manchmal sogar widersprüchlichen Zielen definiert werden.

Was aber, wenn die Organisation noch in Projekten denkt? Können wir dann nicht auch agil vorgehen? Wenn ja, welche Voraussetzungen und Randbedingungen sollten dann beachtet werden? Diese Fragen sollen hier beantwortet werden.

Zuerst betrachten wir die über den Projekten liegende Struktur der Organisation. Wird diese noch nach klassischen Prinzipien geführt, wird das „agile“ Projekt einen schweren Stand haben. Wir müssen daher die folgenden „Transitionen“ herbeiführen:

  • Fixer Umfang mit vorgegebenen oder „verhandelten“ Terminen >>> variabler Umfang und iterativ-inkrementelles Vorgehen
    • Jährliche Budgetplanung >>> Anpassung an die sich ändernde (Projekt-) Portfolio-Planung, mindesten vierteljährlich
    • Jährliche Planung der Entwicklungvorhaben >>>  Anpassung an die sich ändernde (Projekt-) Portfolio-Planung, mindesten vierteljährlich
  • Zu viele gleichzeitig laufende Projekte >>> Fokus der Teammitglieder auf ein Projekt (oder sehr wenige) und Priorisierung innerhalb des variablen Umfangs
  • Allmächtige Chefs >>> Gewaltenteilung und selbstorganisierte Teams

Gehen wir davon aus, dass wir die Hürde genommen haben, schauen wir nach den verschiedenen Arten von Projekten, die in der Organisation durchgeführt werden:

  • Organisatorische Veränderungsprojekte
  • Entwicklung eines oder mehrerer neuer Produkte
  • Entwicklung einer Plattform, auf der neue Produkte entwickelt werden sollen
  • (Weiter-) Entwicklung einer neuen Technologie
  • Entwicklung eines neuen Produkts auf Basis einer Plattform
  • Entwicklung eines neuen Moduls für eine Plattform
  • Entwicklung eines neuen Produkts auf Basis einer oder mehrere Technologien
  • Erweiterung eines bestehende Produkts um eine oder mehrere Funktionen

In den bisherigen Projekten wurden die verschiedenen Projektarten und Ziele gerne in ein einiges Projekt hinein definiert, wodurch sie sehr groß wurden. Auch wurden solche Projekte nur als erfolgreich betrachtet, wenn alle Ziele erreicht wurden, was durch die sich widersprechenden Ziel häufig gar nicht möglich war.

In P4 müssen diese verschiedenen Ziele klar voneinander getrennt und priorisiert werden. Dadurch werden die Vorhaben kleiner und können fokussiert umgesetzt werden.

Wie laufen agile Projekte ab?

Projektstart

Wie auch bei der Entwicklung von Produktversionen, wird eine Vision des Projekts benötigt. Die Vision beschreibt …

  • den Umfang (Scope) der Entwicklung, also die Ziele und Lieferobjekte, wie erwähnt in einer vereinzelten und mit Business-Wert geschätzten Liste
  • den Kontext, also die Umgebung des zu entwickelnden Produkts, seine umgebenen Systeme und deren Schnittstellen, seine bestimmungsgemäße Verwendung, sowie die Märkte und die sich daraus ergebenden Normen und Standards
  • die wichtigsten Stakeholder (u.a. die Nutzer und Kunden, sowie interne Abteilungen), also die Personen die ein Interesse an dem Projekt haben
  • Welche Hauptfragestellungen soll das Projekt beantworten? P4 verwendet hierfür ja die Wissenslücken (Knowledge Gaps)

Projektorganisation

Soweit diese nicht bereits durch das P4-Framework definiert und eingeführt sind, müssen nun weitere Festlegungen getroffen werden:

  • Welche Personen und Rollen werden vorgesehen? In P4 sind dies die Product-Owner, System-Engineers und Scrum-Master.
  • Bei der Team-Aufstellung ist darauf zu achten, dass die deutliche Mehrheit der Team-Mitglieder Vollzeit im Team sind. Spezialisten können als Extended-Team-Mitglieder mit mehr als 30% teilnehmen, oder wenn nicht anders möglich, als Supporter.
  • Wenn mehrere Teams beteiligt sind: Wie sind diese Teams aufgestellt? Wie sehen die Zusammenarbeits- und Lieferbeziehungen zwischen den Teams aus?
  • Welche bereits bestehenden Teams müssen bei dem Projekt mitarbeiten? Wie wird diese Zusammenarbeit organisiert und haben die Teams überhaupt Kapazitäten frei?
  • Wie organisieren sich die Teams intern in zeitlicher Hinsicht? Wann finden also die verschiedenen Team-Events statt und wer nimmt daran teil? (Team-Planning, Team-Sync, Extended-Team-Sync, Team-Refinement, Team-Review, Team-Retrospektive)
  • Wie organisieren sich die Teams untereinander in zeitlicher Hinsicht? Wann finden also die verschiedenen Projekt-Events statt und wer nimmt daran teil? (In P4: Cluster-Planning, Cluster-Sync, Cluster-Refinement, Cluster-Review, Cluster-Retrospektive, sowie Abstimmungsmeetings der POs, SEs und SMs)

Hierbei hilft es, wenn bereits stabile Strukturen geschaffen wurden, z.B. durch die Einführung von P4 in der Organisation. Dann müssen diese nicht für jedes Projekt neu eingerichtet, eingeführt, eingeübt und verbessert werden! Dadurch sind Organisationen mit einer stabilen P4-Struktur deutlich effektiver und am Ende auch effizienter als Organisationen, die für jedes Projekt neue Strukturen einführen.

Bei der Betrachtung und dem Vergleich von agilen Projekten mit stabilen agilen Teams, die Vorhaben durchführen fallen mehrere Punkte auf:

  • Die agile Projektorganisation kann maßgeschneidert werden. Dadurch können spezielle Eigenschaften des Projekts berücksichtigt werden.
  • Agile Projekte rentieren sich erst ab einer gewissen Größe, da sie den zusätzlichen Aufwand für die eigene Projektorganisation investieren müssen. Dadurch ergibt sich aber wieder die schädliche Tendenz zu immer größeren Projekten.

Projektdurchführung

In der Projektdurchführung unterscheiden sich agile Projekte kaum von der Durchführung von der Entwicklung von Produktversionen in stabilen Teams. Eine häufige Schwierigkeit sind aber die unterschiedlichen Auslastungsgrade der spezialisierten Mitarbeiter, die im Projekt zu bestimmten Zeiten völlig überlastet sind, zu anderen Zeiten aber fast gar nichts zu tun haben. Auch hier ist wieder eine mögliche aber gefährliche Antwort, mehrere Projekte zusammenzufassen.

Projektende

„Wie schön wäre es doch, wenn das Projektteam als Ganzes einfach ein neues Projekt bekommen würde. Dann könnten wir weiter zusammenarbeiten.“ Zitat eines enttäuschten Projektteam-Mitglieds.

Das Projektende ist eine ähnlich schwierige Phase, wie der Projektbeginn. Das Hauptproblem bei Projektbeginn ist, die richtigen Projektmitarbeiter zur richtigen Zeit in das Projektteam, und eingearbeitet zu bekommen.  Dabei ist meist die größere Herausforderung, mit zu vielen Leuten zu starten, als mit zu wenigen.

Am Projektende ist dagegen die Hauptfrage: Wann ist das Projekt überhaupt zu Ende? Wenn die Serie angelaufen ist, oder die Entwicklung an die Produktion, Operations oder der Produktpflege übergeben wurde? Und was passiert, wenn Probleme mit dem neuen Produkt auftreten und das Projektteam inzwischen verstreut ist und an anderen Dingen arbeitet? Das sind schwierige Fragen, die im Notfall dann häufig mit Task-Forces beantwortet werden, die das Grundproblem aber oft verschlimmern (siehe „Task-Forces: Die dunkle Seite des Projektmanagements“).

(Titelbild von octadan auf unsplash.com)

Nächster Artikel: Wie mit vorgegebenen Terminen umgehen?  |  Zurück zu den FAQ  |  Hauptseite