Das Scrum-Praxisbuch E-Book

J. J. Sutherland

• Herausgeber: Campus Verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2020

Seitenzahl: 351

Beschreibung

Mehr Scrum-Know-how geht nicht! Niemand könnte ein Praxisbuch schreiben, das anschaulicher erklärt, welche großen Herausforderungen Unternehmen mit Scrum bewältigen können, als die Erfinder der Methode selbst. Anhand zahlreicher Beispiele aus Branchen, die disruptiven Veränderungen ausgesetzt sind – wie Bosch, Saab oder der Ölförderer Schlumberger – verdeutlicht Sutherland die positive Kraft von Scrum. Denn diesen Unternehmen ist es gelungen, ihre Leistungsfähigkeit zu erhöhen, bessere Zahlen zu schreiben und ihre Zukunft selbst zu gestalten. Das Scrum-Praxisbuch ist die Master Class für Scrum-Praktiker aller Ebenen und eine unterhaltsame, gut geschriebene Lektüre noch dazu.

Leseprobe

J. J. SUTHERLAND

DAS SCRUM PRAXISBUCH

Campus Verlag

Frankfurt/New York

Über das Buch

Die englische Originalausgabe erschien 2019 bei Currency unter dem Titel The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future.

© 2019 by J. J. Sutherland and Scrum Inc. All rights reserved.

Vita

J. J. Sutherland ist CEO der Firma Scrum, Inc. und Sohn des Scrum-Erfinders Jeff Sutherland. Mit seinem Vater verfasste er »Die Scrum Revolution«. Bevor er das internationale Beratungs- und Trainingsgeschäft übernahm, war J. J. Sutherland preisgekrönter Journalist.

v* gewidmet

Für Deinen innigen Wunsch, dass dieses Buch Freude ausstrahlen soll

para exigentes nuestra estrella de poste del libro siempre ser esperanza

Für Deine Feststellung, dass Du einen Schriftsteller geheiratet hast

para caer en amor con me otra vez

Für Deine beharrliche Mahnung, immer das Positive zu sehen

Estoy muy bendecido y agradecido contigo en mi vida

Ohne Dich wäre dieses Buch nicht zu dem geworden, was es ist

Inhalt

Kapitel 1Wir haben die Wahl

Eine neue Denkweise

Was nach dem nächsten Ereignis geschieht

Eine Welt aus Legosteinen

Bedeutet dieses Wort wirklich das, was Sie glauben?

Das Mooresche Gesetz, auf Menschen angewendet

Ein Überlebensleitfaden

Kapitel 2Wie Sie Ihre Meinung ändern können, ohne dass es die Welt kostet

Wie Scrum funktioniert

Die Wirklichkeit ist in ständigem Fluss

Wer nicht wächst, geht unter

Veränderungen sind immer instabil

Kapitel 3Warum es so schwerfällt, sich zu entscheiden

Die Latenzzeit von Entscheidungen

Beziffern Sie Ihre Meetings

Überlegen Sie, welche Entscheidungen Sie wirklich treffen müssen

Das funktioniert hier niemals!

Am Rande des Chaos

Das Perfekte ist des Guten Feind

Chaos. Unsicherheit. Handeln.

Lassen Sie sich nicht von den Schatten täuschen

Kapitel 4Beschäftigt zu sein genügt nicht – auf das Fertigwerden kommt es an

Fakten sind oft störrisch

Hören Sie mit dem Anfangen auf und beginnen Sie mit dem Fertigstellen

Output versus Ergebnisse

Was »fertig« bedeutet und welche Rolle die Architektur dabei spielt

In der Klemme

Von der Bedeutung des Neinsagens

Auf das Fertigwerden kommt es an – nicht darauf, beschäftigt zu sein

Kapitel 5Menschen und Orte, die verrückt scheinen, sind es zumeist auch

Das Gehirn, ein morscher Palast

Die Verrücktheit des Wahnsinns

Niemand möchte für uns arbeiten

Ein Sturm, der für Klarheit sorgt

Regeln sollten um ihr Leben kämpfen

Dinge, die verrückt scheinen, sind es zumeist auch

Warum kann nicht immer Sturm herrschen?

Die wertende Stimme

Die zynische Stimme

Die furchtsame Stimme

Verbindungen entstehen durch Menschen

Kapitel 6Die Struktur ist der Kern der Unternehmenskultur

Menschlich bedingte Hindernisse

Von reinem Management zu echter Führung

Eine Führungskraft muss in erster Linie führen

Eine bedauerliche Eigenheit der menschlichen Psyche

Das Scrum-Wertesystem

Selbstverpflichtung (Commitment)

Fokussierung

Offenheit

Respekt

Mut

Halten Sie Werte in Ehren

Beschränken Sie Ihre bürokratischen Abläufe auf ein Mindestmaß

Die Innovation des »Wie«

Große Macht geht mit großer Verantwortung einher

Der rebellische Widerstand

Eine Kulturveränderung verschiebt die eigenen Grenzen

Kapitel 7Wie man es richtig macht

Teams, die früher fertig werden, beschleunigen schneller

Man kann informationsfreie Daten erhalten, aber keine Informationen ohne Daten

Entenbiss mit anschließendem Arztbesuch

Stabile Teams

Das Wetter von gestern (Yesterday’s weather)

Swarming

Unterbrechungspuffer (Interrupt buffer)

Gute Haushaltsführung

Notverfahren

Scrum the scrum

Die Zufriedenheitsmetrik

Wie Worte den Taten auf die Beine helfen

Kapitel 8Was man vermeiden sollte

Wie echte Führungskräfte handeln

Bleiben Sie nicht auf halbem Wege stehen

Das ist deren Aufgabe, nicht meine

Organisatorische Schulden

Übertriebene Schlankheit ist gefährlich

Sich den Tools unterwerfen

Auf die Umsetzung kommt es an

Cargo-Kult-Scrum

Vermeiden Sie ein Scrum à la carte

Lagern Sie keine Kompetenzen aus

Wenn Hindernisse gären

Konzentrieren Sie sich auf das, was funktioniert

Wohl und Wehe Ihres Vorhabens hängen von Ihren Product Ownern ab

Wissen, was zu tun ist und was nicht

Daten scheren sich nicht um Ihre Meinung

Kapitel 9Das Renaissance-Unternehmen

Die Geburt eines stillen Riesen

Wie man lernt, mit der Komplexität des Wachstums umzugehen

Die Reparatur der Reparatur

Eine veränderte Denkweise

Den Wandel leben

Scrum@Scale

Startschuss für die Renaissance

Der Scrum-Master-Zyklus

Das Executive-Action-Team

Der Product-Owner-Zyklus

Die Kunst des Möglichen

Kapitel 10Wie es sein könnte

Ein abgeleitetes Rahmenwerk

Eine bessere Welt

Liebe durch Nutzung vermehren

Dank

Anmerkungen

Kapitel 1Wir haben die Wahl

