Nachhaltig wertvolle Software liefern

Unter der Lupe zeigt sich, dass das Agile Manifest nicht nur auf working software abzielt, sondern auf valuable software. Das ist jedenfalls mein Ergebnis einer näheren Betrachtung.

Es geht darum, wertvolle Software in nachhaltiger Weise zu liefern. Und dafür braucht es einen fundamentalen Modus der für mich so aussieht:

Produktion eines stetigen Stroms von zielführenden Artefaktänderungen ohne Budgetvorgabe.

Wenn das für Sie provokant klingt, dann ist das Absicht. Ja, es soll provozieren, es soll an Gewohnheiten und Glaubenssätzen rütteln. Nur wenn wir unser Denken in solcher Weise an die Grenze bringen, können wir hoffen, unseren Horizont zu erweitern und (noch) bessere Ergebnisse zu erzielen.

Doch natürlich soll das nicht ohne weitere Erklärung im Raum stehenbleiben. Die Begriffe verdienen eine Definition.

Wert

Das Agile Manifest erklärt nicht näher, was working software ist. Liegt das nicht auch auf der Hand? Es ist Software, die ihre Aufgabe erfüllt, die nützlich ist. Nützliche Software ist wertvoll für den Kunden, dafür ist er bereit, Geld zu bezahlen.

Eine aus meiner Sicht oberflächliche Lesart des Agilen Manifests fokussiert die Softwareentwicklung also darauf, einen Strom lauffähiger Software zu produzieren. Der Scrum Guide formuliert es so:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

Ob eine Software useable oder working ist, kann der Kunde beurteilen. Er muss sie nur ausprobieren. Stellvertretend für den Kunden definiert und überprüft der Product Owner diese Qualität.

Allerdings glaube ich, dass mit diesem Fokus das Agile Manifest und noch konkreter der Scrum Guide zu kurz greifen. Working software darf nicht der einzige Marktstein für den Fortschritt der Softwareentwicklung sein.

Working software ist nämlich nur das: working, nützlich, brauchbar im Moment. Was aber in der Zukunft? Wenn eines gewiss ist in der Softwareentwicklung, dann dass der Kunde gerade wenn er working software in den Händen hält, bald mehr davon haben will. Working software heute, soll morgen schon wieder anders aussehen.

Dass jedoch eine Anpassung von Software an immer neue Wünsche des Kunden ohne weiteres Zutun möglich sei, ist ein Trugschluss, dem nicht nur Laien wie der Kunde unterliegen.

Die Anpassbarkeit, die Wandelbarkeit, die eine Codebasis braucht, um dauerhaft ohne steigenden Aufwand neuen Anforderungen nachgeführt werden zu können, braucht explizite Aufmerksamkeit. Darum muss sich die Softwareentwicklung sehr bewusst bemühen. Flexibilität ergibt sich nicht einfach so.

Für mich steckt diese Notwendigkeit jedoch nicht im Begriff working software. Working software zeigt lediglich gewünschtes Verhalten im Moment, also Funktionalität und Effizienz gemäß der Anforderungen.

Aber wie steht es mit der ebenfalls notwendig zu wünschenden Wandlungsfähigkeit? Zugegeben, die kann der Kunde nicht direkt überprüfen. Sie ist keine Laufzeiteigenschaft. Indirekt jedoch zeigt sie sich ihm im Trend der Produktivität der Softwareentwicklung.

Nur weil der Kunde keine unmittelbare Aussage über die Wandelbarkeit einer Codebasis machen kann, heißt das jedoch nicht, dass niemand dazu ein Urteil abgeben könnte. Die Rolle, die traditionell dazu eine Meinung haben sollte, ist der Architekt. Seine Aufgabe ist es, die Erfüllung nicht-funktionaler Anforderungen sicherzustellen. Dazu gehören aber nicht nur Effizienzen wie Performance oder Security, sondern eben auch Zukunftsfähigkeit durch Korrektheit und Wandelbarkeit.

In Scrum spielt der Architekt allerdings keine Rolle. Ob es einen gibt, wie auf die Anforderung „Wandelbarkeit“ geachtet wird, ist kein Thema. In eXtreme Programming hingegen gibt es ausdrücklich Praktiken, die sich darum kümmern, z.B. Refactoring oder TDD. Demgegenüber finde ich im Agilen Manifest eine Formulierung wie „good design enhances agility“ schwach - und sehe als Resultat auch in Scrum-agilen Teams oft nur schwache Testabdeckung und Berge an legacy code.

