Willkommen zum nächsten Post aus der Serie Agile Worst Practices, die ich mit diesem Post begonnen hatte. Wir bleiben bei den Worst Practices für das Team und greifen ein häufiges Missverständnis im agilen Umfeld auf:
Team Worst Practice #3: Alles ist selbstorganisiert
Beschreibung: Wir als Team sind ja selbstorganisiert. Uns hat keiner etwas vorzuschreiben und wir wissen selber am besten, was für uns gut ist. Feste Regeln gelten für uns nicht, sondern wir klären basisdemokratisch, was wir unter agilem Vorgehen verstehen und wie wir das machen wollen. Auch Scrum ist ja eher so eine Art Empfehlung als eine Methode und wir diskutieren ausführlich in jedem Sprint, wie wir das machen wollen. Schließlich sind die Retrospektiven doch dafür da, dass wir unsere Methode nach jedem Sprint (und bei Bedarf auch während des Sprints) ändern können, oder?
Konsequenz: Das Konzept der Selbstorganisation ist vielfach falsch verstanden worden und wird leider auch bis heute noch vielfach falsch vermittelt. Zunächst einmal bedeutet Selbstorganisation nicht komplette Anarchie und Team Empowerment bedeutet auch nicht Basisdemokratie. Es gibt sehr wohl feste Regeln und Ziele, die von außen vorgegeben werden und die ein Team erfüllen muss. Die Selbstorganisation findet innerhalb dieser Regeln und Ziele statt. Die Regeln und Ziele hingegen sind fest und können vom Team nicht nach Belieben umdefiniert werden.
Ein einmal gewähltes Vorgehen wie z.B. Scrum gehört zu den festen Regeln und kann (und sollte auch) nicht nach Belieben geändert werden. Es ist Aufgabe des Scrum Masters, dafür zu sorgen, dass die entsprechenden Regeln eingehalten werden. Tut man das nicht, hat man das große Problem, dass die initiale Lernphase fehlt, in der man versteht, welche Wirkungen die verschiedenen Regeln von Scrum haben. Nicht ad hoc offensichtliche Auswirkungen von Regeln werden nicht verstanden, sie werden mangels Verständnis in der Regel frühzeitig verworfen und es werden typischerweise bequemere, aber auch suboptimale Alternativen eingesetzt.
In Summe führt das Vorgehen typischerweise zu geringerer Produktivität, einmal weil viel Zeit und Energie für die Diskussionen über das Vorgehen verbraucht werden und andererseits, weil das Vorgehen weniger gut ist. Zusätzlich birgt das Vorgehen die Gefahr, dass sich das Verfahren nicht stabilisiert, sondern zu einem dauerhaften Ausprobieren führt.
Maßnahmen: Hier ist insbesondere der Scrum Master gefragt. Er muss die nicht diskutierbaren Anteile des Vorgehens klar kommunizieren und die Einhaltung forcieren. Bei den ergänzenden Anteilen (z.B. das verwendete Schätzverfahren) muss er auch dafür sorgen, dass sich zunächst auf ein Verfahren geeinigt wird und das auch eine Zeitlang ohne Diskussion gelebt wird.
Zusätzlich sollte er das Team auf eine Lernphase ohne Diskussion der Vorgehensweise einschwören.
Für ein erstes Scrum-Projekt sind dafür mindestens 6 Sprints, eher noch einige Sprints mehr zu empfehlen. Nach dieser Lernphase hat das Team dann genug Erfahrung mit der Methode sammeln können, um qualifiziert beurteilen zu können, an welchen Stellen Optimierungen möglich und sinnvoll sind. Aber auch dann noch muss der Scrum Master darauf achten, dass keine von außen vorgegebenen Regeln und Ziele angefasst werden, denn diese sind wie bereits geschrieben fest bzw. müssen in Fällen von Problemen in Form von Impediments angegangen werden und können nicht einfach eigenmächtig vom Team angepasst werden.
Zum Abschluss des Posts wie immer noch ein wenig Verlinkung:
- Den Link zum ersten Post dieser Serie findet Ihr hier .
- Den Link zum nächsten Post dieser Serie findet Ihr hier .
PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Uwe Friedrichsen
16.10.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Uwe Friedrichsen
CTO
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.