Einmal war ich bei einer Firma, die ein neues Produkt launchen wollte. Das Produkt war vielversprechend und innovativ – kein Mitbewerber hatte zuvor etwas Ähnliches entwickelt. Für dieses neue Produkt wurde ein eigenes Team zusammengestellt, in dem sich auch einige neu eingestellte Spezialisten befanden, denn die Firma hatte von Haus aus keine Erfahrung mit der eingesetzten Technologie.

Jetzt stand natürlich die eine große Frage im Raum: "Wann sind wir fertig?" Schnell entspann sich eine Diskussion um verschiedene Schätzverfahren; die Beteiligten warfen mit Begriffen wie "Schätzpoker", "Function Points", "Abstrakte Schätzmaße" und "Schätzmeetings" um sich. Die Entwickler, die sich offenbar an frühere Erfahrungen mit Schätzungen erinnerten, rollten mit den Augen und schnell waren die ersten zynischen Bemerkungen zu hören.

Das Dilemma mit den Schätzungen

Wie kann man in so einer Situation eine verlässliche Aufwandsschätzung produzieren? Generell sind Schätzungen dann zuverlässig und mit wenig Aufwand zu erstellen, wenn wir in einem Umfeld mit geringer Ungewissheit operieren. Angenommen, ein eingespieltes Team entwickelt in einer sicher beherrschten Technologie eine Software, deren Anforderungen vollständig geklärt und sicher verstanden wurden. Darüber hinaus weiß das Team genau, wer ihre Kunden sind und was deren Bedürfnisse sind. Dann ist es sicherlich möglich, eine verlässliche Aufwandsschätzung zu produzieren.

Allerdings stellt sich dann sofort die Frage: Wie häufig kommt so etwas vor? Und wozu brauche ich das? Denn das beschriebene Szenario bedeutet ja letztlich, dass ich etwas, was ich schon einmal genau so getan habe, einfach wiederhole. Zwar gibt es solche Szenarien in der Praxis tatsächlich, aber sie sind sehr selten, und wenn eine Organisation ausschließlich in diesen Bereichen großer Sicherheit operiert, dürfte sie bald Geschichte sein, denn Innovation bedeutet immer Ungewissheit. Wir haben es also mit dem Dilemma zu tun, dass Aufwandsschätzungen und Innovation in einem Spannungsverhältnis zueinander stehen.

Es gibt keine Glaskugel

Zurück zu unserer Geschichte. Hier hatten wir es mit einem Setting voller Ungewissheit zu tun: Ein neu zusammengestelltes Team, eine neue Technologie, etliche Fragezeichen bei der fachlichen Umsetzungen und bei der Frage, wie die Kunden auf das neue Produkt reagieren werden. In dieser Situation ist es nicht nur sehr aufwändig, Schätzungen zu produzieren, sondern auch extrem frustrierend, weil die Schätzungen schlichtweg nicht stimmen. Und das liegt nicht daran, dass schlecht geschätzt wurde, sondern dass wir von den Teams verlangen, eine extrem ungewisse Zukunft vorherzusagen. Das kann die Wahrsagerin im Jahrmarktszelt nicht, und das können auch Entwickler, Designer und Tester nicht.

Und das Schlimmste, was wir in so einer Situation tun können, ist, das Team auf ihre ursprünglichen Schätzungen festzunageln und sie zu zwingen, diese einzuhalten. Das führt nicht nur zu Stress, schlechter Stimmung und Sicherheitspuffern bei der nächsten Schätzung, sondern es verhindert auch effektives Lernen! Denn die Schätzungen beziehen sich ja auf die Annahmen, die wir zum Zeitpunkt der Schätzung getroffen haben.

Wenn wir an einem innovativen Produkt arbeiten, ist es völlig normal, dass wir täglich unsere Annahmen in Frage stellen, einige davon über Bord werfen und neue Annahmen aufstellen. Das macht aber natürlich unsere Schätzungen fragil. Wenn wir darauf bestehen, dass die ursprünglichen Schätzungen eingehalten werden, können wir genauso gut mit großen roten Buchstaben "Hier ist Lernen verboten!" an jede Wand pinseln.

Warum schätzen wir?

Gibt es einen Ausweg aus diesem Dilemma? In vielen Fällen schon! Dafür muss man sich zunächst die Frage stellen: "Wofür benötigen wir die Schätzungen überhaupt?" Lautet die einzige Antwort "Weil das eben dazugehört" oder "Weil wir das schon immer so gemacht haben", dann sollte man darüber nachdenken, Schätzungen einfach ersatzlos zu streichen.

In vielen Fällen ist es aber leider nicht so einfach. Wenn wir über Produktentwicklung sprechen, dann gibt es meiner Meinung nach einen großen, wirklich wichtigen Grund, der Organisationen zu Schätzungen veranlasst: Rendevouz-Planung. Damit ist gemeint, dass verschiedene Teams oder Abteilungen auf einen gemeinsamen Termin hin synchronisiert werden müssen.

Stellen wir uns vor, dass unser Marketing das neue Produkt mit einer großen Werbekampagne ankündigen möchte. Dafür müssen Plakatflächen und Fernsehspots lange im Voraus gebucht und das Material natürlich vorher produziert werden. Völlig verständlich, dass unsere Kollegen vom Marketing dafür wissen möchten, wann wir fertig mit der Entwicklung sind, denn sie wollen ja nichts anpreisen, was es noch gar nicht gibt (genau dies passiert leider regelmäßig in großen Organisationen!)

Reden schützt vor Katastrophen

