Agile Projekte haben den Ruf, öfter und besser zu funktionieren als klassische. Dennoch: Auch agile Projekte laufen manchmal aus dem Ruder. Woran liegt das? Aus unserer Erfahrung liegt es oft daran, dass im Requirements Engineering (RE) und der Planung etwas nicht passt. Ja, auch technische Herausforderungen können ein agiles Projekt ins Schlingern bringen. Gutes agiles RE und Planen sollte dieses Schlingern jedoch früh erkennen und abfangen und so Risiko und negativen Impact minimieren. Das geschieht oft nicht. Oft planen „Agilisten“ nur auf Sicht, hangeln sich von Sprint zu Sprint im Wochenrhythmus vorwärts, sehen nur Bäume und verlieren den Wald aus den Augen. Die Folge ist, dass der intelligente Plan für das große Ganze fehlt. Natürlich ist das ein Missverständnis des agilen Ansatzes, à la „Wir sind jetzt agil, wir müssen nicht mehr planen“. Nichts könnte von der Wahrheit weiter entfernt sein – agiles Vorgehen heißt, dass man mehr plant, nicht weniger. Aber fangen wir mit den weniger komplexen Problemen (Irrtümern) an. Nämlich wie im agilen Projekt sog. Requirements verstanden werden.

Im agilen Projekt gibt es (fast) keine Requirements

Wie, was, warum? So ein Unsinn. Natürlich gibt es Requirements in unserem Projekt. Wir wissen, dass wir eine Online-Plattform für Wohnungsmakler bauen wollen. Man muss sich einloggen können, Bilder hochladen usw. usf.

Schauen wir genauer hin. Wenn man agiles RE ernst nimmt, dann macht man es nutzerzentriert und wertzentriert. Sie haben sicher schon von sog. „User Stories“ gehört, mit denen das RE im agilen Projekt oft gemacht wird. Eine User Story hat das Format „Als [Rolle] will ich [Funktion], damit [Wert]“. Also z. B. „Als Wohnungsmakler will ich mich auf der Plattform einloggen, um Bilder für Objekt 12345 hochzuladen“. Ganz brav haben wir eine Rolle verwendet, nämlich unseren Nutzer, den Makler, und aufgeschrieben, was er tun will und warum er es tun will. Offensichtlich ist das Ganze ein Requirement.

Käme ich zum Projektleiter und fragte ihn „Erklär mir mehr, was will der Makler eigentlich erreichen?“, dann wäre die Antwort „Naja, steht doch da, er will halt Bilder zu einem Objekt hochladen“. Jeff Patton, der Autor von „User Story Mapping“ (ein Must-Read für agile Projektmanager) beschreibt scherzhaft, dass er irgendwann verstanden hat „Requirement“ heißt „Shut up“. Nachfragen sind unerwünscht, weil offensichtlich sinnlos.

User Story – ganz einfach, oder?

Dabei ist das eine eher ziemlich schlechte User Story. In einer User Story geht es darum, wie immer im agilen RE, auszuloten, was eine bestimmte Rolle, etwa der Makler, Wertvolles erreichen will im Kontakt mit unserem Produkt – sei es Plattform, Software oder sonstiges. Kent Beck, der Erfinder der agilen Methode Extreme Programming und Vater der User Story hat genau deshalb den Benutzer in den Mittelpunkt gestellt und den Wert in den Vordergrund.

Die o.g. User Story „Als Wohnungsmakler will ich mich auf der Plattform einloggen, um Bilder für Objekt 12345 hochzuladen“ behauptet, dass sich jemand einloggen will – aber kein Mensch will sich einloggen. Und er will auch keine Bilder hochladen. Das Requirement für ihn ist, seine Objekte möglichst gut auf dem Markt zu vermitteln. Wir gehen davon aus, dass Bilder dafür ein gutes Mittel sind (ich würde zustimmen), aber wir wissen es nicht. Wir reden nicht über ein Requirement, sondern über eine Hypothese: Wenn das Objekt mit Bildern ausgestattet ist, ist es besser vermittelbar. Wenn man das wirklich annimmt, muss man testen: Müssen es viele Bilder sein? Große Bilder? Stimmungsvolle oder eher nüchterne Bilder? Und so weiter.

