Was war?

Am Donnerstag (28. April 2016) fand im Basislager in Leipzig das vierte Treffen der Leipziger Agile Community statt.

Rolf Irion gelang es, Boris Gloger für einen Abriss über Scrum seit 2001 und eine Fishbowl-Diskussion über Scrum 3.0 zu gewinnen. Mit dem folgenden Bericht möchte ich das Erlebte dokumentieren und für mich selbst verarbeiten.

Der Weg von damals bis heute war interessant, ist jedoch bereits recht umfassend dokumentiert. Der komprimierte Abriss aus dem Zentrum der Ereignisse war für mich zur Einordnung ganz hilfreich. Allerdings habe ich den Eindruck, dass vieles davon eher für Historiker wertvoll sein wird.

Scrum 3.0 schafft einiges von dem, was wir täglich praktizieren ab.
Daher spare ich den Teil hier aus.

Für mich war die wesentliche Erkenntnis, dass ich bei Scrum irgendwo bei advanced 2.0 (so etwa 2.8) unterwegs bin. Diese Veranstaltung hat dann Scrum 3.0 in meinem Kopf ausgerollt. Vielen Dank dafür, Boris!

Alexander Krause hat einen Mitschnitt des Abends bis fast zum Ende veröffentlicht.

Wo ist der Punkt? Mangelverwaltung!

In Scrum, wie wir es heute noch vielfach praktizieren und vorfinden gibt es Elemente, die uns helfen sollen, einen Mangel zu verwalten.

Wir machen Dailies, um voneinander zu erfahren, was wir eigentlich so tun. Vielleicht wollen wir auch einen Fortschritt erkennen, um beurteilen zu können, ob wir zum gesetzten Termin (Sprintende) fertig werden. Wir pflegen ein Backlog, weil wir uns nicht um alles gleichzeitig kümmern können und wollen (Fokus!). Wir verfeinern dieses Backlog, indem wir uns mit dem beschäftigen, was da in den nächsten Sprints auf uns zukommt. Wir führen Burndown-Charts, um uns zu orientieren, wo wir stehen. Wir brauchen dafür eine Größe, die wir auf der Skala abtragen – also schätzen wir diese Größe.
Und zuletzt wollen wir darüber sprechen, wie wir Hindernisse wahrgenommen haben und sie zukünftig besser vermeiden oder überwinden (Retro).

Wenn wir den Blick heben und einen Schritt zurücktreten, dann müssen wir uns eingestehen: Das ist alles Verwaltung von Mangel.

Wenn wir immer nur genau das tun, was wir tun wollen und wozu wir uns deshalb verpflichtet haben (Commitment!), dann sind wir konzentriert auf das, was wirklich zählt. Wir tun dann immer genau das, was am wichtigsten ist.

War das nicht schon so oft der Satz, den wir selbst gesagt oder oft gehört haben?

Dann kommt aber zwangsläufig die Frage auf, wie wir dieses „Wichtigste“ identifizieren und was wir mit allem anderen machen.
Die Versuchung, ein (umfangreiches) Backlog aufzubauen ist nun zum Greifen nahe.

Und jetzt kommt die „Magic“

Das Geheimnis liegt in der Auslastung. Es ist wesentlich zu erkennen, dass es um optimale Auslastung, nicht maximale Auslastung geht. Viele haben diesen Punkt bereits beim Sustainable Pace übersehen.

Die Optimale Auslastung erkenne ich, auch ohne die Formel wiedergeben zu können, an der Größe der Warteschlange.
Sie sollte zwischen 1 und 3 liegen. Kommt uns das nicht bekannt vor? Stichwort: WiP-Level. 😉

Also braucht es einen PO, der strengstens darauf achtet, dass diese Warteschlange innerhalb der „1 bis 3-Grenze“ bleibt.
Das „No“ des PO ist also das neue „Yes, we can!“.

Und wie von Geisterhand wird dann das Team immer ausgelastet und fokussiert sein.
Es wird fokussiert sein, weil es idealerweise gar keine weiteren Stories gibt, mit denen man sich verzetteln kann.
Sie werden automatisch alle an der einen, wichtigsten Story arbeiten, anstatt sich in Nebenthemen zu vergraben.
Dadurch gibt es auch den dauernden Bedarf sich zu synchronisieren, damit man weiß, was gerade getan wird und was unmittelbar als nächstes gebraucht wird, um die Story fertig zustellen. Höchster Grad bei der Umsetzung: „Mob-Programming“.
Dailies? Wofür dann noch?