Wie geht man klassischerweise mit dieser Situation um? Zu Beginn der Entwicklung wird eine detaillierte Schätzung durchgeführt, die das Marketing als Grundlage nimmt, um die Werbekampagne zu planen. Kommt es jetzt zur Katastrophe, wenn die Entwicklung deutlich länger braucht als angekündigt? Nein, nicht unbedingt! Die Katastrophe entsteht nur dann, wenn die beiden Abteilungen (Marketing und Entwicklung) nicht miteinander kommunizieren und das Marketing daher zu spät mitbekommt, dass der Termin nicht gehalten werden kann oder sich der Scope des Produkts ändert.

Und genau das ist leider häufig der Fall, weil die Struktur der Organisation keinen regelmäßigen Austausch über Abteilungsgrenzen hinweg zulässt. Bei genauerem Hinsehen haben wir es in diesem Fall also gar nicht mit einem Schätzproblem zu tun, sondern mit einem Kommunikationsproblem, das durch die Organisationsstruktur bedingt ist.

Ein möglicher Ausweg aus dem Dilemma

Wie kann es stattdessen aussehen? Kehren wir zu unserem realen Beispiel vom Anfang zurück. Die Herausforderung bestand auch hier in einer Rendevouz-Planung. Und zwar in einer ziemlich anspruchsvollen, denn mehr als 15 unterschiedliche Teams mussten auf den Launchtermin hin synchronisiert werden! Also wurde ein regelmäßiger Termin einberufen, an dem Delegierte aus allen betroffenen Teams teilnahmen. Dort wurden dann kurz die Fortschritte der Entwicklung demonstriert, auf Probleme und Risiken hingewiesen und Fragen beantwortet. Außerdem hat das Entwicklungsteam eine einfache Frage beantwortet: "Ist es möglich, dass wir innerhalb der nächsten acht Wochen fertig mit der Entwicklung sind?" Acht Wochen deshalb, weil wir vorher in Gesprächen herausgefunden hatten, dass dies der maximale Zeitraum ist, den ein Team braucht, um sich auf den Launch vorzubereiten.

Lautete die Antwort des Entwicklungsteams: "Nein, in den nächsten acht Wochen werden wir auf keinen Fall fertig", konnten alle Teams wieder entspannt an ihre Arbeit zurückkehren. Als das Team aber zum ersten Mal äußerte: "Naja, wenn alles gut läuft, dann schaffen wir es vielleicht", änderte sich der Modus. Nun haben wir uns zusammengesetzt und einen Releasetermin festgelegt, der zehn Wochen in der Zukunft lag. Der Termin war mit keinem Risiko mehr behaftet, denn viele Features waren bereits fertig, und das Team war sich zu 100% sicher, dass sie bis zum Termin eine Version entwickeln konnte, die alle essenziellen Funktionalitäten enthält. Zusätzlich wurde ein Bonus-Scope definiert, der nicht in jedem Fall im Launch enthalten sein würde, denn Ungewissheit gab es natürlich weiterhin.

Die anderen Teams machten sich jetzt also daran, auf diesen Termin hin zu planen. Sie wussten aber, dass sie noch nicht alle Features einplanen konnten, sondern nur diejenigen, die zum Kernumfang gehörten. Der Takt des Synchronisierungsmeetings wurde verkürzt und nun gab es jedes Mal ein Update, ob weitere Features sicher zum Kernumfang des Releases gezählt werden können. Daraufhin haben die anderen Teams dann ggf. ihre Aktivitäten angepasst. Dieses Vorgehen nennt sich inkrementelle Releaseplanung. Dabei muss ein gewisses Maß an Ineffizienz in Kauf genommen werden, denn wir müssen beispielsweise die Werbetexte etliche Male umformulieren, neue Screenshots einfügen usw., sobald neue Features hinzukommen. Mit dieser Ineffizienz erkauft man sich jedoch ein erhebliches Maß an Flexibilität, das böse Überraschungen beim Releasetermin ausschließt.

Fazit

Sind Schätzungen generell unsinnig? Sicher nicht! Es gibt Situationen, in denen es sehr schwierig ist, um Schätzungen herumzukommen (z.B. wenn ich als Dienstleister für einen neuen Kunden einen Festpreis anbieten muss). Aber die Erfahrung zeigt, dass in vielen Organisationen geschätzt wird, was das Zeug hält, obwohl es dafür gar keinen Grund gibt. Vor jeder Schätzung sollte die Frage nach dem Schätzzweck stehen (vgl. hierzu auch Stefan Roock: "Darf's ein bisschen mehr sein? Vom (Un-)Sinn von Schätzungen", in: agile review 02/2013). Daraus ergeben sich häufig interessante Erkenntnisse darüber, ob, wie, in welchem Detaillierungsgrad und wie häufig geschätzt werden sollte. Und ob es andere Dinge gibt, die wir tun sollten, um ein erfolgreiches Produkt/Dienstleistung zu entwickeln - zum Beispiel die Kommunikation über Abteilungsgrenzen hinweg verändern!

P.S.: Wenn Sie unzufrieden mit Ihren Schätzungen sind, aber nicht wissen, wie Sie ohne Schätzungen auskommen sollen (insbesondere in großen Projekten), sollten Sie sich unbedingt einmal Cycle Time Forecasting ansehen (s. hierzu auch ein Video von der "Lean Kanban Central Europe 2013"). Dort geht es darum, Projekte zu simulieren und mit Wahrscheinlichkeiten zu operieren, ganz ähnlich, wie es z.B. in der Wettervorhersage oder in der Pharmazeutik schon lange Gang und Gäbe ist.