Agiles Projektmanagement Sprint

Sprints sind ein Merkmal der beliebtesten agilen Ansätze für Projektmanagement und Produktlieferung. Sie werden hauptsächlich verwendet, um große Arbeitsabschnitte in kleinere, besser handhabbare Teile zu untergliedern, die von agilen Teams geliefert werden können.

Sprints wurden erstmals als Teil von Scrum beschrieben – einem der ersten und definitiv dem beliebtesten agilen Ansatz, der heute verwendet wird. Sie werden auch von Nexus und LeSS (Ansätze für die Skalierung von Scrum) und der neuesten Version von AgilePM verwendet. Andere agile Ansätze wie SAFe, DAD und XP verwenden ein nahezu identisches Konzept, nutzen aber den Begriff Iteration anstelle von Sprint.

In den folgenden Absätzen werde ich zunächst beschreiben, was Sprints sind und wie sie strukturiert sind, bevor ich zu pragmatischen Ratschlägen und Anleitungen übergehe, um sicherzustellen, dass sie wie vorgesehen funktionieren.

Ein Sprint ist eine kurze, festgelegte Zeitspanne, in der ein Team daran arbeitet, eine Reihe priorisierter Aufgaben zu erledigen. Sprints sollen es Lieferteams ermöglichen, auf vorhersagbare, schrittweise Art bedeutsame, schrittweise Fortschritte in Richtung längerfristiger Ziele zu erzielen.

Die Begrenzung von Sprints auf einen Zeitrahmen von 2-4 Wochen und die Sicherstellung, dass jeder Sprint ein klares Ziel hat, fördert die häufige Lieferung wertvoller, strategisch ausgerichteter Ergebnisse.

Der Rhythmus und die Disziplin von Sprints helfen Teams dabei, Schwung aufzubauen, Komplexität schrittweise zu bewältigen und sich schnell an Veränderungen anzupassen. Wichtig ist, dass dies kontinuierliche Verbesserung ermöglicht, indem häufige Gelegenheiten für Feedback, Lernen und Anpassung geboten werden.

Der Sprint, wie er von Scrum definiert wird, hat eine spezifische Struktur. In dieser Form ist er am besten für die Verwendung in einem nicht-projektbezogenen Kontext geeignet, da Scrum die Rolle eines Project Managers nicht anerkennt. AgilePM schlägt einige praktische und pragmatische Verbesserungen zu dieser Standardstruktur vor, die im Kontext eines Projekts Mehrwert bieten, ohne Scrums ursprüngliche Absicht zu widersprechen oder davon abzulenken.

Das folgende Diagramm zeigt die Struktur eines Sprints, wie sie im Scrum Guide 2020 beschrieben ist – dem maßgeblichen Leitfaden zu Scrum, verfasst von den Mitbegründern von Scrum Jeff Sutherland und Ken Schwaber.

Es beschreibt vier wichtige Events, die die meisten Menschen als Teammeetings erkennen würden, die während eines Sprints stattfinden. Das Diagramm zeigt einen 2-Wochen-Sprint, aber bei Sprints mit unterschiedlicher Dauer sollten die meisten Events entsprechend skaliert werden.

1. Jeder Sprint beginnt mit einem Sprint Planning Event, bei dem:

• Ein Sprint Goal vereinbart wird
  • Dies ist ein kollaborativer Prozess, an dem der Product Owner und die Entwickler im Scrum Team beteiligt sind.
  • Der Product Owner ist dafür verantwortlich sicherzustellen, dass die geplante Arbeit optimalen Nutzen für die Stakeholder liefert.
  • Das Scrum Team muss ein Ziel verhandeln, zu dem es sich verpflichten kann.
• Was im Sprint zu tun ist, wird verhandelt
  • Dies ist ebenfalls ein kollaborativer Prozess, an dem der Product Owner und die Entwickler beteiligt sind.
  • Elemente, die zur Erfüllung des Sprint Goals und zur Erreichung eines Product Goals benötigt werden, werden aus dem Product Backlog genommen. Beachten Sie, dass ein Product Goal möglicherweise mehrere Sprints benötigt, um erreicht zu werden.
  • Es kann einen gewissen Grad an Iteration zwischen der Vereinbarung eines präzisen Sprint Goals und der Arbeit geben, die zu dessen Erreichung erforderlich ist.
• Wie die vereinbarte Arbeit erledigt wird
  • Dies ist ein kollaborativer Prozess, bei dem die Entwickler die ausgewählten Product Backlog-Elemente in umsetzbare Arbeitsaufgaben aufteilen und vereinbaren, wie sie im Sprint Backlog geordnet werden.

Das Sprint Backlog umfasst alle drei oben genannten Elemente der zu erledigenden Arbeit. Am Ende des Sprint Planning ist das Sprint Backlog, das "der Plan" für den Sprint ist und den Entwicklern gehört, vereinbart.

2. Das Daily Scrum

• Dies ist ein täglich 15 Minuten (maximal) dauerndes Meeting der Entwickler
  • Es findet normalerweise jeden Arbeitstag zur gleichen Zeit statt.
  • Es skaliert nicht in Bezug auf die Länge des Sprints.
  • Sein Zweck ist es, den Entwicklern zu ermöglichen, ihre Pläne anzupassen, um den Fokus auf das Sprint Goal und ihr Engagement dafür aufrechtzuerhalten.

Während der Sprint voranschreitet, können Product Increments geliefert werden, wobei jedes solche Increment die vorhergehenden umfasst. Die Lieferung von Product Increments ist das Maß für den bedeutungsvollen inkrementellen Fortschritt, der zuvor erwähnt wurde.

3. Sprint Review

• Dies ist das Forum, das das Scrum Team nutzt, um den Stakeholdern den Wert zu demonstrieren, den es am Ende des Sprints geliefert hat.
• Das finale Product Increment wird formal im Kontext seines Beitrags zum Product Goal überprüft und mögliche Verbesserungen werden diskutiert
• Solche Verbesserungen werden dem Product Backlog hinzugefügt, vorausgesetzt sie sind nicht bereits notiert.

4. Sprint Retrospective

• Der Zweck dieses Events ist es, dass das Scrum Team über die Effektivität ihrer Arbeitsweise reflektiert
• Alle Verbesserungsideen werden diskutiert und priorisiert. Eine oder zwei dieser Ideen werden als Experimente für den nächsten Sprint übernommen, wobei die Auswirkungen bei der anschließenden Retrospective evaluiert werden

Die folgenden Verbesserungen für den Scrum Sprint werden von AgilePM vorgeschlagen, wo sie einen Mehrwert im Kontext des Projektmanagements bieten. Sie werden höchstwahrscheinlich einen Mehrwert in Multi-Team-Projekten schaffen, wo Pläne zwischen Teams in einen kohärenten Gesamtprojektplan synchronisiert werden müssen.

5. Die erste der Verbesserungen besteht darin, das Daily Scrum, das 2 Tage vor Ende des Sprints stattfindet, durch ein spezielles Consolidation Scrum zu ersetzen.

• Mit einer Dauer von 30 Minuten ist dieses Event etwas länger als das Daily Scrum.
• Zusätzlich zum Zweck des Events, das es ersetzt, wird das Scrum Team gebeten vorherzusagen, welche der ausstehenden Sprint-Arbeiten abgeschlossen werden und was höchstwahrscheinlich unvollendet bleiben wird.

6. Die zweite Verbesserung ist die Einführung des Project Planning Events.

• An diesem Event nehmen die Projektleitungsrollen Business Visionary, Solution Architect und Project Manager teil, die jeweils spezifische Verantwortlichkeiten in der Projektleitung in AgilePM haben.

Hinweis: Aus allgemeiner Projektmanagement-Sicht sind die Rollenbezeichnungen unwichtig. An dem Event sollten der Projektmanager und alle anderen teilnehmen, die für die Gestaltung des Projektverlaufs Sprint für Sprint verantwortlich sind.

• Die sehr kurzfristigen Vorhersagen aus dem Consolidation Scrum dienen als Eingabe für das Event und ermöglichen sinnvolle Planungsinputs für alle Teams für den nächsten Sprint
• Das Event bietet auch die Gelegenheit zur Planung über einen Horizont hinaus, der über den unmittelbar bevorstehenden Sprint hinausgeht, und für alle Projektaktivitäten, die von Projektteammitgliedern durchgeführt werden sollen, die möglicherweise keine Mitglieder eines Scrum Teams sind.

Ich arbeite seit 1997 mit agilen Ansätzen für Projektmanagement und -umsetzung. Ich weiß, wie gut sie funktionieren können und ebenso gut, wie schlecht die Leistung sein kann, wenn die Dinge nicht so laufen, wie sie sollten.

Wenn Sie Agilität im Projektmanagement einsetzen möchten, ist mein bester Rat, Ihre Sprints entsprechend den Scrum-Richtlinien durchzuführen. Das bedeutet, wenn Sie Projektmanager sind, müssen Sie etwas Abstand zur Planung und Ausführung von Sprints halten. Sie müssen nah genug dran sein, um sicherzustellen, dass sie wie vorgesehen funktionieren, während Sie den kraftvollsten Aspekten der Agilität erlauben, ihre Umsetzung zu beschleunigen.

Hier sind 6 'Top-Tipps' für die erfolgreiche Nutzung von Sprints

1. Versuchen Sie, Scrum in Ruhe zu lassen.

• Es ist bewährt, getestet und effektiv, wenn es ordnungsgemäß entsprechend den Scrum Guide-Richtlinien angewendet wird. Allerdings ist es wesentlich, zu verstehen, was es zum Funktionieren bringt, anstatt es nur prozedural zu befolgen, um das Beste daraus herauszuholen.

2. Verwenden Sie Sprints mit fester Länge in einem regelmäßigen Rhythmus

• Theoretisch können Sie die Länge jedes Sprints in einer Sequenz variieren, und gelegentlich macht es Sinn, ab und zu einen Sprint mit unregelmäßiger Länge zu haben. Zum Beispiel kann ein gelegentlicher Sprint länger oder kürzer als üblich sein, um sich an saisonale Feiertage anzupassen oder ein Lieferdatum zu erreichen, das andernfalls mitten in einen Sprint fallen würde.
• Die Standardeinstellung auf eine feste Sprint-Länge macht jedoch die Planung der Stakeholder-Einbindung und die Verfolgung des Fortschritts einfacher.

3. Verschieben Sie NIEMALS das Enddatum eines Sprints

• Einer der Hauptvorteile der Verwendung von Sprints ist die Vorhersagbarkeit der Lieferung, die sie bietet. Pünktliche Lieferung eines wertvollen Produkts kann praktisch garantiert werden durch:
  • Respektierung des Enddatums des Sprints, und
  • Priorisierung der Arbeit, um die wertvollsten und/oder riskantesten Aspekte vor weniger wertvollen und/oder unkomplizierteren Aspekten zu behandeln.

4. Lassen Sie keine Events aus.

• Jedes Event in einem Sprint hat einen Zweck, der auf die empirischen Grundlagen der Agilität ausgerichtet ist. Konkret:
  • Transparenz dessen, was getan wird und wie
  • Inspektion des sich entwickelnden Produkts und der Arbeitsweisen
  • Anpassung dieser, um das Produkt zunehmend wertvoller zu machen und die Effizienz und Effektivität der Arbeitspraktiken zu verbessern

5. Versuchen Sie, das Konzept der Team-Ermächtigung zu 'leben'.

• Verstehen und übernehmen Sie die Werte, die der agilen Arbeitsweise zugrunde liegen, und ermutigen Sie jeden, der mit dem Projekt verbunden ist, dies zu tun. Scrum definiert diese Werte als Commitment, Fokus, Offenheit, Respekt und Mut. Zitat aus dem Scrum Guide 2020:

"Wenn diese Werte vom Scrum Team und den Menschen, mit denen sie arbeiten, verkörpert werden, erwachen die empirischen Scrum-Säulen Transparenz, Inspektion und Anpassung zum Leben und bauen Vertrauen auf."

Bedenken Sie, dass Sie nicht einem Scrum-Ansatz folgen müssen, um seine Werte zu übernehmen. Sie zu übernehmen wird in jedem teambasierten Vorhaben Mehrwert schaffen.

• Diktieren Sie nicht, führen Sie kollaborativ.
  • Team-Eigenverantwortung und -Commitment sind in einer Umgebung, in der eine einzelne Person, wie ein Projektmanager, diktiert, was getan werden sollte und wann, erheblich vermindert
  • Ein kollaborativer Führungsansatz, der die oben beschriebenen Scrum-Werte übernimmt, wird zu verbesserter Qualität und Produktivität führen.
• Beeinflussen Sie Pläne (sowohl für die Lösung als auch für den Lieferplan) über die Product Owner. Dies erfordert die Anerkennung durch den Product Owner, dass Projektleitungsrollen wichtige Stakeholder sind.

Und wenn Ihre Teams nicht optimal aufgestellt sind, um agil zu arbeiten…

6. Coachen Sie sie in diese Richtung

• Die agile Arbeitsweise stützt sich stark auf die Idee, dass die Menschen, die die Arbeit machen, am besten in der Lage sind, detaillierte Entscheidungen darüber zu treffen, was getan werden muss und wie. Kombiniert mit einer klaren, detaillierten Definition dessen, was benötigt wird und warum, von einem Product Owner, der kollaborativ als Teil des Teams arbeitet, funktioniert das sehr gut. Ich habe persönlich bedeutende Produktivitätssteigerungen erlebt, die nur der Umstellung von einem zentralisierten 'Befehls- und Kontroll'-Ansatz zu ermächtigten Teams zugeschrieben werden können.
• Ermächtigung muss jedoch als zweiseitige Straße erkannt werden, wobei Führungskräfte bereit sein müssen, ihre Teams zu ermächtigen, und Teams in der Lage sein müssen, diese Ermächtigung zu übernehmen. In Situationen ohne Kompetenz und Commitment von Teammitgliedern habe ich erlebt, wie die Produktivität drastisch gesunken ist.
• Die Theorie der situativen Führung, die Paul Hersey und Ken Blanchard in den 1970er Jahren entwickelt haben, beschreibt, wie eine Führungskraft, vielleicht in unserem Kontext ein Projektmanager, zu einer optimalen Führungskraft/Team-Dynamik für Agilität übergehen kann.

Sprints sind ein Eckpfeiler vieler agiler Ansätze und bieten Struktur, Fokus und Rhythmus für die Wertschöpfung. Obwohl ihre Wurzeln in Scrum liegen, wurde das Konzept erfolgreich von verschiedenen Frameworks und skalierten Modellen adaptiert, oft unter dem übergeordneten Begriff "Iteration." Unabhängig von der Terminologie bleiben die Prinzipien konsistent: Timeboxing der Arbeit, häufige Inspektion und Anpassung sowie die Befähigung von Teams zur Selbstorganisation um klare Ziele herum.

Wenn sie durchdacht eingesetzt werden, können Sprints die Projektlieferung dramatisch verbessern — aber nur, wenn sie respektiert werden. Sprints als mehr als nur einen Zeitplan zu behandeln und die Disziplin, Werte und den kollaborativen Geist zu leben, die ihnen zugrunde liegen, ist das, was ihr Potenzial freisetzt.

Für Projektmanager, die in agilen Umgebungen arbeiten, besteht die Herausforderung darin, zu unterstützen, ohne zu kontrollieren — Raum für befähigte Teams zu schaffen und gleichzeitig Ausrichtung und Fokus sicherzustellen. Gut gemacht führt diese Balance nicht nur zu erfolgreichen Sprints, sondern zu durchgängig leistungsstarken Teams und dauerhaftem Projekterfolg.