Schätzen – eine Hassliebe
Das Thema Schätzen begleitet mich seit meinem ersten Job bei Electronic Data Systems (EDS) in Rüsselsheim. Mit einem der Projekte wollten wir unter anderem zeigen, dass wir die Standards des Capability Maturity Models Level 2 erfüllen konnten – und ich wollte dafür den Projektplan erstellen. Wie man es eben so tut, hatten wir fein säuberlich alle Zahlen zusammengetragen und mein Projektplan war einfach toll. Als unser Entwicklungsteam die Designphase beendet hatte und das Projekt in die Implementierungsphase ging, war ich vor dem Status-Meeting mit meinen Entwicklern total nervös. War das Design wirklich fertig? Die zwei Entwickler, die sich bis jetzt um das Designdokument – damals hieß das „Technical Design“ – gekümmert hatten, sagten: „Boris, wir sind fertig, aber bitte sag es noch niemandem. Wir müssen noch einen Test durchführen. Bis übermorgen ist das aber erledigt.“ Zuerst verstand ich das nicht, ich war einfach nur total happy, weil mein Projekt auf Schiene war. Dann sagte Peter, der damalige Senior System Engineer: „Boris, du hast nicht verstanden: Wir sind fertig!“ Ich muss wohl ziemlich verdutzt aus der Wäsche geschaut haben. Peter sagte mir doch tatsächlich, das Projekt sei fertig implementiert und fertig getestet – und das drei Monate früher als es mein schicker Projektplan vorgesehen hatte. Ich war völlig perplex: Die geplanten 800 Entwicklungsstunden wurden nicht gebraucht. Die beiden Senior-Entwickler, die eigentlich „nur“ das Design schreiben sollten, hatten beides gemacht – designt und fertig entwickelt. Sie hatten sich also eigentlich nicht an den Prozess gehalten. Ich fragte sie, wie so etwas möglich sei. Die Antwort der beiden war vollkommen logisch: Eigentlich hätten sie das Design so aufbereiten müssen, dass das Offshore-Team genau verstanden hätte, was zu entwickeln war. In derselben Zeit konnten sie statt Pseudocode genauso gut den Code selbst schreiben.
Ein anderes Mal fragte ich Peter, wie viel Aufwand es wäre, eine Hostmaske zu entwickeln. Sie war nicht sonderlich kompliziert. Peter antwortete wie aus der Pistole geschossen: „40 Stunden!“ Als ich ihn fragte, wie er das denn wissen könne, meinte er, dass er eine solche Maske ja nicht zum ersten Mal entwickeln würde. Er kannte sein System, er hatte es selbst entworfen. Wenn Peter und sein Team eine Schätzung abgaben, konnte ich immer sicher sein, dass ihre Angaben auch korrekt waren. Sie hielten ihre Schätzung wirklich immer ein.
Vom Blindflug zum Sichtflug
Erst Jahre später habe ich begriffen, dass das in der Softwareentwicklung nicht „normal“ war. In Projekten mit anderen Teams und anderen Auftraggebern war auch die Realität eine vollkommen andere. Bei meinem ersten großen Projekt in einem Telekommunikationsunternehmen wurde ich mit einem fertig geschätzten Projektbudget losgeschickt. Später stellte sich heraus, dass es vollkommen falsch war. Meine Vorgänger hatten die Schätzungen aus der Luft gegriffen und sie hatten sie unter der Annahme erstellt, dass die Entwicklung Ahnung von diesem zu implementierenden Internetportal haben würde. Als junger Projektmanager, der Erfolg haben musste, kam ich gar nicht auf die Idee, dass meine Entwickler nicht so professionell und erfahren sein könnten wie Peter und seine Kollegen von EDS. Es war zum Verzweifeln: Die Entwicklungsmannschaft wusste nicht, was sie tat. Woran ich das erkannte? Weil mein Entwicklungsteam von den im Design beschriebenen 149 Web-Templates nur ein einziges fertig geliefert hatte. In diesem vierköpfigen Team saßen lauter neue Mitarbeiter, die so etwas noch nie gemacht hatten. Also ging ich zu meinem Chef und warf die rote Flagge! Ich konnte ihn davon überzeugen, einen Teil des Projektprofits aufzugeben und um dieses Geld einen Entwickler zu „kaufen“, der sich auskannte. Ich hatte Glück: Zwei Wochen später war der Entwickler im Projektteam. Er schrieb 109 Templates selbst. Die übrigen 40 wurden von den restlichen Teammitgliedern erledigt – nachdem sie verstanden hatten, wie man diese Art von Templates entwickelt.
Damals berechnete ich den Projektfortschritt nicht nach den geleisteten Stunden, sondern anhand der Anzahl der gelieferten Produktteile (eben diesen Web-Templates). Auf diese Weise konnte ich herausfinden, wie weit wir im Projekt wirklich vorangeschritten waren. Alle anderen, eher traditionellen Ansätze des Projektmonitorings hätten mich komplett im Blindflug gelassen. So aber konnten wir reagieren. Wir konnten genau sagen, wie weit wir tatsächlich waren und der Fachabteilung ständig etwas Fertiges zeigen. Wie endete dieses Projekt? Wir lieferten beinahe zum ursprünglich geplanten Termin. Aus heutiger Sicht hätte dieses Projekt viel erfolgreicher sein können – hätte es nicht gleich am Anfang die auf falschen Aufwänden basierende Schätzung gegeben. Das Traurige daran: Genau so sieht die Projektrealität in vielen Unternehmen heute aus.
Diese beiden Erfahrungen weckten in mir ein tiefes Misstrauen gegen jede Form von Aufwandschätzung und hinterließen in mir das Bewusstsein, dass der Fortschritt eines Projekts auf keinen Fall in Aufwänden gedacht oder beurteilt werden kann. Kurz vor meiner Zertifizierung zum Project Manager Professional (PMP) des Project Management Institutes kam ich zur bitteren Erkenntnis, dass die gängigen Projektmanagementmethoden für das Thema Planung nicht ausreichten.
Alles besser mit Scrum?
Das Thema Schätzen ließ mein Entwicklungsteam auch nicht los, als wir Projekte immer öfter mit der neuen Wunderwaffe Scrum durchführten. Obwohl wir die Software schneller und mit höherer Qualität lieferten, wollten die Fachabteilungen immer zunächst wissen, was es kosten würde und wann es fertig sein würde. Schon gar nicht konnte ich diesen Fragen später als Scrum-Trainer entkommen. Heute genauso wie vor zehn Jahren haben die meisten Teilnehmer in den Trainings genau diese zwei Fragen im Kopf: „Wann ist es fertig und was wird es kosten?“ Dieser zwingende Wunsch nach absoluter Vorhersagbarkeit dominiert ganze Trainingsnachmittage.
Die ersten Ideen, die Ken Schwaber und Jeff Sutherland dazu in ihren Büchern aufbrachten, waren wenig hilfreich. Auch für sie war es damals immer noch logisch, in Tagen und Stunden zu schätzen. Im Laufe der Zeit wurde aber zusehends deutlicher, dass das Schätzen in Aufwänden ständig in eine Sackgasse führt. Allmählich wurde klar: Wenn es bei Frameworks und Vorgehensweisen wie Scrum immer um die Lieferung von Produktteilen geht, ist ein anderer Zugang zum Schätzen und Planen nötig.
Auf der Suche nach neuen Verfahren kam in der XP Community 2004 die Idee der Storypoints auf – eine Revolution! Zwar wurden Storypoints zunächst auch noch als „Aufwände“ verstanden, aber sie machten den Weg frei, über so etwas wie Komplexität bei Aufwänden zu sprechen. Mit den Büchern von Mike Cohn wurde das Schätzen mit Planning Poker populär. Die Fibonacci-Skala konnte implizit ausdrücken, dass es sich beim Schätzen nicht um einen exakten Wert handelt. Die Ungenauigkeit nimmt bei großen Werten zu.
Unzähligen Scrum-Teams hat dieser neue Zugang zum Schätzen sehr geholfen und neue Möglichkeiten eröffnet. Aber das Thema war noch nicht fertig gedacht. Die Schätzungen mit Planning Poker wurden immer zeitintensiver und es gab keine wirklich guten Argumente dafür, was denn der Tester in einem Team schätzen sollte. Der Begriff der Komplexität hatte das Denken in Aufwänden nur kaschiert – verschwunden war es noch nicht. In Trainings und Projekten suchten wir umständlich nach Argumenten, weshalb zum Beispiel eine Story mit dem Wert 13 das eine Mal lange dauerte und das andere Mal einfach nur schwer (kompliziert, da komplex) war.
Ich machte mich auf die Suche nach einer Methode, mit der ich diese Unklarheit lösen konnte. Bei wissenschaftlichen Erklärungen gilt das Prinzip der Einfachheit: Wenn eine Vorgehensweise zu komplex und undurchsichtig wird – und das war für mich die Idee, Aufwände durch Komplexität zu ersetzen –, dann ist sie falsch.
It's the increment, stupid!
Irgendwann, als ich gerade wieder das Schätzen in Storypoints erklären wollte, machte es „klick!“. Damals, im beinahe katastrophalen Webprojekt, hatte ich doch den Projektfortschritt nicht in Stunden, sondern in gelieferten Web-Templates gemessen. Ich hatte einfach nur die Lieferungen gezählt. Da war er, der Erkenntnissprung! Wenn wir nicht mehr in Aufwänden denken, sondern in Lieferungen, dann – ja dann brauchen wir doch nur die gelieferten Funktionen (Storypoints, Websites etc.) zu zählen. Damit haben wir ein Maß für das gelieferte Produkt und können das wiederum in einen Trend umwandeln.
Es war trotzdem noch ein langer Weg von dieser Erkenntnis zur heutigen Variante, in Projekten vollkommen auf das Schätzen von Aufwänden zu verzichten. Der Theoretiker in mir musste erst vom Experimentator in mir bestätigt werden. Und das gelang auch: Als meine Mitarbeiter und ich in einem...