Also: Nachhaltige Produktivität ist kein Zufall und muss den Kunden interessieren. Sie gehört zu den Anforderungen an die Softwareentwicklung. Die Softwareentwicklung, allemal die agile, muss auch sie liefern. Dafür braucht es einen Begriff, in dem sie mit gefasst ist; der ist für mich valuable software.

Valuable software ist denn auch deutlich mehr, als lauffähige, nützliche Software. Der Wert von valuable software zeigt sich nicht nur an Laufzeiteigenschaften, sondern an all dem, was in einem Code-Repository zu finden ist.

Zielführende Artefaktänderungen

Wenn am Repository eine Änderung vorgenommen wird, die dazu führt, dass die Software mehr kann (Funktionalität), dann steigt ihr Wert.

Wenn am Repository eine Änderung vorgenommen wird, die dazu führt, dass sich die Effizienz der Software verbessert, dann steigt ihr Wert.

Und wenn am Repository eine Änderung vorgenommen wird, die dazu führt, dass die Korrektheit sichergestellt oder die Wandelbarkeit größer ist, dann steigt der Wert der Software ebenfalls.

Den Kunden interessiert für working software lediglich die Logik in einem Code-Repository, also die Anweisungen, die Eingaben in Ausgaben transformieren. Logik ist jedoch nur ein Teil dessen, was sich im Code-Repository findet. Mit ihr lassen sich Funktionalität und Effizienz beeinflussen.

Was ist mit Bibliotheken, Komponenten, Services? Sind die nötig für working software? Durchaus, denn durch eine geschickte Modularisierung und Verteilung lässt sich ebenfalls die Effizienz günstig beeinflussen. Außerdem kann die Bereitstellung von Software vereinfacht werden. Ein nicht zu vernachlässigender Aspekt von working software, der auch noch recht unmittelbar spürbar für den Kunden ist, aber schon zur Forderung nach Produktivität gehört. Dem dienen übrigens auch z.B. CI-Skripte oder Docker Container.

So weit der übliche Fokus der Softwareentwicklung.

Änderungen an Code, die hier eingreifen und die Softwareeigenschaften verbessern, sind deutlich zielführend mit Blick auf working software.

Was aber mit Funktionen und Klassen? Was mit Variablennamen, Kommentaren oder gar Dokumenten wie Glossar oder Entwurfsdiagramm? Was mit automatisierten Tests?

Sie sind für working software nicht nötig. Sie machen nur Sinn, wenn es um valuable software geht. Tests dienen der Überprüfung von Reife und Regressionsfreiheit; Funktionen dienen der Testbarkeit; Variablennamen, Klassen, Kommentare, Dokumente dienen der Verständlichkeit.

Änderungen an diesen Artefakten in einer Code-Basis sind also nicht minder wertvoll. Eine Refaktorisierung, ein weiterer Test, ein besserer Variablenname, ein begründender Kommentar, ein verständlicher Entwurf sind genauso zielführend wie Veränderungen an der Logik. Der Zweck ist nur nicht wertvolleres Softwareverhalten, sondern die Zukunftsfähigkeit der Softwareentwicklung. Es geht um die Lebenszeit der Software.

Ich glaube ganz fest, dass wir gut daran tun, auch für diese Veränderungen Wertschätzung zu entwickeln. Der Kunde wird es uns danken, weil er bemerkt, dass wir produktiver und verlässlicher werden. Er bekommt mehr Wert für sein Geld, nicht nur, weil mehr unserer Arbeit als wertvoll klassifiziert ist, sondern weil wir damit auch der working software auf die Sprünge helfen. Nachhaltigkeit hat einen spürbaren Effekt - allerdings ist sie kein quick win.

Wenn die Erfüllung einer Aufgabe (z.B. User Story, Task) in der Softwareentwicklung dazu führt, dass ein Artefakt zielführend in der obigen Weise verändert wird, dann ist das ein positives Resultat der Arbeit. Es entsteht Wert - entweder im Auge des betrachtenden Product Owners oder im Auge des betrachtenden Architekten als Stellvertreter des Kunden.

