Reporting built in!

In allen Unternehmen, bei denen ich bereits eine Scrum-Implementierung begleiten durfte, war das Thema Reporting immer ein schwieriges und kontrovers diskutiertes. Meistens sind der Hintergrund die Statusreports aus dem klassischen Projektmanagement mit einer Ampel, Ergebnissen, Aktivitäten, Risiken und Handlungsbedarf - in mehr oder weniger abgewandelter Form. Vielleicht fehlt mir ein bestimmtes Gen, aber ich konnte aus diesen Statusreports noch nie relevante Infos rausziehen.Was man sich ansieht und was bei den Report-Lesern hängen bleibt, ist die Ampel. In der Regel steht sie auf Grün - höchstens mal Gelb - niemals jedoch würde man sich die Blöße geben, dass man auf Hilfe von außen angewiesen ist. Die Personen, die diesen Report erstellen müssen, halten ihn in der Regel für überflüssig und nicht aussagekräftig. Schreibt man etwas Unerwünschtes hinein, muss man sich mit Nachfragen rumquälen, die jedoch nur davon abhalten, das Problem zu lösen - denn Unterstützung und Hilfe sind eher ein Ausnahmefall.Und dann kommt plötzlich Scrum. Die POs müssen erst die neuen Artefakte kennen- und nutzen lernen. Das Management und sonstige Reporting-Anforderer sind aber in der Regel etwas schneller als dieser Gewöhnungsprozess. Sie hatten ja vorher einen Status-Report und auf einmal haben sie nichts - oder vielleicht ein paar Zettel. Also fängt man an, sich Gedanken zu machen: Wie könnte ein Reporting in Scrum aussehen?

• Kann man eine Ampel in das Burndownchart einbauen (denn auf die Ampel verzichten wollen wir eigentlich nicht!)?
• Wie können wir abbilden, was gerade im Team los ist (z.B. ein Entwickler fällt für 3 Monate aus)?
• Wie können wir uns im Nachhinein rechtfertigen, wenn in einem halben Jahr doch etwas schief geht?

Oft vergisst man dabei, dass das Reporting in Scrum eigentlich "Built in" ist! Pflegt der Product Owner die ureigenen Artefakte wie den Releaseplan kontinuierlich und wird ein Burndownchart für das aktuelle Release geführt, sollten alle relevanten Informationen vorliegen und sogar aussagefähiger sein als jede Prosa. Diese Artefakte zeigen genau, was tatsächlich bereits geliefert wurde und was in Zukunft geplant ist. Eine Erklärung, warum das so ist, ist natürlich in keinem der beiden Reporting-Vorgehen ausgeschlossen.Was muss der Kunde oder das Management über diese Form des Reportings wissen? Wie ein PO auf einem meiner Projekte so schön anmerkte: "Es wird viel zu oft in vorauseilendem Gehorsam etwas erstellt, das für den Kunden vielleicht zu viel, zu wenig oder in anderer Art und Weise unzureichend ist. Wir müssen erstmal verstehen, was der tatsächliche Bedarf ist!" Daher:

• Versucht so wenig wie möglich ausschließlich auf schriftliches Reporting zu setzen. Nehmt die Artefakte und geht damit zu den Stakeholdern!
• Erfragt genau, was die Stakeholder an Information benötigen. Kommt ihnen ggf. entgegen und versucht einen Weg zu finden, wie es möglichst wenig Aufwand für euch bedeutet. Betrachtet die Anforderungen jedoch kritisch - warum wird danach gefragt? (mangelndes Vertrauen, Reporting nach oben, Vergleichbarkeit zu anderen Reports, die der Stakeholder bekommt etc.). Macht es wie mit eurem Produkt: Versteht den Kunden bzw. in diesem Fall den User des Reportings.
• Bezieht euer Team in die Pflege der Artefakte mit ein. Macht das Reporting zum Reporting des Teams, nicht zum Reporting für die Stakeholder. Eine Kopplung, nicht eine Entkopplung muss stattfinden.

Welche Erfahrungen habt ihr gemacht? Was braucht euer Kunde? Wie integriert ihr das in den Prozess bzw. nutzt es gleichzeitig als Reporting für das Team?