In unseren Projekten begegnen uns immer wieder agile Missverständnisse, die sich teilweise hartnäckig halten und die sich zu folgenschweren Fallstricken entwickeln können. Unsere Blog-Serie „Agile Irrtümer“ räumt mit diesen Missverständnissen auf! Nach der positiven Resonanz auf Teil #1 „Commitment ist ein Leistungsversprechen“ widme ich mich diesmal einem falschen Rollenverständnis, das dem Scrum Master häufig die Aufgabe eines „Wohlfühl-Managers“ für sein Team zuweist.

Taylorismus vs Agilität

Viele Organisationen sind nach wie vor tayloristisch geprägt, das heißt Denken und Handeln sind in der Regel getrennt. Ziele und Prozesse werden überwiegend vom Management definiert, die Mitarbeiter sind lediglich ausführende Kräfte, die ihre Aufgaben innerhalb kleinteiliger, standardisierter Schemata „abarbeiten“.

Ein Merkmal tayloristischer Organisationen ist das tiefe Misstrauen der Mitarbeiter in ihr Management (die Gründe dafür sind vielfältig und würden hier zu weit führen). Trifft nun die agile Transformation mit ihren Paradigmen Selbstorganisation und Eigenverantwortung auf tayloristische Strukturen, sind Konflikte vorprogrammiert.

Falsche Erwartungshaltung

Wenn ich im Rahmen von Scrum-Einführungen mit den Teams über ihre Erwartungen an den Scrum Master spreche, ist häufig zu spüren, wie die Mitarbeiter aufatmen. Endlich ist da einer, der das Team vor allen äußeren schädlichen und unangenehmen Einflüssen durch Product Owner, Stakeholder oder Manager beschützt und abschirmt, oder?

Jein. Zwar zählt das Beseitigen von Impediments zu den Aufgaben des Scrum Masters, doch bei Scrum-unerfahrenen Teams besteht die Gefahr, dass die Schutzfunktion des Scrum Masters missverstanden oder verallgemeinert wird. Daraus entsteht eine falsche Erwartungshaltung des Teams, die in einer vollkommenen Abschottung gegenüber der restlichen Organisation münden kann.

Typische Äußerungen sind beispielsweise:

„Wir sind doch jetzt ein selbstverantwortliches Team, also darf uns niemand mehr unter Druck setzen!“

„Der Sprint ist voll, der Product Owner soll aufhören uns weitere User Stories aufzwängen zu wollen.“

„Es ist dann fertig, wenn es fertig ist. Wir sind jetzt agil, da gibt es keine Milestones mehr.“

„Das Team ist für die Schätzung verantwortlich. Es kostet eben so viel.“

Diese Haltung des Teams ist NICHT im Sinne des Scrum-Erfinders! Denn im Kern geht es bei Agilität um intensive Kommunikation. Im agilen Projektmanagement ist das funktionierende Produkt das Ergebnis funktionierender Kommunikation.

Betrachten wir die obigen Zitate unter dieser Prämisse von Agilität, dann liegt in diesen Fällen ein Fehlverhalten des Teams vor, begründet im historisch gewachsenen Mindset des Unternehmens: Wenn sich ein Team bis dato als vom Management „geknechtet“‘ und durch äußere Kräfte unter Druck gesetzt fühlte (oftmals kombiniert mit intensivem Mikromanagement), dann verwundert es nicht, wenn die neue agile Freiheit zum anderen Extrem führt, nämlich zur Abschottung des Teams. Und das ist schädlich für die Kommunikation und Zusammenarbeit und damit für die Zielerreichung der Organisation.

Der Scrum Master ist der Produktivität verpflichtet

Dieser Haltung muss der Scrum Master entgegenwirken! Er muss dem Team begreiflich machen, dass es bei echter Agilität eben nicht um Abschottung geht, sondern um eine intensive Auseinandersetzung mit den durch den Product Owner vertretenen Kundenzielen und dem Feedback der Anwender – inklusive entsprechender, vom Kunden vorgegebener Meilensteine! Das Team benötigt eine intensive Kommunikation um die Fragen: „Wie können die Kundenziele und Meilensteine erreicht werden? Was ist wirklich, wirklich wichtig? Was kann weggelassen werden?“