Jetzt kommt es nur darauf an, dass solche Werte zuverlässig entstehen.

Ohne Budgetvorgaben

Kunden wollen Fortschritt und das verlässlich. Sie wollen sicher sein, dass ihr Geld tatsächlich in Wert transformiert wird.

Üblicherweise versucht man Kunden diese Sicherheit zu geben, indem man ein Ergebnisversprechen macht: es wird ein inhaltlicher Umfang für eine Veränderung verhandelt, der im Rahmen eines Budgets geleistet wird. Scope und Budget sind fix.

Der Scope kann sich dabei nur auf das Softwareverhalten beziehen, denn nur das ist für den Kunden bei Lieferung nach Ausschöpfen des Budgets unmittelbar überprüfbar. Für den Kunden geht es deshalb sehr verständlich um working software.

Und wenn das so ist, dann ist es nicht verwunderlich, dass das Budget von der Softwareentwicklung vor allem für working software eingesetzt wird - auch wenn valuable software der eigentliche Zweck der Agilität ist. Mit der fixierten Kombination (Scope, Budget) wird mithin notorisch zu wenig Wert hergestellt.

Dazu kommt, dass sich selbst für einen (scheinbar) fixen Scope für einen Zuwachs an Wert bei working software nur schwer ein Budget (z.B. für den zeitlichen Aufwand) bestimmen lässt. Die Kunst der Abschätzung ist eine Jahrmarktskunst, die selten mit ihren Konsequenzen zu leben hat. Die kommen an anderer Stelle zum Tragen und erzeugen große Mengen an Verschwendung, ganz zu schweigen von einem Mangel an Wert. Die fixierte Kombination (Scope, Budget) behindert die Herstellung von valuable software.

Dieser Effekt mag geringer sein, wenn man den Scope verringert und somit das Budget verkleinert. Statt einen riesigen Scope in 3 Jahren mit 10 Personen zu realisieren, geht es heute nur noch um einen kleinen Scope, der z.B. in 2 Wochen mit 4 Personen umgesetzt werden soll.

Iterativ-inkrementelles Vorgehen reduziert zwar das Leiden an Ergebnisversprechen in gewisser Weise. Geheilt ist das fundamentale Problem damit jedoch nicht. Allemal nicht, solange der Fokus weiterhin auf working software und nicht auf valuable software ist.

Deshalb halte ich es für ein Gebot wahrhafter Agilität, genau hier einen anderen Kurs einzuschlagen. Es passt schlicht nicht zum Anspruch der Agilität, die Provokation von Konflikten hinzunehmen, die in Ergebnisversprechen immer lauert.

Anders als bisher gedacht ist dafür eine Verkleinerung der Ergebnisversprechen jedoch nicht genug. Auf 2 Wochen etwas zu versprechen statt auf 3 Jahre, stellt keinen fundamentalen Wandel zu dem dar, was die Agilität ursprünglich motiviert hatte.

Ich denke, es ist nötig, nicht im Versuch einer graduellen Verbesserung zu verharren, sondern das Wurzelproblem bei den Hörnern zu packen. Unzuverlässigkeit, wie sie immer noch die Branche jeden Tag schüttelt, bekämpft man nicht mit einer Erhöhung der Taktzahl für Ergebnisversprechen.

Erstens ist weiter zu fassen, was überhaupt versprochen wird. Man muss klar haben, dass es um valuable software geht.

Zweitens ist die Kopplung von Scope und Budget aufzugeben.

Der Kunde darf für sein Geld keine Lösungen mehr erwarten!

Die Herstellung von Lösungen für Probleme (Scope) im Rahmen eines fixen Budgets kann Softwareentwicklung nicht leisten und sollte es nicht mehr versprechen. Alles andere macht unglücklich. Und das geht so lange, bis einer weint.

Resultatsorientierte Softwareentwicklung

Unerhört, oder? „Keine Lösungen mehr fürs Geld? Wie soll das denn gehen? Das macht der Kunde nie mit!“

Natürlich habe ich die obige Forderung absichtlich etwas provokant formuliert. Sie soll überspitzt auf den Punkt bringen, welches Umdenken ich für nötig halte.