Zu den spannendsten Dingen im Leben gehört für mich die häufige Erkenntnis, dass die Welt tatsächlich ganz anders funktioniert, als ich es mir gedacht hatte. Die Einsicht, wie sehr ich mit meiner Einschätzung danebenlag, fasziniert mich. Sie bedeutet nämlich, dass man die Welt auf eine ganz neue, bessere, genauere und umfassendere Weise betrachten kann. Mir wurde das Glück zuteil, begreifen zu können, dass meine bisherigen Grundsätze – meine alten, fest verankerten Annahmen hinsichtlich der Funktionsweise von Dingen – falsch waren. Normalerweise stelle ich fest, dass bestimmte Abläufe in der Biologie, in den Wissenschaften, in der Geschäftswelt und im Leben viel komplizierter und verwickelter, subtiler und offener gegenüber Veränderungen sind, als ich es mir je hätte vorstellen können. Das ist ein unglaublich befreiendes Gefühl.

Es erinnert mich an die Entstehungsgeschichte des bahnbrechenden Buches Traité élémentaire de chimie (System der antiphlogistischen Chemie), das Antoine Lavoisier im Jahre 1789 veröffentlichte. Lavoisier erläutert darin, dass man mithilfe strenger Experimente grundlegende Prinzipien ableiten könne:

Es ist ein ausgemachter Grundsatz, dessen Allgemeinheit, sowohl in der Mathematik, als in allen übrigen Arten des menschlichen Wissens, anerkannt ist, daß wir, um uns zu belehren, nur von dem Bekannten zum Unbekannten fortschreiten können. … Durch eine Folge von Empfindungen bilden sich Beobachtungen, Analysen und successive Ideenverbindungen, davon ein aufmerksamer Beobachter, sogar bis auf einen gewissen Punkt, den Faden und die Verkettung auffinden kann; und sie allein sind es, welche das Ganze unseres Wissens ausmachen.1

Lavoisiers Theorie zufolge gibt es grundlegende chemische Elemente, die nicht aufgespalten werden können und die Bausteine jeder Materie bilden. Und so begann er, gründlich nach diesen Elementen zu suchen. Lavoisier ist der Wissenschaftler, der Sauerstoff, Wasserstoff und Kohlenstoff entdeckte und benannte; er erkannte die Rolle des Sauerstoffs bei Atmung und Verbrennung, und er zeigte, dass Wasser aus Wasserstoff und Sauerstoff besteht. Er revolutionierte das Gebiet der Chemie, indem er eine ganz neue Sprache erfand, um zu beschreiben, wie die Bestandteile unserer Wirklichkeit sich gegenseitig beeinflussen. Mit anderen Worten erklärte er auf eine ganz neue Art und Weise, wie die Welt funktioniert. Mithilfe der von ihm beschriebenen Grundprinzipien konnte er die Existenz weiterer Elemente prognostizieren, die zu seinen Lebzeiten noch gar nicht entdeckt waren.

Vor Lavoisier hatten Chemiker nur die Möglichkeit, jene chemischen Stoffe zu analysieren, die die Natur zufällig hinterlassen hatte. Lavoisier behauptete nun, dass man sich nicht auf die Elemente beschränken müsse, über die man praktischerweise gestolpert war. Warum nicht so lange experimentieren, bis man das gesamte Universum chemischer Verbindungen entschlüsselt hatte?

Seine Gedanken waren faszinierend, und die Veröffentlichung seines Buches erwies sich als eine der großen Wasserscheiden in der Geschichte der Wissenschaften. Vor Lavoisier hatten Wissenschaftler und Intellektuelle eine ganz bestimmte Vorstellung davon, wie die Welt gestrickt war. Nun erkannte man, dass sie ganz anders funktionierte. Die moderne Chemie war geboren. Sie ermöglichte einen völlig neuen Blick auf den Kosmos. Alle nur denkbaren Elemente unserer modernen Welt, von Ihren Hemdknöpfen über die Kälte in Ihrem Kühlschrank bis zur Druckertinte in diesem Buch oder zu den Chips, die Ihr Lesegerät steuern, existieren nur aufgrund dieser Entdeckung.

Ich finde es großartig, wenn so etwas geschieht – wenn eine neue Entdeckung unsere Wahrnehmung und unser Verständnis der Welt, in der wir leben, grundlegend verändert. Wenn aufgrund neuer Informationen oder Daten unser gesamtes Wissen plötzlich infrage gestellt wird. Wenn die Welt kurz zuvor noch in alten Bahnen verlief und wir heute auf einmal über Möglichkeiten verfügen, die wir uns am Vortag noch nicht einmal hätten ausmalen können.

Eine neue Denkweise

In den Jahren seit dem Erscheinen meines ersten Buches Die Scrum-Revolution, das ich gemeinsam mit meinem Vater verfasst habe, sind immer mehr Menschen zu der Erkenntnis gelangt, dass wir uns heute inmitten eines vergleichbaren Umbruchs innerhalb der Geschäftswelt befinden. Dort vollzieht sich derzeit eine Revolution, die den Wandel antreibt. Und wie durch Lavoisiers Arbeit schält sich dabei eine neue Welt heraus, für die althergebrachte Beschränkungen nicht mehr gelten. In meinen Gesprächen mit Unternehmen, CEOs und leitenden Managern verwende ich mittlerweile eine neue Redewendung, wonach Scrum die Kunst ist, unseren Möglichkeitsraum zu verändern.

Scrum wird gebraucht, weil wir rasche soziale, wirtschaftliche und politische Veränderungen durchleben, die wiederum durch die enorme Geschwindigkeit des technologischen Fortschritts angetrieben werden. Sicher haben Sie bereits vom sogenannten Mooreschen Gesetz gehört, das von Gordon Moore, dem Mitbegründer von Intel, geprägt wurde. 1965 veröffentlichte er einen Aufsatz mit dem launigen Titel »Cramming More Components on Integrated Circuits« (zu Deutsch »Wie man integrierte Schaltkreise mit weiteren Bauteilen vollstopft«). Was heute als Mooresches Gesetz bezeichnet wird, ist die Schlussfolgerung des Aufsatzes: Die Anzahl der Transistoren auf einem Chip werde sich alle zwei Jahre verdoppeln, also exponentiell wachsen. Und übrigens, der Preis für diese erhöhte Rechenleistung werde gleichzeitig um die Hälfte sinken.

Es fällt schwer, die Geschwindigkeit dieses Wandels zu begreifen, von der künftigen Entwicklung ganz zu schweigen. Um das Tempo zu veranschaulichen, mit dem sich die Veränderungen vollziehen, können wir auf ein altes französisches Kinderrätsel zurückgreifen. Angenommen, Sie stoßen auf einen wunderschönen Seerosenteich – vielleicht jenen in Giverny, den Monet in Dutzenden seiner Bilder porträtierte. Stellen Sie sich diesen Teich vor. Still ruhendes Wasser, auf dessen Oberfläche Seerosen treiben, vielleicht eine kleine Brücke, das Ganze eingerahmt vom Himmel und von den Bäumen, die sich im Teich spiegeln.

