Montag, 21. Juli 2014

Zeitmanagement für Softwareentwickler

Warum kommt Clean Code oft gar nicht oder nur mit Mühe im Tagesgeschäft von Entwicklerteams an? Warum fühlen sich Entwickler oft überlastet?

Abgesehen von fachlichen Problemen liegt das, so scheint mir, häufig an einer gut gemeinten, aber unsystematischen Arbeitsweise. Selbst wo man schon an Agilität geschnuppert hat, ist das persönliche Zeitmanagement weithin unterentwickelt.

Deshalb hatte ich vor einiger Zeit die Idee, für diesen Aspekt der Entwicklerarbeit ein Angebot mit Prinzipien und Praktiken zu formulieren. Prinzipien und Praktiken für das Zeitmanagement für Softwareentwickler.

Allgemeine Angebote zum Thema Zeitmanagement gibt es natürlich viele. Doch wenn man die wahrnimmt, dann ist der Transferaufwand in die eigene Arbeitspraxis hoch. Außerdem ist die Softwareentwicklung in einigen Aspekten recht eigen. Wenn allgemeines Zeitmanagement z.B. über Priorisierung spricht - Stichwort: Eisenhower-Prinzip - dann ist das nicht nur für Studenten und Sachbearbeiter relevant, sondern auch für Softwareentwickler. Doch es bleibt eine Lücke. Speziell für die Softwareentwicklung lässt sich eben mehr zur Priorisierung sagen.

Diese Lücke zu schließen, war mein Anliegen. Ich wollte das Thema Zeitmanagement für Softwareentwickler zugänglicher, leichter anwendbar machen.

Nicht unerheblich an dieser Idee beteiligt war allerdings meine Partnerin Andrea “Mrs. Paperless” Kaden. Denn sie gab schon Zeitmanagement-Seminar der allgemeinen Art im Rahmen ihrer Arbeit als Professional Organizer. So war meine Idee denn auch, das Angebot für die Softwareentwicklung als Komplementärtraining zu formulieren.

Das haben wir dann getan und im Juli 2014 das erste Seminar gehalten. Das Ergebnis sehen Sie hier :-)

image

Ja, tatsächlich war dieser power nap eines Teilnehmers in der Mittagspause ein Ergebnis des Seminars. Nachdem wir einen Tag an Zielen, Prinzipien und Praktiken gearbeitet hatten, war für ihn am zweiten Tag klar, dass es für ihn zu einem professionellen Umgang mit seinen Kräften und seiner Zeit gehört, zwischendurch kurz mit einem power nap aufzutanken.

Ein systematischer Umgang mit Zeit lässt sich aber natürlich nicht im Schlaf erlernen ;-) Wir haben zwei Tage lang einigen Stoff “gepaukt”. Hier das Kanban-Brett unserer Themen:

image

Neben praktischen Übungen war uns dabei wichtig, Denkprozesse anzustoßen. Das Zeitmanagement kommt ja nicht einfach in Ordnung, indem man z.B. plötzlich seine Arbeit mit der Pomodoro Technique taktet oder Nein sagen geübt hat. Das sind nur Werkzeuge, die man zu einem Zweck im Rahmen von Prinzipien und “Naturgesetzen” einsetzen kann. Was aber ist der Zweck? Worum geht es eigentlich im persönlichen Leben? Worum geht es bei der Arbeit wirklich? Warum sollte wofür welche Zeit überhaupt aufgewandt werden? Und wie beeinflusst die Softwareentwicklung als Arbeitsrahmen die Antworten auf diese Fragen?

Solche Fragen galt es auch zu diskutieren. Und gerade da hat es sich als besonders hilfreich erwiesen, dass Andrea und ich einen unterschiedlichen Hintergrund haben. Ihrer ist die allgemeine Arbeitsorganisation, bei ihr geht es um Prozesse und “das Menschliche”; meiner ist die Technik, die konkrete Organisation der Softwareproduktion, die Entwickler- und Stakeholder-Sicht.

Das Seminar war für uns inhaltlich ein Experiment und in der Zusammenarbeit. Beides hat gut funktioniert, wie wir finden. Es hat uns Spaß gemacht und den Teilnehmern auch, wie uns das Feedback zeigt.

imageIch freue mich, dass meine Idee aufgegangen ist. Also machen wir weiter. Im November 2014 sind wir wieder in Hamburg am Start, im Januar 2015 in München. Genaueres finden Sie hier.

Überlegen Sie einmal, ob Sie mit dabei sein wollen. Wir versprechen zwei erhellende und ungewöhnliche Tage inklusive online Nachlese. Denn wir sind ja daran interessiert zu hören, wie der Transfer in die Praxis gelingt.

Wer will schon immer nur Technologieseminare besuchen? ;-) Systematisches Zeitmanagement ist auch eine coole Sache - und die Grundlage für technische Erfolge.

Wir freuen uns auf Sie!

image

Andrea und Ralf

Mittwoch, 9. Juli 2014

Erfolgreich in der Unvorhersagbarkeit, oder: Softwareglück ohne Schätzungen

imageBahnfahren 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.[1]

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.[2]

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.

imageWelchen 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

imageBeim 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.[3]

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.[4]

Beispiel 5: Aktienbörse

imageNach 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.

imageErfolg 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

imageEin 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.

imageUnd 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?

image

