“A good game is easy to learn but hard to master.” Dieses Zitat von Nolan Bushnell, dem damaligen Atari-Gründer, ist mir als Erstes in den Sinn gekommen, als ich diesen Blogpost begonnen habe.
Warum? Da sich dieses Zitat auch wunderbar auf Scrum anwenden lässt. Nicht umsonst beginnt der Scrum Guide mit der Zeile „The Definitive Guide to Scrum: The Rules of the Game“. Und in gewisser Weise kann man Scrum ebenfalls als ein Spiel sehen …
Ähnlich einem Spiel, in dem man zunächst die Spielregeln lernen und verstehen muss, bevor man mit dem Spielen beginnen kann, verhält es sich auch mit Scrum.
Wobei die Spielanleitung bzw. das Tutorial mit allen relevanten Informationen auf kompakten 14 Seiten des Scrum Guides Platz finden. Aber zwischen Lesen, verstehen und in der Praxis anwenden, gibt es so manchen Platz für Missverständnisse. Missverständnisse, die oft in Form von Anti-Pattern in der Praxis auftreten.
Fünf dieser Anti-Pattern, die wir in der Praxis immer wieder vorfinden, haben wir gesammelt und werden sie hier näher beleuchten. Los geht’s.
Anti-Pattern 1: Nicht alle Rollen innerhalb des Scrum-Teams sind besetzt
Scrum ist so designt, dass es innerhalb eines Scrum-Teams unterschiedliche Rollen (Entwickler, Scrum Master, Product Owner) gibt, die unterschiedliche Aufgaben wahrnehmen müssen, um das gemeinsame Sprintziel erreichen zu können. Oft werden bestimmte Rollen aber als optional angesehen. Was sie nicht sein sollten.
Der Wegfall von Rollen führt dazu, dass die Aufgaben innerhalb des Teams umverteilt werden müssen. Und schon kippt die Balance zwischen Abstimmung und Lieferung von Mehrwert; mit dem Ergebnis, dass das Sprintziel nicht erreicht werden kann oder die Qualität des Inkrements leidet. Eine Rolle, die gerne dem Rotstift zum Opfer fällt, ist der Scrum Master.
Warum? Nun, von außen betrachtet ist der Scrum Master die einzige Rolle, die nicht aktiv an der Fertigstellung bzw. Erfüllung des Sprintziels beteiligt ist.
Schaut man genauer hin, ist das natürlich ein Trugschluss. Scrum Master haben einen entscheidenden Anteil am Erreichen des Sprintziels und sollten stets fester Teil des Scrum-Teams sein. Scrum Master tragen dazu bei, dass innerhalb des Scrum-Teams jeder seine Arbeit erledigen kann, den Fokus nicht verliert und sich das Team kontinuierlich weiterentwickeln (persönlich und fachlich) kann. Fehlt ein Scrum Master im Team, ist dies deutlich mess- und spürbar.
Daher der Appell: Besetzt Scrum-Teams mit allen notwendigen Rollen. Besetzt die Rollen nicht doppelt. Setzt den Rotstift besonders nicht beim Scrum Master an. Die Nichtbeachtung wird sich negativ auf das Produkt und dessen Qualität auswirken.
Anti-Pattern 2: Liefermodell innerhalb einer Multiprojekt-Umgebung
Scrum ist ein Liefermodell, dass es einem Scrum-Team ermöglicht, ein Produkt kontinuierlich zu verbessern und weiterzuentwickeln. So weit zur Theorie im Scrum Guide.
In der Praxis findet man dieses Setup aber nicht immer vor. Vielmehr scheint das Standardmodell ein Multiprojekt-Umfeld zu sein. Darin arbeitet ein Scrum-Team an mehreren Produkten bzw. in mehreren Projekten gleichzeitig. Wie wirkt sich eine solche Arbeitsweise aus?
Scrum ist ein auf Balance ausgelegtes Framework, das seinen Focus auf die kontinuierliche Auslieferung eines Inkrements hat. Balance in dem Sinn, dass die Zeit, die es für Abstimmungen und Kommunikation innerhalb des Teams braucht, in einem guten Verhältnis zu der Zeit steht, die benötigt wird, um am eigentlichen Produkt zu arbeiten.
Was passiert nun, wenn ein Scrum-Team statt an einem Produkt an, sagen wir, drei Produkten gleichzeitig arbeitet? Die Balance gerät aus dem Gleichgewicht. Denn die Zeit für Abstimmung und Kommunikation innerhalb des Teams nimmt zu. Währen die effektive Zeit, die an einem Produkt gearbeitet werden kann, abnimmt.
Zusätzlich geht Zeit durch Kontextwechsel verloren. Denn jedes Mal, wenn das Team oder einzelne Teammitglieder von einem auf das andere Produkt wechseln, müssen sie sich erst in die neue Fachdomäne eindenken. Ähnlich der Rüstzeit einer Maschine in der Industrie, gibt es auch Rüstzeiten für Wissensarbeit. Zudem sind solche digitalen Rüstzeiten anstrengend und verbrauchen mentale Energie, die sonst dem Produkt zugutekommen würde.
Daher der Appell: Der effizienteste Weg ein Produkt nach vorne zu bringen, ist, mit einem Team in Vollzeit daran zu arbeiten.
Anti-Pattern 3: Reporting statt Transparenz
Zu den Grundpfeilern von Scrum gehört auch die Transparenz. Alle relevanten Informationen sollten jederzeit abrufbar sein. Und zwar innerhalb wie auch außerhalb des Scrum-Teams. Es braucht also kein aktives Reporting, sondern transparente Strukturen.
Und genau hier liegt ein Anti-Pattern versteckt: Besonders zu Beginn der agilen Arbeit mit Scrum gibt es die Erwartungshaltung in Richtung des Scrum-Teams, den Fortschritt während des Sprints und andere Kennzahlen kontinuierlich zu reporten. Was aber durch eine transparente Bereitstellung z. B. in Form von Metriken und durch regelmäßige Rituale wie z. B. dem Review am Ende eines Sprints gar nicht mehr notwendig ist.
Die Verantwortung liegt also nicht mehr darin, regelmäßig Reports an Vorgesetzte zu schicken. Sondern vielmehr darin, die geleistete Arbeit transparent darzustellen, sodass diese Information jederzeit bei Bedarf abgerufen werden können.
Daher der Appell: Anbieten statt liefern. Transparenz statt Reporting. Zu Beginn eine Umstellung, auf Dauer aber ein großer Gewinn.
Anti-Pattern 4: Schätzungen werden als Commitment gewertet
Kennt ihr das? Schätzungen werden gerne als Commitment gewertet. Und nicht als das, was sie sind – Schätzungen in einem komplexen Umfeld nach besten Wissen und Gewissen.
Aber wozu wird im agilen geschätzt, wenn eine Punktlandung besonders zu Beginn eher unwahrscheinlich ist? Um anhand von empirischen Verhalten in der Lage zu sein, eine Planung durchführen zu können! Geschätzt werden sollte auch nicht nach Aufwand oder Zeit, sondern stets in Komplexität.
In Relation zu einer einfachen, gut schätzbaren Referenz-Story. Dieses Vorgehen ermöglicht nach einem gewissen Zeitraum, Vergleichswerte zu besitzen und somit eine recht gute Annäherung an die ursprüngliche Schätzung. Mit anderen Worten: Je längere man schätzt, desto genauer werden die Schätzungen werden.
Daher der Appell: Schätzungen sind und bleiben Schätzungen. Dank Empirie nähert sich ein Team nach und nach den gemachten Schätzungen. Aber besonders in einem neuen Umfeld werden Schätzungen zu Beginn nur Näherungswerte sein können.
Anti-Pattern 5: Der Product Owner hat nicht die notwendige Produkthoheit
Wird Scrum in Organisationen neu eingeführt, bleiben die alten Entscheidungsstrukturen im Hintergrund oft aktiv. Diese entscheiden dann meist nach wie vor über die Richtung, die ein Produkt einschlägt.
Ein Modell, das hier helfen kann, ist das Product Ownership Evolution Modell – kurz POEM. POEM hilft dabei, den Grad des Product Ownership bildlich darzustellen. So können die unterschiedlichen Level an Ownership rollenübergreifend sichtbar gemacht und ausgehandelt werden. Dabei unterhält man sich über den aktuellen Ist-Zustand der einzelnen Rollen und gleicht diesen mit dem gewünschten Zielzustand ab.
Wichtig ist, dass sich alle Beteiligten möglichst realistisch einordnen und einander über die vorherrschenden Unterschiede austauschen. Wer steht aktuell wo auf der Skala und wie kann eine Veränderung gestaltet werden, um den Zielzustand näherzukommen? Erst durch das transparent machen der einzelnen Zustände wird der Dialog gefördert und ein Aushandlungsprozess kann in die Wege geleitet werden.
POEM unterstützt dabei zusätzlich, möglichen Veränderungsbedarf zu erkennen, sowie Schulungsinhalte gezielt anbieten zu können.
Daher der Appell: Wie der größtmögliche Mehrwert für das Produkt geschaffen werden kann, variiert in der Regel stark und ist dabei abhängig von der Organisation, der Kultur und den vorherrschenden Strukturen. Daher ist ein Aushandlungsprozess zwischen den Produktverantwortlichen notwendig. POEM kann hier einen entscheidenden Beitrag leisten.
Summary
Wie anfangs erwähnt, kann man Scrum durchaus als Spiel betrachten – für das dann das Zitat “A good game is easy to learn but hard to master.” gut passt. Es ist eben noch kein Meister vom Himmel gefallen. Aber bekannte Fehler müssen nicht selbst begannen werden, um daraus lernen zu können.
Schaut gerne mal über diese fünf Anti-Pattern und fragt euch, welche davon ihr ggf. selbst aus eurer Organisation kennt. Der erste Schritt für Veränderung beginnt immer mit dem Erkennen, dass es überhaupt einer Veränderung bedarf.
Mayflower unterstützt euch gerne mit Trainings wie Agile Essentials oder Agile Transformationen erfolgreich gestalten.
Keep on gaming.
Hier gibt es weitere Agile Missverständnisse
Schreibe einen Kommentar