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.

Agile Toolbox
Scrum
Schätzen
bgloger-redakteur
August 11, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4