Nehmen wir nun an, die Anzahl der Seerosen im Teich würde sich täglich verdoppeln. Schon nach 30 Tagen würden die Blüten die Wasseroberfläche mit ihren Blättern vollständig bedecken. Ganz ohne eigene Schuld würden die Seerosen jedes andere Leben im Teich vernichten – Fische, Frösche, sogar andere Seerosenblüten. Aber es bleibt doch sicher noch Zeit, um den Teich zu retten? Schließlich sind die Seerosen wunderschön. Sollten Sie sich entscheiden zu warten, bis die Seerosen den halben Teich bedecken, wie viele Tage bleiben Ihnen dann noch, um den Teich zu retten?

Antwort: einer. Genau einer. Am neunundzwanzigsten Tag würden die Seerosen den halben Teich bedecken. Und einen Tag später die gesamte Oberfläche.

Eine weitere Illustration der Geschwindigkeit, die eine Verdoppelung der Transistoren und Rechenleistung verkörpert, ist das berühmte Beispiel der Weizenkörner auf einem Schachbrett, das auf das Jahr 1256 zurückgeht (was belegt, wie lange Menschen bereits über solche Fragen nachdenken). Würde man auf das erste Feld eines Schachbretts ein Weizenkorn legen und auf jedes weitere Feld jeweils die doppelte Anzahl an Weizenkörnern des vorherigen Feldes, dann hätte sich beim Erreichen des letzten Feldes die Zahl der Weizenkörner 63-mal verdoppelt. Auf diesem Feld lägen mehr als neun Trillionen (9 223 372 036 854 775 808) Weizenkörner. Das ist eine sehr, sehr große Zahl. Eine unvorstellbar große Zahl. Und genau in dieser Geschwindigkeit verändert sich unsere Welt. Die althergebrachten Arbeitsmethoden versagen, wenn sie mit sich rasch verändernden Problemen konfrontiert werden, die sie schlichtweg überfordern. Komplexität ist kein Ausnahmefall mehr; wir müssen täglich damit zurechtkommen.

Was nach dem nächsten Ereignis geschieht

Scrum ist ein Mechanismus, der es Einzelnen, einem Team oder einer Organisation ermöglicht, mit dieser Komplexität umzugehen. Mithilfe von Scrum können sie auf nicht prognostizierbare Veränderungen reagieren sowie flexibel und schnell durch Problemräume navigieren, die im ständigen Wandel begriffen sind. Das schiere Tempo, in dem sich heute Veränderungen vollziehen, verlangt nach einer neuen Arbeitsweise. Scrum stellt eine mögliche Antwort auf dieses Problem dar.

Doch um das wahre Potenzial von Scrum in Form drastischer Produktivitäts- und Wertschöpfungssteigerungen zu erschließen, bedarf es grundlegender Änderungen der betrieblichen Abläufe und der Unternehmensführung. Während einzelne Scrum-Teams durchaus in der Lage sind, beeindruckend schnell Ergebnisse zu liefern, kommt es darauf an, Scrum auf der Ebene des Gesamtunternehmens zu verankern. Althergebrachte Strukturen müssen sich ändern, dasselbe gilt für Anreizsysteme und das Leistungsmanagement, und Mitarbeiter sämtlicher Unternehmensfunktionen – auch wenn sie nicht selbst Teil eines Scrum-Teams sind – müssen lernen, mit solchen Teams zu interagieren, ihnen zuzuliefern, sie zu unterstützen und sie auf eine neue Art und Weise zu steuern.

Wenn Mitarbeiter herkömmlicher Unternehmen begreifen, wie umfassend der erforderliche Wandel ist, werfen sie bisweilen nur die Hände in die Luft. Unmöglich. Der Sprung ist einfach zu groß. In etablierten Unternehmen gibt es zu viel Bürokratie, zu viel Geschichte und zu viele genau festgeschriebene Abläufe. Wir können nicht einfach alles umwerfen, heißt es da von Managementseite, so funktioniert das hier einfach nicht. Und wenn dann etwas schiefgeht, beginnt rasch die Suche nach einem Sündenbock.

Dabei kommt es gar nicht darauf an, wer für einen Erfolg oder Misserfolg verantwortlich ist, wie das Geld ausgegeben wurde oder was im Einzelnen schiefgegangen ist. Entscheidend ist ausschließlich die Frage: Was geschieht nach dem nächsten Ereignis? Was passiert ist, ist passiert. Das gilt in der Geschäftswelt ebenso wie in der Politik oder in privaten Beziehungen. Wie aber soll die Zukunft aussehen? Wie kann man sich so aufstellen, dass man von den als notwendig erkannten Veränderungen profitiert? Wie gelingt es, ein Team, eine Abteilung oder ein Unternehmen nicht nur widerstandsfähig zu machen, sondern es vielmehr mit einem System auszustatten, das das Team mit jedem bearbeiteten Problem weiter stärkt? Wie lässt sich ein System entwickeln, das so robust ist, dass es Katastrophen nicht nur übersteht, sondern daran wächst, daraus lernt und immer schlagkräftiger wird?

Die besten Unternehmen lernen aus ihren Fehlern und Erfolgen und nutzen diese Lehren systematisch, um sich zu verbessern. Wenn meine Teams einen Fehlschlag an mich herantragen, sage ich gern: »Wunderbar. Nun wissen wir, was nicht funktioniert. Zeigt mir nächstes Mal einen interessanteren Fehler.«

Ihr Ziel muss es sein, das zu erschaffen, was ich als Renaissance-Unternehmen bezeichne – eine Organisation, die sich von den Fesseln der Vergangenheit, von überkommenen Betrachtungsweisen befreit hat und nun imstande ist, Dinge zu erschaffen, die noch vor wenigen Jahren außerhalb der Vorstellungskraft lagen. Wir brauchen ein auf Menschen anwendbares Mooresches Gesetz. Wie können wir selbst schneller, effizienter und produktiver werden? Und wie gelingt uns das in großem Maßstab?

Eine Welt aus Legosteinen

Begleiten Sie mich nach Schweden, der Heimat von Ikea, Stieg Larsson und der Popgruppe ABBA, der womöglich besten Fleischbällchen der Welt und der Mitternachtssonne. Auch Saab ist in Schweden zu Hause. Vermutlich kennen Sie Saab als Automobilhersteller, der keine Autos mehr produziert, doch die Fahrzeugherstellung war für das Unternehmen stets nur ein Nebengeschäft. Nur wenige wissen, dass Saab überwiegend Kampfflugzeuge baut.

Schon seit Jahrzehnten, genauer gesagt seit 1937, stellt Saab Kampfflieger her. Damals stand die Welt ganz offensichtlich vor einem Flächenbrand, und das mit keiner Partei und keinem Staat verbündete Schweden entschied sich, eine eigene Luftwaffe aufzubauen. Das Land verfolgte seit Ende des napoleonischen Zeitalters offiziell einen neutralen Kurs, ähnlich der Schweiz, und behielt diesen während des gesamten Zweiten Weltkriegs und des nachfolgenden Kalten Krieges bei. Doch die Tatsache, dass man zwischen der NATO auf der einen und der UdSSR auf der anderen Seite eingezwängt war, sorgte bei unseren Freunden im Norden durchaus für eine gewisse Unruhe.

