Zwei Aspekte aus diesem Artikel möchte ich herausgreifen. Einerseits wird großen Wert auf das Erreichen eines gemeinsamen Ziels gelegt:

„[…] a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements”

Es geht also darum, sich die Aufgaben innerhalb eines Teams gegenseitig „zuzuspielen“ und ihn gemeinsam in die Endzone zu tragen, nicht darum, „seinen Teil“ zu erledigen und den Rest Anderen zu überlassen.

Andererseits gibt der Artikel sechs Erfolgsfaktoren an, die ein Team aufweisen muss, um hyperperformant zu werden:

  1. Built-in instability
  2. Self-organizing project teams
  3. Overlapping development phases
  4. “Multilearning”
  5. Subtle control
  6. Organizational transfer of learning

Definition von Scrum

Scrum ist im Scrum Guide definiert (https://www.scrumguides.org), der immer noch von den Erfindern weiterentwickelt wird. Die Definition lautet:

„Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.“

Es lohnt sich, diese Definition etwas genauer zu betrachten.

  • Es geht also um ein „Rahmenwerk“, nicht um eine Methodik oder eine Methode. Ein Rahmenwerk ist – wie der Bilderrahmen an der Wand – weder Selbstzweck noch vollständig gefüllt. Erst mit dem Bild – oder den unternehmensspezifischen Prozessen, Produkten und Rahmenbedingungen – kommt der Rahmen zur Geltung.
  • Der Mensch steht ebenfalls ganz vorne in der Definition. Nicht als Ressource oder „Full Time Equivalent (FTE)”, sondern als ganzheitliches Individuum. Das sagt viel über das Menschenbild aus, das in Scrum vorherrscht.
  • Komplexe (also mit hoher Unsicherheit behaftete) adaptive (also sich verändernde) Aufgaben werden durch Scrum adressiert. Es geht nicht um komplizierte (schwierige, aber mit Wissen lösbare) oder einfache (vollständige planbare) Probleme.
  • Produktivität steht im Vordergrund. Das ist das Produkt aus Effizienz und Effektivität. Es geht nicht darum, eine dieser Größen für sich allein genommen zu optimieren, sondern immer um die Kombination dieser.
  • Kreativität ist notwendig, um unbekannte Lösungen zu finden. Das erfordert eine kreativitätsfördernde Umgebung und Rahmenbedingungen (z.B. wenig Überstunden). Denk einfach mal daran, wann du besonders kreativ bist: Im Büro am Schreibtisch?
  • Scrum kümmert sich um Produkte, nicht um Projekte. Stark vereinfacht ausgedrückt ist ein Projektleiter erfolgreich, wenn das Projektergebnis abgenommen wurde. Ein Product Owner ist dann erfolgreich, wenn er das Produkt durch den gesamten Produktlebenszyklus, also von der Idee bis zur Abkündigung, begleitet hat.
  • Der Wert steht im Vordergrund. Was genau Wert ist, hängt stark vom Kontext ab. Auf jeden Fall ist es mehr, als eine Liste von Anforderungen, die ohne Marktfeedback von Führungskräften priorisiert wurde.

Grundelemente von Scrum

Die Grundelemete von Scrum gliedern sich in 3 Rollen, 3 Artefakte und 5 Events.

Rollen

Das Entwicklungsteam besteht aus ca. 3-9 Personen mit verschiedenen Fähigkeiten, die gemeinsam aus den Anforderungen, die im Product Backlog stehen, ein Produkt entwickeln. Ein solches Team verfügt idealerweise über alle Fähigkeiten, die benötigt werden, was Abhängigkeiten zu anderen Abteilungen, Personen oder Teams überflüssig macht. Das Entwicklungsteam organisiert sich selbst, ist also für das „Wie“ bzw. die Umsetzung verantwortlich.

Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu optimieren. Das tut er, indem er dafür sorgt, dass die richtigen Dinge in der richtigen Reihenfolge im Product Backlog stehen. Auch Stakeholdermanagement, Reporting und die Entscheidung, wann releast wird, liegen bei dieser Rolle. Er ist für das „Was“ des Produktes verantwortlich.

Die Scrum Masterin managt den Prozess. Sie unterstützt Entwicklungsteam und Product Owner, moderiert wo nötig Events und sorgt auch dafür, dass die restliche Organisation agiler wird. Mein Lieblingsbild ist das einer Hebamme: Sie macht die Arbeit nicht selbst, aber sorgt dafür, dass die anderen ihren Job besser machen.

Diese drei Rollen zusammengenommen nennt man „Scrum Team“.

Artefakte

Im Product Backlog stehen alle Anforderungen, die umgesetzt werden sollen. Dieses Artefakt ist die einzige Quelle für Anforderungen. Egal ob Bug, Feature oder sonstige Aufgabe: Wenn es nicht im Backlog steht, wird es auch nicht gemacht (wobei in der Praxis die Aufenthaltsdauer im Backlog auch im Minutenbereich liegen kann, bevor das Team mit der Arbeit beginnt, z.B. bei einem dringlichen Produktionsproblem). Das Product Backlog gehört dem Product Owner. Dieser erlaubt in der Praxis aber oft dem Entwicklungsteam und den Stakeholdern, ebenfalls an der Entstehung und Pflege mitzuwirken. Das Product Backlog ist zu jedem Zeitpunkt sortiert (die obersten Elemente werden zuerst umgesetzt) und es ist normal, dass die Elemente oben im Backlog feiner ausspezifiziert sind, als die Elemente unten im Backlog. Es ist entfernt verwandt mit dem klassischen Lastenheft.

Wenn man das Product Backlog mit einem Lastenheft vergleichen kann, dann ist das Sprint Backlog in etwa mit einem Pflichtenheft vergleichbar. Es gehört dem Entwicklungsteam und ist jeweils für einen Sprint gültig. In ihm stehen die Anforderungen des Sprints sowie alle Aufgaben (Tasks), die abgearbeitet werden müssen, um diese Anforderungen umzusetzen. Die Tasks haben typischerweise die maximale Größe von acht Stunden, damit von einem zum nächsten Tag ein Fortschritt erkennbar wird. Das Sprint Backlog verändert sich täglich, je nachdem welche Fortschritte und Erkenntnisse aufgetreten sind.

Die Arbeit führt zum Produktinkrement. Jeden Sprint muss mindestens einmal ein solches „potenziell auslieferbares Produktinkrement“ erstellt werden, es darf aber auch mehrmals am Tag fertig werden. Dieses Inkrement wird dann mindestens mit Stakeholdern und Kunden inspiziert, idealerweise sogar produktiv ausgeliefert. Die Grundüberzeugung in Scrum ist, dass echte Erkenntnisse nur erzielt werden können, wenn echte Kunden mit dem echten Produkt arbeiten.

Events

Der Sprint ist eine Iteration, in der gearbeitet wird. Er dauert nicht länger als einen Monat (in der Praxis sind im Moment 2 Wochen allgemein üblich, mit der Tendenz zu kürzeren Sprints) und beginnt mit einem Sprint Planning. In diesem Planungsevent erklärt der Product Owner dem Entwicklungsteam, was er gerne umgesetzt haben würde. Das Team stellt Rückfragen und schätzt ab, welchen Umfang in diesem Sprint geschafft werden kann. Dann zieht es sich („Pull-Prinzip“) die Aufgaben gemäß der Reihenfolge des Product Backlogs in sein Sprint Backlog. Anschließend werden die Tasks so gut wie möglich geplant. Am Ende des Sprint Plannings wird ein „Forecast“ abgegeben, also die Abschätzung, mit welcher Menge an Ergebnissen der Product Owner zum Sprintende rechnen darf. Auch wird gemeinsam ein Sprintziel definiert, das das gesamte Team auf ein gemeinsames Ziel einschwört.

Der Fortschritt wird dann täglich im Daily Scrum geprüft. Allerdings nicht im Sinne eines Reportings, sondern im Sinne eines Planungsevents vom Entwicklungsteam für das Entwicklungsteam. Die Hauptfrage lautet dabei: “Was müssen wir verändern, um unser Sprintziel noch zu erreichen?”

Am Ende des Sprintes wird das Produkt im Sprint Review inspiziert. Es geht hier weder um eine „Demo“ noch um eine „Abnahme“. Es geht um die Kollaboration mit den Stakeholdern. Diese probieren das Produkt aus, geben Feedback und ihre Meinung zum Product Backlog, also den für die nahe Zukunft geplanten Anforderungen, ab. Der Product Owner spart so diverse Stakeholder-Management-Meetings und kann sein Product Backlog mit realem Feedback anpassen.

Zuletzt führt das Scrum Team gemeinsam eine Retrospektive durch. Sie ist vergleichbar mit einer „Lessons Learned“-Veranstaltung, allerdings wird sie jeden Sprint durchgeführt, nicht nur einmal im Projekt als „Post Mortem“. Hier werden die Prozesse und die Zusammenarbeit des Teams inspiziert und angepasst. Mindestens eine konkrete Maßnahme wird zur sofortigen Umsetzung mit in den nächsten Sprint genommen. Diese stetigen Verbesserungen führen dazu, dass viele Scrumprojekte produktiver laufen als klassische.

Erfolgsfaktoren aus „The New New Product Development Game“ in Scrum

Oben hatten wir schon kurz die von Nonaka und Takeuchi erwähnten Erfolgskriterien erwähnt. Betrachten wir doch kurz, wie Scrum diese aufgreift. Zur Definition der einzelnen Elemente empfehle ich die Lektüre des sehr lesenswerten Artikels (https://hbr.org/1986/01/the-new-new-product-development-game).

1. Built-in instability

Scrum überlässt die gesamte Umsetzungsplanung dem Entwicklungsteam. Außerdem sind nur die zeitlich nahen Anforderungen im Product Backlog ausdetailliert. Die weiter entfernten sind oft nur als Stichpunkte verfügbar. So kann sich die Richtung jederzeit ändern.

2. Self-organizing project teams

Ein Scrum Team hat mit Product Owner, Scrum Master und Entwicklungsteam alle Fähigkeiten, die benötigt werden. Außerdem ist das Entwicklungsteam in sich interdisziplinär und selbstorganisiert aufgebaut.

3. Overlapping development phases

Die Sprints geben den im Artikel erwähnten „Puls“ vor. Auch überlappen sich die klassischen Entwicklungsphasen stark, weil nur so jeden Sprint ein Produktinkrement fertiggestellt werden kann.

4. “Multilearning”

Durch die ständige Interaktion im Team und mit der Umwelt, zum Beispiel den Stakeholdern, lernt das Scrum Team ständig dazu. Allerdings definiert Scrum nichts zu individuellen „Lernzeiten“, z.B. einem „Lernfreitag“ oder Pair Programming. Dies bleibt dem individuellen Unternehmen und dem jeweiligen Kontext überlassen.

5. Subtle control

Hartes „Command and Control“ gibt es in Scrum nicht. Stattdessen werden allen Personen im Scrum Team große Freiheiten eingeräumt. Das heißt aber nicht, dass gar keine Kontrolle ausgeübt wird: Gerade durch die häufigen Interaktionen mit Stakeholdern und die kurzen Zyklen entsteht eine enorme Transparenz, die zusammen mit den klaren Verantwortlichkeiten der Rollen in Scrum zu einer automatischen Kontrolle und einem gewissen Gruppendruck führt. Auch ermöglicht Scrum das Lernen aus Experimenten, so dass am Ende nicht der schlauste Kopf, sondern das Ergebnis des Experiments den größten Einfluss auf Entscheidungen hat.

6. Organizational transfer of learning

Auf der Produktebene hat Scrum hier nichts definiert. Allerdings ist die Scrum Masterin so definiert, dass sie das Prozesswissen durch die Organisation verteilen soll. So werden Multiplikatoren geschaffen und „Wissensinseln“ vermieden.

Fazit

Scrum ist sehr leichtgewichtig und einfach zu verstehen, allerdings sehr schwer zu meistern. Es stellt lediglich ein Framework dar, die individuelle Ausgestaltung bleibt den Beteiligten überlassen. Grundsätzlich erfüllt es aber schon vieles von dem, was Takeuchi und Nonaka schon 1986 als Erfolgsfaktoren für hochproduktive Entwicklungsteams identifiziert haben.

Folgende Beiträge könnten dich auch interessieren