SAFe vs. Scrum: And the winner is ….

Business Men in suits boxing

SAFe vs. Scrum: And the winner is ….

Machen wir jetzt Scrum oder SAFe? 

Wir sind ein Scrum Team, also eindeutig Scrum.

Dogmatisch, weil es der Scrum Guide so sagt, fängt jeder Sprint mit einem Sprint Planning an.

Sprint Planning? – so ein Nonsens

Ein Sprint Planning, das den PI Plan (maßgeblich) verändert, ist ein No-Go!

SAFe, ein Framework für Projekte an denen mehrere Teams an einer sogenannten Solution arbeiten, sieht am Anfang eines jeden Program Increments (PI) ein PI Planning vor. Ein großes Event, bei dem alle Teams samt RTEs, Product Manager, Architects und auch alle Stakeholder und der eine oder andere Manager zusammenkommen, um das nächste Program Increment zu planen. Wenn nicht gerade eine Pandemie ihr Unwesen treibt, ist das PI ein Big Room Planning, das von so manch Abstimmungsrunde in kleinerem Rahmen flankiert wird. Zumeist dauert es zwei ganze Tage.

Folgt man der vorgegebenen Agenda, dann findet am Ende des ersten Tages – nachdem die Teams schon viel Energie in die Erstellung des Plans der Sprints des anstehenden PIs investiert haben – ein Management Review statt. In diesem Meeting versucht das Management Probleme aus dem Weg zu räumen, die von den Teams im Rahmen des Plannings identifiziert wurden. Gegebenenfalls wird der Scope ein wenig geändert und / oder es werden Beschlüsse bezüglich erforderlicher Ressourcen gefällt. Mitunter werden Kraft der Entscheidungsbefugnis der anwesenden Manager:innen hinderliche Dependencies aufgelöst.

pi-planning, www.scaledagileframework.com

Mehr oder minder holt man sich während des PI Plannings die Unterstützung und das GO des Managements für den Plan des anstehenden PIs ein.

Grundvoraussetzungen für ein (PI) Planning

Ein Planning ist ein Matching zwischen Angebot und Nachfrage. Der Bedarf, spezifiziert über die User Stories, muss mit den vorhandenen Kapazitäten abgeglichen werden. Um ein (PI) Planning sinnvoll durchführen zu können, bedarf es

  • der Kenntnis der (zumindest ungefähr) verfügbaren Kapazitäten und
  • der Kenntnis darüber, wie viel Aufwand (ungefähr) in der Umsetzung der einzelnen User Stories steckt.

Um den Aufwand schätzen zu können, der in etwa in der Umsetzung einer Anforderung steckt, bedarf es oftmals – je nach Größe der Anforderung – eines sogenannten Task Breakdown. Wenn die Umsetzungsschritte grob bekannt sind, kann man über den Daumen hinweg eine Aufwandsschätzung durchführen.

Die Aufwandsschätzungen für alle Anforderungen (User Stories, Tasks, etc.), die im Rahmen eines PIs umgesetzt werden sollen, sollten im Rahmen der Refinements durchgeführt werden. Siehe dazu auch Continuous Exploration.

Story Points??? – oftmals ein Schmarrn

Aus welcher Notwendigkeit heraus, so fragt sich der Autor dieses Blogs, ist die Erfindung einer kryptischen Fremdwährung zur Schätzung des Aufwands von Anforderungen entstanden?

So ein Nonsens!

“Mit Story Points lässt sich auch die Komplexität abbilden”, erzählte mir erst kürzlich ein junger Softwareentwickler. “Und glaubst Du vor 20 Jahren hat es keine komplexen Aufgaben gegeben, die es umzusetzen galt?” war meine Antwort.

In aller Kürze: Alle Softwareentwickler, die ich danach gefragt hatte, wie sie denn zu einer Aufwandsschätzung kämen, haben einhellig bestätigt, dass sie zuerst einen groben Task Breakdown (oftmals nur im Kopf durchgeführt) machen, grob abschätzen wie lange sie für die einzelnen Schritte brauchen und dann – entsprechend der Komplexität – einen Puffer draufschlagen. Je größer die Komplexität / die Unwägbarkeiten, desto größer der Puffer.

Ein Plan ist ein Plan ist ein Plan.

Soll heißen, dass die Unwägbarkeiten des Lebens immer wieder gegen diesen Plan schießen. Da wird der eine oder andere Entwickler krank, weil draußen oftmals ein Sauwetter herrscht. Die eine oder andere Aufwandsschätzung ist daneben gegangen. Man hat sich grob verschätzt. Und dann gibt es da noch Menschen, die unvermittelt nicht nur das Projekt sondern gleich das Unternehmen verlassen. All diese Unwägbarkeiten müssen agile gehandhabt werden. Es muss darauf reagiert werden, weil sie den Plan in Gefahr bringen.