Deshalb ist es im agilen Vorgehen, bei dem es um schrittweises Vorgehen in Richtung des idealen Ergebnisses geht, nicht sinnvoll, von Requirements zu sprechen. Mit Ausnahme von Rahmenbedingungen, die fix sind, auf die wir keinen Einfluss haben, etwa gesetzliche Vorgaben oder Technologieentscheidungen, die unumstößlich sind. Was aber ansonsten Requirements sind, wissen wir erst, wenn wir den Erfolg unserer Ergebnisse im Projekt testen. Wenn Sie etwas produzieren, was dann kein Mensch benutzt, war es offensichtlich kein Requirement. Deshalb kann es beim iterativen, inkrementellen Vorgehen eigentlich kaum ein Requirement geben. Wüssten wir sicher, dass es ein Requirement ist, bräuchten wir nicht agil vorzugehen.

Ok, wollen wir nicht wortklauberisch sein. Letztlich ist es egal, wie wir die Dinge nennen, wenn wir uns einig sind. Nennen wir es Requirement. Aber machen wir uns bewusst: Die Illusion, dass wir wissen, was genau das Ergebnis des Projekts sein soll, en detail und mit Sicherheit, ist gefährlich. Sie verstellt unseren Blick darauf, was eigentlich Wert hat und welche Hypothesen wir schrittweise testen sollten, um nicht Zeit, Geld und Energie zu verschwenden.

Und wie lange dauerts jetzt? Und wie viel kostets?

Es gibt kaum zwei Fragen, die einen Produzenten oder Dienstleister mehr drücken, und es gibt kaum einen Auftraggeber, für den sie nicht von höchster Brisanz wären. Selten hat man einen Kunden, der sagt: „Mir egal, wie viel Geld Sie verbraten, und wann es fertig ist, ist auch nicht so wichtig.“

Um diesem Problem zu begegnen, wird in klassischen Projekten meist mit Festpreis und scheinbar klarer Spezifikation gearbeitet. Im agilen Vorgehen wird geschätzt. Vielleicht kennen Sie die sog. „Story Points“. Eine User Story wird in Story Points geschätzt, daher der Name. Story Points sind ein elastisches Maß, das Aufgaben grob in Größenordnungen einteilt. Man verwendet meist die Skala 1, 2, 3, 5, 8, 13, 20, 40, 100 und schätzt vergleichend, also: Wenn diese Aufgabe eine 3 ist, dann ist jene mindestens eine 8. Nicht wenig agile Teams schätzten auch einfach nur in T-Shirt-Größen, also Small, Medium, Large, X-Large. Manche schätzen sogar in Zeit, wobei das sehr kritisch zu sehen ist. Zeitschätzungen suggerieren eine Exaktheit und Belastbarkeit, die bei Schätzungen grundsätzlich nicht gegeben ist.

Warum überhaupt schätzen?

Der Wert von Schätzungen liegt darin, dass sie das Abarbeiten von Aufgaben planbar und finanziell bezifferbar machen. Und wenn das ginge, wäre es eine super Sache. Es geht aber nicht. Schätzungen sind immer nur grob. Wenn Ihnen jemand sagt „Diese Aufgabe zu bearbeiten wird 16 Stunden brauchen“ dann lügt er in den meisten Fällen. Bewusst oder dazu politisch gezwungen. Gutes Schätzen ist wahnsinnig schwierig, wie die meisten Statistiken bzw. Projektverläufe leider zeigen. Deshalb wäre es die Überlegung wert, das Schätzen einfach bleiben zu lassen, denn es ist schwierig und bringt nicht viel.

