No Estimates – Stop creating waste

What is No Estimates? Does it mean that we do not have to estimate at all? Basically, yes. This approach is based on ideas from Lean Manufacturing, and we can use it on the team as well as the organizational level. The big benefit of No Estimates is a significant one: it enables us to save vast amounts of time that we would usually spend on estimating the required time to deliver a specific feature.

Join me in my new video to find out how it works.

 

Dynamic Magic Estimation – Funktionalität schätzen 3.0

 
Schätzen. Egal, ob Funktionalität oder Aufwand geschätzt wird, es ist ein ewiges Thema. Hinzu kommen die verschiedenen Nachteile verschiedener Methoden, wie zum Beispiel die recht leichte Beeinflussbarkeit beim Planning Poker oder die Dauer des Team Estimation Games.
Ich präferiere das Verfahren „Magic Estimation“, das Boris Gloger entwickelt hat (basierend auf der Idee zu „Affinity Estimation“ von Lowell Lindstrom). In der Umsetzung hat sich bei einigen Teams jedoch herauskristallisiert, dass durch das Nichtkommentieren von Änderungen beim Umsortieren von User Storys das gemeinsame Verständnis der Funktionalität (oder den Aufwand) nicht vertieft wird und so oftmals im Nachhinein Unsicherheiten, manchmal auch angeregte Diskussionen entstehen.
Diesem Umstand begegne ich durch das Hinzufügen der kurzen Erklärung beim Umsortieren einer User Story beim Team Estimation Game zur Magic Estimation. Als alternative Variante kann man auch die bei Magic Estimation üblicherweise vorhandene Skala weglassen.
Dynamic Magic Estimation läuft dann gemäß dem Ablauf der Magic Estimation, wie er von Boris Gloger in seinem Buch „Wie schätzt man in agilen Projekten“ dargestellt (und von dort zitiert) wird, so ab:

    1. Der Product Owner bereitet die User Storys vor.
      1. Geeignet sind Ausdrucke in DIN A4, mit Versalien
      2. Nummerierung nach aktueller Priorisierung nicht vergessen!
    2. Der ScrumMaster hat die Skala vorbereitet, falls nicht wie im Team Estimation Game darauf verzichtet werden
      soll.
    3. Der Product Owner verteilt die User Storys möglichst gleichmäßig ans Team aus.
      1. Diese wichtige Regel bleibt erhalten: Ab hier wird die Estimation schweigend gespielt, auch nonverbale
        Kommunikation sollte nicht stattfinden.
    4. Die Teammitglieder lesen ihre User Storys und legen sie auf der Skala zu jener Zahl, die nach Meinung des
      jeweiligen Teammitglieds die Größe der User Story darstellt.

      1. Sollte ohne Skala gespielt werden, beginnt ein Teammitglied seine User Storys abzulegen. Hat das
        Teammitglied alle seine User Storys abgelegt, ist das nächste Teammitglied dran.
        Hierbei gilt die Regel aus dem Team Estimation Game:
        Eine User Story ablegen, die nächste wird der Einschätzung nach darüber oder darunter abgelegt. Darüber
        bedeutet „kleiner“, darunter „größer“.
    5. Nun liest jedes Teammitglied noch die zuletzt einsortierten User Storys
    6. Jedes Teammitglied kann nun vortreten und eine User Story „verschieben“.
      1. Tritt ein Teammitglied nach vorne, hat es den „Vortritt“, auch wenn alle parallel das Verschieben
        durchführen.
      2. Während des Umsortierens einer User Story gibt das Teammitglied eine kurze (!), diskussionslose
        Erklärung ab.
    7. Der Product Owner beobachtet die User Storys in dieser Phase sehr intensiv, da er herausfinden muss, ob eine
      oder mehrere User Storys „springen“. Diese markiert er mit einem Punkt oder einem sonstigen Merkmal, da hier
      weitere Klärung nötig ist.

      1. Der ScrumMaster notiert die Erklärungen.
        Diese können später noch sehr hilfreich sein, zum Beispiel bei markierten User Storys oder auch im
        Sprint bei der Implementierung.
    8. Das Spiel ist beendet, wenn keine User Storys mehr umsortiert werden oder sich das Team sichtlich langweilt.

Dieses Verfahren beinhaltet alle Vorteile der Magic Estimation, angereichert durch die Erklärungen zum Verständnis einzelner Teammitglieder zu den User Storys. Auch der große Vorteil, dass jede User Story zur Referenz der anderen User Storys wird, bleibt erhalten.
 
Foto Karsten KlopmannAutor: Karsten Klopmann, KI Solutions UG
Produkte schnell und effektiv, mit gesundem Menschenverstand, zu entwickeln ist für mich schon jeher ein Anliegen. Scrum hat mir dazu schon sehr bald den passenden Rahmen geboten. Seit 1999 selbständig, bin ich seit ca. 15 Jahren als ScrumMaster, Product Owner oder Business Analyst auch in skalierten Projekten bis ca. 160 Kolleginnen/Kollegen tätig und es bereitet mir jedes Mal Freude zu sehen wie sich die Teams weiterentwickeln.
 

Video: No Estimates – Durchfluss schlägt alles

 
Es wäre doch schön zu wissen, wie teuer das Abarbeiten eines Backlogs wird, ohne lange schätzen zu müssen. Noch toller wäre es, wenn die ermittelten Werte so gut wie exakt und damit besser als Schätzungen wären.
In diesem Video erkläre ich, wie das funktionieren kann und dabei greife ich auf Ideen aus dem Lean Management zurück.
 
Viel Spaß beim Anschauen — Boris
 

 
 

Entscheidungsgremien: Erfolgsfaktor in agilen Projekten?

In einem unserer Projekte ging es darum, einen Systemverbund zu stabilisieren, der bisher durch eine fehlerverursachende Schnittstelle nur eingeschränkt genutzt werden konnte. Im Vorgängerprojekt sollten die beiden Systeme zusammengeschalten werden – es wurde klassisch abgewickelt und musste schließlich wegen Erfolglosigkeit gestoppt werden. Wegen der guten Erfahrungen mit Scrum in anderen Projekten lag es nahe, im zweiten Anlauf den agilen Ansatz zu wählen – hier kam ich ins Spiel. Und bevor ich weitererzähle, hier mein Appell gleich zu Beginn: Seid bereit, das Management aktiv an die Hand zu nehmen. Sie werden es euch danken!

