Large-Scale Scrum E-Book

Craig Larman

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2017

Seitenzahl: 475

Beschreibung

Wie können wir agiles Arbeiten in großen, komplexen Organisationen skalieren? Eine Frage, die sich vielen Unternehmen stellt. Mit Large-Scale Scrum (LeSS) liegen nun zwei Frameworks (LeSS und LeSS Huge) vor, mittels derer Scrum konsequent ohne viel Zusatz skaliert werden kann, um als Unternehmen agil und überlebensfähig zu sein. In diesem Buch haben Craig Larman und Bas Vodde ihre Erkenntnisse aus mehr als einem Jahrzehnt an Erfahrung in der Einführung von LeSS in groß angelegten Umgebungen gebündelt. Es sind konkrete Wegweiser entstanden, die dabei helfen, mehr Flexibilität durch weniger Komplexität, mehr Wert durch weniger Verschwendung und mehr Sinnhaftigkeit durch weniger Vorschriften im Unternehmen zu verankern. Es werden u.a. folgende Themen adressiert: - Implementierung von LeSS für die Entwicklung in großen Umgebungen - Auswahl der richtigen Umsetzungsstrategie und des Organisationsdesigns - Ausrichtung und Strukturierung einer großen Entwicklungsorganisation hin zum Kundennutzen - Klärung der Rolle des Managements, des Product Owners und des Scrum Masters - Skalierung von Produktdefinition, Anforderungen, Planung und Produktmanagement - Synchrones Arbeiten mit mehreren Feature-Teams - Koordination und Integration zwischen den Teams - Integration von Scrum in Multisite- und Offshore-Projekten - Skalierung von Design und Architektur

Leseprobe

Craig Larman arbeitet als wissenschaftlicher Leiter bei Valtech, einem der führenden Beratungsunternehmen mit Geschäftsstellen in den Vereinigten Staaten, Europa und Asien. Er ist weltweit in der Software Community bekannt als Experte und Coach für OOA/D und Entwurfsmuster, agile/iterative Methoden, einen agilen Ansatz des Unified Process (UP) und die Modellierung mit der UML. Er hält einen B.S. und M.S. in Computerwissenschaften der Simon Fraser University in Vancouver, British Columbia.

Die Übersetzer:

Bas Vodde arbeitet als selbstständiger Coach für Produktentwick-lung und Scrum(skalierung). Er leitete für mehrere Jahre die unternehmensweite Initiative zur Adaption von Agile und Scrum bei Nokia Networks. Er begeistert sich für die Verbesserung von Produktentwicklung im Allgemeinen, studiert leidenschaftlich Organisationsentwicklung und Teammanagement und schafft es dabei, noch aktiver Softwareentwickler zu bleiben.

Björn Jensen ist als Agile Coach und Certified Scrum Trainer® (CST) bei der improuv GmbH tätig. Seine Reise in Richtung Agile begann Anfang 2000, als er als Softwareentwickler in Kontakt mit eXtreme Programming (XP) und Pragmatic Programming gekommen ist. Seitdem hat er Agilität in vielen Kontexten angewendet, in kleinen und großen Organisationen, von der Entwicklung über das Management hin zur Führungsebene, von eher traditionell bis sehr agil – als Entwickler, Release & System Engineer, Scrum Master, Product Owner, Agile Coach und Trainer. Seine Arbeitsschwerpunkte sind Large-Scale Scrum mit LeSS und agile Produktentwicklung.

Alexander Marquart arbeitet als Agile Coach, Trainer, Certified Scrum Professional® (CSP) und Certified LeSS Practitioner® bei improuv. Erste Kontakte zu agiler Produktentwicklung ergaben sich 2008 aus dem klassischen Projektmanagement kommend mit ersten kundenzentrierten, iterativen Ansätzen als Scrum Master. Seit diesem Zeitpunkt betreut er Unternehmen aller Größenordnungen darin, ihre Produkte in enger Zusammenarbeit von Teams und Kunden erfolgreich zu positionieren. Er unterstützt Organisationen und Teams bei der Einführung und Optimierung von Scrum. Seine Arbeitsschwerpunkte sind Large-Scale Scrum mit LeSS und agile Produktentwicklung.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

Large-Scale Scrum

Scrum erfolgreich skalieren mit LeSS

Aus dem Englischen übersetzt vonBjörn Jensen und Alexander Marquart

Craig LarmanBas Vodde

Lektorat: Christa Preisendanz

Übersetzung: Björn Jensen und Alexander Marquart

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Susanne Bröckelmann

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print   978-3-86490-376-2

PDF   978-396088-121-6

ePub   978-396088-122-3

mobi   978-396088-123-0

1. Auflage 2017

Translation Copyright für die deutschsprachige Ausgabe © 2017 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized translation from the English language edition, entitled Large-Scale Scrum: More with Less, 1st Edition (978-0-321-98571-2) by Craig Larman; Bas Vodde, published by Pearson Education, Inc, publishing as Addison-Wesley Professional, Copyright © 2016 by Pearson Education, Inc.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.

German language edition published by dpunkt.verlag GmbH, Copyright © 2017

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Geleitwort von Stephen Denning

Large-Scale Scrum oder LeSS setzt die Reihe wichtiger Entdeckungen fort, die die Welt des Managements verändern werden, indem es zeigt, wie Agile und Scrum im großen Maßstab implementiert wird.

Im 20. Jahrhundert hat hierarchische Bürokratie großen Gruppen ermöglicht, zusammenzuarbeiten, um außergewöhnliche Verbesserungen in der Produktivität zu erreichen. Dann veränderte sich die Welt. Deregulierung, Globalisierung, die Entstehung von Wissensarbeit und neuen Technologien, insbesondere vom Internet, veränderte alles. Der Wettbewerb stieg. Das Tempo des Wandels nahm zu. Computersoftware ermöglichte riesige Zugewinne an Produktivität, generierte jedoch im Gegenzug immense Komplexität. Als die Machtposition am Markt vom Verkäufer zum Käufer überging, wurde der Kunde, nicht die Firma, das Zentrum des kommerziellen Universums. Diese Verschiebungen erforderten ein grundsätzlich anderes Management, das die Talente von jedem Einzelnen in der Organisation – und darüber hinaus – mobilisieren konnte, um die neue und wesentlich schwierigere Herausforderung zu erfüllen, nämlich den Kunden zu begeistern. Die Änderungen gingen sehr weit über einfache Updates der Managementpraktiken hinaus. Agile und Scrum bieten explizite Alternativen zu scheinbar lang gehegten, klaren, selbstverständlichen Managementannahmen.

LeSS zeigt, wie große und komplexe Entwicklung gehandhabt wird. Selbstverwaltende Teams sind nicht nur winzige Kuriositäten. Sie können enorme internationale Tätigkeiten von großer, technischer Komplexität bewältigen. Die Praktiken sind im Gegensatz zu Bürokratie nicht nur skalierbar, sie sind skalierbar ohne Sklerose.

LeSS setzt den Prozess fort, Management grundsätzlich neu zu erfinden – durch Einbetten der schwer erkämpften Lektionen aus Erfahrungen aus über mehr als einer Dekade im Skalieren der Manage-mentmethoden aus Agile und Scrum. Es zeigt, wie man immense Komplexität durch Erzeugen von Einfachheit bewältigen kann.

LeSS ist bewusst unvollständig. Es lässt Raum für enormes, situatives Lernen. Es bietet weder definitive Antworten, noch versucht es, die Sehnsüchte des 20. Jahrhunderts nach schablonenhaften Antworten oder scheinbar sicheren und disziplinierten Ansätzen, die eine beruhigende Illusion von vorhersehbarer Kontrolle anbieten, zu befriedigen. LeSS konzentriert sich auf die minimale Essenz, die zur Skalierung nötig ist, inklusive kontinuierlicher Aufmerksamkeit auf technischer Exzellenz und einer Mentalität des kontinuierlichen Experimentierens. Es beinhaltet immer neue Experimente in dem Bemühen, sich zu verbessern. Wie Scrum selbst, strebt LeSS nach einer Balance zwischen abstrakten Prinzipien und konkreten Praktiken.

Und wie Scrum auch ist LeSS kein Prozess und keine Technik zum Bauen von Produkten. Vielmehr ist es ein Framework, innerhalb dessen Prozesse und Techniken adaptiert werden können, um den Bedürfnissen der jeweiligen Situation gerecht zu werden. Es zielt darauf ab, deutlich zu machen, wie Produktmanagement- und Entwicklungspraktiken kontinuierliche Verbesserung ermöglichen können, die Wert für den Kunden hinzufügt.

Anstatt feste Antworten zur Verfügung zu stellen, stellt LeSS den Ausgangspunkt für Verständnis und Adaption der tieferliegenden Prinzipien dar. Statt zu fragen: »Wie können wir im großen Maßstab in unserer komplexen, hierarchischen Bürokratie Agile einsetzen?«, fragt es eine andere und tiefer gehende Frage: »Wie können wir die Organisation vereinfachen und agil sein?«

LeSS strebt danach, diese Balance in größeren Produktgruppen zu erreichen. Es fügt mehr konkrete Struktur zu Scrum hinzu und hält dabei gleichzeitig radikale Transparenz aufrecht und betont den Inspektions-und-Adaptions-Zyklus, damit Gruppen ihre eigene Art zu arbeiten kontinuierlich verbessern können. Es adressiert die grundlegende Frage: Wie können wir das, was gut auf individueller Team-ebene funktioniert, nehmen und dafür sorgen, dass es auf einer viel breiteren Ebene in der Organisation ebenfalls funktioniert?

Es bleibt viel zu lernen und zu tun im Sinne der Skalierung von Agile und Scrum. Dieses Buch ist sowohl Fortschrittsbericht als auch Wegweiser für die Zukunft. Gegenwärtig machen viele Organisationen keinen guten Job durch das Vorhandensein mehrerer Teams, die synchron an verschiedenen Aspekten der Produkte und Plattformen arbeiten. Umfragen haben gezeigt, dass die meisten agilen und Scrum-Teams heutzutage über die Spannungen zwischen der Art und Weise, wie das Team arbeitet, und der Art und Weise, wie der Rest des Unternehmens läuft, berichten. Dieses Buch stellt einen praktischen Wegweiser zur Verfügung, wie man schrittweise diese Spannungen auflösen kann.