Wann ist Schätzen nötig?

Wenn Sie sich sicher wären, dass ich das Bestmögliche mit Ihrem Geld mache und wir uns alle zwei Wochen verabreden, um die Fortschritte zu begutachten… Bräuchten Sie dann Schätzungen auf Ebene einzelner Aufgaben? Ich denke nein. Moment, aber Sie müssten dennoch eine Aussage von mir bekommen, ob wir insgesamt über die nächsten 8 Monate das Ganze gewuppt kriegen. Also mit 10-Kilometer- Flughöhe betrachtet, ohne Details, so das Große und Ganze: Kriegen wir das hin? Auch dafür brauchen Sie keine Schätzung, sondern nur ein Ja oder Nein.

Voraussetzung für den inhärenten Vertrauensvorschuss, sind drei Dinge:

• Sie glauben mir, dass ich nur und stets das Beste für Sie tue. Vertrauen ist wichtig; ohne Vertrauen ist agile Zusammenarbeit gar nicht möglich.
• Sie wissen, dass ich die inhaltliche und planerische Expertise habe (i.e. Erfahrung), um überhaupt ein Ja oder Nein antworten zu können.
• Wir gehen in kleinen Schritten voran, damit Sie aussteigen können, wenn Punkt 1 oder 2 sich als Flop erweisen.

Schätzen müssen wir jetzt nur noch, um auszuloten, ob wir vom vermuteten Business Value her das kleinstmögliche Experiment zum Thema X wagen sollen. Ein Beispiel: Joshua Kerievsky (Begründer von Modern Agile) versprach sich etwas von einem Live-Chat-Feature, mit dem sich die Besucher seiner Lernplattform austauschen könnten. Natürlich wusste er nicht, wie viel das Feature wirklich bringen würde. Er ließ einen Button auf die Plattform machen „Jetzt mit anderen Besuchern chatten“. Der Button tat nichts, außer eine Meldung anzuzeigen: „Dieses Feature steht in Kürze zur Verfügung – wie wahrscheinlich werden Sie es nutzen?“ Nur 6% der Besucher klickten den Button und von denen hielt es die Mehrheit für nicht höchstwahrscheinlich, dass sie das Feature nutzen würden. Also entschied er, die Idee fallenzulassen. Der Chat war wohl kein „Requirement“ – kaum ein Mensch wollte ihn haben.

Die Schätzung, wie viel es kosten würde, diesen Chat zu bauen, ist unnötig. Wir müssen nur wissen, wie viel es kostet, den Button und ein Tracking einzubauen – fast nichts. Dann müssen wir entscheiden, ob der vermutete Business Value dafür steht, dass wir dieses kleine Geld ausgeben.

Schätzen ist nicht wichtig für Planung, sondern für Entscheidung

Deshalb ist Schätzen nicht wichtig. Es ist ein Hilfsmittel, um zu entscheiden, ob man etwas ausprobieren will, eine Hypothese testen, wie die mit dem Online- Chat. Es ist kein Instrument, das uns zur Aussage führen soll: „In x Monaten bekommst Du y Stories zum Preis von z Euro.“ Diese Aussage kann man mit Erfahrung und gesunder Statistik vielleicht machen. Für dieselbe Aussage reicht es aber, Aufgaben zu zählen, statt ihren Umfang zu schätzen, die Vorhersagegüte ist mindestens gleich gut, oft sogar besser. Glauben Sie nicht? Schauen Sie sich das Zahlenmaterial in unserem Whitepaper zu Schätzgüte an.

Besprechen Sie also die Aufgaben im Team, damit alle ein gemeinsames Verständnis entwickeln und Input und Kritik liefern können. Aber vergessen Sie das Schätzen. Betrachten wir die Kanban-Community: Kanban schätzt gar nicht. Weil kontinuierlicher Arbeitsfluss und gelungene Entscheidung „Was wollen wir als nächstes“ wichtiger sind, als die Größe der Aufgaben.

