In einem von mir betreuten Projekt begegnete mir recht häufig das Phänomen, dass die Teams ihre Sprints sehr konservativ geschätzt haben und regelmäßig Anforderung nachziehen mussten. Dabei haben sich die Teams nie überschätzt, sondern (fast) immer unterschätzt, obwohl alle sehr erfahren im Umgang mit Schätzgrößen und Velocity waren. In der Literatur wird oft davon gesprochen, dass ein Team seine Sprints möglichst genau einschätzen sollte. Ist dieses Phänomen also ein Problem?
Viele Menschen werden zu dieser Frage viele Meinungen haben. Meine Position hierbei ist eindeutig: »Nein, wenn …«
Grundsätzlich können wir uns sicherlich darauf einigen, dass es weit problematischer ist, wenn ein Team sein Commitment regelmäßig nicht einhalten kann, weil es die eigene Leistungsfähigkeit überschätzt. Dabei ist es mir vollkommen egal, ob sich die Kollegen einfach zu viel vornehmen, oder ob sie alles schaffen und der Product Owner die Abnahme verweigert, weil die Umsetzung ungenügend ist. Das Outcome ist in beiden Fällen gleich: das Team konnte sein Versprechen nicht einlösen. Die Folge davon ist, dass auch der nächste Sprint versaut ist, und unser Releaseplan auch häufiger als nötig überarbeitet werden muss. Noch schlimmer wird es, wenn Abhängigkeiten zwischen Teams bestehen.
Wenn sich das Team jedoch unterschätzt, kommen wir schneller voran. Auch dann müssen wir unseren Releaseplan überarbeiten, bewegen uns jedoch in eine wesentlich angenehmere Richtung. Und hier sind wir auch schon bei einem ganz wichtigen Punkt angekommen: es fühlt sich einfach sehr viel angenehmer an, schneller voranzukommen und seine eigenen Erwartungen zu übertreffen.
Wir haben alle gelernt, dass es nicht schlimm ist, wenn man sich mal verschätzt. Trotzdem fürchten sich viele Teams davor, ihr Commitment nicht einhalten zu können und unangenehme Fragen beantworten zu müssen. Vielleicht sind sie noch zu sehr in alten Denkstrukturen verhaftet, die viel mit Strafen bei Nichterfüllung einer Erwartung zu tun haben. Aber auch Kollegen, die schon lange agil arbeiten, und die schon lange in einem Umfeld unterwegs sind, das Strafen im klassischen Sinne (Anpfiff eines Vorgesetzten) nicht kennt, neigen dazu, eine Erwartung lieber zu übererfüllen als sie nicht zu erfüllen.
Das kann ich niemandem zum Vorwurf machen. Dabei handelt es sich um eine gewöhnliche menschliche Sichtweise. Niemand enttäuscht gerne, jeder überrascht gern positiv. Das ist weder schlimm noch schädlich oder problematisch. Es besteht jedoch die Möglichkeit, dass wir das zu einem Problem machen, indem wir sagen, dass es unsere Planung störe und uns dazu zwinge, immer wieder unseren Releaseplan zu überdenken.
Doch ist nicht gerade das das Wesen der Agilen Vorgehensweise? Wir lassen uns darauf ein, keinen unverrückbaren Releaseplan zu Beginn eines Projekts zu erstellen, weil wir wissen, dass dies sowieso ein Ding der Unmöglichkeit ist. Ein unerwartet schnelles Vorgehen behindert keine Abhängigkeiten der Teams untereinander, es führt auch nicht zu einem schlechteren Produkt oder unzufriedenen Anwendern, ganz im Gegenteil. Es widerspricht lediglich dem Wunsch, einen Sprint möglichst genau zu planen.
Ein Problem haben wir nur dann, wenn der Product Owner sein Backlog nicht so gut vorbereitet und gepflegt hat, dass er von der Entwicklung überrascht wird und keine sinnvollen Anforderungen nachziehen kann. Aber seien wir ruhig ehrlich: in diesem Fall macht der PO einfach einen schlechten Job.
Ich will nicht, dass ein PO fertig ausgearbeitete Anforderungen mit Abnahmekriterien für acht Sprints vorbereitet hat. Spätestens nach drei Sprints muss er sowieso die Hälfte davon wegwerfen oder zumindest überarbeiten (wenn wir wirklich agil vorgehen und nicht nur Wasserfall im Kleidchen machen). Ich möchte, dass ein PO zu Beginn des einen Sprints bereits Material für den Folgesprint komplett hat. Das ist eine recht gute Faustregel. Damit sollte er genug Nachzügler zur Verfügung haben, die geschätzt, priorisiert und ausgearbeitet sind.
Die Einschätzung des Bedarfs liegt damit ausschließlich beim Product Owner. Das Team nimmt sich die Dinge vor, die es glaubt, auch umsetzen zu können. Auch wenn es dem PO nicht gefällt, auch wenn er sich sicher ist, dass sich das Team erneut deutlich unterschätzt, liegt die Entscheidung ausschließlich beim Team. Product Owner oder Scrum Master dürfen zwar die Frage stellen, ob sie sich sicher sind, weil sie in den letzten Sprints schließlich jeweils deutlich mehr geschafft haben, aber sie sollten sich davor hüten, das Team zu stark zu beeinflussen. Die Entwickler entscheiden, wie viel sie sich in einem Sprint vornehmen. Das ist ein Kernprinzip, an dem nicht gerüttelt wird. Das ist die Unwandlung des Push-Prinzips in ein Pull-Prinzip.
Jetzt ist sich der Product Owner sicher, dass sich das Team unterschätzt hat. Was soll er also tun? Die Antwort ist ganz einfach: nichts. Sorgen Sie als PO lediglich dafür, dass sie vorbereitet sind, indem sie genug Material haben, dass Sie nachziehen können. Als Scrum Master können Sie durchaus in der Retrospektive die Frage danach stellen, warum das Team dazu neigt, übervorsichtig in den Sprint zu gehen. Vielleicht kommen sie einigen verborgenen Befürchtungen auf die Spur, die sie ausräumen können. Vielleicht auch nicht. Vielleicht bemerken Sie lediglich, dass sich das Team ganz einfach wohler fühlt, wenn es auf der »sicheren Seite« steht. Ich würde Ihnen in diesem Fall dazu raten, nicht auf Biegen und Brechen den Versuch zu unternehmen, das Team dazu zu bringen, präzisere Sprintschätzungen vorzunehmen. Achten Sie lediglich darauf, dass der Product Owner gut vorbereitet ist.
Sehr oft sehe ich, dass Scrum Master, Product Owner und auch das Team selbst bemüht sind, ihren Sprint möglichst genau vorauszuplanen. Da wird die Velocity regelmäßig ausgewertet, Buch geführt, welcher Entwickler wann einen halben Tag Urlaub hat oder auch nur eine Stunde in einem Meeting verschwindet, und dann wird festgelegt, dass das Team im bevorstehenden Sprint 42 Punkte schaffen sollte, weil das genau der errechneten Entwicklunggeschwindigkeit entspricht. Ich halte das für leicht übertrieben. Es ist vollkommen in Ordnung, wenn man einen Blick auf die Velocity wirft, aber es sollte dann die Frage erlaubt sein, ob Punkte und Velocity nicht eine zu vage Größe sind, um so konkret angewandt zu werden. Wichtiger ist in diesem Zusammenhang sogar die Frage danach, was man eigentlich inhaltlich in einem Sprint erledigen möchte. Geht es darum, einen Zahlenwert möglichst genau zu treffen, oder ein möglichst rundes Paket für unsere Kunden zu schnüren?
Lassen Sie sich als Product Owner, Scrum Master oder Entwickler nicht treiben, wenn andere Ihre Schätzungen und den Burndown-Chart betrachten und bewerten. Diese Ding werden sehr oft herangezogen, um die Effizienz eines Teams oder einer Entwicklungsbteilung zu messen, dafür sind sie jedoch nicht geeignet. Das einzige geeignete Messinstrument für die Leistungsfähigkeit eines Entwicklungsteams ist die Qualität der gelieferten Features und die damit verbundene Kundenzufriedenheit. Achten Sie als Scrum Master darauf, dass Zahlen und Charts nicht überbewertet werden. Das bring Sie und das Team lediglich in eine Zwangslage, bestimmte Quoten zu erfüllen, aber gerade das widerspricht unserem Wunsch, die bestmögliche Software zu entwickeln.