Stephen DenningAutor von The Leader’s Guide to Radical Management27. April 2016

Vorwort

Alle großen Wahrheiten waren anfangs Blasphemien.George Bernard Shaw

Willkommen an der Pforte zur Welt von LeSS, wo einfachere Strukturen organisatorische Komplexität ersetzen – durch die Konzentration auf Menschen und ihr Lernen. Für einige Menschen erscheint LeSS romantisch und hoffnungslos idealistisch. Das trifft aber nicht zu – es ist für viele Produktgruppen heute Realität.

Warum dieses Buch?

Als die Autoren über das Feedback zu den letzten beiden Büchern über LeSS reflektiert haben, dass zu viele Ideen mit zu wenig Ansatzpunkten präsentiert wurden, hat Craig Bas gefragt, ob er ein weiteres Buch schreiben wolle. Bas lehnte ab, da er ungeduldig auf die Geburt seines zweiten Sohnes wartete. Doch Craig blieb hartnäckig und überzeugte Bas letztendlich, dass dieses weitere Buch ein Leichtes sein würde. Wie sehr Craig sich doch getäuscht hatte.

Die ursprüngliche Absicht war es, die Grundlagen für die bisherigen LeSS-Bücher zu schreiben. Allerdings landete man bei einem ganz anderen Buch, da das Erforschen konkreter Ansatzpunkte zu einer Beschäftigung mit den minimalen Voraussetzungen für eine Skalierung führte. Das Ergebnis? Die LeSS-Regeln, die LeSS-Wegweiser und dieses Buch.

Die LeSS-Regeln und -Wegweiser sind wichtig, aber sie sind nicht die einzigen Dinge, die zu berücksichtigen sind, wenn man skalieren möchte oder muss. Bevor wir in LeSS eintauchen, wollen wir zwei andere wichtige Punkte explizit hervorheben: kontinuierliche Aufmerksamkeit auf technische Exzellenz und eine experimentierfreudige Geisteshaltung.

Für wen ist dieses Buch?

