Bahnfahren erinnert mich an Softwareentwicklung: Regelmäßig werden Versprechen nicht eingehalten. Der ICE von Hamburg nach Wien hat schon beim Start 6 Minuten Verspätung. Daraus werden 10 bis Würzburg. Das sind ca. 5% Verzug und hört sich nicht viel an. Nur verpasse ich dadurch meinen Anschlusszug. Ich muss 45 Minuten warten - und komme mit 60 Minuten Verspätung am Ziel an. Der Gesamtverzug der für mich interessanten End-to-End Verbindung beträgt damit über 20%.
Wenn die Bahn bei Direktverbindungen sich also womöglich für nur geringe Verzögerungen rühmt, dann lügt sie sich in die Tasche. Für mich als Fahrgast, der fast immer ein- oder zweimal umsteigen muss, ist die Verlässlichkeit der Deutschen Bahn inakzeptabel. Die Differenz zwischen Versprechen und Leistung ist zu groß. Da verliere ich das Vertrauen…
Oder ich passe einfach meine Erwartung der Realität an. Wenn die Bahn nicht verlässlich liefert, dann muss ich meine Planung und mein Verhalten ändern.
Let´s get real: Aufwandschätzung funktioniert nicht
Zu derselben Einsicht sollten Kunden und Manager der Softwareentwicklung kommen. Nach 50 Jahren unzuverlässiger Lieferung von Software, sollten sie ihre Erwartungen und ihren Umgang mit der Softwareentwicklung dieser Realität anpassen.
Eine Lieferung von Funktionalität + Qualität + Wandelbarkeit innerhalb einer engen Zeitvorgabe funktioniert nicht verlässlich.
Softwareentwicklung ist kein Brotbackautomat, bei dem man vorhersagen kann, wann er nach Einfüllen der Zutaten das Brot fertiggestellt haben wird.
Die Schätzung der Dauer von Softwarevorhaben - von der relativ kleinen Änderung bis zur Neuentwicklung - im Sinne einer Vorhersage ist unmöglich.
Mit “unmöglich” meine ich hier: Vorhersagen werden regelmäßig, d.h. in mehr als 80% der Fälle, um 10%, 20% oder mehr verfehlt. Da hilft es auch nicht, beim nächsten Mal mehr Puffer einzurechnen.
Wenn sich bei Ihnen jetzt Widerstand regt, weil es in Ihrem Unternehmen, bei Ihren Projekten doch immer funktioniert… dann nehmen Sie meine Glückwünsche entgegen. Freuen Sie sich an diesem Erfolg. Überlegen Sie, ob Sie ein Buch über Ihr Rezept schreiben. Ich bin sicher, die Softwarewelt lechzt danach. Sie können reich werden.
Aber Spaß beiseite: Mir geht es weniger darum, ob es objektiv unmöglich ist, die Dauer von Softwareentwicklung vorhersagen zu können. Es mag möglich sein - nur kenne ich niemanden, der das verlässlich beherrscht.
Ebenso will ich Ihnen Ihren Erfolg nicht ausreden. Wenn Sie das für mich Unmögliche schaffen sollten, dann erkenne ich das an - nur nützt das all den anderen Projekten nichts, in denen es nicht funktioniert.
Die schlichte Praxisrealität ist - zumindest in meiner Wahrnehmung über viele Projekte/Teams pro Jahr hinweg -, dass Aufwandschätzung in der Softwareentwicklung für die Vorhersage (!) nicht funktioniert. Sie ist entweder nicht in praxisrelevanter Breite möglich oder sie so schwierig, dass es wieder nicht praxisrelevant ist.
Wenn ich also dazu rate, es mit den Voraussageversuchen zu lassen, dann halte ich das für eine realitätsinformierte erwachsene Reaktion. Wenn es 50 Jahre lang nicht funktioniert, mit dem Kopf durch die Wand zu kommen, sollte man anfangen, die Tür zu suchen.
Ja, Manager und Kunden der Softwareentwicklung - wie auch viele Softwareentwickler selbst - scheinen mir manchmal in dem Witz gefangen, wo der Betrunkene nachts seinen Schlüssel unter der Laterne sucht - und nicht da, wo er ihn verloren hat.
Also: Vergessen Sie die Aufwandschätzung zur Vorhersage. Schätzung für den Vergleich sind hingegen ok - wenn Sie denn einen Vergleichswert, also Erfahrung haben.
- “User Story A schätzen wir auf 5 Story Points, Story B auf 8.”
- “System Y scheint grob mit System X vergleichbar. X haben wir in 5 Monaten realisiert. Dann wird Y wohl auch in überschaubaren Monaten umsetzbar sein und keine Jahre brauchen.”
Das sind vergleichende Schätzungen. Die können funktionieren - wenn man sich überhaupt ein Urteil erlauben darf. Aus Vergleichen leiten sich aber keine Termine ab. Hier geht es “nur” um Größenordnungen. Darum, ob zu erwartende Aufwände zur selben oder einer anderen Liga gehören.
Und selbst wenn man sich nur auf den Vergleich beschränkt, gibt es keine Gewissheit. Egal, wie klein man die zu schätzende Größe herunterbricht.
Aber ich will endlich aufhören, mir den Mund fusselig zu reden. In diesem Artikel geht es mir ja um etwas anderes. Nämlich darum, wie Kunden und Manager mit dieser dreckigen Realität umgehen können.
Ein realistischeres Weltbild
Ok, also Schluss mit der Wahnidee “Softwareaufwände lassen sich verlässlich vorhersagen.” Schluss mit der ewigen Frage, “Wann könnt ihr X liefern?” Vor allem Schluss mit der Forderung, “Y muss bis dann und dann auf jeden Fall fertig sein.”
Ja, das tut weh. Ohne diese Pseudosicherheit - denn nicht mehr als das ist es ja - stellt sich ein Gefühl der Hilflosigkeit ein.
Welchen Gewinn der Wechsel des Fokus von “Fertigstellung” (completion) auf “Fortschritt” (progress) jedoch bringt, habe ich an anderer Stelle ausführlich beschrieben. Siehe dazu meine Artikelserie zu Spinning als Kern agilen Vorgehens. Wenn Software inkrementell “einfach wächst”, dann entsteht ein Strom von Releases, in den man jederzeit hineingreifen kann, um immer wieder Nützliches abzuschöpfen. Die Flexibilität, auf Prioritätenänderungen zu reagieren, steigt. Es entsteht plötzlich die Möglichkeit, sogar Geld zu sparen. Denn wer kleinschrittig in Inkrementen vorgeht, der kann nicht nur jederzeit seinen Kurs ändern, sondern auch anhalten, wenn der erreichte Stand gut genug ist.
Wer hingegen nur “alles und zwar sofort” denken kann… der muss auch immer für alles (und noch viel mehr) bezahlen. Gier und Ungeduld haben ihren Preis. Das war immer schon so. Die Softwareentwicklung kann dieser Wahrheit nicht entfliehen.
Aber auch Spinning möchte ich hier nicht noch einmal erklären. Mich hat vielmehr ein Bild ereilt, das ich Ihnen mitteilen möchte. Neulich habe ich für mich eine tauglichere Analogie für die Softwareentwicklung gefunden.
Das vorherrschende Bild von Softwareentwicklung vergleicht sie mit irgendeiner Form von Produktion. Da mögen andere das Gärtnern oder die Bergbesteigung dagegen halten. Es nützt nichts. Management und Kundschaft glauben, es handle sich bei der Softwareentwicklung - entgegen ihrer Bezeichnung als Entwicklung - um eine Form von Handwerksleistung. Ja, sogar Softwareentwickler wollen das glauben und bezeichnen sich lieber als craftsmen denn als engineers.
Aber auch wenn es selbstverständlich wahr ist, dass in der Softwareentwicklung handwerklich gut gearbeitet werden muss, ist die Analogie fundamental falsch. Weder ist Softwareentwicklung eine handwerkliche Einzelfertigung, noch eine industrialisierte Massenfertigung. Beides ist nämlich per definitionem Reproduktion und daher im Aufwand vorhersagbar.
In den letzten 100 Jahren scheinen wir in der westlichen Hemisphäre in einer durch Vorhersagbarkeiten gesicherten Welt gelebt zu haben. Allemal die aktuellen Entwicklergenerationen können sich an nichts anderes erinnern.
Der Trimuph des skalierten Handwerks, genannt Industrialisierung, ist offensichtlich. Da ist es verständlich, wenn nicht nur der Laie, sondern auch der Fachman glaubt und glauben will, dass Softwareentwicklung zu dieser Kategorie gehört.
Dabei besteht keine Not, alles der Reproduktion und Verlässlichkeit zu subsummieren. Menschen können mit Unverlässlichkeit umgehen. Historisch gesehen ist es wohl sogar die absolute Neuheit und damit Ausnahme, dass wir in so viel Verlässlichkeit eingebettet sind.
Ich habe also überlegt, ob es Beispiele für alternative Analogien für die Softwareentwicklung gibt. Können wir nicht mit einem Weltbild erfolgreicher sein, dass die real existierende Unvorhersagbarkeit umarmt? Gibt es vielleicht Beispiele dafür, dass Menschen auch in Unvorhersagbarkeit erfolgreich gewesen sind?
Und siehe da… tatsächlich können Menschen mit Unwägbarem, Unsicherem, gar hoch Risikobehaftetem umgehen.
Beispiel 1: Baseball
Beim Baseball wird ein Ball mit einem Schläger so geschlagen, dass er möglichst weit fliegt und nicht gefangen wird. Das versuchen Fänger im Spielfeld zu vereiteln. Wo ist die Unvorhersagbarkeit? Im Abschlag des Balls und in den Windverhältnissen. Wie der Schläger den Ball trifft - Geschwindigkeiten von Ball, Schläger, Winkel - und wie der Ball während des Fluges beeinflusst wird, ist für die Fänger nicht messbar. Sie müssen sich überraschen lassen. Die Fänger im Spielfeld können sich also nicht einfach dorthinstellen, wo der Ball landen wird. Auch wenn es sich um einen ballistischen Flug handelt, steckt das Ergebnis voller Überraschungen. Das macht den Reiz des Baseballspiels aus.
Beispiel 2: Wetter
Das Wetter folgt einem Rhythmus (Jahreszeiten, Tag & Nacht). Wir haben also zumindest grobe Erwartungen an seine Entwicklung. Es gibt eine gewisse Vorhersagbarkeit. Im Detail - für die nächsten Stunden oder Tage - hat die sich sogar in den letzten Jahrzehnten erheblich verbessert.
Grundsätzlich jedoch ist das Wetter unvorhersehbar. Regenwahrscheinlichkeiten von 20% oder 50% sind keine Seltenheit, wenn man in seine Wetter-App schaut. Was soll man damit machen? Regenschirm mitnehmen oder nicht?
Aber wir haben gelernt, damit zurechtzukommen. Wir können einen Urlaub “erfolgreich durchführen”, auch wenn wir nur grob wissen, wie das Wetter sein wird.
Klar, es gibt Erwartungen: Wer im Sommer nach Italien fährt, erwartet dort keine drei Wochen Regen bei 15°. Und das wahrscheinlich zurecht. Dennoch… ununterbrochener Sonnenschein bei angenehmen 28° ist nicht garantiert. Heute in Zeiten des Klimawandels sogar weniger als früher, da das Wetter im Sommer immer schön war, wie wir uns alle erinnern.
Und nicht nur den Urlaub bewältigen wir trotz des Wetters. Wir können uns sogar ernähren. Wir haben gelernt, selbst mit größten Wetterüberraschungen zurechtzukommen. Wo früher Hungersnöte Landstriche leergefegt haben, da bleiben Menschen heute ungerührt.
Beispiel 3: Auktion
Bei einer Auktion ist ungewiss, wie hoch am Ende der Preis für einen Gegenstand sein wird. Ist das Fahrrad bei der Versteigerung im Fundbüro für 5€ oder 50€ zu haben? Kann man das Haus in der Zwangsversteigerung für 50.000€ oder 150.000€ “schießen”?
Das Auktionshaus mag einen Einstiegspreis setzen. Darunter geht es nicht - doch nach oben gibt es keine Grenze. Der Preis entwickelt sich vielmehr unvorhersagbar während der Auktion, selbst wenn man nach einer Vorbesichtigung eine Idee der “Preis-Liga” gewonnen hat. Und damit können alle Bieter leben.
Beispiel 4: Der Markt
Ist der Markt, auf dem Ihr Unternehmen agiert vorhersagbar? Kaum. Sie mögen Erwartungen haben… aber es gibt keine Garantie. Da können sich Manager Quartalsziele setzen wie sie wollen. Am Ende ist der Markt immer unzuverlässig.
Für den Absatz von Nutella mag er weniger schwanken als für den Absatz von Autos. Oder umgekehrt. Letztlich gibt es aber keine Garantie, nichts kann erzwungen werden. Und dennoch überleben Lieferanten - allerdings umso schlechter, je unflexibler sie sind. Mehr “Planwirtschaft” erzeugt mehr Schmerzen.
Beispiel 5: Aktienbörse
Nach all diesen Beispielen nun noch mein Lieblingsbeispiel, das Bild, das mich ereilt hat.
An der Aktienbörse ist Vorhersagbarkeit notorisch abwesend - und dennoch zieht es ständig Menschen dorthin. Denn wo viel Unvorhersagbarkeit, da viel Gewinn, wenn es doch mal klappen sollte. Das Risiko lockt.
Wer sich an der Börse behauptet, der agiert jedoch nicht ignorant. Der lernt, mit Risiko umzugehen. Er weiß, dass er nicht auf den einen großen Coup setzen kann, sondern seine Gewinne und Verluste ausbalancieren muss.
Natürlich gibt es wie beim Wetter und dem Markt an der Aktienbörse Muster. Doch die scheinen nur vergleichsweise wenigen bekannt. Die Masse bewegt sich dort wahrscheinlich eher im Unvorhersehbaren - und hat gelernt, trotzdem erfolgreich zu sein.
Von Siegern und Überlebenden lernen
Menschen können erfolgreich sein im Angesicht von Unvorhersagbarkeit. Manchmal suchen sie die Unwägbarkeit sogar auf. Sie verlassen die Geborgenheit der Berechenbarkeit bewusst, weil die ihre Chancen begrenzt. In anderen Fällen gibt es keine Alternative. Da ist das Leben trotz aller Bemühungen eben unvorhersagbar. Wie zum Beispiel in der Softwareentwicklung.
Auch in der Softwareentwicklung gibt es Muster. Um Feiertage herum oder in der Urlaubszeit wird wahrscheinlich weniger geschafft als zu anderen Zeiten. Die Softwareentwicklung hat also auch eine Jahreszeitlichkeit. In diesen Rhythmus grätschen dann allerdings z.B. Krankheiten hinein.
Und es lässt sich natürlich auch eine gewisse “Wetterentwicklung” feststellen: Wenn es an einem Feature schon 2–3 Tage gut voran gegangen ist, dann ist es vielleicht recht wahrscheinlich, dass es auch zügig weitergeht. Morgen ist mit 60% Wahrscheinlichkeit wieder solches Wetter wie heute - mit 40% Wahrscheinlichkeit jedoch eben nicht. Und so kann sich das Blatt bei der Featureumsetzung auch von heute auf morgen wenden. Wie lange es bis zu Fertigstellung braucht… nicht vorhersagbar. Genausowenig, wieviele Tage hintereinander die Sonne scheinen wird.
Also nocheinmal: Let´s get real. Wer als Manager oder Kunde mit der Softwareentwicklung umgeht, sollte nicht an Handwerk denken, sondern an Aktienbörse.
Wer insofern an das Eintreffen einer Aufwandschätzungsvorhersage glaubt und darauf seine Planung ausrichtet, der wettet. Er geht ein Spekulationsgeschäft ein. Er tut genau das, was wir von unseren Banken immer weniger wollen. Und er wähnt sich im selben Glauben, die Sache im Griff zu haben - bis ihm die Sache um die Ohren fliegt. Dann heißt es, den eigenen Arsch retten und den Schaden begrenzen.
Wer das besser machen möchte, der sollte von den Siegern an der Aktienbörse und den Überlebenden der Evolution lernen. Die haben Strategien entwickelt, die uns in der Softwareentwicklung nutzen können.
Strategie 1: Sense & adapt
Vom Baseball-Spieler im Feld können wir lernen, dass Erfolg davon abhängig ist, sich einer Entwicklung anzupassen.
Natürlich rennt der Fänger nicht in einer beliebigen Richtung und auch noch vor Abschlag des Balls los. Er wartet vielmehr, ob der Ball grob in seine Richtung fliegt. Er beobachtet also zunächst. Und dann… dann berechnet er nicht einen Aufschlagort für den Ball und rennt direkt in dessen Richtung. Vielmehr folgt er dem Ball mit einem ständigen Blick darauf. Er läuft keine Gerade, sondern folgt einer Kurve - die ihn umso eher zu einem erfolgreichen Rendevouz mit dem Ball bringt, je besser er beobachtet und seinen Lauf korrigiert. Dazu braucht er Erfahrung und Fähigkeit.
Erfolg ist im Baseball der Fang des Balls, nicht die Einhaltung eines Zeit- oder Kraftbudgets.
Natürlich hilft es dem Spieler, sich bei jeder Ballverfolgung ökonomisch zu verhalten, um das Spiel durchzuhalten. Deshalb definiert er jedoch keine Aufwände vorab. Das wäre im wahrsten Sinn des Wortes nicht zielführend.
Der gefangene Ball zählt. Übersetzt bedeutet das: Software in ausreichender Funktionalität + Qualität + Wandelbarkeit herzustellen, das zählt. Nicht die Einhaltung eines Budgets.
Das Budget gibt nur vor, wie lange man das tun kann, aber nicht, wie weit man dabei kommt. Genauso gibt das Baseball-Spielfeld vor, wie weit man dem Ball folgen kann - ohne Garantie, dass man ihn innerhalb des Spielfeldes auch fängt.
Das einzig Gewisse ist also der Rahmen, in dem man durch ständiges Beobachten und Anpassen versuchen kann, dem Erfolg so nahe wie möglich zu kommen.
So lautet auch der Standpunkt der Agilität. Eigentlich. Wenn man sie denn mutig genug lebt. Dann verzichtet man nämlich darauf, Story Point Schätzungen in Termine zu übersetzen.
Die Beobachtung-Anpassung-Runden heißen in der Agilität Iterationen. In Scrum sind es die Sprints. Beim Spinning allerdings dauern Sie nur wenige Stunden oder maximal vom Morgen des einen Tages bis zum Abend des nächsten.
Nach jeder Iteration kann der Kurs geändert werden, weil in Inkrementen vorgegangen wird. Jede Iteration produziert etwas mehr Nutzen oder zumindest Gewissheit, was das Verständnis der Anforderungen angeht.
Leider ist diese Strategie noch nicht bei Management und Kunde angekommen. Da mögen die Teams noch so sehr PO-Feedback getrieben dem Ball hinterherlaufen - draußen glaubt man weiterhin daran, dass der Fang berechnet werden könne.
Strategie 2: Limits
Ein Bieter hat in zwei Fällen Erfolg bei einer Auktion. Wenn er ein Auktionsstück zu einem guten Preis ersteigert - aber auch, wenn er nichts ersteigert, weil er seinen Ausgabewillen begrenzt hat.
Noch mehr gilt das an der Börse. Aufträge sollten dort immer mit Limits versehen werden. Ein Stop Buy Limit verhindert, zu teuer zu kaufen, in dem man zu lange kauft. Ein Stop Loss Limit verhindert, (zu viel) Verlust zu machen, in dem man zu lange auf seinen Aktien sitzt.
Stop Loss kann dabei in zwei Richtungen interpretiert werden. Naheliegend ist, dass es greift, wenn der Kurs unter eine gewisse Marke fällt. Aber man kann es auch so sehen, dass es greift, wenn der Kurs über eine gewisse Marke steigt. Dann wäre es sozusagen ein Start Reaping Limit, bei dem man automatisch verkauft. Ganz unemotional. Denn es gilt ja: Nicht realisierte Gewinne sind keine Gewinne.
Limits sind im Umgang mit der Softwareentwicklung unbekannt, wie es mir scheint. Wie denn auch: Wo nicht beobachtet wird, kann man auch nicht die Überschreitung von Limits beobachten.
Außerdem braucht man für Limits eine Vorstellung von Wert. Da der für Anforderungen unterschiedlicher Größenordnungen notorisch nicht bestimmt wird, kann man weder ein Limit definieren, noch den aktuellen Wert.
Die Gesamtvorstellung einer Software mag man mit einem Wert belegen. Deshalb kann man dann das eine Angebot zu teuer finden und beim anderen den Zuschlag geben.
Anschließend wird vor allem über Aufwand gesprochen. Der muss auf die eine oder andere Weise für Vergleiche, aber noch besser für Voraussagen geschätzt (gemeint ist: berechnet) werden. Ihm wird jedoch nur äußerst selten ein objektivierter Nutzen oder Wert gegenübergestellt.
Deshalb sind Priorisierungen vor allem eine Sache des Gefühls. Denn ohne objektiven, wenn auch geschätzten Aufwänden genauso objektiven Wert gegenüberzustellen, kann sich keine nachvollziehbare Priorität ergeben.
Dieses Gefühl hat ein Product Owner oder es wird lautstark vom Support oder dem Management vermittelt. So rennt denn ein Team solange Gefühlen hinterher, bis sich andere Gefühle einstellen. Systematisch ist das nicht. Budgetschonend auch nicht.
Sobald man jedoch den Wert umzusetzender Anforderungen in einiger Feinheit bestimmen kann, ist es möglich, Limits zu definieren.
Und wenn man Limits hat, dann kann man aufhören, wenn genügend Wert für den Moment angesammelt ist. Man kann dann wieder ausliefern. Nicht nur festgelegt alle Jahre oder Quartale, sondern eben jederzeit, wenn die Wertsteigerung aus Sicht des Kunden, des Vertriebs oder sonst eines Stakeholders attraktiv ist.
Für die Softwareentwicklung gilt: Nicht ausgelieferte Inkremente generieren keinen Umsatz.
Außerdem gilt, dass alles, was umgesetzt und sogar ausgeliefert wurde, aber nicht genutzt wird, nichts nützt und deshalb Verschwendung ist.
Solche Verschwendung lässt sich nicht grundsätzlich vermeiden. So wie sich bei einer Auktion nicht vermeiden lässt, etwas zu teuer zu kaufen oder nur knapp vor dem Zuschlagspreis ausgestiegen zu sein. Ebenso lässt sich an der Börse nicht vermeiden, den optimalen Kurspreis für Kauf oder Verkauf zu verpassen.
Aber je breiter das Risiko gestreut wird, desto geringer der Verlust. Je kleiner die Inkremente, je häufiger das Feedback, desto eher ist es möglich, Verschwendung einzudämmen.
Auch hier hilft wieder der Ansatz des Spinning. Dort werden Anforderungen so dünn geschnitten, dass Feedback innerhalb von 1–2 Tagen Verschwendung minimiert. Keine Anforderungen “in der Urfassung” muss mehr fertiggestellt werden. Vielmehr kann man nach jedem Inkrement wieder evaluieren, ob es lohnt, weiter zu investieren (nachkaufen) - oder doch besser auszusteigen (verkaufen).
Die Evaluation kann z.B. nach dem Verfahren Weighted-Shortest-Job-First (WSJF) erfolgen. Dafür ist es nicht einmal erforderlich, absolute Beträge für Wert und Aufwand zu kennen. Anforderungsgewichte berechnet aus Anforderungsnutzen (Wert) und Realisierungsaufwand dienen nicht der Vorhersage, sondern nur dem Vergleich.
Die sich aus der Gewichtung ergebende Reihenfolge (Priorität) von Anforderungen kann sich ständig ändern. Gearbeitet wird immer nur an dem, was schon/noch genügend Wert pro Aufwand verspricht.
Das bedeutet: “Absolute” Fertigstellung tritt in den Hintergrund. Nicht eine (größere) Anforderung komplett fertigstellen, sondern mehrere parallel vorantreiben. Am Ende reißt nicht ein Feature eine Software heraus, sondern der Mix genügend guter Features.
Strategie 3: Puffer aufbauen
Das Baseballspiel lehrt, “am Ball bleiben” und den Entwicklungskurs ständig korrigieren. Die Börse lehrt, Werte bewusst zuordnen, Grenzen setzen und das Risiko zu streuen.
Und der Umgang mit dem Wetter lehrt: man muss Reserven haben. Wer die Speicher voll mit Gepökeltem, Eingemachtem, Getrocknetem und auch noch Brennholz hat, muss sich um eine schlechte Ernte oder einen langen Winter nicht so viele Sorgen machen.
Die Entsprechung dafür in der Softwareentwicklung ist aber nicht Zeit, wie man meinen könnte. Zeitpuffer sind für mich keine, weil sie schon bei der Planung als ausgeschöpft angesehen werden. Nein, wir brauchen andere Puffer. Puffer, die Softwareherstellung und die Softwarenutzung bzw. den Vertrieb entkoppeln.
Wie bei Getreidespeichern sollte der Puffer dabei aus dem bestehen, was die eine Seite (Natur) produziert und die andere Seite (Mensch) konsumiert.
Zeit ist das nicht. Weder produziert die Softwareentwicklung Zeit, noch konsumieren Vertrieb oder Kunden Zeit. Das Gut, um das es geht, sind vielmehr Softwaremerkmale (Features).
Angesichts des unvorhersagbaren Softwareentwicklungswetters brauchen wir Puffer an umgesetzten Anforderungen. Das halte ich für ein notwendiges Umdenken. Kunden/Management (oder auch der Vertrieb) müssen sich Puffer an schon Realisiertem anlegen.
Statt die Softwareentwicklung zu einer Vorhersage zu nötigen, wann ein bestimmter Wert geschaffen sein wird, sollte geschaffener Wert “eingelagert” werden, statt ihn immer sofort zu konsumieren.
“Live in the now” muss das Motto werden. Es geht um das, was sicher “im Sack” ist. Das kann man bewerben, vorführen, verkaufen. Alles andere sind “Wunschgewinne” - die können eintreten oder nicht. Und wer weiß, wann?
(Im Bild hat das Entwicklerteam Releases in den Puffer “eingelagert”. Aus dem entnehmen Interessenten, wenn Sie es brauchen, also entsprechend einem Vorlauf für ihre Maßnahmen. Sie haben keinen Einfluss auf die Einlagerung zu einem absoluten Termin. Sie können nur mit dem arbeiten, was sie vorfinden. Die Entwicklung zieht unterdessen weiter. Allerdings: Prioritäten, also relative Fertigstellungstermine, dürfen der Entwicklung vorgegeben werden.)
Ob das nächste Jahr eine Spitzenernte abwerfen wird? Niemand weiß das. Ob die Aktie bis Monatsende den Wunschkurs hat? Niemand weiß das.
Was man weiß, das ist, was jetzt da ist. Damit lässt sich arbeiten. Ganz verlässlich.
Aus dem Strom der ständig geschaffenen Werte sollte also ein Teil in einen Puffer geleitet werden. Der andere Teil steht zum sofortigen Konsum zur Verfügung.
Geldgewinne spart man oder reinvestiert. Nicht alles, aber einen Teil. Ernteertrage lagert man zum Teil ein und verzehrt den Rest.
Genauso sollte mit dem Strom an Werten in der Softwareentwicklung umgegangen werden.
Konsequenzen für Kunde/Management
Wer im Wahn lebt, also in Verkennung der Realität, kann nicht auf Dauer erfolgreich sein. Oder etwas attraktiver formuliert: Umso näher Weltbild und damit Handeln der Realität sind, desto größer der Erfolg.
Seefahrt, Medizin, Maschinenbau sind erfolgreicher geworden, indem sie sich der Realität angenähert haben. Weniger Wunschvorstellung und Glaubenssatz, dafür mehr Fakten.
Das scheint mir für die Softwareentwicklung auch ein Erfolgsrezept. Die Agilität hat in dieser Hinsicht eine Wende eingeleitet. Angekommen ist die bei Kunde und Management jedoch noch nicht. Es herrschen noch Wunschvorstellungen, Missverständnisse und Ignoranz bzw. Naivität vor.
Um das noch besser zu vermitteln, dürfen wir keine Gelegenheit verpassen, um die Idee eines realitätsnäheren Weltbildes zu verbreiten.
In dem müssen Nachhaltigkeit und Unvorhersagbarkeit verbunden werden.
Dafür scheinen mir gerade der Umgang mit dem Wetter und die Aktienbörse gute Beispiele.
In beiden Sphären sind die Veränderungen nicht vorhersagbar - und dennoch ist nachhaltiges Handeln wichtig. Sonst ist man bald tot oder pleite.
Erste Konsequenz für Kunde/Management: das Weltbild anpassen. Get real! Now!
Zweite Konsequenz: Abschied von der “fire and forget” Mentalität. Anforderungen laden, Ziel anpeilen, abfeuern - und dann auf den Einschlag warten… Das funktioniert nicht. Der PO weiß das schon. Eigentlich. Bis auf manche. Kunde, Management, Vertrieb, Marketing allerdings, die müssen das noch lernen. Vielerorts.
Dritte Konsequenz: Abschied von der “Ich will Alles! Und das sofort!” Mentalität. Denn ob Alles machbar ist innerhalb des Budgets oder ob Alles überhaupt gemacht werden sollte… Wer wollte das mit Sicherheit sagen? Die Verschwendung lauert überall. Also muss eine viel bewusstere Wertvorstellung entwickelt werden. Das bedeutet, mehr Werte bestimmen, doch das bedeutet auch, Werten Grenzen setzen. Denn ohne Grenzen regiert Maßlosigkeit.
Vierte Konsequenz: Abschied von der Zukunftsfixierung. Der Erfolg stellt sich nicht durch Wahrsagerei ein. Die Glaskugel der Softwareentwicklung ist genauso trüb wie die einer Zigeunerin auf dem Jahrmarkt. Wer viel fragt, bekommt viele Antworten, die er hören will - die deshalb aber nicht etwas mit der zukünftigen Realität zu tun haben.
Das Glück liegt in der Gegenwart, in dem, was ist. Der Spatz in der Hand, das ist Erfolg. Die Taube auf dem Dach fliegt weg, bis man dorthin geklettert ist.
Kunde, Management, Vertrieb, Marketing sollten lernen, mit dem zu arbeiten, was real existierend ist. Alles andere sind Wunschvorstellungen einer märchenhaften Zukunft.
