Tobias Renk - Der Scrum-Reiseführer

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.

Die Hauptaufgabe der Entwickler ist es, ein nutzbares Produktinkrement am Ende eines Sprints erzeugt zu haben. Wir werden in Kapitel 5.5 und 5.6 noch einmal intensiv auf diesen Punkt eingehen, da er ein essenzieller Bestandteil von Scrum ist und in der Praxis manches Mal falsch umgesetzt wird. Die Betonung liegt insbesondere auf nutzbares Produktinkrement, also etwas, was Fachabteilungen im operativen Geschäft verwenden können und das einen Nutzen, einen Mehrwert, bringt.

Die lediglich drei vorhandenen Rollen in Scrum erwecken den Eindruck, dass Vorgehensmodell sei einfach umzusetzen und strukturiert. In der praktischen Anwendung führt ebendiese Einfachheit jedoch gelegentlich zu Verwirrungen. Das Verständnis für das Konzept crossfunktionaler Teams ist deshalb umso wichtiger. Crossfunktional bedeutet, dass in einem Entwicklerteam alle notwendigen Kenntnisse, um ein Produktinkrement zu erzeugen, vorhanden sind. Zerlegen wir als Beispiel einen Softwareentwicklungsprozess in drei Schritte: Analyse, Programmierung, Testen. Ein Scrum Team würde mindestens diese drei Fähigkeiten abbilden müssen. Im Idealfall wird jeder Schritt von einem Experten begleitet, der über zusätzliches Know-how in den anderen Bereichen verfügt. Solche Teammitglieder bezeichnet man als T-Shaped ProfessionalsT-Shaped Professional (siehe Abbildung 6). Der große Vorteil besteht darin, dass T-Shaped Professionals Tiefenwissen (Expertenwissen) in einem Bereich besitzen und zeitgleich über ein Breitenwissen aus anderen Bereichen verfügt. Solche Mitarbeiter haben in der Regel einen scharfen Blick für das große Ganze und greifen die Gesamtzusammenhänge schnell; eine Fähigkeit, die besonders in dynamischen und agilen Arbeitsumgebungen von Vorteil ist.

Abbildung 6:

T-Shaped Professionals

Um die oben beschriebene Hauptaufgabe, ein nutzbares Produktinkrement am Ende eines Sprints zu erzeugen, erreichen zu können, sind folgende Tätigkeiten ebenfalls in der Verantwortung des Entwicklerteams: Das Team erzeugt einen Plan für den Sprint, das sogenannte Sprint Backlog. Hierin werden alle Aufgaben, die innerhalb des Sprints erledigt werden sollen, transparent aufgelistet. Um jedoch eine zielgerichtete Erledigung der Aufgaben zu gewährleisten, ist es notwendig, Abhängigkeiten bereits im Vorfeld zu identifizieren und die Planung entsprechend anzupassen. Wird dieser Punkt nicht beachtet, könnten einzelne Aufgaben die Tätigkeiten anderer Teammitglieder blockieren und somit die Erreichung des Sprintziels gefährden. Das Entwicklerteam ist maßgeblich für die Qualität des Produktes zuständig. Hierbei ist vor allem die Definition of Done wichtig, die konkret definiert, wann eine bestimmte Aufgabe oder User Story fertiggestellt ist. Qualität sollte dabei bereits als integraler Bestandteil des Entwicklungsprozesses gesehen werden, um sie von vornherein in das Produkt zu integrieren und nicht erst anschließend in aufwendigen Testphasen zu ergänzen. Dieser Umgang mit Qualität ist eine Umsetzung des Andon Cords, dass bei Toyota Verwendung findet und zu einer enormen Steigerung der Qualität geführt hat. Das Andon Cords ist eine Leine, die jeder Mitarbeiter entlang der Produktionsstrecke ziehen kann – und damit die gesamte Produktion stoppt –, sobald ihnen Qualitätsmängel auffallen. Als Folge werden Probleme und Qualitätsmängel frühzeitig im Prozess erkannt und können kostengünstiger korrigiert werden, als wenn man diese nach der Produktion feststellt. Die tägliche Anpassung des Plans gehört deshalb zu den Aufgaben eines Entwicklerteams. Die Korrekturen finden im Rahmen der Daily Stand-ups statt. Sie dienen dazu, den Weg zum Sprintziel zu optimieren und somit das Ziel schneller, effizienter oder günstiger zu erreichen. Veränderungen, die keinen Einfluss auf die Erreichung des Sprintziels haben sind obsolet. Darüber hinaus trägt jedes Teammitglied die Verantwortung, sich selbst und die anderen immer wieder aufs Neue in die Pflicht zu nehmen, die vereinbarten Ergebnisse im Rahmen eines Sprints zu erreichen.

Die Rolle des Scrum MastersScrum Master ist entscheidend bei der Implementierung von Scrum in Unternehmen. Der Scrum Master übernimmt gleich mehrere Schlüsselaktivitäten, die maßgeblichen Einfluss auf eine erfolgreiche Einführung haben. Zusammengefasst kann die Rolle so definiert werden, dass der Scrum Master der Dienstleister im Scrum Team ist, denn seine Hauptaufgaben als Servant LeaderServant Leader, die wir uns im Nachgang näher anschauen werden, weisen einen gewissen Dienstleistungscharakter auf.

Der Scrum Master ist dafür zuständig, Scrum als Produktentwicklungsmethode in einem Unternehmen einzuführen und zu etablieren. Diese Aufgabe beinhaltet zu einem großen Teil Training- und Coachingaktivitäten, um das Team und die Organisation zuerst mit den üblichen Begrifflichkeiten und ihren jeweiligen Bedeutungen bekannt zu machen. Ein wesentlicher Aspekt für die erfolgreiche Einführung von Scrum ist, dass die Aufgabe des Scrum Masters die Teamgrenzen überschreitet. Erst wenn auch das Stakeholder-Umfeld mit Scrum verstanden hat, wie Scrum funktioniert und welche Anforderung auf die umstehenden Parteien außerhalb des Teams zukommen, hat Scrum eine Chance, erfolgreich zu sein. Es ist dabei in der Praxis nicht so wichtig – der eine oder die andere mag hier widersprechen –, dass Scrum eins-zu-eins wie im Scrum Guide beschrieben umgesetzt wird. Vielmehr ist es ausschlaggebend, dass der Scrum Master das Unternehmen mit agiler Denkweise, dem oft zitierten Agile Mindset, vertraut macht und dass eine Variante von Scrum gefunden wird, die zum Unternehmen passt und bestmögliche Erfolgsaussichten hat. Weiterhin hat der Scrum Master die Aufgabe, sich um die Effektivität des Scrum Teams zu kümmern und es dabei zu unterstützen, sich stetig zu verbessern. Dies kann auf vielfältige Weise geschehen. Dazu gehören gut strukturierte Retrospektiven ebenso wie offene und ehrliche Gespräche mit dem Team und mit einzelnen Mitgliedern. Die in Managementliteratur immer prominenter werdende Transparenz kann sich genauso durch Teamzusammenkünfte mit allen Personen wie auch im Einzelgespräch mit den Mitgliedern herauskristallisieren. Die vertrauensvollere Atmosphäre unter vier Augen lässt die ein oder andere Schwierigkeit in den Aufgaben oder im Team manchmal eher ans Licht kommen. Das verdeutlicht, dass ein guter Scrum Master Fingerspitzengefühl für unangenehme Situationen oder schwelende Konflikte benötigt, um diese zeitnah zu beseitigen, bevor daraus größere Probleme erwachsen.