Seit langem mal wieder ein reinrassiger Projektmanagement Beitrag. Jüngst bin ich über einen Artikel von Ron Quartel auf medium gestolpert: „Why Story Pointing Needs to Die„
Wortwörtlich ins Auge gefallen sind mir vor allem die beiden Zitate in der Illustration:
„I may have invented points. If I did, I´m sorry now.“ – Ron Jeffries
„Velocity is killing agility!“ – Jom Highsmith
Vor allem das zweite spricht mir aus der Seele. Das Konzept der Velocity wollte mir nie so recht eingehen.
Also nicht, dass ich nicht verstanden hätte, worum es dabei geht und wie es funktioniert, aber Velocity-Betrachtungen laufen meinem Verständnis von Projekten fundamental entgegen.
Projekte sind einzigartige, komplexe Herausforderungen und Velocity zielt auf die Optimierung einer gleichmäßigen und prognostizierbaren Teamauslastung. Finde den Fehler!
Klar, wenn sich ein Projekt an das andere reiht, dann können wir nicht immer auf 120% fahren. Das macht uns kaputt. Aber die Vorstellung Projektfortschritt sei ein kontinuierlicher Prozess ist schon schizophren, denn sind nicht Disruption und sprunghafte Entwicklungen gerade in komplexen Projekten zu beobachten?
Nichts gegen eine Auslastungsoptimierung. Sie sichert Effizienz. In Projekten steht aber vor der Effizienz vor allem die Effektivität. Erreichen wir überhaupt, was wir erreichen wollen?
Effizient Scheitern ist keine Option!
Ich will das Konzept Velocity gar nicht in Frage stellen. Dafür gibt es sicher Anwendungsfälle, aber eher weniger in Projekten.
Bevor ich nun wieder in die Schublade des traditionellen Projektmanagements gesteckt werde, will ich dem schon vorab widersprechen. „Gutes“ Projektmanagement hatte immer schon agile Züge, denn nur mit einer solchen Einstellung kann man komplexen Anforderungen gerecht werden. Das hat aber nur bedingt mit der Umsetzung agiler Projektmanagement-Ansätze zu tun. Die großen Stärken von beispielsweise Scrum sind für mich, die Stärkung des Teams, Facilitation (in der Rolle des Scrum Masters), die intensive Einbindung der Anforderungsseite (Product Owner) sowie die Etablierung von Lernprozessen und Kommunikation. Diese Dinge helfen aber in jeder Form des Projektmanagements weiter und erhöhen unsere Erfolgswahrscheinlichkeit. Lediglich formale Implementierungen von Scrum sind wie alle halbherzigen Projektmanagementimplementierungen zum Scheitern verurteilt.
Überbewertete Konzepte gibt es aber auch im traditionellen Projektmanagement. Mein „Lieblingsbeispiel“ hier ist der Earned Value, also die laufende Quantifizierung des Projektfortschritts. Der bereits geschaffene Wert im Projekt wird kontinuierlich ermittelt. Ich halte diesen Ansatz für gefährlich. Er suggeriert, dass tatsächlich bereits ein Wert geschaffen wurde. Der Wert eines Projektgegenstandes ist mitunter aber digital zu sehen: Das fertige Produkt funktioniert oder funktioniert nicht. Zugegeben, die Argumentation ist stark vereinfacht. Vielleicht haben wir tatsächlich etwas gelernt oder es sind brauchbare Zwischenprodukte entstanden, gemessen an unserm Projektauftrag sind wir aber gescheitert. Als Gegenpol dazu gefällt mir hingegen die Idee des „Minimum Viable Product“, die zu einer Rückbesinnung und Ergebnisorientierung führt. Mit dem MVP ist ein Projekt zwar in der Regel noch nicht am Ziel, aber das Risiko des Scheiterns wird minimiert.
Alle Earned Value-Implementierungen, die ich in der Praxis gesehen habe, dienten – böse gesagt – auch eher der Befriedigung des Management Reportings, als dem Projekterfolg.
