Dieses Beispiel zeigt anhand einer Transition zu einem Large Scale Scrum Umfeld, dass man mit eigentlich offensichtlichen Veränderungen und klaren Rollen großen Einfluss auf Organisationen hat. Gleichzeitig lernt man als Berater immer wieder, dass man selbst Teil des Problems ist, wenn man zu tief involviert ist.

Während der Beauftragung als Scrum Master in einem IT-Startup sind wir auf eine Situation gestoßen, welche wir recht häufig in Organisationen beobachten können. Die Rollenklarheit ist nicht gegeben. Oft bekommt man offiziell eine Rolle, inoffiziell wird allerdings etwas anderes getan weil es der Organisation hilft, allerdings ist es vielen Mitarbeitern in der Organisation nicht bekannt und stößt auf Mitssverständnis. Meist wird dem jedoch nicht aktiv Beachtung geschenkt und eine klare Rollendefinition und Kommunikation findet nicht statt. Während dieser Beauftragung äußerte es sich in der Rollenklarheit des Porduct Owners (PO). Durch das personelle Wachstum der Entwicklerteams und dem daraus resultierenden Start weiterer Entwicklerteams kam der PO nicht mehr zeitnah dazu die User Stories fertig zu stellen, die Qualität der Anforderungen nahm ab und die Teams begannen Rückfragen bei unterschiedlichen Personen einzuholen – obwohl diese nicht POs waren – da diese lange genug im Unternehmen warem um sich “auszukennen”. Dazu kam allerdings, dass nur der eingesetzte PO das Vertrauen der Organisation genoss, genügen Erfahrung mit der Webseite zu haben, um auch Anforderungen zu schreiben. Die Folge war, dass nicht genügen Arbeit bei Sprintbeginn für die Teams zur Verfügung stand, dann die Sprints überzogen und öfters die Anforderungen falsch umgesetzt wurden. Die Teams haben die Erwartungshaltung aus Sicht der Geschäftsleitung mehr und mehr nicht erfüllt. Nach anfänglichen Versuchen die Feedbackmechanismen in Richtung PO zu optimieren mussten wir erkennen, das wir ein Teil des Problems waren (Scrum Master). Daraufhin zogen wir einen unbeteiligten Dritten Berater von uns hinzu um gemeinsam das Erlebte zu Beschreiben. Wir reflektierten diese der Geschäftsleitung, was dazu führte, einem erfahrenen Entwickler das Vertrauen entgegen zu bringen und ihm die Rolle eines POs offiziell zu geben. Dies musste zwingend an alle Teams kommuniziert werden. Seit diesem Zeitpunkt stieg die Qualität der Anforderungen, Missverständnisse nahmen ab und die Gewindigkeit der Teams nahm zu. 

Ein weiteres Resultat dieser Erfahrung war, dass wir erkennen mussten, ebenfalls die Transition durch den Einsatz weiterer Scrum Master zu unterstützen. Die Rolle des Scrum Masters im einem Umfeld, welches sich weg von einem Entwicklerteam hin zu Large Scale Scrum entwickelt, erfährt in diesem Fall eine innhaltliche Veränderung in Richtung Manager obwohl die Rolle nach außen unverändert bleibt. Dies hat während der Transition öfters zu Missverständnissen bzgl. „wer macht eigentlich was“ geführt.