(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.


  1. Wohlgemerkt geht es mir nicht nur um die sichtbaren Aufwände. Es gibt immer wieder Vorhersagen, die sich äußerlich mit nur wenig Verzug wahr machen lassen. Die dem unbewaffneten Auge sichtbaren Budgets werden kaum überschritten. Ein unbekannt hoher Preis wird dann jedoch woanders bezahlt: bei der Motivation und der inneren Codequalität. Wer Termine durchprügelt mit Überstunden und/oder durch Vernachlässigung von Clean Code Development, der zahlt später. Auf die eine oder andere Weise. Das muss dem Gesamtaufwand zugeschlagen werden. Nur tut das niemand. Es ist so schwer zu fassen. Außerdem ist das dann womöglich das Problem von jemandem anderes. Womit wir wieder bei der Deutschen Bahn wären. So funktioniert nachhaltiges oder wirklich kundenorientiertes Denken nicht. Wer nur an jetzt und sich denkt, arbeitet auf Kosten der Zukunftsfähigkeit von Projekt/Produkt oder gar Unternehmen.

  2. Bitte verstehen Sie mich richtig: Es gibt kaum etwas, was ich mir sehnlicher für die Softwareentwicklung wünsche, als dass sie vorhersagbarer würde. Ehrlich. Der Gewinn an Vertrauen und Effizienz wäre unschätzbar [sic!]. Aber, ach, ich habe es aufgegeben, es zu versuchen und darauf zu warten. Mag es einem zukünftigen goldenen Zeitalter des Software Engineering vorbehalten sein, solche Verlässlichkeit herzustellen.

  3. Bei einem Kanonenschuss will man natürlich das Gegenteil erreichen. Der soll genau in ein anvisiertes Ziel treffen. Letztlich findet man diese Vorhersagbarkeit jedoch limitierend. Immer mehr interessante Ziele bewegen sich. Deshalb ist ein Lenkgeschoss die überlegene Waffe. Und heutige Drohnen gehen noch einen Schritt weiter. Das Militär hat also viel investiert, um stetig besser mit der unvorhersagbaren Realität der Bewegungen seiner Gegner umzugehen.

  4. Wie bei der Softwareentwicklung werden hier Vorhersagen (also Vorgaben) oft zwanghaft erreicht, indem an weniger sichtbarer Stelle Kosten verursacht werden. Mitarbeiterfluktuation, Burn-out, Dienst nach Vorschrift, sinkende Kommunikationsverlässlichkeit, Papierberge uvm. können Symptome dafür sein, dass man mit dem falschen Weltbild, also im Wahn agiert - und sich deshalb an der Wand die Nase blutig stößt.

Samstag, 28. Juni 2014

Regelmäßiges Lernen - Mein Commitment

imageGute Softwareentwicklung gibt es nicht ohne regelmäßiges Lernen. Technologisch bleibt man sonst immer weiter zurück. Aber auch neue Methoden können sonst nicht wirklich eingeführt werden.

TDD, Clean Code, NoSql, Reactive Programming, F# oder was sich sonst noch nützlich auf die Softwareproduktion auswirken könnte, kann man nicht im Kopf anschalten. Dafür braucht es vielmehr Zeit, um zu lesen, zu denken, zu üben, bevor man es in den Alltag der Produktionscodeentwicklung übernehmen kann.

Ich glaube, 20% Lernzeit während (!) der Arbeitszeit wären gut. Mehr als 10% scheinen in den allermeisten Unternehmen jedoch nicht machbar. Dann also 10% - aber nicht weniger!

Diese 10% können aus autodidaktischem Lernen für sich, Lernen in der Gruppe und Teilnahme an Kursen bestehen. Einer meiner Kunden stellt seinen Entwicklern z.B. 150 Stunden pro Jahr für das Lernen zur Verfügung. Das sind ca. 10% der Arbeitszeit, wenn ich mal 200 Arbeitstage à 8 Stunden rechne. Allerdings verplant man diese 150 Stunden in Form von Seminarteilnahmen. Das ist gut gemeint - aber kontraproduktiv. Denn wann soll denn das, was man im Seminar lernt, geübt werden? Seminarteilnehmer können ja nicht nach 2–3 Tagen Seminar, was als Lernstoff vermittelt wurde. Dafür ist unser Metier zu kompliziert. Unser Lernstoff muss geübt werden. Und nochmal geübt werden. Bevor man ihn halbwegs sicher auf Produktionscode anwenden kann.

Kein Musiker probt auf der Bühne. Kein Chirurg lernt neue Techniken am gewöhnlichen Krankenhauspatienten. So sollte es auch bei der Softwareentwicklung sein. Es braucht für Neues geschützte Übungszeit. Regelmäßig.

Das fällt schwer. Das höre ich immer wieder. Es passt einfach nicht zum vorherrschenden Mindset der 110% Auslastung aller Mitarbeiter mit Tagesgeschäft. Doch es hilft nichts. Wer nachhaltig “wirtschaften” will, der muss dafür Zeit zur Verfügung stellen. Und nicht nur fürs Lernen.

Nun mag man sagen, “Ralf, du hast gut reden. Als Berater/Trainer ist dein Leben viel einfacher. Du kannst dir Zeit nehmen, wie du willst.”

Aber das stimmt nicht. Auch ich habe ja mein Tagesgeschäft. Klar, das sieht anders aus als das eines Entwicklungsteams. Von den Prioritäten her fühle ich mich da allerdings genauso eingeengt. Für einen Entwickler mag es aussehen, als würde ich ständig lernen. Ist nicht ein Buch über Softwareentwicklung lesen, einen Artikel schreiben, ein Seminar vorbereiten Lernen?

Das stimmt in Bezug auf die Softwareentwicklung. Es stimmt aber nicht in Bezug auf die Vermittlung von Softwareentwicklung. Was für Entwickler Lernen ist, ist für mich Tagesgeschäft.

Das verwechsle ich allerdings auch oft. Deshalb muss ich einsehen, dass selbst ich, nicht genug lerne. Ich lebe sozusagen selbst noch nicht das, was ich predige. Das ist Mist. So kann ich meine Überzeugung nicht authentisch vermitteln. I need to put my money where my mouth is :-)

Das Lernversprechen

imageDas will ich, nein, das muss ich nun ändern. Da geht kein Weg dran vorbei, wenn ich als One Man Think Tank weiterhin glaubwürdig sein will. Also lege ich hier ein Versprechen ab.

Ich verspreche, dass ich fortan mindestens 10% meiner Arbeitszeit[1] dem Lernen widmen werde.

Dieses Lernen kann im Besuch von Vorträgen oder Seminaren bestehen, das kann aber auch Lesen und Üben daheim sein.

Da mein Job die Vermittlung von Softwareentwicklungsmethodiken ist, können Lerninhalte natürlich nicht Softwareentwicklungsmethodien sein. Mein Lernen muss vielmehr auf der Meta-Ebene bzw. im Allgemeineren stattfinden.

Oder ich könnte auch sagen: Ich muss beim Lernen dasselbe Gefühl haben, wie meine Kunden. Einerseits muss ich es wollen, andererseits muss es mir aber auch wehtun. Auch ich muss beim Lernen spüren, dass ich eigentlich etwas anderes dringender tun müsste.

Aktivitäten auf die das für mich zutrifft, sind z.B. eine Sprache lernen, Meditation, die Beschäftigung mit “Sachthemen”.

Für Sie mögen das Freizeitaktivitäten sein, für mich gehört das jedoch im weiteren Sinn zum Job:

  • Mein Job ist es, mit Sprache umzugehen, sowohl mit natürlicher wie mit formaler. Auf die eine oder andere Weise. Deshalb ist es wichtig, dass ich meinen “Sprachmuskel” fit halte. Jede Sprache, die ich lerne oder deren Kenntnis ich verfeinere, macht es mir leichter, zu kommunizieren, was ich vermitteln will.
  • Mein Job ist es, mich vielen Einflüssen auszusetzen und oft zu reisen. Innere Ruhe und Gelassenheit sind dann wichtig, um in dem Rahmen eine balancierte und authentische Botschaft zu vermitteln. Medidation und die Beschäftigung mit spirituellen Themen hilft, diesen Zustand herzustellen.
  • Die Softwareentwicklung profitiert davon, sich durch andere Disziplinen oder sogar ganz allgemein “durch das Leben” informieren zu lassen. Bauarchitektur, Biologie, Physik, Soziologie usw. halten viel bereit, von dem wir lernen können. Darüber hinaus kann meine didaktische und methodische Praxis als Trainer nur davon profitieren, wenn ich mich in anderen Bereichen umschaue (z.B. systemische Analyse, Lernpsychologie). Ich muss also “Sachthemen” erkunden - und das durchaus, ohne immer genau zu wissen, wann ich welches wie anwenden kann. Sozusagen Grundlagenforschung statt angewandte Forschung.

Natürlich habe ich in der Vergangenheit diese Aktivitäten schon betrieben - nur nicht systematisch. Da war es Freizeit und ich konnte jederzeit damit aufhören. Nun will ich das ändern. Darin besteht mein Commitment.