Und so bauten die Schweden munter ihre Luftwaffe aus. 1950 kam der Saab 29 Tunnan auf den Markt, ein Kampfflugzeug, das sich mit den besten Konkurrenzmodellen weltweit messen konnte. Schweden stellte 55 einsatzfähige Geschwader zusammen, viele davon in Alarmbereitschaft und innerhalb von nur 60 Sekunden einsatzbereit. Mit der Zeit begann Schweden seine Flugzeuge an andere Länder wie Österreich, Brasilien, Südafrika und Thailand zu verkaufen.

Auf den Tunnan folgten der Lansen und der Draken und später, in den 1980er-Jahren, der Gripen A/B, gefolgt vom Gripen C/D. Doch dann gab es plötzlich ein Problem. Der Gripen war ein gutes Flugzeug und verkaufte sich recht ordentlich. Doch Saab und das schwedische Militär wollten es modernisieren: Es sollte leistungsstärker werden, eine höhere Reichweite und bessere Waffen erhalten. Und so entstand die Idee, den Gripen E zu entwickeln. Zunächst planten die Saab-Ingenieure, einfach rund 60 bestehende Gripen 39C zu modernisieren – schließlich sind Flugzeuge teuer und schwer zu bauen. Doch im Zuge der Verbesserung ihrer Modelle führten sie irgendwann Scrum ein – zunächst nur in ihrer Softwaregruppe, bald jedoch auch anderswo: im Design, in der technischen Planung, der Qualitätskontrolle und so weiter. Scrum@Scale ist eine modulare Organisationsstruktur, in der bereichsübergreifende Teams für eine rasche Wertschöpfung sorgen. Doch als sich Scrum im Unternehmen verbreitete, verfiel das Management von Saab auf eine neue, radikale Idee: Wie wäre es, wenn das Flugzeug die Organisationsstruktur des Unternehmens widerspiegelte?

Wir möchten ein Flugzeug bauen, das potenziell 50 Jahre lang einsatzfähig ist, betonte Saab. Wir wissen, dass sich die Technologie im Laufe der Jahrzehnte tief greifend verändern wird. Es ist sehr schwer, Flugzeuge aktueller Bauart zu modernisieren. Da hängt jedes Bauteil eng mit dem nächsten zusammen. Warum bauen wir nicht einen modularen Flieger, der sich leicht auseinandernehmen und wieder zusammensetzen lässt, vergleichbar dem Aufbau eines Scrum-Teams? Dann könnten wir laufend ganze Systeme modernisieren. Wir müssten nicht mehr auf ein umfassendes Modernisierungsvorhaben warten. Stattdessen könnten wir, wenn ein neues Radarsystem, ein neuer Computer oder ein neues Triebwerk entwickelt wird, einfach das alte herausnehmen und das neue anschließen, ohne den Rest des Flugzeugs anfassen zu müssen. Warum bauen wir also ein Kampfflugzeug nicht einfach so, als wäre es aus Legosteinen?

»Wir stellen uns ein Steckersystem vor«, bekundete Saab-Manager Jörgen Furuhjelm. »Wir bezeichnen das als intelligentes Kampfflugzeug. Schließlich wissen wir nicht, was unsere Kunden in einigen Jahren nachfragen werden.«

Vielleicht eine bessere Maschine? Kein Problem – sie kann einfach ausgetauscht werden. Ein verbesserter Radar? Schon erledigt. Raffiniertere Waffen? Geht in Ordnung. Die Philosophie von Saab ermöglicht dem Gripen, das schier Unmögliche zu bewältigen. Er kann unter extremen Witterungsbedingungen auf einer Straße landen. In weniger als zehn Minuten kann er betankt und mit neuen Waffen bestückt werden – dazu bedarf es nur sechs Menschen und keinerlei Werkzeugs. Bei den meisten anderen Kampffliegern dauert das zwei- bis dreimal so lange. Saab kann ein Triebwerk in nur einer Stunde austauschen. So leistungsfähig ist Modularität.

Gleichzeitig macht es Spaß, in diesem Unternehmen zu arbeiten. Bei schwedischen Studenten der Ingenieurswissenschaften steht Saab gleich hinter Google auf Platz zwei der beliebtesten Arbeitgeber. Und im Gegensatz zu den meisten Unternehmen weltweit, wo die Mitarbeiter in der Regel alles andere lieber täten, als morgens ihren Arbeitsplatz aufzusuchen, gehen Saab-Mitarbeiter gern zur Arbeit.

»Das Schlüsselwort lautet Engagement. Unsere Mitarbeiter haben das Gefühl, an einem wirklich coolen Projekt zu arbeiten. Sie lieben Flugzeuge. Und in den Teams ist dieses Engagement fast körperlich spürbar«, sagt Furuhjelm.

So wirkmächtig ist Scrum. Es verschafft Menschen den nötigen Freiraum, um schneller und produktiver zu arbeiten und dadurch mehr in kürzerer Zeit zu schaffen. Es ermöglicht Teams, ihrer Arbeit mit Hingabe und frei von Hindernissen nachzugehen. Als Saab sich auf Scrum einließ, stellte das Unternehmen fest, dass es eine schier unglaubliche Menge an menschlichem Potenzial freisetzen konnte, wenn es sich nur darauf konzentrierte, störende Elemente zu beseitigen.

Obwohl der Gripen E in nahezu jeder Hinsicht besser ist als sein Vorgängermodell – in Bezug auf Teile, Ausrüstung und vieles andere mehr –, sind die Kosten für seine Entwicklung, seine Herstellung und seinen Unterhalt im Vergleich zu jenem Modell gesunken. Mit rund 20 Milliarden Euro kann man 150 Gripen 40 Jahre lang in der Luft halten. Für nur 65 US-amerikanische Maschinen vom Typ F35 müsste man etwa das Doppelte aufwenden.

Und all das – der Aufbau eines hoch entwickelten Kampffliegers von Grund auf – gelang mithilfe von Scrum. Oft stoße ich bei meiner Arbeit mit Unternehmen auf Manager, die mir sagen: Wissen Sie, das Scrum-Rahmenwerk zielt ja auf die Entwicklung von Software. Was wir hier machen, ist viel zu komplex, um agil zu sein. In diesem Fall beginne ich üblicherweise, vom Gripen zu erzählen. »Ich bin mir ziemlich sicher«, entgegne ich dann, »dass das, was Sie herstellen oder bauen, nicht komplizierter als ein Kampfjet ist.«

Bedeutet dieses Wort wirklich das, was Sie glauben?

In den vergangenen Jahren ist Scrum, das oft unter der Bezeichnung »agile Methodik« firmiert, allgegenwärtig geworden. Nicht mehr allein Software- und Technologiefirmen, sondern auch große Konzerne setzen es in nahezu jedem Bereich ein. Unternehmen, die auf Bankgeschäfte, Fahrzeuge, medizinische Geräte, Biotech, Versicherungen, Gesundheitsdienstleistungen oder anderes spezialisiert sind, greifen auf Agilität zurück, um relevant zu bleiben. Blue-Chip-Unternehmen wie Bosch, Coca-Cola, USAA, Schlumberger, Fidelity und Lockheed Martin verwenden Scrum, um den Nutzen und die Qualität in der Geschwindigkeit bereitzustellen, die nach Ansicht ihrer Kunden heute unverzichtbar sind.

