Jetzt tun vs. der richtige Zeitpunkt

• Video
• Audio (Podcast)

Peer-to-peer player für bessere Performance

Oder, hole dir diese Serie als Audio-Only Podcast!

Zur aktuellen Episode geht's hier

"Move fast and break things" oder "Move slow and mend things"? Besser jetzt etwas liefern oder Optionen und Möglichkeiten für die Zukunft schaffen? Welche Aufgaben müssen wir sofort erledigen und was kann warten?

Heute werden wir uns mit diesen, zugegebenermaßen nicht ganz einfachen, Fragen befassen. Im vorigen Teil der Serie "Quick Glance At: Agile Engineering" ging es um Kritikpunkte und Einwände gegen agile Softwareentwicklung.

Umkehrbare und unumkehrbare Änderungen

Manche Entscheidungen, die wir treffen, und manche Änderungen, die wir im Code machen, sind leicht wieder umgkehrbar. Wenn wir während der Entwicklung merken, dass das eben implementierte Design in eine Sackgasse führt, können wir die Entscheidung oft rückgängig machen—z.B. durch ein einfaches git reset.

Andere Entscheidungen sind schwieriger umzukehren: Wenn wir im Moment einen Rich Client entwickeln und auf eine Single-Page-Application mit HTML, CSS und einem JavaScript-Framework umstellen wollen, wird das bedeutenden Aufwand verursachen.

Und es gibt Änderungen, die sind gar nicht mehr umkehrbar: Wenn wir in einem Online-Shop aufgrund eines Fehlers zu wenig für Produkte verrechnen, wird es später nicht mehr möglich sein, das verlorene Geld zu bekommen. Wenn die Firma dadurch sogar Pleite geht, ist die Entwicklung vorbei und damit auch jede Möglichkeit, Entscheidungen und Software zu verändern.

Leg bitte hier eine kurze Pause ein und notiere dir aus deinem aktuellen Projekt für jede Kategorie einige Entscheidungen und Änderungen des letzten Jahres:
Welche Entscheidungen hätte man jederzeit ändern können?
Welche Entscheigungen hätte man nur mit erheblichem Aufwand wieder rückgängig machen können?
Welche Entscheidungen wird man nie wieder ändern können?

Am besten lädst du dir die aktuelle Notizbuchseite als PDF herunter und druckst sie doppelseitig aus.

Optionen und Commitment

In unserem Kontext ist eine Option die Möglichkeit, etwas zu tun, ohne Verpflichtung, es auch tun zu müssen. Ein Zugticket ist zum Beispiel so eine Option: Ich kann es nutzen, kann es aber auch verfallen lassen. Wenn ich es dann nutze, wird daraus ein Commitment.

Für das Bahnunternehmen, auf der anderen Seite, ist das verkaufte Zugticket eine Verpflichtung: Wenn ich es nutzen will, muss die Bahn mich zu meinem Zielort bringen (etwas vereinfacht gesagt, natürlich).

Diese "Real Options" haben normalerweise

• ein Ablaufdatum: Mein Zugticket ist heute und morgen gültig.
• einen Preis: Es hat 15€ gekostet.
• und einen Wert, den wir uns gleich noch genauer ansehen.

Sie haben gewisse Ähnlichkeiten mit Optionen, wie man sie aus dem Finanzwesen kennt, sind aber trotzdem nicht ganz vergleichbar.

Der Wert von Lieferungen und Optionen

Der Wert einer Option setzt sich aus zwei Teilen zusammen:

• Den Wert der Sache, die ich erhalte, wenn ich die Option einlöse: Das kann ein ideeller Wert sein, wie z.B. ein netter Ausflug mit dem Zug, oder etwas Greifbareres, wie etwa eine Softwarelieferung
• Der Wert, der sich aus der Möglichkeit ergibt, noch entscheiden zu können: Ich würde gerne den Ausflug mit dem Zug machen, aber wenn sich etwas wichtigeres ergibt, kann ich ihn absagen - So lange ich noch nicht in den Zug eingestiegen bin.

Da sich ein Teil des Werts einer Option daraus ergibt, noch entscheiden zu können, sollte man sich nicht zu früh committen, außer man hat einen guten Grund dafür.

Ein ähnliches Phänomen haben wir auch bei der Softwareentwicklung an sich: Ein Teil des Werts der gelieferten Software ergibt sich daraus, was die Software bereits leisten kann. Ein zweiter Teil des Werts wird aber dadurch bestimmt, was die Software in Zukunft noch zusätzlich leisten wird—also durch die Optionen, die wir für die Zukunft noch haben.

Andererseits können wir den Wert der Optionen nicht realisieren, wenn wir uns nicht auch irgendwann mal committen. Wenn wir gar keine Software liefern—oder, wenn wir Software liefern, die nur technische Abstraktionsschichten enthält, um alle Optionen offen zu halten, aber keine Features implementiert—werden die Benutzer auch nicht glücklich sein.

Commitment, Spikes und Experimente

Was können wir also tun, wenn wir ein Feature implementieren sollen, aber noch nicht wissen, was genau zu tun ist? Liz Keogh sagt im Buch "Commitment", wir haben drei Möglichkeiten:

• Die Entscheidung verschieben und erst mal etwas ganz anderes machen: Umpriorisieren.
• Die Entscheidung treffen, die sich am einfachsten wieder ändern lässt: Umkehrbare Entscheidungen priorisieren.
• Etwas implementieren, das es uns später ermöglicht, die Entscheidung zu ändern, zum Beispiel eine Abstraktionsschicht, durch die wir die konkrete Implementierung später austauschen können. Das macht die Entwicklung zwar etwas kostspieliger, dafür aber können wir das Commitment verschieben.

Wir können auch hier wieder auf Experimente und Feedback setzen: Wir wissen nicht, ob wir Weg A oder B wählen sollen? Man könnte doch einfach beides probieren, jeweils für 1-2 Tage. Danach weiß man hoffentlich mehr.

Dieses Vorgehen, etwas für kurze Zeit und timeboxed auszuprobieren, mit dem Ziel zu lernen, nennen wir Spike Solution. Dabei zählt jedoch nicht das Ergebnis. Dieses werfen wir normalerweise sogar in die Tonne und wir starten nach dem Spike noch einmal neu. Was zählt, ist zu lernen, ob der gewählte Weg der richtige sein könnte. Achtet also während dem Spike darauf, so viele Daten wie möglich für die Entscheidung zu sammeln.

Bevor es weitergeht, notiere kurz die Antworten auf folgende zwei Fragen:

• Welche Entscheidungen oder Änderungen stehen in deinem aktuellen Projekt in nächster Zeit an?
• Welche der vorgestellten Strategien—Umpriorisieren, umkehrbare Entscheidungen, zusätzliche Implementierung, Spike—scheint im Moment am passendsten, und warum?

Änderbares Design = Einfaches Design

Um uns in der Entwicklung Optionen offen zu halten, muss das Design der Software—speziell die Architektur—alle diese Optionen unterstützen. Was aber nicht funktioniert, ist ein Design zu schaffen, das von vornherein für alle Eventualitäten geeignet ist (auf die Gründe dafür werde ich in zukünftigen Teilen noch näher eingehen).

Um uns Optionen offen zu halten, müssen wir also sicherstellen, dass wir unser Design später noch ändern und bereits getroffene Entscheidungen widerrufen können.

Manchmal bedeutet das, zusätzlichen Code zu implementieren, um eine Entscheidung zu verschieben; so, wie vorhin in der dritten Strategie beschrieben. Das funktioniert aber nur, wenn wir bereits wissen, welche Entscheidung in die Zukunft verschoben werden muss.

Für den allgemeinen Fall funktioniert also auch das nicht. Wir können aber unser Design so einfach wie möglich halten. Wir können sicherstellen, dass es nur die aktuellen, bereits bekannten Anforderungen unterstützt—und keine derzeit unnötigen Abstraktionen und Eventualitäten enthält. Denn wenn wir das Design später ändern müssen, ist das leichter, wenn es einfach ist. Enthält das Design nur wenige Elemente und wenige Beziehungen, ist es einfach verständlich.

Schnell Handeln

Immer auf einen besseren Zeitpunkt zu warten und immer Optionen für die Zukunft zu generieren, können uns daran hindern, überhaupt zu handeln. Wir können uns selbst dadurch lähmen, zu viel zu analysieren und zu sehr zu warten.

Deshalb ist "Bias for action", eines der Prinzipien bei Amazon, ebenfalls wichtig. Besser schnell handeln und einen Fehler wieder gut machen als gar nichts zu tun.

Was wir dabei erreichen müssen, ist eine Konvergenz zu besseren Ergebnissen. Durch die schnellen Entscheidungen dürfen wir nicht hin- und herspringen und auch nicht genauso viele Rückschritte wie Schritte vorwärts machen. Wir müssen lernen, unsere Fehler zu korrigieren und mit den neuen Informationen bessere Entscheidungen zu treffen.

Wir müssen die Risiken von schnellen Entscheidungen klein halten. Und das schaffen wir durch reversible Entscheidungen und durch Optionen für die Zukunft.

Fazit

Ein Teil des Werts unserer Entwicklungsarbeit besteht darin, was wir an Software bereits geliefert haben. Aber auch das, was wir noch liefern können, trägt zum Wert bei. Uns Optionen offen zu halten, steigert diesen Wert. Unsere Software änderbar zu gestalten, steigert diesen Wert.

Andererseits müssen wir uns auch trauen, Entscheidungen zu treffen. Und schnelle Lieferungen sind wertvoll und essentiell, wie ich in einem früheren Teil erklärt habe.

Wir müssen zwischen diesen beiden Überlegungen abwägen: Schnell Entscheidungen treffen und liefern, aber uns trotzdem Optionen für die Zukunft offen halten. Einfaches Design, umkehrbare Entscheidungen, Spikes und Experimente helfen uns dabei.

In diesem Teil der Serie habe ich Abwägungen zwischen "Jetzt tun" und "den Richtigen Zeipunkt finden" erklärt. Im nächsten Teil befassen wir uns damit, warum der Code, den wir produzieren, nicht der Flaschenhals der Softwareentwicklung ist.

Weitere Informationen

• Commitment - A novel about managing project risk by Olav Maassen, Chris Matts and Chris Geary
• Tidy First? by Kent Beck
• What is a bias for action (and how do you build it)?