Auf den Punkt gebracht geht es in agilen Teams also um wertgetriebene Kommunikation (einer der wesentlichsten Unterschiede zu traditionellen Projektmanagementmodellen, bei denen plangetriebene Kommunikation mittels Projektplänen, Statusreports etc. im Fokus steht.) Damit diese Kommunikation funktioniert, darf sich ein Team nicht abschotten, sondern muss lernen, auch an taffen Diskussionen zur Zielerreichung teilzunehmen.

Das ist unangenehm – und plötzlich sieht sich der Scrum Master der Kritik seines Teams ausgesetzt. Warum schützt er sein Team nicht vor diesen äußeren Einflüssen, vor lästigen Diskussionen? Weil er nicht darf! Der Scrum Master ist in erster Linie Wächter und Förderer des Scrum-Prozesses. Das bedeutet, dass er alles tut, damit alle am Scrum-Prozess beteiligten Parteien gemeinsam besser werden. Wenn er dafür sein Team kritisieren oder zum Einhalten agiler Regeln und Verhaltensweise auffordern muss, dann ist das so.

Es geht nicht um eine Vertrauensfrage. Der Scrum Master steht weder auf der Seite des Teams noch auf der Seite des Managements, sondern er ist lediglich der Wertschöpfung verpflichtet! Es ist wichtig, diesen Punkt von Anfang an klarzustellen und auch immer wieder zu betonen. Ein guter Scrum Master benötigt deshalb viel Erfahrung, Aufklärungsgeschick und auch feine Antennen für historisch gewachsene Verhaltensmuster („Kultur wirkt nach!“).

Konkret kann der Scrum Master genau differenzieren, wo ein Team seine Selbstverantwortung einfordern darf und wo nicht. Wenn es beispielsweise darum geht, Wege zu finden, wie ein Meilenstein erreicht werden kann, dann ist das eine Gemeinschaftsaufgabe des Teams mit dem Product Owner. Wenn es hingegen darum geht, wie das Team die Qualität sicherstellt, dann liegt das in der Verantwortung des Teams. Doch auch dann gilt das Gebot der Kommunikation. Es ist sehr wertvoll für das Team, konstruktiv darüber zu diskutieren, ob 100% perfekte Dokumentation (wichtig im reglementierten Umfeld) wirklich wichtiger sind als 100% Meilensteinerreichung. Wie könnten Kompromisse aussehen, die von allen vertreten werden können? Wie geht das Team mit bewusst gemachten technischen Schulden um? Darüber muss gesprochen werden!

Frage stellen

Teamprove Wissen

Auf unserer Q&A Plattform Teamprove Wissen können Sie Ihre Fragen mit uns und unserer Community diskutieren!
Frage stellen

Fazit

Der Scrum Master ist also nicht der Freund des Teams, sondern der Freund der Wertschöpfung. Um den kontinuierlichen Verbesserungsprozess voranzutreiben, kann – und muss – er manchmal auch unbequem und konfliktfreudig sein, vergleichbar mit einem Trainer im Sport.

Wie sieht es bei Ihnen aus? Sind Sie zufrieden mit der Kommunikationskultur in Ihren Projektteams und in Ihrer Organisation? Oder tun sich die Mitarbeiter schwer, effektiv zu kommunizieren? Mit unserer Kultur- und Strukturanalyse haben wir ein ausgereiftes Verfahren entwickelt, strukturelle Schwächen in Organisationen aufzudecken, die einer konstruktiven Kommunikation im Weg stehen. Interessiert? Sprechen Sie uns an, wir unterstützen Sie gerne.

Beitrag teilen

Alle Blogartikel
Markus Fuchs war als Agile Coach und Scrum Master bei Teamprove tätig.

Beitrag teilen