Das alles klingt vielleicht merkwürdig. Doch denken Sie daran: Agiles Projektvorgehen ist ein grundsätzlich anderes Vorgehen als klassisches. Es ist nicht dasselbe in grün, es ist etwas wirklich anderes, auch wenn viele das nicht so leben.

Und das Ganze funktioniert nur gut, wenn wir das Projekt nach den Regeln der Kunst agil durchführen, und damit sind wir beim letzten Mythos, den dieser Text angreifen will: Der geplante Scope besteht nicht aus Features und Nicht-funktionalen-Anforderungen. Er besteht aus Impact-Hypothesen. Deshalb müssen wir anders planen.

Wie ein agiles Projekt planen?

Ein klassisches Projekt ist plangetrieben, ein agiles Projekt ist wertgetrieben. Wie aber beurteilen wir den Wert? Denn wir kennen ihn ja nur ungefähr bzw. vermuten ihn, sonst wäre jede Produktentwicklung ein Welterfolg, jedes Feature ein Killer-Feature, jedes Projektergebnis der reine Wahnsinn. Wenn wir den Scope eines agilen Projekts in Features und anderen Anforderungen betrachten, sitzen wir einem Irrtum auf: Dem Irrtum, dass wir die Zukunft kennen können.

Natürlich gibt es Dinge, die fix sind, das ist selbstverständlich. Nicht-funktionale Anforderungen wie Performance und Sicherheit. Funktionale Anforderungen wie die Wahl des Zahlungsmittels in einem Shop, die Auswahl eines Bildes in einer Blogging-Software, die Wahl eines Status in einem CRM-Funnel. Das steht gar nicht infrage. Im agilen Planen wird jedoch das Was vom Wie getrennt, auf der Ebene der User Stories, aber auch auf den höheren Betrachtungsebenen. Denn was wir wollen, ist nicht Scope, sondern Wirkung. Alles, was wir tun, in Projekten und in unserer Arbeit, zielt darauf an, dass andere dadurch etwas tun können oder an die Hand bekommen, was Wert für sie hat. In Ihrem Shop wollen Sie also im Grunde keinen Checkout, sondern einfach nur, dass maximal viele Kunden genau das finden und kaufen, was sie wollen. Vielleicht mithilfe eines Checkouts – vielleicht auch anders.

Lieber Impact als Features – Ziele erreichen statt Listen abarbeiten

Die beiden agilen Größen Jeff Patton und Gojko Adzic haben unabhängig voneinander zwei Ansätze popularisiert, die gut zusammenpassen und genau das leisten, was wir brauchen: Story Mapping stellt den Scope eines Projekts auf verschiedenen Ebenen dar, über das Produkt und die Zeitschiene abgetragen. Impact Mapping stellt unsere Annahmen klar, welche Wirkung (Impact) wir uns von welcher Maßnahme versprechen, wer beteiligte Akteure sind und wie wir das Ganze testen könnten.

Ein agiles Projekt nur mit einem Backlog voller User Storys zu managen, ohne Big Picture, z. B. mit Story Maps, ist eine hochgefährliche bad practice. In der Infobox sieht man eine exemplarische Story Map. Noch wichtiger ist die Impact Map. Sie macht uns klar, dass die Outcomes, die wir mit unserem Projekt erzielen wollen, auf Annahmen basieren, wir müssen diese Annahmen explizit machen, analysieren, überprüfbar machen. So wird klar: Der Scope unseres Projekts besteht nicht aus Requirements, sondern aus Impact, den wir erreichen wollen. Ach so, ja, das gilt nicht, wenn wir auf die Projektlaufzeit genau wissen, was an Outcome benötigt wird. Dann können wir klassisch durchplanen. Kennen Sie ein Beispiel, wo Sie zu 100% im Voraus wissen, was benötigt wird, für eine nennenswerte Zeitspanne, etwa ein halbes Jahr? Ich glaube nicht an so etwas. Wenn Sie ein Beispiel haben, dann schreiben Sie es mir bitte (das meine ich ernst) unter einspruchtechdivision.com.

