Follow my new blog

Mittwoch, 11. Januar 2012

Schätzungen auf dem Prüfstand

Kann man verlässlich schätzen, wie lange ein Team braucht, Anforderungen in einsetzbare Software zu übersetzen? Kann man das für einen Horizont von wenigen Wochen? Kann man das für Monate oder Jahre?

Diese Frage führt immer wieder zu hitzigen Diskussionen. Eine der am besten besuchten Sessions auf der letztjährigen DevCon drehte sich auch um diese Frage. Das Interesse an einer Antwort, ja geradezu an einer Erlösung von diesem Thema ist groß.

Ich habe dazu auch meine Meinung und bin stolzes Mitglied der XING-Gruppe "Stop Software Estimation Now!" :-)

image

Aber wenn ein Thema so lange und so fortschrittslos diskutiert wird, frage ich mich auch: Gibt es hinter der Frage nicht ein grundsätzlicheres Problem? Sitzen wir vielleicht einem Missverständnis auf?

Vielleicht rennen wir ja kollektiv gegen eine Wand - und sehen nicht, dass nur ein paar Schritte weiter eine Tür ist.

Solch eine Tür meine ich nun entdeckt zu haben. Ich glaube, die Diskussion zum Thema Schätzen kommt aus einem ganz simplen Grund nicht voran: Wir messen einfach nicht den Erfolg des Schätzens. Keine Partei weiß so richtig, ob Schätzen wirklich erfolgreich ist.

Der Weg aus dem Problem mit dem Schätzen besteht aus meiner Sicht daher aus zwei Schritten:

1. Festlegen, wann eine Schätzung erfolgreich ist; wir brauchen Kriterien.
2. Messen, ob eine Schätzung nach den aufgestellten Kriterien erfolgreich war.

Klingt einfach, oder? Und man fragt sich, ob das nicht immer schon so gehandhabt wurde. Ich glaube, nein. Mit dem Schätzen ist man schnell bei der Hand. Aber weder werden Schätzungsqualitätskriterien bilateral (!) festgelegt, noch wird geprüft, wie die Schätzqualität am Ende war.

Bilateral Schätzungsqualitätskriterien festlegen

Beim Schätzen sind mindestens zwei Parteien beteiligt: der Kunde und das Entwicklungsteam. Der eine hat das Geld und die Zeit, die anderen sollen sagen, was sie im Rahmen dieser Budgets leisten können. Das Team muss also abschätzen, wie viel Geld und Zeit es für einen Scope braucht oder ob es einen Scope innerhalb eines gewissen Budgets realisieren kann.

Wenn nun Geld, Zeit und Scope zu einem Vertrag zwischen diesen Parteien gehören, dann natürlich auch die Schätzung. Deshalb müssen sich beide einig darüber sein, wann eine Schätzung gut war. Sonst ist es schlecht mit der Schätzerfolgskontrolle für beide Seiten. Und ohne Erfolgskontrolle kein Lernen, um es das nächste Mal genauso zu machen, weil es gut war, oder es besser zu machen, weil es nicht gut war.

Hier sehe ich das erste Defizit: Üblicherweise werden Schätzungsqualitätskriterien nicht explizit festgelegt und schon gar nicht bilateral. Es gibt einfach keine Diskussion darüber. Die Schätzung besteht aus zwei Zahlen (“Wir brauchen M Monate und G Euro für den gegebenen Scope.”), die irgendwer irgendwie im Blick behält. Wenn M und G zur Neige gehen, schaut man, wie viel vom Scope noch übrig ist. Dann stellt man fest, dass M und G nicht reichen werden und die Nachverhandlungen beginnen.

So tut man das halt. Darüber wird vorher nicht gesprochen. Das nehmen beide Seite als normal hin – und ärgern sich doch. Oder zumindest eine Seite ärgert sich. Die andere mag es nicht kratzen, weil sie eine Horde von Anwälten für solche Nachverhandlungen beschäftigt.