Ich verspreche, jede Woche mindestens 4 Stunden wie folgt ins Lernen und Üben zu investieren:

  1. Sprachenlernen: Ich widme jeden Arbeitstag 20–30 Minuten dem Lernen einer Sprache. Derzeit ist das Französisch. 5x20=100 Minuten, d.h. 1,66 Stunden.
  2. Meditieren: Ich mediere jeden Tag 10–15 Minuten. 7x10=70 Minuten, d.h. 1,16 Stunden.
  3. Sachthemen: Ich lese jeden Arbeitstag 15–30 Minuten über ein Sachthema. 5x15=75 Minuten, d.h. 1,25 Stunden. Dazu mögen über das Jahr verteilt Konferenzen oder Seminare kommen, wo ich mich en bloc länger mit einem Thema befasse. In diesem Jahr waren das z.B. schon eine Konferenz zum Thema Unternehmertum und ein Seminar über Prozessmanagement.

Das sind Aktivitäten, von denen ich weiß, dass sie für mich wichtig sind. Ich muss hier regelmäßig am Ball bleiben. Dennoch fällt es mir schwer, sie auch ständig während des Tagesgeschäftes auf dem Zettel zu haben.

Jeden (Arbeits)Tag 15–30 Minuten mit so einer Aktivität verbringen, führt das denn zu Fortschritt? Ja, das glaube ich ganz sicher. Nicht kurzfristig, aber mittel- und langfristig. Es gibt ja auch keine Rüstzeiten und spezieller “mental state” muss auch nicht aufrechterhalten werden. Außerdem steht es mir jederzeit frei, mehr Zeit einer dieser Aktivitäten einzuräumen.

Soviel zu meinem Versprechen. Und wie dokumentiere ich, dass ich es einhalte?

Ich benutze die App Lift, um die Durchführung zu protokollieren.

imageimage

imageimage

Nach Abschluss einer Aktivität hake ich sie in der App ab. Das an sich ist schon ein kleiner Erfolg. Noch motivierender ist es jedoch, in der Übersicht zu sehen, wie kontinuierlich ist dabeigeblieben bin.

Wer mag, kann meinen Fortschritt verfolgen. Ich habe die lift-Aktivitäten öffentlich gemacht:

Spätestens in 3 Monaten berichte ich dann hier, wie es mir mit der Erfüllung meines eigenen Anspruchs ergangen ist. (Dass ich unterwegs nicht mogle, müssen Sie mir glauben. Ich mache also nur einen lift-Haken, wenn ich wirklich eine Aktivität durchgeführt habe.)

Und nun: Ich bin genauso gespannt wie Sie :-)

Let the learning begin…


  1. Meine Arbeitszeit ist nicht so klar abgezirkelt wie die eines Angestellten. Als Freiberufler bin ich sehr frei, was Zeit und Datuer meiner Arbeit angeht. Außerdem verschwimmen Arbeit und Freizeit bei mir. Mein Versprechen bezieht sich der Einfachheit halber auf eine 40 Stunden Woche. Ich verspreche also 4 Stunden Lernen pro Woche.

Montag, 9. Juni 2014

Die wichtigste Rolle in der Softwareentwicklung

Natürlich ist Softwareentwicklung eine Tätigkeit, an der viele beteiligt sind. Alle Rollen sind wichtig.

Und doch… ich glaube, es gibt eine Rolle, die ist wichtiger als andere. Sozusagen erste unter gleichen. Das ist die Rolle des Product Owner (PO).

Nicht die Programmierer sind die Wichtigsten, nicht die Qualitätssicherer, sondern der PO. Das stürzt hoffentlich niemanden in Ärger oder Verzweiflung ;-)

Wichtiger ist der PO, weil er die Softwareentwicklung klammert. Er hat zwei Hüte auf. Er kippt einerseits in den Produktionsprozess vorne Anforderungen als Input hinein. Andererseits nimmt er am Ende den Output entgegen und gibt dazu Feedback. Er ist Sender und Empfänger, Quelle und Senke.

imageDamit ist er für den Kurs der Softwareentwicklung verantwortlich. Er ist wie ein Kapitän. Der Steuermann mag lenken, der Ausguck mag vorausschauen, der Maschinist mag für Vortrieb sorgen; und alle entscheiden dabei situativ.

Doch allein der Kapitän entscheidet strategisch, d.h. im Hinblick auf das zu erreichende Ziel. Er gibt den Rahmen für alle anderen vor.

Genauso der PO. Er hat als Ziel den Nutzen für den Anwender im Auge. Dafür soll Software mit bestimmten Eigenschaften bereitgestellt werden. Wie, das entscheidet der PO. Er ist Stellvertreter des Kunden auf dem Projektschiff, so wie ein Kapitän Stellvertreter des Reeders auf einem Handelsschiff ist.

Selbst der Softwarearchitekt ist dem PO untergeordnet. Architektonische Entscheidungen müssen sich immer im Rahmen dessen bewegen, was der PO an Anforderungen stellt.

Die wichtigste Aufgabe des Product Owner

Besonders schwierig macht es die Aufgabe des PO, dass er als Klammer sowohl am Anfang wie am Ende des Produktionsprozesses steht.

Deshalb möchte ich betonen, was die wichtigste Aufgabe des PO ist. Welchen Hut sollte er vor allem aufhaben?

Wikipedia widmet dem PO 14 Sätze. Davon ist allerdings nur ein Teilsatz der aus meiner Sicht wichtigsten Aufgabe des PO gewidmet: Er trifft “die Entscheidung darüber, ob die vom Entwicklungsteam am Ende jedes Sprints gelieferte Funktionalität akzeptabel ist.”

Das vor allem muss der PO tun: akzeptieren. Er muss Lieferungen von Programmierung und QS prüfen und dazu Feedback geben. Im besten Fall akzeptiert er das Gelieferte, im schlechteren Fall verweigert er die Weitergabe und muss Nachbesserungen anweisen.

Am wichtigsten ist der PO also in seiner Funktion als Senke, als schließende Klammer.

Die Literatur hingegen betont vor allem seine Funktion als Quelle, als öffnende Klammer. Da wird von Backlog, Priorisierung, User Stories, Story Points usw. gesprochen; das alles gehört zum PO als Sender von Aufträgen an das Restteam.

Natürlich, es geht nicht ohne klare Aufträge. Anforderungsdefinition ist eine rechte Kunst. Da braucht es auch viel Dialog zwischen Restteam und PO.

Aber die Anforderungsdefinition ist nicht die wichtigste Aufgabe des PO, weil sie nur eine Folge der wichtigsten Aufgabe ist. Der PO will nicht beauftragen, sondern in Empfang nehmen. Nur weil er in Empfang nehmen will, muss er wohl oder übel beauftragen. Aber je weniger Aufwand er darauf verwenden muss, desto besser.

Das Abnehmen, das Akzeptieren ist aber nicht nur für den PO bzw. den weiter downstream gelagerten Anwender/Kunden wichtig, sondern auch für das Restteam.

Indem der PO nämlich zuallererst sich auf das Akzeptieren konzentriert, stiftet er für das Restteam Sinn. Dadurch, dass er geradezu sehnsüchtig auf die nächste abzunehmende Veränderung wartet, weiß das Restteam, wer es braucht, wofür es sich anstrengt. Der PO als schließende Klammer stellt ein Ziel dar, auf das sich jeder ausrichten kann. Kohärenz wird geschaffen. Insofern ist der PO sogar als leader anzusehen.

