Weniger, dafür früher, ist besser

• 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

Iterative Entwicklung, kleine Arbeitspakete, DevSecOps, Continuous Delivery: Alles läuft darauf hinaus, dass wir schneller liefern können.

Im letzten Teil der Serie habe ich über Werte, Prinzipien und Ziele der agilen Softwareentwicklung gesprochen und wie diese eine Engineering-Kultur beeinflussen. Heute geht es um Geschwindigkeit: Schnellere Lieferung ist besser, selbst wenn das bedeutet, dass wir weniger liefern. Und das fast immer. Warum das so ist und welche Ausnahme es dann doch gibt, werde ich in diesem Teil der Serie "Quick Glance At: Agile Engineering" erklären.

Bevor es weitergeht, nimm dir kurz Zeit und notiere auf Papier:
Aus welchen Gründen könnte es besser sein, ein Zehntel der Funktionalität in einem Zehntel der Zeit zu liefern, als zu warten, bis alles fertig ist?

Dafür kannst du dir auch die aktuelle Notizblock-Seite herunterladen und doppelseitig ausdrucken.

Kosten vs. Wert

Bevor wir zu spezielleren Betrachtungen kommen, möchte ich kurz über Kosten und Wert sprechen.

Während wir aktiv an einem Task arbeiten, steigen die Kosten für diesen Task stetig an - als Vereinfachung nehme ich diesen Anstieg erst mal linear an. Wenn der Task gerade "wartet"—auf den Test, das nächste Review oder das Deployment in Produktion—steigen die Kosten nicht weiter an.

Wenn das Ergebnis dieser Arbeit in die Produktion geliefert wird, liefern wir einen bestimmten Wert, der hoffentlich höher als die Kosten ist.

Wenn wir mit weniger Personen an dem selben Task arbeiten und dafür länger brauchen, verursachen wir also dieselben Kosten und liefern denselben Wert, nur eben später. Genauso verhält es sich mit verlängerten Wartezeiten. Dafür kann ein Team derselben Größe an mehreren Tasks gleichzeitig arbeiten.

All das ist natürlich sehr stark vereinfacht: Die Kosten können bei verlängerter Durchlaufzeit höher werden und der Wert kann sinken. Andererseits kann die Verlängerung der Arbeitszeit weniger extrem ausfallen als es durch die Verringerung der Personenanzahl suggeriert wird. Aber warum denn? Schreibe deine Überlegungen in deine Notizen.

ROI und Durchlaufzeit

Auch, wenn wir konzeptionell durch die Auslieferung ein Paket mit einem gewissen Wert geliefert haben, so ist dieser doch eigentlich nur fiktiv. Für unsere Benutzer ist die Software jetzt ein kleines bisschen wertvoller geworden, aber sie beginnt erst ab jetzt, diese "Returns" zu generieren.

Mit der nächsten Lieferung wird sie noch etwas wertvoller und kann dadurch ab dann noch schneller Wert für unsere Benutzer generieren.

Bei gleichzeitiger Bearbeitung mit verlängerter Durchlaufzeit liefern wir also einfach nur etwas später die selbe Funktionalität, in größeren gelieferten Paketen, bei gleichen Kosten. Und trotzdem ist der generierte Wert zu jedem Zeitpunkt niedriger als bei schnellerer Lieferung - Und das bei gleichen Investitionen bis zu diesem Zeitpunkt!

Feedback: Steuerungsmöglichkeiten

Wenn wir früher liefern, bekommen wir früher Feedback. Und das ist wichtig: Wenn wir früher Feedback bekommen, können wir früher Fehler beheben, neu priorisieren und gegensteuern.

Mal angenommen, ein Team liefert gleichzeitig Arbeitspaket A, B und C und plant danach, gleichzeitig D, E und F zu liefern. Jedes dieser Arbeitspakete soll danach eine Wertsteigerung von 2/Woche bringen (eine zugegebenermaßen sehr abstrakte Zahl, die nicht unbedingt etwas mit Geld zu tun hat).

Aber ein Fehler in Arbeitspaket A verringert diese Wertsteigerung und als Feedback aus den Tests von B geht hervor, dass C im Moment gar nicht benötigt wird, dafür G vorgezogen werden muss, da es einen Wert von 3/Woche bringen würde. Der Bugfix und Arbeitspakete D, E und G können noch im nächsten Release geliefert werden und steigern den generierten Wert.

Und jetzt sehen wir uns den selben Fall noch einmal an, aber dieses Mal liefert das Team nach jedem Arbeitspaket. Im ersten Schritt liefern sie A und bekommen als Feedback einen Bug Report. Danach liefern sie B und den Bugfix. Als Feedback erfahren sie, dass G wichtiger ist und C nicht mehr benötigt wird, also liefern sie G. Danach noch D, E und F.