Klassische Wünsche im agilen Rahmen

Schon in der Setup-Phase wurde klar, dass im vorherrschenden Umfeld ein tatsächlich agiles Projektvorgehen eine wahre Herausforderung werden wird. Erstens lastete hoher Druck auf dem Projekt, die Systeme endlich stabil zu bekommen und jede Form von Mehrkosten zu vermeiden. Zweitens wurde das Projekt noch mit einem zusätzlichen Gesamtprojektleiter, der übergeordnet die Verantwortung für das Projekt trug, besetzt. Und drittens hatten die entscheidenden Personen, allen voran das Top Management in Form eines Lenkungskreises, alles andere als agile Ansätze im Sinn. Beginnend mit der Forderung nach einem Reporting mit dem Fokus auf Budget und Zahlen kam auch schnell die Frage nach dem „großen“ Projektplan über die angesetzten 6 Monate auf. Was wird bis Datum XY geliefert und viel wichtiger: Was kostet dieses Unterfangen?

Ein Schritt zurück, um vorwärts zu kommen

Um dem Management einen groben Projektplan zu bieten, erarbeiteten die Product Owner mit Unterstützung der ScrumMaster einen physischen Releaseplan mit Post-Its. Dabei planten sie nach dem Eisberg-Prinzip: die kommenden Sprints detailliert und die zukünftigen Sprints auf höherer Ebene. Mit diesem Instrument konnten sie nun auch auf Gesamtprojektsicht einen Plan vorweisen. Anfangs wurde das noch skeptisch beäugt und als schwammig kritisiert. Das größte Hindernis war dabei wohl, dieses Nichtvorhersagen-Können zu akzeptieren. In traditionellen Projekten gibt man sich von Anfang an der Illusion hin, alles bis zum letzten Tag hin genauestens geplant und damit im Griff zu haben. Den Schritt zurück zu machen und zu akzeptieren, dass der Plan sehr wahrscheinlich so nicht eintreten wird, ist schwierig, aber notwendig. Es gelang in diesem Projekt und im Laufe der Zeit entwickelte sich der Releaseplan zu einem zentralen Planungsinstrument.
IMG_0464 Kopie 3

Sehen, worüber wir reden

Trotz des Releaseplans traf das Management in seinem Lenkungskreis (in dem nur der Gesamtprojektleiter, aber kein Product Owner oder ScrumMaster vertreten war) Entscheidungen, die mehr oder weniger große Auswirkungen auf unser Projekt und unseren Releaseplan hatten. Jedes Mal passten die Product Owner resigniert den kompletten Releaseplan an die neuen Entscheidungen an. Bei der x-ten Diskussion über Inhalt und Budget nahmen wir ScrumMaster schließlich das Zepter in die Hand. Wir forderten das Management auf, seine Diskussionen zu neuen Entscheidungen direkt mit uns – den ScrumMastern und Product Ownern – vor unseren Artefakten zu führen und Befürchtungen mit uns zu besprechen. Um es kurz zu machen: Das war die beste Entscheidung, die wir je treffen konnten. Noch nie zuvor hatte es zwischen dem Management (dem Lenkungskreis) und den Projektverantwortlichen einen so regen Austausch über den Scope und das Budget des Projekts gegeben. Alle Unklarheiten wurden geklärt und wir erzielten ein gemeinsames Commitment. Die Teams hielten dieses Commitment auch ein und lieferten.
Im Nachhinein hat es über den Erfolg des Projekts entschieden, dass das Top Management eingebunden wurde und sich mit den Verantwortlichen direkt und regelmäßig ausgetauscht hat. Wie oft hatten wir in der Vergangenheit das Gefühl gehabt, dass reines „Management by Desk“ praktiziert wurde, ohne zu wissen, wie es um das Projekt wirklich bestellt war. Wie oft hatte das Projektteam Angst vor folgenschweren Entscheidungen im Lenkungskreis. Angst davor, dass das Projekt gestoppt werden könnte, trotz erster nachweisbarer Erfolge. Angst vor Budgetkürzungen, die uns den notwendigen innovativen Freiraum nehmen könnten.
Daher nochmals mein dringender Appell: Nehmt euer Management an die Hand! Führt es zu den Artefakten und trefft dort mit den richtigen Personen die richtigen Entscheidungen — gerade und vor allem in traditionell geprägten Unternehmen.

Sag mir, wie du schätzt und ich sage dir, wer du bist

Traditionell fragen Projektmanager ihre Kollegen: “Wie lange dauert es, das zu entwickeln?“ Sie wollen Kosten berechnen, die Länge des Projekts kalkulieren und möglichst früh wissen, wie viele Ressourcen das Projekt braucht.
Diese Fragen deuten immer in die gleiche Richtung: Die Projektmanager wollen die Unsicherheit aus dem Projekt nehmen. Unsicherheiten gibt es in Projekten genug: Haben die Projektmitarbeiter genügend Ahnung? Bekommt man die Technologie in den Griff? Hat man am Ende für das gesamte Projekt genügend Budget? Findet man die richtigen Features für das Produkt? Wird der Kunde es haben wollen? Werden die Kollegen die geeigneten Lösungen schnell genug finden … und, und, und. Kurz, es wird versucht die Zukunft vorherzusagen und gleichzeitig weiß man ganz genau, dass das gar nicht geht. Denn jeden beschleicht das Gefühl, dass man bei einem Projekt ja etwas Neues macht – also etwas, das es vorher noch nicht gegeben hat, etwas, das noch nie gemacht wurde. Alle diese Fragen können also gar nicht beantwortet werden. Mit diesen Fragen bin ich immer in die Diskussion eingestiegen und habe mich dabei gewundert, wie man als Projektmanager überhaupt annehmen kann, diese Fragen zu Anfang eines Projekts klären zu können. 
Dann fragte mich letztens ein Zuhörer bei einem meiner Vorträge: „Ist es denn so? Ist es nicht vielmehr so, dass die meisten Projekte sehr wohl von Leuten gemacht werden, die genau das Gleiche schon einmal gemacht haben? Daher kann man doch sehr genau die Aufwände schätzen.” In diesen Fällen wisse man doch genau, wie lange etwas dauere.