Verständlich wird es hoffentlich, wenn ich den Dreh- und Angelpunkt benenne: Verantwortlichkeit.

Ich glaube, bei Agilität geht es ganz grundsätzlich um eine Umkehrung der Verantwortlichkeit, sozusagen inversion of responsibility.

Wer von einem Dienstleister eine Lösung will, der muss ihm ganz präzise beschreiben, wie das Problem lautet und was die Eigenschaften der Lösung sein sollen. Ganz präzise bedeutet, dass der Dienstleister wirklich, wirklich beurteilen kann, ob er die Lösung auch tatsächlich herstellen kann. Wenn er das verspricht, übernimmt er die Verantwortung. Dann ist der Ball in seinem Spielfeld und er muss leisten. Der Kunde kann sich zurücklehnen und auf die Lieferung der Lösung warten.

Ein solches Verhältnis besteht zwischen Ihnen und zum Beispiel einer Bäckerei. Sie gehen in den Laden, fragen nach einem Dinkelbrot – und der Verkäufer kann entscheiden, ob er eine Lösung für Sie hat.

Ein solches Verhältnis besteht aber z.B. schon nicht mehr zwischen Ihnen und einem Friseur. Dem beschreiben Sie nämlich nicht präzise, wie eine Lösung für Ihr Haarproblem aussieht und überlassen sich ihm dann blind. Nicht umsonst sitzen Sie während der Dienstleistung vor einem Spiegel. Sie sollen und müssen sehen, wie sich die Lösungsherstellung entwickelt. Gegen Ende hält dann der Friseur auch noch einen Spiegel hinter Sie, so dass sie beurteilen können, ob die Lösung schon am Hinterkopf erreicht ist.

Der Friseur hat eine Menge Kompetenzen, die er Ihnen gern anbietet als Hilfestellung bei der Lösungserarbeitung. Aber letztlich benutzen Sie den Friseur nur als Werkzeug. Sie selbst sind es, der die Lösung herstellt. Die Verantwortung bleibt bei Ihnen.

Das glauben Sie nicht? Dann setzen Sie nächstes Mal beim Friseurgang eine Augenbinde auf. Vermeiden Sie den Blick in jeden Spiegel, bevor Sie wieder zuhause sind. Wie fühlen Sie sich damit?

Die Softwareentwicklung muss klar machen, dass sie keine Lösungen produziert, sondern lediglich dem Kunden ein williges Werkzeug ist, das zielführende Resultate liefert – die der Kunde zu einer Lösung zusammensetzt. Er behält die Hoheit der Steuerung.

Für die Steuerung braucht der Kunde jedoch zweierlei:

• Kontakt zur Softwareentwicklung, denn er muss spüren, wie sie sich bewegt, und mit Anforderungen immer wieder steuernd eingreifen.
• Feingranulare Resultate zu fixem Preis, um die Kosten des Fortschritts im Blick zu behalten und ggf. umzusteuern.

Kunde und Softwareentwicklung müssen also in touch sein. Entfernt der Kunde sich, widmet er der Softwareentwicklung keine Aufmerksamkeit, wird er seiner Verantwortung als Lösungsproduzent nicht gerecht. So weit war das Agile Manifest auch noch klar in seinen Werten. Customer collaboration sei zentral. „Business people and developers must work together daily throughout the project“ heißt es fordernd.

Doch auch das Agile Manifest verlagert nicht ausdrücklich die Verantwortung für die Lösung dorthin, wohin sie gehört: zum Kunden. Softwareentwicklung wird noch als Lösungshersteller angesehen. Ich glaube, genau das funktioniert jedoch nicht. Denn was schon beim Friseur keine Option ist, kann bei etwas so viel Komplexerem wie Software gar nicht funktionieren.

Wenn die Verantwortung jedoch zum Kunden (zurück)verlagert wird, was liefert dann die Softwareentwicklung? Wie oben gesagt: zielführende Veränderung am Code-Repository im Sinne von valuable software.

Da nun jedoch keine Lösung mehr von der Softwareentwicklung erwartet wird, ist es auch nicht nötig, für solche Veränderungen vorher ein Budget zu vereinbaren. Es muss lediglich feststellbar sein und festgestellt werden, welche Veränderungen auf welches Ziel hin vorgenommen wurden. Resultate müssen klar zuordnbar sein.

