Jan Kus hat gestern in der Online-Ausgabe des Technologie-Magazins t3n mit einer markanten These aufhorchen lassen. Da heißt es gleich am Beginn der Einleitung:
„Projektmanagement ist so etwas wie das Stiefkind moderner Softwareentwicklung.“
Ich fand den Artikel so spannend und mutig, dass ich gerne noch meinen „Senf“ dazu geben möchte. Zuerst aber zu den Kernbotschaften des Artikels:
- In Fixpreisprojekten wird häufig viel Zeit mit Vertragsvereinbarungen verschwendet. Diese Zeit wäre besser in produktive Arbeit investiert.
- Teams sollten möglichst dezentral gesteuert werden (nämlich indem sie sich soweit möglich selbst steuern).
- Agile Softwareentwicklung und Projektmanagement sollten Hand in Hand gehen. Man sollte sich die agilen Werte und Prinzipien immer wieder vergegenwärtigen.
- Agiles PM birgt aber auch Risiken: (Klassische) Kundenanforderungen (wie z.B. eine saubere Dokumentation) müssen von Teams auch erfüllt werden.
- Fixpreisverträge sind zeitaufwändig, ihre Ausarbeitung teuer. Vor allem kleine Agenturen / Dienstleister sollten wenn möglich zeitbasiert abrechnen. Dies kann aber nur funktionieren, wenn gegenseitiges Vertrauen zwischen Auftraggeber und -nehmer herrscht (Stichwort: Handschlagqualität).
- Die Definition und Umsetzung starrer, komplizierter Prozesse ist in der Softwareentwicklung häufig wenig sinnvoll. Es ist ratsam, die Energie stattdessen auf die Schaffung guter Rahmenbedingungen für das Team, eine gute Kommunikation untereinander, das Ergebnis selbst oder das Lernen aus Erfahrungen zu lenken.
- Aussagekräftige und dokumentierte Tests können teilweise eine aufwändige Dokumentation ersetzen.
- In jedem Fall gilt: Eine konsequente Fokussierung auf das Ergebnis ist das A und O moderner Softwareentwicklung nach agilen Prinzipien.
In den meisten Punkten stimme ich dem Autor zu. Nicht allerdings in folgenden:
- Ich vertrete (nicht erst seit heute) die Ansicht, dass in den meisten Projekten (IT oder auch anderswo) eine Integration klassischer und agiler Ansätze sinnvoll ist. Denn ich sehe weder in klassisch-deduktiven noch in agil-iterativen Vorgehensmodellen ein Allheilmittel zur Bewältigung komplexer Vorhaben.
- Konkret heißt das für beispielsweise für die Softwareentwicklung, dass bei der Initiierung und Planung von Projekten sehr wohl eine bestmögliche Abgrenzung und Spezifikation des „project scope“ notwendig und sinnvoll ist. Allerdings sollte das Projektmanagement-Dreieck (triple constraint) nicht starr, sondern vielmehr in zumindest einem Parameter flexibel interpretiert werden. Beispiel:
- Leistungsziele = Muss- und Soll-/Kann-Anforderungen (deren Notwendigkeit im laufenden Entwicklungsprozess verifiziert wird)
- Kostenziele / Budget = fixiert (+ ggf. definiertes Nachtragsbudget)
- Terminziele = harte Deadline für Muss-Anforderungen, weiche Deadlines für Soll-/Kann-Anforderungen
Hier ein Beispiel eines möglichen Ansatzes (in Anlehnung an „APM – Agiles Projektmanagement“ von Bernd Oestereich und Christian Weiss, S. 4):
Fazit: Klassisches Projektmanagement ist gut, agiles Projektmanagement ist (im Zweifelsfall) besser. Aber die wahre Kunst liegt in der Überbrückung vermeintlicher Gegensätze. Dies kann gelingen, wenn man den guten alten Hausverstand einschaltet und sich auf das Wesentliche konzentriert.
PS: Die Kernkonzepte des Buches „Agiles Projektmanagement“ können hier als Poster herunter geladen werden.