Diesem Argument lässt sich nicht viel entgegensetzen, oder? Denn es ist korrekt: Wenn man mehr oder weniger immer das Gleiche tut, kann man auch Vorhersagen treffen. Auf diesem Prinzip basieren auch alle Ansätze der Schätzverfahren in Scrum-Teams. Wenn man zu irgendeinem Zeitpunkt genug Daten darüber hat, wie lange etwas dauert, dann lassen sich sehr wohl die Aufwände schätzen. Aber Moment: In diesem Fall befindet sich ein solches Team doch gar nicht mehr in einem Projektmodus. In diesem Moment, in dem es wiederkehrende Aufgaben vollbringt, ist es wieder in einem Support-, Maintenance- oder Bug-Fixing-Modus. Aber genau dann sollte man doch sofort vom Projektmanagement hin zu einem klassischen Verfahren der Prozesssteuerung und des Workflowmanagements zurückgehen und wo landet man da? Genau – beim Lean Management des Toyota Production Systems. Dann ist man besser damit beraten sich anzusehen, wie man in Call Centern, in Produktionsbetrieben, in der Logistik oder in Einkaufszentren arbeitet. Dort sollten Logistiker den Ton angeben: Denn Workflowmanagement wird seit 40 Jahren nach dem Pull-Verfahren und dem One-Piece-Flow-Verfahren optimal gesteuert. Es hat lange gedauert, bis sich dieses Wissen durchgesetzt hat, aber es war am Ende erfolgreich. Viele Manager, die Sales-Zahlen vorgeben, Absatzzahlen erfinden und Produktionsziele vorgeben wollen, wollten lange nicht wahrhaben: Der Empfänger des Produkts, meist der Kunde, bestimmt durch sein Kaufverhalten, wie viel ein Unternehmen liefern sollte, und nicht die Annahmen darüber, wie viel der Kunde möglicherweise kaufen wird. Das hat der Handel in den letzten 10 Jahren gelernt und man sieht es jeden Tag an der Kasse der Discounter, wie dieses Prinzip funktioniert.

Dieses Denken hat auch in die Software-Entwicklung Einzug gehalten. Die massive Hinwendung vieler Software-Entwicklungsabteilungen hin zu Kanban – die heute sogar in Tools wie JIRAs Ansatz zur Workflowsteuerung gipfeln – lässt sich so erklären, und sie ist folgerichtig. Wo nichts Neues entwickelt, wo keine Projekte gemacht und einfach das immer Gleiche immer wieder neu angepinselt und noch einmal verkauft wird, da gilt es tatsächlich nichts anders als effizientes Workflowmanagement zu machen. Support-Aufgaben hier, ein Bugfix da.
Es gibt Untersuchungen und IT-Leiter, die behaupten, 70% dessen, was entwickelt werde, wäre nunmal Maintenance. Aus meiner Beobachtung stimmt das. Es ist so – aber wieso? Ist das eine Ursache oder ein Symptom? Ich glaube, dass ist das Symptom. Wenn Software-Entwicklung so durchgeführt wird, wie in vielen Unternehmen heute noch immer und am Ende zu gigantischen Bergen technischer Schulden führt, ja dann schreibt man relativ schnell keine neuen Features, sondern ist ständig damit beschäftigt, das Alte anzumalen oder kleine, völlig unbedeutende Veränderungen vorzunehmen. Die wunderbare Präsentation von Salesforce.com zeigt sehr eindrucksvoll, wie das auch einem Internet-Startup wie Salesforces.com sehr schnell passiert ist.

Aber zurück zum Schätzen. In diesen Umfeldern ist es zwar prinzipiell möglich, Aufwände sogar relativ gut und valide zu schätzen, denn man hat ja eh immer das Gleiche zu tun. Aber es ist völlig unnötig, wie uns die Logistikindustrie gezeigt hat. In diesen Umfeldern hat sich etwas anderes durchgesetzt: Die sogenannte Flusssteuerung, die mit Hilfe statistischer Verfahren die Durchflussgeschwindigkeit und die Höhe der Inputschlange bestimmt, und basierend auf diesen Aussagen die Lieferzeiten sehr korrekt ermitteln kann.
Man braucht also gar nicht mehr zu schätzen, sondern man weiß, wann etwas geliefert wird. Diese Ideen hat Kanban für die Software-Entwicklung populär gemacht – es wurden Serviceklassen eingeführt und nun ist man sehr gut darin, mit diesen Verfahren und WIP-Limits die Auslastung von Teams zu steuern. Jedes Schätzen ist hier Zeitvergeudung und vollkommen unnötig. Erklärt man diesen Umstand, schauen mich Projektmanager oft ungläubig an. Die Prinzipien sind zwar einfach, doch leider liegen diese Erkenntnisse quer zu dem, was der gesunde Menschenverstand sagt und vollkommen quer zu dem, was in vielen Unternehmen zum Thema Auslastung, Workflowmanagement etc. gelehrt wird. Es hat 20 Jahre gedauert, bis in der Automobilindustrie die Ideen von Toyota wirklich angekommen sind.
forward-412761_640

