Keep it simple, stupid

Lass mich mal direkt mit einer Hypothese starten:

Als Product Owner möchtest du schneller einen höheren Nutzen für deine Anwender und dein Unternehmen erzielen.

Und? Liege ich mit meiner Hypothese halbwegs richtig? Vermutlich schon. Die Lösung für dieses Problem ist relativ simpel. KISS. Keep it simple, stupid. Wie die Lösung genau aussieht, erkläre ich in diesem Beitrag.

Lass uns mal einen Blick auf eine typische zeitliche Abfolge werfen. Ihr entwickelt einen Satz neue Features in einem Sprint, liefert aus und generiert einen Nutzen. Nächster Sprint, nächste Features, wieder ein Mehrwert. Dritter Sprint, du kennst das Spiel, aber diesmal etwas weniger Nutzen. 

Wie können wir jetzt schneller einen höheren Nutzen erzielen?

Möglichkeit 1: Priorisierung. Wir machen zuerst die Features, die einen hohen Nutzen haben, und danach die anderen. Das machst du vermutlich schon und ist hier nicht unser Thema.

Möglichkeit 2: Effizienzsteigerung. Ihr überlegt, wie ihr als Team und innerhalb des Unternehmens besser arbeiten könnt. Wie könnt ihr die Kommunikation verbessern? Wie könnt ihr Fehler und Missverständnis vermeiden? Was müsst ihr lernen oder welche Erfahrung fehlt euch, um effizienter als Team zu arbeiten? Auch mit diesen Themen beschäftigt ihr euch vermutlich - das ist ja eines der zentralen Elemente in einer Retro.

Möglichkeit 3: Streichen. Ihr streicht überflüssige Features. Ihr streicht überflüssige Tätigkeiten. Das ist ein gigantischer Hebel, der leider viel zu selten genutzt wird. Es ist auch völlig klar, warum - wer gibt schon gerne zu, dass die eigene Tätigkeit oder das eigene Wunschfeature überflüssig ist? Niemand. Also musst du ein bisschen forschen…

Ich möchte dich auf zwei gegensätzliche Konzepte aufmerksam machen. Vermutlich kennst du sie schon und das Folgende ist nur eine Erinnerung:

• „Just in Case“: wir tun jetzt etwas, für den Fall, dass wir dieses etwas später einmal brauchen.
• „Just in Time“: Wir tun in dem Moment etwas, in dem dieses etwas brauchen.

Als produzierendes Unternehmen lege ich mir ausreichend Material ins Lager, damit ich alle möglichen Aufträge sofort bedienen kann. Das wäre just in case. Oder aber ich lasse mir das Material erst in dem Moment liefern, in dem der Auftrag tatsächlich eintrudelt. Just in Time.

Als Verbraucher lege ich mir 100 Rollen Klopapier in den Keller, damit ich die nächsten Monate nicht mir der Hand säubern muss. Oder aber ich gehe alle zwei Wochen in den Supermarkt und hole wieder 10 Rollen.

Als iPhone-Nerd schließe ich eine Handyversicherung ab, kaufe eine Schutzhülle und benutze Panzerglas. Just in case - vielleicht fällt es auf die Steine oder in die Toilette. Oder ich nutze das blanke Telefon und zahle die Reparatur, wenn es tatsächlich beschädigt ist. Just in time.

Als Mitarbeiter in der Buchhaltung fordere ich ein Multi-Währungs-Feature. Falls wir evtl. in den nächsten Jahren Produkte außerhalb des Euro-Raums verkaufen, kann ich sie direkt verbuchen. Oder ich passe die Buchhaltungssoftware erst in dem Moment an, in dem die ersten Verkäufe getätigt sind.

Als Entwickler füge ich bei der Entität „Kunde“ in der Datenbank eine Treueprogrammnummer ein. Falls wir evtl. in den nächsten Jahren ein Treueprogramm einführen, brauchen wir keine Datenbankänderung.

Mit diesen Beispielen will ich auf eins hinaus: „Just in Case“ ist eine Risikoverringerungsstrategie. Quasi eine Versicherung. Es gibt ein gewisses Risiko - oder Chance - dass in der Zukunft etwas passiert. Damit ich dann, in der Zukunft, keinen Stress habe, sorge ich jetzt schon mal vor. Klingt logisch, oder?

Unter diesem Gesichtspunkt können wir diese just in case Aktivitäten dann als normales Risikomanagement durchführen. Du schaust, wie hoch die Eintrittswahrscheinlichkeit ist. Du schaust, wie hoch der potenzielle Schaden ist. Und dann entscheidest du, ob du das Risiko akzeptierst, welche Risikoverringerungsstrategien möglich sind und welche du ggf. anwendest. Der zentrale Punkt ist hier, dass du eine bewusste Entscheidung triffst, ob du etwas unternimmst oder nicht. Üblicherweise passiert genau das nicht. Üblicherweise wird gerade nicht evaluiert, wie wahrscheinlich ein Ereignis eintreten wird. Üblicherweise wird gerade nicht evaluiert, wie aufwendig eine nachträgliche Anpassung ist. Es wird halt einfach umgesetzt.

Das Problem dabei: Risikoverringerungsstrategien sind - genauso wie Versicherungen - nicht umsonst. Du bezahlst dafür. Du bezahlst damit, dass die Umsetzung länger dauert, weil eine komplexere Programmierung gewählt wird. Du bezahlst damit, dass andere Features später kommen. Du bezahlst damit, dass die Wartung und Anpassung deiner Software komplexer und damit aufwändiger wird. Du bezahlst damit, dass neue Teammitglieder eine längere Einarbeitungszeit benötigen, weil „Just-in-case-Code“ nicht intuitiv verständlich ist. Du bezahlst damit, dass deine Anwender mit nicht notwendigen UI-Elementen verwirrst werden.

Wenn du also das nächste Mal von deinen Teammitgliedern, Anwendern oder Stakeholdern Begriffe hörst wie „eventuell zukünftig“, „es könnte sein, dass“, „vielleicht brauchen wir“ dann sollten bei dir alle Alarmglocken schrillen. Das klingt nach Just in Case. Du solltest transparent machen, was die Konsequenzen sind, d.h. der Preis, der bezahlt werden muss. Und du solltest hartnäckig nachfragen, wie hoch die Eintrittswahrscheinlichkeit ist und wie groß der mögliche Schaden sein wird, um eine bewusste Entscheidung zu treffen.

Risikomanagement ist eine sehr sinnvolle Sache. Aber nicht jedes Risiko muss minimiert werden. Und so kannst du schneller einen höheren Nutzen für deine Anwender schaffen. In diesem Sinne wünsche ich dir viel Erfolg beim Streichen überflüssiger Features und überflüssigen Codes!