Folgen eines Missverständnisses

Leider wird die Rolle des PO meist missverstanden. Entweder wird er nicht als die wichtigste Rolle angesehen. Entwickler scheinen am wichtigsten, immerhin produzieren die das “Objekt der Begierde” für den Kunden. So schwer kann das doch auch nicht sein, oder? Am besten wissen es womöglich sogar die Entwickler, was gebaut werden sollte.

Das Resultat ist ein insgesamt schwacher PO. Er ist halbherzig bei der Sache - wahrscheinlich, weil er sich erstens diese Aufgabe nicht gewünscht hat und zweitens auch noch eine Menge anderer Dinge zu tun hat.

Ein schwacher PO - oder noch schlimmer: ein fehlender - führt dann zu schlechtem Input für das Restteam. Nach der Gleichung garbage in = garbage out führt das wiederum zu schlechtem Output. Und der wiederum führt zu Nachbesserungen. Das verringert die Kapazität des Restteams für neue Features, das erhöht die Verschwendung durch Produktion von Unnötigem und das nagt am Vertrauen des Kunden, weil der nur unzuverlässig und mit suboptimaler Qualität beliefert wird. Und zu allem Überfluss steigen noch die Supportkosten und es sinkt die Motivation.

Oder, selbst wenn der PO als wichtig angesehen wird, dann im üblichen Sinn: als sprudelnder Quell von Anforderungen. Er nimmt dann seine Aufgabe ernst und produziert User Stories, dass es nur so eine Freude ist. Er spricht mit dem Support, er spricht mit dem Kunden, er ist da für Fragen vom Restteam. Das Backlog wächst, die Entwicklung hat zu tun. Die Klammer ist geöffnet.

Doch am Ende… da fehlt es an Zugkraft. Der PO beauftragt stark - und zieht am Ergebnis zu schwach. Er hat wenig Erwartung, wann etwas geliefert werden soll. Und wenn, dann lässt er sich einladen zu einer Präsentation dessen, was das Team meint, präsentieren zu können. Im Zweifelsfall hat er womöglich sogar nicht einmal genügend Entscheidungskompetenz, um Abweichungen “vom Plan” akzeptieren oder ablehnen zu können.

Aus womöglich ordentlichem Input wird auf diese Weise Output von ungewisser Qualität. Da der PO nicht maximal daran interessiert zieht, gibt es endgültiges (!) Feedback oft erst Tage oder Wochen nach Fertigstellung.

Das führt zu Ungewissheit, Motivationsschwund, Verschwendung. Die Zuverlässigkeit des Restteams wird auf diese Weise auch nicht erhöht.

Die Qualität des Teams bestehend aus PO + Restteam(Programmierung, QS) steht und fällt also mit dem PO. Ein schwacher PO wird genauso vom Restteam erkannt wie ein schwacher Lehrer oder schwache Eltern. Der mag dann nett sein - aber systematisch und verlässlich für den Kunden muss man dann nicht produzieren.

Fazit

Softwareentwicklung ist kein Ponyhof. Es ist ein hartes Business, in dem man umso besser besteht, je klarer die Richtung ist. Einer, der Richtung vorgibt, ist der PO. Das tut er aber nicht durch Backlog-Einträge, sondern durch seinen unermüdlichen Willen, produziertes Abzunehmen.

Das hat auch einen ökonomischen Grund: Statt neue Aufträge in das Restteam zu stopfen, sollten angefangene Aufträge herausgezogen werden. Es ist sonst unklar, ob der Arbeitseinsatz gelohnt hat. Nur kann auch Wert für den Kunden entstehen. Den freut ja nicht, wenn das Restteam busy ist, sondern nur, wenn er etwas brauchbares in die Hand bekommt.

Ich habe hier den Begriff PO gebraucht, weil er sich für diese Rolle eingebürgert hat. Ich sehe die aber nicht an Scrum geknüpft. Und ich vermute sogar, dass rundum agiles Vorgehen weniger wichtig ist als ein starker PO, der weiß, dass die Abnahme seine vornehmste Aufgabe ist.

Ein klares Ziel und klares, schnelles Feedback – das ist das Geheimnis erfolgreicher Softwareentwicklung. Das ist oft der Fall am Anfang eines Softwareprojektes/-produktes. Daran erinnern sich alle immer gern zurück. Mindestens diesen Zustand aufrecht zu erhalten, sollte das Ziel jedes Projekt-/Produktmanagements sein.

Wenn ich Softwareprojekte/-produkte gesehen habe, die im Verhältnis zu ihrer Codesauberkeit gut im Fluss waren, dann hat das immer an starken POs gelegen.

Oder umgekehrt: Wo der PO schwach oder gar abwesend war, hat es immer massiv gehakt - auch wenn das Restteam motviert und kompetent war.

Ein PO wird der Wichtigkeit seiner Rolle also am besten gerecht, wenn er stets zuerst schaut, was es abzunehmen gibt. Das erfragt er aber nicht beim Team, sondern hat eine genaue Erwartung dazu. Denn darüber hat er schon vorher mit dem Team verhandelt - und das nicht vor Wochen, sondern gestern.

Jeden Tag etwas abnehmen - so sollte der Rhythmus des PO sein.

Und nur, wenn dem Restteam die Aufträge ausgehen, denkt er daran, was er als nächstes “einkippen” sollte.

Im Stil des agilen Manifests könnte ich so formulieren: acceptance over specification.

Dienstag, 3. Juni 2014

Klein ist ökonomisch

Es kommt auf die Größe an – zumindest bei der Wartbarkeit (oder besser: Evolvierbarkeit). Über Helge Nowaks Präsentation bin ich auf diesen Text gestoßen und darüber dann auf einen Video-Vortrag:

Viktigste faktorer for å redusere teknisk gjeld - Dag Sjøberg from Smidigkonferansen on Vimeo.

Keine Angst, Sie müssen nun nicht Ihr Norwegisch abstauben. Ich denke, interessante Einsichten lassen sich auch aus den Vortragsfolien ziehen.

Vorab aber die Geschichte hinter dem Vortrag: Es wurde ein Experiment zu Wartungskosten für Softwaresysteme gemacht. Dazu wurde dasselbe System bei vier Softwarehäusern in Auftrag gegeben. Anschließend wurden alle vier Systeme gleichermaßen genutzt und also mit realen Daten befüllt. Und dann hat man allen Softwarehäusern einen Änderungsauftrag erteilt.

Mit dem Experiment sollte herausgefunden werden, welche Merkmale von Software mit guter/schlechter Wartbarkeit korrelieren. Deshalb hat man auch noch Softwarequalitätsexperten befragt, wie sie die Wartbarkeit der Systeme einschätzen.

Das spannende Ergebnis: Die Experten lagen daneben mit ihren Metriken. Vorhersagekraft hatte allein die Zahl der Codezeilen (Lines of Code, LOC).

image

Verblüffend, oder?

Denn dem stehen diese Vorhersagen gegenüber:

image

Systeme B und D sollten die beste Wartbarkeit aufweisen, A und C die schlechteste.

Nun könnten Sie sagen, der Aufwand für B und D lag nicht soviel über dem von A wie C. Für B mit dem besten Vorhersagewert war nur ca. 50% mehr Aufwand als für A nötig. Für D nur knapp 100% mehr. Das sind doch keine großen Missweisungen wenn man an das Verschätzen bei der Softwareentwicklung im Allgemeinen denkt.