Wenn also Schätzen in diesen Umfeldern nicht mehr notwendig ist, wie ist das dann bei echten Projekten? Also in einem Kontext, in dem etwas versucht wird, das noch nie zuvor versucht worden ist? Ich habe das große Glück, in den letzten beiden Jahren mit Kunden arbeiten zu dürfen, die solche Projekte durchführen. Dort werden tatsächlich Dinge getan, erforscht, erprobt, ausgetüftelt – also Produkte gebaut, die noch nie zuvor ein Mensch gesehen hat. Das ist ein bisschen so wie der erste Mondflug. Man weiß einfach nicht ob es geht. Die einzige Chance, in diesen Projekten zu Ergebnissen zu kommen, ist die Welt zu gestalten. Man erfindet einfach das, was man braucht. Seien es die Entwicklungsmethoden, die Tools oder auch die notwendigen Produktideen. Allerdings ergibt sich aus diesem Vorgehen eine prinzipielles und unlösbares Faktum. Nun kann man einfach nicht mehr voraussagen, wann man fertig ist. Sicher, man kann sich etwas vornehmen, auf ein Ziel hinarbeiten. Doch etwas zu versprechen wäre illusorisch.
Findige Designer haben für Dinge, die nicht zu komplex sind, eine relativ simple Methode gefunden, wie man dennoch Fortschritte dokumentieren kann und wie man sich zumindest auf etwas festlegen kann: Man gibt einen Zeitrahmen vor. Diese zeitliche Grenze erzeugt den notwendigen Druck, zumindest immer auf ein Ziel hinarbeiten zu müssen, sich also nicht selbst zu belügen und einfach ergebnislos vor sich hinzuarbeiten. Zeitliche Grenzen erzeugen den Fokus, man probiert nicht alles aus, sondern liefert mal den erstmöglichen Fortschritt, das erstmögliche Ergebnis. Kann man diesen Zeitrahmen sinnvoll strukturieren? Sicher! Es gibt Techniken wie Design Thinking oder Scrum, die Teams dabei helfen, genau diesen Zeitrahmen zumindest insofern zu strukturieren, dass das Finden von Ergebnissen wahrscheinlicher – nicht aber sicher – wird.

Doch jetzt das Paradoxon: Diese Methoden sind bekannt. Sie sind sogar so erfolgreich, dass die erfolgreichsten Firmen des letzten Jahrzehnts freiwillig erzählen, dass sie darauf setzen. Sie sind sogar in den Firmen bekannt, die bis dato ganz anders gearbeitet haben – dennoch wird stillschweigend noch immer vorausgesetzt, dass man wissen muss, wann zu welchen Kosten und mit welchem Ergebnis auf jeden Fall das geliefert werden soll, was man heute noch gar nicht kennt. Es wird also versucht, diese neuen Methoden in einem Kontext zu leben, der zugegeben hat, dass die Aufgabe unlösbar ist. Deshalb nimmt man die neuen Methoden und gleichzeitig verdrängt man die Tatsache, dass die Aufgabe unlösbar ist.
Aufwände zu schätzen ist in diesen Umfeldern schlicht unmöglich. Das ist jedem klar, und doch wird es immer wieder gefordert. Warum? Der Trugschluss herrscht, dass man mit Hilfe des Schätzens eines bekämpfen könnte: Die Angst, in irgendeiner Weise zu versagen. Es geht also anders ausgedrückt darum, das Risiko zu verringern. Als könne man durch das Schätzen gewährleisten, dass es zu keinem Verlust kommen könnte.

Doch Schätzen ist aus mindestens diesen vier Gründen ungeeignet, das Risiko zu minimieren:

  1. 
Aufwandsschätzungen werden zumeist optimistisch abgegeben. Damit wird das Risiko erhöht.
  2. Aufwände werden als Kostenfaktor gesehen. Damit ist eine hohe Schätzung zwar vielleicht ein Maß für Risiko, aber wirtschaftliche Interessen konterkarieren dieses Thema sofort.
  3. Wir wissen aus den Arbeiten von Eliyahu Goldratt, Autor von „The Goal“, dem einflussreichsten Buch zur Theory of Constraints, dass im Falle dessen, dass Aufwandsschätzungen zu groß waren, dennoch diese Aufwände aufgebraucht werden. Damit erhöht sich das Risiko, die Puffer des Projekts zu sprengen und wenn dann wirklich eine Schätzung zu gering war, bricht man die zeitlichen Grenzen. Das Projekt wird also riskanter.
  4. 
Aufwandsschätzungen sind abhängig von dem, der sie durchführt. Damit erhält man kein objektives Maß für das Risiko.

All das ist hinreichend bekannt. Dennoch erzeugen Aufwandsschätzungen und die sich daran ausrichtende Planung immer wieder die Illusion, das Risiko wäre gebannt.
Was durch das Schätzen von Aufwänden also in Wahrheit geschieht: Das Risiko wird nicht eingeschätzt und bewertet, sondern es wird verdrängt und ignoriert. Wir haben geschätzt und gebannt.
Wie wäre es, wenn wir das Risiko benennen würden, ihm ins Gesicht schauen und es angreifbar machen? Wie wäre es, wenn wir von Anfang an sagen würden: Wir haben hier die besten Kollegen zusammengerufen, die wir haben. Wir lassen Sie das Vorhaben mit ungewissem Ausgang wagen. Wir wissen, dass wir nicht wissen können, wann wir fertig sein werden, doch wir nehmen uns Etappen vor, und wir überprüfen immer wieder, was es braucht, um das Ziel zu erreichen. Was wäre, wenn wir offen darüber sprechen würden, dass wir nicht wissen, ob die Technologie die richtige ist, und deshalb davon ausgehen, dass wir bei neuen Erkenntnissen die Richtung noch einmal wechseln können. Was wäre, wenn wir das Risiko dadurch minimieren, dass wir immer einen kleinen Schritt machen und überprüfen, ob wir auf Kurs sind?
Auch dann wäre es nicht nötig zu schätzen. Man schaut einfach, wie viel man ausgegeben kann und wohin man kommen muss, damit man die nächste Investition rechtfertigen kann. Venture Capitalists gehen so vor – und nicht nur diese. Jeder nutzt genau diese Strategie in seinem eigenen privaten Bereich. Man schaut, was man an Ressourcen hat und dann fängt man an. 
Ist das ideal? Nein, aber der einzige Ausweg für alle, die innovative Produkte auf den Markt bringen wollen.
Für alle, die sich der Unvorhersagbarkeit stellen wollen, habe ich ein Buch geschrieben: Wie schätzt man in agilen Projekten – oder warum Scrum-Projekte erfolgreicher sind.

Schätzt du noch oder baust du schon?

