Suche
Interview mit Matthias Bohlen

„Schätzen ist wie eine Droge – lassen wir dieses dumme Spiel!“

Hartmut Schlosser

Matthias Bohlen

Aufwandsschätzungen für Software-Projekte geraten regelmäßig aus dem Ruder. Doch warum liegen Entwickler mit ihren Einschätzungen, wie lange sie für ein bestimmtes Feature brauchen, so oft daneben? In welchem Rahmen sind solche Schätzungen überhaupt sinnvoll? W-JAX-Sprecher Matthias Bohlen gibt im Interview Hinweise, wie man sich der „Droge der Schätzung“ entziehen kann.

Wir unterschätzen jedesmal den Aufwand, etwas wirklich fertig zu machen.

JAXenter: “Liefern, schon vor dem Schätzen” – so lautet der Titel deiner W-JAX Session. Das hört sich irgendwie so an, als sollte man den Lottoschein NACH der Ziehung der Lottozahlen ausfüllen, und nicht vorher. Ist was dran, an diesem Vergleich?

Matthias Bohlen: Ein bisschen was ist dran. 🙂 Ich habe den Titel so provokant gewählt, weil ich in meiner Arbeit mit Entwicklungsteams immer wieder gesehen habe, dass Detailschätzungen gemacht werden, die richtig Zeit kosten, weil eine hohe Verlässlichkeit angestrebt wird. Währenddessen hätte ein Team das ein oder andere Feature bereits liefern können – besonders bei Verwendung heutiger Technologien, Prozesse und der DevOps-Kultur. Übrigens: Mein E-Book zum selben Thema heißt genauso.

JAXenter: Weshalb ist es denn eigentlich so schwer, Aufwandsschätzungen abzugeben.

Matthias Bohlen: Stell Dir vor, Du bist Entwickler und baust ein Feature, für das Du zwei Tage geschätzt hast. Beim ersten Mal klappt es nicht richtig. Du suchst die Fehler, merkst aber, dass der Ansatz nichts taugt und baust es mit einem besseren Ansatz noch einmal. Diesmal funktioniert es und Du hast beim zweiten Mal auch exakt zwei Tage gebraucht. Insgesamt waren es jedoch vier oder fünf.

Die Wochen vergehen. Dein Kunde fragt Dich nochmal nach einem ähnlichen Feature. Was sagst Du, wie lange es dauert? Sagst Du zwei oder fünf Tage?

Meine Erfahrung ist, dass wir Menschen dazu tendieren, unsere Fehlversuche zu vergessen und nur die Nettozeit des letzten, erfolgreichen Versuchs anzusetzen. Deshalb lautet die Antwort eben meist zwei und nicht fünf.

Bei Dingen, die wir wirklich zum ersten Mal programmieren, sieht es natürlich noch viel ungewisser aus.

Und es gibt noch einen dritten Fall: Wir unterschätzen jedesmal den Aufwand, etwas wirklich fertig zu machen. Es gibt doch die schöne 90/90-Regel von Tom Cargill: „Die ersten 90% des Codes dauern die ersten 90% der Zeit, die letzten 10% kosten die anderen 90% der Zeit.“ Das kommt, weil wir vielfach in den Teams noch eine Trennung zwischen Programmieren und Ausliefern haben und deshalb das Ausliefern aus dem Fokus verlieren.

w-jax 2016 logoTreffen Sie Matthias Bohlen auf der W-JAX 2016

Session: Liefern, schon vor dem Schätzen!

Aufwandsschätzungen sind in der Softwareentwicklung ein Problem – Organisationen, die Software entwickeln, fragen immer wieder, wie sie ihre geschätzten Termine besser definieren und einhalten können. Ironischerweise geht das am besten, wenn Sie Ihren Prozess so umstellen, dass Schätzen überflüssig wird! Matthias Bohlen zeigt in diesem Talk, wie Sie von Blei (Personentage) zu Gold (gar keine Schätzungen mehr) kommen.

9.11.2016 – 10:00 – 11:00 Uhr

 

JAXenter: Meist braucht der Kunde oder Manager aber dennoch irgendeinen Anhaltspunkt, wann ein bestimmtes Produkt fertig wird – oder was es denn nun kosten wird. Was sagst du dem Kunden/Manager dann in solchen Momenten?

Matthias Bohlen: Natürlich möchten alle beim Projektbeginn wissen, ob man eine Hundehütte, einen Bungalow oder ein Hotel vor sich hat. Gegen solche Schätzungen ist nichts einzuwenden. Hier kann man Grob-Schätzverfahren anwenden, die ein Ergebnis liefern, das immerhin 0,25mal bis 4 mal so groß ist wie der tatsächliche Entwicklungsaufwand. Nach ersten Prototypen wird das Verständnis des Problems besser, man macht noch eine etwas qualifiziertere Schätzung und geht dann aber sofort dazu über, aus einem festen Termin und aus festem Budget das Maximum an Features herauszuholen (agiler Festpreis), anstatt zu erwarten, dass die Schätzung auch eintrifft. Also auch hier: Keine Detailschätzungen anwenden, das ist Zeitverschwendung, die falsche Daten liefert.

