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 |
Scrum erfolgreich skalieren mit LeSS
Aus dem Englischen übersetzt von
Björn Jensen und Alexander Marquart
Craig Larman
Bas 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
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 Denning
Autor von The Leader’s Guide to Radical Management
27. April 2016
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.
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.
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.
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.
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.
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.
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.
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
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 I LeSS-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 II LeSS-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 III LeSS-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 IV More 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
Die billigsten, schnellsten und verlässlichsten Komponenten sind die, die gar nicht da sind.
Gordon Bell
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).
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
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 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 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.
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.
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.
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
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 mehr durch weniger – »More with LeSS«