Im einem Projekt verlangte das Management für den kommenden Release, einmal zu schätzen, wie viele Bearbeitertage für die zu liefernde Menge an Funktionalitäten wohl benötigt würden, um einen Forecast abgeben zu können. Die Manager wollten das, weil sie mit der Storypointschätzung per Magic Estimation nicht zufrieden waren. Denn die sagte aus, dass das Scrum-Team bis zur Deadline bei der aktuellen Velocity von 40 Storypoints lange nicht das liefern würde, was eigentlich erwünscht war.
Alte Schule. Statt anzufangen, werden nun viele Arbeitsstunden darauf verwendet, vorherzusagen, wie lange es wohl dauern wird mit der Lieferung. Zeitverschwendung, so meine Hypothese. Zahlen aus 2012 belegen: 74% der IT-Projekte werden in der Zeit überschritten, 59% in den Kosten und 69%, was die Anzahl der gelieferten Features angeht. (Quelle: Standish Group 2013, S.2) Warum also viel Zeit auf die Schätzung verwenden, wenn wir immer wieder sehen, dass sie ohnehin mehr als ungenügend ist?
Ganz einfach: Die Schätzung wird verlangt. Punkt. Eines jedoch sollte die Erkenntnis aus diesen Erfahrungen sein: Lieber mehr Zeit für die Umsetzung verwenden als auf das stunden- oder tagelange Schätzen.
Natürlich gibt es in einem Unternehmen immer Interessengruppen, die Ressourcen und Kosten planen müssen. Aber uns sollte klar sein, dass wir unser „Geschätze“ der Dauer und unsere Methoden stark überdenken müssen. Vor allem auch die Frage, wer denn schätzen sollte. Im konkreten Fall entschied man sich dafür, pro Story und Thema den jeweiligen Experten die Dauer der erwarteten Arbeit schätzen zu lassen. Gefährlich, sage ich, und möchte hiermit auf das Buch „Die Weisheit der vielen“ von James Surowiecki verweisen. Darin behauptet der Autor, dass die Masse stets besser entscheidet als ein Einzelner: „Die Masse ist dumm, dumpf und gefährlich. Dieses verbreitete und von Wissenschaftlern gestützte Urteil ist falsch. Wahlumfragen, Pferdewetten, der Publikumsjoker bei Günther Jauch, Google oder Millionen Steuerzahler belegen: Die Menge entscheidet in der Regel intelligenter und effizienter als der klügste Einzelne in ihren Reihen. Ihre Problemlösungen greifen besser als die von Experten. Vorausgesetzt, jeder Einzelne denkt und handelt unabhängig, die Gruppe ist groß und vielfältig, und sie kann darauf vertrauen, dass ihre Meinung wirklich zählt.“ (aus dem Klappentext)
Prompt versuchte ich nun, Surowieckis Vermutungen in einem kleinen Experiment zu beweisen, um die Schätzweise im Projekt überdenken zu lassen. Ich ließ von jedem im Team schätzen, wie viele orange Bälle in dem Sack waren, den ich mitgebracht hatte. Die Wahrheit lag bei 101 Bällen. Das wusste außer mir jedoch niemand. Die kleinste Schätzung lag bei 50, die höchste (im übrigen von einem Experten für Zahlen) lag bei 150. Im Mittelwert schätzte das Team den Inhalt auf 96 Bälle. Ein beeindruckendes Ergebnis, das erstaunlich nahe an der Realität von 101 lag und die Theorie Surowieckis zumindest unterstützt.
Eine Gruppe von Menschen (je größer desto besser) schätzt immer genauer als der klügste Einzelne.
Genau das ist der Grund dafür, warum der Publikumsjoker bei „Wer wird Millionär“ in den meisten Fällen so zuverlässig funktioniert.
Auch dafür, warum eine Gruppe von Experten mit je nur einem Tipp es 1968 schaffte, den Standort des im im Atlantik havarierten U-Bootes “Skorpion” auf 75 Meter genau zu ermitteln.
Bei all diesen plakativen und hochinteressanten Beispielen erinnern wir uns daran, worum es geht: Mehr Zeit in die Umsetzung als in das aufwändige Schätzen zu stecken.
Bleibt nur noch die Frage: „Schätzt du noch, oder baust du schon?“

Von Zahlenfetischismus und anderen Angewohnheiten

Letztens im Sprint Planning 1: Der Product Owner stellt gerade die 7. Story vor. Bereits das Commitment der 6. Story hatte einigen Teammitgliedern Bauchschmerzen bereitet. Doch zu meiner Überraschung ist das Team schnell zu dem Entschluss gekommen, auch diese weitere Story zu committen.
Szenenwechsel: Die Nachbesprechung des Meetings in kleinem Kreis. “Warum wart ihr euch als Teammitglieder bei der letzten Story so sicher?”, lautet meine Frage als ScrumMaster. Kleinlaut wird mir erklärt, dass ein Teil der Storys vorab im Aufwand mit Manntagen geschätzt wurde. Und das alles, nachdem wir die letzten Schätzungen mit Hilfe von Magic Estimation [1] auf der Basis des relativen Funktionsumfangs sehr effizient durchgeführt hatten und das Team überzeugt von den Vorteilen wirkte.
Das Beispiel zeigt, wie schwierig es doch ist, alte Gewohnheiten hinter sich zu lassen. Obwohl mir doch in den Diskussionen mit dem Team bestätigt wurde, dass alle bisherigen Aufwandschätzungen keineswegs genau und richtig waren. Zudem sind viele der traditionellen Software-Schätzverfahren mit hohem Aufwand verbunden, da viele Faktoren erhoben und Bewertungen durchgeführt werden müssen, wie beispielsweise in der Function Point Methode [2]. Und doch scheint es schwierig zu sein, die alten Angewohnheiten einfach einmal beiseite zu legen.
Doch was ist es, das uns an den Schätzungen mit Aufwand festhalten lässt? Ist es das Gefühl der vermeintlichen Sicherheit, die Größe der Story bestimmt zu haben? Ist es die Annahme, das Projekt mit Hilfe dieser Zahlen „im Griff“ zu haben? Oder ist es der reine Zahlenfetischismus, der von Jahr zu Jahr zuzunehmen droht? Oder sind es ganz andere Gründe, die wir gar nicht benennen können?
[quote author = “Heinrich Heine”] “Man kann die Ideen, wie sie in unserem Geiste und in der Natur sich kundgeben, sehr treffend durch Zahlen bezeichnen; aber die Zahl bleibt doch immer das Zeichen der Idee, nicht die Idee selbst. Der Meister bleibt dieses Unterschieds noch bewusst, der Schüler aber vergisst dessen und überliefert seinen Nachschülern nur eine Zahlenhieroglyphik, bloße Chiffren, deren lebendige Bedeutung niemand mehr kennt und die man mit Schulstolz nachplappert.”[/quote]
Mein Tipp: Lasst euch auf neue Methoden ein, wenn die bisher verwendeten keinen Erfolg versprechen. Lasst euer Bauchgefühl entscheiden und verschwendet keine Stunden und Tage für kompliziert berechnete Schätzungen, die nicht halten. Benutzt Magic Estimation, mit dessen Hilfe ihr die Storys schneller und fokussierter schätzen könnt. Ich bin mir bewusst, dass dies auch Mut erfordert. Den Mut, bisher jahrelang verwendete Verfahren in Frage zu stellen. Glaubt mir, es lohnt sich!
[1] Gloger, B.: Scrum. Hanser Verlag (4. Auflage), 2013.
[2] Poensgen, B.: Function-Point-Analyse: Ein Praxishandbuch. dpunkt Verlage (2. Auflage), 2012.
Übrigens frisch im Buchhandel: “Wie schätzt man in agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind” von Boris Gloger. Hanser Verlag 2014.