Ein Großteil dieser Entwicklung geht auf das zurück, was oft als digitale Transformationsprozesse bezeichnet wird. Demnach gehört die Zeit, in der eine Trennlinie zwischen einem Unternehmen und seiner IT bestand, endgültig der Vergangenheit an. Heute ist jedes Unternehmen ein Technologieunternehmen. Und Software beherrscht die Welt. In Ihrem Fahrzeug stecken mehr Codezeilen als in Windows. Verdammt, meine neue Waschmaschine will das WLAN-Passwort wissen.

Und so beschließen heute Firmen – oft nachdem ihr CEO einen TED-Talk verfolgt und von seinen Freunden oder einem Unternehmensberater von den Vorteilen agiler Prinzipien erfahren hat –, auf Biegen und Brechen agil zu werden.

An dieser Stelle sollte ich den Begriff agile Methodik und seine Beziehung zu Scrum erläutern. Scrum wurde 1993 erfunden und dann 1995 von seinen beiden Entwicklern Jeff Sutherland und Ken Schwaber formalisiert. Viele Menschen suchten Mitte der 1990er-Jahre in Usenet-Gruppen und auf Tagungen nach Möglichkeiten, Software zu entwickeln, ohne die erschreckend hohe Versagerquote in Kauf nehmen zu müssen, die in dieser Zeit immer häufiger anzutreffen war.

Im Jahre 2001 kamen 17 dieser Menschen in Snowbird, einem Skiort im US-Bundesstaat Utah, zusammen, darunter mein Vater Jeff Sutherland, Ken Schwaber und ein weiterer frühzeitiger Scrum-Anwender, Mike Beedle. Die 14 anderen Teilnehmer hatten unterschiedliche berufliche Hintergründe und methodische Herangehensweisen, doch sie erkannten, dass sie alle die gleichen Probleme auf sehr ähnliche, wenn auch nicht identische Art angingen.

Am ersten Tag stritten sie miteinander – so wurde es mir jedenfalls von einigen Teilnehmern berichtet. Es ging im Wesentlichen darum, eine Bezeichnung für das übergreifende Konzept zu finden, das sie erkennen konnten, aber nicht zu benennen wussten. Gegen Ende des Tages schlug Mike Beedle den Namen »Agile« vor. Alle hielten das für leichter vermittelbar als andere, ebenfalls erwogene Begriffe wie etwa »Leichtgewicht«. Also entschied man sich für »Agile«. Dann begann die Diskussion darüber, was dieser Begriff genau beinhaltete.

Am nächsten Tag ging der Streit weiter. Gut, es sollte also »Agile« heißen, aber was hieß das nun? Wie konnte man es beschreiben? Irgendwann beschlossen neun der Teilnehmer, eine Raucherpause einzulegen, während die anderen acht im Raum blieben. Einer von ihnen, Martin Fowler, schritt zum Whiteboard und sagte sinngemäß: Wäre es nicht eine Schande, wenn es uns in diesen zwei Tagen nicht gelänge, uns auf etwas zu einigen? In ungefähr 15 Minuten dachten sich die acht Anwesenden Folgendes aus:

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Als die anderen neun Teilnehmer nach einer Viertelstunde wieder das Zimmer betraten, sagte Ward Cunningham, der Erfinder des Wiki und anderer Dinge: »Das ist ja fantastisch!« Es wurde kein einziges Wort geändert.

Das ist also »Agile«: ein Wertebekenntnis. Den Rest des Tages verbrachten die Teilnehmer mit der Entwicklung von zwölf Prinzipien, etwa »Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell«, »Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen« oder »Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität«. Das sind alles großartige Dinge, aber es ist keine Gebrauchsanleitung. Es gab kein Rahmenwerk, keine Methodik, nur vier Werte und einige vernünftige Prinzipien.

Doch es erwies sich als revolutionär. Die Teilnehmer stellten das Agile-Manifest auf eine Website, agilemanifesto.org, und machten sich zu Hause an die schwierige Aufgabe der praktischen Umsetzung. Sie hatten keine Vorstellung davon, welche Auswirkungen das Manifest haben würde, und zwar weit über die Softwarewelt hinaus.

Ich möchte Ihnen aber nahelegen, jeden, der seinen Betrieb als »agil« bezeichnet, danach zu befragen, was er oder sie damit genau meint. Scrum ist die bei Weitem beliebteste Anwendungsmethode – rund 70 Prozent aller agilen Teams verwenden Scrum. Doch es ist eben nicht die einzige Methode, daher ist die Behauptung, dass ein Unternehmen agil sei, für sich allein genommen nicht sehr aussagekräftig.

Das Mooresche Gesetz, auf Menschen angewendet

Falls Sie noch nie von Scrum gehört haben sollten, aber auch, wenn das Konzept Ihnen bereits vertraut ist, ohne dass Sie aber wüssten, inwiefern es Ihrem Unternehmen nützen könnte, mag ein kurzer historischer Abriss hilfreich sein. Woher kommt Scrum und worauf zielt es ab?

Schon seit den späten 1980er-Jahren haben die Leute im Silicon Valley sich darüber Gedanken gemacht, wie sich das Mooresche Gesetz über den raschen technologischen Fortschritt auswirken könnte. Mit der zunehmenden Leistungsfähigkeit von Computern wurden auch Softwareprojekte immer komplexer. Diese schlugen aber leider auch immer häufiger fehl, womit immer größere Verluste an Zeit, Energie, Produktivität und Visionen einhergingen.

Betrachten wir das TAURUS-Projekt, das die Londoner Börse in dieser Zeit verfolgte. TAURUS ist ein Akronym, das für Transfer and Automated Registration of Uncertified Stock (zu Deutsch »Übertragung und automatisierte Registrierung von nicht zertifizierten Aktien«) steht. Das Problem bestand darin, dass die Börse ein Abwicklungssystem namens »Talisman« verwendete. Abwicklung ist ein hochtrabendes Wort, das nicht mehr bedeutet als »Man erhält seine bezahlte Ware«. Wer an der Börse eine Aktie gekauft hatte, musste oft zwei bis drei Wochen warten, bis sie im eigenen Portfolio eingegangen war, denn papierene Aktienzertifikate mussten dafür von einem Ort zu einem anderen befördert werden. Das Handelssystem, das die Käufe und Verkäufe steuerte, hieß Seaq. Es war elektronisch, konnte aber nicht mit dem viele Jahre älteren Talisman-System kommunizieren.

TAURUS sollte diesen Mangel beheben. Es handelte sich um ein elektronisches Abwicklungssystem, das das alte papierbasierte System ablösen und sich zudem in internationale Abwicklungssysteme einfügen würde, um so einen internationalen Wertpapierhandel zu ermöglichen. Es würde großartig sein. Doch individuelle Aktienhändler benötigten das eine, Großhändler das andere. Die meisten Händler wollten außerdem, dass TAURUS mit ihrem maßgeschneiderten System interagierte, statt es zu ersetzen. Und so wurde das TAURUS-Programm mit immer neuen Anforderungen befrachtet.

