Was sich nach einem Witz anhört ist leider allzu oft Realität. Auch in einigen agilen Scrum Projekten in denen ich als Entwickler selbst unterwegs war gab es solche Situationen.
Kann man so machen, ist dann halt doof. Wenn das Business (also die fachlichen Anforderer) die Aufwände der Userstories
schätzen und keiner aus dem Entwicklungsteam bei den Schätzungen dabei ist, sollte man sich nicht wundern wenn
- keiner aus dem Entwicklungsteam Committed ist
- die geschätzten Aufwände stark von den tatsächlichen Aufwänden abweichen
- die Team Moral und damit auch die Velocity nicht gut ist
Warum passiert so etwas?
Ganz einfach, die Grundlagen von Scrum sind Vertrauen, Transparenz, Commitment und der Teamgedanke. Wenn den Entwicklern vom Fachbereich diktiert wird welche Userstories mit welchen Aufwänden verbunden sind, entfällt die Selbstbestimmung und das Commitment der Entwickler. Wenn die so festgesteckten Ziele nicht erreicht wurden, ist es einfach zu sagen “Wir hätten dafür ohnehin mehr Aufwände eingeschätzt” oder “das war von Anfang an klar”. Solche Projekte sollen agil sein, sie sind aber klassisches Wasserfallmodell.
Wie kann man diesen Fehler vermeiden?
Wer auf eine allgemein gültige Antwort gehofft hat, den muss ich leider enttäuschen. Es gibt allerdings einige Hebel die ihr nutzen könnt um solche Probleme zu vermeiden:
Soll das Projekt wirklich agil entwickelt werden, oder ist des dem Business nur wichtig, dass agil drauf steht. Wenn dem so ist, weiß das DevTeam an wem es ist und muss sich nicht unnötig auf Diskussionen zwischen agil und Wasserfall einlassen.
Mit Schulungen aller Projektbeteiligten in regelmäßigen Abständen schafft ihr nicht nur das Verständnis von agilen Projekten nach Scrum (was schon mal gut ist) sondern auch durch den sogenannten “Seitenbacher Effekt” ein Einschleifen des Verständnisses ins Unterbewusstsein. Werden die Schulungen in kleinerem Umfang wiederholt, werden auch immer andere Fragen von den Teilnehmern gestellt.
Schulungen vor Projektbeginn – das ist ein hehres Ziel! Wenn ihr es vor Projektbeginn schafft alle Teilnehmer und Stakeholder zu schulen seid ihr schon sehr weit vorne mit dabei!
Der optimale Fall dass die o.g. Möglichkeiten durchgeführt werden ist leider aus meiner eigenen Erfahrung nicht häufig. Deswegen loht es sich auch hier über das Thema Agile Coaching nachzudenken. Alle haben ohnehin wenig Zeit während der Projekte, warum nicht währenddessen einen guten Agile Coach mit ins Team holen?
[mc4wp_form id=”1229″]