Der Scrum-Reiseführer. Tobias Renk
ging es bisher um die Beantwortung von zwei zentralen Fragestellungen: Die Entscheidung, welche Product Backlog Items im nächsten Sprint bearbeitet werden sollen und wie diese realisiert werden können. Im aktuellen Scrum Guide kommt nun eine dritte Fragestellung hinzu: Warum ist der Sprint sinnvoll bzw. wie kann der Wert des Sprints am effektivsten maximiert werden? Mit der genauen Beschreibung dieses Sprintziels bekommt das selbstverwaltende Team eine klare Richtschnur für den Sprint.
In Abbildung 3 wird das Zusammenspiel der Scrum Rollen, der Scrum Events, der Scrum Artefakte und der zugehörigen Commitments dargestellt.
Scrum Framework
4 Scrum Rollen – Die Idealbesetzung eines Scrum Teams
Unsere Reise in Scrum ist weniger auf den Individualtouristen ausgerichtet, sondern erlangt seine volle Pracht erst in einer Gruppe, die zu einem echten Team werden soll. Lernen Sie daher die Wege kennen, die auch abseits grauer Theorie einen perfekten Blick auf das Wesentliche bei der Teamzusammensetzung geben.
4.1 Passende Rollenbesetzung als Erfolgsschlüssel
Wie in jedem Team ist die passende Rollenbesetzung wichtig. Eine Reisegruppe zu den Pyramiden Südamerikas hat viel mehr Spaß, wenn ein kenntnisreicher Reiseführer dabei ist. Eine Fußballmannschaft ohne Torwart dürfte es schwer haben, Spiele zu gewinnen. Und auch ein American Football Team dürfte vor großen Herausforderungen stehen, ohne Quarterback im Super Bowl zu brillieren. Auch Scrum „benötigt“ bestimmte Rollen, damit es in der Praxis gut funktionieren kann.
Scrum macht es sich dabei sehr einfach, denn es gibt nur drei RollenScrum Rollen: Den Product Owner, den Scrum Master und das Entwicklungsteam. Wie die Rollenbezeichnungen schon andeuten, sind der Product Owner und der Scrum Master jeweils eine Person, das Entwicklungsteam jedoch eine Gruppe (siehe Abbildung 4).
Rollen in einem Scrum Team
Ein wesentlicher Aspekt von Scrum ist, dass es prinzipiell keine Hierarchien innerhalb des Teams gibt. Zwar hat jede Rolle die ihr zugeordneten Aufgaben, für die sie jeweils auch verantwortlich ist, aber ein hierarchisches Gefälle, in dem eine Person Anweisungen erteilt, die dann nur noch von anderen ohne Hinterfragen umgesetzt werden, wird klar vermieden. Diese Freiheit hat Vor- und Nachteile. Einerseits wird das Wissen aller Teammitglieder eingebracht, was in der aktuellen VUCA-Welt sinnvoll und notwendig ist – die notwendige Expertise für eine Produktentwicklung konzentriert sich auf Grund der Komplexität nicht in einem Individuum. Andererseits gibt es in der Praxis Momente, in denen der eine oder die andere sich ein bisschen „Basta“-Mentalität zurückwünscht, um längere Diskussionen abwürgen zu können. Und damit sind wir schon bei einem Kernthema von Scrum und von agilen Arbeitsmethoden im Allgemeinen: Kommunikation. Agile Arbeitsmethoden benötigen zwingend deutlich mehr Kommunikation und Abstimmung als Wasserfall-Methoden.
Wenn es keine Hierarchien innerhalb des Teams gibt, bedeutet das zusätzlich, dass das Team sich selbst organisieren muss. Selbstorganisierende Teams sind derzeit äußerst beliebt und finden als Schlagwort Eingang in viele Reden, Präsentationen und Veröffentlichungen (wie auch in diese). Aber was bedeutet Selbstorganisation überhaupt für ein Scrum Team? Wo liegen die Schwierigkeiten? Wie sieht das in der Praxis aus? Und kann das überhaupt funktionieren oder ist es eine Wunschvorstellung vom idealen, aber nie zu erreichenden Team Utopia? Die gute Nachricht ist, es kann funktionieren. Die Schlechte ist, es gestaltet sich oft schwieriger als es oft erwartet wird. Selbstorganisation bedeutet, dass das Scrum Team die Art und Weise der Zusammenarbeit innerhalb eines vorgegebenen Frameworks selbst definiert. Orchestriert wird das Ganze vom Scrum Master. In der Praxis kann dies eine Herausforderung für den Scrum Master sein. Dafür gibt es zwei Gründe: Erstens befürchten viele Manager einen gewissen Kontrollverlust, wenn sie dem Scrum Team nicht die Art und Weise der Zusammenarbeit vorgeben können. Zweitens fällt es manchen Mitarbeitern schwer, mit der neugewonnenen Freiheit umzugehen. Dies ist umso verständlicher, wenn man berücksichtigt, dass viele Unternehmen die letzten Jahre oder Jahrzehnte in einer Wasserfallwelt zuhause waren, in der sich eine Kultur der Compliance entwickelt hat. In einem solchen Umfeld wurde den Mitarbeitenden wenig Freiheit gegeben, um eigene Ideen voranzutreiben und auszuprobieren. Wird nun Selbstorganisation über Nacht per Dekret eingeführt, weil das Wort häufig in Verbindung mit agilen Arbeitsweisen fällt, kann dies schnell zu einer Überforderung der Mitarbeitenden führen, die noch kein Vertrauen in die neue Herangehensweise entwickeln konnten. Die Ursache beider Punkte liegt im agilen Mindset, das sich erst noch im gesamten Unternehmen ausbilden muss. Dieser Vorgang benötigt Zeit und sollte durch einen umfassenden Veränderungsprozess begleitet werden.
Scrum Teams sind crossfunktional, was bedeutet, dass innerhalb des Teams alle Fähigkeiten vorhanden sind, die für die Erreichung des Produktziels notwendig sind. Nehmen wir als Beispiel eine Webapplikation, die unter Verwendung von Wetter- und Verkehrsdaten die Besuchszahlen für einen Zoo vorhersagen will. Ein solches Scrum Team könnte aus einem Product Owner, einem Scrum Master und Entwicklern bestehen, die folgende Fähigkeiten bereithalten: UX/UI-Design, Frontend- und Backendentwickler, Testentwickler, Datenbankentwickler, Data Scientist.
Das obige Team würde aus circa sieben Mitgliedern bestehen (abhängig davon, ob bestimmt Fähigkeiten in einer Person vereint sind oder, ob bestimmte Kompetenzen mehrfach vorhanden sein müssen). Die Frage nach der Größe eines Scrum Teams wird vor dem Beginn des Projektes beantwortet. Folgende Faustregel kann dabei verwendet werden: Das Scrum Team sollte klein genug sein, um flexibel agieren zu können und den Kommunikationsaufwand nicht zu groß werden zu lassen. Gleichzeitig sollte es groß genug sein, um einen signifikanten Fortschritt zu erzielen. Typischerweise liegt die Zahl zwischen sieben und neun Teammitglieder. Kleine Teams sind meist produktiver und kommunizieren effizienter. Jeff Bezos hat bei Amazon die Zwei-Pizzen-Regel eingeführt, um die ideale Teamgröße für ein produktives Arbeiten zu bestimmen (siehe Abbildung 5).
Performance – Teamgröße
Sie besagt, dass an einem Meeting nur so viele Mitarbeiter teilnehmen dürfen, wie von zwei Pizzen satt werden. (Achtung, gemeint sind amerikanische Pizzen, die im Gegensatz zu europäischen Pizzen einen Durchmesser von 40 cm anstatt von 26 cm haben. Von einer amerikanischen Pizza werden vier Personen satt.) Die Anzahl an Teilnehmern ist demnach auf acht beschränkt. So willkürlich diese Zahl erscheinen mag, sie ist wissenschaftlich fundiert und wird auch von Bob Sutton in seinem Buch Scaling Up Excellence: Getting to More without Settling for Less bestätigt. Wird ein Team zu groß, sollte das Team in kleinere Einheiten zerteilt werden. Ab jetzt betreten wir den Bereich der Skalierung von agil, der wir uns später in einem separaten Kapitel widmen. So viel sei bereits an dieser Stelle gesagt: Wird das Thema Skalierung nicht umfänglich durchdacht, was in der Praxis häufiger vorkommt, kann dies mittel- und langfristig sowohl zu funktionalen als auch technischen Problemen führen, die nur mit einem enormen Zeit- und Kostenaufwand wieder beseitigt werden können.
Scrum Teams kümmern sich um alles Produktbezogene. Das umfasst unter anderem das Stakeholder Management, das Erfassen und die Verifikation von Anforderungen (in Form von Epics und User Stories), die Entwicklung eines wert- und sinnvollen Produktinkrements am Ende eines Sprints, den operativen Betrieb und was sonst noch alles anfallen könnte. In einem solchen Szenario kann es zu Situationen kommen, in denen die Teammitglieder eigenverantwortlich Entscheidungen im Sinne des Produktes treffen müssen. Um die Produktivität des Teams durch aufwendige Rücksprachen dazu nicht zu behindern, ist ein gewisser Spielraum förderlich, indem selbst Entscheidungen getroffen werden dürfen. Hierbei spricht man von Empowerment. Es ist ein wesentlicher Erfolgsfaktor von agilen Teams, wenngleich sich dieser Aspekt auf Grund der bereits oben genannten Herausforderungen als schwierig in der Praxis erweisen kann.
4.2 Entwickler als T-Shaped Professionals
Die Hauptaufgabe der Entwickler