Scrum Commitments dürfen nicht erfüllt werden

Ziele sind NICHT zum Erreichen da, schreibt Conny Dethloff. Und Elon Musk will bis 2025 Menschen auf den Mars bringen. Beides gefällt mir.

Ob und wann 1.000.000 Menschen auf dem Mars leben werden, ist nicht so wichtig. Es geht darum, welchen Sog diese Vision ausübt. Wenn wir uns darauf einlassen, kann Kohärenz entstehen. Kräfte werden gebündelt. Das macht an sich schon Freude. Und was man am Ende bzw. auf dem Weg erreicht, ist Fortschritt; der macht auch Freude. (Dass es auch andere Visionen gibt, die verfolgenswert sind, ist klar. Nicht entweder-oder, sondern sowohl-als-auch. Auf den Mars und Schluss mit Plastikmüll usw.)

Wer alles haarklein so erfüllt sehen will, wie Elon Musk es beschreibt, der engt sich selbst ein.

Und ich übertrage das jetzt mal auf die Softwareentwicklung bzw. noch konkreter auf das beliebte Vorgehensmodell Scrum. Da bedeutet es:

Es geht eben nicht darum, dass ein Sprint Commitment erfüllt wird. Die Punktlandung zum Sprintende mit allen User Stories im Sprint Backlog durch zu sein (done), ist nicht das, worum es geht.

Ansonsten „werden alle [Entwickler] ihre ganze Energie darin legen, [das Commitment zu erfüllen] und dafür unter Umständen auch [Qualitäten] herunter schrauben, unabhängig davon, ob diese dann noch einen Mehrwert darstellen oder nicht.“

Ich mache es mal ganz plakativ und extrem: Das Commitment für den nächsten Sprint sollten alle (!) User Stories im Backlog sein.

Sehr wahrscheinlich ist das ein nicht erreichbares Ziel. Aber das ist egal, weil letztlich nie klar ist, ob ein Commitment wirklich, wirklich erfüllt werden kann. Das ist immer nur Wunschdenken. Das ist immer nur eine Wette – die der Erfahrung nach meistens verloren wird; zumindest wenn man genau hinschaut.

Schritt für Schritt auf dem Weg zum Ziel

Aber nehmen wir das Commitment für einen Moment mal hin. Das Ziel ist nicht erreichbar: Was nun? Man muss sich auf den Weg machen. Man muss einen Schritt tun. Und dann macht man noch einen Schritt. Schritt für Schritt geht man voran. So gut man eben kann. Zügig, aber sorgfältig.

Irgendwann ist man entweder fertig – oder die Zeit ist um.

Was auch sonst?

So sind Sie wahrscheinlich in der Schule bei Klausuren auch vorgegangen. Der Lehrer hat für die angesetzten 90 Minuten 5 Aufgaben vorgelegt. Sie haben die Augen aufgerissen und nicht gewusst, ob Sie das alles in der Zeit schaffen werden. Dann haben Sie mit einer Aufgabe einfach begonnen. Vielleicht war es die scheinbar leichteste, vielleicht umgekehrt die scheinbar schwierigste. Egal, ob Sie zuerst priorisiert haben oder nicht, Sie haben überhaupt nur mit genau einer Aufgabe beginnen können. Danach die nächste, danach die nächste usw.

Nicht anders, so meine ich, sollte es bei der Softwareentwicklung sein. Wer in einer Planungssitzung steckt, darf sich gern einen tollen Plan machen und ein Commitment abgeben. Nur er sollte nicht darauf schielen, den Plan zu erfüllen. Der Plan dient lediglich einer Ausrichtung auf einen Weg. Er bündelt Kräfte, stellt Kohärenz her. Und dann… dann macht man nur den ersten Schritt. That’s it.

Nach dem ersten Schritt kommt… eine Orientierung mit der Frage „Wo bin ich? Was ist jetzt angesagt?“ und dann der nächste Schritt, der zur aktuellen Lage passt. Der mag dem Plan entnommen sein oder er ist ad hoc auf die veränderte Situation angepasst.

Eigentlich gibt es immer nur erste Schritte. Nach dem Schritt ist vor dem Schritt. Keiner unterscheidet sich vom anderen. Denn alle sind gleich in dem, dass sie im jeweiligen Moment die sind, die gemacht werden sollten, um möglichst viel Wert herzustellen.