Dennoch würde es fantastisch sein. Es würde sich mit 17 unterschiedlichen Systemen vernetzen. Großartig. Einem Artikel der Journalistin Hamish McRae zufolge, der am 12. März 1993 in der Zeitung The Independent erschien, gab es jedoch drei Probleme. Erstens ist es hochriskant, ein gigantisches Softwaresystem von Grund auf zu entwickeln und es in Form eines riesigen »Urknalls« einzuführen. Da dürfen keine Ausfälle oder Fehlfunktionen auftreten. Schon der kleinste Ausfall wäre katastrophal. Doch diese Herangehensweise war damals üblich und ist auch heute bisweilen noch anzutreffen. Unternehmen gehen riesige Wetten darauf ein, dass irgendein riesiges System alles gleich von Anfang an in Ordnung bringt. Die Standish Group hat errechnet, dass rund 40 Prozent aller derartigen Projekte vollständig scheitern.2 Die Hälfte sind im Verzug, sprengen ihr Budget und enttäuschen die in sie gesetzten Erwartungen. Das versprach nichts Gutes für TAURUS, ein System, das die Abwicklungssysteme an einem der globalen Drehscheiben des Aktienhandels vollständig ersetzen sollte.

Das zweite Problem, auf das McRae hinwies: Man sollte zwar durchaus ein funktionierendes System besitzen, jedoch ist ein recht gutes System, das funktioniert, dem Streben nach einem perfekten System, das nicht funktioniert, unbedingt vorzuziehen. Das Perfekte sollte niemals des Guten Feind sein. Wie bei fast jedem Projekt weltweit erwies sich die schleichende Umfangsausweitung als Todesstoß. Wäre es nicht fantastisch, wenn dieses neue System nicht nur all das erledigen würde, woran wir schon gedacht und wofür wir eine entsprechende Anforderung formuliert haben, sondern auch noch diese eine andere Sache? Und wenn es einen perfekten Espresso zubereiten würde, während man auf die Ausführung einer Order wartet, wäre das noch fantastischer, und so weiter. Mit der Zeit verwandelt sich so ein ursprünglich einfaches und wohldefiniertes Projekt in eine Rube-Goldberg-Maschine, die für sämtliche Menschen alles nur Denkbare erledigen soll. Und natürlich schafft es am Ende nicht einmal die einfachsten Dinge, die seine Entwickler ursprünglich im Sinn gehabt hatten.

Ich erlebe dies ständig bei Firmen, wenn es um ein bestimmtes unternehmensweites System geht, nämlich SAP. SAP ist der Marktführer bei den sogenannten ERP-Systemen (das Kürzel steht für Enterprise Resource Planning). ERP-Systeme sollen alles Mögliche leisten: Es sind riesige Datenbanken, die Ressourcen wie Kapital, Rohmaterial oder Produktionskapazitäten verfolgen und mit Gehaltslisten, Rechnungen, Bestellungen und so weiter abgleichen. Ein ERP-System berührt daher alle Disziplinen eines Unternehmens – Beschaffung, Verkauf, Personal, Rechnungswesen, Produktion, wirklich nahezu alles – und integriert sie digital. Das gelingt in der Praxis auch recht gut, wenn man die Standardversion des Produkts verwendet.

Schwierig wird es, wenn – wie im Falle von TAURUS – die Leute in Begeisterung darüber ausbrechen, die vermeintlich eierlegende Wollmilchsau gefunden zu haben: ein Produkt, das jedes System integriert, mit den uralten Großrechnern im Keller kommuniziert, Cloud-Computing beherrscht und die Patchwork-Systeme zusammenflickt, die verschiedene Abteilungen notdürftig entwickelt haben und noch immer verwenden. (Oder sie vollständig ersetzt! Durch etwas Besseres!) Und so beginnt die schleichende Umfangsausweitung. Sorgen wir dafür, dass es mit diesem bestehenden System kommuniziert, das wir seit 30 Jahren benutzen. Oder: Es sollte jede Funktion jenes Standardprodukts besitzen, das wir vor 20 Jahren gekauft haben und das nicht mehr unterstützt wird. Eine endlose Liste.

Allein in den vergangenen sechs Monaten habe ich mit drei weltweit tätigen Konzernen zusammengearbeitet, die seit mehr als einem Jahrzehnt versuchen, SAP zu implementieren. Nachdem ich bei einem globalen Getränkehersteller – vermutlich haben Sie heute eines seiner Produkte konsumiert – darüber gesprochen hatte, dass man die Dinge möglichst einfach halten sollte, rückte einer der Ingenieure an mich heran. »Wir haben mehr als eine Milliarde dafür ausgegeben«, sagte er mit gedämpfter Stimme. »Und es funktioniert immer noch nicht.« In einem anderen Unternehmen mit Hunderttausenden von Angestellten, die in den entferntesten Ecken unseres Planeten arbeiten, erklärte man mir, dass eine Milliarde US-Dollar noch günstig sei. Sie hatten bereits anderthalb Milliarden für SAP ausgegeben, ohne dass es bislang funktioniert hätte. Ich erspare Ihnen das dritte Beispiel, um Sie nicht zu deprimieren. Glauben Sie mir, es ist dramatisch. Alle drei Unternehmen hatten eines gemeinsam: Trotz der investierten Milliarden und trotz Tausender involvierter Menschen funktionierte es nicht. Und dennoch versuchten sie das Problem mit weiteren Hunderten von Millionen Dollar zu lösen. Sie taten also immer wieder dasselbe, erwarteten aber andere Ergebnisse.

Doch zurück zu TAURUS, diesem Musterbeispiel eines Abwicklungssystems, und jenen armen Seelen, die 17 verschiedene Vorschläge für die Funktionsweise des Systems zusammenführen sollten – eine wahre Sisyphusarbeit. Es sollte allen möglichen Leuten jeden Wunsch erfüllen. Sie versuchten das zu schaffen. Mit aller Kraft.

Das dritte und letzte Problem mit TAURUS möge folgendes Zitat aus dem Artikel von McRae beleuchten:

Die Börse hat nicht auf ihre Kunden gehört. Ihr Kundenkreis setzt sich aus vielen verschiedenen Gruppen zusammen: den Mitgliedsfirmen, den Unternehmen, dessen Aktien sie handelt, den institutionellen sowie den privaten Investoren. Die Mitglieder sorgten sich über die Kosten von TAURUS, die Unternehmen waren unzufrieden (einige hatten sogar ihre Kooperation verweigert), die Institutionen zeigten sich bestenfalls desinteressiert, manche aber auch ablehnend, und kleinere Investoren, die davon wussten, fürchteten die zu erwartenden höheren Gebühren. Es erfordert schon ein erhebliches Maß an Arroganz, um trotz solcher Widerstände an einem Vorhaben festzuhalten.

»Ein erhebliches Maß an Arroganz« – die Arroganz des Experten. Die Arroganz des Fachmanns. Die Arroganz des Bürokraten. Die Arroganz des Prozesses gegenüber Menschen – eines Prozesses, der mehr Wert auf die aufwändige Beschreibung von Dingen legt, die funktionieren, als auf die Dinge selbst. Das egoistische Beharren darauf, dass ein ausgeklügelter Plan, in den man sein Herzblut gesteckt hat, der weiseren Idee überlegen sei, dass die Dinge sich ändern könnten und es daher vielleicht vernünftig wäre, sich dafür einen Plan zu überlegen.

