Projektmanagement agil oder klassisch?

Projektmanagement agil oder klassisch?

Gerade habe ich die Abschlussdokumentation für ein Projekt fertig gestellt. Dabei ist mir aufgefallen, dass ich an einigen Stellen Änderungen gegenüber dem ursprünglichen Fachkonzept dokumentiert habe. Und das, obwohl ich behaupte wirklich gut im Schreiben von Fachkonzepten zu sein.

Kann man die Anforderungen an ein System im Vorfeld überhaupt genau und vollständig ermitteln?

Falls nein, sind agile Projektmanagementmethoden wie Scrum oder eXtreme Programming die bessere Wahl?

Ist das wirklich eine Frage von „entweder oder“?

Oder vielleicht eine Frage von „sowohl als auch“? Wo liegen die Stärken und Schwächen der jeweiligen Methode?

Betrachtet man die verschiedenen Phasen, die in einem Softwareprojekt durchgeführt werden müssen, so ergeben sich in etwa sechs Phasen:

agile_methoden

  1. In der Initialisierung wird das Projekt mit Mitarbeitern ausgestattet, in der Unternehmensorganisation eingebunden und die Ziele werden festgelegt.
  2. In der Planung wird die Vorgehensweise im Projekt festgelegt, betroffene Stakeholder werden identifiziert, Umstrukturierungen angedacht, die Anforderungen grob ermittelt, Zwischenergebnisse werden festgelegt und eine erste grobe Kosten- Nutzenanalyse durchgeführt.
  3. Bei Analyse & Design werden detaillierte Anforderungen ermittelt und ein Systemdesign festgezurrt.
  4. In der Programmierung werden die Anforderungen programmiert und es entsteht die fertige Software.
  5. In der Testphase wird überprüft, ob das System einsetzbar ist.
  6. In der Schulungs- und Einführungsphase werden die Anwender auf dem neuen System geschult, das Unternehmen wird umorganisiert und die Software wird den Anwendern zur Verfügung gestellt.

Diese Aufzählung mag unvollständig sein und es gibt Vorgehensmodelle, welche die Phasen anders nennen oder anders aufteilen. Egal wie die Phasen genannt werden, alle diese Aufgaben müssen in einem Softwareprojekt durchgeführt werden (und ggf. noch einige mehr).

Betrachtet man agile Methoden, so umfassen diese meistens nur die Phasen Analyse & Design, Programmierung und Test. Beim Test fehlt meistens der Abnahmetest.

Damit ist zumindest die Frage Projektmanagement agil oder klassisch eine Frage des „sowohl als auch“. Dabei hängt es vom Projekt ab, welcher Teil überwiegt.

Wenn man eine Software an 30.000 weltweit verteilte Anwender ausrollen möchte, ist alleine die Schulungs- und Einführungsphase ein Projekt für sich und kann den Aufwand der Programmierung leicht übersteigen.

Zurück zur Ausgangssituation. Die Anforderungen im Fachkonzept, die letztendlich nicht oder anders realisiert worden sind, waren verschwendete Zeit.

Hätte ich mir diese Zeit sparen können, indem ich eine agile Methode verwendet hätte?

Wie wäre es gewesen, wenn ich Scrum genutzt und die Rolle als Product Owner eingenommen hätte?

Im Buch Scrum von Roman Pichler (ISBN 978-3-89864-478-5) wird die Rolle des Product Owner wie folgt definiert: „Der schlanke Product Owner ist dabei ein Hybrid aus Produktmanager, Projektleiter und Chefarchitekt“.

In diesem Projekt habe ich unbewusst in etwa diese Rolle eingenommen. Die unnötige Anforderungsdokumentation hätte ich mir mit einer agilen Methode wahrscheinlich sparen können.

Was wäre der Preis dafür gewesen? Ich kann nur ahnen, dass es beim Design des Systems zu mehr Diskussionen und Unsicherheiten gekommen wäre. Es war ein kleines Projekt.

Kann ich die Ergebnisse auch auf große Projekte übertragen? Gibt es eine Person, die bei einem großen Projekt die Rollen des Produktmanagers, Projektleiters und Chefarchitekten in Personalunion einnehmen kann?

Roman Pichler empfiehlt in diesem Fall ein Team von Product Ownern einzusetzen.

Ich bin ein Freund davon, zunächst einen Überblick zu bekommen, bevor ich in die Tiefe eintauche.

Bei einem großen Projekt würde ich mir eine Phase wünschen, bei der die Anforderungen auf einem Übersichtsniveau (z.B. in Form von dokumentierten Geschäftsprozessen) festgehalten werden. Sonst besteht die Gefahr, dass man sich mit einer agilen Methode an einer Ecke des Systems „festbeißt“ und das große Ganze aus den Augen verliert.

Außerdem gibt es Anforderungen, die essenziell für ein System sind. Dies sind üblicherweise die statischen Anforderungen an ein System (z.B. Datenmodell oder Klassenmodell).

In einer Autovermietung ist die Antwort auf die Frage „kann ein Kunde auf einem Mietvertrag ein oder mehrere KFZ mieten?“ elementar. Wird diese Frage falsch beantwortet und erst gegen Ende des Projekts korrigiert, ist ein sehr hoher Refactoringaufwand notwendig.

Will man dieses Risiko vermeiden, macht eine Phase Sinn, in der man die essenziellen Anforderungen im Vorfeld klärt.

Aus diesem Blickwinkel betrachtet, könnte man die Methoden von Scrum perfekt in den inkrementellen und iterativen Unified Process einbetten. Damit ist man mit agilen Methoden sehr nahe am Timeboxing des klassischen Projektmanagements. Am Ende einer Timebox muss vom Team ein von Außen überprüfbares Ergebnis (z.B. eine benutzbare Software mit eingeschränktem Funktionsumfang die von den Anwendern ausprobiert werden kann) geliefert werden.

Der größte Fehler im klassischen Projektmanagement ist es, mit Aufgaben der folgenden Timebox zu beginnen, während das Ergebnis der ersten Timebox noch nicht ausgeliefert ist. Genau diesen Fehler vermeiden agile Methoden, wenn sie denn richtig angewendet werden.

Fazit:

  • Agiles oder klassisches Projektmanagement ist keine Frage des „entweder oder“ sondern eine Frage des „sowohl als auch“.
  • Agile Methoden decken nur den Teil der Projektmanagementaufgaben ab, der sich um Anforderungsanalyse, Design, Programmierung und Test dreht.
  • Agile Methoden stellen wesentlich höhere Anforderungen an den „Projektleiter“ und die Teammitglieder.
  • Agile Methoden reduzieren das Risiko unnötig viel zu dokumentieren, erhöhen gleichzeitig das Risiko hohe Aufwände für das Refactoring aufzuwenden.
  • Agile Methoden lassen sich sinnvoll in das klassische Projektmanagement integrieren.
  • Bei großen Projekten ist es wichtig, von Außen überprüfbare Zwischenergebnisse zu erreichen.
Projektmanagement agil oder klassisch?

Download Digitalisierungscockpit