On Lean and Agility

Youtube ist und bleibt eine Fundgrube für die bemerkenswertesten Dinge. Das heutige Fundstück ist ein Video eines weitgehend unbekannten E-Learning-Anbieters namens Bean Stalk, der auf wunderbar nachvollziehbare Art und Weise das Konzept des User Story Mappings erklärt.

Was mir beim Ansehen auffällt - ich muss unbedingt wieder meine Visualisierungs-Fähigkeiten trainieren. Vor Corona hätte ich ein ähnliches wachsendes Gemälde wie das im Video auch hinbekommen, nach drei Jahren Miro-Nutzung ist dieses Talent aber etwas eingerostet.

Bild: Wikimedia Commons / Rainer Flassig - CC BY-SA 2.0

Stellen wir uns folgende Situation vor: ein Product Owner (oder ein Mensch in vergleichbarer Rolle) kommt zu seinem Team. Er stellt ihm die neueste User Story vor, die auch von allen sofort verstanden wird. Als es dazu kommt eine Aufwandsschätzung abzugeben sind die Entwickler aber ratlos - die Umsetzung müsste in einer Technologie oder in einem System erfolgen mit denen sie noch nie gearbeitet haben. Ohne diese Erfahrungswerte können sie den Aufwand nur raten.

Im klassischen Projektmanagement würde man versuchen dieses Problem zu lösen inden man einem team-externen Experten die Aufwandsschätzung überlässt, z.B. einem Architekten, Lead Developer oder Business Analysten. In einem agilen Vorgehen wäre das aber keine gute Lösung, schliesslich soll die Aufwandsschätzung hier nach Möglichkeit von den Mitgliedern des umsetzenden Teams selbst kommen.¹ Wie versetzt man die also in die Lage das zu tun?

Eine Lösung dafür kommt aus dem Extreme Programming, dem Framework dem wir auch die User Story verdanken, und nennt sich Spike Solution (oft abgekürzt zu Spike). Sie besteht in Abgrenzung zur Perfect Solution oder Possible Solution, bei denen zumindest grundlegend klar ist wie gross der Aufwand ist und die direkt neue Funtionen erzeugen sollen.² Die Spike Solution soll das nicht, ihr Ziel ist es lediglich, die Entwickler mit der Technik vertraut zu machen.

But what if you haven't done anything like this story before? What if it's the beginning of the project and you haven't done anything at all? The answer is simple: do some experimenting. We call such an experiment a "Spike Solution" to remind us that the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out. You need to know how long it will take you to do something.

Ron Jeffries and Chet Hendrickson, Extreme Programming Installed, S.55

Was Ron Jeffries und Chet Hendrickson, zwei der drei Erfinder von Extreme Programming, hier sagen streicht die entscheidenden Punkte heraus: wenn die Erfahrungswerte für eine Aufwandsschätzung zu gering sind können diese dadurch hergestellt werden, dass so lange Experimente mit der Anwendung durchgeführt werden bis die Vertrautheit gross genug für eine Schätzung ist. Um möglichst schnell an diesen Punkt zu kommen sollten diese Experimente, bzw. Spikes, möglichst klein sein.

In dem Buch aus dem sein Zitat stammt nennen die beiden auch Beispiele dafür. Eines besteht darin einem System einfache Rechenoperationen hinzuzufügen, ein anderes in der Änderung der Formatierung einer Zahl. Derartige Experimente sind in wkurzer Zeit abschliessbar, geben dem der sie durchführt aber trotzdem ein Gefühl davon wie aufwändig die Arbeit in diesem System ist. Falls das noch nicht reicht kann ein zweites oder drittes folgen, bis ein Grundverständnis da ist.

Wichtig ist dabei, dass der im Rahmen der Spikes erzeugte Code im Anschluss nicht weiterverwendet wird und stattdessen gelöscht werden kann. Nur so kann sichergestellt werden, dass nicht versehentlich etwas beschädigt wird und dass das Experiment dort stattfinden kann wo die Unklarheit am grössten ist. Den bereits erzeugten Code irgendwie weiterverwenden zu wollen ist zwar ein verständlicher Reflex, allerdings ist davon aus den genannten Gründen abzuraten.

