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.
***
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"