Was wurde für diese Funktionalitätsanforderung getan? Wie viel wurde für jene Effizienzanforderung aufgewendet? Wann wurde etwas für die Wandelbarkeit geleistet?

Das muss der Kunde grundsätzlich sehen können, wenn er auch nicht immer selbst einschätzen kann, ob das alles nach den Regeln der höchsten Kunst geschehen ist.

Insbesondere müssen klare Resultate in Richtung nachhaltiger Produktivität überhaupt identifizierbar sein. Das Herumeiern um Refactorings und automatisierte Tests, für die angeblich nie Zeit und Geld vorhanden sind, kann so nicht weitergehen. Es ist eine Schande für die Branche. Unsicherheit darüber, ob und wann man sich für nachhaltige Qualität engagieren darf, ist im höchsten Grade unprofessionell.

Softwareentwicklung darf sich deshalb nur agil nennen, wenn sie dem Kunden gegenüber in diesem Punkt glasklar die Wahrheit sagt. Sie muss ihn in die Lage versetzen, auch in dieser Hinsicht Vertrauen zu entwickeln. Das Mittel dazu ist Transparenz. Wofür und in welcher Menge wird Aufwand für nachhaltige Produktivität und nicht nur für Funktionalität und Effizienz getrieben?

Sollte der Kunde mit dieser Transparenz nichts anfangen können, steht es ihm frei, einen Sachverständigen hinzuzuziehen, der auf die gemeldeten Resultate einen Blick wirft. Das macht jeder Kunde eines Immobilienherstellers nicht anders. Bauingenieure arbeiten nicht nur beim Hersteller, sondern auch beim Abnehmer.

Damit meine ich allerdings nicht, dass auf platte Code-Metriken gestarrt werden sollte. Es geht vielmehr um den Strom der Resultate. Auf ihm schwimmt der Kunde in Richtung Lösung, in ihm muss er steuern. Produktivität und Fortschritt sind nichts, was man aus einem Schnappschuss herauslesen kann.

Die Lösung entsteht also im Auge des betrachtenden Kunden (bzw. seiner Stellvertreter). Fast bin ich versucht zu sagen, sie emergiert. Denn die Lösung im Ganzen als Ergebnis der Softwareentwicklung ist nicht für die Softwareentwicklung im Detail mit vorhersehbaren Schritten kontrolliert herstellbar. Die Softwareentwicklung konzentriert sich nur auf sicheren Tritt, sie setzt einen Fuß vor den anderen. Gesteuert wird sie dabei vom Kunden bzw. von den Verhältnissen des Terrains.

Mit der Verantwortung für die Lösung beim Kunden ist die Softwareentwicklung reduziert auf die verlässliche Lieferung von Fortschritten. Ja, Verlässlichkeit steht im Kern agiler Softwareentwicklung. Dafür ist alles zu tun. Sie ist nämlich die hauptsächliche Zutat für Kleber und Schmierstoff zwischen Kunde und Dienstleister: Vertrauen.

Agilität kreist mithin um die Frage, wie Verlässlichkeit geradlinig und dauerhaft hergestellt werden kann.

Fixe Budgets

Es ist etwas dran an dem überkommenen Liefermuster. Verlässlichkeit profitiert von einem fixen Budget. Es stellt ein minimales Versprechen dar, das in jedem Fall erfüllt werden muss:

• Die Softwareentwicklung arbeitet das Budget für eine Aufgabe konzentriert ab.
• Nach Ausschöpfung des Budgets liefert die Softwareentwicklung und der Kunde gibt Feedback.

Dieses Versprechen ist schon schwierig genug zu erfüllen. Denn: Konzentrierte Arbeit ist eine Seltenheit in den Softwareabteilungen, die ich kenne.

Ohne Konzentration geht es jedoch nicht, weil das Budget sonst verschwendet wird. Die Lieferung fällt kleiner aus als sie könnte. Ein Kunde, der bemerkt, dass das gewährte Budget verschwendet wird, ist kein glücklicher Kunde.

Agiles Vorgehen bedeutet also, dass sich Softwareentwicklung um fixe Budgets dreht. Allemal braucht es vordefinierte Timeboxes, in denen sie stattfindet.

