Im Jahre 1960 parkte Philip Zimbardo ein in die Jahre gekommenes Auto im New Yorker Stadtteil Bronx. Er öffnete die Motorhaube, demontierte das Nummernschild und ging.
Bereits nach zehn Minuten begannen die New Yorker damit, das Auto auszuschlachten. Nach nur einem Tag waren alle verwertbaren Teile gestohlen. Darauf folgte die sinnlose Verwüstung des Autowracks.
Dann stellte er ein ähnlich präpariertes Auto in Palo Alto im Bundesstaat Kalifornien ab. Es geschah nichts. Ganz im Gegenteil: Ein besorgter Passant schloss sogar die offen stehende Motorhaube.
Der Psychologieprofessor Zimbardo schloss daraus, dass die Vorbeschädigungen eines Objekts Diebstahl und weiteren Vandalismus nach sich ziehen. Allerdings nur, wenn das soziale Umfeld bereits Schäden aufweist, was in verwahrlosten Teilen von Städten der Fall ist. Auf diesem Experiment fußt die Broken-Window-Theorie. Sie attestiert einen Zusammenhang zwischen dem Verfall von Stadtgebieten und Kriminalität.
Um diesem Phänomen entgegenzuwirken, wendet die Polizei in den USA die sogenannte Strategie der Null-Toleranz an. Dabei schreiten Polizisten bereits bei kleinen Ordnungsverstößen konsequent ein, um schlimmere Auswüchse zu verhindern.
Das Broken-Window-Syndrom gilt auch für Scrum!
Kleine Missverständnisse wuchern schnell zu ernsthaften Erkrankungen aus. Möchtest du dies verhindern, solltest du frühzeitig und konsequent handeln. Natürlich ist nicht jede kleine Regelabweichung gleich besorgniserregend. Allerdings gibt es drei Erkrankungen, die Grund zur Sorge bereiten.
Beginnen wir mit der ersten:
Scrum-Erkrankung 1: Die Entwickler verpflichten sich, das Sprint Backlog zu erledigen
Dann wird das Projektmanagement-Dreieck zum Qualitätsgrab.
Das Dreieck setzt sich aus drei Variablen zusammen, die die Qualität des Projekts bestimmen.
- Funktionsumfang: Er entspricht der Arbeit im Sprint Backlog.
- Zeit: Sie wird durch die Länge des Sprints bestimmt.
- Budget: die Kosten, welche für einen Sprint anfallen.
In Scrum sind die Zeit und das Budget eines Sprints festgelegt. Müssen sich die Entwickler nun auf einen festen Umfang im Sprint verpflichten, dann ist auch die letzte Seite des Dreiecks festgelegt. Insgesamt sind also alle Seiten des Projektmanagement-Dreiecks fest bestimmt.
Welche Auswirkung hat dies für die Arbeit des Scrum Teams?
Die Welt steht nicht still, nur weil das Scrum Team jetzt sprintet. Es geschehen unvorhergesehene Dinge. Es müssen Fehler im Produktivsystem behoben werden, die Arbeit benötigt mehr Zeit, als veranschlagt, oder es werden Teammitglieder krank. Da Umfang, Zeit und Budget fest vorgegeben sind, hat das Team keinen Spielraum, um auf diese Dinge zu reagieren. Sprints können nicht verlängert werden, kurzfristig mehr Entwickler zu beschäftigen ist nicht sinnvoll, und den Funktionsumfang zu reduzieren würde als Misserfolg gedeutet. Somit kann der Sprint nur noch erfolgreich abgeschlossen werden – also muss innerhalb der fest vorgegebenen Zeit mit der gleichen Anzahl von Entwicklern ein vorgegebener Funktionsumfang geliefert werden. Das kann nur funktionieren, wenn die Entwickler bei der Refaktorisierung des Codes, dem Pair-Programming, den automatisierten Tests und Code-Reviews sparen. An der Qualität zu sparen, ist der einzige Ausweg, der dem Team noch bleibt. Die Qualität ist die einzige verbleibende Variable, wenn Umfang, Zeit und Budget bereits vorher feststehen.
Das Dreieck des Projektmanagements wird zum Grab für die Qualität.
Da Qualität aber über die langfristigen Erfolge eines Produkts entscheidet, sollten sich Scrum Teams also niemals auf einen fest vorgegebenen Funktionsumfang festlegen lassen. Weder für die ganze Laufzeit des Projekts, Etappenziele oder Meilensteine noch für Sprints. Stattdessen verpflichten sich Scrum Teams, die Ziele des Teams zu verfolgen.
„Das Scrum Team committet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen.“ –Scrum Guide, 2020
Ich schreibe hier bewusst: „verpflichten sich Scrum Teams, die Ziele zu verfolgen“, und nicht: „verpflichten sich Scrum Teams, die Ziele zu erreichen“. Wenn der Scrum Guide von Commitment spricht, dann bezieht es sich hierbei auf die Leistungsbereitschaft und die Hingabe und nicht auf das tatsächliche Endergebnis. Gunther Verheyen, einer der weltweit anerkanntesten Scrum Trainer, erklärt die Verwendung des Worts „Commitment“ so: „Wenn ein Fußballtrainer nach einem verlorenen Spiel sagt: ‚Meinen Spielern ist in Bezug auf ihr Commitment nichts vorzuwerfen.’ Dann sprechen wir über Commitment, wie es im Scrum Guide zu verstehen ist.“
Nur die Verpflichtung, die Ziele des Scrum Teams zu verfolgen, garantiert dem Scrum Team die nötige Flexibilität, qualitative Arbeit zu leisten, auch wenn unvorhergesehene Dinge passieren.
Scrum-Erkrankung 2: Es gibt kein Produkt-Ziel
Wozu entwickeln Teams eine neue Version eines Produkts?
Der Scrum Guide gibt hier die Antwort:
„Ein Increment ist ein konkreter Schritt in Richtung des Produkt‐Ziels.“
Scrum Teams entwickeln somit neue Versionen, um einem Ziel des Produkts näherzukommen. Dieses Ziel beschreibt einen zukünftigen Zustand des Produkts. Ein Beispiel für ein solches Produkt-Ziel ist: „35 % der Besucher unserer Webseite registrieren sich für den kostenpflichtigen Service.“ Dieses Ziel zeigt dem Scrum Team eine Richtung auf, in welche sich das Produkt verändern soll. Das Produkt-Ziel ist noch mehr: Es dient als Maß für den Fortschritt. Denn es ist doch so, dass erst die Kombination aus Produkt-Ziel und neuer Produktversion den Fortschritt sichtbar macht.
Woran wird Fortschritt festgemacht, wenn ein solches Ziel nun fehlt?
Meistens an der Anzahl der erledigten User Stories, der Menge der Story Points pro Sprint oder der Anzahl der gelieferten Produktversionen im Quartal. Diese Metriken stellen alle Maße für die Entwicklungsgeschwindigkeit des Scrum Teams dar. Du kennst diese Metriken bestimmt unter dem Begriff „Velocity“. Das Problem mit der Velocity ist: Wenn sie stabil ist, symbolisiert sie keinen Fortschritt. Um als Unternehmen erfolgreich zu sein, braucht es aber Fortschritt. Deshalb passiert das Unausweichliche: Die Velocity zu steigern, wird zum Ziel erklärt. Und eine höhere Entwicklungsgeschwindigkeit mit Unternehmensfortschritt gleichgesetzt. Das offenbart das eigentliche Problem: Wird eine Metrik zum Ziel, dann stellt sich die Frage, wann dieses Ziel erreicht ist. Oder anders gefragt: Wann ist schneller schnell genug?
Niemals.
Die Auswirkung dieser Denkweise ist katastrophal. Sind Unternehmen an diesem Punkt angekommen, haben sie ihre Scrum Teams erfolgreich zu Fabriken degradiert.
Welche Strategie verfolgen Unternehmen, die Fabriken betreiben?
Das Ziel einer Fabrik ist, die Produktionslinie voll auszulasten. Bei gleichbleibender Qualität muss die Stückzahl um jeden Preis erhöht werden, nur so kann das Unternehmen im Preiskampf mit der Konkurrenz und bei steigenden Rohstoffpreisen profitabel bleiben. Das Erfolgsgeheimnis hinter einer Fabrik lautet: „Effizienz“.
Aber wie erfolgsversprechend ist eine Strategie, die auf Effizienz setzt, heute noch?
Eine bereits im Jahr 1981 durchgeführte Umfrage unter 700 US-Unternehmen ergab, dass ein Drittel aller Gewinne in den 1980er Jahren auf neue Produkte entfallen würde, während es in den 1970er Jahren noch ein Fünftel war. Ich denke, es ist fair zu behaupten, dass sich dieser Trend im Zuge zunehmender Digitalisierung in den vergangenen Jahren nur noch weiter verstärkt hat.
Die Profitabilität von Unternehmen wird also immer weniger dadurch bestimmt, wie sie kostengünstig große Stückzahlen ihrer Produkte produzieren, sondern wie häufig sie neue Produkte auf den Markt bringen können. In Zukunft wird immer mehr die Innovationsfähigkeit eines Unternehmens darüber entscheiden, ob es sich am Markt von der Konkurrenz abheben kann und somit profitabel bleibt. Es entscheidet also nicht mehr die Effizienz, sondern die Effektivität. Innovative Unternehmen produzieren ihre Produkte nicht schneller, sondern sie produzieren bessere Produkte. Natürlich kann Innovation nicht geplant werden, aber die Möglichkeit, innovativ zu sein, kann geschaffen werden.
Und darum geht es bei Scrum.
Ein Scrum Team zeichnet sich gerade dadurch aus, dass Fachexperten aus unterschiedlichen Disziplinen zusammenkommen und innovativ und kreativ nach Wegen suchen, Probleme für die Kunden des Unternehmens zu lösen und die Ziele des Unternehmens zu erreichen. Das Produkt-Ziel bündelt die Kreativität der einzelnen Fachexperten, um effektiver zu arbeiten. Fehlt das Ziel, ist das Scrum Team kein Team, sondern nur eine Gruppe von Experten, die wie in einer Fabrik arbeiten.
Scrum-Erkrankung 3: Der Product Owner managt die Entwickler
Weder der Product Owner noch der Scrum Master haben eine Management-Position in Scrum.
Scrum begreift Management radikal anders!
Beginnen wir damit, dass Management keine Person ist, sondern eine Tätigkeit des Scrum Teams.
Wie gelingt das? Durch Aufteilung des Managements auf drei Einzelverantwortungen.
- Der Product Owner managt das Product Backlog.
- Der Scrum Master managt den Einsatz des Scrum Rahmenwerks.
- Die Entwickler managen die Arbeit im Sprint.
Wenn es in Scrum Teams keine Manager gibt, wie kann dann das Management eines Unternehmens Einfluss auf die Arbeit des Scrum Teams nehmen?
In „The new new product development game“ untersuchten Hirotaka Takeuchi and Ikujirō Nonaka zwischen 1976 und 1982 Unternehmen in Japan und in den Vereinigten Staaten, die einen radikal neuen Ansatz für das Management des Produktentwicklungsprozesses gewählt hatten. Ihre Studie betrachtete Produkte von Fuji Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox und Hewlett-Packard. Dabei fanden sie heraus, dass die Manager in diesen Unternehmen den Teams keine Projektkonzepte aushändigten oder Arbeit zuteilten. Stattdessen leiteten sie den Entwicklungsprozess ein, indem sie ein Ziel oder eine allgemeine strategische Richtung vorgaben. „Das Topmanagement von Fuji Xerox verlangte einen radikal anderen Kopierer und gab dem Projektteam für den FX-3500 zwei Jahre Zeit, um ein Gerät zu entwickeln, das zur Hälfte der Kosten der High-End-Produktlinie hergestellt werden konnte und trotzdem genauso leistungsfähig war.“
Der Scrum Guide, welcher seinen Namen der Arbeit von Hirotaka Takeuchi and Ikujirō Nonaka verdankt, greift diesen Ansatz auf. Die Vorgabe eines Ziels oder einer strategischen Richtung verbirgt sich im Produkt-Ziel. Es stellt somit eine Möglichkeit dar, wie das Management Einfluss auf die Arbeit eines Scrum Teams nehmen kann, ohne dabei das Selbstmanagement des Teams zu untergraben. Die drei Einzelverantwortungen werden also nicht eingeschränkt.
Neben Vorgaben von Zielen gibt es noch eine weitere Möglichkeit, wie das Management Einfluss auf das Team nehmen kann.
Manager können zum Bestandteil eines Scrum Teams werden.
Was meine ich damit? Die bittere Wahrheit ist doch, dass die wenigsten Scrum Teams einen Product Owner im Team haben. Mit Product Owner meine ich jemanden, auf den diese Aussage des Scrum Guides zutrifft:
„Damit der:die Product Owner:in Erfolg haben kann, muss die gesamte Organisation seine:ihre Entscheidungen respektieren.“
Die meisten Scrum Teams haben bestenfalls einen Stellvertreter des Product Owners und im schlimmsten Fall einen Gehilfen des Product Owners im Team. Ein einfacher Test, um zu entscheiden, ob der Product Onwer im Team ein Product Owner ist, lautet: „Kann die Person die Entwicklung des Produkts abbrechen und das Produkt in den Ruhestand schicken?“ Die wenigsten Personen, die sich Product Owner nennen, haben dieses Mandat. Gleichzeitig muss es immer jemanden im Unternehmen geben, der diese Entscheidung treffen kann.
Diese Person ist der wahre Product Owner.
Die Chancen stehen gut, dass er im höheren Management des Unternehmens sitzt. Diese Person kann einen großen Einfluss auf die Arbeit des Scrum Team nehmen und dessen Richtung bestimmen. Er kann dies tun, indem er selbst die Product-Owner-Verantwortung im Scrum Team ausfüllt oder jemanden anderen ermächtigt, diese Verantwortung zu übernehmen. Das meine ich, wenn ich sage, dass Manager zum Bestandteil eines Scrum Teams werden können.
Zusammenfassend managen weder Product Owner oder Scrum Master noch Manager die Arbeit im Scrum Team. Manager steuern die Scrum Teams im Unternehmen, indem sie durch die Vorgabe von Zielen und die strategische Ausrichtung das Team inspirieren oder durch die Vergabe der Product-Owner-Verantwortung lenken.
Wenn du mehr über die Rolle von Management in Scrum erfahren willst, dann empfehle ich dir mein „Professional Agile Leadership“-Training.
Wenn du für den Erfolg von Scrum die Verantwortung übernehmen willst, solltest du darauf achten, dass aus kleinen Missverständnissen keine ernsthaften Erkrankungen entstehen. Werden die Entwickler verpflichtet, das Sprint Backlog zu erledigen, gibt es keine Produkt-Ziele oder managt der Product Owner die Entwickler, dann ist es höchste Zeit, eine Behandlung der Erkrankung zu starten.