Release Planung: so funktioniert es!

Von Sebastian Schneider // 06.04.2018 // 1 Kommentare

In diesem Artikel zeige ich dir, wie du die Release Planung in Scrum behandeln kann. Interessanter Weise denken nach wie vor viele Menschen, dass die Release Planung in Scrum zwingend notwendig ist. Das ist sie nicht, lass uns gleich mal schauen, was uns die Release Planung für Vorteile bringen kann.

Was ist ein Release?

Als ein Release verstehen wir eine veröffentlichte Version einer Software. Wenn wir also ein fertiges, veröffentlichtes Inkrement unseres Produktes (kann Software sein, muss es aber nicht) erzeugt haben, dann bezeichnen wir diese als Release. Diese Version ist dann in der Regel immer für einen Kunden - wo auch immer der angesiedelt ist - verfügbar und wird auch genutzt.

Release Planung in Scrum

Release Planung in Scrum

Im Folgenden gehe ich nur auf die Möglichkeiten der Release Planung in Scrum ein. Dabei werden wir zum einen ein Blick darauf werfen, wann wir diese Release Planung überhaupt brauchen. Zum anderen schauen wir uns genau an, welche Möglichkeiten Sie in Scrum haben, um eine Release Planung durchzuführen.

Scrum braucht keine Releases

Grundsätzlich braucht Scrum keine Releases. Scrum hat den Anspruch in jedem Sprint etwas zu entwickeln, wobei der Nutzen die Kosten übersteigt. Wenn das so ist, können wir im Sprint Review überprüfen, in wie weit das Ergebnis dem Kunden zusagt, überlegen ob wir Anpassungen vornehmen wollen und dann in den nächsten Sprint gehen.

Das ist zum einen nicht immer realistisch, gerade wenn du deine Integrations- und Deployment-Strategien (noch) nicht soweit entwickelt hast, dass du jeder Zeit immer liefern kannst. Zum anderen musst du ja nicht zwangsläufig Software entwickeln, sondern kannst Scrum in der Hardware oder anderen Bereichen benutzen. Es gibt also durchaus die Situationen, in denen Sie sich mit einer Release Planung in Scrum auseinander zusetzen.

Wenn deine Organisation reif ist, dann kannst du jederzeit liefern und brauchst praktisch keine Releases mehr bzw. dann ist jedes Inkrement auch gleich ein neues Release.

Eine Vision, die es braucht

Schaffe die organisatorische Fähigkeit, auf Veränderungen zu reagieren, indem du jederzeit in der Lage bist, ohne zusätzliche Kosten zu liefern oder die Richtung zu ändern.

In vielen Organisationen finden wir den folgenden Zusammenhang zwischen Inkrementen und Releases.

Inkrement und Release

Lies dich gerne in meinem Artikel agil und Lean übertrieben einfach ein und behalte im Hinterkopf, je ungewisser die Rahmenbedingungen sind bei dir sind, desto mehr sind regelmäßige und qualitative Releases wichtig. Nur so kannst du das Risiko verringern, das auf einem unbeständigen Markt herrscht.

Hohe Anforderungen, wenn der Sprint das Release ist

Wer pro Sprint immer der Mehrwert an den Kunden liefern kann, ist gut dran. Viele Unternehmen und Teams befinden sich noch lange nicht auf dieser Reife. Deswegen kann man den Gedanken der Release Planung (mindestens als Übergang) weiterführen.

Bedenke, dass du praktisch in einem Sprint alles das machen musst, um wirklich eine fertige, getestete und releaste Version zu erzeugen. Ja, das ist eigentlich nichts neues in Scrum, aber viele Teams sind da schlicht noch nicht. Das muss nicht schlimm sein, aber das ist grundlegend das Ziel von Scrum.

Wann du doch eine Release Planung in Scrum benötigst

Nicht jeder Kunden möchte tatsächlich immer jeden Sprint ein neues Release haben. Dann ist es ebenso am Product Owner zu entscheiden, wie mit dem Kunden gemeinsam eine Strategie für die auszuliefernden Releases entstehen kann.

Das entbindet dich im Team natürlich noch lange nicht davon, dass du ein fertiges Produktinkrement benötigst. Denn damit bist du im Team auch in der Lage dich permanent weiterzuentwickeln und den Produktfortschritt zu sehen und zu erkennen.

In den wenigsten Fällen denke ich, dass du die Release Planung in Scrum komplett ignorieren solltest. Product Owner und Kunde sollten davon ein klares Bild bekommen.

Release nach Zeit

Oft hast du als Product Owner ein zeitliches Ziel. Das ist meistens dann der Fall, wenn du Termine hast, die nicht verschiebbar sind. So möchte dein Kunde auf Messen etwas zeigen und dafür braucht er natürlich ein Release des Produktes zu einem bestimmten Zeitpunkt - sonst ist die Messe ja vorbei. In den meisten (mir bekannten) Fällen geht es Kunden und Menschen genau um diesen zeitlichen Faktor.

