Wir alle haben (hoffentlich) schon einmal davon gehört, dass auch im frühen Scheitern einer der größten Vorteile Agiler Entwicklung liegt. Die wenigsten von uns haben sich jedoch schon einmal Gedanken darüber gemacht, was das eigentlich bedeutet. Einer der Gründe dafür liegt darin, dass wir oft von Agilität sprechen, aber eigentlich Wasserfall im Kleidchen meinen.
Unter dem Begriff »Wasserfall im Kleidchen« stelle ich mir z.B. folgendes Szenario vor: Wir treffen eine Entscheidung für ein Produkt mit einem – wie wir in Scrum gelernt haben – nur vorläufigen Featureset. Das alles ist sehr grob gefasst, damit wir noch viel Flexibilität haben und während der Entwicklung an den Details schrauben können. Das halten viele Product Owner und Scrum Master leider schon für ein Agiles Vorgehen.
Bitte verstehen Sie mich nicht falsch. Grundsätzlich ist das richtig und bewährt. Was leider nur allzu oft fehlt, ist der Check, ob man überhaupt noch in die richtige Richtung läuft. Viel zu oft beobachte ich, dass Teams eine einmal getroffene Entscheidung nicht mehr hinterfragen. Man kommt in den gewünschten Zyklus kontinuierlicher Deployments und regelmäßiger neuer Features für den Kunden. Selbstzufrieden wird dann das Geleistete und das System betrachtet. Die Anwender meckern nicht, also wird daraus geschlossen, dass das Gelieferte auch das Gewünschte ist.
Wir bewegen uns eigentlich in einem Plan-Do-Check-Act-Zyklus (5 Kröten ins Phrasenschwein und ein Kreuzchen auf der Bullshit-Bingo-Karte), der vorsieht, dass wir uns regelmäßig selbst überprüfen, unsere Entscheidungen, unsere Richtung und unser Vorgehen. Es wird jedoch nichts darüber gesagt, wie oft diese Überprüfung stattzufinden und wie sie auszusehen hat. Und genau da liegt die große Gefahr. Jedes Team und jedes Projekt trifft diese Entscheidung für sich selbst.
Wir wissen, dass Menschen dazu neigen (das liegt einfach in unserer Natur), ungern zu scheitern und sich ungern zu irren. Niemand hört gern, dass er einen Fehler gemacht oder eine falsche Entscheidung getroffen hat. Wir gehen in unserer Arroganz (und in diesem Fall ist das genau das richtige Wort) sehr gern davon aus, dass eine einmal getroffene Entscheidung Bestand hat. Selbstverständlich gibt es Ausnahmen, aber meine Erfahrung zeigt leider, dass die wenigsten Teams den regelmäßigen Check fest in ihrem Vorgehen verankert haben. In den Retrospektiven wird darüber gesprochen, wie man effizienter in die einmal eingeschlagene Richtung laufen könnte, wir fragen uns aber nur sehr selten, ob diese Richtung überhaupt die richtige ist.
Was sollten wir also tun? Was sollten wir wann wie überprüfen? Zunächst einmal muss uns klar werden, das alles jederzeit auf dem Prüfstand steht. Jedes Feature, das wir ausrollen, sollte auf seine Akzeptanz hin gecheckt werden. Wird es von den Kunden genutzt? Wie sieht das Feedback aus? Gibt es überhaupt einen einfachen Weg für den Anwender, Feedback zu geben? Wenn wir uns nicht darum kümmern, dürfen wir uns auch nicht wundern, wenn wir keine Kritik hören und immer meinen, dass alles in Ordnung sei.
Wir haben das Ziel, nicht nur nach jedem Sprint neue Features ausgerollt zu haben, sondern auch nach jedem Sprint ein wenig schlauer geworden zu sein. Wir wollen lernen, wie unser Anwender mit den von uns gelieferten Produkten arbeiten, wir wollen aber auch ihre Wünsche und Anforderungen immer besser verstehen lernen. Und genau das ist mit Fail Early gemeint.
Zu Beginn des Projekts (oder des Teil-Projekts) haben wir vielleicht Ergebnisse aus Kundenbefragungen und unsere eigenen Erfahrungen aus Feedbacks früherer Projekte. Auf Basis dieser Informationen treffen wir unsere Entscheidungen, was vollkommen richtig und nachvollziehbar ist. Uns muss jedoch zu diesem Zeitpunkt schon bewusst sein, dass unsere Informationsbasis immer lückenhaft ist. Wir treffen unsere Entscheidungen auf Basis der zu einem bestimmten Zeitpunkt verfügbaren Informationen. Das bedeutet aber auch, dass sich diese Basis mit der Zeit erweitert. Wir sprechen mit unseren Anwendern, den Stakeholdern, beobachten den Markt, verfolgen technische Entwicklungen. Mit all diesen im Laufe der zeit immer weiter wachsenden Informationen kann es sein, dass wir feststellen, dass unsere einmal getroffene Entscheidung keinen Bestand mehr hat, dass es nicht mehr sinnvoll ist, die einmal eingeschlagene Richtung weiter zu verfolgen.
Dieser Gedanke hat mehrere Aspekte: zum einen müssen wir bereit sein, die Arbeit von mehreren Sprints wieder einzustampfen ohne darüber zu jammern, dass wir wieder Dinge für die Tonne produziert haben, zum anderen müssen wir der Versuchung widerstehen, den eingeschlagenen Weg rückblickend zu verdammen. Jede Entscheidung, die wir treffen, ist zuerst einmal richtig. Wir treffen sie auf Basis der uns zur Verfügung stehenden Informationen. Wir versuchen, so viele Informationen zusammenzutragen, wie wir können, um eine tragfähige Entscheidung treffen zu können, und wir wägen sorgfältig ab.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Es ist immer leicht, rückblickend zu sagen, dass man eine falsche Richtung eingeschlagen habe. Noch leichter ist es, Schuldige für die vermeintliche Fehlentscheidung zu finden. Das führt uns jedoch nicht weiter. Sinnvoll ist es hingegen natürlich, sich zu fragen, welche neu gewonnenen Erkenntnisse zum Umdenken geführt haben. Einzig zielführend ist dabei allerdings nur die Frage, ob wir nachlässig gewesen sind, um daraus für die Zukunft zu lernen.
Man wird immer sagen können, dass – wenn wir anders gefragt hätten – wir diese Erkenntnis schon früher hätten haben können, aber woher hätten wir wissen sollen, wie wir zu fragen haben? Wir haben eine Entscheidung getroffen, es hat nicht funktioniert, wir lernen daraus für die Zukunft – fertig.
Der Vorteil des frühen Scheiterns muss nicht lange diskutiert werden. Wie viel teurer (in allen Beziehungen) wäre es, erst nach einem Jahr zu merken, dass man sich in seinen Annahmen geirrt hat, anstatt dies schon nach vier Wochen zu wissen? Wir müssen dabei nur eins lernen: es ist nicht schlimm, sich zu irren.
Haben wir das einmal verstanden und verinnerlicht, sollte es uns möglich sein, den ständigen Selbstcheck in unseren Abläufen unterzubringen und auch nicht nur als Alibi-Veranstaltung einzuplanen. Dabei beginnen wir damit, unsere Erkenntnisse zu dokumentieren. An dieser Stelle höre ich schon den einen oder anderen aufschreien und auf das Agile Manifest verweisen. Natürlich stimme ich dem zu, dass funktionierende Software wichtiger ist als ausufernde Dokumentation, aber zum einen spreche ich hier von einer anderen Form der Dokumentation, und zum anderen sollte niemand widersprechen, wenn ich sage, dass es ziemlich dumm wäre, überhaupt nichts zu dokumentieren. Dieses Fass möchte ich an dieser Stelle aber nicht noch weiter aufmachen. Lassen Sie uns also zu den immer weiter wachsenden gewonnen Erkenntnissen zurückkehren.
Diese beschränken sich nicht nur darauf, was wir von unseren Anwendern lernen, dazu zählen auch unsere eigenen Erfahrungen. Das kann z.B. sein, dass das Team (aus welchen Gründen auch immer) wesentlich langsamer voran kommt, als ursprünglich angenommen, oder dass die Aufwände ursprünglich wesentlich geringer eingeschätzt wurden, als sie tatsächlich sind. Das kann bedeuten, dass die geplanten Features für den Kunden zwar durchaus interessant sind, der Entwicklungsaufwand aber so hoch ist, dass es sich nicht lohnt. Vielleicht hat auch ein Mitbewerber eine hervorragende Lösung fertiggestellt, mit der er den gesamten Markt aufrollt, so dass unsere Lösung plötzlich wesentlich weniger relevant für die Zielgruppe wird. All diese Dinge sind möglich und sollten in unsere Überlegungen einfließen.
Wie oft sie neue Erkenntnisse bewerten und die eigene Richtung überprüfen, steht Ihnen natürlich frei. Wenn ein Big Bang erfolgt ist (z.B. das Release des Mitbewerbers) dann ist die Sache einfach. Der Prozess wird gewissermaßen von außen getriggert. In der Regel ist die Situation aber eher die, dass sich im Laufe mehrerer Sprints eher unbewusst neue Erkenntnisse ansammeln. Man spürt also keinen Bedarf und fällt in eine Art »Agilen Trott« und macht immer so weiter. Ich rate dazu, alle zwei bis drei Sprints einmal zusammenzukommen und sich zu fragen, welche neuen Erkenntnisse man in den letzten Wochen gewonnen hat, und was diese im Zweifel für Auswirkungen auf das Fortschreiten haben. Zunächst einmal innerhalb des Teams, aber sicherlich auch auf der Ebene PO – Stakeholder.
Allein sich einmal zurückzulehnen und sich die letzten Wochen anzusehen – was hat man getan, und was hat man gelernt – reicht vollkommen aus. Wir sind vernünftig genug, zu erkennen, wenn es ein Problem gibt, oder wenn sich die Lage geändert hat. Wir benötigen dafür keinen weiteren Prozess, wir benötigen lediglich die Bereitschaft, ein frühes Scheitern zu akzeptieren.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