Dazu kann man nun sagen: “So ist halt die Welt.” Doch das will ich nicht akzeptieren, solange diese Parteien auf der anderen Seite klagen, “alles” sei so teuer. Denn Aufwand für Nachverhandlungen aufgrund schlechter Schätzung ist unnütz, falls schlechte Schätzungen die Norm sein sollten. Es wäre dann auf die Dauer billiger das Schätzen zu verbessern. Dafür braucht man jedoch Qualitätskriterien. Die müssen bilateral und explizit definiert sein, weil sie zum Vertrag gehören. Und die müssen dann auch am Ende überprüft werden.

Explizite Schätzungsqualitätskriterien

Müssen denn die Softwarevertragsparteien aber länglich über Schätzungsqualitätskriterien sprechen? Sind die nicht offensichtlich?

Nein. Das ist ja das Problem. Darüber bestehen unterschiedliche Meinungen, über die nicht gesprochen wird.

Offensichtlich sind natürlich die Schätzwerte selbst, z.B. geschätzte Zeit und geschätztes Geld. Die werden mit dem Soll an Scope verglichen und man erfährt, ob das geschätze Budget ausgereicht hat oder nicht.

Zu diesen offensichtlichen Schätzwerten sollten dann allerdings noch mindestens drei weitere Kriterien treten:

Hinnehmbare Budgetabweichung: Es sollte ausdrücklich darüber gesprochen werden, welche Abweichung von den Schätzwerten noch als Erfolg verbucht werden darf. Sind 5% Abweichung ok oder 10% oder gar 20%? Schätzungen sind eben Schätzungen. Dass ein Team punktgenau landet, ist nicht zu erwarten. Also sollte man sich darüber unterhalten, wie groß der Landeplatz ist.

Hier sind sogar zwei Seiten zu unterscheiden: Am Anfang stehen ein Termin und ein Geldbetrag in Bezug auf einen Scope. Der Kunde ist zufrieden, wenn aus seiner Sicht beides innerhalb einer zu definierenden Abweichung eingehalten wird.

Das Team hat zur Erreichung dieser Fixpunkte aber auch noch einen Aufwand geschätzt, der durch den Geldbetrag gedeckt werden soll. Selbst wenn der Kunde also zufrieden ist, kann es sein, dass das Projekt aus Teamsicht floppt. Falls es den Aufwand erhöhen musste, um den Scope zum Termin zu liefern, ohne mehr Geld zu bekommen, ist die Schätzung auch schlecht gewesen – ohne, dass der Kunde davon etwas merken muss.

Hinnehmbarer Qualitätsverlust: Inzwischen wissen wir ja, dass es eben nicht nur um Geld, Zeit und Scope geht, sondern immer auch um Qualität. Der Kunde stellt funktionale und nicht-funktionale Anforderungen (Scope), die ein Entwicklungsteam mit unterschiedlicher interner Codequalität umsetzen kann. Inwiefern der Scope innerhalb des geschätzt nötigen Budgets umgesetzt wird, beobachtet der Kunde natürlich genau. Fällt der Erfüllungsgrad unter eine bestimmte Marke, übt der Kunde Druck aus. Darunter leidet gewöhnlich die interne Codequalität. Das sollte so nicht sein, ist aber so. Deshalb ist es wichtig, sich darüber Gedanken zu machen, ein wie großer Verlust an dieser Qualität noch als Erfolg beim Schätzen verbucht werden darf. Denn beim Schätzen besteht ja der Anspruch, dass die interne Qualität konstant über die geschätzte Dauer gehalten wird. (Dass man die interne Qualität dann auch noch messen können muss, um eine Abweichung vom Soll feststellen zu können, steht auf einem anderen Blatt.)

Hinnehmbarer Zufriedenheitsverlust: Der Kunde ist zufrieden, wenn er seinen Scope innerhalb des geschätzten Budgets bekommt. Wie ein Team das schafft, ist ihm in der Regel ziemlich egal. Überstunden, Wochenendarbeit, Urlaubssperre, Zuckerbrot, Peitsche… das schert ihn nicht. Schade – aber wohl nicht zu ändern.