Tools sind toll, Papier ist besser

… zumindest in Fällen, wo

In vielen Projekten stoßen wir mit unserer “Abneigung” gegen Tools auf Gegenwehr, um nicht zu sagen auf blankes Entsetzen. (Zwinkern)
Man argumentiert, dass es doch viel praktischer sei, vor allem für das heiß geliebte Reporting. Auch eine detailliertere Beschreibung der Stories als auf den A5-Karten sei damit möglich. Dagegen zu argumentieren hilft in den meisten Fällen herzlich wenig. Solange der Vorteil von Papier nicht am eigenen Leib gespürt wird, kämpf man in diesem Fall gegen Windmühlen. Ich gebe ja zu, dass z.B. zur Revisionsicherheit ein Mindestmaß an elektronischer Dokumentation das Leben erleichtert. Dennoch sollte es nicht als Allheilmittel gesehen werden. Also warte ich geduldig auf eine Gelegenheit, um es am eigenen Leib erfahrbar zu machen. Das spannt zwar meinen Geduldsfaden oft bis zum Zerreißen an, aber wenn der Moment dann kommt, ist es meist umso wirkungsvoller. Lasst mich ein Beispiel erzählen.

Klick, klick, klick, klick, klick, klick …..

In einem Projekt sollten zwei übergreifende Backlogs zusammengeführt werden. Voraussetzung dafür war die Priorisierung des übergreifenden Backlogs. Passieren sollte das in einem Termin mit den Product Ownern, die an diesem übergreifenden Backlog arbeiten (ja, eigentlich sollte der Weg anders herum sein, hier war es jedoch so der Fall). Der ScrumMaster hatte sich gewappnet und bereits das übergreifende Backlog im Tool geöffnet. Nachdem die erste halbe Stunde mit einer Diskussion über andere Dinge zugebracht wurde (u.a. Zielklärung), blieb nur noch wenig Zeit für die eigentliche Zielsetzung. Wir begannen also mit dem Durchsehen des Backlogs im Tool. Nachdem wir nach den ersten 5 MInuten immer noch bei den ersten von ca. 30 Stories/Epics waren, witterte ich meine Chance. Die Teilnehmer waren schon leicht frustriert, weil das ständige Hin- und Herklicken des ScrumMasters, der ja als einziger das Tool bedienen konnte, sehr lange dauerte und erst nach dem dritten Anlauf das Ergebnis brachte, das der Product Owner gerade brauchte. Außerdem ließen sich die Stories/Epics nicht per Drag an Drop verschieben, sondern es bedurfte einer zwei- bzw. dreistelligen Priorisierungsnummer, damit nachträglich Stories dazwischengeschoben werden konnten. Gefühlter Zeitbedarf pro Story/Epic: 2-3 Minuten. Gefühlte notwendige Klicks: 20-30… (ja, wahrscheinlich übertreibe ich etwas (Lächeln))! Wir hatten aber direkt einen Anschlusstermin, um das übergreifende Backlog mit dem anderen übergreifende Backlog zu mergen.

Zack, zack!

Hier witterte ich meine Chance. Ich lief in ein Büro, griff mir die erstbesten Post-Its und ging wieder zurück, um xy vorzuschlagen, spontan vom Tool auf Papier zu wechseln. Nach kurzer Zeit hatten wir einen guten Arbeitsmodus – man könnte fast Flow sagen – erreicht. Der ScrumMaster schrieb die JIRA Nummern auf ein Post-it und ein Stichwort/Thema der jeweiligen Story dazu. Ich ließ die POs kurz diskutieren, wie die Story in Relation zu den anderen zu bewerten sei und legte das Post-it an die entsprechende Stelle auf dem Tisch vor ihnen. Diskussionen zu einem Item, die auszuufern drohten, unterband ich mit dem Hochhalten des nächsten Items auf dem Post-It oder reichte einem der Product Owner direkt das Post-it mit der einhergehenden Aufforderung, es entsprechend zu priorisieren. Währenddessen schrieben wir noch schnell das entsprechende Team auf das Post-it, da wir merkten, dass das nachträglich auch noch relevant sein würde. Viele der Stories konnten wir sehr schnell einordnen und die Product Owner waren sich einig. Manche der Items führten zu mehr Diskussionen und einer erneuten Umpriorisierung von mehreren anderen Items. Schnell gemacht, ohne Klicks. Schließlich hatten wir 8 Hände zum Helfen.Kleines Manko: Leider war irgendwann der Tisch zu Ende.
Schöner Effekt: Die am niedrigsten priorisierten Stories fielen vom Tisch runter und wir priorisierten auf dem Boden weiter!
Nach der ersten halben Stunde des Termins hatten noch alle es für unmöglich gehalten, das Backlog zu priorisieren. Am Ende schlossen wir den Termin 5 Minuten früher, weil wir schon fertig waren.
Mit unseren Zetteln ernteten wir im nächsten Termin erstmal nur ein müdes Lächeln. Auch hier war das elektronische Tool das Mittel der Wahl. Auch dass der ScrumMaster, eigentlich überzeugter Tool-Nutzer, beeindruckt war und lauthals verkündete, dass er gerade Zeuge geworden war, wie schnell und gut Papier funktionierte, half nicht. Erschwerend kam hinzu, dass wir die Post-Its auf das White Board kleben wollten und sie abfielen. Leider hatte ich einen Rest-Stapel Post-Its gegriffen, die zum Teil schonmal irgendwo geklebt hatten oder anderweitig ihre Haftkraft verloren hatten.
Als wir dann begannen, die Backlogs im Tool zu mergen, griff zu meinem Erstaunen sogar ein anderer ScrumMaster sofort nach den Post-Its und wir wiederholten den beschleunigten Prozess. Auch dieses Mal kamen wir mit der Timebox hin. Zusätzlich gelang es einem der Teilnehmer, gleichzeitig die auf Papier priorisierten Items in das Tool einzupflegen, ohne dass alle auf ihn warten mussten oder von der Geschwindigkeit des Tools abhängig waren. Auch hier hielten wir die Timebox und waren wesentlich schneller als mit 5 Personen direkt im Tool.
Kein Grund euphorisch zu werden, ich weiß … Aber die nächste Gelegenheit kommt bestimmt!
 