Gegen diese Interpretation spricht für mich aber zweierlei: Zum einen ist der Vorhersagewert von A der schlechteste und auch noch für sich genommen grottig. Zum anderen steht hinter den schlechteren Wartungsaufwänden bzw. besseren Vorhersagewerten ein deutlich höherer Anfangsaufwand:

image

Meine Norwegisch-Kenntnisse geben mir ein, hier wird gefragt, ob wirklich mehr Aufwand zu geringeren technischen Schulden (lies: mehr Evolvierbarkeit) geführt hat. Leider muss die Antwort Nein lauten. Die laut Vorhersage besser wartbaren Systeme haben zwar knapp 100% bzw. 250% der Aufwands erfordert, der in den Letztplatzierten gegangen ist. Doch trotzdem hat der sie am Ende deutlich geschlagen.

Bessere Metrikwerte waren also teuer – und haben es nicht gebracht. Das ist bitter, oder?

Das am besten wartbare System hat pro Person am wenigsten Zeit in der Entwicklung gekostet und am wenigsten LOC enthalten.

Ist das eine triviale Aussage? Hm… ich glaube nicht. Denn sonst hätten die Experten ja besser geurteilt.

Schlussfolgerungen

Ich denke, es lassen sich aus dem Ergebnis einige Schlussfolgerungen für die Praxis ziehen. Wenn weniger LOC bessere Evolvierbarkeit bedeuten, dann müssen wir alles (naja, zumindest vieles) daransetzen, weniger LOC herzustellen. Und das geht so:

1. YAGNI

Weniger LOC beginnen nicht so sehr beim Entwickler, sondern eher beim Kunden bzw. beim PO. Er sollte noch schärfer darüber nachdenken, was wirklich, wirklich an Features benötigt wird. Und er sollte in noch dünneren Inkrementen codieren lassen, um schneller sagen zu können “Good enough!”. Ich bleibe also dabei, das Spinning eine Kernpraxis jeder Softwareentwicklung sein sollte.

Code erst gar nicht zu schreiben, ist das beste Mittel, um LOC zu reduzieren.

Aber das geht natürlich nicht nur den PO etwas an, sondern auch die Entwickler. Gern wird auf Vorrat implementiert, weil man ja soviel Erfahrung hat, was da noch alles kommen mag. Dann wird vorhergesehen und flexibilisiert, was das Zeug hält. Wiederverwendbarkeit ist ganz beliebt als herzustellendes Merkmal – auch wenn niemand weiß, was wie viel wiederverwendet wird.

2. KISS

Was dann implementiert wird, sollte so einfach wie möglich sein. Da verschwimmt manchmal die Grenze zwischen YAGNI und KISS, aber ich denke, jeder kennt Beispiele, wo etwas kompliziert gelöst wurde, wo es einfacher gegangen wäre. Der Grund: Unkenntnis, vermeintlicher Zeitmangel.

Auch für Code gilt Pascals (oder Goethes?) Ausspruch: Wenn ich mehr Zeit gehabt hätte, hätte ich mich kürzer gefasst.

Wie das Experiment zeigt, ist Zeitaufwand gesteckt in weniger LOC aber gut investierte Zeit. Die macht die später unabsehbaren “Wartungsarbeiten” kostengünstiger.

Natürlich gilt es da eine Balance zu finden. Mancher elegante Einzeiler ist am Ende schwerer zu evolvieren als etwas gesprächigerer Code.

3. Knappe Programmiersprache

Die LOC-Frage wirft eine zweite, womöglich schon zu den Akten gelegte auf: Welche Programmiersprache sollte benutzt werden, um das Nötige simpel zu codieren?

Früher ging es um Compiler- und Ausführungsgeschwindigkeiten. Heute ist das nicht mehr so ein großes Thema. Stattdessen sollte es um Knappheit (terseness) gehen. Natürlich Knappheit, die zur Lesbarkeit beiträgt. Das kann man von PERL oder APL eher nicht sagen, aber wohl z.B. von F#.

Welche Sprache bietet gute Abstraktionen, welche Sprache bemüht sich um “Rauschunterdrückung”? Java hat da heute für mich z.B. eher einen hinteren Platz. C# scheint mir im Mittelfeld. Und wie steht es mit Modernem wie Go, Exlixir, Swift?

Einerlei. Ich will hier für keine Sprache werben, sondern nur auf ein Mittel zur Reduktion der LOC für mehr Evolvierbarkeit aufmerksam machen. Die Sprachfrage sollte nicht leichtfertig abgetan werden mit dem Verweis aus die Tradition: “Wir haben halt immer schon in X entwickelt.”

4. Granulare Abstraktion

Eine Programmiersprache bietet mehr oder weniger Abstraktion. Mehr bedeutet gewöhnlich weniger LOC. Noch mehr bedeutet noch weniger LOC – aber ab einem gewissen Punkt geht das auf Kosten der Universalität. Beispiel SQL: damit lassen sich sehr knapp Anweisungen ausdrücken, aber SQL ist nicht computationally complete.

Durch die Wahl einer 3GL lassen sich die LOC also nur auf ein gewisses Maß reduzieren. Weiter muss es dann mit DSLs (Domain Specific Languages) gehen. Die gibt es nur nicht für alle Problemdomänen. Und es ist nicht zu erwarten, dass sich das grundlegend ändert. Einzelne Teams haben es schon schwer genug, Bibliotheken mit vernünftigen Abstraktionen zu entwickeln, da sind eigene DSLs in weiter Ferne. Sie haben ihren Platz – aber ihr Beitrag zur LOC-Reduktion für den Mainstream wird gering bleiben.

Wichtiger finde ich es daher, mit den Mitteln der gewählten 3GL eigene Abstraktionen auf unterschiedlichem Niveau zu schaffen. Die Mittel sind Container wie Funktion, Klasse/Modul, Komponente, (micro)Service.

Mein Annahme ist, dass sich das Versuchsergebnis auf verschiedene Größenordnungen übertragen lässt. Zwei Funktionen, die dasselbe leisten, sind je nach LOC unterschiedlich evolvierbar. Zwei Klassen, die dasselbe leisten, sind je nach LOC unterschiedlich evolvierbar. Usw. usf.

Kleine Funktionen, kleine Klassen, kleine Komponenten, kleine Services sind also anzustreben. Funktionen mit 3000 LOC, Klassen mit 100.000 LOC, die Abwesenheit von Komponenten und Services… das alles sind Zeichen der Unwartbarkeit.

Wer Evolvierbarkeit will, der sollte sich also stetig um kleine Container bemühen und um Container auf weiteren Abstraktionsebenen oberhalb von Klassen. Wo es nur Funktion, Klasse, Softwaresystem und das auch noch ohne LOC-Begrenzung gibt, ist der Monolith vorprogrammiert.

Wie kommen Sie denn aber zu kleinen Funktionen und Klassen? Die Forderung ist ja auch schon älter, ohne dass sie einen spürbaren Effekt gehabt hätte. Manche sagen, Funktionen sollten nur 7 oder 20 Zeilen haben. Andere sagen, sie sollten nicht länger als eine Bildschirmseite sein (aber mit welcher Auflösung).