Ein Team sollte für sich allerdings in dieser Hinsicht einen Anspruch definieren. Ist eine Schätzung erfolgreich, wenn zwar der Scope zum geschätzten Termin abgeliefert wird – aber die Stimmung auf Null ist? An dieser Stelle geht es mir nicht um eine Abweichung beim Aufwand, ohne dass der Kunde das zu spüren bekommt. Dafür gilt es, eine hinnehmbare Budgetabweichung zu definieren (s.o.).

Nöjd Crispare HistorikIch glaube, genauso wichtig wie die Beobachtung der Ressourcen Zeit und Geld, ist die der Motivation, der Stimmung, der Zufriedenheit, der Kompetenz (s. dazu z.B. Jeff Sutherland, “Happyness Metric – The Wave of the Future”). Alle Teammitglieder sind wertvolle Ressourcen – warum sollte man sie sonst bezahlen? Also sollte man nicht leichtfertig mit ihnen umgehen. Sie können ihren Wert nur voll einbringen, wenn sie “wie geschmiert funktionieren”.

Eigentlich mag ich diesen Ressourcen-Jargon nicht, aber an dieser Stelle scheint er mir nützlich, um den Kontakt zu anderen Schätzungsqualitätskriterien zu halten.

“Wie geschmiert funktionieren” die Teammitglieder nur, wenn sie das Gefühl haben, dass ihre persönlichen Bedürfnisse erfüllt werden. Sie haben einen Anspruch daran, wie ihr Arbeitsumfeld zur Befriedigung ihrer Bedürfnisse beitragen soll. Dazu zählt z.B. “regelmäßiges Gehalt für das Bedürfnis ‘Certainty’” oder “nette Kollegen für das Bedürfnis ‘Connection’” oder “Zeit fürs Lernen für das Bedürfnis ‘Growth’” (Bedürfnisbezeichnungen nach Tony Robbins “Why we do what we do”).

Dass nicht immer alle Bedürfnisse voll erfüllt werden können, weiß jeder. Man ist deshalb damit zufrieden, wenn sie recht verlässlich innerhalb eines gewissen Bereichs erfüllt werden. Geschieht das allerdings nicht… dann geht die Stimmung in den Keller. Unaufmerksamkeit schleicht sich ein, die Fehler nehmen zu, Demotivation zieht ihre Kreise, Dienst nach Vorschrift bekümmert den Kunden, Krankmeldungen nehmen zu, Fluktuation entsteht usw.

Das sind Entwicklungen, die nicht nur persönlich bedauerlich für die Teammitglieder sind, sondern Unternehmen Geld kosten. Diese Kosten sind allerdings meist unsichtbar für das Projekt. Wenn Teammitglieder aus Frust über das Projekt kündigen, das unter hohem Druck steht, weil ein Termin zu halten ist, dann wird die Einarbeitung eines neuen Teammitglieds nicht dem Projekt zugeschlagen – obwohl das Projekt sie verursacht.

Deshalb scheint es mir nützlich, die Zufriedenheit der Teammitglieder als Kriterium heranzuziehen. Dieser Messwert kann innerhalb des Teams erhoben werden, auch wenn niedrige Zufriedenheit außerhalb des Teams zu Kosten führt.

Ein Projekt kann also mit dem gewünschten Scope zum geschätzten Termin mit dem geschätzen Aufwand und mit hinnehmbarer Qualität abgeschlossen werden – und doch war die Schätzung insgesamt nicht erfolgreich, wenn nämlich trotz der Einhaltung dieser Kriterien die Zufriedenheit aus dem definierten Rahmen gefallen sein sollte. Das kann z.B. passieren, wenn die Einhaltung der anderen Kriterien dazu führt, dass Stress entsteht, der messbar unzufrieden macht. Das ist dann ein Raubbau an der “Ressource Entwickler”.

Fazit

Ob Schätzungen funktionieren oder nicht… Ich habe da zwar meine Meinung, doch ich empfehle ihnen heute nur: Messen Sie doch einfach mal. Aber richtig.

