Ich hatte kürzlich die Gelegenheit, mich mit einem Kollegen auszutauschen, der neuerdings erstmalig in einem größeren agilen Projekt arbeitet. Er berichtete mir von einigen Schwierigkeiten im Projekt, ein interessanter „Kristallationspunkt“ dieser Probleme zeigte sich im Thema „Schätzungen“ und wie diese im Team angegangen werden.
Zunächst ein paar Infos zum Hintergrund: Mein Kollege hat viel Erfahrung mit „klassischen“ Projekten, in denen er beteiligt und als (Teil-)Projektleiter eingesetzt war, von den Projekten waren auch viele erfolgreich. Er ist jetzt als technischer Berater in einem groß skalierten Scrum-Projekt, das für seinen Auftraggeber auch eine der ersten Berührungen mit agilem Vorgehen ist. Dementsprechend gibt es in dem Projekt und im Umfeld des Projektes eine bunte Mischung aus dem Wunsch, alles „richtig“ und „by the book“ zu machen und Erwartungen und Gewohnheiten, die sich noch sehr an dem bisherigen Vorgehen aurichten.
Eines der Rituale, das dort eingeführt wurde, ist auch das Planning Poker, mit dem den Sprint-Aufgaben Story Points gegeben werden. Daran störte sich nun mein Kollege sehr – von der Frage, warum man denn nun auf einmal Komplexität statt Aufwand schätzen sollte bis hin zu dem zähen Vorgehen, da man in Unkenntnis des Aufgabeninhaltes Zahlen „raten“ müsse.
Interessant war für uns im Gespräch darüber, dass sich einige Dysfunktionalitäten des Vorgehens genau an diesem Punkt heraus kristalisierten.
Der offensichtlichste Punkt ist der, dass es in dem Team aktuell kaum Teamarbeit gibt – im Endeffekt hat jedes Gruppenmitglied seine oder ihre Aufgaben und arbeitet diese innerhalb des Sprints ab, man kann kaum anderen helfen, da jeder ein Spezialgebiet bearbeitet. Das macht die Schätzrunden schwierig, da jeweils immer nur ein Teammitglied eine Aussage zur Komplexität machen kann, während die anderen versuchen zu „erraten“, was diese Person wohl schätzen wird.
Die eigentlichen Probleme im Team zeigen sich aber, wenn man beginnt zu hinterfragen, warum überhaupt Schätzungen gemacht werden. Wenn ja ohnehin jeder seine Aufgaben hat, wird die Schätzung dann benötigt um zu wissen, ob die Aufgaben in den Sprint passen? Soll mit dem Schätzen sichergestellt werden, dass alle im Team das gleiche Verständnis der Aufgabe haben?
Leider war die Antwort, dass das Schätzen benötigt werde, da das Projektcontrolling damit die Leistungsfähigkeit des Teams messen und überprüfen wolle. Darin sehe ich ein grundsätzliches Problem, das ich hier schonmal angesprochen habe, nämlich, dass ein Indikator zu einem (zumindest indirekten) Ziel erklärt wird. Schließlich soll sich – so die Erwartung des Controllings – der Output des Teams ja verbessern. Wenn das erwartet wird, so sorgt dies bestenfalls zu einem Drift der Schätzungen nach oben. Doch selbst, wenn das nicht der Fall wäre: Die Schätzung der Komplexität (meinetwegen auch des Aufwandes) der Aufgaben ist für diese Fragestellung eine absolut unbrauchbare Schätzgröße! Damit wird bestenfalls der konstante (oder steigende) Mittelabfluss sichergestellt, das sagt absolut nichts darüber aus, wie gut der Output des Teams ist! Dann sollte besser der Product Owner den Business Value der Features schätzen. (Und ja, auch da würde sich sicherlich die Schätzung verändern, wenn ich anfange, das zum Ziel zu erklären.)
Es gibt meiner Meinung nach einige Gründe, warum ein Schätzen durch ein Team sinnvoll sein kann. Beispielsweise, damit das Team weiß, wie viel Komplexität es im Sprint umsetzen kann. Hier kamen wir übrigens auf die Diskussion, warum dann nicht gleich Aufwand geschätzt werden sollte. Meiner Meinung nach deswegen, weil die Komplexität eine Einigung erlaubt, auch wenn die Skills im Team unterschiedlich verteilt sind. Es mag sein, dass ich für die Implementierung eines Features 5 Tage brauche, wenn ich mich in der Technologie nicht auskenne, eine erfahrenere Entwicklerin benötigt eventuell nur 2 Tage. So könnten wir uns nie auf einen Aufwand einigen, wohl aber darauf, dass eine CRUD-Applikation nicht allzu komplex wäre. Zudem kann ich mit der Schätzung von Komplexität auch belegen, dass zumindest ein ähnliches Verständnis für das Feature existiert. Nicht zuletzt habe ich damit einen Indikator, dass ein Team eine bestimmte Velocity hat und diese auch besser werden kann.
Das „Standardziel“ ist es, dass der PO mit den Schätzergebnissen eine Vorstellung davon hat, welche Features in einem längeren Zeitraum schaffen kann, diese Schätzungen helfen bei einer langfristigen Planung. Damit diese Schätzungen allerdings eine Aussagekraft haben, müssen eine ganze Reihe von Voraussetzungen erfüllt sein: Das Team muss relativ stabil sein, um seine Velocity kennen und halten zu können; die Schätzgrundlage muss stabil bleiben können, es darf also nicht durch falsche Zielvorgaben eine Veränderung der Schätzbasis belohnt werden; das Entwicklungsziel muss bekannt genug sein, um zukünftige Features sinnvoll und stabil beschreiben (und in der Komplexität kennen) zu können.
Kurz gesagt, Schätzen ist kein Selbstzweck. Bevor man eine Schätzmethode auswählt oder anwendet, sollte das Ziel der Schätzung klar sein, was in der Realität leider erstaunlich selten der Fall ist.