Allerdings ist die Größe der Budgets eben nicht abhängig von einem abgeschätzten Lösungsumfang! Die Softwareentwicklung produziert ja keine Lösungen mehr. Stattdessen ist das Budget schon vorher festgelegt und steht höchstens in Zusammenhang mit einer Aufgabenkategorie. Eine Aufgabe im Frontend könnte mit einem anderen fixen Budget angegangen werden als eine Aufgabe im Backend, eine Codierungsaufgabe könnte ein anderes fixes Budget haben als eine Analyseaufgabe usw.

Wesentlich ist jedoch nicht der genaue Budgetumfang, sondern seine Unabhängigkeit von genauer Aufgabe und Lösung. Damit wird das Budget zum verlässlichen Taktgeber. Damit entsteht Zug in der Softwareentwicklung, denn Lieferungen erfolgen stets am Ende des Budgets. An dieser Gewissheit muss sich alles ausrichten. Softwareentwicklung findet somit quasi vom Ende her statt.

Minimale Budgets

Fixierte Budgets können zwar grundsätzlich unterschiedlich groß sein, doch wie berechnet sich diese Größe? Eine Schätzung findet nicht mehr statt. Die Schätzung hat sich ja als fundamental untauglich zur Herstellung konfliktfreier Softwareentwicklung herausgestellt. Das ist die Erkenntnis der Agilität – auch wenn sie so nicht gelebt wird.

Statt die Größe eines Budgets zu schätzen, wird es einfach festgesetzt. Der Umfang ist im Grunde beliebig. Allerdings gibt es zu bedenken: je größer das Budgets, desto größer auch die Gefahr für Konzentrationsverlust, desto länger die Zeit bis zu einer Lieferung inkl. Feedback, desto wahrscheinlicher, dass Verschwendung entsteht.

Wenn also schon keine Lösung mehr durch Ausschöpfen des Budgets hergestellt wird, dann sollte es so gewählt werden, dass ein Strom an Lieferungen entsteht, der leicht gesteuert werden kann. Das klappt am besten bei feingranularen Lieferungen.

Mir scheint deshalb empfehlenswert, das Budget aggressiv klein zu halten. Eine Timebox für übliche Softwareentwicklungsaufgaben sehe ich bei einer Dauer von 30min bis 90min - wobei ich derzeit 30min oder 45min favorisiere.

„Was, so kurz?! In der Zeit kann man doch nichts schaffen!“ mögen Sie jetzt ausrufen. Doch bitte bedenken Sie: Es geht nicht darum, in dieser Timebox eine Lösung herzustellen. Selbst für die Aufgabe „Entwickle einen Twitter-Klon“ wäre die Timebox nicht größer ;-) Das ist ja mein Punkt: Agilität entsteht nur durch radikale Aufgabe der Vorstellung, dass Lösungen mit abschätzbaren Budgets punktgenau realisiert werden können oder überhaupt von der Softwareentwicklung geliefert werden sollten.

Im Rahmen der einzelnen Timebox ist die ganze Lösung nicht bewältigbar, nicht erkennbar. Nur so kann Emergenz entsteht. Nur so kann die Illusion, dass Lösungen kontrolliert geradlinig entwickelt werden können, durchbrochen werden.

Innerhalb einer Timebox gibt es keinen Druck, eine Lösung zu erzielen, also einen Scope garantiert umzusetzen. In ihr besteht die einzige Aufgabe darin, konzentriert und nach Kräften Wert zu erzeugen. Das kann in Bezug auf die Funktionalität oder Effizienz oder Korrektheit oder Wandelbarkeit geschehen.

Es geht ausschließlich um Fortschritt im Sinne einer Wertsteigerung. Wie viel Wert entsteht dann in einer Timebox? Das hängt davon ab, wie konzentriert die Arbeit in der Timebox ist und welche Kompetenz die beteiligten Personen haben. Wer mehr Wert herstellen will, der konzentriert sich besser und achtet darauf, unabhängig und befähigt zu sein.

Eine aggressiv kleine Timebox hilft, die Verschwendung zu begrenzen. Mehr als 90min konzentrierte Arbeit ist kaum möglich. Wer es länger versucht, der erhöht die Wahrscheinlichkeit zum Konzentrationsverlust und damit zu einer Lieferung, die kleiner als möglich ausfällt.