Eine gängige Methode auf solche “Hickups” zu reagieren könnte sein, die eine oder andere User Story von einem Team in ein anderes Team zu verschieben. Beim “anderen” Team eine weniger wichtige Anforderung herausnehmen und die wirklich wichtige User Story des “Hickup-Teams” dort umsetzen lassen. Klar, das funktioniert oftmals nur unter “Bauchschmerzen”, weil nicht jedes Team in jedem Themenbereich die gleiche Expertise hat. Oftmals ist es dann sinnvoll die ursprüngliche Schätzung noch einmal um einen dicken Puffer zu vergrößern; aus 3 PDs mach 5 PDs.

Wie aber soll das erfolgen, wenn man so gar keine Ahnung darüber hat, was denn die 12 Story Points, die das eine Team geschätzt hat, tatsächlich bedeuten?

Fakt ist, dass Story Points zumeist eine teamspezifische Wertigkeit haben. Der Wert des Story Points des einen Teams entspricht selten der Wertigkeit des Story Points eines anderen Teams.

12 Story Points des einen Teams mögen 5 Story Points eines zweiten Teams und 18 Story Points eines dritten Teams gleichzusetzen sein. Wie soll hier das Product Management, in Zusammenarbeit mit den Product Ownern der einzelnen Teams, ein Shifting von Anforderungen vornehmen können?

Zeit ist eine gute Metrik

Ab dem Moment, ab dem wir in den Kindergarten müssen (weil Mama und / oder Papa zur Arbeit müssen), hat uns die Zeit am Wickel.

transparente Uhr im Vordergrund eines Terminkalenders

Die Uhr können wir zu diesem Zeitpunkt wahrscheinlich noch nicht lesen, doch stinkt es uns gewaltig, dass wir nun nicht mehr ausschlafen können. Früh am Morgen werden wir aus dem Schlaf gerissen. Haben wir den Kindergarten (halbwegs) überstanden, geht es fast übergangslos zur Schule. Über viele, viele, viele Jahre begleitet uns ein Stundenplan. Eine Schulstunde dauert 45 Minuten. Ist der Schultag kurz, endet die Quälerei um 12:00 Uhr oder 13:00 Uhr; ist er lang, erst am (späten) Nachmittag.

Gegen 18:00 Uhr treffen wir uns mit Freunden. Das haben wir so verabredet.

Lange Rede kurzer Sinn: Von Kindesbeinen an leben wir mit der Zeit. Wir lernen die Uhr zu lesen, erfahren wie langsam oder schnell die Zeit oftmals verrinnen kann. Jeder bekommt mit der Zeit ein Gefühl dafür, respektive weiß irgendwann wie lange ½ Tag, ein ganzer Tag, 4 Tage oder zwei Wochen dauern.

Klar, wir können uns immer noch verschätzen, aber der eine Entwickler zum anderen Entwickler sagt …

“Wird in etwa drei Tage in Anspruch nehmen. Habe aber mal so 30 % Puffer eingeplant”,

… dann erzeugt diese Information für den anderen Entwickler eine in der Regel viel klarere Vorstellung von den ungefähren Aufwänden, als wenn etwas von 37 Story Points gefaselt wird.

In SAFe, “da wo” mehrere Teams an einer Solution arbeiten, macht die Freiheit von Scrum mit Story Points als Schätzmetrik arbeiten zu können, das Leben nur ein gutes Stück schwerer.

Conclusio

Das Scrum Sprint Planning macht nicht mehr wirklich Sinn, wenn ein Scrum Team als Teil eines Agile Release Trains an einer Solution arbeitet. Die Freiheit als Schätzmetrik Zeit, Story Points, T-Shirt-Größen oder gar Hunderassen wählen zu können, hat dort seine Grenzen, wo ein Miteinander aller Teams – zum Wohle einer zu entwickelnden Solution ein großes, funktionsfähiges, Ganzes ergeben muss.

Nachdem SAFe auch eine sogenannte Cadence – siehe SAFe Prinzip #7 – als sinnvoll und notwendig erachtet, sollten einzelne Scrum Teams eines Agile Release Trains auch nicht selbst über die Sprint-Länge entscheiden dürfen.

Sofern wir bei der sinnvollen Zusammenführung von SAFe und Scrum unterstützen dürfen

Von 
Allgemein,Methode
Keine Kommentare

Share This Story, Choose Your Platform!

Über den Autor:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.

*

Menü