Und so wurde TAURUS, als wunderbare Idee geboren, 1993 wieder beerdigt – nach Jahren der Anstrengung, während derer Tausende von Menschen lange Tage und Nächte an dem Projekt arbeiteten, und unter Verlust von rund 75 Millionen Pfund. Der Gesamtaufwand, den die Projektbeteiligten zu schultern hatten, wird auf etwa 400 Millionen Pfund geschätzt.

Das ist eine Menge Geld. Aber es ist auch eine Menge an verschwendeter Lebenszeit von Menschen. Eine Menge hochintelligenter Leute widmeten Jahre ihres Lebens der Erschaffung eines Systems, das heute als Lehrbuchbeispiel eines technologischen Flops gilt.

So gerne ich Ihnen nun mitteilen würde, dass TAURUS zu den schlimmsten Beispielen gehört, die mir bekannt sind: Das trifft leider nicht zu. Es gibt viele weitere. Das Projekt »Connecting for Health« des britischen National Health Service, das elektronische Gesundheitsakten im Vereinigten Königreich anlegen sollte: neun verschwendete Jahre, Kostenpunkt: 12 Milliarden Pfund. Das Expeditionary Combat Support System des US-Militärs: sieben verschwendete Jahre, Kostenpunkt: 1,1 Milliarden US-Dollar. Das kalifornische Kraftfahrzeugamt gab ab 1987 mehrere zehn Millionen US-Dollar für den Bau eines Systems aus, das 1990 schon schlechter funktionierte als das System, das es ablösen sollte – und trotzdem dauerte es bis 1994, bis man sich endlich überwand, es einzustampfen. Der San Francisco Chronicle beschrieb es als »nicht handhabbares System, das ohne Einsatz vieler weiterer Millionen nicht zu reparieren war«.

Unsere Maschinen wurden immer schneller und leistungsfähiger, doch wir Menschen standen mit leeren Händen da – in diesem Kontext bewegte sich mein Vater Anfang der 1990er-Jahre. Einen vollständigen Überblick über die damaligen Ereignisse finden Sie in seinem Buch Die Scrum-Revolution (Campus 2015). Doch kurz gesagt erfand er eine neue Arbeitsmethodik. Seine entscheidende Erkenntnis lautete, dass die Schuld an solchen Fehlschlägen nicht den daran beteiligten Menschen zufällt. Die Manager, Ingenieure und Softwaredesigner, die versagten, waren keine schlechten Menschen. Sie waren weder dumm noch hatten sie mit einem Misserfolg gerechnet. Sie verfolgten große Träume und Ziele und wollten die Welt und deren Abläufe verändern.

Nicht die Menschen hatten versagt, sondern das System. Das Problem lag in ihrer Arbeitsweise, in ihren Vorstellungen hinsichtlich dessen, was zu geschehen hatte, die sie in ihre Arbeitstreffen und Planungen hineintrugen. In ihren Augen war es einfach die Art und Weise, wie Dinge nun mal erledigt wurden. Jede andere Arbeitsweise wäre so, als würde ein Fisch die tiefe Verbundenheit seiner Spezies mit dem Element Wasser infrage stellen.

Ein Überlebensleitfaden

Menschen, deren Arbeitsplatz aufgrund von Automatisierung gefährdet ist, unterscheiden sich kaum von Unternehmen, deren Existenzgrundlage ständig bedroht ist. Ob Sie nun persönliche Entscheidungen hinsichtlich Ihrer beruflichen Zukunft zu treffen haben, die strategischen Ziele eines großen multinationalen Konzerns entwerfen oder entscheiden müssen, auf welche Weise sich eine Kultur an veränderte Umweltbedingungen mit ganz neuen Axiomen und Regeln anpasst, stets gilt: Die Fähigkeit zu schneller Anpassung entscheidet über Ihren Erfolg. Wie mein Vater und ich es in unserem vorigen Buch formulierten: Wer sich nicht wandelt, geht unter.

In diesem Buch möchte ich Ihnen aber einige weitere Werkzeuge an die Hand geben. Ich werde Sie einmal rund um den Globus führen, vom Weltall bis in Callcenter und von radikal neuen Technologien bis in ein Restaurant. Die Trends mögen beängstigend wirken, doch ich bin fest davon überzeugt, dass wir lernen können, den Wandel anzunehmen – um belastbarer und weniger ängstlich zu werden, um uns zu höheren Leistungen anzuspornen, anstatt zu beklagen, was wir alles nicht mehr tun können, und um globale Ziele zu verfolgen, anstatt uns von den Kräften in unserem unmittelbaren Umfeld einhegen zu lassen.

Denn der wirkliche Clou besteht darin, dass Scrum allein gar nichts bewirkt. Es setzt lediglich die großartigen Kräfte frei, die in uns allen schlummern. Diese Kräfte sind vorhanden. Sie mögen versteckt oder angeschlagen sein, doch sie können niemals verloren gehen. Sie sind Teil unseres Menschseins. Heute glauben wir zu wissen, wie die Welt tickt; morgen stellen wir fest, dass sie tatsächlich nach ganz anderen Regeln funktioniert. Auf einmal erkennen wir, dass wir die Welt durch eine sehr enge Linse betrachtet haben, dass es unzählige Möglichkeiten gibt, an die wir noch nie gedacht haben, und dass wir nun plötzlich imstande sind, die großen Abläufe zu verändern … was wir tatsächlich immer schon konnten.

Zusammenfassung

Take-away

Scrum ist die Kunst, seinen Möglichkeitsraum zu erweitern. Sie können sich dieser in schnellem Wandel begriffenen Welt anpassen und herausfinden, wozu Sie selbst, Ihr Unternehmen, Ihre Kollegen und Ihre Mitarbeiter wirklich imstande sind. Gleich ob Sie persönliche Entscheidungen hinsichtlich Ihrer beruflichen Zukunft zu treffen haben oder die strategischen Ziele eines großen multinationalen Konzerns entwerfen: Die Fähigkeit zu schneller Anpassung entscheidet über Ihren Erfolg.

Zu scheitern ist ebenso unvermeidlich wie wertvoll. Es kommt nicht darauf an, wer für einen Erfolg oder Misserfolg verantwortlich war, wie das Geld ausgegeben wurde oder was im Einzelnen schiefgegangen ist. Die besten Unternehmen lernen aus ihren Fehlern und Erfolgen und nutzen diese Erkenntnisse systematisch, um sich zu verbessern.

Perfektion wird überbewertet. Ein recht gutes System, das funktioniert, ist dem Streben nach einem perfekten System, das nicht funktioniert, unbedingt vorzuziehen.

Übung

Backlog

Lassen Sie die vier agilen Wertebekenntnisse Revue passieren und beurteilen Sie, wie agil Sie und Ihr Unternehmen sind. Denken Sie daran: »Obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.«

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software (Produkte oder Dienstleistungen) mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Prüfen Sie, wie Ihre Organisation auf Fehlschläge reagiert. Werden diese als wertvolle Lernchancen betrachtet oder lösen sie Schuldzuweisungen aus?