Du hast ein bereits abgeschätztes Backlog welches D.E.E.P. ist? Perfekt, dann hast du natürlich auch die Schätzungen für die Product Backlog Einträge bereits vorliegen. Solltest du das noch nicht haben, erreichst du mit agilem Schätzen genau diese benötigte Schätzungen.

Jetzt musst du lediglich noch wissen, was die Entwickler pro Sprint schaffen und du hast alles was du brauchst. Das kannst du immer mit dem folgenden Muster ganz einfach erledigen:

  1. 1
    Als Product Owner kannst du dir nun eine recht einfache, auf Empirie basierende, Vorhersage machen. Dazu brauchst du nur die geschätzten Einträge und die Velocity.
  2. 2
    Du schaust dir gemeinsam mit dem Kunden die Einträge von oben nach unten an. Die Reihenfolge sagt auch etwas über die Wahrscheinlichkeit aus, wann diese Elemente kommen.
  3. 3
    Wenn du mit dem Kunden von oben nach unten durchgehst und dir die Wichtigkeit noch mal bestätigen lässt, dann addierst du einfach die Schätzungen bis zum Wert der Velocity pro Sprint

Ein Beispiel dazu? Du hast in deinem Product Backlog Item oben die Items mit den Schätzungen 3,5,8,8,13,2,1,5,5,13,1 und dein Team hat eine Velocity von 23. Auf Basis der Sprintlänge und dem Datum, an dem der Kunde ein "Messe-Release" benötigt ergibt sich die Zeit für die Arbeit. Im folgenden Beispiel sind das drei Sprints.

Release Planung in Scrum (zeitlich)

Natürlich ist das nicht immer so einfach, denn auch die Velocity von 23 ist nicht immer stabil. Aber auch das ist Empirie - wenn du nichts besseres hast, dann ist das ein guter Indikator. Jetzt kannst du eine erste Schätzung vornehmen von Einträgen aus dem Product Backlog, die wahrscheinlich bis zu diesem Zeitpunkt "Messe-Release" fertig sein werden.

Release nach Umfang

Jetzt wirst du dir das Release nach Umfang schon denken können, nicht wahr? Hier ist es einfach nur anders herum. Es ist klar, dass zum Beispiel alles aus dem obigen Backlog geliefert werden muss. Das bedeutet dann im Umkehrschluss, dass du die Schätzungen addierst und dann durch deine Velocity dividierst und dann kommst du zu deiner Zeit in Form von Sprints.

Vorsicht

Wenn du das im obigen Beispiel einmal nachrechnest wirst du natürlich merken, dass die Rechnung rein mathematisch ist. Berücksichtige dabei immer die Situationen, bei denen du noch 5 Punkte in einem Sprint über hättest, aber nur das 13 Punkte Product Backlog Item ziehen kannst. Das "verwässert" dann natürlich etwas deine Rechnung.

Empirische Beobachtungen zur Release Planung in Scrum

Wenn du meinen Blog schon länger verfolgst oder mich sogar kennst, dann weißt du, das ich sehr gerne Muster in Teams und Organisationen beobachte. Auch bei der Release Planung in Scrum ist das nicht anders. Die folgenden Beobachtung kannst du dir einmal in Ruhe ansehen, diese müssen natürlich nicht bei dir auftreten, vielleicht tun sie aber aber.

Team ist kein wirkliches Team

Manchmal kann es vorkommen, dass eine Release Planung in Scrum nur deshalb benutzt wird, weil das Team kein Team ist. Es ist eine Ansammlung von Experten, die lediglich eine Pseudo-Agilität leben. Dadurch arbeiten die wenigsten in einem Sprint wirklich zusammen, sondern bringen in unterschiedlichen Zeitabständen ihre Ergebnisse in das Team zurück. Dadurch wird die Laufzeit der Aufgaben sofort länger, sie schaffen nicht mehr alls notwendige in einem Sprint und versuchen sich dann über Releases zu synchronisieren.

Aufgaben werden nicht fertig

Manche Teams legen zum Beispiel keinen großen Wert auf das Refinement. Sie haben dadurch Dinge in den Sprints, die zu groß sind und auch nicht wirklich in dieser Granularität da hinein gehören. Wenn dann noch dazu kommt, dass die Umgebung im Grunde gar nicht komplex, sondern einfach oder kompliziert ist, dann finde ich die Situation vor, dass es scheinbar egal ist, ob im Sprint Aufgaben fertig werden oder nicht. Auch hier wird dann das Konstrukt der Release Planung verwenden, um sich zu synchronisieren.

Falscher Teamschnitt

Wenn Teams durch einen falschen Teamschnitt die Release Planung in Scrum benötigen, um unterschiedliche Komponenten oder Module gemeinsam zu erstellen, dann ist das im Grunde auch keine Notwendigkeit einer Release Planung, sondern viel mehr der dringende Bedarf in den richtigen Teamschnitt zu schauen.

Fazit

Die Release Planung in Scrum ist ein gutes Konstrukt, wenn es darum geht dem Kunden aufzuzeigen, was in entweder für eine zeitliche oder inhaltliche Planung angedacht ist. Vorsicht walten lassen sollte man immer dann, wenn versucht wird Disfunktionen mit der Release Planung auszugleichen.


Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>