Diese Aussage von Dwight Eisenhower verdeutlicht, warum man im agilen Projekt sogar mehr planen muss, als im klassischen. Wenn sich alles durchplanen lässt und spezifizieren bis auf die granularen Ebenen des „Wie machen wir es genau“, dann muss man vor Beginn des Projekts Zeit aufwenden, um einen guten detaillierten Plan zu machen. Danach folgt die Execution, man muss dann per Definition nicht mehr planen, weil der Plan schon steht, umplanen muss man nur im Fall von Störungen. Wenn die Bedingungen es zulassen, planen Sie Ihr Projekt unbedingt auf diese Weise. Das ist billiger als ein agiler Ansatz. Es zeigt sich nur, dass diese Bedingungen in der Realität beinah nie gegeben sind, außer bei kleinen kurzen Projekten.

Die oben genannten Techniken Impact Mapping und Story Mapping gliedern den Scope eines Projekts vom Warum her, von den Zielen und dem Impact, den wir uns wünschen. Die Abbildung zeigt, dass die Spezifikation nachgelagert ist, zeitlich wie inhaltlich. Da wir uns im agilen Projekt dem Ziel iterativ und inkrementell nähern, also Schritt für Schritt in kleinen Teilstücken und Experimenten, muss in einem agilen Projekt ständig (um)geplant werden. Denn während unsere Ziele und die gewünschten Impacts eher gleich bleiben, ändern sich unsere Erkenntnisse über das Nutzerverhalten beständig, und wir lernen Stück für Stück, wie wir dem eigentlichen Ziel nahekommen. Das eigentliche Ziel besteht in der Realität nämlich nicht in Planerfüllung, sondern im Erzielen der erhofften Wirkungen – auf den Nutzer und den Markt.

Iterativ und inkrementell?

Agiles Vorgehen ist iterativ und inkrementell. Was heißt das? Ein Inkrement ist ein Teilstück des angestrebten Gesamtergebnisses. Wir bauen eine Straße von München nach Berlin, das Stück bis Nürnberg ist ein Inkrement. Eine Iteration ist eine Variante des Inkrements, es kann mehr oder weniger „Implementierungstiefe“ haben, wie man oft sagt. Es kann eine einspurige Landstraße bis Nürnberg sein, dann können Autos schon mal nach Nürnberg fahren – lange, bevor unser gesamtes Projekt fertig ist. Es kann auch nur ein Trampelpfad sein, damit wir mit dem Motorrad erkunden können, ob uns auf dem Weg bis Nürnberg Überraschungen erwarten. Und mit dem wir feststellen, ob überhaupt irgendwer nach Nürnberg will. Jurgen Appelo, Vater von Management 3.0, hat den Satz geprägt: „Wir inkrementieren, um uns anzupassen; wir iterieren, um uns zu verbessern.“ Auf unser Beispiel gemünzt: Das Inkrement nach Nürnberg hat gezeigt, dass kein Mensch in die Richtung fahren will, Nutzerfeedback hat uns gezeigt: „Wir wollen nach Italien, nicht nach Berlin!“ Also passen wir uns an. Die Iteration „Landstraße nach Verona“ (statt Nürnberg, unsere Kunden wollen nicht nach Nürnberg) hat uns gezeigt, dass das Businessmodell „Fahrzeuge nach Italien bringen“ funktioniert. Lasst uns die Landstraße zu einer Autobahn ausbauen, um mehr Fahrkomfort und Geschwindigkeit zu bieten. Und ja, die Metapher hinkt; das ist immer so; wenn Sie Widerspruch anmelden wollen, schreiben Sie uns unter: einspruchtechdivision.com