Dieses Vorgehen führt natürlich dazu, dass ein Sprint nicht mehr n Wochen lang sein wird.
Er wird eher wenige Tage oder sogar nur einen Tag lang sein – vielleicht noch kürzer.

Und das Review (bspw. zu Beginn des Folgetages) wird dann sofort zu Tage fördern, ob wir mit der Story gelandet sind oder es Nachbesserungsbedarf gibt.
Das Erlebte ist noch frisch, das Team ist noch im Thema.
Kein Kontext-Switch, keine Backlogs, reine „Fokuszeit“!

Und Retros? Die sind doch für die Team-Entwicklung so wichtig!
Ja. Und sie sind kurz.
Eine Frage – eine Antwort: „Was wird uns die nächste Iteration möglicher machen“?
Schon wieder kein Backlog. Schon wieder volle Konzentration.

Ja, aber …

Unser Vertrag enthält aber […].

Egal, ob intern oder extern. Auftragsentwicklung oder Kerngeschäft.
Verträge sind nicht dazu da, auf ewig oder ihrer selbst willen zu bestehen. Verträge sollen das dokumentieren und die Bedingungen schaffen, um das Eigentliche, das Wesentliche zu erreichen.
Verträge sind nur ein Hilfsmittel!

Ein Kaufvertrag ist dazu da, die Verpflichtung zur Eigentumsübertragung zu schaffen.
Ein Werkvertrag ist dazu da, ein spezifiziertes Werk („Feature“?) zu liefern.
Egal, ob ich dieses „Feature“ bereits habe oder noch erstellen muss, meine Verpflichtung als Auftragnehmer ist es, das Feature zu liefern.
Wieviel Herstellungskosten ich dabei habe, wie lange es dauert, wo die Entwickler sitzen usw. interessiert den Kunden eher nicht so. Er will eigentlich nur wissen, was es ihn kostet und wann er es bekommt.

Wie wird ein Geschäft daraus?

Der Kunde braucht ein „Feature“ und dieses Feature stellt für ihn einen (angenommenen!) Wert dar.

Der Erzeuger wird sich auf die Lieferung einlassen, wenn das vom Kunden ausgelobte Entgelt für ihn passt.
Entweder, weil er dringend Liquidität braucht („Startup mode“), weil er Erfahrung hat, was es ihn kosten wird, dieses Feature zu erstellen und zu liefern („Factory Mode“) oder weil es ihn schlicht interessiert und er eine bestimmte Erfahrung machen möchte oder den Kunden gewinnen („Intrinsified mode“).

Wie kommt man nun zueinander?
Das ausgelobte Entgelt hat eine Höhe, die unterhalb des vorgestellten Werts für den Kunden und oberhalb der Kosten für den Erzeuger liegt, denn beide Seiten wollen Gewinn machen.
Herrscht auf einer Seite ein Ungleichgewicht, kommt die Einigung (Kern eines jeden Vertrages) nicht zustande.

Wenn doch, hat mindestens eine Seite einen Fehler gemacht. Mit all dem, was damit verbunden ist …

Fazit

Scrum 3.0 funktioniert. Es bedarf „nur“ etlicher Umbauarbeit im Bestehenden, um es zum Fliegen zu bekommen.

Der wichtigste Umbau findet in unserem Kopf statt!
Erst wenn wir all das, was uns umgibt schonungslos kritisch betrachten und würdigen, dann werden wir erkennen, was wir zukünftig brauchen und was wir ändern müssen.

Aber das ist ja kein Problem für „uns“.
Wir stehen für die agilen Werte. Auch Mut und Offenheit. 😉

Viel schwerer wird es, alle um uns herum zu überzeugen, Vertrautes und Liebgewonnenes aufzugeben und zu neuen Ufern aufzubrechen.

Und das ist für mich die wertvollste Erkenntnis aus diesem Abend: es wird noch für Jahre zu tun geben …

Danke Boris, danke Rolf, danke Peter und Dank an alle, die dabei waren!