Soviel zu den Warum und Wie einer Spike Solution, es bleibt aber noch eine Frage - warum eigentlich der Name? Er leitet sich ab von einem einfachen Stech-Werkzeug mit dem Löcher gebohrt werden können. In Analogie dazu ist es durch den Spike möglich in die "Black Box" des unbekannten Systems Löcher zu bohren, wodurch Licht in das Innere fällt, das dadurch sichtbar und begreifbar wird.

Bild: Pixabay / Larisa K. - Lizenz

Seit November 2020 muss die agile Community mit einer Begriffsverwirrung leben. Das in diesem Monat veröffentlichte Update des Scrum Guide führte einen neuen, bis dahin kaum bekannten Begriff ein: das Produktziel (Product Goal). Verwirrend ist das deshalb, weil es (ausserhalb von Scrum) einen sehr ähnlichen und bereits etablierten Begriff gibt, die Produktvision (Product Vision). Ist das jetzt das Gleiche? Gibt es Unterschiede? Wenn ja welche? Schauen wir uns die Begriffe an.

Die Ursprünge der Produktvision verlieren sich irgendwo im Dunkel der Geschichte, bereits in rückwirkend digitalisierten Fachartikeln findet man sie aber wieder, z.B. 1984 im Harvard Business Review als "Vision for the Product". Konkretisiert wurde sie später in verschiedenen Formen, unter anderem 1991 von Geoffrey Moore in Crossing the Chasm (als "Product Elevator Pitch") und 1995 von Michael McGrath in Product Strategy for High Technology Companies (als "Strategic Vision").

Die Gemeinsamkeit dieser Ansätze ist, dass sie die Produktvision im Sinn eines Leitsterns, Fernziels oder Idealtypus definieren, also als etwas was in der Realität kaum zu erreichen ist. Der damit verbundene Zweck ist, dass durch eine Ausrichtung an dieser Vision kontinuierlich in eine gleichbleibende Richtung gearbeitet werden kann, was sowohl durch Abarbeiten eines langfristigen Plans möglich ist (im Wasserfall-Vorgehen) als auch durch kurzfristiges Optimieren der jeweils nächsten Schritte in Richtung des Langfristziels (agiles Vorgehen).

Im Unterschied dazu kann das im Scrum Guide beschriebene Produktziel explizit erreicht werden. Der in diesem Zusammenhang entscheidende Absatz lautet "The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.", wodurch klar wird, dass eine Beendigung der Arbeit am Produktziel möglich ist. Eine Zwangsläufigkeit dass das in absehbarer Zeit geschieht ist das zwar nicht (theoretisch sind Produktziele möglich die erst in Jahrzehnten erreichbar sein werden) grundsätzliche Abschliessbarkeit sollte aber gegeben sein.

Der Differenzierung sollte damit klar sein: die Produktvision ist der führende, aber letztendlich unerreichbare Leitstern, das Produktziel der ferne aber (theoretisch) erreichbare Abschluss aller Arbeiten die für ein Produkt nötig sein werden.

Absehbar ist aber auch: So hilfreich diese begriffliche Unterscheidung für das Verständnis auch sein mag, in der Realität dürfte sie nur selten vorgenommen werden. Es werden wohl nur die methodenbegeisterten Teams sein die in ihrem Backlog eine Differenzierung zwischen Produktvision und Produktziel vornehmen, die meisten werden nur einen der Begriffe verwenden oder sie synonym gebrauchen - was angesichts der grossen Schnittmengen auch unproblematisch sein sollte. Wichtig ist nur, die Unterscheidung zu kennen, um bei Bedarf beides einsetzen (oder den Unterschied erklären) zu können.

Bild: Unsplash / Lukas Eggers - Lizenz

Eine der Gemeinsamkeiten praktisch aller agil aufgestellten Organisationen ist die Nutzerzentrierung. Die Anforderungen sind in der Regel aus der Sicht des Nutzers formuliert (so genannte User Stories), und die fertigen Ergebnisse werden zusammen mit ihm getestet und besprochen. Was bei all dem aber zu bedenken ist -  manchmal lassen Benutzer sich zu Aktionen hinreissen die sie besser unterlassen hätten, und von denen das System sie abhalten sollte. Lassen sich auch derartige "verhindernde Funktionen" als User Story formulieren?