JAXenter: Welcher Aspekt der agilen Software-Entwicklung hat dich gerade in der letzten Zeit besonders fasziniert?

Matthias Bohlen: Der Einzug von Ideen aus „Lean Startup“ in den Alltag. Ein Startup ist eine temporäre Organisation, die ein erfolgreiches Businessmodell sucht. Wenn sie es gefunden hat, ist es kein Startup mehr, sondern eine Company. Eigentlich sollten wir den Gedanken von Software-„Projekten“ – also von Vorhaben, die einen definierten Anfang und ein definiertes Ende haben – aufgeben und jedes einigermaßen riskante Projekt gleich wie ein Startup führen. Ganz hungrig und verrückt mit wenigen Leuten beginnen, dann die Machbarkeit und den Erfolg beweisen, erste zahlende User bekommen, und dann erst mit Hilfe eines Investors voll zuschlagen. Ganz genauso sollten wir auch normale, „langweilige“ Enterprise-Software entwickeln. Was meinst Du, was das für ein Erfolg werden würde!

JAXenter: Was ist die Kernbotschaft deiner Session, die jeder Teilnehmer mit nach Hause nehmen sollte?

Schätzen macht aus Unwissen eine Zukunft. Diese ist wie eine Droge.

Matthias Bohlen: Schätzen macht aus Unwissen eine Zukunft. Diese ist wie eine Droge. Wir sind süchtig nach Zukunft und versuchen, die Gegenwart so zu verbiegen, dass sie der vorgesehenen Zukunft entspricht. Lassen wir dieses dumme Spiel und holen wir aus der Gegenwart mit guten Leuten aus Zeit und Geld das Maximum heraus. In meiner Session zeige ich Euch ganz genau den Weg zum Entzug von der „Schätzdroge“.

matthias bohlenMit seinen Coachingprogrammen und Trainings hilft Matthias Bohlen Führungskräften und Teams, die in der Entwicklung von Produkten tätig sind, dabei, profitable Produkte zur Tür hinaus zu bekommen, ohne dabei den Verstand zu verlieren: Start-ups und Produktmanager erarbeiten mit Matthias, wie deren neues Produkt aussehen soll, damit es für Kunden unwiderstehlich wird. Kleine und mittlere Unternehmen wollen von ihm wissen, wie sie effizienter und zuverlässiger entwickeln können, z. B. mit Kanban. Unternehmen mit reifen Produkten nutzen Matthias’ Talent als Softwarearchitekt und Mitglied des iSAQB, um mit seiner Hilfe ihre Produkte wieder wartbar und robust zu bekommen. Alle möchten bei Matthias Soft Skills lernen wie z. B. Präsentieren, Moderieren, Designmeetings leiten, Entscheidungen herbeiführen und Konflikte bei der Arbeit ausräumen. Teammitglieder, die mit Matthias schon gearbeitet haben, nennen ihn den „Team- und Managementflüsterer“. Matthias Bohlen hat eine einzigartige Weise, komplizierte Dinge einfach zu erklären und in kleinen Schritten umsetzbar zu machen.

.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Oliver2016-08-13 15:11:28

    Schade, hier wäre eine gute Gelegenheit gewesen, den Unterschied zum relativen Schätzen im Rahmen von Scrum darzustellen. Das klappt nämlich über alle Maßen gut.

  2. Stefan2016-08-14 18:27:36

    OMG, selten so gelacht.

    Nein, lieber Matthias: Entwickler WOLLEN GAR NICHT SCHÄTZEN!

    Die Schätzkrankheit existiert nur deshalb, weil es in jedem Unternehmen sogenannte Betriebswirte gibt, oft in Rolle sogenannter Controller oder Programmanager und ihrer Handlanger (der sogenannten Projektmanager), die dämliche Fragen stellen wie:
    "Und was kostet das nun alles zusammen?", und dann auch noch vorschreiben, dass man das DAS-ALLES-ZUSAMMEN aufschreibt, bevor man eine Chance hat es zu kennen.

    Und alle verfallen dann in das Utopiesyndrom (a/k/a "Schwarmdummheit"),
    glauben plötzlich an die Glaskugeln ihrer ausgefeilten Schätzmethodiken, erfinden PMI, IPMA, Prince2, Schätzpoker und was für ein Glaubensmodell auch immer, und fahren halt ihre Festpreisprojekte strukturiert und professionell an die Wand.

    Nein, nein das Schätzen ist nicht das Problem. Die Betriebswirte sind es.
    Die haben nämlich an der Uni nicht gelernt, dass man nicht in die Zukunft schauen kann.
    Und sie kriegen beigebracht, dass nichts unter 100% gut ist.

    Wenn der agile Festpreis (was auch immer das sein mag ;-) ) endlich in den Planungsebenen
    der Unternehmen angekommen und VERSTANDEN wurde,
    UND zu allem Überfluss auf Seiten des Kunden das nötige Vertrauen,
    beim Entwickler hinreichende Kompetenz und
    auf beiden Seiten Engagement und Kommunikationsfähigkeit vorhanden sind,
    dann könnte da was draus werden.

    Da krankt's nämlich. Nicht am Schätzen.

    Scheint also doch etwas komplexer zu sein, das Problem, oder?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.