Setzen Sie sich im Team oder noch besser mit dem Kunden zusammen und definieren Sie die Erfolgskriterien für Schätzungen. Bleiben Sie allerdings nicht bei Geld und Zeit stehen. Weiten Sie Ihren Blick und definieren Sie auch Ihren Anspruch an die innere Qualität und Ihre persönliche Zufriedenheit.

Dann messen Sie vorher, während und nachher. Und dann vergleichen Sie die Messwerte mit Ihren vorher definierten Ansprüchen.

Wenn die Messungen innerhalb der Toleranzgrenzen sind, dann funktioniert das Schätzen. Glückwunsch.

Aber wenn sie wiederholt außerhalb der Toleranzgrenzen liegen… tja, dann funktioniert das Schätzen eben nicht. Soviel Einsicht sollten Sie dann haben und Ihre Praxis ändern.

 

PS: Dass die Diskussion über das Schätzen so hitzig verlaufen, liegt also daran, dass da unterschiedliche Wertesystem aufeinanderprallen. Die Kriterien, wann Schätzungen erfolgreich sind, differieren. Deshalb lohnt es, einen Schritt zurückzutreten und erst einmal zu schauen, was denn diese Kriterien überhaupt sind.

Kommentare:

Florian hat gesagt…

Hallo Ralf,

ich finde deinen Gedankengang zutreffend. Aus meiner Erfahrung kann ich nur bestätigen, dass sich kein Mensch fragt, ob die Schätzung eines Projekts erfolgreich war oder nicht. Deine Ideen für Schätzungsqualitätskriterien finde ich sehr gut. Vor allem, weil du nicht nur auf die Punkte Zeit und Geld fixiert bleibst, sondern auch den Faktor Mensch (Motivation, Zufriedenheit,...) mit einbeziehst. Bei mir im Unternehmen werde ich nicht um Schätzungen herum kommen, deshalb ist dein hier geäußerter Ansatz sehr hilfreich um in Zukunft besser damit umgehen zu können.
Allerdings muss für die Bewertung einer Schätzung die Bereitschaft vorhanden sein über das eigene Verhalten oder das Projekt zu reflektieren. Ohne diese Grundvoraussetzung sind deine Qualitätskriterien dann zwar schön zu lesen, aber mehr auch nicht.

Viele Grüße
Florian

Ralf Westphal - One Man Think Tank hat gesagt…

@Florian: Die menschliche Seite ist mir sehr wichtig. Und auch das Thema Qualität.

Beides ist nämlich immer wieder in Diskussionen über das Schätzen präsent - nur nicht explizit. Das macht die Missverständnisse der Diskutanten aus.

Am Ende geht einem Unternehmen vor allem ums Geld. Deshalb stiert der PM auf die offensichtlichen Budgets.

Aber auch mangelnde Qualität hat mit Geld zu tun. Früher oder später. Und Motivationserosion hat auch mit Geld zu tun. Früher oder später.

Wenn ein Unternehmen es also wirklich ernst meint mit dem Geld, dann muss es diese Aspekte in den Blick nehmen.

Da das Geld, das durch Qualitätsabstriche und Motivationsverfall verschwendet wird so schwer zu zählen ist, müssen wir Qualität und Motivation direkt messen - was auch nicht leicht ist. Aber besser so, als gar nicht.

Ich würde mich freuen, wenn du bei deinen unausweichlichen Schätzungen in Zukunft diese Aspekte einbringen könntest. Zettel allemal eine Diskussion darüber an.

Matthias Bohlen hat gesagt…

Hallo Ralf,
ich bin zwar dafür, Schätzungen durch Messungen zu ersetzen, wollte Dir aber trotzdem diesen Link geben, weil Todd Little sich anscheinend doch mit der Qualität von Schätzungen befasst: http://www.toddlittleweb.com/Papers/Agility,%20Uncertainty%20and%20Estimation.pdf

Schöne Grüße
Matthias

Ralf Westphal - One Man Think Tank hat gesagt…

@Matthias: Danke für den Link.