Ich glaube, die Forderung nach einem bestimmten max. Zeilenzahl bringt uns nicht weiter. Wir brauchen einen Ansatz des Softwareentwurfs, der ganz natürlich zu kleinen Funktionen und Klassen führt. Die bisherige Objektorientierung leistet das nicht. Wir müssen nachbessern.

In meiner Codierungspraxis gibt es inzwischen keine Funktion mehr, die länger als 50 Zeilen ist (und mehr als Triviales tut). Nicht, weil ich mich durch StyleCop warnen lasse, sondern weil ich Software mit Flow-Design nur so entwerfen kann, dass alle Funktionen klein sind. Wenn Sie wissen wollen, wie das funktioniert, folgen Sie doch dem “Book in Progress” von Stefan Lieser und mir: The Architect´s Napkin Kata für Kata.

Eine größere Zahl von Funktionen und Klassen braucht dann natürlich wieder Container. Das Softwaresystem als Ganzes ist zu groß. Deshalb gehören für mich Komponenten- und Serviceorientierung ganz natürlich zu den Maßnahmen, die LOC pro Container zu reduzieren. Die einzuführen ist aber natürlich nochmal eine andere Nummer als die LOC-Reduktion bei den schon in Gebrauch befindlichen Containern Funktion und Klasse.

Aber es lohnt sich, denke ich. Durch Komponenten und Services wird es nicht nur mit LOC besser pro Container, sondern auch mit der Produktionseffizienz. Denn durch die expliziten Kontrakte kann an Komponenten und Services viel besser arbeitsteilig parallel gearbeitet werden. Darüber hinaus bieten Services die Chance, im selben Softwaresystem mehrere Runtimes/3GLs einzusetzen. Plattformneutrale Kontrakte machen es möglich. Ausführlicher dazu in The Architect´s Napkin – Der Schummelzettel.

Ziel ist in jedem Fall, mit den vielen kleinen Containern ein eigenes Domänenvokabular, gar eigene “Domänensätze” zu formulieren. Mit dem können Sie dann immer neue Geschichten (user stories) “schreiben”.

5. Geschichten trennen

Container sind ein technisches Granulat. Ich denke, es gibt aber auch aus Sicht von Kunde/Benutzer die Möglichkeit, granularer zu entwickeln, d.h. mehr Funktionseinheiten mit jeweils weniger LOC zu bilden.

Das Problem beginnt hier wieder beim Kunden. Der will oft “alles unter einem Hut”. Der sucht die “one size fits all” Anwendung. Die wächst und wächst dann und enthält alle LOC.

Was aber, wenn die Anforderungen nicht durch nur eine Anwendung, sondern durch viele umgesetzt würden. Nicht ein Icon auf dem Desktop, nicht eine URL im Intranet für alles, sondern viele.

Die Smartphones machen es vor. Statt einem Boliden wie Outlook vertrauen wir uns einem Schwarm aus kleinen Apps für Email, Kalender, Aufgaben, Notizen an. Viele Spezialisten statt ein Generalist. Das sind viele kleine Zweige unabhängiger Evolutionsmöglichkeit.

Jede App ist auf eine Domäne spezialisiert, erzählt sozusagen eine eigene Geschichte. Warum nicht dasselbe tun mit CRM, ERP, Buchhaltung, Qualitätsmanagement, Vertragsverwaltung usw. usf.? Das gesamte Softwaresystem enthält dann immer noch 100% aller LOC – nur ist es unterteilt in Apps mit jeweils einem Bruchteil der LOCs. Die lassen sich für sich leichter evolvieren.

Und innerhalb von Apps können Sie weiter Geschichten trennen. Apps müssen keine Monolithen sein, sondern können aus Modulen bestehen.

Am Ende geht es also nicht um ein Softwaresystem, sondern um einen bunten Strauß ein Modulen in Apps zusammengefasst. Das ist dann nicht eine monolithische Codebasis. Vielmehr gibt es viele schmale Schnitte durch die Anforderungen: Durchstiche. Jeder macht für sich Sinn. Jeder kann getrennt von anderen evolvieren. Änderungsaufträge werden sich meist auf einzelne Module beziehen. Die gesamte Codebasis steht also gar nicht mehr zur Debatte.

Fazit

Ich denke, das Ergebnis des Experiments bestätigt ein Bauchgefühl, das wir immer hatten. Zeit, dass wir es ernst nehmen. Packen wir die LOC bei den Hörnern und reduzieren, wo wir können.

Wo der LOC-Haufen schon groß ist, geht es nur mit Refaktorisierungen. Wo immer wir aber neuen Code schreiben, sollten wir uns mit den beschriebenen Mitteln bemühen, die LOC gering zu halten. Prevention over refactoring ;-)

Kleiner Code, Code mit weniger LOC ist unterm Strich einfach ökonomischer. Das zählt für unsere Kunden.

Sonntag, 18. Mai 2014

Zuschauen beim Softwareentwurf

Konzepte, Notationen, Methoden auf Papier sind geduldig. Darüber zu lesen, ist eine Sache. Sie dann aber anzuwenden, auch mit dem besten Willen, eine andere. Was im Artikel oder im Buch noch verständlich war und einfach aussah, erweist sich in der Praxis schnell als knifflig. Der Transfer fällt schwer – und dann lässt man es einfach sein und macht weiter wie bisher.

Dem möchten Stefan Lieser und ich nun etwas entgegenstellen. Wir sind überzeugt, dass leichtgewichtiger Softwareentwurf möglich und wünschenswert ist. Wir finden, dass er mit Flow-Design und Softwarezellen vor dem Hintergrund des Softwareuniversums wirksam ist. Und wir wollen das nun auch live demonstrieren.

imageBisher haben wir dazu viel geschrieben, in diesem Blog, in der dotnetpro und anderen Zeitschriften und schließlich auch in einem Buch: The Architect´s Napkin – Der Schummelzettel.

Was in den Artikeln über Jahre durch eine Evolution gegangen ist, fasst das Buch zusammen. Es ist eine Referenz unserer Konzepte und Notationselemente. Wir benutzen es als Schulungsunterlage in unseren Clean Code Developer Trainings z.B. bei der CCD Akademie. Es ist bei leanpub.com und sogar bei amazon erhältlich.

Wir wir erleben, braucht es einige Übung, um vom traditionellen schwergewichtigen Entwurfsdenken – das deshalb oft vermieden wird – auf diesen Ansatz umzuschalten. Bei aller Leichtgewichtigkeit ist er doch sehr anders.

In Trainings können wir das anleiten und begleiten. Was aber danach?

Für die Zeit danach bzw. zwischen Trainingseinheiten, für das Selbststudium haben wir nun ein gemeinsames Buchprojekt gestartet:

image

In diesem Buch wenden wir unsere Methode an. Wir lösen mit ihr kleine und große Aufgaben aus dem Coding Dojo der CCD School.

Das tun wir jedoch nicht wieder nur im Text, sondern auch per Video. Und die Resultate stehen in einem öffentlichen Git-Repository.

Zu jeder Kata führen wir den Entwurf live durch. Wir treffen uns online ohne weitere Vorbereitung und gehen die Anforderungen gemeinsam an. Hier als Beispiel der Entwurf zur ersten Kata im Buch. Die ist natürlich noch klein und einfach, doch sie zeigt den grundsätzlichen Ansatz:

In dieser Weise geht es weiter mit den anderen Katas bis zu Application und Architecture Katas, die wir dann verteilt implementieren.

Das Buch dient der Zusammenfassung von Video und Code. Es destilliert das Wichtigste nochmal zum Nachlesen heraus. Denn in Text lässt sich leichter navigieren als in einem Video. Und es kommentiert und ergänzt den live Entwurf.

Wir hoffen, in dieser Weise einem stiefmütterlich behandelten und zu Unrecht als trocken oder gar irrelevant angesehenem Thema neues Leben einzuhauchen. Softwareentwurf ist ein systematischer Prozess unter Anwendung einer Methode. Dabei kann man nun zuschauen. Das zeichnet ein realistisches Bild des Vorgehens. Das nimmt hoffentlich Unsicherheit.

So wie wir Software entwickeln, so arbeiten wir auch an dem Buch: agil. Es ist nicht fertig, sondern wächst in Inkrementen. Das erste Inkrement veröffentlichen wir heute. Weitere Releases folgen in den nächsten Wochen.

So können wir aus unserer Erfahrung bei der Videoaufzeichnung, beim Schreiben, beim Publizieren lernen. Und Feedback aus der Community können wir auch einfließen lassen.

Ich würde mich freuen, wenn Sie Lust hätten, uns beim Softwareentwurf zuzuschauen. Über neue Releases erfahren Sie bei Twitter hier und hier.

Mittwoch, 9. April 2014

Wichtiges verlässlich erledigt kriegen

Erledigt wird nur, was dringend ist. Ich denke, darin stimmen wir überein.

Aber es gibt Wichtiges und es gibt Dringendes. Beides muss erledigt werden – nur schiebt sich das Dringende scheinbar oft, allzu oft vor das Wichtige.

Das Wichtige

Das ist misslich und früher oder später gefährlich, denn das Wichtige ist ja das, was getan werden muss. Das macht seine Definition aus: Was bei Unterlassung über kurz oder lang zu einer Gefährdung der Existenz eines Systems führt, ist wichtig.

Ein Beispiel: Der Zweck einer Softwareschmiede ist (zumindest), mit Software soviel Geld zu verdienen, dass die daran beteiligten Menschen auf unbestimmte Zeit, d.h. jetzt und in Zukunft ihr Auskommen haben.

Im Hinblick auf diesen Zweck ist es unter anderem wichtig...

•    fähige und motivierte Menschen zu beschäftigen (Personalwesen),
•    attraktive Software herzustellen (Softwareentwicklung),
•    die Software dem Markt bekannt zu machen (Marketing),
•    für die Software Kunden zu bekommen (Vertrieb),
•    Kunden zu betreuen (Support, Schulungen)
•    mit Kunden und Lieferanten und Mitarbeitern abzurechnen (Buchhaltung)
•    Steuern zu zahlen (oder auch zu sparen) (Buchhaltung, Steuerberatung)
•    den Markt zu beobachten und Strategien zu definieren (Geschäftsführung)

Wenn eine dieser und weiterer Wichtigkeiten für längere Zeit unbeachtet bleibt, dann wird die Existenz der Softwareschmiede bedroht.

Nicht wichtig ist gewöhnlich hingegen, einen speziellen Mitarbeiter zu bekommen/halten, eine bestimmte Rechnung zu schreiben, ein spezifisches Feature einzubauen, einen bestimmten Kunden zu bekommen, einen speziellen Rechner zu kaufen usw.

Einzelnes ist nicht wichtig, sondern höchstens dringend. Oder wenn Einzelnes wichtig ist, dann ist es eine systemrelevante Größe. Dann ist Gefahr im Verzug!

Da nun selbstverständlich ausschließlich getan werden soll, was unter das Dach von etwas Wichtigem gehört, ist das Dringende immer auch etwas Wichtiges.

Damit schließt sich der Kreis: Wichtiges wird also doch getan. Zumindest sobald es dringend geworden ist. Das bedeutet unzuverlässig. Und das bedeutet oft spät. So spät, dass die Arbeit sich ausnimmt wie krampfhaftes Zucken, denn koordiniertes Voranschreiten.

Wie kann das verhindert werden?

Das Dringende

Wichtiges und Dringendes sind mithin keine Gegensätze. Dringendes ist vielmehr eine Sonderform des Wichtigen. Was es so besonders macht, das ist seine Konkretheit in Bezug auf Zustände.

Dringendes hat einen konkreten Ziel- oder Erledigungszustand sowie einen existenzbedrohenden Zustand. Immer ist es an Zeit gekoppelt, oft auch an einen Termin. Erledigung des Dringenden soll den Zielzustand herstellen; bleibt das Dringende hingegen unerledigt, tritt der existenzbedrohende Zustand ein.

Beispiel 1: Steuererklärung. Steuern zu zahlen, ist wichtig. Deshalb muss jährlich eine Steuererklärung abgegeben werden. Diese Tätigkeit ist jedoch nicht per se dringend. Sie wird erst mit der Zeit dringend, wenn der Abgabetermin näher rückt. Verstreicht der Abgabetermin ohne Steuererklärung, kann das existenzbedrohende Folgen haben.

Beispiel 2: Angebotsabgabe. Aufträge zu gewinnen, ist wichtig. Deshalb müssen immer wieder Angebote abgegeben werden. Oft unterliegt diese Abgabe einem Termin. Ein Angebot abzugeben ist jedoch nicht per se dringend. Es wird erst mit der Zeit dringend, wenn der Abgabetermin näher rückt. Verstreicht der Abgabetermin ohne Angebot, kann das – zumindest wenn es häufiger geschieht – existenzbedrohende Folgen haben.

Beispiel 3: Geldreserve. Eine Geldreserve zu haben, ist wichtig. Nur so können Schwankungen im Umsatz ausgeglichen werden, um weiterhin Verbindlichkeiten nachzukommen und Löhne zu zahlen. Deshalb ist die Aufstockung der Geldreserve jedoch nicht per se dringend. Sie wird es erst, wenn sich die Geldreserve dem Nullpunkt nähert. Allemal wenn die Geldreserve auf Null ist, ist die Existenz bedroht, sofern die Umsätze zu schwach sind.

Zielzustand und existenzbedrohender Zustand sind in den Beispielen klar. In den ersten Beispielen ist der Wechsel vom aktuellen Zustand in den einen oder anderen quasi binär und termingebunden. Im dritten Beispiel hingegen ist er graduell und nicht termingebunden, sondern wertgebunden.

Wann wird eine Tätigkeit oder allgemeiner der Eingriff in die Entwicklung eines Zustands nun dringend? Wenn das Risiko groß wird, in der verbleibenden Zeit den Zielzustand nicht zu erreichen.

image

Das Risiko ist an den Aufwand gekoppelt. Ist der Aufwand sehr klein und auch nicht selbst noch mit Unwägbarkeiten behaftet, gibt es bis kurz vor Erreichen des existenzbedrohenden Zustands keine Dringlichkeit. Ist der Aufwand hingegen groß oder gar unbekannt, stellt sich Dringlichkeit schon lange vor Erreichen des existenzbedrohenden Zustands ein.