Bevor wir darauf eingehen eine kurze Sinnfrage: wenn ein Nutzer eine bestimmte Aktion nunmal durchführen will, warum sollte man ihn davon abhalten? Weiss er nicht am besten was richtig für ihn ist? Die Antwort darauf: leider nicht immer, und ein wie es der Zufall will gibt es auch ein aktuelles Beispiel dafür. Um zu zeigen wie produktiv sie im Home Office war veröffentlichte eine niederländische Ministerin auf Twitter einen Screenshot von einer EU-Ministerrunde an der sie gerade teilnahm. Da dieser in seiner URL den Konferenzdienst und den Zugangscode anzeigte war es für jeden ihrer Twitter-Follower möglich ebenfalls an dem Meeting teilzunehmen. Und ein Journalist gönnte sich den Spass und machte genau das.

Dit was de oorspronkelijke foto die vanaf het account van minister Bijleveld werd gedeeld, met daarin de meeting-ID en vijf cijfers van de pincode.

Het was een zescijferige pincode. Ik joinde met de naam 'admin'. pic.twitter.com/Fztrbqm5FR

— Daniël Verlaan (@danielverlaan) November 20, 2020

Zurück zur Ausgangsfrage. Lassen sich User Story formulieren die zwar aus Nutzerperspektive geschrieben sind aber ein fahrlässiges Verhalten wie das der niederländischen Ministerin verhindern sollen? Natürlich geht das, es fühlt sich aber künstlich an. "Ich als Videokonferenz-Teilnehmer möchte daran gehindert werden Zugangsdaten zu veröffentlichen, damit kein Unbefugter teilnehmen kann" ist kein Satz oder Wunsch den ein echter Mensch jemals äussern würde.

Ein besserer Ansatz wäre es sich den Benutzer/User aus einer anderen Perspektive vorzustellen. In UX-Design und Software-Test gibt es den Typus des "Evil User", der sich dadurch auszeichnet, dass er Funktionen immer wieder so benutzt wie sie nicht gedacht sind und dadurch Fehlfunktionen und falsche Ergebnisse erzeugt. Wichtig ist dabei, dass er das (meistens) nicht aus bösem Willen tut sondern aus Unkenntnis und ohne zu wissen was er anrichtet - wie im Fall der oben genannten Ministerin.

Vom Evil User zur User Story ist es jetzt nur noch ein kurzer Sprung. "Ich als Videokonferenz-Teilnehmer möchte Screenshots mit allen sichtbaren Informationen veröffentlichen, damit jeder sehen kann was ich mache". Mit solchen Anforderungen in ein Refinement zu gehen kann wertvolle Diskussionen ermöglichen. Für den Fall dass jemand etwas Derartiges tut (verhindern kann man es nicht) welche Informationen sind dann öffentlich sichtbar? Welche davon sind sicherheitsrelevant? Und wie könnte man sie unkenntlich machen?

Aus derartigen Diskussionen können sich dann die Akzeptanzkriterien der Evil User Story ergeben, die in diesem Fall negativ formuliert sind, da sie ja das "bösartige" Nutzerverhalten eindämmen sollen. Angelehnt an den oben genannten Fall könnte etwa eines sein, dass weder auf der Website des Video-Calls noch in der URL Zugangsdaten sichtbar sein dürfen.

Als letztes noch ein Tip aus der Praxis: es macht Sinn die Evil User Stories im Backlog mit einer besonderen Kennzeichnung zu versehen. Wenn das nicht passiert besteht das Risiko, dass das Team vergessen hat, dass es sich bei einer älteren Story um eine zu verhindernde Aktion handelt und diese dann in der Weiterentwicklung nicht verhindert sondern erleichtert oder sogar erst ermöglicht. In solchen Fällen steckt eine feine Ironie: das Team ist dann der Evil User seines eigenen Prozesses.