Die Rolle des Scrum Master ist eine der einfachsten Rollen, die es im Agilen Projektmanagement gibt. Eigentlich ist es die leichteste Rolle im gesamten Unternehmen! Sie ist klar beschrieben (steht ja alles im Scrum-Framework), tiefgreifendes fachliches KnowHow ist nicht erforderlich (dafür ist das Entwicklungsteam verantwortlich), und das bisschen Moderation macht sich mit Links (vielmehr braucht es ja auch nicht). Oder doch nicht? Christian Konz beschreibt seine persönlichen Erfahrungen mit dieser Rolle.
Erstaunlich, dass diese Aussagen, wenn auch oft hinter vorgehaltener Hand, immer noch zu hören sind. Denn man sollte doch meinen, dass sich mittlerweile ein anderer Eindruck durchgesetzt hat. Für mich ist das zumindest Anlass genug, an dieser Stelle meine ganz persönlichen Erfahrungen mit dieser Rolle zu teilen. Sozusagen mein ganz persönliches Manifest der 7 Fettnäpfchen, die Scrum Master auf jeden Fall vermeiden sollten, damit es auch mit den Projektnachbarn klappt. Denn eigentlich geht es ja nur um eins – gemeinsam das Projekt zu wuppen!
Persönliches Manifest der 7 Fettnäpfchen
- Rollenkonflikte sind die Pest
Scrum Master sollten sich und ihrer Rolle treu bleiben. Viel zu oft gerät man in Versuchung, Meinungen oder Erwartungen anderer zu verteidigen, sich zu rechtfertigen. Sicherlich kommen Antworten oft besser an, als Fragen. Tatsächlich wird dadurch jedoch Kommunikation unterbunden. Die Integrität der Rolle bleibt auf der Strecke, wenn stellvertretend für andere Rollenträger Antworten gefunden werden, z.B. für die Rolle des Product Owners, der gerade nicht verfügbar ist. Scrum Master begeben sich dann sehr schnell auf Glatteis und geraten in die Rechtfertigungsfalle. Fokus, Fokus, Fokus … sie haben schon genug Aufgaben zu bewältigen, langweilig wird es auf keinen Fall. - Unpersönliche Email-Flut und der Cc…- noch schlimmer der Bcc…-Wahnsinn
Im Zweifel wird immer kommuniziert … und zwar direkt und persönlich. Scrum Master sind idealerweise immer auf ‚stand by‘ – auf Abruf. Ergebnisfokussierer, Problemlöser sowie Selbstorganisierer mit einer Prise ‚Prozessbegleitung‘ bitte. „Welches Schweinderl hättens gern? Oder was bin ich?“ (wer kennt diesen Spruch noch? Oh Mann, bin ich alt…) Als Scrum Master bin ich immer froh, wenn die Sprint-Planung abgeschlossen ist, User Stories verstanden und Abnahmekriterien sowie Definitions of Ready und Done formuliert und akzeptiert wurden. Kann also losgehen, der Sprint. Jedoch beginnt an dieser Stelle erst die eigentliche Arbeit für den Scrum Master. Zurücklehnen ist nicht! Denn im Sprint zeigen sich seine wahren Qualitäten.
Scrum Master blicken gleich durch mehrere Brillen. Zum einen gehört zu ihren Aufgaben, dass das Entwicklungsteam arbeitsfähig bleibt. Regelmäßige ‚Stand up Meetings‘ (Dailys) stellen sicher, dass es keinen zeitlichen Leerlauf gibt, Transparenz wird durch offenen Austausch und Scrumban-Boards gewährleistet. Offene Fragen werden direkt mit dem Product Owner geklärt, mit dem Scrum Master als Moderator oder besser gesagt als Mediator und Sparringspartner, der mit den richtigen W-Fragen dem eigentlichen Problem und vielleicht auch der Lösung auf die Schliche kommt. Denn Scrum Master treffen keine eigenen Entscheidungen bezüglich der Sprintaufgaben und deren Umsetzung, sondern tragen Verantwortung für das Verfahren, sie sind sozusagen Prozessverantwortliche. Ob und in welcher Form der Scrum Master selbst überhaupt inhaltliche Lösungsvorschläge unterbreiten darf, entscheidet nicht er, sondern das gesamte Team. Aber Vorsicht – an dieser Stelle kommt Punkt Nr. 1 wieder ins Spiel. - Transparenz mit Dokumentation verwechseln (Papier ist geduldig)
Was nicht dokumentiert ist, ist nicht wirksam. Da ist was Wahres dran. Wie häufig werden unnötige Schleifen gedreht, weil es damals zum Zeitpunkt der Entscheidung nicht schriftlich fixiert wurde. Genauso gilt aber auch im agilen Umfeld: So viel Dokumentation wie nötig, so wenig Dokumentation wie möglich! Dafür ist ein (virtueller) Speicher-Ort zu wählen, der für alle ohne große Umwege erreichbar und jederzeit zugänglich ist.
Das Zeitalter der ‚digitalen Kollaboration‘ eröffnet uns unzählige Möglichkeiten. Es sollte nur für alle klar und verbindlich geregelt sein, sonst entsteht schnell Wildwuchs – das große Suchen nach der aktuellsten Version oder dem jüngsten Fotoprotokoll beginnt – und das nervt! Transparenz hingegen geht noch einen Schritt weiter: zusätzlich zur Dokumentation sollten Information und Wissen verständlich, also auch noch nach Wochen nachvollziehbar, vollständig, aktuell und kommunizierbar sein (siehe auch Punkt Nr. 2).
Wir in der ibo Akademie z.B. stellen über unser Board (ein virtuelles OKR-Kanban-Board, Marke: Eigenbau!) die Transparenz und den Arbeitsfluss sicher, dokumentieren und speichern jedoch (nicht zuletzt aus Datenschutzgründen) zentral auf einem korrespondierenden Netzwerklaufwerk auf unserem Server. Sicher ist sicher – und es funktioniert (wenn sich alle daranhalten)! Verbindliche Working Agreements, die die gemeinsamen Regeln der Zusammenarbeit festhalten, helfen dabei! - Heute so und morgen so – Was interessiert mich mein Geschwätz von gestern?!
Keine Frage, die Ansprüche und Anforderungen an Scrum Master sind hoch. Der Anspruch ‚auf alles eine Antwort zu haben‘ gehört jedoch sicher nicht dazu. ‚Probieren geht über Studieren‘ schon eher. Denn durch Ausprobieren erfährt man am besten, ob etwas funktioniert oder nicht. Es ist besser, etwas in der Praxis zu erproben, als es sich theoretisch herzuleiten, nur, weil es im Lehrbuch steht. Vorgekaute Modelle und Methoden gibt es zu Hauf. Erst beim Ausprobieren und Reflektieren stellt man fest, ob empfohlene Methoden, Modelle und Werkzeuge ‚passen‘, sprich von den Anwendern akzeptiert und tatsächlich auch genutzt werden.
Kontinuierliche Optimierung (KVP), Trial & Error im Sinne des Leitprinzips ‚safe enough to try‘ und iteratives-inkrementelles Vorgehen bedingen einander und sind nicht ohne Grund wesentliche Bestandteile agilen Handelns. Also keine Angst vor sog. ‚but‘ (Aber)-Regeln – soll heißen, auch wenn nicht 1:1 nach Lehrbuch vorgegangen wird, in unserer agilen Praxis funktioniert’s. Wenn ein Kochrezept nicht schmeckt, hat man ja auch keine Skrupel es zu ändern.
Ausnahmen bestätigen schließlich die Regel! Aber Vorsicht: Agilität ist nicht ‚heute so und morgen so‘ oder ‚was interessiert mich mein Geschwätz von gestern‘. Agilität bedeutet beweglich und flexibel zu sein, sprich, selbstorganisiert zu agieren, und gleichzeitig gemeinsam an einem effizienten und effektiven Strang zu ziehen – und das erfordert Prinzipientreue und Durchhaltevermögen. - Das allwissende Orakel (… oder die Quelle allen Übels?)
Vorsicht vor Überheblichkeit und Borniertheit. Auch ein Scrum Master kann (und soll) nicht alles wissen. Zur Teamorientierung gehören immer mindestens zwei. Um ungewollte, informelle Hierarchien zu vermeiden (gewollte, informelle Hierarchien gibt es auch), sollten gerade Scrum Master offen für Feedback und Anregungen sein. Lösungen werden gemeinsam erörtert und einem praktischen ‚Klemmtest‘ unterzogen. Wer sich diese Offenheit bewahrt und sein eigenes Ego zurückstellt, der bleibt authentisch und akzeptiert. Wer Coaching aber mit Beratung verwechselt und als Einbahnstraße wohlwollender Ratschläge versteht, der steht ganz schnell alleine da. Denn es wird über kurz oder lang keinen mehr geben, der zuhört. - Hier herrscht eine hierarchiefreie Zone, basta!
Grundvoraussetzung für eine agile Organisation sind selbstorganisierende, emergente Teamstrukturen (siehe hierzu auch: Die Mär vom Team). Hierarchie und selbstorganisierende Teams schließen sich nicht aus. Mit Komfortzone und Wohlfühlambiente hat agile Teamkultur wenig zu tun. Vielmehr ist es ein ‚Kampf mit offenem Visier‘ und mit fairen Mitteln. Soll heißen, transparente Team-Performance ermöglicht Benchmarking zwischen Teams und fördert organisationales Lernen.
Führungskräfte sind gut beraten, wenn sie ihre Aufgabe trotz Selbstorganisation weiterhin wahrnehmen und ihren Teams Planungssicherheit, einen klaren Führungsstil und transparente Unternehmensziele mit auf den Weg geben. Klare Kompetenz- und Verantwortungsbereiche schaffen darüber hinaus Verlässlichkeit und Systemvertrauen. Auf diese Weise funktionieren z.B. OP-Teams im Krankenhaus, Teams im Flugzeug-Cockpit und Mannschaften im Teamsport. Eine Basketball-Mannschaft hat einen Spielmacher, Flügel- und Center-Spieler. Sie spielen genau auf der Position, die sie am besten beherrschen, können sich, wenn es darauf ankommt, aber auch aushelfen. Und alle orientieren sich (hoffentlich) an den Vorschlägen ihres Coachs und folgen den Anweisungen des Team-Managers, um am Ende als Sieger vom Feld zu gehen. Und falls sie das nicht tun, dann werden sie ausgewechselt. Wenn das nicht (agile) Hierarchie ist! 😉 - Ich habe fertig (FALSCH, Thema verfehlt: setzen, 6!)
Wenn agiles Projektmanagement konsequent gedacht und gemacht wird, dann haben Scrum Master einen der sichersten (und einen der spannendsten und abwechslungsreichsten) Jobs der Welt. Denn sie sind nie fertig. Sobald sich dieser Eindruck verfestigt, gilt es gegenzusteuern. Damit die agile Team- und Organisationsentwicklung nicht auf halber Strecke verpufft, braucht es ein sinnvolles Maß an Unterstützung und Begleitung.
In Abstimmung mit Agile Coachs unterstützen Scrum Master individuell und teamübergreifend dabei, Hindernisse auf dem Weg zu einer agilen Organisation zu identifizieren und zu beseitigen. Reflexions- und Feedbackprozesse müssen angestoßen, Manöverkritik geübt und Arbeitsweisen kontinuierlich angepasst/verbessert werden. Scrum Master fördern und fordern. Wer eine Aufgabe übernimmt, wird daran gemessen, wie er sie meistert. Das gilt für Product Owner, Entwicklungsteams und Scrum Master gleichermaßen – eigentlich für alle Organisationsmitglieder! 🙂
Schon gewusst?
Unsere SAFe-Weiterbildungen machen Dich fit für die agile Projektwelt! Wir bieten Dir die Weiterbildung und Zertifizierung in deutscher Sprache mit deutschen Unterlagen zum SAFe® Scrum Master, SAFe® Product Owner / Product Manager und SAFe® Agilist an.
Hier erfährst Du alles über die SAFe-Zertifizierungen | ibo Akademie.