Dass Projekte, die agile Methoden einsezten eine höhere Erfolgsquote haben, hatte ich gestern schon berichtet. In der gleichen Untersuchung hatten wir auch den Einsatz klassischer Methoden aus dem Bereich des Software-Engineering abgefragt, hierbei hatten wir uns unter anderem an den Punkten des Joel Tests orientiert. Bei Betrachtung der Erfolgsquoten der Projekte, die diese Methoden einsetzen, erhält man ein überraschendes und ernüchterndes Ergebnis. Die Erfolgsquoten liegen unterhalb der durchschnittlichen Erfolgsquote aller Projekte.
Hier zum Vergleich nochmals die Erfolgsquoten der Projekte, die agile Methoden einsetzen:
In dieser Deutlichkeit überraschen mich – selbst als Verfechter agiler Methoden – diese Ergebnisse doch sehr. In der Untersuchung, die zur Zeit vorbereitet wird, werden wir dieses Thema weiter untersuchen … stay tuned.
Hallo Sabine,
Du hast völlig recht, nicht überall wo Scrum drauf steht ist wirklich SCRUM oder Agil drin. Nicht jeder der Sprints, Daily Scrums und Retrsopektiven macht, macht wirklich Scrum.
Meine These lautet – der Schlüssel zum Erfolg ist ein „echtes Team“ also eine wirklich weitgehend selbstorganisierte Gruppe, die die gruppendynamischen Phasen kosntruktiv durchlaufen hat. Ein Projekt mit einem solchen Team hat viel bessere Chancen. Meine Beobachtung und Analyse ist, dass Agilität oder SCRUM im speziellen den Weg zum Team vereinfachen.
Das scheint sich in den Daten zu bestätigen, die Projekte, die agile Elemente einsetzen (mal davon abgesehen wie agil sie wirklcih sind) haben eine signifikant höhere Erfolgsaussicht und signifikant bessere Teamqualitäten (ermittelt auf Basis von 16 Teamfaktoren). Eine Korrelation ist vorhanden, Kausalität ist nochmal was anderes 😉
Ich habe da gerade einen Artikel in Arbeit der das ganze sehr viel ausführlicher beleuchtet.
viele Grüße Eberhard
Hallo Eberhard,
das sind interessante Untersuchungen. Ich weiß, dass viel nach solchen Auswertungen gefragt wird, und dass die Leute „Beweise“ sehen wollen, dass Scrum sie erfolgreicher macht. Ich finde es kritisch, solche Daten in dieser Form zu benutzen.
Beispiel: selbst wenn jemand alle Scrum-Praktiken brav anwendet, ist er/sie deswegen lange noch nicht agil. Selbst wenn ein Product Owner oder Scrum Master benannt ist, heißt es noch nicht, dass sie diese Rolle auch gut ausfüllen. Wenn sie Retrospektiven durchführen, heißt es noch nicht, dass sie es auch schaffen, die Ergebnisse umzusetzen. Ich habe leider oft gesehen, dass man mir erzählt hat, Scrum hätte „nicht funktioniert“, und bei näherem Hinsehen war es auch klar warum: Scrum ist nicht so wie gedacht angewandt worden. Nun ist es aber sehr schwer, Scrum „wie gedacht“ anzuwenden. All diese Zwischentöne lassen sich durch Statistiken schlecht erfassen.
Viele Grüße
Sabine