Beurteilen Sie die Anpassungs- und Innovationsfähigkeit Ihres Unternehmens. Wie leicht fällt es Ihnen, mit wechselnden Vorgaben, Bedürfnissen und Anforderungen Schritt zu halten? Trauen Sie sich, ganz neue Wege zu beschreiten, oder warten Sie so lange ab, bis sie irrelevant geworden sind? Was stärkt oder behindert Ihre Fähigkeit, auf Veränderungen zu reagieren?

Kapitel 2Wie Sie Ihre Meinung ändern können, ohne dass es die Welt kostet

Mein Kollege Joe Justice hat eine simple Botschaft, die er oft wiederholt: »Bei Scrum geht es darum, die Kosten einer Meinungsänderung zu senken.« Joe arbeitet überwiegend mit Herstellern von Gebrauchsgütern wie Fahrzeugen, Raketen, medizinischen Geräten, Schutzkleidung für Feuerwehrleute und Ähnlichem zusammen. Also Herstellern von »Dingen«.

Die Probleme, denen er begegnet, betreffen nicht nur die Branchen, die »Dinge« produzieren. Es geht immer darum zu begreifen, wie das Produkt aussehen sollte, welche Eigenschaften es haben sollte, was man tun muss, um hohe Standards zu erfüllen, wie man es zu vertretbaren Kosten und mit einer Geschwindigkeit bereitstellt, die sich an den Bedürfnissen der Kunden und den Maßnahmen der Wettbewerber orientiert. Dies alles gilt unabhängig von der Branche, in der man operiert.

In diesem Buch stelle ich die Modelle und Praktiken vor, die es uns ermöglichen, diese Probleme schneller zu lösen, als Sie es sich ausmalen können. Doch bevor ich ins Detail gehe, möchte ich Ihnen einen kurzen Überblick über die Grundlagen von Scrum geben.

Wie Scrum funktioniert

Hier also ein Schnellkurs in Scrum.

Zunächst muss man wissen, dass Scrum nur drei Rollen kennt: den Product Owner, den Scrum Master und das Teammitglied. Es gibt weder einen Business-Analysten noch einen Technikleiter noch einen leitenden Scrum Master – nur diese drei Rollen. Gemeinsam bilden sie ein Scrum-Team, das einen eigenständigen Wertschöpfungsbeitrag leisten kann. Das Team ist die kleinste organisatorische Einheit in Scrum. Solche Teams liefern Kunden in kurzen Zyklen, die als Sprints bezeichnet werden, einen raschen Wertschöpfungsbeitrag.

Der Product Owner oder PO entscheidet über den Inhalt der Arbeit – also über das, was das Team bauen oder erschaffen wird, welche Dienstleistung es anbieten oder welchen Prozess es erfinden oder veröffentlichen wird. Der PO sammelt Input von Kunden, relevanten Akteuren, dem Team selbst und von jedem, der von den Aktivitäten des Teams profitieren wird. Das können Bauern in Uganda sein, die mit einer Pflanzenkrankheit zu kämpfen haben, oder Ingenieure, die an der Entwicklung eines selbst fahrenden Autos arbeiten, oder auch Kinogänger, die eine Neuerscheinung sehen möchten. Der PO muss mithilfe all dieser Inputs, die bisweilen widersprüchlich sein können, eine Vision dessen entwerfen, was das Team leisten soll. Anschließend – und dies ist oft die schwierigste Aufgabe – muss er all diese Vorschläge anhand ihres jeweiligen Werts in eine Reihenfolge bringen. In Scrum gibt es keine Hauptprioritäten, sondern zu jedem gegebenen Zeitpunkt nur eine einzige Priorität. Es ist oft nicht leicht, diese festzulegen. Doch so funktioniert Scrum nun einmal.

Der PO priorisiert also alle zu erledigenden Dinge anhand ihres Wertschöpfungsbeitrags und erstellt damit das sogenannte Product-Backlog. Dieses ist eine potenziell unendlich lange Liste, die all jene Dinge aufführt, die das Team möglicherweise bewältigen könnte. Es ist zudem ein lebendes Dokument, das sich laufend verändert – auf der Basis von Kunden-Feedback, veränderlichen Marktbedingungen, neuen Einsichten, Eingriffen des Managements oder was auch immer. Es soll Veränderungen erleichtern.

Der Product Owner stellt nun seinem Team dieses Backlog im Rahmen des sogenannten Sprint-Planning-Meetings vor. Hier geht das Team gemeinsam das Product-Backlog durch und entscheidet, welche der Aufgaben es angehen soll und wie viele es wohl im Rahmen des nächsten Sprints erledigen kann. Beachten Sie bitte, dass das Team diese Entscheidung trifft, nicht der PO oder das Management. Es überträgt die obersten Punkte des Product-Backlog in das sogenannte Sprint Backlog. Während das Product-Backlog völlig austauschbar ist, sind die Elemente des Sprint-Backlog festgelegt. Das Team soll sich im kommenden Sprint auf diese Punkte und nur auf diese Punkte konzentrieren.

Nun wird durchgestartet. Das Team führt einen Sprint aus, der eine bis vier Wochen umfasst – je nachdem, welcher Rhythmus sich für das Team am besten eignet. Die meisten Unternehmen entscheiden sich dieser Tage für zweiwöchige Sprints, doch ich rate meinen Kunden stets zu einwöchigen Sprints. Warum? Nun, der Scrum-Prozess beinhaltet Feedback-Schleifen, die meiner Meinung nach möglichst kurz sein sollten, damit man rasch lernen kann. Besonders wichtig ist dies für Teams, die in Disziplinen wie Vertrieb, Kundendienst oder Rechnungswesen tätig sind, wo es auf Reaktionsschnelligkeit ankommt.

Das nächste Ereignis ist der Daily Scrum, oft auch als Daily Stand-up bezeichnet. Dieses Meeting nimmt nur 15 Minuten in Anspruch. Das Team bespricht darin, was es am vergangenen Tag dafür getan hat, um das Ziel dieses Sprints zu erreichen, was es in den nächsten 24 Stunden dafür tun wird und welche Hindernisse es erkennt, die das Team davon abhalten könnten, das Ziel zu erreichen. Der Daily Scrum ist kein Status-Meeting. Es gleicht eher dem Moment, an dem Fußballspieler vor Beginn eines Spiels die Köpfe zusammenstecken. Es ist ein kleines Treffen zur Neuplanung. Das Team hat am Vortag im Verlauf seiner Arbeit manches gelernt und kann sich nun darüber austauschen. Man kann sich das wie eine Gruppe von Menschen vorstellen, die zu einer Autoreise aufbrechen: Sie planen die Route, die sie zu ihrem Zielort führen soll, fahren los und schauen dann jeden Morgen beim Frühstück erneut auf die Karte, prüfen die Wetteraussichten, überlegen, wer heute den Wagen steuern soll, und fahren dann weiter. Nach 15 Minuten ist der Daily Scrum beendet.