Das zweite Team hat nicht nur dadurch mehr Wert generiert, dass sie diesen früher generieren, sondern noch mehr dadurch, dass sie auf Feedback schneller reagieren konnten: Dadurch, dass sie das unnötige Arbeitspaket C gar nicht begonnen haben und dafür das wertvollere Arbeitspaket G vorziehen konnten!

Feedback: Qualität und WIP

Wenn wir weniger, dafür aber schneller und öfter liefern, bekommen wir auch weniger und dadurch besseres Feedback.

Bei der ersten großen Lieferung seit 6 Monaten werden erst mal Fehler gefunden werden und Kleinigkeiten, die die Benutzer stören, aber nicht besonders großen Wert liefern. Erst danach bekommen wir Feedback, das wir brauchen, um die weitere Entwicklung besser planen zu können—und für dieses Feedback ist es dann oft auch schon zu spät, weil wir von einem Feature zuviel geliefert oder sogar das falsche Feature geliefert haben.

Und wir bekommen so viel Feedback auf einmal, dass wir es managen müssen: Ein großer Teil davon kommt erst mal ins Backlog. Damit sind auch Features, die wir bereits abgeschlossen geglaubt hatten, noch nicht erledigt: Der Fehler muss noch behoben werden! Es fehlt doch noch ein wichtiger Sonderfall!

Wir haben verstecktes Work-in-Progress: Offene Arbeitspakete, von denen wir gar nichts wissen, bis wir das Feedback bekommen.

Wenn wir hingegen regelmäßig kleine Pakete liefern, bekommen wir auch Feedback in kleinen Häppchen. Diese können wir sofort erledigen und müssen sie nicht managen. Und wir kommen schneller zu wertvollerem Feedback.

Geschwindigkeit und Nachhaltigkeit

Wenn wir regelmäßig kleine Pakete liefern, fällt es einfacher unser Backlog, die Fehlerliste und das Work-in-Progress klein zu halten. Das Risiko wird kleiner und es gibt damit weniger Themen, die wir managen müssen. Der Overhead sinkt und das macht es uns leichter, regelmäßig kleine Pakete zu liefern.

Dadurch, dass wir in "kleineren Portionen" ausliefern, wird auch die Wahrscheinlichkeit kleiner, dass wir unbeabsichtigt etwas kaputt machen. Und wenn etwas schiefgeht, ist es einfacher, auf die vorige Version zurückzurollen: Die Änderung war ja sehr klein, also ist es auch der Verlust, den wir durch das Rollback erleiden. Lange Test-Bugfix-Zyklen mit Stress und Überstunden vor dem Release werden weniger oder verschwinden komplett.

Schneller ist somit auch einfacher als langsamer - Wenn wir es richtig machen.

Overhead und Transaktionskosten

Kleinere Pakete schneller zu liefern, kann nur dann funktionieren, wenn der Overhead und die Transaktionskosten der Lieferung auch kleiner werden. Wenn wir für jede Lieferung 3 Tage Tests und zwei Tage Freigaben einplanen müssen, können wir nicht einen Tag entwickeln und danach liefern.

Aber die gute Nachricht ist: Overhead und Transaktionskosten können wir zumindest teilweise durch Agile Engineering reduzieren, zum Beispiel durch Automatisierung oder Sicherheitsnetze.

Wann sind häufige Releases zumutbar?

"Aber können wir den Benutzern überhaupt zumuten, dass sich die Software alle paar Tage komplett ändert?" - Nein, das sicher nicht.

Aber wenn wir oft kleine Pakete liefern, ändert sich die Software nicht komplett, sondern graduell. Und es gibt auch technische Möglichkeiten, diese Änderungen noch weiter abzufedern: A/B Testing, Tranchen, Feature Toggles, Branch by Abstraction und mehr. Aber dazu mehr in späteren Teilen der Serie.

Fazit

Durch schnellere Lieferung generieren wir mehr Wert bei gleichen Kosten. Wir bekommen besseres Feedback, haben weniger work-in-progress und können unser zukünftiges Vorgehen effizienter gestalten. Wir können frühzeitiger auf Feedback und veränderte Bedingungen und Anforderungen reagieren. Das ermöglicht es uns, an Dingen zu arbeiten, die gerade jetzt den größten Nutzen bringen und gegenzusteuern, wenn wir in die falsche Richtung losgelaufen sind.

Damit das funktioniert, müssen wir Overhead und Transaktionskosten so weit wie möglich verringern. Und wir müssen uns Gedanken über die Zumutbarkeit der Änderungen machen. Aber auch dafür haben wir Werkzeuge im Agile Engineering - Werkzeugkasten.

In diesem Teil der Serie ging es um Geschwindigkeit und warum früher fast immer besser ist. Im nächsten Teil erkläre ich, was ich mit Mean Time to Feedback meine und warum wir diese optimieren sollten.

Weitere Informationen

• Why Speed is Key
• Well-crafted code will ship faster