Scrum – die Untiefen ODER Warum Scrum nicht immer gut ist

Nach weit mehr als hundert Tagen möchte ich auch die Schattenseiten oder auch „Challenges“ offenlegen. Mit der Einführung von Scrum wurde auch die Matrix-Organisation eingeführt. Die Teamleiter sind noch solche, jedoch nicht mehr für die Verteilung der Arbeit verantwortlich. Die Hauptaufgabe besteht in der Mitarbeiterführung und -entwicklung. Weiterhin ist es von Vorteil, wenn die Teamleiter in dieser Struktur fachliche Ansprechpartner sein können. Damit sind sie weiterhin natürliche Führungskräfte. Die Teamleiter arbeiten in den Teams mit und müssen sich entsprechend dem Scrum Prozess fügen. Das hört sich schlimmer an als es ist. Das Problem sind idR nicht die Teamleiter, sondern die Mitarbeiter die es gewohnt waren, Arbeitsaufträge zu erhalten. Durch die Umtellung auf ein Pull System (in Scrum holen sich die Teams ihre Arbeit) kann es eben passieren, dass einzelne irritiert sind. Schließlich hat bis „gestern“ jemand die Arbeit vorbei gebracht.

Product Owner

In Scrum gibt es die Product Owner (PO) Rolle. Der PO ist im Sprint Planning 1 (SP1) und auch SP2 dafür da, Fragen zu beantworten und Stories vorzustellen. Für n Scrum Teams sind also n POs von Vorteil. n Scrum Master sind ohnehin Voraussetzung. Hat man weniger POs, dann kann man die Sprint Plannings nicht mehr parallel durchführen. Der zeitliche Versatz ist aber schwieriger zu organisieren. Damit wird das ganze System komplexer als unbedingt nötig. Je weniger POs vorhanden sind, desto eingfacher können sich diese abstimmen – das ist der einzige Vorteil. Ein separates Backlog pro Team wird aber schwieriger zu führen.

Backlogs

Ein Produkt mit verschiedenen Teams zu realisieren setzt im gewissen Maße Synchronität voraus. Da wir ja Cross-Functional-Teams haben, können Features innerhalb eines Teams realisiert werden. Es gibt also eine gewisse Abgeschlossenheit. Da Features und auch Bugfixes jedoch nicht völlig im luftleeren Raum existieren, gibt es immer Abhängigkeiten zwischen ihnen. Um diese Abhängigkeiten optimal behandeln zu können, müssen die abhängigen Featues vom selben Team bearbeitet werden oder die Teams sich abstimmen. Variante 1, dasselbe Team, funktioniert gut wenn der PO ein Team-Backlog erstellt und dafür Sorge trägt, dass „sein“ Team diese abhängigen Aufgaben bekommt. Variante 2, die Teams werden eher zufällig mit Aufgaben betraut, funktioniert hinsichtlich dieser Abhängigkeiten nicht so gut. Jedoch verbreitet man hier das Wissen über Teamgrenzen hinweg, zum Preis einer erhöhten Kommunikation zwischen den Teams. Diese Kommunikation kann in den Communities of Competence bzw. Communities of Practice erfolgen.

Siehe auch

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.