Seiten

Sonntag, 13. April 2014

Agile Projekte sind nicht zu kontrollieren

Ein gemeinsames "Klagelied" als Beschwerde über agile Projektmanagementmethoden ist, dass Führungskräfte und traditionelle Projektmanager nicht mehr dasselbe Ausmass an "Kontrolle" über ein Projekt haben. Wir sollten aufhören, uns Gedanken über diese Beschwerde zu machen und beginnen, dieses augenscheinliche Laster als eine Tugend zu betrachten. Wenn wir versuchen "Kontrolle" in agilen Projekten zu erlangen, dann werden wir einen erheblichen Teil des Nutzens von agilen Methoden zu verlieren. 

Davon abgesehen, sind die Voraussetzung für das "agile Projekt" so zu gestalten, dass parallel zur Planung und Umsetzung die Projektspezifikationen detailliert werden müssen. Ansonsten wäre ja eine Planung und Umsetzung mit traditionellen Methoden sinnvoller!

Denn - oftmals erhalten Sie das, was Sie messen. Sie müssen nur sicher sein, dass Sie das Richtige messen!

Weiterführende Quelle: http://java.dzone.com/articles/dont-control-agile-projects

3 Kommentare:

Andreas Kleffel hat gesagt…

Agile Projekte kann man so kontrollieren, wie man jedes Projekt kontrollieren kann. Erbrachten Aufwand und erreichter Geschäftswert ins Verhältnis setzen.

Erbrachten Aufwand sollte man mittels Zeiterfassung und sonstigen Ausgaben leicht ermitteln können und den erreichten Geschäftswert sollte ein versierter Produkt/Projektmanager auch "mitten" im Projekt einschätzen können.

Um das Ganz noch etwas zu fundieren:
Fertiges Feature inkl. Dokumentation - 100% des Wertes in €
Fertiges Feature ohne Dokumentation - 90% des Wertes in €
Fertiges, noch nicht ausreichend getestetes Feature - 30 % des Wertes in €
Spezifiziertes, noch nicht implementiertes Feature oder Feature in Progress - 5% des Wertes in €

Was braucht man mehr? Der Faktor Zeit im Sinne von Kalendermonaten ist doch meist gar nicht so kritisch, Budgetüberschreitungen dagegen schon.

Andreas Kleffel hat gesagt…

Agile Projekte kann man so kontrollieren, wie man jedes Projekt kontrollieren kann. Erbrachten Aufwand und erreichter Geschäftswert ins Verhältnis setzen.

Erbrachten Aufwand sollte man mittels Zeiterfassung und sonstigen Ausgaben leicht ermitteln können und den erreichten Geschäftswert sollte ein versierter Produkt/Projektmanager auch "mitten" im Projekt einschätzen können.

Um das Ganz noch etwas zu fundieren:
Fertiges Feature inkl. Dokumentation - 100% des Wertes in €
Fertiges Feature ohne Dokumentation - 90% des Wertes in €
Fertiges, noch nicht ausreichend getestetes Feature - 30 % des Wertes in €
Spezifiziertes, noch nicht implementiertes Feature oder Feature in Progress - 5% des Wertes in €

Was braucht man mehr? Der Faktor Zeit im Sinne von Kalendermonaten ist doch meist gar nicht so kritisch, Budgetüberschreitungen dagegen schon.

Organisationsgestalter.de hat gesagt…

Hallo Andreas,

danke für Dein schönes Statement. Ja genau so sehe ich das auch. Dem ist auch nichts mehr hinzuzufügen!

Mein provokanter Posting-Titel ist jedoch genau die Aussage, die ich öfter von dogmatischen Verfechtern der "traditionellen" Projektmanagementmethode höre.

Um mich nicht falsch zu verstehen: Genauso wenig, wie das traditionelle Projektmanagement nach IPMA oder PMI (PMI hat da schon den eigenen Standard mit agilen "Komponenten" ergänzt) keine Methode für alle Projektanforderungen darstellt, ist auch das agile Projektmanagement für ganz bestimmte Anforderungen sehr gut, für andere jedoch auch nicht geeignet ( siehe dazu auch: http://organisationsgestalter.blogspot.co.at/2013/05/methoden-zur-planung-und.html ).

Aus meiner Sicht ist es sinnvoll, die Auswahl der passenden PJM-Methode in Relation zu den Anforderungen zu treffen.

Mit besten Grüssen aus Bonn,
Manfred Brandstätter