Dieses Buch ist für jeden, der mit der Entwicklung von Produkten zu tun hat. Die einzige Voraussetzung für dieses Buch ist ein grundlegendes Verständnis von Scrum. Wenn das nicht vorhanden ist, empfehlen wir, vorher den Scrum Guide (http://www.scrumguides.org) und den Scrum Primer (http://www.scrumprimer.org) zu lesen. Wir werden aber jedes Kapitel auch noch mit einer kleinen Scrum-Auffrischung in Bezug auf das Thema beginnen.

Wie ist das Buch aufgebaut?

Jedes Hauptkapitel hat folgende Struktur:

Scrum mit einem Team

Dieser Abschnitt fasst Scrum in dem entsprechenden Kontext für ein Team zusammen und schafft damit die idealen Voraussetzungen, um LeSS zu erlernen.

LeSS

Dieser Abschnitt deckt den grundlegenden Teil des LeSS-Frameworks ab und ist wie folgt aufgebaut:

• Einführung und zugehörige LeSS-Prinzipien

• LeSS-Regeln

• LeSS-Wegweiser

LeSS Huge

Dieser Abschnitt ist genau so aufgebaut wie der LeSS-Abschnitt.

Schreibstil

Wir haben uns für folgende stilistische Möglichkeiten entschieden:

LeSS- und Scrum-Begriffe sind nicht ins Deutsche übersetzt, wie zum Beispiel Scrum Master oder Product Backlog Refinement.

Im gesamten Buch sprechen wir Sie als Leser direkt an. Wir nehmen an, dass Sie in eine LeSS-Einführung involviert sind, und gehen davon aus, dass Ihre Rolle mit dem Thema des Kapitels in Zusammenhang steht. Wenn Sie sich also beispielsweise mit dem Kapitel Product Owner beschäftigen, gehen wir davon aus, dass Sie auch als Product Owner tätig sind.

Wir benutzen kursive und fette Schrift sowie Boxen, um wichtige Punkte hervorzuheben.

Das Buch ist bewusst spärlich gehalten in Bezug auf Literaturangaben. Wer auf der Suche nach genaueren Hinweisen ist, dem seien unsere vorherigen Bücher ans Herz gelegt, da diese ein deutlich umfangreicheres Literaturverzeichnis enthalten.

Organisationsbezogene Begrifflichkeiten

Die meisten Begriffe definieren wir, wenn wir sie das erste Mal benutzen. Das ist jedoch nicht immer ganz einfach gewesen, da verschiedene Unternehmen unterschiedliche Begriffe verwenden. Aus diesem Grund stellen wir an dieser Stelle einmal die Begriffe vor, die wir dann auch im ganzen Buch verwenden. Für einige Leser ist deren Bedeutung offensichtlich, für andere wiederum sind sie vielleicht relativ neu.

Produktgruppe

Das sind alle Personen, die in das Produkt involviert sind. Unternehmen verwenden häufig den Begriff Projekt, um alle Personen zu referenzieren, die an der Entwicklung beteiligt sind. Wir vermeiden den Begriff Projekt in diesem Buch, da wir die Entwicklung eines Produkts besonders betonen wollen – daher Produktgruppe.

Linienorganisation

Rein formell wird die Organisation in der Regel in einem Organigramm dargestellt. Die Linienorganisation ist typischerweise involviert in Beurteilung, Einstellung, Entlassung und Kompetenzentwicklung. Sie ist in vielen Fällen sofort sichtbar, wenn man sich das Organigramm des Unternehmens ansieht und somit die Berichtslinie innerhalb des Unternehmens.

Neben der Linienorganisation gibt es dann meist eine Organisation mit sogenannten Stabsstellen, die zur Unterstützung dienen. Dazu gehören dann unter anderem das Personalwesen (HR), die Qualitätssicherung usw.

Zusätzlich dazu haben einige Unternehmen eine Projektmatrixorganisation (so etwas sollte in LeSS nicht existieren). Diese ist nicht aus dem Organigramm ersichtlich, stellt aber im Wesent-lichen dar, wer welche Arbeit mit wem zusammen in welchem Kon-text erledigt.

Direkte Vorgesetzte und 1st-Level-Manager

Als direkter Vorgesetzter berichtet man an die Linienorganisation. Der 1st-Level-Manager ist der direkte Vorgesetzte, an den Sie berichten.

Senior Manager oder Führungskräfte

Das sind die Manager, die im oberen Bereich der Organisation arbeiten. In einer großen Organisation befinden sie sich meist außerhalb der Produktgruppe.

Produktmanagement oder Produktmarketing

Diese Funktionseinheit in einer Produktorganisation hat die Aufgabe, den Markt zu erforschen und Entscheidungen hinsichtlich des Produktinhalts zu treffen. Diese Mitarbeiter stehen normalerweise nicht in einer Vorgesetztenbeziehung mit den Teams.

Leiter der Produktgruppe

Er ist der Kopf der Produktgruppe und ihm berichten alle Menschen in der Produktgruppe entlang der Berichtslinie.

Projekt/Programm-Manager-Rolle

Diese Rolle ist traditionell verantwortlich für die Planung eines Releases. Sie steht normalerweise nicht mit dem Team in einer Beziehung entlang der Berichtslinie, da diese Rolle einen kurzfristigen vorübergehenden Fokus hat. Beide Rollen sollten in einer LeSS-Organisation nicht existieren.

Funktionale Organisation

Darunter versteht man die Linienorganisation für eine funktionale Fähigkeit wie zum Beispiel Entwicklung, Tests oder Analyse. Sie sollte in einer LeSS-Organisation aufhören zu existieren.

Danksagungen

Wir hatten eine riesige Anzahl an Reviewern für dieses Buch. Diejenigen, die mehr als ein Kapitel kommentiert haben, sind nachfolgend aufgeführt.

Janne Kohvakka, Hans Neumaier, Rafael Sabbagh, Ran Nyman, Ahmad Fahmy, Mike Cohn, Gojko Adzic, Jutta Eckstein, Rowan Bunning, Jean-Marc Gerber, Yi Lv, Steve Spearman, Karen Greaves, Marco Seelmann, Cesario Ramos, Markus Gärtner, Viktor Grgic, Chris Chan, Nils Bernert, Viacheslav Rozet, Edward Dahllöf, Lisa Crispin, Mike Dwyer, Francesco Sferlazza, Nathan Slippen, Mika Sjöman, Tim Born, Charles Bradley, Timothy Korson, Erin Perry, Greg Hutchings, Jez Humble, Alexey Krivitsky, Alexander Gerber, Peter Braun, Jurgen De Smet, Evelyn Tian, Sami Lilja, Steven Mak, Alexandre Cotting, Bob Schatz, Bob Sarni, Milind Kulkarni, Janet Gregory, Jerry Rajamoney, Karl Kollischan, Shiv Kumar Mn, David Nunn, Rene Hamannt, Ilan Goldstein, Juan Gabardini, Mehmet Yitmen, Kai-Uwe Rupp, Christian Engblom, James Grenning, Venkatesh Krishnamurthy, Peter Hundermark, Arne Ahlander, Darren Lai, Markus Seitz, Geir Amsjø, Ram Srinivasan, Mark Bregenzer, Aaron Sanders, Michael Ballé, Stuart Turner, Ealden Escañan, Steven Koh, Ken Yaguchi, Michael James, Manoj Vadakkan, Peter Zurkirchen, Laszlo Csereklei, Gordon Weir, Laurent Carbonnaux, Elad Sofer.

Ein ganz besonderer Dank geht an Bernie Quah für die Illustrationen und Terry Yin, der uns bei nahezu allen Anfragen unterstützt hat, sowie Chris Guzikowski von Addison-Wesley für seine Geduld bei diesem Buchprojekt, das länger dauerte als gedacht.

Inhaltsübersicht

1      More with LeSS

2      LeSS

Teil I      LeSS-Struktur

3      Einführung

4      Organisiere nach Kundennutzen

5      Management

6      Scrum Master

Teil II      LeSS-Produkt

7      Produkt

8      Product Owner

9      Product Backlog

10    Definition of Done

Teil III      LeSS-Sprint

11    Product Backlog Refinement

12    Sprint-Planung

13    Koordination & Integration

14    Review & Retrospektive

Teil IV      More or LeSS

15    Was kommt als Nächstes?

Anhang

A      Literaturempfehlungen

B      Regeln

C      Wegweiser

Index

Inhaltsverzeichnis

1 More with LeSS

Warum LeSS?

2 LeSS

Scrum mit einem Team

LeSS

▀   Vorgeschichte

▀   Experimente, Wegweiser, Regeln und Prinzipien

▀   LeSS-Prinzipien

▀   Zwei Frameworks: LeSS & LeSS Huge

LeSS-Framework

▀   LeSS-Framework – Zusammenfassung

▀   LeSS-Geschichten

▀   LeSS-Geschichte: Der Ablauf von Teams

▀   LeSS-Geschichte: Der Fluss von Einträgen

LeSS-Huge-Framework

▀   Requirement Areas

▀   Area Product Owner

▀   Area-Feature-Teams

▀   LeSS-Huge-Framework – Zusammenfassung

▀   LeSS-Huge-Geschichten

▀   LeSS-Huge-Geschichte: Eine neue Requirement Area

▀   Standortübergreifende Teams: Begriffe und Tipps

▀   LeSS-Huge-Geschichte: Standortübergreifende Teams

Ausblick

Teil ILeSS-Struktur

3 Einführung

Scrum mit einem Team

LeSS-Einführung

▀   LeSS-Regeln

▀   Wegweiser: Drei Einführungsprinzipien

▀   Wegweiser: Erste Schritte

▀   Wegweiser: Kultur folgt Struktur

▀   Wegweiser: Gesicherter Arbeitsplatz, aber keine gesicherte Rolle

▀   Wegweiser: Vision einer perfekten Organisation

▀   Wegweiser: Kontinuierliche Verbesserung

▀   Wegweiser: Skalierung der Einführung

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Evolutionäre inkrementelle Einführung

▀   Wegweiser: Nur eine Requirement Area gleichzeitig

▀   Wegweiser: Parallele Organisationen

4 Organisiere nach Kundennutzen

Scrum mit einem Team

Organisiere nach Kundennutzen in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Baue teambasierte Organisationen auf

▀   Wegweiser: Feature-Teams verstehen

▀   Wegweiser: Feature-Team Adoption Maps

▀   Wegweiser: Bevorzuge Spezialisierung nach Kundengebiet

▀   Wegweiser: LeSS-Organisationsstruktur

▀   Wegweiser: Mehrere Standorte in LeSS organisieren

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Requirement Areas

▀   Wegweiser: Dynamiken von Requirement Areas

▀   Wegweiser: Übergang zu Feature-Teams

▀   Wegweiser: LeSS-Huge-Organisation

5 Management

Scrum mit einem Team

LeSS-Management

▀   LeSS-Regeln

▀   Wegweiser: Taylor und Fayol verstehen

▀   Wegweiser: Theorie-Y-Management

▀   Wegweiser: Manager sind optional

▀   Wegweiser: Die LeSS-Organisation

▀   Wegweiser: Go & See

▀   Wegweiser: Manager als Lehrer und Lernende

▀   Wegweiser: Sowohl fachliche als auch technische Kompetenz

▀   Wegweiser: LeSS-Metriken mit weniger Zielen

▀   Wegweiser: Literaturliste für das Management

6 Scrum Master

Scrum mit einem Team

LeSS Scrum Master

▀   LeSS-Regeln

▀   Wegweiser: Im Fokus des Scrum Masters

▀   Wegweiser: Fünf Scrum-Master-Werkzeuge

▀   Wegweiser: Großgruppenmoderation

▀   Wegweiser: Fördere Lernbereitschaft & ein breites Fähigkeitenspektrum

▀   Wegweiser: Community-Arbeit

▀   Wegweiser: Überlebenstipps für Scrum Master

▀   Wegweiser: Literaturliste für Scrum Master

▀   Wegweiser: Achte besonders auf ...

LeSS Huge

▀   Wegweiser: Vermeide Requirement-Area-Silos

Teil IILeSS-Produkt

7 Produkt

Scrum mit einem Team

LeSS-Produkt

▀   LeSS-Regeln

▀   Wegweiser: Was ist dein Produkt?

▀   Wegweiser: Definiere dein Produkt

▀   Wegweiser: Ausdehnen der Produktdefinition

▀   Wegweiser: Produkt über Projekt oder Programm

LeSS Huge

8 Product Owner

Scrum mit einem Team

Product Owner in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Wer sollte Product Owner sein?

▀   Wegweiser: Starte früh oder unstrukturiert mit einem fingierten Product Owner

▀   Wegweiser: Wer sind diese Nutzer bzw

▀   Wegweiser: Priorisierung über Klärung

▀   Wegweiser: Tu es nicht

▀   Wegweiser: Helfer für Product Owner

▀   Wegweiser: Fünf Beziehungen

▀   Wegweiser: Zusammenarbeit mit dem Kunden über ...

▀   Wegweiser: Liefere mindestens jeden Sprint

▀   Wegweiser: Sei nicht nett

▀   Wegweiser: Lass los

▀   Wegweiser: Lass dir unerledigte Arbeit nicht zum Verhängnis werden

▀   Wegweiser: LeSS-Meetings

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: LeSS Huge Product Owner

▀   Wegweiser: Area Product Owner

▀   Wegweiser: Product-Owner-Team unterstützt durch Scrum Master

9 Product Backlog

Scrum mit einem Team

Product Backlog in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Nicht »Abhängigkeiten managen«, sondern Einschränkungen minimieren

▀   Wegweiser: Nimm nur ein Stückchen

▀   Wegweiser: Umgang mit Elternelementen

▀   Wegweiser: Umgang mit speziellen Einträgen

▀   Wegweiser: Werkzeuge für große Product Backlogs

▀   Wegweiser: Mehr Ergebnis, weniger Leistung

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Area Backlogs

▀   Wegweiser: Maximal drei Ebenen

▀   Wegweiser: Eine neue Area für eine gigantische Anforderung

▀   Wegweiser: Umgang mit gigantischen Anforderungen

10 Definition of Done

Scrum mit einem Team

LeSS Done

▀   LeSS-Regeln

▀   Wegweiser: Entwerfen der Definition of Done

▀   Wegweiser: Entwickle die Definition of Done

LeSS Huge

Teil IIILeSS-Sprint

11 Product Backlog Refinement

Scrum mit einem Team

LeSS Product Backlog Refinement

▀   LeSS-Regeln

▀   Wegweiser: Arten von Product Backlog Refinement

▀   Wegweiser: Gesamt-PBR

▀   Wegweiser: Multiteam-PBR

▀   Wegweiser: PBR mit verteilten Standorten

▀   Wegweiser: Initiales PBR

▀   Wegweiser: Schneiden

▀   Wegweiser: Schätzung skalieren

LeSS Huge

12 Sprint-Planung

Scrum mit einem Team

LeSS-Sprint-Planung

▀   LeSS-Regeln

▀   Wegweiser: Sprint-Planung 1

▀   Wegweiser: Multiteam-Sprint-Planung 2

▀   Wegweiser: Keine Softwarewerkzeuge für das Sprint Backlog

LeSS Huge

▀   Wegweiser: Product-Owner-Team-Meeting

13 Koordination & Integration

Scrum mit einem Team

Koordination & Integration in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Einfach reden

▀   Wegweiser: Koordinationsfreundliche Umgebung

▀   Wegweiser: Kommuniziere mittels Code

▀   Wegweiser: Integriere kontinuierlich

▀   Wegweiser: Communitys

▀   Wegweiser: Teamübergreifende Meetings

▀   Wegweiser: Multiteam-Design-Workshop

▀   Wegweiser: Workshop zur aktuellen Architektur

▀   Wegweiser: Komponentenmentoren

▀   Wegweiser: Open Space

▀   Wegweiser: Traveler

▀   Wegweiser: Scouts

▀   Wegweiser: Eher kein Scrum of Scrums

▀   Wegweiser: Ein führendes Team

▀   Wegweiser: Mischen und Verbinden von Techniken

LeSS Huge

14 Review & Retrospektive

Scrum mit einem Team

Sprint-Review & Retrospektiven in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Adaptiere das Produkt früh und häufig

▀   Wegweiser: Review-Basar

▀   Wegweiser: Gesamtretrospektive

▀   Wegweiser: Verbessere das System

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Multi-Area-Reviews & -Retrospektiven

Teil IVMore or LeSS

15 Was kommt als Nächstes?

Anhang

A Literaturempfehlungen

B Regeln

LeSS-Framework-Regeln

▀   LeSS-Struktur

▀   LeSS-Produkt

▀   LeSS-Sprint

LeSS-Huge-Framework-Regeln

▀   LeSS-Huge-Struktur

▀   LeSS-Huge-Produkt

▀   LeSS-Huge-Sprint

C Wegweiser

    Index

1 More with LeSS

Die billigsten, schnellsten und verlässlichsten Komponenten sind die, die gar nicht da sind.

Gordon Bell

Warum LeSS?

Warum ist die Zahl von Scrum-Einführungen in den letzten zehn Jahren förmlich explodiert? Das war die Frage, mit der wir uns bei einem Bier in einer der großen Garküchen in Singapur beschäftigt haben.

Einige meinen, dass der Grund dafür in seinem einfachen Zertifizierungsmodell liegt. Mag sein. Aber eine andere agile Methode – DSDM (Dynamic Systems Development Method) – hat Zertifizierungen bereits vor Scrum angeboten und nie eine solche Verbreitung erfahren.

Andere wiederum sagen, dass das Angebot an Scrum-Master-Trainings den Unterschied gemacht hat. Ken Schwabers ursprüngliches Scrum-Master-Training hat sicher einen starken Einfluss gehabt, doch auch in diesem Kontext war eine andere agile Methode schneller: Extreme Programming hat das XP-Vertiefungstraining (»XP Immersion«) angeboten, was sich aber auch nicht so durchgesetzt hat.

Vielleicht ist es ja die Einfachheit von Scrum, die den Unterschied macht? Verglichen mit XP stellt Scrum ein deutlich einfacheres Framework zur Verfügung. Doch auch noch einfachere agile Methoden wie beispielsweise Crystal sind nicht wirklich durchgestartet.

Nach einigen weiteren Diskussionen und Gedanken schlug Craig vor:

Scrum trifft eine ideale Balance zwischen abstrakten Prinzipien und konkreten Praktiken.

Damit schlossen wir die Diskussion ab und tranken noch ein Bier. Diese konkreten Praktiken betonen die empirische Prozesskontrolle – ein elementares Scrum-Prinzip. Durch die empirische Prozesskontrolle unterscheidet sich Scrum von anderen agilen Frameworks. Der Scrum Guide bringt es auf den Punkt:

Scrum ist weder ein Prozess noch eine Technik zur Erstellung von Produkten, sondern ist vielmehr als Rahmenwerk zu verstehen, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar, so dass Sie sich verbessern können.1

Was bedeutet das? Mit empirischer Prozesskontrolle legen wir weder den Umfang des Produkts noch den Prozess, wie es herzustellen ist, fest. Stattdessen bauen wir in kurzen Zyklen kleine, auslieferbare Teile des Produkts. Wir inspizieren, was wir haben und wie es erstellt wurde. Dann überarbeiten wir das Produkt und die Art, wie es erstellt wurde – basierend auf dem, was wir in der Inspektion erkannt haben. Diese klare Inspektion wird durch die eingebauten Mechanismen zur Erzeugung von Transparenz ermöglicht.

Prinzipien klingen gut, sind aber offenbar nicht immer so leicht umsetzbar. Es ist diese kleine, einfache Menge an konkreten Praktiken, die es so einfach machen, mit Scrum zu starten: die klaren Rollen, Artefakte und Events.

Diese Praktiken erleichtern den Einstieg, sind aber bewusst »unvollständig«, sodass Gruppen genug Raum und Freiheiten innerhalb des Scrum-Frameworks haben, um kontinuierlich zu lernen und zu verbessern. Dies geschieht immer in dem vollen Bewusstsein, dass wir in Domänen von sehr hoher Komplexität arbeiten, für die festgelegte Prozessrezepte eine zu starke Vereinfachung sind.

Die konkreten Praktiken aus Scrum bilden den Ausgangspunkt für die Einführung seiner tieferen Prinzipien. Eine perfekte Balance.

Large-Scale Scrum (LeSS) erreicht die gleiche Balance für größere Produktgruppen. Es fügt ein bisschen mehr konkrete Struktur zu Scrum hinzu, deren Zweck es ist, Transparenz aufrechtzuerhalten und die »Inspect & Adapt«-Zyklen zu betonen, sodass Gruppen kontinuierlich ihre eigenen Arbeitsweisen verbessern können.

Genau wie Scrum ist LeSS bewusst unvollständig. Es lässt genug Raum für sehr viel situatives Lernen. Es bietet nicht viele endgültige Antworten. Wer nach schablonenhaften Antworten oder scheinbar sicheren, disziplinierten Ansätzen sucht, die die tröstliche Illusion von vorhersehbarer Kontrolle wie bei den definierten Prozessen bieten, wird mit LeSS wohl nicht glücklich werden. Diese Ansätze zerstören die Prinzipien von empirischer Prozesskontrolle und das Gefühl, Hoheit über die Prozesse und Praktiken zu haben.

Ein weniger definierter Prozess führt zu mehr Lernen. More with less (mehr durch weniger).

Inhalt Kapitel 2

»LeSS«

Scrum mit einem Team

LeSS

  Vorgeschichte

  Experimente, Wegweiser, Regeln und Prinzipien

  LeSS-Prinzipien

  Zwei Frameworks: LeSS & LeSS Huge

LeSS-Framework

  LeSS-Framework – Zusammenfassung

  LeSS-Geschichten

  LeSS-Geschichte: Der Ablauf von Teams

  LeSS-Geschichte: Der Fluss von Einträgen

LeSS-Huge-Framework

  Requirement Areas

  Area Product Owner

  Area-Feature-Teams

  LeSS-Huge-Framework – Zusammenfassung

  LeSS-Huge-Geschichten

  LeSS-Huge-Geschichte: Eine neue Requirement Area

  Standortübergreifende Teams: Begriffe und Tipps

  LeSS-Huge-Geschichte: Standortübergreifende Teams

Ausblick

Eine große Story Map während des initialen Product Backlog Refinement in LeSS

2 LeSS

Es gibt zwei Möglichkeiten für die Umsetzung eines [Designs]: Eine Möglichkeit ist es, die Umsetzung so einfach zu gestalten, dass es offensichtlich keine Mängel gibt, die andere Möglichkeit besteht darin, es so kompliziert zu machen, dass es keine offensichtlichen Mängel gibt.

C.A.R. Hoare

Scrum mit einem Team

Scrum ist ein Framework zur Entwicklung mittels empirischer Prozesskontrolle, in dem ein cross-funktionales, selbstgeführtes Team ein Produkt iterativ-inkrementell entwickelt.1 In jedem zeitlich begrenzten (Timebox) Sprint wird ein potenziell auslieferbares Produktinkrement erstellt und idealerweise ausgeliefert. Ein Product Owner (ein einziger!) ist verantwortlich dafür, den Wert des Produkts zu maximieren, die Einträge im Product Backlog zu priorisieren und basierend auf konstantem Feedback und Lernen adaptiv zu entscheiden, was das Ziel eines jeden Sprints ist. Ein kleines Team ist gemeinsam dafür verantwortlich, das Sprint-Ziel zu liefern; es gibt hier keine limitierenden einzelnen Spezialistenrollen. Ein Scrum Master vermittelt, warum Scrum eingesetzt wird und wie man wertvolle Arbeit damit erzielen kann. Er coacht den Product Owner, das Team und die Organisation, wie man Scrum anwenden kann, und agiert als Spiegel. Es gibt keinen Projektleiter oder Teamleiter.

Empirische Prozesskontrolle braucht möglichst vollständige Transparenz, die durch die kurzen Entwicklungszyklen entsteht und die Begutachtung der auslieferbaren Produktinkremente. Es wird Wert gelegt auf kontinuierliches Lernen, Inspektion und Adaption hinsichtlich des Produkts und der Art und Weise, wie es erstellt worden ist. Scrum basiert auf dem Verständnis, dass die Entwicklung zu komplex und dynamisch ist für detaillierte, schablonenhafte Prozesskochrezepte, die eher dem Infragestellen, dem Engagement und der Verbesserung im Weg stehen.

Im Scrum Guide und dem Scrum Primer liegt die Betonung auf einem Team; der Fokus liegt nicht auf vielen Teams, die zusammen an einem Produkt arbeiten. Und das führt natürlich dazu, dass man über Large-Scale Scrum, also Scrum im Großen, nachdenkt.

LeSS

LeSS ist Scrum, angewandt auf viele Teams, die gemeinsam an einem Produkt arbeiten.

Siehe Kapitel

Einführung, S. 61

LeSS ist Scrum – Large Scale Scrum (LeSS)2 ist kein neues und verbessertes Scrum. Und es ist nicht Scrum auf unterer Ebene für jedes Team mit etwas anderem oben draufgepackt. Es geht eher darum, herauszufinden, wie man die Prinzipien, den Zweck, die Elemente und die Eleganz von Scrum in einem skalierten Kontext anwendet, und das so einfach wie möglich. Genau wie Scrum und andere, wirklich agile Frameworks ist LeSS bewusst eine »eher unvollständige Methode«, um große Auswirkungen zu erzielen.

Skaliertes Scrum ist kein spezielles Skalierungsframework, das zufälligerweise Scrum nur auf Teamebene enthält. Echtes skaliertes Scrum ist Scrum skaliert.

Siehe Kapitel

Organisiere nach Kundennutzen, S. 87

... angewandt auf viele Teams

Cross-funktionale, komponentenübergreifende, »Full-Stack«-Feature-Teams von drei bis neun Personen, die auf Lernen fokussiert sind und alles machen – von UX über Code bis hin zu Videos –, um Einträge komplett fertigzustellen und ein auslieferbares Produkt zu erzeugen.

Siehe Kapitel

Koordination & Integration, S. 309

... die zusammenarbeiten

Die Teams arbeiten zusammen, da sie ein gemeinsames Ziel haben: ein gemeinsames, auslieferbares Produkt am Ende eines gemeinsamen Sprints auszuliefern. Und jedes Team kümmert sich darum, da sie Feature-Teams sind, die verantwortlich für das Ganze sind, nicht nur für einen Teil.

Siehe Kapitel

Produkt, S. 169

... an einem Produkt

Was für ein Produkt? Eine umfassende, komplette, von Anfang bis Ende gedachte kundenzentrierte Lösung, die von echten Kunden benutzt wird. Ein Produkt ist keine Komponente, Plattform, Schicht oder Bibliothek.

Vorgeschichte

2002, als Craig Agile & Iterative Development geschrieben hat, haben viele geglaubt, dass agile Entwicklung nur für kleine Teams gedacht war. Wie auch immer, wir beide (Craig und Bas) haben angefangen, uns dafür zu interessieren, wie Scrum in großen, verteilten und Offshore-Entwicklungen angewandt werden kann – und wir erhielten auch immer mehr Anfragen hierzu. So kam es, dass wir uns 2005 zusammengetan haben, um mit Kunden daran zu arbeiten, Scrum zu skalieren. Heute sind beide LeSS-Frameworks (LeSS und LeSS Huge) in großen Gruppen weltweit in unterschiedlichen Domänen eingeführt worden:

Telekommunikationsequipment – Ericsson & Nokia Networks3

Investment- und Handelsbanken – UBS

Handelssysteme – ION Trading

Marketingplattformen und Markenanalyse – Vendasta

Videokonferenzsysteme – Cisco

Onlinespiele (Wetten) – bwin.party

Offshore Outsourcing – Valtech India4

Was ist in Bezug auf groß ein typischer Fall einer LeSS-Einführung? Vielleicht fünf Teams an einem oder zwei Standorten. Wir waren in Einführungen von solcher Größenordnung involviert, in solche mit ein paar Hundert Leuten bis hin zu einem LeSS-Huge-Fall von weit über tausend Personen, viel zu vielen Entwicklungsstandorten, vieler Zehnmillionen Zeilen C++-Code mit kundenspezifischer Hardware.

Weitere Informationen zu LeSS

Um Menschen bei ihrer Weiterentwicklung zu unterstützen, haben wir, basierend auf unseren Erfahrungen mit Kunden, 2008 und 2010 zwei Bücher über die Skalierung von agiler Entwicklung mit dem LeSS-Framework veröffentlicht:

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum – erklärt das Denken, die Führung und Veränderungen am organisatorischen Design.

Practices for Scaling Lean & Agile Development: Large, Multi-site & Offshore Product Development with Large-Scale Scrum – lässt teilhaben an Hunderten konkreten Experimenten für LeSS, basie-rend auf unserer Erfahrung mit Kunden; Experimente im Produkt-management, Architektur, Planung, verteilte Umgebungen, Offshore, Verträge und mehr.

Dieses Buch – Large-Scale Scrum: Scrum erfolgreich skalieren mit LeSS5 – ist das dritte in der LeSS-Serie, ein Vorgänger und Grundlagenbuch. Dieses Buch fasst zusammen, erklärt und hebt hervor, was am wichtigsten ist.

Neben diesem Buch findet man online auf http://less.works weitere Quellen zum Lernen (inklusive Buchkapitel, Artikel und Videos), Kurse und Coaching.

Experimente, Wegweiser, Regeln und Prinzipien

In den ersten beiden LeSS-Büchern wurde bereits hervorgehoben, dass es Dinge wie »Best Practices« in der Produktentwicklung nicht gibt. Es gibt nur Praktiken, die in einem bestimmten Kontext passend sind.

Praktiken sind situativ. Fröhlich zu behaupten, sie seien das »Beste«, trennt sie von der Motivation und dem Kontext, die sie jedoch erst zu dem machen, was sie sind. Ohne das werden sie zu Ritualen. Und sogenannte »Best Practices« hervorzuheben, tötet eine Kultur des Lernens, des Infragestellens, des Engagements und der kontinuierlichen Verbesserung. Warum würden Menschen das Beste anfechten?

Daher haben die früheren LeSS-Bücher die Leser an Experimenten teilhaben lassen, die wir und unsere Kunden ausprobiert haben. Wir bestärkten – und bestärken nach wir vor – diese Geisteshaltung. Allerdings beobachteten wir mit der Zeit auch zwei Probleme der Nur-Experimente-Geisteshaltung:

Unerfahrene Gruppen treffen ungeschickte Entscheidungen zu ihrem Nachteil und führen LeSS in einer Art und Weise ein, für die LeSS nicht gedacht war, mit offensichtlichen Problemen. Zum Beispiel gibt es Gruppen, die Requirement Areas mit nur einem Team erstellt haben. Autsch!

Unerfahrene Gruppen fragen: »Wo fangen wir an? Was ist das Wichtigste?« Verständlicherweise können sie die wesentlichen Grundlagen nicht sehen.

Aufgrund dieses Feedbacks haben wir nachgedacht und sind noch mal zum Shu-Ha-Ri-Modell des Lernens zurückgekommen: Shu – folge den Regeln, um die Grundlagen zu erlernen. Ha – breche die Regeln, um den Kontext zu erkunden. Ri – meisterhaftes Können und finde deinen eigenen Weg. In einer LeSS-Einführung auf Shu-Ebene sind nur wenige Regeln nötig für ein gerade mal ausreichendes Framework, um empirische Prozesskontrolle und einen ganzheitlichen Produktfokus anzukurbeln.6 Diese Regeln definieren die beiden LeSS-Frameworks, die schon bald vorgestellt werden.

Um später darauf aufzubauen und um es einmal zusammenzufassen, sind nachfolgend die Bestandteile von LeSS aufgeführt:

Regeln

Ein paar wenige Regeln genügen, um loszulegen und um das Fundament zu schaffen. Sie definieren die wesentlichen Elemente des LeSS-Frameworks, die vorhanden sein sollten, um empirische Prozesskontrolle und einen ganzheitlichen Produktfokus zu unterstützen, beispielsweise führe in jedem Sprint eine Gesamtretrospektive durch.

Wegweiser

Ein angemessener Satz an Wegweisern hilft dabei, die Regeln effektiv einzuführen, und gilt für eine Untermenge von Experimenten, die es wert sind, ausprobiert zu werden, da sie auf jahrelanger Erfahrung mit LeSS basieren. Wegweiser enthalten Tipps. In der Regel sind sie hilfreich und ein Bereich für kontinuierliche Verbesserung, beispielsweise die Drei Einführungsprinzipien.

Experimente

Viele Experimente sind sehr situativ und sind es nicht unbedingt wert, ausprobiert zu werden, beispielsweise der Versuch, bei der Entwicklung von multilingualen Anwendungen den Übersetzer im Scrum-Team zu verorten. Dieser Versuch könnte sich im Verhältnis Kosten zu Nutzen als eher nicht praktikabel herausstellen. Doch es gilt: Probieren geht über Studieren!

Prinzipien

Im Mittelpunkt steht ein Satz von Prinzipien – herausgezogen aus der Erfahrung mit LeSS-Einführungen –, die die Regeln, Wegweiser und Experimente prägen, beispielsweise ganzheitlicher Produktfokus.

Die LeSS-Wegweiser und Experimente sind optional. Die Wegweiser werden vermutlich hilfreich sein und wir empfehlen, diese auszuprobieren. Solche, die nicht passen oder die weitere Verbesserung eher einschränken, können Sie übergehen oder weglassen.

Ein guter Weg, LeSS zu betrachten, ist im LeSS-Gesamtbild visualisiert:

Das LeSS-Gesamtbild gibt den Weg vor, wie wir LeSS einführen:

LeSS-Prinzipien – kommen als Nächstes

LeSS-Frameworks (definiert durch die Regeln) – im Rest des Kapitels

LeSS-Wegweiser – in den nachfolgenden Kapiteln dieses Buches

LeSS-Experimente – stehen schon mit den ersten beiden LeSS-Büchern zur Verfügung

LeSS-Prinzipien

Die LeSS-Regeln definieren das LeSS-Framework. Diese Regeln sind jedoch minimalistisch und beantworten nicht die Frage, wie LeSS in einem spezifischen Kontext angewendet wird. Die LeSS-Prinzipien lie-fern die Basis für solche Entscheidungen.

Large-Scale Scrum ist Scrum

Es ist kein neues und verbessertes Scrum. Viel eher geht es in LeSS darum, herauszufinden, wie die Prinzipien, Regeln, Elemente und der Zweck von Scrum in einem großen, skalierten Kontext angewendet werden können, und zwar so einfach wie möglich.

Transparenz

Basiert auf greifbaren »fertigen« Einträgen, kurzen Zyklen, Zusammenarbeit, gemeinsamen Definitionen und dem Vertreiben von Angst am Arbeitsplatz.

More with less (mehr durch weniger)

Wir wollen nicht noch mehr Regeln aufstellen, da mehr Rollen zu weniger Verantwortlichkeit der Teams führen. Wir wollen nicht noch mehr Artefakte, da mehr Artefakte zu einer größeren Distanz zwischen Teams und Kunden führen. Wir wollen nicht noch mehr Prozess, da dies zu weniger Lernen und Teamhoheit über den Prozess führt. Statt dessen wollen wir mehr verantwortliche Teams durch weniger (LeSS-) Regeln. Wir wollen mehr kundenorientierte Teams, die sinnvolle Produkte bauen, indem sie weniger Artefakte haben. Wir wollen mehr Hoheit der Teams über den Prozess und mehr sinnhafte Arbeit durch einen weniger definierten Prozess. Wir wollen mehr durch weniger – »More with LeSS«.

Ganzheitlicher Produktfokus

Ein Product Backlog, ein Product Owner, ein auslieferbares Produkt, ein Sprint – egal, ob drei Teams oder 33 Teams. Kunden wollen wertvolle Funktionalität in einem zusammenhängenden Produkt, keine technischen Komponenten in einzelnen Teilen.

Kundenzentriert

Die Konzentration liegt darauf, die wirklichen Kundenprobleme zu verstehen und zu lösen. Identifizieren Sie Wert und Nutzlosigkeit aus Sicht des bezahlenden Kunden. Reduzieren Sie die Wartezeit aus seiner Perspektive. Erhöhen und verstärken Sie Feedbackschleifen mit echten Kunden. Jeder muss verstehen, wie sich seine tägliche Arbeit direkt auf den zahlenden Kunden auswirkt und wie dieser davon profitiert.

Kontinuierliche Verbesserung in Richtung Perfektion

Hier ist ein Perfektionsziel: Erstellen und liefern Sie ein Produkt möglichst jederzeit ohne zusätzliche Kosten und Fehler, das Kunden erfreut, zur Verbesserung der Umwelt beiträgt und das Leben lebenswerter macht. Seien Sie immer bescheiden und führen Sie radikale Verbesserungsexperimente durch, bis dieses Ziel erreicht ist.

Lean Thinking

Bauen Sie ein organisatorisches System auf, dessen Fundament aus Managern als Lehrer besteht, die Lean Thinking anwenden und vermitteln, die führen, um zu verbessern, die »Stop & Fix« fördern und die »Go & See«7 praktizieren. Fügen Sie die beiden Säulen, Respekt für den Menschen und Geisteshaltung hin zu einer Verbesserung durch kontinuierliches Infragestellen des Status quo, hinzu – alles zur Erreichung der Perfektion.

Systemisches Denken

Betrachten, verstehen und optimieren Sie das gesamte System8 (und nicht einzelne Teile davon) und verwenden Sie die Systemmodellie-rung, um Systemdynamiken zu erforschen. Vermeiden Sie lokale Teiloptimierungen durch Konzentration auf die Effizienz oder Produktivität von einzelnen Individuen oder Teams. Kunden interessieren sich für die Dauer und den Fluss des gesamten Zyklus »vom Konzept zu Cash«, nicht für individuelle Schritte, und lokale Optimierungen führen meist zur einer Verschlechterung des Gesamten.

Empirische Prozesskontrolle

Das bedeutet kontinuierliches Inspizieren und Adaptieren des Produkts, der Prozesse, der Verhaltensweisen, des organisatorischen Designs und der Praktiken, sich in situativ angemessenen Wegen zu entwickeln. Tun Sie dies, statt einem vorgeschriebenen Satz sogenannter Best Practices zu folgen, die den Kontext ignorieren, zu einem ritualisierten Befolgen führen, Veränderungen und Lernen behindern und den Sinn der Menschen für Engagement und Eigentum zermalmen.

Warteschlangentheorie

Verstehen Sie, wie Systeme mit Warteschlagen sich in einem Forschungs& Entwicklungsumfeld verhalten, und setzen Sie diese Erkenntnisse ein, um die Größen von Warteschlangen, Work-in-Progress(WIP)-Limitierungen, Multitasking, Arbeitspakete und Varianz zu managen.

Zwei Frameworks: LeSS & LeSS Huge

Large-Scale Scrum hat zwei Frameworks:

LeSS

zwei bis acht Teams

LeSS Huge

mehr als acht Teams

Das Wort LeSS bedeutet zweierlei: Es meint sowohl Large-Scale Scrum im Allgemeinen als auch das kleinere LeSS-Framework.

Die magische Zahl Acht

Eigentlich ist die Acht keine magische Zahl, und wenn Ihre Gruppe das kleinere LeSS-Framework mit mehr als acht Teams erfolgreich anwenden kann, wunderbar! Aber das haben wir nicht erlebt ... noch nicht. Diese Obergrenze hat sich einfach nur durch empirische Beobachtung ergeben. Und in einigen Fällen, z.B. unterschiedlich komplexen Zielen in verteilten Umgebungen mit unerfahrenen Teams, die jeweils nur ihre eigene Sprache sprechen, könnte es sein, dass diese Grenze bei weniger als acht liegt.

Es gibt auf jeden Fall einen Zeitpunkt,

an dem ein einziger Product Owner nicht mehr länger den Überblick über das gesamte Produkt erfassen kann,

der Product Owner nicht mehr den Ausgleich zwischen externem und internem Fokus schaffen kann und

das Product Backlog so groß ist, dass es für eine Person schwierig wird, damit zu arbeiten.

Trifft die Gruppe auf diesen Wendepunkt, könnte es Zeit werden für den Wechsel vom kleineren LeSS-Framework zum LeSS-Huge-Framework. Auf der anderen Seite schlagen wir vor, erst einmal zu versu-chen, besser, kleiner und einfacher zu werden, bevor man größer wird.

Gemeinsamkeiten beider Frameworks

Das LeSS- und das LeSS-Huge-Framework weisen gemeinsame Elemente auf:

Ein Product Owner und ein Product Backlog

Ein gemeinsamer Sprint über alle Teams

Ein auslieferbares Produktinkrement

Die folgenden zwei Abschnitte dieses Kapitels gehen mehr ins Detail der beiden Frameworks. Zunächst wird das kleinere LeSS-Framework erläutert, anschließend folgt LeSS Huge auf Seite 39.

LeSS-Framework

LeSS-Framework – Zusammenfassung

Das kleinere LeSS-Framework ist ausgelegt für einen (und nur für einen) Product Owner, dem das Produkt gehört und der ein Product Backlog verwaltet, an dem Teams in gemeinsamen Sprints daran arbeiten, das Gesamtprodukt zu verbessern. Die Elemente des LeSS-Frameworks sind ungefähr die gleichen wie bei Scrum mit einem Team:

Rollen

Ein Product Owner, zwei bis acht Teams, ein Scrum Master für ein bis drei Teams. Es ist entscheidend, dass diese Teams Feature-Teams sind – echte cross-funktionale, komponentenübergreifende »Full-Stack«-Teams, die zusammen an einer gemeinsamen Codebasis arbeiten, wo jedes Team alles macht, um fertige Einträge zu erstellen.

Artefakte

Ein potenziell auslieferbares Produktinkrement, ein Product Backlog und ein eigenes Sprint Backlog für jedes Team.

Events

Ein gemeinsamer Sprint für das gesamte Produkt. Dieser inkludiert alle Teams und endet in einem potenziell auslieferbaren Produktinkrement. Details hierzu kommen in den anstehenden Geschichten und in eigenen Kapiteln zur Sprache.

Regeln & Wegweiser

Regeln für ein gerade mal ausreichendes Skalierungsframework für empirische Prozesskontrolle und ganzheitlichen Produktfokus. Wegweiser könnten helfen.

LeSS-Geschichten

LeSS lernen

Ein Weg, etwas zu lernen, besteht darin, tiefgehende Erklärungen zu lesen, und Leser, die das bevorzugen, können problemlos alles bis zur Vorstellung des LeSS-Huge-Frameworks (S. 39) überspringen und von dort aus weiterlesen. Andere, die Geschichten mögen, können hier weitermachen.

Einfache Geschichten

Diese Geschichten handeln nicht von den Komplexitäten großer, skalierter Entwicklungen – von der Politik bis zur Priorisierung –, die wir durch Beratung erfahren. Wir widmen uns in späteren Kapiteln diesen Dingen. An dieser Stelle haben wir bewusst klare und einfache Geschichten ausgewählt, um nur die Grundlagen eines LeSS-Sprints vorzustellen. Wer auf der Suche nach einem aufregenden Dialog oder einem Drama ist, der sollte ein Lean-Buch lesen.

Regeln & Wegweiser

Bei den Geschichten wird Ihnen auffallen, dass die Randnotizen auf die dazugehörigen LeSS-Regeln und Wegweiser referenzieren, um für mehr Klarheit zu sorgen und Verbindungen herzustellen.

Zwei Perspektiven

Nachfolgend sind zwei zusammenhängende Geschichten mit zwei grundlegenden Perspektiven aufgeführt, um einige Abläufe einfacher vorzustellen:

Der Ablauf von Teams innerhalb eines LeSS-Sprints

Der Fluss von kundenzentrierten Einträgen (Features)

LeSS-Geschichte: Der Ablauf von Teams

Diese Geschichte konzentriert sich auf den Ablauf von Teams in einem Sprint und weniger auf den Fluss von Arbeitspaketen. In der Realität verbringt man den größten Teil der Zeit in einem Sprint mit entwicklungsbezogenen Aufgaben und weniger in Meetings. Wie auch immer, diese Geschichte betont die Meetings und die Interaktionen, da es das Ziel dieser Geschichte ist, zu verstehen, wie mehrere Teams in den LeSS-Events zusammenarbeiten und wie sie sich tagtäglich koordinieren.

Tipp

Wechsle die Stellvertreter in jedem Sprint.

Mark betritt den Raum, in dem sein Team (»Handel«) arbeitet, und sieht Mira9. »Guten Morgen!«, sagt sie, »nur zur Erinnerung: Wir sind die Stellvertreter unseres Teams in diesem Sprint und Sprint-Planung 1 beginnt in 10 Minuten.« »Richtig«, antwortet Mark, »Ich treffe dich gleich im großen Raum.«

Sprint-Planung 1

(Wegweiser: Sprint-Planung 1, S. 298)

Regel

Es gibt einen produktübergreifenden Sprint und nicht verschiedene Sprints für jedes Team.

Es ist Zeit für die gemeinsame Sprint-Planung 1. In einem großen Raum haben sich die zehn Stellvertreter von den fünf Teams aus dieser Produktgruppe verteilt. Alle arbeiten am Flagschiffprodukt zum Handel mit Anleihen und Derivaten. Sam, der Scrum Master der Teams »Handel« und »Marge«, ist ebenfalls anwesend. Er plant, das Event zu beobachten und ggf. zu coachen, sollte das nötig werden.

Früher, vor vielen Sprints war jedes Teammitglied aus allen Teams bei der Sprint-Planung 1 dabei. Das war zu dem damaligen Zeitpunkt auch wesentlich nützlicher, da die Gruppe nicht sehr gut darin gewesen war, Arbeitspakete aus dem Product Backlog klar und »fertig« zu bekommen oder überhaupt ein tieferes Wissen in den verschiedenen Teams entstehen zu lassen. In jenen Tagen wurde die Sprint-Planung 1 dazu verwendet, Antworten auf viele der wesentlichen Fragen zu lie-fern, die auch jeder hören musste. Die Sprint-Planung 1 wurde immer weiter verbessert, und verglichen mit damals wurde bis heute eine deutliche Verbesserung erzielt. Die Gruppen experimentieren mit dem Entsenden von wechselnden Stellvertretern, was dazu führte, dass die Sprint-Planung 1 ein einfaches und kurzes Meeting wurde, in dem nur ein paar unwesentliche Fragen geklärt werden, die immer mal wieder auftauchen. Sollte dieser neue Ansatz nicht so gut funktionieren, wird das mit Sicherheit in einer der Gesamtretrospektiven thematisiert werden, woraufhin dann ein neues Experiment zur Verbesserung der Sprint-Planung angegangen wird.

Regel

Die Sprint-Planung besteht aus zwei Teilen: Sprint-Planung 1 ist für alle Teams gemeinsam, wohingegen Sprint-Planung 2 typischerweise jedes Team für sich macht. Wenn man mehrere Teams hat, die an eng zusammenhängenden Dingen arbeiten, führt man mit diesen Teams eine gemeinsame Sprint-Planung 2 in einem gemeinsamen Raum durch.

Regel

An der Sprint-Planung 1 nehmen der Product Owner, die Teams oder deren Stellvertreter teil. Gemeinsam werden sie probeweise die Dinge auswählen, an denen jedes Team im kommenden Sprint arbeiten wird.

Paolo betritt den Raum und begrüßt alle mit einem »Hi!«. Er ist der Product Owner und der leitende Produktmanager.10 Paolo verteilt 22 Karten auf einem Tisch und sagt: »Hier sind die großen Themen: der Deutsche Markt, Auftragsverwaltung und ein paar regulatorische Berichte. Ich habe sie entsprechend meiner Priorisierung geordnet und ausgelegt. Ich denke, jeder hier versteht, warum die Prioritäten so sind, da wir das häufig genug in den Product Backlog Refinements diskutiert haben. Sollte jedoch etwas unklar sein, fragt bitte noch mal.«

Tipp

Teams wählen ihre Arbeitspakete selbst aus.

Mira und Mark gehen gemeinsam mit den anderen Stellvertretern um den Tisch herum und nehmen sich zwei Karten heraus, die mit Dingen zu tun haben, die den deutschen Anleihenmarkt betreffen. In den letzten beiden Sprints hat ihr Team diese Dinge durch Workshops zu Product Backlog Refinement (PBR) in Einzelteams im Detail geklärt.

Wegweiser

Multiteam-PBR, S. 273

Sie nehmen auch noch zwei weitere Karten, die mit der Auftragsverwaltung zu tun haben und die sowohl das Team »Handel« als auch das Team »Marge« relativ gut verstehen. Beide Teams haben in Multi-team-PBR-Workshops an diesen Einträgen zusammengearbeitet. Warum? Die Teams wollten so spät wie möglich in einer zukünftigen Sprint-Planung entscheiden, welches Team an welchem Eintrag arbeitet. Das erhöht die Agilität der Gruppen, einfach auf Veränderungen zu reagieren, und das tiefere Gesamtproduktwissen begünstigt selbstorganisierte Koordination.

Tipp

Treffe keine Vorentscheidungen, welches Team an welchen Einträgen arbeiten soll.

Eine Minute später überfliegt Mary von Team »Marge« die Karten eines anderen Teams und fragt deren Stellvertreter: »Würde es euch etwas ausmachen, wenn wir uns um diesen Bericht kümmern? Wir haben etwas sehr Ähnliches im letzten Sprint gemacht, und ich könnte wetten, dass wir das hier schnell fertig bekommen. Könnten wir das gegen diesen Eintrag hier für den deutschen Markt tauschen?« Sie stimmen zu.

Nach ein paar Minuten sind die Teams fertig mit der Auswahl und dem Tauschen gemäß ihren Interessen, Stärken und Vorlieben bezogen auf den Gruppenschwerpunkt.

Wegweiser

Fünf Scrum-Master-Werkzeuge, S. 153

Tipp

Verteile wichtige Dinge.

Sam (der Scrum Master) sagt: »Mir ist aufgefallen, dass Team ›Marge‹ die vier wichtigsten Einträge ausgewählt hat. Könnte das zu einem Problem werden?« Es folgt eine kurze Diskussion, in der die Gruppe realisiert, dass die Möglichkeit besteht, dass einer der vier Einträge nicht fertig werden könnte, wenn die Sachen für Team »Marge« nicht reibungslos laufen. Sie entscheiden sich, ein paar dieser hoch priorisierten Einträge über mehrere Teams zu verteilen (abhängig davon, welches Team welchen Eintrag kennt), was es deutlich wahrscheinlicher macht, dass alle wichtigsten Arbeiten auch fertiggestellt werden können.

Die Stellvertreter haben insgesamt 18 Karten ausgewählt. Die unwichtigsten vier Karten bleiben auf dem Tisch liegen. Paolo betrachtet die vier übriggebliebenen Karten, nimmt zwei davon in die Hand und meint: »Diese beiden sind ziemlich wichtig für mich in diesem Sprint. Vielleicht hätte ich ihnen zu Anfang eine höhere Priorität zukommen lassen sollen, was ich nicht habe, und nun würde ich gern meine Meinung ändern. Lasst uns einen Weg finden, diese beiden Karten mit zweien zu tauschen, die ihr schon ausgewählt habt. Und sollte ein Team Glück haben und vorzeitig fertig werden, kann es sich natürlich die liegengebliebenen Dinge ziehen.«

RegelDie Teams identifizieren

Möglichkeiten der Zusammenarbeit, und finale Fragen sind geklärt.

Nachdem das gelöst ist, sagt Paolo: »Okay, lasst uns ein wenig Zeit nehmen, um noch offene Fragen zu klären. Wie ihr wisst, konzentriere ich mich eher auf die Priorisierung und die meisten von euch kennen die Details dieser Einträge wesentlicher besser als ich, aber schauen wir mal, welche kleineren Punkte wir noch gemeinsam klären können.«

Tipp

Diskutiere abweichende Meinungen, um zu klären.

Gleichzeitig denken Mira, Mark und die anderen angestrengt darüber nach, welche Punkte noch zur Klärung für ihre Teams offen sind, und schreiben einige Fragen auf Flipchart-Papiere, die auf allen Wänden im Raum verteilt sind. Paolo geht von einem Bereich zum anderen und diskutiert mit den anderen. Alle verteilen sich und arbeiten mit. Nach ungefähr 30 Minuten sind alle Fragen, die zur Klärung anstanden, beantwortet.

Die Gruppe bildet stehenderweise einen Kreis, um alles zusammenzufassen. Niemand bringt Koordinationsthemen zur Sprache. Daraufhin bemerkt Sam: »Mir ist aufgefallen, dass die Teams ›Handel‹, ›Marge‹ und ›Nicht-Derivate‹ Einträge bearbeiten, die sehr stark miteinander zusammenhängen.« Mira sagt: »Hey, lasst unsere Teams ›Handel‹, ›Marge‹ und ›Nicht-Derivate‹ zu einer gemeinsamen Sprint-Planung 2 zusammenkommen. So haben wir die Gelegenheit, zusammenzuarbeiten.« Dem stimmen alle zu und das Meeting ist beendet.

Team- und Multiteam-Sprint-Planung 2

(Wegweiser: Multiteam-Sprint-Planung 2, S. 302)

Regel

Jedes Team hat sein eigenes Sprint Backlog.

Nach einer Pause gehen zwei der fünf Teams in ihr eigenes Sprint-Planung-2-Meeting (SP2), um ihre eigenen Sprint Backlogs zu erstellen und damit ihre Arbeit für den Sprint zusammenzustellen und zu planen.

Regel

Führe ein Multiteam-SP2 in einem gemeinsamen Raum durch, wenn die Teams an eng zusammenhängenden Einträgen arbeiten.

Im Gegensatz dazu gehen die Teams »Handel«, »Marge« und »Nicht-Derivate« gemeinsam zu einer Multiteam-Sprint-Planung 2 in einen großen Raum, da sie stark zusammenhängende Inhalte implementieren, die zuvor gemeinsam in einem Multiteam-PBR geklärt worden sind, und sie einen Mehrwert darin erkennen, eng zusammenzuarbeiten.

Tipp

Eine Sitzung für die ganze Gruppe für Design und gemeinsame Arbeit

Sie reden zusammen in einer 10-minütigen Sitzung, um durch die Identifizierung der gemeinsamen Arbeit (gemeinsamen Aufgaben) und der Designthemen den Weg für die nächsten Schritte zu bereiten. Dazu starten sie eine 30-Minuten-Timebox zum Thema Design und einigen sich darauf, möglichst viel zu visualisieren: mehr Skizzen auf dem Whiteboard und weniger Reden ohne Zeichnen. Während dieser Zeit entdecken die Teams noch mehr gemeinsame Arbeit und schreiben dies ebenfalls aufs Whiteboard.

Wegweiser

Keine Softwarewerkzeuge für das Sprint Backlog, S. 304

Dong! Nach 30 Minuten bleibt noch eine Menge ungeklärter Details bestehen, aber die Teams machen trotzdem weiter mit dem nächsten Schritt. Jedes Team geht in eine andere Ecke des Raumes und beginnt konzentriert mit seiner eigenen Sprint-Planung 2, in der mehr über Designthemen im Detail gesprochen wird und das Sprint Backlog mit Karten erstellt wird. Weitere Koordinierung wird durch eine fort-geschrittene Variante der Just-talk-Technik in LeSS adressiert: Just scream.

Wegweiser

Einfach reden, S. 311

Während des Gesprächs kommen die Teams zu dem Schluss, dass ein gründlicherer Multiteam-Design-Workshop nötig ist. Sie vereinbaren, sich im Laufe des Tages dazu noch einmal zu treffen.

Multiteam-Design-Workshop

(Wegweiser: Multiteam-Design-Workshop, S. 325)

Nach der Sprint-Planung und einer weiteren Pause gehen Mira und Mark vom Team »Handel« und ein paar Leute aus dem Team »Marge« und Team »Nicht-Derivate« in einen Multiteam-Design-Workshop mit einer Timebox von einer Stunde, um tiefer in ein gemeinsames und konsistentes Design für ihre Arbeit einzutauchen. Auf einem großen Whiteboard skizzieren sie ihre Überlegungen und unterhalten sich, um mehr Klarheit und Einigung hinsichtlich des Designansatzes der gemeinsamen technischen Aufgaben zu bekommen. Glücklicherweise haben die Ergebnisse keine ernsthaften Auswirkungen auf die bestehenden Sprint-Pläne. Allerdings fühlen sie sich mit ihrem Prozess nicht sehr wohl, da sie den Klärungsbedarf hinsichtlich solch großer Designfragen früher hätten feststellen können.

Entwicklungsaktivitäten, die die Koordinierung und kontinuierliche Auslieferung unterstützen

Wegweiser

Kommuniziere mittels Code, S. 316

Wegweiser

Integriere kontinuierlich, S. 317

Nach der Sprint-Planung tauchen die Teams in die Entwicklung ein mit dem Schwerpunkt, mittels Code zu kommunizieren. Alle Teams integrieren kontinuierlich. Die kontinuierliche Integration des ganzen Codes aller Teams sorgt für die Möglichkeit, zu kooperieren, indem überprüft wird, wer noch Änderungen an der Komponente vorgenommen hat, an der gearbeitet wurde. Das ist hilfreich, da die Gruppe das Integrieren als Weg benutzt, andere zu informieren, und als Unterstützung zur Koordination.

Regel

Bevorzuge dezentrale und informelle Koordination vor zentralisierter Koordination

Wegweiser

Einfach reden, S. 311

Beispielsweise zieht Mark, seines Zeichens Entwickler im Team »Handel«, früh am Morgen des zweiten Tages des Sprints die letzte Version lokal auf seinen Rechner und überfliegt schnell die letzten Änderungen, die im Zusammenhang mit der Komponente stehen, an der er gerade arbeitet. Er entdeckt dabei Änderungen, die mit Code zusammenhängen, den Maximilian vom Team »Marge« hinzugefügt hat. Mark weiß, dass Team »Marge« an etwas arbeitet, was sehr stark mit seiner Komponente zusammenhängt, sodass ihn die Änderungen von Maximilian nicht wirklich überraschen. Jetzt, da der Code im Versionskontrollsystem gelandet ist, besteht die Notwendigkeit zur Koordination, und es ist klar, wer mit wem reden muss. Daher macht sich Mark auf den Weg und trifft sich mit Team »Marge« am anderen Ende des Flurs. Sie unterhalten sich darüber, wie sie zusammenarbeiten wollen, damit sie von der Arbeit der anderen profitieren.

Für den Eintrag, den das Team »Handel« gerade entwickelt, tatsächlich aber auch für jeden Eintrag jedes anderen Teams, wurden automatisierte Akzeptanztests geschrieben, bevor man überhaupt mit dem Programmieren der Lösung begonnen hat. Dementsprechend integrieren sie ebenfalls die automatisierten Tests in Ergänzung zum kontinuierlichen Integrieren des Quellcodes. Diese Akzeptanztests lassen die Teammitglieder regelmäßig laufen und sobald ein Test fehlschlägt, wird den Teams signalisiert, dass Koordinationsbedarf besteht. Der Code sagt ihnen: »Hey! Es gibt da ein Problem! Ihr müsst miteinander reden und das lösen.«

RegelDas Perfektionsziel ist es, die Definition of Done dahingehend zu verbessern, dass nach jedem Sprint ein potenziell auslieferbares Produkt vorliegt (oder zumindest häufiger als zurzeit).

Ein weiterer, großer Vorteil, dass die Gruppe kontinuierlich integriert, automatisiert testet und jedes Mal, wenn der Build bricht, die Arbeit liegen lässt, um den Build zu fixen, ist natürlich auch, dass das Produkt mehr oder weniger kontinuierlich bereit ist, in Produktion zu gehen. Es gibt keine speziellen Integrations- oder Testteams, die für zusätzliche Verzögerungen, Übergaben und Komplexität sorgen würden.

Gesamtretrospektive

(Wegweiser: Gesamtretrospektive, S. 344)

Regel

Eine Gesamtretrospektive findet im Anschluss an die Retrospektiven der Teams statt, um team- und systemübergreifende Themen zu diskutieren und Experimente zur Verbesserung zu beschließen. Der Product Owner, die Scrum Master, Stellvertreter aus den Teams und Führungskräfte (wenn überhaupt) nehmen daran teil.

Am zweiten Tag im Sprint kommen Sam und die anderen Scrum Master, der Product Owner Paolo, ein Standortleiter und Stellvertreter der meisten Teams für eine Gesamtretrospektive zusammen, die auf 90 Minuten angesetzt ist und mit dem letzten Sprint im Zusammen-hang steht.

Warum führen sie die Gesamtretrospektive nicht durch, bevor der neue Sprint startet? Sie hätten es machen können, aber normalerweise endet ein Sprint an einem Freitag und ein neuer beginnt am Montag (im Gegensatz zu Sams Vorschlag, einen Mittwoch-Donnerstag-Über-gang zu versuchen). Und am letzten Freitag haben sie sowohl das Sprint-Review als auch die Retrospektiven auf Teamebene abgehalten. Anschließend hatten sie nicht mehr die Energie, am Ende des Tages noch eine fesselnde Gesamtretrospektive abzuhalten. Und so haben Sam und die anderen eine Gesamtretrospektive früh am Anfang des nächsten Sprints gewählt. Insgeheim denkt Sam nicht, dass diese Verzögerung eine gute Idee war – er hätte eher die Sprint-Planung ein wenig später nach dieser Retrospektive durchgeführt, aber er möchte, dass die Gruppe das selbst herausfindet.

Wegweiser

Verbessere das System, S. 346

Sie konzentrieren sich auf ein systemweites Thema und dessen Verbesserung: Wie laufen die Koordination, das Teilen von Informationen und das Lösen von Problemen mit der ganzen Gruppe während des Sprints? Bisher hat man Scrum-of-Scrum-Meetings ausprobiert und das fanden sie nicht sehr effektiv. Sam erklärt das Prinzip von Open Space und sie vereinbaren, das in diesem Sprint auszuprobieren.

Aktivitäten zur Koordination

(Siehe KapitelKoordination & Integration, S. 309)

Regel

Teamübergreifende Koordination wird von den Teams entschieden.

Wegweiser

Scouts, S. 332

Der vierte Tag zeigt eine Vielzahl von Ideen zur Koordination in LeSS:

In LeSS hält jedes Team ein Daily Scrum ab wie üblich. Um die Koordination zwischen den Teams »Handel« und »Marge« zu unterstützen, macht Mira sich auf den Weg zum Daily Scrum von Team »Marge«, um das Meeting als Scout zu beobachten. Anschließend kommt sie zurück und berichtet dem Team, was sie gelernt hat. Und jemand aus dem Team »Marge« macht das Gleiche.

Wegweiser

Open Space, S. 330

Wie in der Gesamtretrospektive beschlossen, halten die Gruppen ein 45-minütiges Open-Space-Meeting zur Koordination und zum Lernen ab, das mit Getränken und Snacks eröffnet wird. Sam agiert hier als Moderator, um den Gruppen beizubringen, wie man ein Open-Space-Meeting durchführt. Jeder ist herzlich eingeladen, aber die meisten Teams haben entschieden, nur ein paar Stellvertreter zu schicken. Mira und Mark vom Team »Handel« sind ebenfalls dabei. Gemeinsam planen sie, einen Open Space pro Woche zu versuchen.

Wegweiser

Communitys, S. 319

Die Test-Community, die die größte Menge an Teilnehmern aus den meisten Teams hat, kommt für eine halbe Stunde zusammen, um Marys Vorschlag bezüglich eines neuen Werkzeugs für automatisierte Akzeptanztests zu hören. Enthusiastisch stimmen sie zu und Mary schlägt vor, dass ihr Team »Marge« das Werkzeug im nächsten Sprint ausprobieren wird, da alle sehr interessiert daran sind, das Werkzeug kennenzulernen.

Tipp

Etabliere eine Architektur-Community

Mira ist Mitglied der Design/Architektur-Community. In diesem Sprint ist kein Design-Workshop hinsichtlich der Gesamtarchitektur nötig, aber sie möchte gern im kommenden Sprint einen halbtägigen Spike machen, um eine neue Technologie zu erkunden. Sie veröffentlicht ihre Idee auf dem Werkzeug, das die Community zur Kollaboration einsetzt, und schlägt vor, den Spike zusammen mittels Mob Programming durchzuführen, um ihr gemeinsames Lernen zu verstärken.

Tipp

Stoppe und behebe Fehler, wenn es Probleme gibt.

Tipp

Experten unterrichten andere.

Das Build-System scheint einen äußerst merkwürdigen Fehler zu haben. Zeit, die Arbeit zu stoppen und den Fehler zu beheben! In diesem Sprint ist Team »Handel« dafür verantwortlich, und das ist eine von Marks weiteren Spezialitäten. Daher meldet er sich freiwillig, den Fehler zu beheben, und fragt ein anderes Teammitglied, ob dieses mit ihm paarweise arbeiten möchte. So kann Mark seinem Kollegen helfen, mehr über das Build-System zu lernen.

Regel

Klärung findet idealerweise zwischen den Teams und den Nutzern und anderen Stakeholdern statt.

Tipp

Frühes Feedback

Später besuchen Mira und ein paar weitere Teammitglieder die Gruppe, die sich um Kundenbetreuung und Training kümmert und somit sehr eng mit den Anwendern zusammenarbeitet. Miras Team hat gerade sein erstes Product Backlog Item (PBI) fertiggestellt und will frühzeitiges Feedback von denen bekommen, die näher am Anwender dran sind. Einer der Trainer hat Zeit und spielt mit dem neuen Feature herum. Nach einer gewissen Zeit gehen die Mitglieder von Team »Handel« wieder mit ein paar Ideen, wie sie das Feature verbessern können, an die Arbeit zurück.

Wegweiser

Kommuniziere mittels

Code, S. 316

Wegweiser

Integriere kontinuierlich,

S. 317

Im weiteren Tagesverlauf arbeiten Mark und der Rest des Teams »Handel« an ihrem zweiten PBI. Mark hat gerade einen 10-minütigen TDD-Zyklus hinter sich gebracht und hat sauberen, stabilen Code nach einer minimalen Änderung vor sich. Und wieder einmal stellt Mark eine kleine Änderung unter Versionskontrolle in das zentrale, gemeinsame Repository ein (ganz oben im Hauptentwicklungszweig, dem Trunk). Das geschieht ungefähr alle 10 Minuten und so integrieren Marks Team und alle anderen auch kontinuierlich. Mark schaut hinüber zum großen, deutlich sichtbaren Rot-Grün-Monitor und sieht, wie das Build-System erfolgreich alle Tests durchläuft – nicht nur die des Teams, sondern die der gesamten Gruppe.

Gesamt-Product-Backlog-Refinement

(Wegweiser: Arten von Product Backlog Refinements, S. 269)

Regel

Führe Multiteam- und/oder ein Gesamt-PBR durch, um das gemeinsame Verständnis zu erhöhen, und nutze die Gelegenheit zur Koordination, wenn es eng zusammenhängende PBIs gibt oder das Bedürfnis nach breiterem Input oder Lernen besteht.

Tipp

Rotiere die Stellvertreter in jedem Sprint.

Wegweiser

Priorisierung über Klärung, S. 195

Am fünften Tag nehmen Mark und Mira zusammen mit Vertretern der anderen Teams und Paolo, dem Product Owner, an einem GesamtPBR-Workshop