Agil, Berichtswesen, Kommunikation, Projektmanagement, Selbstorganisation

Beobachten und Messen

Agile Softwareentwicklung ist empirisch. Wenn möglich, werden Entscheidungen auf der Grundlage von Fakten getroffen.  Die benötigten Fakten werden an erster Stelle durch Verhaltens- und Ergebnisbeobachtungen erhoben. Aber was bedeutet Beobachtung im Kontext agiler Organisationen? Worauf sollten wir achten, damit Messungen nicht unseren Blick auf das Große und Ganze verschleiern, sondern zum Erfolg unserer Vorhaben beitragen?

Weiterlesen

Standard
Agil, Berichtswesen, Kommunikation, Projektmanagement, Scrum

Der Sprintbericht

Im Scrum wird zu jedem Sprintende sowohl der Projektfortschritt überprüft als auch nach Verbesserungsmaßnahmen für den Entwicklungsprozess gesucht. Die erzielten Ergebnisse sowie die Hindernisse auf dem Weg zur Spitzenleistung finden Eingang in einen Sprintbericht

Der Bericht schafft Transparenz für alle Beteiligten. Er informiert regelmäßig und objektiv. Nicht nur der Informationsfluss an das Management, sondern auch die teaminterne und die teamübergreifende Kommunikation wird durch diesen Bericht unterstützt.

Der Sprintbericht dient der Kommunikation von Messwerten. So, wie das Messen des Projektfortschrittes anhand fertiggestellter Features zu einer Ausrichtung des Teams dahingehend führt, Features auszuliefern, so wird sich die umgebende Organisation an den Inhalten des Sprintberichtes ausrichten. Damit fällt dem Autor des Berichtes eine aktive und organisationsgestaltende Rolle zu.

Der Bericht ist so kurz wie möglich und er wird zwischen dem Product Owner, dem Scrum Master und dem Team abgestimmt, bevor er einem weiteren Personenkreis zugänglich gemacht wird. Der Bericht wird direkt nach dem Sprint Review und der Sprint Retrospektive erarbeitet und spätestens am darauffolgenden Tag fertiggestellt. Für einen klaren Informationsstatus wird der Bericht an zentraler Stelle abgelegt, so dass er für alle Beteiligten jederzeit einsehbar ist. In einer Organisation mit mehreren Scrum Teams sollten die Sprintberichte einem einheitlichen Aufbau folgen.

Im Bericht wird wenig Augenmerk auf die Planungsebene gelegt, sondern vielmehr besteht der Schwerpunkt in einer Bestandsaufnahme beobachteter Fakten.

Das steht drin
Kontext

  • Der Name des Produktes oder der Komponente, für die das Scrum Team arbeitet.
  • Der Name des Product Owners und des Scrum Masters.
  • Die Sprintnummer und der Zeitraum des vergangenen Sprints sowie das Datum des Berichtes.
  • Der Name des Berichterstellers (also der Scrum Master oder der Product Owner).
  • Die Mitglieder des Teams mit ihren Rollen.

Die vergangenen Sprints

  • Der Arbeitsfortschritt (Product Burndown) und die Arbeitsgeschwindigkeit (Velocity).
  • Eine Verlaufslinie der Mitarbeiterkapazität lässt sich dem Arbeitsfortschritt gegenüberstellen. Wenn bestimmte Kapazitäten, wie zum Beispiel die Verfügbarkeit der Fachexperten, nicht ausreichend sind, können die Kapazitäten dieser Rollen mit einer separaten Verlaufslinie in einer anderen Farbe dargestellt werden.
  • Zusätzlich kann eine Information zum Budgetverbrauch und zum Zeitverbrauch enthalten sein.

Der letzte Sprint

  • Was war das übergeordnete Ziel des Sprints (Sprint Goal). Wurde das Sprintziel erreicht?
  • Welche konkreten Funktionen mit welchem Gewicht (Story Points) wurden ausgeliefert?
  • Welche Kapazität hatte das Team zur Erbringung der Leistung zur Verfügung, ggf. nach Teamrollen untergliedert.
  • Welche Hindernisse wurden beseitigt? Welche Verbesserungsmaßnahmen wurden umgesetzt?
  • Welche Hindernisse sind neu entstanden bzw. bestehen noch immer und welche Verbesserungsmaßnahmen wurden aus dem vergangenen Sprint abgeleitet? Hierzu gehört auch die Kultivierung positiven Verhaltens (die „Plus“ Themen aus einer Plus-Delta-Retrospektive, [Derby und Larsen 2006:116] ).

Der nächste Sprint

  • Das übergeordnete Sprintziel (Sprint Goal) und die geplanten Verbesserungsmaßnahmen sowie die Verstärkung positiver Effekte werden dargestellt.
  • Konkret geplante Features sollten nur dargestellt werden, soweit diese bei der teamübergreifenden Kommunikation für andere Teams wesentlich sind.

Änderungen des Product Backlog

  • Größere Änderungen des Product Backlog werden kurz erläutert und begründet.

Architektur- und Fachentscheidungen

  • Falls Architektur- oder Fachentscheidungen [Schneider 2011] getroffen wurden, sind diese im Bericht referenziert.

Das steht nicht drin
Auf einen Ampelstatus kann normalerweise verzichtet werden. Ein solcher Status ist eine starke Reduktion und häufig fehlen eindeutige Kriterien zur Begründung der Statuswerte. Gerade bei einem Ampelstatus lässt sich oft beobachten, dass der Status während der Projektlaufzeit eher als unkritisch (grün) eingestuft wird und kurz vor dem Liefertermin kritisch wird (also gelb oder gar rot). Ein solcher Status hat keine Aussagekraft, so dass auf dieser Grundlage ein Projekt auch nicht gesteuert werden kann. Die Fakten des Sprintberichtes (Arbeitsfortschritt, Arbeitsgeschwindigkeit, Zeitverbrauch und ggf. Budgetverbrauch) besitzen genug Aussagekraft für die kontinuierliche Projektbewertung und die Ableitung von Entscheidungen.

Weitgehende und detaillierte Zukunftsplanungen gehören nicht in den Sprintbericht.

Manchmal kann es in der Sprint Retrospektive zu persönlichen Konflikten kommen. Diese Form des Konfliktes wird im Sprintbericht nicht behandelt. Trotz aller angestrebten Transparenz muss die Retrospektive in diesen Fällen ein geschützter Raum sein, der dem Team erlaubt, zunächst für sich Klarheit zu finden.

Zusammenfassung

Inhalte des Sprintberichts

Referenzen
[Derby und Larsen 2006] Esther Derby und Diana Larsen, Agile Retrospectives: Making Good Teams Great, Pragmatic Programmers, 2006

[Schneider 2011] Ulf Schneider, Architektur und Fachentscheidungen, 2011, siehe: https://allesagil.net/2011/07/27/architektur-und-fachentscheidungen/

Standard
Berichtswesen, Projektmanagement, Scrum

Ein Sprint ist kein Meilenstein

Im Scrum liefern wir Funktionalität in einem durch Sprints vorgegebenen Rhythmus aus. Die Sprints sollten eine gleichbleibende Dauer von z.B. zwei Wochen haben und zu jedem Sprintende sollten überprüfbare Ergebnisse vorliegen, im Falle der Softwareentwicklung am besten in Form von lauffähigem Programmcode.

Normalerweise stehen nicht nur die auszulieferneden Features für den aktuellen und den kommenden Sprint fest, sondern oft hat das Auslieferungsteam gemeinsam mit dem Product Owner eine Auslieferungsreihenfolge für die nächsten ungefähr fünf Sprints vorbereitet. Diese Planung wird natürlich unter der Maßgabe vorgenommen, dass wenn sich zum Abschluss eines Sprints neue Erkenntnisse ergeben oder im laufenden Sprint neue Features in den Product Backlog aufgenommen werden, eine Neuplanung der Auslieferungsreihenfolge möglich ist.

Bei der Einführung von Scrum in klassisch wasserfallgeprägten Organisationen kann die vorausschauende Ordnung der Auslieferungsreihenfolge leicht zu einem Missverständnis führen: Die Interpretation der Sprints als Meilensteine mit definiert erwarteten Zwischenergebnissen für das Projekt. Diese Sichtweise verzerrt die Bedeutung von Sprints und erschwert die Handhabung der Sprints sowohl für die Teilnehmer des Scrum Projektes als auch für das Management. Folgende Problempunkte sind zu benennen:

  • Berichtswesen: Meilensteine und ihre Erreichung werden an das Management berichtet. Im Falle der Sprintmeilensteine führt das also zu einer Kette vieler Meilensteine. Sind die nächsten fünf Sprints geplant, aber der weitere Verlauf des Projektes noch nicht, wird das Management nach weiteren Meilensteinen bis zum geplanten Abschluss des Projektes fragen. Das wiederum führt zu einer Durchplanung des Projektes mit Meilensteinen in Sprintabständen. Abgesehen von der Tatsache, dass wohl kein Projekt so viele Meilensteine hat, muss der Berichtende bei jedem Sprintergebnis, das nicht vollständig erreicht wurde, einen nicht erreichten Meilenstein berichten. Man gerät so ganz unnötig in Erklärungsdruck, denn ein nicht erreichtes Sprintergebnis ist nicht gleichzusetzen mit einem nicht erreichten Meilenstein.
  • Beobachtung und Anpassung: Das wesentliche Problem der Sprintmeilensteine liegt in der Aushebelung der Selbststeuerungskräfte, die wir durch Beobachtung und Anpassung für uns einsetzen möchten. Es ist gerade die kontinuierlich mögliche und nötige Neuplanung der Auslieferungsreihenfolge, die uns im Scrum erlaubt, Erkenntnisse aus unserem Tun zu gewinnen und diese Erkenntnisse für ein optimales Auslieferungsvorgehen einzusetzen. Eine Durchplanung des Projektes mit Sprintmeilensteinen vernachlässigt die Auslieferungsgeschwindigkeit des Teams, verneint Selbstorganisationskräfte selbst dann, wenn die Sprintplanung gemeinsam mit dem Auslieferungsteam gemacht wurde und unterstützt die eigentlich zu verhindernde Sichtweise des Scrumfall.
  • Scrumfall: Im Scrumfall werden die Phasen des Wasserfallmodells, also Anforderungserhebung, Analyse, Design, Implementierung, Test und Auslieferung auf aufeinanderfolgende Sprints verteilt. Der Scrumfall ist ein Anti-Pattern und es ist klar, dass auf diese Weise in den ersten Sprints lediglich Papier- und Konzeptarbeit geleistet wird und – genau wie beim Wasserfallmodell – erst zu einem späten Zeitpunkt im Projekt Funktionalität geliefert wird. Im Scrum ist unser Ziel, sämtliche Phasen des Wasserfallmodells in jedem Sprint zu durchlaufen und so in jedem Sprint konkrete, wertschöpfende Ergebnisse liefern und überprüfen zu können.

Ein Sprint ist kein Meilenstein, sondern ein Sensor.

Der Sprint erlaubt uns, in einem festgelegten Rhythmus überschaubare und damit beherrschbare Ergebnisse auszuliefern. Am Ende jedes Sprints können wir sowohl die erreichten Ergebnisse als auch unseren Weg dahin überprüfen, aus dem vergangenen Sprint lernen und die gewonnenen Erkenntnisse bewusst für die nächsten Sprints einsetzen.

Genauso sollte ein Sprint auch an das Management berichtet werden: als ein Sensor der uns mitteilt, was ist. Ein Sensor, an dem wir ablesen können, welche Aufgaben erledigt wurden und welche Hindernisse – z.B. in der umgebenden Organisation – das Team an einer Top-Leistung hindern.

In meiner Praxis hat sich dafür das Burndown Diagram (Fortschrittsübersicht) in Verbindung mit einer kurzen Auflistung der ausgelieferten Funktionen und der Hindernisse bewährt.

Beispiel einer Fortschrittsübersicht

Beispiel einer Fortschrittsübersicht

Nach einigen Sprints ist die Interpretation des Diagramms für das Management intuitiv klar. In vorliegendem Beispiel wird die Arbeitsmenge, die in einem laufenden Sprint neu entstanden ist, als grauer Balken dargestellt. Die tatsächliche Arbeitsmenge und -geschwindigkeit wird blau oder grün ausgefüllt dargestellt, die geplante Arbeitsmenge und -geschwindigkeit wird blau oder grün umrandet dargestellt. In dem vorliegendem Fortschrittsbericht wird ausserdem sichtbar, dass das Team noch keinen optimalen Auslieferungsrhythmus gefunden hat. Der Bericht kann damit auch durch das Team verwendet werden, um den eigenen Auslieferungsprozess zu analysieren und zu verbessern.

Standard