Aggressiv kleine Timeboxes takten die Arbeit in einer Weise, die durch häufige konzentrierte Lieferungen befriedigt und gleichzeitig offen hält für Kontakt mit der Umwelt.

Bei Timeboxes von 30min bis 45min lassen sich Fortschritte sogar quasi zwischendurch erzielen.

Wie gesagt: Es geht bei dieser Art fixer, minimaler Budgets nicht um die Herstellung von Lösungen, sondern um Fokus und garantierten Fortschritt in Form eines Wertzuwachses.

Struktur der Lieferung

Wenn aber mit Budgets keine Lösungen mehr geliefert werden sollen, was dann?

Die Umkehrung der Budgetverhältnisse führt aus meiner Sicht dazu, dass Aufgaben kein „monolithisches“ Ergebnis mehr haben, sondern ein strukturiertes.

Die übliche, nicht agile Transformation lautet: (Aufgabe,Budget) -> Lösung

In der Agilität verändert sie sich jedoch zu:

Aufgabe -> (Resultat, Backlog)

Die Lieferung am Ende jedes vorfixierten Budgets, das deshalb nicht mehr auf der linken Seite der Transformation auftaucht, ist ein Tupel! Das ist von allergrößter Wichtigkeit. Das ermöglicht Fortschritt ohne Lösungszwang.

• Resultat: eine zielführende Veränderung an Artefakten im Code-Repository.
• Backlog: eine Liste von Aufgaben, die sich aus der Arbeit an der ursprünglichen Aufgabe ergeben.

Jede Aufgabe führt innerhalb des Budgets also garantiert zu einem Wertzuwachs. Den bezeichnet der Resultatsanteil der Lieferung. Zielführende Veränderungen am Code-Repository, d.h. solche, die es einer Lösung der Aufgabe näher bringen, oder solche, die die Korrektheit bzw. Wandelbarkeit erhalten oder erhöhen, sind per definitionem wertvoll.

Der Resultatsanteil ist so groß, wie es die Konzentration innerhalb des Budgets kombiniert mit der Kompetenz zulässt.

Darüber hinaus stellt aber auch das Backlog einen Wert dar. Der besteht nicht in Artefaktänderungen, sondern in Erkenntnissen. Weil keine Lösung mehr innerhalb des Budgets möglich oder auch nur angestrebt ist, müssen Erkenntnisse, die auf dem Weg zur Lösung hin entstehen, explizit gemacht werden. Sie sind nicht mehr ungreifbar in einem Kopf oder in der informellen Kommunikation zwischen Entwicklern, sondern hinterlassen eine nachvollziehbare Spur.

Das Backlog einer Lieferung wird Teil des Gesamtbacklogs. Dessen Einträge stehen ständig zur Disposition. Der Kunde kann also jederzeit den einen hoch priorisieren oder den anderen streichen. Es entsteht durch die Aufgabe der Lösungslieferung deshalb sichtbare Freiheit für die Steuerung. Verschwendung durch Planverfolgung ist nicht mehr nötig.

Inhalt des aus einer Aufgabe resultierenden Backlogs können schlichte Folgeaufgaben sein, die Aspekte der ursprünglichen adressieren, die noch nicht in der Timebox geschafft wurden. Darüber hinaus sind nicht nur erlaubt, sondern sogar gewünscht Aufgaben, die über die unmittelbare Aufgabe hinaus weisen. Vielleicht wurde während der Aufgabenbearbeitung ein Bug gefunden? Das ist eine Information, die ins Backlog gehört. Ihn in der Timebox zu fixen würde die eigentliche Aufgabenumsetzung behindern. Oder die Aufgabe konnte gar nicht erst solide begonnen werden, weil der Code schwer verständlich ist? Das sollte mit einer Refaktorisierungsaufgabe im Backlog protokolliert werden. Oder der Erlediger der Aufgabe konnte sich keinen Reim auf einen Teil der Dokumentation machen? Dann gehört eine Aufgabe ins Backlog, die eine Verbesserung der Dokumentation anfordert.