***

Der Zauberer von OzDas Ziel tritt in den Hintergrund. Der Blick richtet sich nur auf den durch das Ziel ausgerollten Weg. Man folgt der „gelben Ziegelsteinstraße“, ohne zu wissen, wann (und ob) man die smaragdene Stadt erreichen wird.

Das mag paradox klingen. Aber – wie auch Dethloff sagt – Paradoxie gehört zum Leben. Wer sich auf die Paradoxie einlässt, ist insofern lebendig. Erfolg wird dann nicht mehr kontrolliert und erzwungen, sondern emergiert.

 

Abbildung aus dem Film „Der Zauberer von Oz

Posted in Deutsche Beiträge and tagged , .

4 Comments

  1. Moin moin Ralf, eine Anmerkung zu deinem Beitrag habe ich. Mir ist es wichtig, zwischen dem Ziel für den Sprint und der Summe der User Stories deutlich zu unterscheiden. Mit dem Ziel wird beschrieben, was für den Kunden oder die Anwender in diesem Sprint Wertvolles erreicht werden soll. Das erfolgt abstrakter als in den User Stories, so dass das Ziel auch erreicht werden kann, obwohl nicht alle Stories umgesetzt wurden. Wir möchten den Kunden/die Anwender zufrieden stellen, und das wird nicht von der Umsetzung der einen oder anderen beliebigen Story abhängen, sondern von den Stories, die besonders wichtig dafür sind und davon, dass alle Beteiligten verstanden haben, was wertvoll ist aus Sicht des Kunden. Für mich passt diese Trennung auch sehr gut zur Aussage deines Beitrags (zumindest wie ich ihn verstanden habe).
    Herzliche Grüße, Uwe

    • Wenn es nicht mehr auf eine bestimmte Zahl von US ankommt, also ein quantitatives Ziel, hört sich das schonmal gut an, finde ich.

      Problematisch bleibt für mich dennoch der Begriff „Ziel“. Denn in ihm kommen zwei Dinge zusammen: eine Ausrichtung und eine Messlatte.

      Ausrichtung sorgt dafür, dass man sich in die eine Richtung und nicht in die andere bewegt. Kompass und Polarstern sind z.B. Mittel zur Ausrichtung.

      Eine Messlatte hingegen hat einen anderen Zweck. Sie dient der Bewertung.

      Messlatten finde ich passend, wo eine Leistung handwerklich erbracht werden kann. Man tut etwas, was man im Wesentlichen schon sehr, sehr häufig getan hat; man reproduziert also. Deshalb weiß man, welche Messlatte bei gegebenen Ressourcen übersprungen werden kann. Man kann ein Ergebnisversprechen abgeben. Am Ende wird mit der Messlatte geprüft, ob es eingehalten wurde.

      Softwareentwicklung hat aus meiner Sicht jedoch ganz wenig Handwerkliches. Deshalb finde ich Messlatten kontraproduktiv. Messlatten führen nämlich schnell dazu, das Überspringen über anderes zu setzen. VW ist dafür das beste traurige Beispiel. Die Messlatte der Grenzwerte wurde durch Manipulation übersprungen – der eigentliche Zweck hinter den Grenzwerten ist aber nicht erreicht worden.

      Anders ist es bei der Ausrichtung. Der fehlt der Leistungsansporn. Da sehe ich weniger Gefahr der Perversion. Mit einer Ausrichtung muss man nicht handwerklich (re)produzieren, sondern kann sich auch forschend und entwickelnd fortbewegen. Alles ist gut, solange man in die vereinbarte Richtung geht. Es geht nur um Fokus.

      Solange also noch von „Sprint Goal“ gesprochen wird, ist für meinen Geschmack zu viel Messlatte dabei. „Goal“ sitzt als Begriff tief in allen drin. „Goals“ wollen erreicht werden. Alles andere ist enttäuschend. Um Enttäuschung zu vermeiden, tut man am Ende alles.

      Dazu kommt der ganze Aufwand, so ein „Goal“ zu formulieren. Denn es macht ja nur Sinn, wenn die Messlatte auch klar verständlich für alle ist. Ich finde das verschwenderisch. Es lenkt vom Fortschritt ab (deviation) und/oder es verzögert durch ganz eigene Verhandlungen den Fortschritt (hesitation).

      Warum nicht einfach vom „Sprint Focus“ sprechen? Der Fokus könnte sein „In diesem Sprint wollen wir die UX verbessern“ oder „In diesem Sprint konzentrieren wir uns auf den Ausbau der Recommendation Engine“ oder „In diesem Sprint ist der Fokus Bug Fixing“ usw. usf.

      Damit würde „lediglich“ ein Verhaltensversprechen gegeben. Das ist viel leichter einzuhalten. Und es lässt sich jeden (!) Tag überprüfen. Man muss nicht bis zum Sprintende warten, um an der Messlatte zu messen. Man kann jeden Tag einfach nur darauf schauen, ob die aktuelle Tätigkeit auf den Fokus ausgerichtet ist. Der Fokus ist „Recommendation Engine“ und ich arbeite an einer US, die das Regelwerk der RE betrifft? Dann diene ich dem Sprint Fokus. Wenn ich hingegen an einer US sitze, die das UI aufhübscht, diene ich nicht dem Fokus. Wenn ich einen Bug in der Fakturierung fixe, diene ich nicht dem Fokus.

      Es entfällt die unselige Frage „Werden wir das Ziel erreichen?“ Die wird ja gegen Sprintende tendenziell intensiver, gar panischer 😉 Bei jeder Art von Ziel.

      Stattdessen kann man sehr schön in jedem Daily Standup fragen: Wie viel deiner Zeit hast du gestern dem Sprint Fokus gewidmet? Das lässt sich jeden Tag sehr präzise beantworten. Und wenn nicht, dann steckt da ein grundsätzliches Problem des Zeitmanagements.

      Bottom line: Es kommt auf die Begriffswahl an. Vielleicht verstehst du unter „Sprint Goal“ das, was ich hier beschrieben habe.
      Doch so lange wir den Begriff „Ziel“ im Munde führen, dürfen wir uns nicht wundern, dass wir immer wieder frustriert werden.

  2. Ich denke commitments sollten schon erfüllt werden, ansonsten sind sie sinnlos und man sollte sie weg lassen.
    Die Frage ist doch eher, ob der Begriff „Ziel“ in diesem Kontext nicht vollkommen fehl am Platz ist. Siehe dazu: https://blog.codecentric.de/2016/09/planlos-agil
    Warum planen wir in Scrum überhaupt, wenn es dann anschließend nicht darauf ankommt ein geplantes Ziel zu erreichen? – Wäre es nicht wesentlich konsequenter die Sprint Planung komplett weg zu lassen und immer nur an dem grade wichtigsten Thema zu arbeiten. Wenn das fertig ist, kann auf Basis des Ergebnisses gemeinsam entschieden werden, welches der nächste sinnvolle Schritt ist.

    • Da bin ich ganz dabei! Weg mit der Planung! Oder zumindest der, die derzeit mainstream ist.

      Was man immer wieder periodisch machen kann, das ist eine Durchsicht zukünftiger Aufgaben. Da würde ich einteilen zwischen „Sollte demnächst umgesetzt werden“ und „der ganze Rest“ 🙂

      Der Rest und das Demnächstige sind aber nur Haufen. Und das Demnächstige ist auch kein Ziel. Da gängt kein Ergebnisversprechen dran. Das Bild mit den Trichtern hier http://zeitgewinn-hamburg.de/mehr-schaffen-mit-der-ivy-lee-methode/ gefällt mir in dem Zusammenhang.

      Vom Haufen des Demnächstigen nimmt man dann jeweils nur das „grade wichtigste Thema“, den Highlander, und setzt es um. Danach zurück zum Haufen des Demnächstigen und wieder von vorne.

      Wenn der Haufen umgesetzt ist, muss man mal wieder einen neuen Haufen aus dem Rest heraussuchen. Oder wenn man will, kann man das auch vorher tun, weil sich z.B. die Situation drastisch verändert hat.

      Kein Sprint muss abgebrochen werden. Keine Messlatte muss zwanghaft übersprungen werden. Periodisch stellt man Fokus her und schreitet in dem voran.

      Was bleibt dann noch von Scrum? Das ist mir egal. Es geht doch nicht um Namen, sondern darum, zur Situation Passendes zu tun, um verschwendungsarm zu arbeiten.

Comments are closed.