Die Frage kommt öfters – ich habe mal bei einem Barcamp bei Siemens eine kleine Session über Scrum gegeben. Das ist ja immer sehr interessant, denn Scrum ist zwar in der Info-Blase, in der ich mich bewege ein alter Hut, aber es gibt da draussen ja noch große Bereiche, in denen das überhaupt kein Thema ist und man sich bisher noch gar nicht damit beschäftigt hat. Und so kam auch hier wieder beim Scrum Master – als ich kurz die Rollen erklärt habe – die Frage: Was macht so ein Scrum Master eigentlich den ganzen Tag? Der hat ja eigentlich nicht viel zu tun, muss nur die paar Scrum-Events moderieren (also am Anfang das Planungsmeeting, dann jeden Tag ne viertel Stunde ein Daily Standup und dann noch das Review und die Retro, also ist er bei einem Zwei Wochen-Sprint nur 2 Tag ausgelastet und sonst nur eine viertel Stunde täglich beschäftigt…
Es liegt also nahe, dass Scrum-Master ein Job ist, den man so neben der Linien oder Dev.-Teamrolle so mitmachen kann. Es braucht also eigentlich keine eigene Person dafür…
Nun muss ich als Scrum Master mich natürlich rechtfertigen und sagen; NEIN, so einfach ist das nicht, der Scrum Master hat VIEL zu tun und ist unheimlich WICHTIG….ich will jetzt mal von dieser Frage etwas abschweifen und Dir später die Möglichkeit geben, die Frage selbst für Dich zu beantworten…
Kommen wir erstmal zu Daily Scrum oder auch Daily Standup genannt:
Nach dem Sprint-Planungsmeeting geht ja die Arbeit im Sprint los. Um während des Sprints die Transparenz im Team sicherzustellen, also dafür zu sorgen, dass jeder weiß was jeder andere im Team macht, woran er gerade arbeitet und was aktuell bremst, gibt es jeden Tag ein kleines Meeting, in dem maximal 15min lang darüber gesprochen wird: das Daily Standup oder kurz “Daily”. Standup wird es deshalb genannt, weil es am besten ist, das Meeting stehend vor dem physikalischen Taskboard durchzuführen – also nicht vor einem virtuellen Taskboard in einem Tool wie Jira oder Trello, sondern tatsächlich mit Zetteln an der Wand.
Nun ist das ein sehr kleines Meeting aber auch ein sehr wichtiges. Daher auch hier wieder ein paar Punkte, die Du vermeiden solltest, wenn Du als Scrum-Master unterwegs bist aber natürlich auch, wenn Du als Mitglied des Dev.-Teams oder als Product Owner dabei mitmachst.
Dinge, die Du beim Daily vermeiden solltest:
Nr. 1: Keine Routine: Wenn das Daily nicht an jedem Tag zum selben Zeitpunkt stattfindet, ist die Gefahr groß, dass es vergessen wird oder nur wenige Leute teilnehmen. Lass den Tag am besten mit dem Daily beginnen oder setze einen festen Termin kurz vor dem Mittag: Das hat dann auch den Nebeneffekt, dass alle gleich zum Essen wollen und deshalb das Meeting nicht zu lange dauert…
Nr. 2: Daily als Statusmeeting: Bitte achte darauf, dass das Daily kein Statusmeeting ist, in dem jeder kurz dem Product-Owner oder dem Scrum-Master berichtet, wie der Fortschritt ist. Das Daily dient dem Team. Damit jeder weiß, woran der andere arbeitet, wo vielleicht Hilfe benötigt wird oder gerade nichts zu tun ist. Und damit jeder weiß, ob gerade Probleme auftauchen und welche das sind.
Nr. 3: Daily nur als Aufzählung von Ticketnummern: Bitte kein lustloses: Gestern habe ich an Ticket 4711 gearbeitet und heute mache ich 4712. Probleme habe ich keine…Damit erreichst Du keine Transparenz. Bitte erzähle was Du gemacht hast und erzähle was Du heute bzw. gleich machen willst. Dokumentiere das, indem du die entsprechenden Zettel an der Wand bewegst. Und bitte verschweige keine Dinge, die dich an irgendwas hindern…Der Überbringer von schlechten Nachrichten wird hier nicht geköpft (Du sollest das, falls Du Scrum-Master bist, jedenfalls strengstens vermeiden)
Nr.4: Probleme gleich im Daily lösen: Bitte nicht ->Das Daily ist dazu da in kurzer Zeit Transparenz zu schaffen. Wenn Ihr gleich alle Probleme hier lösen wollt, wird das Meeting täglich Stunden dauern. Nein: Wenn Problem hochkommen, dann vertagt Euch mit der Besprechung auf später. Und nur die Betroffenen machen dann einen Termin aus um das Thema zu klären und nicht das gesamte Team!
Nr. 5: Verstecktes Planungsmeeting. Ähnlich wie Nr. 4: Hier werden keine neuen Anforderungen besprochen, hier werden keine Userstories angepasst oder geändert oder neue geplant. Dazu gibt es die entsprechenden Meetings wie Planung oder Refinement. Beim Daily geht es nur und das, was ihr jetzt macht -hier und jetzt – Um das geht es und um nichts anderes.
Nr. 6: nicht zuhören…Wenn ein Team-Mitglied über mehrere Tage Schwierigkeiten bei der Lösung einer Aufgabe hat und keiner Hilfe anbietet…kann das daran liegen, dass die Auslastung im Team zu hoch ist (es sind keine Zeitpuffer mehr vorhanden) oder dass man sich untereinander nicht vertraut…Bitte achte hierauf, falls Du Scrum-Master bist und gebe mal geeignete Trigger…
Nr. 7: Monologe: Die Leute kommen nicht zum Punkt und missachten das Timeboxing. Sorge als Scrum-Master dafür, dass die Leute in der Zeit bleiben und dass ihr nals Team die 15min einhaltet (Aber auch hier gilt natürlich wieder – nicht zu dogmatisch sein. Bitte nicht das Meeting nach 15min abbrechen, wenn nicht jeder was gesagt hat. Aber gibt deutliche Hinweise. Falls Du im Dev.-Team bist, denke einfach daran, dich kurz zu fassen. Jeder soll dran kommen und Du möchtest ja auch wissen, was die anderen tun…)
Nr. 8: Wir kennen das vielleicht noch aus der Muppet Show: Statler and Waldorf. Wenn ein paar Team-Mitglieder jeden Punkt kommentieren ist das nicht nur Zeitverschwendung sondern auch respektlos und nervig.
Nr. 9: Respektlosigkeit II: Ebenso ist es respektlos, wenn sich Team-Mitglieder unterhalten, während jemand anderes gerade dran ist und über seine Arbeit spricht.
Nr. 10: Aufgabenverteilung durch PO oder Scrum-Master: Das Dev.-Team entscheidet grundsätzlich wer was macht um das gemeinsame Zeil zu erreichen. Aufgaben werden nicht von oben delegiert.
Nr. 11: Ahnungslosigkeit: “Ich kann mich nicht mehr erinnern, was ich gestern gemacht habe”- Sowas geht natürlich gar nicht. Man kann auch mal nichts für das Projekt gemacht haben, weil vielleicht eine wichtige Linienaufgabe dran war. Aber dann sollte das auch offen kommuniziert sein und das wäre dann auch eher ein Hindernis…
12.: Respektlosigkeit III: Die Leute kommen zu spät zum Daily. Wenn Du Scrum-Master bist, erziehe die Leute zu einer gewissen Disziplin…Oft hat dabei schon ein kleines Sparschwein geholfen…Jede Minute zu spät = 1 Euro…(das gesammelte Geld dann natürlich nur für Teamevents zu nutzen…)
Nr. 13: Feedback-Stress: Wenn Team-Mitglieder andere Team-Mitglieder gleich im Daily kritisieren und Diskussionen vom Zaun brechen, solltest Du als Scrum-Master einschreiten. Kritik muss offen besprochen und geklärt werden, aber nicht im Daily, sondern danach.
Nr. 14: zu viele Teilnehmer: Ein Scrum-Team hat bekanntlich zwischen 3 und 9 Mitglieder. Wenn sich 20 Leute im Daily tummeln und jeder was zu sagen hat, haltet Ihr die 15min niemals ein…
Nr. 15: Unbeteiligte reden mit: Das Daily ist für das Entwicklungsteam. Es dient nicht dazu, das Stakeholder Kommentare abgeben oder aktiv teilnehmen. Sicherlich kann man mal ne Frage zulassen aber achte auf dem eigentlichen Zweck des Dailies.
Nr. 16: Linienvorgesetzte wollen im Daily die Performance von einzelnen Mitarbeitern beurteilen. Das ist nicht agil und zeigt einen sehr geringen agilen Reifegrad des Unternehmens. Es geht um die Selbstorganisation des Teams und nicht um Performance jedes einzelnen.
Soweit erstmal zu den Dingen, die ein Daily torpedieren können. Vielleicht fallen Dir auch noch ein paar Dinge ein, die in einem Daily schief laufen können. Falls ja, kannst Du dich gerne melden – z.B. über das Kontaktformular auf meiner Webseite agilophil.de
Aber kommen wir nun mal zurück zu der Frage, was ein Scrum-Master eigentlich den ganzen Tag so macht…
Im Scrum-Guide steht folgendes zu den Aufgaben eines Scrum-Masters:
Der Scrum-Master…
- Ist ein Servant Leader für das Scrum-Team
- schützt das Scrum-Team vor unnötigen Einflüssen von außen
- moderiert bei Bedarf oder Notwendigkeit die Meetings
- hilft in methodischen Fragen dem Product Owner
- coacht das Entwicklungsteam in Selbstorganisation und Cross-Funktionalität
- beseitigt Impediments oder Hindernisse
- hilft der Organisation bei der Scrum-Einführung
- hilft anderen, Scrum zu verstehen
- arbeitet an Organisationsveränderungen, die dem Team helfen, produktiver zu sein
- arbeitet mit anderen Scrum Mastern zusammen, um die Effektivität von Scrum in der Organisation zu verbessern
Das klingt jetzt ein bisschen statisch, aber letztlich ist der Scrum-Master das Mädchen für alles, was es braucht, damit das Team besser arbeiten kann. Du darfst Dir dabei nicht zu schade sein, auch mal durch das Büro zu laufen und neue Stifte für das Whiteboard zu besorgen oder mal den Kaffee aufzusetzen. Aber lass Dich als Scrum Master oder Scrum Masterin nicht darauf reduzieren nur die Sekretärinnen-Arbeiten zu übernehmen. Du hast immer 3 Hüte auf: einen des Trainers oder der Trainerin, die allen, die es wissen müssen, Scrum beibringt. Dann den Hut des Beraters oder der Beraterin, die Hinweise gibt, wie man sich in machen Situationen verhalten sollte oder was man bei Problemen tun kann. Und letztlich noch die Mütze des Coaches, der bei Problemen im Team Lösungen durch geeignetes Fragen finden kann (Merke: ein Coach hat nie selbst die Lösung, sondern lässt den Coachee die Lösung selbst finden in dem er geschickt Fragen stellt.)
Hier also noch ein paar Beispiele für Dinge, die ein Scrum-Master so macht. Was ich jetzt aufzähle, ist aber kein “Must Do” oder irgendwo festgeschrieben, sondern das sind alles Vorschläge und Ideen – Vieles von dem kann auch vom Product Owner oder vom Team übernommen werden, je nachdem wer Zeit dafür hat oder es am besten und schnellsten kann. Denke an den Teamgedanken. Wenn Du dich zurücklehnst und sagst, “das muss der Scrum-Master machen” und dich heimlich darüber freust, wenn kein Raum zur Verfügung steht und Du somit die Inkompetenz des Scrum-Masters deutlich machen kannst, hat das nichts mit Teamarbeit und Fokus auf ein gemeinsames Ziel zu tun. Das ist dann weit entfernt vom so oft beschworenen “agilen Mindset”.
Am sichtbarsten ist der Scrum Master natürlich bei allen Scrum-Meetings. Insbesondere sorgt er oder sie dafür, dass die Meetings regelmäßig stattfinden und die gewünschten Ergebnisse erreicht werden. Hier gilt es also eine Terminserie einzustellen, damit frühzeitig klar ist, wann die Sprints beginnen und enden, Räume zu buchen und sonstige Vorbereitungen zu treffen (wie z. B. ein paar Kekse oder Snacks zu besorgen). Beim Planungsmeeting kann – zumindest am Anfang – aber auch der Product Owner die Moderation übernehmen und beim Review das Team. Es ist auch durchaus sinnvoll das mal wechseln zu lassen, damit keine Langeweile im Sprint 34 aufkommt…
Die Retrospektive hingegen ist DAS Meeting des Scrum-Masters. Hier ist es wichtig, möglichst keine Routine aufkommen zu lassen und sich immer etwas Neues einfallen zu lassen. Kleine Spielchen, die die Teamsituation betreffen, oder unterschiedliche Abfragen, auf die ein Brainstorming folgen kann oder oder oder…Das Ergebnis der Retro ist mindestens eine Maßnahme, die direkt im nächsten Sprint umgesetzt werden sollte und die dazu dient, die Teamarbeit zu verbessern. Und das ist auch das Ziel des Scrum-Masters…
Zwischen den Meetings liegt die Haupttätigkeit des Scrum Masters in der Arbeit mit dem Team. Dazu gehört zu einem großen Bestandteil auch das reine Beobachten und Kennenlernen – Das Team sollte – besonders am Anfang- keinen Grund haben, dem Scrum Master zu misstrauen, aber ist es wichtig alle Mitglieder des Teams auch kennenzulernen und mit ihnen zu sprechen und anzusehen, wie alle miteinander im Team interagieren. Dazu gehört es auch, mal ein Teamevent zu organisieren, also gemeinsam zum Abendessen zu gehen oder mal Bowling zu spielen oder Kart zu fahren oder die sonstigen Dinge, die Spaß machen – oder einfach nach Feierabend mal mit den Teamkollegen ein Bierchen zu trinken. Das schmeckt auch alkoholfrei…
Das nächste große Thema des Scrum Masters sind die Impediments.
Der Scrum Master ist für die Beseitigung von Hindernissen zuständig. Dazu müssen diese erstmal aufgedeckt und gelistet werden. Hierzu bietet sich eine klassische to-do Liste an, wie sie ja gerne in Excel gepflegt wird aber natürlich sollte alles möglichst transparent sein, also auch irgendwie neben dem Taskboard auftauchen. Es geht darum, die Impediments zu beseitigen, das heißt aber nicht, dass der Scrum Master alleine alles lösen muss. Wenn Du Scrum-Master bist, dann sammle die Punkte und adressiere sie oder leite sie weiter und zwar so lange, bis sie gelöst sind. Hier kommt auch das unschöne Wort “Eskalation” ins Spiel – scheue Dich nicht davor, Langläufer bei oberen Hierarchiestufe bekannt zu machen, damit dann was passiert. In diesem Punkt ist die Arbeit des Scrum Master der des klassischen Projektmanagers am ähnlichsten – mit der Ausnahme, das der Scrum Master nicht wie der klassische Projektmanager automatisch an allem Schuld ist…
Es gibt noch eine ganze Menge mehr Dinge, die ein Scrum Master den ganzen Tag so macht und wenn Du Scrum Master bist, frage Dich einfach nur: „Was kann ich tun, damit es allen besser geht oder alle besser zusammenarbeiten können?“ Dann fällt Dir bestimmt noch viel ein…
Damit möchte ich die 6.Folge beenden und danke Dir fürs Zuhören.
Tschüß Dein agilophiler Frank
Für die Shownotes: weitere Tipps, was ein Scrummaster den ganzen Tag so macht, findest Du in einem viel beachteten Beitrag von “IT-agile”: