Warum Scrum nicht optional ist

Scrum vs. PMOs

Die Fortune-500-Unternehmen, die Scrum eingeführt haben, erzielten einen 40-mal höheren Shareholder Value als ihre Mitbewerber.

Was für ein Managementtyp ist Scrum und warum ist er besser als klassisches Projektmanagement? Um das anschaulich zu machen, schauen wir uns Exhibit A an:

Wie wir sehen können, ist im klassischen Projektmanagement der Scope fest definiert, während Kosten und Deadline variieren.

Vergleich: Klassisches vs. modernes Projektmanagement

WASSERFALL

SCRUM

Wenn Sie damit leben können, ist Wasserfall der richtige Ansatz für Ihr Projekt. Dennoch lohnt es sich weiterzulesen, um die Vorteile von Empirismus gegenüber bloßem Glauben zu verstehen. Vorhersagbarkeit im klassischen Projektmanagement bedeutet nicht, dass diese auf reinem Glauben basierenden Prognosen sich als zutreffend erweisen – ganz im Gegenteil: In 99,9 % aller Fälle stellen sich diese orakelartigen Vorhersagen als falsch heraus.

Dafür gibt es verschiedene Gründe. Erstens ist akademisch belegt, dass IBMs Function Point Analysis nicht funktioniert. Zweitens kann das Projekt nicht an veränderte Kundenanforderungen angepasst werden, wenn alle Dimensionen des Projektmanagement-Dreiecks fest sind – Scrum hingegen schon. Drittens, und das folgt aus dem letzten Punkt, ist FPA nicht empirisch, da nicht alle Anforderungen eines Projekts bekannt sein können, bevor es überhaupt begonnen hat.

Wir sind also deutlich besser aufgestellt, wenn wir bei festen Kosten und einem festen Termin bleiben, aber einen variablen Scope wie in Scrum einführen. Darüber hinaus versucht Scrum, die Projektmanagement-Lücke durch Product Vision, Product Goal und Release Planning zu schließen – etwas, das klassische Projekte meist nicht adressieren. Scrum verzichtet auf die Rolle des Projektmanagers, diese Verantwortung wird jedoch vom Scrum-Team gemeinsam und selbstorganisiert übernommen. Dies hat den Vorteil, dass die Verantwortung und das Eigentum am Projektergebnis teilweise auf das Entwicklungsteam übergeht – sie haben also Skin in the Game und sind am Erfolg interessiert.

Nun tauchen wir tiefer in das Scrum-Framework ein.

Agile Werte

Sie haben diese wahrscheinlich schon gehört, aber ich möchte sie etwas erläutern und erklären, wie man diese agilen Werte verstehen sollte.

Menschen über Prozesse

Schaffen Sie ein Umfeld, in dem Menschen zusammenarbeiten und kommunizieren können. Werkzeuge und Prozesse neigen dazu, sich nur langsam an schnell und stark verändernde Anforderungen anzupassen.

Software über Dokumentation

Dokumentation verschlanken. Funktionierende Software ist der beste Indikator für Erfolg.

Kundenzusammenarbeit über Vertragsverhandlung

Nicht nur am Anfang oder Ende des Projekts – reine Vertragsorientierung führt dazu, dass nur vertragliche Anforderungen erfüllt werden, Erwartungen jedoch nicht, was zum Scheitern des Projekts führt.

Reagieren auf Veränderung über das Befolgen eines Plans

Ein geplantes Wasserfallprojekt kann sich nicht an neue oder veränderte Anforderungen anpassen, insbesondere in späteren Phasen, und verpasst so die Möglichkeit, auf Kundenfeedback zu reagieren – mit einem weniger erfolgreichen Produkt als Ergebnis.

12 Agile Prinzipien

(1) Höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung wertvoller Software oder Produktfunktionen zufriedenzustellen.

Um frühzeitig Feedback zu erhalten und Kundenerwartungen zu erfüllen.

(2) Veränderte Anforderungen sind willkommen, selbst spät in der Entwicklung – Veränderung zum Wettbewerbsvorteil des Kunden nutzen.

In klassischen PMO-getriebenen Projekten sind Änderungen unerwünscht, da sie gegen Plan und Zeitplan verstoßen würden.

(3) Funktionierende Software häufig liefern, wöchentlich oder monatlich.

Nicht warten, bis jedes einzelne Feature entwickelt ist, sondern so früh wie möglich liefern – das ermöglicht schnelles Lernen und Produktverbesserung.

(4) Fachexperten und Entwickler müssen während des gesamten Projekts zusammenarbeiten.

In klassischen PMO- und Gantt-Chart-getriebenen Projekten sind Fachexperten nur in der Anforderungsanalyse eingebunden. Agile implementiert kontinuierliche Feedback-Schleifen im Projekt, um schnell lernen und anpassen zu können.

(5) Bauen Sie Projekte rund um motivierte Menschen auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie darauf, dass sie die Arbeit erledigen.

In einem agilen Projekt sind die Menschen der wichtigste Erfolgsfaktor und in der Lage, selbst komplexeste Probleme zu lösen.

(6) Die effizienteste und effektivste Methode zur Informationsvermittlung innerhalb eines Entwicklungsteams ist das direkte Gespräch.

Agile bevorzugt ausdrücklich direkte Kommunikationsformen: persönlich, von Angesicht zu Angesicht, Stimme zu Ohr.

(7) Funktionierende Software ist das primäre Maß für Fortschritt.

In einer agilen Denkweise geht es nicht um ausgefeilte Dokumentation oder einen sehr detaillierten Produktplan. Funktionierende Software befriedigt den Kunden und ist der Maßstab für Erfolg und Fortschritt.

(8) Agile Prozesse fördern nachhaltige Entwicklung. Auftraggeber, Entwickler und Nutzer sollten in der Lage sein, ein dauerhaft konstantes Tempo beizubehalten.

Um Arbeitsspitzen zu vermeiden, setzt Agile auf konstante, iterative Arbeitszyklen mit einem gemeinsamen Ziel – die Sprints.

(9) Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design fördert Agilität.

Agile betrachtet Softwareentwicklung als eine Art Handwerk, statt einfach nur Aufgaben abzuhaken.

(10) Einfachheit und die Kunst, die Menge nicht erledigter Arbeit zu maximieren, sind essenziell.

Viele Produkte enthalten Funktionen, die nach der Entwicklung nicht benötigt oder genutzt werden. In Agile ist es bevorzugt, wenige Funktionen sehr gut umzusetzen, anstatt viele ungenutzte und schwer wartbare Funktionen zu haben.

(11) Die besten Architekturen, Anforderungen und Designs entstehen in selbstorganisierten Teams.

Selbstorganisierte Teams warten nicht darauf, dass jemand – etwa ein Projektmanager – ihnen ihre Arbeit zuweist. Jedes Teammitglied fühlt sich für ein großartiges Produkt verantwortlich und verwaltet daher eigenständig seine Zeitpläne und Aufgaben.

(12) In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Vermeidet Stress durch die Untersuchung der Teaminteraktion und findet Wege, effektiver zu werden.

Scrum-Grundlagen

Scrum hilft Teams und Organisationen dabei, durch adaptive Lösungen für komplexe Probleme Wert zu schaffen.

Verantwortlichkeiten

Entwickler verpflichten sich, in jedem Sprint ein Stück funktionierende Software zu entwickeln.

Verantwortlich für: Product Increment / Increment of Value

Product Owner ist verantwortlich für die Maximierung des Produktwerts und zuständig für die Priorisierung der Arbeit durch die Verwaltung des Product Backlogs.

Verantwortlich für: Produktwert und Priorisierung der Arbeit

Scrum Master ist verantwortlich für die Etablierung von Scrum gemäß dem Scrum Guide. Er hilft allen, Scrum-Theorie und -Praxis im Team und in der Organisation zu verstehen.

Verantwortlich für: Etablierung & Facilitation

Events

Sprint Planning

• Eröffnet den Sprint. Das Team legt die im Sprint zu erledigende Arbeit fest.
• Erstellt einen Plan, wie die Arbeit erledigt wird.
• Das Sprint Goal beschreibt, warum der Sprint wertvoll ist, und kann an Stakeholder kommuniziert werden.

Das Commitment des Teams in einem Sprint ist seit der Überarbeitung des Scrum Guide 2020 das Sprint Goal.

Daily

• 15-minütiges Time-boxed Event für das Scrum-Team.
• Fortschritt in Richtung Sprint Goal überprüfen.
• Sprint Backlog bei Bedarf anpassen.

Retrospektive

• Wie der letzte Sprint in Bezug auf Einzelpersonen, Aktionen, Prozesse und Werkzeuge verlaufen ist.
• Planung, wie Qualität und Effektivität gesteigert werden können.

Review

• Ergebnis des Sprints überprüfen.
• Zukünftige Anpassungen bestimmen.
• Das Team präsentiert die Ergebnisse seiner Arbeit den wichtigsten Stakeholdern.
• Fortschritt in Richtung Product Goal wird besprochen.

Artefakte

Product Backlog

• Einzige Arbeitsquelle für das Scrum-Team
• Was zur Verbesserung des Produkts benötigt wird
• Dargestellt als geordnete Liste von Einträgen

Sprint Backlog

• Sprint Goal (Warum?)
• Sprint Backlog Items (Was?)
• Sprint-Plan zur Erstellung eines oder mehrerer Increments (Wie?)

Increment

• Nutzbare Funktionalität, die Wert für den Kunden darstellt
• Mehrere Increments können während eines Sprints erstellt werden
• Muss ein nutzbares Stück Produkt sein
• Der Product Owner entscheidet, ob ein Increment freigegeben werden kann
• Eine Freigabe während des Sprints oder nach dem Review ist keine Pflicht
• Alle Increments müssen zusammenarbeiten
• Voraussetzungen für die Increments müssen vorab entwickelt worden sein und mit der bisherigen Arbeit des Teams zusammenpassen
• Die Summe aller Increments im Sprint wird beim Review präsentiert
• Es ist erlaubt, Increments vor dem Review freizugeben, sofern sie die Definition of Done erfüllen

Commitment: Definition of Done

• Ist eine formale Definition des Zustands eines Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßstäbe erfüllt
• Definiert, wann es freigegeben werden kann
• Schafft Transparenz durch ein gemeinsames Verständnis darüber, welche Arbeit als Teil des Increments abgeschlossen wurde
• Beispiel: Ein Increment ist getestet, Sicherheitsgenehmigungen wurden eingeholt, Dokumentation wurde angepasst