Bug, Sauberkeitsmangel, Verständnishindernisse: all das sind wichtige Informationen für die Softwareentwicklung. Solche Mängel eher stillschweigend von einzelnen Entwicklern nebenbei kompensieren zu lassen, führt erstens zu einer Überlastung der Einzelnen, zweitens zu Unzufriedenheit, weil damit die Lösungsfindung innerhalb des üblichen Budgets behindert wird, drittens zu einem kontinuierlichen Rückschritt der Produktivität.

Gerade wo kontinuierliche Verbesserung auf dem Banner steht wie bei der Agilität, kann es nicht sein, dass „unterwegs“ gewonnene Erkenntnisse nicht transparent gemacht werden. Das ist jedoch der Fall, solange Lösungen mit großzügigen Budgets erarbeitet werden sollen. Die unselige Verquickung von (Scope, Budget) fördert die lokale Optimierung – die alsbald zu einer globalen Verschlechterung führt. So viel kann man gar nicht Retrospektiven reflektieren, dass man all die en passant gewonnenen Erkenntnisse und irgendwie kompensierten oder umgangenen Probleme finden und verarbeiten könnte. Eine Retrospektive findet schlicht zu spät und zu weit weg vom Geschehen statt.

Wenn allerdings Erkenntnisse zur Lieferung gehören… dann ändert sich alles. Dann gibt es eine Motivation für jeden Entwickler, sie zu gewinnen. Voraussetzung dafür ist allerdings die Aufgabe des Lösungsversprechens und die Minimierung der Timebox.

Sehen Sie es so: Softwareentwicklung ist eine forschende Tätigkeit. Lieferungen an den Kunden sind darin Experimente, die eine Hypothese über die Anforderungen und eine dazu passende Lösung bestätigen oder widerlegen. Und zur Forschung gehört es, Erkenntnisse zu publizieren. Das geschieht hier mittels des Backlogs als Teil der Lieferung und anschließend in Form von weiteren Resultaten.

Diese Art der Softwareentwicklung nenne ich resultatsorientiert (oder: Results-Oriented Software Development (ROSD)) und wurde dazu angeregt durch die Beschäftigung mit XDSD (eXtremely Distributed Software Development).

Übliches Vorgehen ist schmerzhaft lösungsorientiert. Echt agiles Vorgehen, so meine ich, ist hingegen resultatsorientiert. Oder etwas mehr fürs Management formuliert: agile Softwareentwicklung ist wertorientiert. Denn auch wenn der Blick zunächst zu den Resultaten geht, stellen die Backlogs der Lieferungen ebenfalls Wert dar. Sie tragen dazu bei, dass die Entwicklung nicht stehenbleibt. Fortschritt wird gemacht!

Bei ROSD erwächst aus einer initialen Aufgabe ein Baum an weiteren Aufgaben, an dessen Ästen Resultate als Früchte hängen. Ist das nicht ein schönes Bild? ;-)

Wie weit der Kunde einen Resultatsbaum wachsen lässt, wie viele Früchte er davon ernten will, bis sein Lösungskorb voll ist, das entscheidet er. Er kann den Baum wild sprießen lassen oder ihn beschneiden.

Über den Fortschritt des Resultatswachstums wird der Kunde mit jeder Lieferung informiert. Er bewegt sich also auf einem Strom von Wertzuwächsen, in dem er steuern kann. Abgerechnet wird stets das fixe, kleine Budget, also pro Resultat. Geld für glasklare Leistung bei voller, feingranularer Kontrolle. Was will der Kunde mehr?

—

In diesem Sinne beende ich auch diesen Artikel. Ich hatte mir dafür eine Timebox eingerichtet, die nun ausgefüllt ist. Eine komplette Beschreibung dessen, was ich mir unter wahrhaft agiler Softwareentwicklung vorstelle, habe ich Ihnen darin nicht liefern können. Ich bin untröstlich, keine Lösung für Ihre Probleme geliefert zu haben ;-) Doch selbst wenn das schön gewesen wäre, es war nicht mein Ziel. Stattdessen habe ich Ihnen Denkanstöße gegeben - ob Sie mit mir übereinstimmen oder nicht ;-) Das sind meine Resultate für Sie.

In meinem Backlog stehen nun weitere Themen, die ich in dem einen oder anderen Artikel noch abhandeln will. Wie steht es z.B. mit der Teamorganisation bei einer ROSD-Entwicklung? Oder woher weiß man, wie viel ein ROSD-Projekt kostet?

Stay tuned!