Kaum eine Organisation verzichtet auf das Folterinstrument namens „Reporting“.
Ein Auftraggeber außerhalb der Organisation („Kunde“) oder innerhalb („Manager“) verpflichtet den Auftragnehmer/Mitarbeiter dazu, über sein Handeln und den Fortschritt von Projekten regelmäßig Rechenschaft abzulegen: „Was Du nicht misst, kannst Du nicht steuern“.
Meist werden neben ein paar qualitativen Aussagen zum Stand der Dinge Key Performance Indicators (KPIs), Kurven und Statistiken gefordert. Zahlen sollen objektive Transparenz schaffen und so das Steuern erleichtern.
So weit, so gut.
Es gibt allerdings einen nahezu allgegenwärtigen Effekt, der viele Berichtende in den Wahnsinn treibt: Zahlen ohne Sinn.
- Es werden sehr häufig Zahlen und Statistiken angefordert, die schwer oder aufwändig zu ermitteln sind. Entweder, weil es Quantifizierungen qualitativer Effekte sind („Wie ist die Stimmung im Team?“) oder weil die eingesetzten Systeme die Zahlen nicht von selbst hergeben, sie also manuell gesammelt oder aus dem Vorhandenen zusammeninterpretiert werden müssen.
Kontraproduktiver Nebeneffekt zum reinen Zeitaufwand: Schnell setzt hier ein solider Schlendrian ein, denn wenn der Berichtende schon riesige Mühe hat, die Zahlen zu besorgen, kann sicher auch niemand nachvollziehen, ob sie wirklich stimmen! - Der Gegenstand des Reportings bildet gar nicht die Realität des Projekts ab.
Beispiele: Über Epics soll berichtet werden, aber viel von dem, was die Teams tun, gehört zu keinem Epic. Die „Lines of Code per Day“ sollen berichtet werden, sie haben nur praktisch keine Aussagekraft. In einem Scrum-Projekt wird die Team-Velocity verlangt, aber das Team jeden Sprint umgebaut, was für die Velocity jedes Mal einen Reset bedeutet und die Werte zwischen Sprints unvergleichbar macht. - Das Management hat fast nie eine klare Idee, was es aus den Zahlen überhaupt für Steuerungsimpulse ableiten soll. Wenn KPI X nach oben oder nach unten geht, was heißt das und was macht man dann? Was sind gefährliche Grenzwerte? Was ist Rauschen, was Signal? Keine Ahnung, aber schön die Zahlen zu haben…
- Wenn ein Manager doch eine Idee davon hat, was er tun will, wenn sich die Zahlen in die eine oder andere Richtung bewegen, trifft er Entscheidungen oft allein auf dieser Basis (Am Tag nach dem Release: „Die Zahl der beobachteten Produkte im Shop ist nach Update der Benutzeroberfläche gesunken? Panik! Rückgängig machen!“).
Dabei können Zahlen nur ein Indikator für Probleme sein, da sie immer eine – zum Teil grobe – Vereinfachung sind und einen qualitativen Kontext brauchen, um korrekt verstanden zu werden: Natürlich geht die Benutzung einer neu gestalteten Funktion immer erstmal zurück, bis sich die Leute daran gewöhnt haben. Die zurückgehende Team-Velocity ist auf Urlaube zurückzuführen. Das Burndown, das Story Points aus abgeschlossenen User Storys darstellt, verlässt kurz nach Beginn des Betrachtungszeitraums seinen Ideal-Korridor – weil das Team richtigerweise mit der größten, risikoreichsten Story beginnt und deshalb die Abtragung erst später, dafür aber größer als bei den anderen Storys erfolgt.
Möglichst wenige, richtig definierte, realitätsnahe, leicht ermittelbare Zahlen können ein sehr hilfreiches Instrument beim Steuern von Projekten sein – wenn klar ist, was sie einem sagen und was daraus folgt.