Zu Beispiel 1: Wie groß ist der Aufwand für eine Steuererklärung? Bei mir dauert es ca. 1 Tag, um alle Unterlagen und Daten zusammenzutragen. Anschließend braucht der Steuerberater nochmal ca. 4 Wochen. Diese Aufwände sind mit wenig Unsicherheit behaftet. D.h. dringend wird für mich die jährliche Steuererklärung vielleicht 5 Wochen vor Abgabetermin.

Zu Beispiel 2: Wie groß ist der Aufwand für das Angebot? Vielleicht dauert es nur 1 Stunde, vielleicht dauert es aber auch 1 Woche, um alles durchgerechnet und formuliert zu haben. Wie unwägbar ist der Aufwand? Statt 1 Stunde könnten es auch 2 sein? Statt 1 Woche auch 3? Wenn der Versand per Email quasi in Nullzeit erfolgt, dann wird das Angebot 2 Stunden bzw. 3 Wochen vor Abgabetermin dringend.

Zu Beispiel 3: Wie groß ist der Aufwand, die Geldreserve wieder aufzustocken bis sie das nächste Mal in Anspruch genommen werden muss? Vielleicht geschieht das durch eine absehbare Zahlung eines Kunden in der nächsten Woche, vielleicht braucht es aber auch Wochen und Monate. Im ersten Fall tritt Dringlichkeit vielleicht gar nicht ein, weil die Entwicklung des Reservebestands bis nächste Woche nicht bei Null angekommen sein wird. Im zweiten Fall ist die Aufstockung eher kontinuierlich dringend, solange die Reserve unterhalb einer Sollmarke liegt.

Das Wichtige verdringlichen

Mit der Zeit wird alles Wichtige dringend. Wenn wir das aber passiv zulassen, dann reagieren wir nur noch. Dann sind wir nicht mehr Herr im eigenen Haus, sondern werden „Spontanbränden“ zur ewigen Feuerwehraktionen gezwungen.

So lässt sich ein Unternehmen führen – sogar recht lange, wie ich immer wieder feststellen muss. Aber macht das Spaß? Ist das ökonomisch? Das bezweifle ich.

Ich ziehe Agieren dem Reagieren vor. Ich ziehe fließende ruhige Abarbeitung dem Hinterherhecheln vor.

Dafür ist es unabdingbar, das Wichtige nicht aus den Augen zu lassen. Sonst erschreckt es uns irgendwann.

Wenn nun aber anscheinend nur das Dringende getan wird, muss das Wichtige von vornherein auch dringend sein. Wir müssen es also bewusst und angemessen verdringlichen. Wie kann das geschehen?

Beobachtung

Am Anfang steht für mich, sich des Wichtigen überhaupt erst einmal bewusst zu werden – und dann das Wichtige zu beobachten. Wie entwickeln sich wichtige Metriken? Steigen oder fallen Mitarbeiterfähigkeit, Mitarbeitermotivation, Vertriebserfolg, Softwarequalität, Betreuungszufriedenheit usw.?

Daraus ergeben sich früher oder später wünschenswerte und existenzbedrohende Werte für die Metriken und auch Entwicklungskurven.

Planung

Wenn insbesondere die existenzbedrohenden Zustände und ihre Entwicklungskurven bekannt sind, dann plane ich konkrete Kompensationen ein, soweit das geht. Für die Steuererklärung trage ich einen Tag 5 Wochen vor dem Abgabetermin ein. Für die Angebotsabgabe blocke ich z.B. 4 Stunden ein oder zwei Tage vor Abgabetermin – sobald ich den kenne.

Auf diese Weise überrascht mich das Wichtige nicht, sondern ich kann ihm mit einem Blick in den Kalender immer ins Auge sehen. So kann ich andere Tätigkeiten danach ausrichten und das Wichtige läuft nicht Gefahr, unter den Tisch zu fallen.

Gewohnheit

Nicht alles Wichtige ist termingebunden oder in seiner Entwicklung länger vorher absehbar. Punktuelle Termine kann ich in den Kalender nicht eintragen. Deshalb muss ich aus der Behandlung des Wichtigen eine Gewohnheit machen.

Meine Geldreserve stocke ich regelmäßig jeden Monat mit einem bestimmten Betrag auf. Um meine Fakturierung kümmere ich mich regelmäßig einmal im Monat. Um meine Positionierung kümmere ich mich jeden Tag eine Stunde. Um das Lernen kümmere ich mich jede Woche 4 Stunden usw.

Hier löst nicht ein „Hau-ruck-Aufwand“ das Problem, sondern Kontinuität. Das Wichtige wird nicht on-demand angegangen, sondern ständig in mehr oder weniger kleinen Häppchen. Das Motto: “Stehter Tropfen hölt den Stein.”

Automatisation

Geplante und rhythmisierte Maßnahmen muss ich noch selbst übernehmen. Ein nächster Schritt ist die Übertragung des Wichtigen an einen Automaten. Der kann geplant, rhythmisch oder on-demand Zustände beobachten und kompensierende Maßnahmen durchführen. Ein Beispiel dafür ist der Dauerauftrag ans Finanzamt für die Einkommenssteuervorauszahlung. Aber auch die Garbage Collection einer Runtime gehört dazu: statt das Wichtige – Speicherverwaltung – dem “Zufall” (oder der mehr oder weniger entwickelten Fähigkeit von Entwicklern) zu überlassen, automatisiert die Runtime die Berücksichtigung dieses Aspekts.

Stakeholder

Wenn eine Automatisation nicht möglich ist, setze ich einen menschlichen Stakeholder ein, dessen (Haupt)Aufgabe das Wichtige ist. Sobald ich mehr mit Abarbeitung des Geplanten und des Kontinuierlichen und der Beobachtung des Wichtigen zu tun habe, als meine Arbeitszeit zulässt, sollte ich Teile des Wichtigen „outsourcen“.

Das gilt auch, wenn ich für das Wichtige unterschiedlich qualifiziert bin. Es mag genauso wichtig sein, eine neue Website aufzusetzen wie neue Kunden zu gewinnen. Aber ich bin besser qualifiziert, für mich Kunden zu finden, als meinen Website zu überarbeiten mit all den HTML5/CSS/JS-Feinheiten, die heute state-of-the-art sind.

Nach der Manifestation des Wichtigen im Kalender und im Rhythmus kommt also die Manifestation in Form einer Person. Damit bekommt das Wichtige zwei Beine, die immer wieder den Weg zu mir finden, um Input einzufordern. Das ist dann wiederum für mich wichtig und sollte ebenso geplant oder rhythmisiert werden.

Zusammenfassung

Wenn sich Dringendes immer wieder störend in unseren Arbeitsfluss mischt, läuft etwas falsch. Dann haben wir das Ruder aus der Hand gleiten lassen.

Unerwartet Dringendes gilt es mit aller Macht zurückzudrängen und zur Ausnahme zu machen. Stattdessen müssen wir versuchen, das Wichtige bewusst so zu konkretisieren, dass es sich wie Dringendes ausnimmt, geplantes Dringendes. So können wir auch erkennen, wenn es über unsere Kräfte geht. Dann müssen wir Hilfe suchen.

Es ist also nicht schlimm, wenn nur Dringendes erledigt wird. Wir dürfen uns davon nur nicht überraschen lassen. Umarmen wir also das Dringende. Machen wir uns seine Kraft zunutze.