Jede Methode, jede Technik oder jedes Werkzeug ist nicht an sich gut oder schlecht, sondern wird es erst durch die Art und Weise des Gebrauchs. Ein Hammer kann hilfreiches Werkzeug sein genauso wie zerstörerische Waffe. Was in der physischen Welt aufgrund unserer Erfahrung sofort klar ist, gilt aber für weniger greifbare Werkzeuge ebenso: Auch ein scheinbar harmloses Burndown-Chart im Scrum birgt in den falschen Händen mit zweifelhaften Absichten viel Sprengkraft.
Zunächst ist ein Burndown-Chart ein Hilfsmittel, um den Fortschritt im Sprint oder im Release insgesamt aufzuzeigen. Mit Hilfe dieses Werkzeugs kann das Team einschätzen, wie gut es vorankommt. Daraus lässt sich die Geschwindigkeit des Teams (in Storypoints pro Sprint) ermitteln und mit den vorherigen Sprints desselben Teams vergleichen. Da nach und nach Hindernisse beseitigt werden und die Prozesse im Team mit jeder Retrospektive selbstorganisiert verbessert werden, steigt diese Geschwindigkeit in der Regel von Sprint zu Sprint. Die Visualisierung des Fortschritts als Burndown und die Geschwindigkeit als Kennzahl helfen also dem Team die eigenen Fortschritte messbar und steuerbar zu machen.
Das funktioniert allerdings nur solange diese Messung angstfrei erfolgt. Käme ein ebenso zahlenverliebter wie naiver Manager auf die Idee, eine Normgeschwindigkeit zu fordern oder die Geschwindigkeiten von Teams miteinander in Konkurrenz zu bringen und entsprechende Bonussysteme zu installieren, ginge der Nutzen von Burndown-Chart und Geschwindigkeitsmessung schnell verloren. Nicht nur, dass die derart unter Druck gesetzten Mitarbeiter die Messung zu ihren Gunsten verfälschen würden und damit das Werkzeug für den Manager wertlos würde, auch das Team verlöre damit ein wichtiges Instrument zur Justierung der eigenen Leistung. In den falschen Händen mit zweifelhafter Absicht verwandeln sich also nützliche Werkzeuge und Methoden ganz schnell zu Massenvernichtungswaffen von Motivation und Produktivität.
If you give a manager a numerical target, he’ll make it even if he has to destroy the company in the process.
W. Edwards Deming
Scrum ist in dieser Hinsicht ein wenig naiv, indem von einer recht idealen und förderlichen Umgebung für das Team und Projekt ausgegangen wird. In der Realität ist das aber nicht so. Da gibt es oft mächtige Stakeholder die nur allzu gerne die Offenheit von Besprechungen und Transparenz von Steuerungswerkzeugen für Ihre Zwecke nutzen oder wenigstens die Daten unpassend interpretieren. Ein guter Scrum-Master oder Projektleiter beschützt sein Team auch in dieser Hinsicht und verhindert, dass Werkzeuge absichtlich oder unabsichtlich gegen das Team verwendet werden.
2 Kommentare
Kannst Du Gedanken lesen? Genau diese zwei Seiten der Medaille habe ich gestern in meiner Vorlesung thematisiert.
Vielleicht treiben uns einfach nur die gleichen Probleme um? Freut mich jedenfalls, dass ich mit meiner Wahrnehmung nicht alleine bin.