Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Als ScrumMaster werde ich in Unternehmen geholt, um zur Produktivitätssteigerung Scrum „einzuführen“. Relativ schnell begegne ich dabei folgendem Umstand: Viele Product Owner haben nicht im Blick, was ihr Team eigentlich genau liefern soll. Jedenfalls beantworten sie diese Frage selten aus Kundensicht. Meistens treffe ich auf Product Owner, die durch ihre lange Erfahrung und ihr umfangreiches Wissen zwar Experten für ihre Produktsparte geworden sind, aber ihr Blick hängt am eigenen Tun und Denken fest. Letzteres ist folglich zu wenig nach draußen gerichtet, in die Erlebniswelt des Kunden und des Nutzers. Für mich als ScrumMaster bedeutet das, den Product Owner und das Entwicklungsteam zu dieser Sicht- und Denkweise hinzuführen, was viel umfassendere Implikationen hat, als einfach mal eine neue Methode „einzuführen“. Genau genommen sprechen wir von der Entwicklung hin zu einer kundenorientierten Organisation, und das wirkt sich gleich auf mehreren Ebenen aus:Ein wichtiger erster Schritt ist, eine agile Produktentwicklung zu etablieren. Das heißt im Idealfall, dem Scrum-Team beizubringen, wie man iterativ ein MVP (Minimum Viable Product) entwickelt und es dem Markt bzw. den Usern aussetzt – bis ein Produkt gefunden wird, das es sich in allen Details fertig zu bauen lohnt.In diesem Prozess stellt man wiederum fest, wo es im Team an Skills mangelt, und in der Regel tut es das. Die nächste Aufgabe wäre also, diese Skills zu entwickeln. In der Softwareentwicklung hat sich für den Aufbau und den Austausch von Wissen das Mob bzw. Pair Programming etabliert, das Prinzip lässt sich aber auf andere Arbeitsbereiche anwenden. Fehlen bestimmte Skills zur Gänze, muss man sich diese zusätzliche Kompetenz ins Team holen.Auf der Ebene der Infrastruktur stößt man schnell an Grenzen, die aufgelöst werden wollen: Hat das Team überhaupt geeignete Räume, in denen die Zusammenarbeit möglich ist? Sind Kommunikationsmittel im Einsatz, mit denen die Teamarbeit strukturell überhaupt abgebildet werden kann („Pull“-basierte Tools wie Slack oder Microsoft Teams können das), oder läuft die schriftliche Kommunikation des Teams hauptsächlich über E-Mail? Gibt es Arbeitsmaterialien wie Flipcharts, Whiteboards etc. erstens in ausreichender Menge und zweitens in guter Qualität?Bleibt noch die Ebene der Architektur, auf die man einen Blick werfen sollte. Wie ist das Unternehmen organisiert und passt diese Organisationsstruktur überhaupt zu dem Produkt, das sich die Kunden und Anwender wünschen? Eng verbunden damit ist die Frage der Führungskultur in der Organisation: Sind Selbstorganisation, Freiwilligkeit und Commitment erlaubt und werden sie belohnt?Was bedeutet das für die Arbeit als ScrumMaster oder Agile Coach? Ich muss einerseits die genannten Ebenen im Blick behalten und gleichzeitig meine Rolle mit Konsequenz leben. Das bedeutet, die agilen Werte und Prinzipien mit Bestimmtheit zu vertreten. Das bedeutet zum Beispiel, den nötigen langen Atem mitzubringen und dem Management so lange auf den Nerv zu gehen, bis die Lizenz für das geeignete Kommunikationstool gekauft wurde. Müsste ich das Handeln des ScrumMasters auf einen Aspekt reduzieren: immer wieder transparent machen, wo es hängt – auf allen Ebenen. Nur so komme ich überhaupt an die entscheidenden Punkte heran, die eine Organisation in ihrer Produktivität behindern.