Warum überhaupt schätzen?

Schätzen bedeutet für viele Menschen Stress. Wie sollte es auch anders sein? Solange Schätzungen herangezogen werden, um das Fertigstellungsdatum festzulegen, wird es ein abgekartetes Spiel bleiben. Die einen wollen ein tolles Produkt liefern und versuchen daher, durch möglichst großzügige Angaben und dem Einschieben von vielen Pufferzonen ihre Freiheit zu erkaufen. Die anderen wollen den Kunden behalten, haben ihm vielleicht sogar schon Zusagen gemacht, und versuchen daher, die Zeit bis zur Auslieferung maximal zu reduzieren.
Natürlich ist die Spannung beiden Seiten bekannt – und so versucht jeder, das Spiel mit möglichst wenig Kompromissen zu überstehen. Das Spiel kostet üblicherweise viel Zeit und Nerven, und führt letztendlich zu lokalen Optimierungsstrategien: Hier die Strategie, das beste Produkt zu entwickeln. Dort die Strategie, den besten Marktwert für das Produkt zu erzielen. Das Gesamtergebnis muss suboptimal bleiben, weil jede Strategie eigensinning arbeitet, ohne die andere wirklich miteinzubeziehen.
Angesichts dessen haben wir zwei Möglichkeiten: Das Schätzen komplett sein zu lassen und dem Kunden nur noch das zu versprechen, was in den nächsten Iterationen jeweils fertig gestellt werden kann. Vorteil: Der Kunde zahlt für genau das, was er bekommt. Und er kann nach jeder Iteration entscheiden, ob er noch mehr braucht. Dadurch spart er sich den Aufwand und die Schleierhaftigkeit, die mit allen großen Spezifikationskatalogen einhergehen. Nachteil: Nicht jeder Kunde möchte so arbeiten.
Die zweite Möglichkeit besteht darin, das Schätzen komplett umzudeuten. Wir machen das so: Anstatt die Entwicklungsmannschaft nach dem Fertigstellungsdatum zu fragen, lassen wir sie mit dem Product Owner über das Produkt reden. Geht es zum Beispiel darum, ein neues Suchfeld zu implementieren, wird nicht über Aufwand für Entwicklung und Testen gesprochen, sondern um die Funktionalitäten dieses neuen Suchfelds.
Die Entwicklungsmannschaft fragt dann den Product Owner, was dieses Suchfeld leisten soll: Nach welchen Kriterien Anfragen durchgeführt werden sollen, in welcher Reihenfolge und Form die Ergebnisse angezeigt werden sollen, und so weiter. Aus solchen Gesprächen entwickelt sich ein gemeinsames Verständnis für das Produkt. Das Team wird in die Lage versetzt, die noch verbleibende Arbeit nach ihrem funktionalen Umfang zu schätzen.
Und damit ist auch die Brücke zwischen Entwicklung und Markt geschlagen: Der Product Owner, der nach einigen Sprints weiß, wie viel Funktionsumfang sein Team im historischen Durchschnitt pro Sprint liefern kann, kann nun zum Kunden gehen und ihm anhand seines priorisierten Backlogs erklären, welche Funktionalitäten er wann erwarten kann (Kristina Kleßmann hat hier eine anschauliche Beschreibung zum Schätzen nach Funktionalität geschrieben).

Eine große Umstellung

Das Schätzen nach Funktionalität bedeutet für viele eine große Umstellung. Wir alle sind es gewohnt, nach Aufwand zu schätzen. Ein Entwicklungsteam möchte möglichst früh klären, was alles zu tun ist, um eine neue Produkteigenschaft zu implementieren. Zudem wird beim Schätzen nach Funktionalität schnell deutlich, wenn keine Weiterentwicklung stattfindet. Konzeptstories (auch “Spikes” genannt) liefern genau so wenig Produktivität wie technische Aufgaben und solche, die “nur” auf ein Redesign einer bestehenden Funktionalität abzielen. Im “schlimmsten” Falle heißt das dann: Das Team hat über mehrere Sprints keinen funktionalen Mehrwert geliefert. Für viele Teams ist das ein echtes Problem – vor allem dann, wenn das Management sie an ihrer Velocity (also dem Durchsatz an Funktionalitäten pro Sprint misst). Sie schätzen dann lieber nach Aufwand oder Komplexität (oder einer alchemistisch anmutenden Mischung aus beiden), um dem Unternehmen zu zeigen: Schaut her, wir machen unsere Arbeit.
Und so ist es in Scrum häufig wie beim Arztbesuch. Keiner steht gerne im Unterwäsche vor dem Mensch im weißen Kittel, um sich auf Herz und Nieren prüfen zu lassen. Trotzdem ist es wichtig, sich ab und an die Blöße zu geben. Zu erkennen, dass es hier und da nicht so gut läuft. Dass kein Kunde der Welt wirklich bereit ist, für Konzepte oder Generalüberholungen zu zahlen. Dass ein Unternehmen es nicht mehr schafft, seine Produkte weiter zu entwickeln, sondern an Bestehendem herumdoktert.
Entscheidend ist dabei, wie ein Unternehmen mit dieser Erkenntnis umgeht. Wie geht es Mitarbeitern, die solche Defizite offen ansprechen? Werden sie ernstgenommen und anerkannt, oder eher sachte beiseite geschoben und am Ende des Tages ignoriert? Und selbst wenn es ein Problembewusstsein gibt: Führt das im Unternehmen zu Hilflosigkeit und Frustration oder raufen sich alle zusammen, um einen Schlachtplan zu entwerfen? Teams spüren sehr genau, wie ihr Unternehmen tickt, welche “Persönlichkeit” es hat. In einem Unternehmen, das am liebsten gut dastehen möchte, wird die Offenheit, die mit dem Schätzen nach Produktivität einhergeht, keine guten Chancen haben. Das heißt aber nicht, dass die Methode die falsche ist. Es zeigt nur, dass sie nicht zum Selbstverständnis des Unternehmens passt.
Siehe auch: Martin Fowler: Purpose of Estimation

