Der Scrum Master (m/w) ist einer der Spezialisten, die das agile Mindset, also agile Werte und Prinzipien, im Projektmanagement und der Produktentwicklung in Unternehmen und Organisationen einführen, vorleben, verankern. Dieses moderne Berufsbild ist vielschichtig und entsprechend spannend.
Lehrer der Scrum-Mechanik – und doch viel mehr
In frisch aufgestellten Projekt-Teams, die nach Scrum-Methodik Projekte managen bzw. Produkte/Dienste entwickeln, sind Scrum Master zunächst vor allem Lehrende: Sie geben den Produktentwicklern Input zur Mechanik von Scrum, bis diese verstanden wird. Im Falle von Scrum bedeutet dies, dass sie die im „Scrum Guide“ in seiner je aktuellsten Fassung angelegten Praktiken, Rollen, Meetings und „Artefakte“ und ihre Funktion/Bedeutung vermitteln.
„Rollen“ im Scrum sind, neben den Scrum Mastern selber, Produkteigner (product owner) und die „Entwickler“, was im Scrum schon lange nicht mehr nur IT-Programmierer meint, sondern eben alle, die die Aufgaben des Projekts in täglicher Kleinarbeit umsetzen. Alle zusammen – Scrum Master, Produkteigner und Entwickler – bilden das Scrum-Team. Und alle haben, naturgemäß, je spezifische Aufgaben und Verantwortlichkeiten: Der Produkteigner etwa befüllt das so genannte Product Backlog und bringt dessen Elemente („items“) in eine Reihenfolge der Abarbeitung. Das Product Backlog ist der Arbeitsspeicher, quasi die To-do-Liste des Gesamt-Projekts, so, wie das Sprint Backlog die To-do-Liste für den einzelnen Sprint darstellt.
Product und Sprint Backlog, Tasks und Inkrement: eine kleine Begriffslehre an Beispielen
Ein Product Backlog kann bspw. die Anforderungen einer Software beinhalten. Das sind bestimmte Funktionen, die in User Stories formuliert sind – zum Beispiel: „Als Online-Shopper möchte ich eine Bestell-Übersicht haben, die meine bestellten Produkte in zeitlicher Reihenfolge anzeigt“. Diese User Stories hängen als User Story Cards auf dem Taskboard des Scrum-Teams – oder sind digitale Kärtchen, falls der Prozessfortschritt digital gesteuert und sichtbar gemacht wird. In der analogen Variante kann man sich das Taskboard wie ein klassisches Kanban-Board vorstellen, mit Spalten wie „to do“, „in progress“ und „done“.
Diese Anforderungen/Funktionen werden im Sprint Planning und späteren Refinement Meetings auf Features bzw. Tasks heruntergebrochen, also den einzelnen Team-Mitgliedern zuzuordnende Aufgaben. Diese feingeschnittenen Aufgaben sollten sich innerhalb eines Arbeitstages erledigen lassen. Bezogen auf unser obiges Beispiel einer Online-Shopping-Software könnte das Feature, dass die besagte User Story verwirklicht („Als Online-Shopper möchte ich…“) dann ein Software-Programmcode sein, der die in der User Story enthaltene Anforderung umsetzt.
Da agile Projekte unvorhersagbare Ereignisse stets einkalkulieren – bzw. ja gerade auf die Entwicklung von Produkten und Diensten in komplexen Märkten mit sich rasch ändernden Kundenbedürfnissen fokussieren –, schneidet das Team im Sprint Planning zunächst nur Tasks für die ersten Tage des Sprints fein. Diese Tasks bilden das Sprint Backlog, das man sich wie den Arbeitsspeicher des einzelnen Sprints vorstellen kann. Die weitere Einteilung der Anforderungen in Tasks erfolgt dann im Spint-Verlauf, in Refinement Meetings.
Nun ist Scrum schon lange keine rein der IT und Software-Programmierung vorbehaltene Methode des Projektmanagements mehr, auch wenn Scrum ursprünglich aus der IT kommt. Daher möchte ich die Begriffe der Methode an einem zweiten, nunmehr ganz handfesten Beispiel illustrieren: Im Fall von Produkt- bzw. Industriedesign kann es etwa um die Entwicklung eines neuen Bürostuhls gehen. Im Product Backlog befinden sich dann alle Anforderungen, die für die Herstellung des Stuhls notwendig. Die einzelnen Sprints umfassen die einzelnen Arbeitsschritte, die für die Herstellung einer Komponente bzw. eines Teils des neu zu entwickelnden Bürostuhls nötig sind. Diese Teilprodukte heißen im Scrum „Inkremente“ und sind Resultat bzw. Ziel eines „Sprints“. Ein solches Inkrement kann die Armlehne unseres Stuhls sein. Die auf den Sprint von maximal 4 Wochen (in der Praxis oft verwendet: 2-wöchige Intervalle – Vorteil: frühere Iteration = früherer Check auf mögliche Fehl-Entwicklungen im Sinne des Auftraggebers) heruntergebrochenen Anforderungen könnten – bspw. – die Fertigung der Metall-Konstruktion oder (weitere mögl. Anforderung) der Stoff- oder Kunstleder-Überzug unserer Armlehne sein.
Die auf den einzelnen Arbeitstag zugeschnittenen Tasks des Sprints könnten dann bspw. notwendige Schweiß- oder Stanz- oder Schneidearbeiten sein (Metall-Bestandteil der Armlehne) oder entspr. Arbeitsschritte der Textilverarbeitung (Überzug der Armlehne).
Herzschlag im Scrum: Sprints
Sprints sind Teil-Projekte bzw. „Mini-Projekte“ mit eigener Dauer (maximal 4 Wochen, in der Praxis, wie geschrieben, oft auch zwei), an deren Ende eines der erwähnten Inkremente fertig gestellt ist.
Dieses Inkrement, das die Summe des im je aktuellen Sprint erstellten Teilprodukts und der Teilprodukte der vorausgegangenen Sprints darstellt, präsentiert das Team dann dem Produkteigner. Dieser vertritt die Kunden-, Nutzer- bzw. Auftraggeberseite und ist für die Wert-Maximierung des Gesamt-Produkts wie auch seiner in den Sprints erstellten Teile verantwortlich.
Das Meeting, in dem diese Präsentation stattfindet, wird vom Scrum Master organisiert und heißt „Review“. In der Review nimmt der Produkteigner das Inkrement entweder ab oder äußert, evtl. zusammen mit den Stakeholdern des Projekts, Verbesserungswünsche, die das Team in den Folge-Sprints umsetzt. Sprint Backlog, Product Backlog und Inkrement heißen im Scrum „Artefakte“.
In der „Retrospektive“, einem weiteren Scrum-Meeting, reflektiert sich das Team selbst, also seine Arbeit, die Zusammenarbeit, Prozesse, Interaktionen. Leitmotiv dabei ist: Was lief gut und soll beibehalten worden – was lief schlecht und sollte nicht weiter so gemacht werden?
Neben dem Input zur Scrum-Mechanik, also zu Rollen, Meetings und Artefakten, sind Scrum Master aber auch Facilitator, Moderatoren und Coaches „ihrer“ Teams.
Facilitation, moderation, teaching, coaching: Scrum Master – mehr als „nur“ Lehrende der Scrum-Mechanik
„Scrum is about people`s stuff!“ Das sagen langjährige Scrum-Anwender im angelsächsischen Raum gern, um zu verdeutlichen, dass die o. g. Mechanik (Rollen, Events, Artefakte) zwar wichtig, aber eben wie eine Grundmauer, ein Fundament zu verstehen ist. Der „Überbau“ ist, im Hinblick auf die sozialen Kompetenzen und die Empathie des Scrum Masters, komplexer: Scrum Master sind „servant leaders“, das heißt sie dienen dem Team, indem sie ihm helfen – nicht, indem sie es zu etwas zwingen. Das können sie auch nicht, weil sie keine Führungskräfte im hierarchischen Sinn sind.
Und dieses „dienen durch helfen“ meint im Alltag, dass sie auch Störungen, Konflikten im Scrum-Team bearbeiten bzw. ganz generell: sich fragen, was der Product Owner und das Team brauchen, um zusammenarbeiten zu können.
Scrum Master sind für ihr Team zunächst Teacher – etwa, wenn sie, gerade zu Beginn der Arbeit eines Teams mit Scrum, die bereits erwähnte Mechanik lehren.
Sie sind zu dem Facilitator, was im deutschsprachigen Raum meist mit „Moderatoren“ übersetzt wird und bspw. meint, dass sie die Meetings in Scrum moderieren und organisieren: also Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Das beginnt bei der Raum- und Zeitplanung, umfasst aber auch inhaltlich-konzeptionelle Moderation, bspw. die Vermittlung und Moderation von Phasen (stages), also der Struktur, die eine Retrospektive in der praktischen Umsetzung aufweisen sollte.
Als Coaches sind Scrum Master, wie Coaches generell, Geburtshelfer für Ideen und Antworten bzw. Lösungen, die in den Teammitgliedern selbst bereits liegen – aber eben noch nicht „freigelegt“ sind. Entsprechend bedienen sie sich hier auch nicht scrumspezifischer oder agiler Methoden, sondern genereller Coaching-Methoden wie Aktivem Zuhören, Fragetechniken oder Paraphrasieren. Auch ein fragend-entwickelndes Input eignet sich methodisch für diesen Teil ihrer Rolle: „Was könnte sich ändern, wenn wir X ausprobieren würden?“
Die Mentoren-Rolle schließlich dient ebf. der Vermittlung von Wissen, dies jedoch klassisch im 1:1-Format und in der unmittelbaren Arbeitssituation. Für den gelingenden Transfer empfiehlt es sich dabei einerseits, ebf. auf ein dem Coaching entliehenes fragend-entwickelndes Vorgehen zurückzugreifen. Zudem wird hier oft eine „Yoda-Vorgehen“ angesetzt, angelehnt an den kleinwüchsigen Jedi-Lehrmeister aus „Star Wars“: Wie dieser es gegenüber seinen Schülern tat, so meint auch Mentoring ein „anleiten zum selbst ausprobieren“.
WELCHE ERFAHRUNGEN HABT IHR IN DER PRAXIS MIT SCRUM GESAMMELT? WIE SEHT IHR DIE METHODE IM VERGLEICH ZUM KLASSISCHEN PROJEKTMANAGEMENT?
ICH BIN GESPANNT AUF EURE KOMMENTARE 🙂