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?

Agile Toolbox
Scrum
Scrum Artefacts
bgloger-redakteur
February 24, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen
BG

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?
BG

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?

Scrum by the book - Die Power agiler Prinzipien
BG

Scrum by the book - Die Power agiler Prinzipien

Organisieren für das Dringliche – oder der Verlust des Wesentlichen
BG

Organisieren für das Dringliche – oder der Verlust des Wesentlichen

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode
BG

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode

Statt einer Rezension – OKR als Rezept
BG

Statt einer Rezension – OKR als Rezept

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren
BG

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen
BG

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt
BG

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt

FRAGE: Warum macht ihr eigentlich kein SAFe®?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe®?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?