Für mich eine Bestätigung, dass das Schätzen nicht innerhalb der Schmerzgrenze derjenigen funktioniert, die es einfordern. Sie mögen an eine Verdopplung gewöhnt sein - aber den vierfachen Aufwand, der auch nur die Wahrscheinlichkeit eines Erfolges erhöht, werden sie nicht akzeptieren.

Damit ist der Schätzende zu unrealistischen Werten verdammt.

Da sich das nicht a priori dem Auftraggeber kommunizieren lässt, muss gemessen werden. A posteriori kann gehofft werden, dass "rote Zahlen" mehr bewegen als Engelszungen vorher.

Hinzu kommt: Die Studie hat natürlich nur die offensichtlichen Schätzwerte für Geld/Zeit untersucht. Ich behaupte aber mal ganz keck: Selbst die danach erfolgreichen Projekte sind nicht mehr in gleicher Weise erfolgreich, wenn man auch noch Qualität und Motivation hinzunimmt.

Golo Roden hat gesagt…

Hallo Ralf,

"Schätzen kommt aus einem ganz simplen Grund nicht voran: Wir messen einfach nicht den Erfolg des Schätzens. Keine Partei weiß so richtig, ob Schätzen wirklich erfolgreich ist."

Das stimmt in meinen Augen so nicht.

Die Velocity zB in Scrum ist nichts anderes als die Messung der Differenz der ursprünglichen Schätzung und der Realität, um zukünftig auf dieser Erfahrung besser schätzen zu können. Der Erfolg der Schätzung wird sehr wohl überprüft und fließt in zukünftige Schätzungen ein.

Auch das Event-Based Scheduling misst den Erfolg einer Schätzung, und lässt dies in zukünftige Schätzungen einfließen.

Wo fehlt Dir da das Messen?

Viele Grüße,


Golo

Ralf Westphal - One Man Think Tank hat gesagt…

@Golo: Das Problem liegt in den Erfolgskriterien. Das habe ich doch deutlich geschrieben:

Wenn ein Team das Sprint-Commitment einhält, dann heißt das nur, das in einer gewissen Zahl von Tagen eine gewisse Menge an SP realisiert wurden.

An der einen Zahl Velocity ist nicht abzulesen, ob dafür Überstunden gemacht wurden oder ein weiterer Entwickler eingestellt wurde oder die visionierte innere Qualität durchgehalten wurde.

Wer misst, bekommt immer nur das, was er misst. Darauf richten sich alle aus. Das kennen wir aus der Schule: es geht um die Zensur, nicht darum, ob man etwas kann. Nicht umsonst muss immer wieder ermahnt werden, "Nicht für die Schule lernen wir, sondern fürs Leben."

Das kennen wir auch vom Sport, Beispiel Joggen: Die Leute Joggen für den Kreislauf (und das Gewicht). Beim Gewicht tut sich dann wenig - aber egal, der Kreislauf bessert sich. Fein - nur leider kommt es dabei zur Muskelatrophie. Das weiß nur kaum jmd, weil man das nicht misst. Man schau nur auf den Puls.

Und wer nur auf die Velocity schaut, der bekommt eben Velocity und sonst nix. In Scrum ist nichts anderes drin. Wenn du in deine DoD auch noch eine Qualitätsmetrik einbaust, ist das natürlich wunderbar. Dann kann nichts als Done abgehakt werden, was keine passene innere Quali hat. Aber das ist ja das, was ich meine. Dann misst du das. Aber wer tut das? (Testabdeckung mag noch in der DoD drin stehen. Aber andere Maßstäbe?)

Und die Zufriedenheit, die Motivation der Entwickler? Ist ein Death March Project ein Erfolg, wenn am Ende doch irgendwie within budget geliefert wird? Wohl kaum.

Erfolg ist auch nicht, wenn du mit 50 ne Million auf dem Konto hast - aber schon den 3. Herzinfarkt. Zumindest nicht für mich. Aber genau darum geht es: man soll halt seine eigenen Erfolgskriterien fürs Schätzen finden und nicht nur auf Geld/Zeit starren. Am Ende wäre das aber auch ok, wenn multilateral so vereinbart. Dann halt selbst schuld.