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
Agil, Architektur, Kommunikation, Projektmanagement, Softwareentwicklung

Architektur- und Fachentscheidungen

Täglich treffen wir in unseren Projekten Entscheidungen, die Einfluß auf die Aufgabenangemessenheit des Produktes haben, das wir gerade erstellen. Selbst kleine Entscheidungen, wie die Benennung oder Positionierung einer Schaltfläche in einem Software-Dialogsystem, können einen relativ großen Einfluss auf die Alltagstauglichkeit des Systems haben. Bei der Benennung einer Schaltfläche kommt uns zugute, dass wir die einmal getroffene Entscheidung leicht revidieren und verbessern können. Andere Entscheidungen, wie z.B. die Entscheidung zur Verwendung eines Rich-Clients im Gegensatz zum Web-Browser, lassen sich nicht so einfach zurücknehmen. Im Gegenteil, häufig sind Entscheidungen, die mit einem strategischen Betrachtungshorizont getroffen werden, schwierig zurückzunehmen und haben eine längere Lebensdauer als das Projekt, in dem die Entscheidung getroffen wurde. Dabei ist unerheblich, ob die Entscheidungen in die Fach- oder die Technikdomäne des Projektes fallen. Nachfolgend mache ich Vorschläge, unter welchen Prämissen strategische Entscheidungen in einem Projekt getroffen werden und wie sie dokumentiert und kommuniziert werden können. Dabei gehe ich sowohl auf technische als auch auf fachliche Fragestellungen ein.

Den teamorientierten Kommunikationsprozess auf dem Weg zur Entscheidung und die Verantwortlichkeit für die getroffene Entscheidung behandle ich hier nicht – das ist ein separates Thema.

Architekturentscheidungen

Technische Entscheidungen, die mit strategischem Betrachtungshorizont getroffen werden, bezeichnen wir als Architekturentscheidungen. Für Softwaresysteme werden diese Entscheidungen unter den folgenden Prämissen getroffen:

  • Vertretung der Interessen aller Stakeholder am System über den gesamten Lebenszyklus.
  • Minimierung der Gesamtkosten für das System über den gesamten Lebenszyklus.

Architekturentscheidungen sollen die Abhängigkeiten der Systemkomponenten zueinander minimieren (vgl. Quasar Architekturstil). Es ist die Architektur, die es erlaubt, ein Softwaresystem an veränderliche Anforderungen anzupassen. Während Architekturentscheidungen einen Lösungsraum aufspannen, strukturieren Designentscheidungen, die auf taktischer und operativer Ebene getroffen werden, diesen Lösungsraum. Manche Designentscheidungen werden ausschließlich aus dem Kontext einer zuvor getroffenen Architekturentscheidung abgeleitet. Genau deshalb sind Architekturentscheidungen schwierig zu revidieren, weil ihre Änderung zu einer Änderungskaskade bei den abhängigen Designentscheidungen führt. Der Übergang zwischen Architektur- und Designentscheidung kann fließend sein, klar ist jedoch, dass viel weniger Architekturentscheidungen als Designentscheidungen getroffen werden. Während man in einem Projekt möglicherweise mit 20 oder weniger Architekturentscheidungen auskommt, können durchaus 100 und mehr Designentscheidungen nötig sein.

Die folgende Grafik visualisiert die fünf Disziplinen Strategie, Anforderungen, Architektur, Design und Implementierung als Aufgabenkomplexe, die bei jedem Softwareprojekt zu adressieren sind.

Architektur als Brücke zwischen Anforderungen und Umsetzung

Es gibt eine natürliche Reihenfolge der Disziplinen von links nach rechts sowie Übergänge von einer Disziplin zur nächsten. Die Strategie und daraus abgeleitete Anforderungen gehören zur Problemdomäne eines Vorhabens. Alles dreht sich um die Fragestellung: „Welches Problem – was – soll gelöst werden?“ Die Architektur wiederum ist Teil der Lösungsdomäne eines Projektes. In der Lösungsdomäne sucht man nach Antworten auf die Frage: „Wie kann die Lösung zu einem Problem erreicht werden?“ (vgl. dazu auch „Scrum und Architektur: Konzeptionelle Integrität im Scrum-Prozess“). Die Architektur übernimmt dabei eine Brückenfunktion zwischen der Problem- und der Lösungsdomäne.

In agilen Projekten ist ein Beobachtungs- und Anpassungsverhalten, also ein Lernverhalten, über sämtliche Disziplinen vorgesehen. In klassischen Softwareentwicklungsprojekten versucht man diesen Erkenntnisprozess so lange wie möglich zu negieren und über Change Requests teuer zu machen.

Zum heutigen Stand des Wissens gehört die Verschriftlichung des Diskurses, der zu einer Architekturentscheidung geführt hat. Dabei wird die Problemstellung, die getroffenen Annahmen, die berücksichtigten Randbedingungen und die betrachteten Alternativen sowie die Entscheidungsbegründung nachvollziehbar dokumentiert. Die Schriftform hat verschiedene Gründe:

  • Die Entscheidung wird bewusster getroffen.
  • Es wird größere Klarheit in der Formulierung gefordert und die Nachvollziehbarkeit der Überlegungen wird unterstützt.
  • Die Entscheidung wird erinnerbar und leichter kommunizierbar.
  • Neu hinzukommende Projektmitglieder haben eine Chance, getroffene Entscheidungen nachzuvollziehen.

Stefan Zörner schlägt vor, für die Dokumentation eine festgelegte Abfolge von Fragestellungen zu durchlaufen und zu beantworten. Dieses Vorgehen halte ich für ausgesprochen sinnvoll und wende es in allen meinen Projekten an. Im einzelnen sieht die Abfolge der Fragestellungen so aus:

Fragestellungen zur Dokumentation einer Architekturentscheidung

Den Ergebnistext kann man z.B. in einem Wiki festhalten. Aufwändig gestaltete Word-Formulare benötigt man dazu nicht. In meinen Projekten wird oft memYAK als web-basierte Kommunikationsplattform eingesetzt, dort steht ein eigenes Web-Formular zur Erfassung von Architekturentscheidungen zur Verfügung.

Die erfassten Entscheidungen sind in einer Liste zu führen, die für die Projektmitglieder jederzeit zugreifbar ist. Es ist darauf zu achten, die Dokumentation aktuell zu halten. Das gilt für überarbeitete und revidierte Entscheidungen ebenso, wie für neu getroffene Entscheidungen.

memYAK Formular zur Erfassung einer Architekturentscheidung

memYAK Beispiel einer Architekturentscheidung

memYAK Liste mit Architekturentscheidungen

Dieses Verfahren der Dokumentation von Architekturentscheidungen kann bei einem wasserfall-orientierten Vorgehen ebenso eingesetzt werden, wie bei agilen Vorhaben. Es kann nicht nur, es sollte sogar!

Fachentscheidungen

Fachentscheidungen liefern Antworten auf die Frage: „Welches Problem soll gelöst werden?“ Sie sind damit im Problemraum eines Vorhabens angesiedelt und sind komplementär zu den technischen Fragestellungen, die im Lösungsraum des Projektes verortet sind.

Wie wird mit fachlichen Entscheidungen umgegangen, die unter einem strategischen Blickwinkel getroffen werden? In klassischen Projekten manifestieren sie sich in der Projektvision und in den Fachkonzepten. Bei agilem Vorgehen stecken sie in der Produktvision und in den User Stories.

Während es üblich ist, die strategischen technischen Entscheidungen als Architekturentscheidungen zu dokumentieren, habe ich eine analoge Herangehensweise für strategische fachliche Entscheidungen bisher nicht beobachtet. Der zur Entscheidung führende Diskurs wird häufig nicht dokumentiert. Dabei lassen sich dieselben Gründe, die für eine Dokumentation von Architekturentscheidungen sprechen, auch für strategische Fachentscheidungen heranziehen. Zeitlich werden Fachentscheidungen sogar vor den Architekturentscheidungen getroffen und es besteht durchaus eine gegenseitige Beeinflussung von Fach- und Architekturentscheidungen. Ich rege daher an, strategische fachliche Entscheidungen ebenso zu behandeln, wie Architekturentscheidungen. In leicht angepasster Form können wir die fünf Fragenkomplexe wiederverwenden, die uns bei Architekturentscheidungen bereits gute Dienste erweisen. Während Architekturentscheidungen unter den Prämissen der Interessenvertretung und Kosteneffizienz getroffen werden, gelten für Fachentscheidungen die Prämissen des Kosten-Nutzen-Verhältnisses und der Wertmaximierung. Strategische Fachentscheidungen können in agilen Projekten Gültigkeit für mehrere User Stories haben und für die Ableitung weiterer Entscheidungen bei der Umsetzung der User Stories eine Orientierungshilfe bieten. Es ist auch denkbar, ausgewählte fachliche Entscheidungen aus der Produktvision heraus zu referenzieren.

Fragestellungen zur Dokumentation einer Fachentscheidung

Auch für Fachentscheidungen können Formulare und Listen verwendet werden, die weiter oben für Architekturentscheidungen bereits beispielhaft gezeigt wurden. Die Verwendung ist sowohl in Wasserfall-Projekten als auch in agilen Projekten möglich und kommt der Qualität und Kommunizierbarkeit fachlicher Entscheidungen meiner Meinung nach zugute.

Standard
Agil, Projektmanagement

Wie erfolgreich sind agile Projekte?

Am 5. April war ich im Rahmen der Saarbrücker Reihe des Frankfurter PMI Chapters in Saarbrücken, um mit den anwesenden Projektleitern über die Grundlagen von Scrum zu sprechen. Frank Heil hatte den Termin gemeinsam mit Michael Royar organisiert und wir trafen uns in den Räumen der eXirius GmbH.

Der inhaltliche Schwerpunkt des Abends lag darauf, definierte und empirische Prozesse zu unterscheiden und so die Problemklasse zu erkennen, für die Scrum funktioniert. Scrum ist ein Managementframework für empirische Prozesse. Damit sind Problemstellungen gemeint, für die nicht a-priori ein Prozess definiert werden kann, der dann automatisch zu einem erfolgreichen Ergebnis führt. Vielmehr entspricht das empirische Vorgehen einem Erkenntnisprozess, der kontinuierliche Beobachtung, Lernen und Anpassung erfordert. Definierte Prozesse finden wir dagegen in Umfeldern, in denen es zum Beispiel um Fertigungsautomatisierung geht oder in denen sehr hohe Sicherheitsanforderungen eingehalten werden müssen.

Zur Verdeutlichung und mit allem Respekt für die betroffenen Menschen: Der Betrieb des Atomkraftwerks in Fukushima war vor dem 11. März ein definierter Prozess. Der Umgang mit der Situation nach dem 11. März entspricht einem empirischen Prozess. Um der aus diesem Beispiel vielleicht erwachsenden Assoziation „Empirischer Prozess = Krisenbekämpfung“ entgegenzuwirken: Jeder Innovationsprozess, zu denen ich auch Softwareentwicklungsvorhaben zähle, ist ein empirischer Prozess.

Im Scrum werden die Werte des Agilen Manifests bejaht. Aus diesem Grund wird Scrum auch als agiles Verfahren bezeichnet. Die Anerkennung empirischer Problemklassen ist einer der Werte des Agilen Manifests („Responding to change over following a plan“). In Abgrenzung dazu bezeichnen wir ein wasserfallorientiertes Vorgehen, bei dem gegen eine vorab erstellte Anforderungsspezifikation die aufeinanderfolgenden Phasen Analyse, Entwurf, Implementierung, Test und Auslieferung durchlaufen werden, oft als klassisches Verfahren. Das zugrundeliegende Paradigma des Wasserfallmodells entspricht dem eines definierten Prozesses mit a-priori gegebenem Ablauf.

Herr Royar stellte in der Diskussion die Frage, wie erfolgreich agile Verfahren im Vergleich zu klassischen Verfahren seien. Eine gute Frage, denn ausser meinen persönlichen, sehr positiven Erfahrungen mit agilen Techniken in IT-Projekten, durch die ich von agilen Verfahren überzeugt bin, hatte ich keine Vergleichswerte zur Beantwortung dieser Frage.

Im Anschluss an unser Treffen habe ich nach Material gesucht, das eine Antwort liefert. Zwei Quellen, die den Erfolg agiler Methoden in IT-Projekten analysieren, fand ich hilfreich.

In einer Studie zum Einfluss klassischer und agiler Techniken auf den Erfolg von IT-Projekten von 2009 haben die umtriebigen Mitarbeiter der oose in Kooperation mit dem PMI (Project Management Institute) und der GPM (Deutsche Gesellschaft für Projektmanagement) 212 Personen befragt. Danach gibt es Techniken, die unabhängig von klassischem oder agilem Vorgehen den Projekterfolg wahrscheinlicher machen:

  • Enger und guter Kundenkontakt, mindestens einmal pro Woche, besser täglich.
  • Einbeziehung der Entwickler in die Planung (besonders wichtig für klassisches Vorgehen).
  • Iteratives Vorgehen mit Einhaltung der Timeboxes und eine Timebox-Dauer von maximal 4 Wochen.

Die folgenden Grafiken verdeutlichen diese Aussagen und wurden der oose PM-Studie entnommen.

Zusammenhang zwischen Kundenkontakt und Projekterfolg

Zusammenhang zwischen Kundenkontakt und Projekterfolg (Quelle: oose PM-Studie)

Zusammenhang zwischen iterativem Vorgehen und Projekterfolg

Zusammenhang zwischen iterativem Vorgehen und Projekterfolg (Quelle: oose PM-Studie)

Es zeigt sich aber auch, dass agile Projekte insgesamt häufiger erfolgreich sind (ca. 70%) als klassische Projekte (ca. 40%). Das gilt in Bezug auf die Qualität, Termintreue, Budgettreue und Zufriedenheit der Akteure. Dagegen wird das Ziel „Funktionsumfang nach ursprünglicher Spezifikation“ sehr häufig von Projekten erreicht, die als Misserfolg eingestuft werden.

Agile Projekte sind erfolgreicher als klassische Projekte

Agile Projekte sind erfolgreicher als klassische Projekte (Quelle: oose PM-Studie)

Neben der oose Studie findet man bei Scott Ambler die Ergebnisse einer Vielzahl von Umfragen, unter anderem eine Reihe zu IT Project Success Rates. Ein erläuternder Text zu einer solchen Studie erschien im April 2009 in Dr. Dobb’s Journal.

Auch in dieser Studie, in der 279 Personen befragt wurden, findet man eine generelle Empfehlung, die den Projekterfolg wahrscheinlicher macht:

  • Die Akteure sollten an einem Standort arbeiten, da sie dann seltener scheitern, als verteilt arbeitende Entwicklungsteams.

Nur 4% der Teilnehmer an Scott Amblers Umfrage haben IT-Projekte als erfolgreich eingestuft, bei denen der Termin und das Budget eingehalten und der Funktionsumfang der ursprünglichen Spezifikation geliefert wurde. Das bestätigt meiner Meinung nach die Sichtweise, dass IT-Projekte empirisch, also als Lernprozesse zu begreifen sind. Eine Fokussierung auf die ursprüngliche Spezifikation negiert den Erkenntnisgewinn, den die Teilnehmer jedes IT-Projektes erreichen müssen.

Scott Ambler vergleicht die Wirksamkeit agiler, iterativer, klassischer und ad-hoc Ansätze in Bezug auf die Erreichung einer gewünschten Qualität, Funktion, Budget und Zeit und kommt dabei generell zu besseren Werten für agile und iterative Ansätze. Besonders hervorzuheben ist, dass ein ad-hoc Vorgehen (also ohne jeden Prozess, weder agil noch klassisch) effektiver in Bezug auf die gelieferte Funktionalität und die dabei verursachten Kosten ist, als ein klassisch wasserfallorientiertes Vorgehen!

Wirksamkeit verschiedener Methoden (Quelle: Scott Ambler)

Wirksamkeit verschiedener Methoden nach Scott Ambler (Very Effective 10 points, Effective 5 points, Neutral was worth no points, Ineffective -5 points, and Very Ineffective -10 points)

Ich habe hier nur wenige, mir relevant erscheinende Aussagen aus den Studien entnommen und empfehle, die ursprünglichen Texte selbst zu lesen.

Zum Schluss noch einige Fotos von unserem sehr angeregten Treffen in Saarbrücken, die mir Andreas Steinel geschickt hat.

 

PMI/GPM Treffen in SaarbrückenPMI/GPM Treffen in SaarbrückenPMI/GPM Treffen in SaarbrückenPMI/GPM Treffen in Saarbrücken

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