Gedanken eines frisch gebackenen Product Owners

Wahrscheinlich ist es meine Verantwortung für den ROI, die mich immer wieder dazu verleitet, die Priorisierung einzig und allein vom Wert der User Story in Euro und Cent, also dem originären Business Value ableiten zu wollen. Doch der Versuch, einen absoluten Wert hinter die Story zu schreiben, den der Kunde im Endeffekt sicher bezahlen wird, lässt mir eher graue Haare wachsen als ein priorisiertes Backlog gedeihen.
Denn machen wir uns doch nichts vor: Das, was ich hier im Backlog formuliere, sind Hypothesen. Wenn der Kunde noch nichtmal weiß, dass er das bald unbedingt haben will, weiß er doch auch heute noch nicht, wie viel er dafür zu bezahlen bereit sein wird. Ok, das Risiko bleibt also mal wieder an mir hängen. Ich muss mir sicher sein, dass meine Hypothese so gut ist, dass es sich lohnt, die Jungs und Mädels ein paar Tage dran zu setzen.
Auf der anderen Seite: Zu den Zeiten, in denen mir der Kunde vorgegeben hat, was er als Nächstes haben möchte und auch gleichzeitig den Preis mitgeliefert hat, möchte ich auch nicht zurück. Ok, also erstmal keine Euros … aber wie komme ich dann zu meiner Priorisierung? Irgendjemand hat mir mal gesagt, dass Scrum viel mit Menschenverstand zu tun hat … also …
Bauchgefühl? 
Hm, hat zwar weniger mit Verstand zu tun, aber dafür habe ich davon eine ganze Menge 🙂 Aber reicht das? Ich hätte da lieber was, mit dem ich die Komplexität zumindest scheinbar etwas greifbarer machen kann.
Was könnte greifbarer sein als die gute alte Deadline? Verliert ein Feature seinen Wert oder wird er erheblich verringert, wenn ich es erst nach der bestimmten Deadline auf den Markt bringe? Oder schlimmer noch: Muss ich vielleicht sogar mit einer Strafe rechnen, wenn ich das Feature nicht rechtzeitig zur Verfügung stelle? Klingt nach zwei guten Kategorien.
Wen muss ich denn mit dem Produkt beglücken? Gibt es Stakeholder, die ich vorrangig zufrieden stellen muss und oder kann ich einzelne Stories bestimmten Themen zuordnen, die als Gesamtpaket unterschiedlich wertvoll oder wichtig für das Produkt sind?
Da wir mit Scrum auch endlich mal unsere Systeme in den Griff bekommen wollen, könnte ich mir natürlich auch genau die Stories raussuchen, die die meisten Systeme gleichzeitig anfassen. Oder die Stories, die sich erstmal mit dem zentralen Sorgenkind beschäftigen. So können wir möglichst schnell identifizieren, wo die größten Probleme liegen. Apropos Probleme – was ist eigentlich mit Risiken? Könnte in die Kategorie Systemarchitektur fallen, aber auch der auslaufende Vertrag mit dem Zulieferer könnte zu einem Risiko werden, wenn wir noch vorher die entsprechende Unabhängigkeit der Daten sicherstellen.
Da fällt mir die Kooperation mit der Uni ein. Die haben bestimmte Vorlaufzeiten, damit sie die Studenten auftreiben können.
Puh, was könnte noch eine Rolle spielen?
Naja, wir hatten uns ja bei der Ausrichtung des Produktes damals so viele Gedanken gemacht, was es eigentlich für die Firma bringen soll. Vielleicht kann ich bewerten, wie gut das Feature dieses Ziel unterstützt? Falls mir das noch nicht reicht, könnte ich eine Kombination mit Methoden wie z. B. MuSCoW oder Kano versuchen:
MuSCoW: Must – Should – Could – Won’t
Kano: Basis-, Leistungs-, Begeisterungs- und Zurückweisungs-Merkmale!  
Ok, bevor ich das alles ausprobiere, erstmal zum PO Weekly. Immerhin gibt es auch noch die Abhängigkeiten zu den anderen Teams, die Einfluss auf meine Prio nehmen könnten. Und jetzt, wo wir so viele neue Scrum-Teams haben, könnten wir doch eigentlich eine übergreifende Priorisierung vornehmen und dabei die gleichen Kriterien anwenden. Mal sehen wie die anderen es machen – bekanntlich ist es ja einfacher, wenn man ab und zu die Köpfe im Team zusammensteckt.
Wir könnten im PO Team einfach mal aufschreiben, wer wie priorisiert und sehen, wo die Gemeinsamkeiten und Unterschiede sind und welchen Nutzen die einzelnen Aspekte für den jeweiligen PO haben. Macht es Sinn, dass wir die gleichen Kriterien anwenden und was verstehen wir eigentlich genau darunter? Und wahrscheinlich hat mein ScrumMaster auch noch ein paar Ideen und kann mir bei der Fülle der Möglichkeiten für die Priorisierung helfen … Aber wahrscheinlich wird er am Ende wieder sagen: “Triff einfach eine Entscheidung!” Product Owner sein heißt Entscheidungen treffen, und die trifft man per Definition unter Unsicherheit! Man muss es trotzdem tun und vor allem dazu stehen.