1KAPITEL 1:

Der Scrum-Kern als Muster

Dieses Kapitel wird Sie auf drei verschiedene Weisen auf Ihren Weg bringen.

1. Wir geben Ihnen einen kurzen Überblick über Scrum, der Ihnen hilft, das große Ganze zu sehen.

2. Wir verknüpfen die Hauptelemente von Scrum mit Mustern, damit Sie intuitiv verstehen, wie diese zusammenwirken.

3. Wir stellen die wesentlichen Regeln des Spiels "Menschen bauen etwas gemeinsam" vor.

Wir werden Ihnen helfen, Ihr Verständnis von Scrum zu vertiefen, und zwar so, dass Ihre Intuition sich darauf einstellt, was Muster sind. Es wird ebenfalls deutlich, dass dies ein Buch über umfangreiche Erfahrungen mit Menschen ist, und wie Sie davon profitieren können, indem Sie diese organisatorischen Bausteine an Ihre Situation anpassen. In diesem Buch finden Sie keine Regeln und absoluten Wahrheiten, denen Sie blind folgen können.

Wir werden Scrum anhand seiner beiden umfassenden Strukturen beschreiben: die Organisation, die ein Produkt baut, und der Wertstrom, an dem das Produkt entlang fließt. Jede dieser Strukturen bildet eine Ganzheit, eine selbst gestaltete Sache. Eine Mustersprache leitet uns schrittweise, während wir so eine Ganzheit aufbauen. Dieses Buch präsentiert zwei Mustersprachen, eine für jede der beiden konzeptionellen Ganzheiten. Sie bieten Ihnen einen kenntnisreichen und bewährten Leitfaden, während Sie Ihre Scrum-Organisation aufbauen.

In diesem Kapitel lernen Sie das erste Muster kennen, ¶1 Der Geist des Spiels, das am Anfang jeder Mustersprache steht. Es bereitet auf alle weiteren Muster vor. Was noch wichtiger ist: Wir hoffen, dass dieses Kapitel und Der Geist des Spiels Ihnen neue Erkenntnisse darüber liefern werden, wie man dieses Buch betrachtet, wie man es nutzt und wie man Scrum anwendet.

Betrachten Sie Scrum als ein Spiel, das wir spielen. Wie die meisten Spiele, kann es eine wundervolle Form des Engagements sein, wenn seine Spieler sowohl die Disziplin als auch die Freiheit schätzen, die ihnen helfen, einen Wert zu schaffen. Die meisten Muster in diesem Buch empfehlen organisatorische Veränderungen, die auf diese Weise funktionieren. Aber auf einer tiefergehenden Ebene, sollten Sie die Kunst des Aufbaus oder Wachstums Ihrer Organisation ebenfalls als Spiel betrachten. Wir finden es gut, wenn man sich den Mustern spielerisch nähert, in der Hoffnung, die Vorteile aus jedem Muster umzusetzen und mit einem gewissen 2Grad an Zuversicht, dass man die Disziplin jedes Musters annimmt. Ihre Erkundung ist eher wie ein ernsthaftes als wie ein reglementiertes Spiel, und viele Ihrer Untersuchungen werden eher dem gesunden Menschenverstand folgen als den Regeln. Sie werden erforschen, was Done für Sie bedeutet (siehe ¶82 Definition of Done), wie lang ein Sprint sein sollte, wie viele Leute in Ihrem Team sein sollten und vieles mehr. Sich im Spiel zu engagieren, bedeutet, Dinge auszuprobieren, das Ergebnis zu beurteilen und entsprechend fortzufahren. Es kann auch bedeuten, einige Muster abzulehnen. Falls das allerdings aus Furcht oder Unbehagen, statt aus einer Haltung großer Erwartungen geschieht, oder weil Sie sich einfach an die Regeln im Buch halten wollen, dann werden Sie wahrscheinlich keine geeignete Grundlage erhalten, um Ihre Arbeit fortzusetzen. Wir werden versuchen, Ihnen zu helfen, auf dem richtigen Fuß zu starten.

Wenn man es nicht richtig spielt, ist "Menschen bauen etwas gemeinsam" ein Spiel, das unser Team oder unser Unternehmen zu gewinnen versucht. Im weiteren Sinne ist Scrum jedoch ein Spiel, das niemals endet. Unser Unternehmen und unsere Wettbewerber können abwechselnd an der Spitze stehen, wenn jeder neue Funktionalitäten, Wege zur Markterschließung oder andere Wertsteigerungen für die Gesellschaft realisiert. Wenn man dieses Spiel langfristig auf diese Weise spielt, steigern wir die Lebensqualität der gesamten Gemeinschaft. Um in einer komplexen Welt dorthin zu gelangen, muss man mit dieser Welt in Verbindung stehen, bei jedem Schritt überprüfen und als Gemeinschaft innovativ sein, um das Richtige zu tun. Dort beginnen wir, und in diesem Sinne ist das erste Muster die Grundlage für alle anderen. Ein gutes Muster steht für sich allein, und wir lassen es sich selbst erklären.

¶1 Der Geist des Spiels

Bewertungssterne: **

3. das Scrum-Rahmenwerk hat nicht auf alles eine endgültige Antwort, was bedeutet, dass das Team von Scrum keine Anweisungen erwarten kann.

Schriftliche Regeln geben vielleicht konkrete Anleitungen für die Zusammenarbeit, aber der Geist ist Teil der Kultur, die die Interaktionen lenkt und die vielleicht nur wahrgenommen wird, wenn sie ignoriert oder verletzt wird.

Cricket ist ein Spiel, das viel von seinem besonderen Reiz dem Umstand verdankt, dass es nicht nur innerhalb seiner Gesetze gespielt werden sollte, sondern auch im Geist des Spiels. Wenn die Spieler irgendetwas tun, dass diesen Geist missbraucht, dann verletzt das das Spiel selbst. Die Hauptverantwortung, den Geist des Fair Play zu gewährleisten, liegt bei den Kapitänen.1

Am 16. Mai 1999 veranlasste das Verhalten des Kapitäns eines Cricket-Spiels im World Cup den Schiedsrichter einzuschreiten, obwohl keine Verletzung eines Cricket-Gesetzes vorlag. Der Kapitän des indischen Teams beklagte sich beim Schiedsrichter darüber, dass der südafrikanische Kapitän einen Ohrstöpsel benutzte, um mit dem Trainer zu kommunizieren. Der Ohrstöpsel verletzte zwar kein Cricket-Gesetz, aber den Geist des Spiel und musste daher entfernt werden.2

Scrum verlangt einen Spirit der Interaktionen zwischen Menschen, und dieser Spirit kann schwer zu definieren sein. Er ist Teil der Organisationskultur, aber wird vielleicht von den Menschen innerhalb dieser Kultur gar nicht wahrgenommen. Aber obwohl er schwierig zu definieren ist, ist es einfach zu erkennen, wenn er beschädigt ist.

Scrum ist ein leichtgewichtiges Prozess-Rahmenwerk, einfach zu verstehen, aber schwierig zu beherrschen.3 Weil es einfach zu verstehen ist, neigen Menschen dazu, ihre blinden Flecken mit Annahmen zu füllen. Häufig wird davon ausgegangen, dass Scrum nur einfache Veränderungen in den Arbeitsabläufen erfordert. So übersieht man allerdings seinen wesentlichen Spirit. Infolgedessen behandeln einige Scrum eher als Instruktion denn als Leitfaden. Scrum selbst bietet keine Antworten, schafft aber Transparenz im Alltag, sodass Teammitglieder beginnen können, Erkenntnisse über die Art ihrer Zusammenarbeit zu gewinnen und sich so verbessern.

Kultur hat mit Gewohnheiten zu tun, und Gewohnheiten zu ändern ist schwierig. Für Entwickler mag es sich unangenehm anfühlen, wenn aus einem Command-and-Control-Unternehmen ¶16 Autonome Teams hervorgehen, da sie gezwungen sind, verstärkt für sich selbst zu denken. Die Manager haben möglicherweise das Gefühl, Macht zu verlieren, da die Teams ohne ihre Genehmigung Entscheidungen treffen können. Einzelne im Unternehmen blockieren Veränderungen vielleicht mit der Entschuldigung, dass sie die Dinge immer schon so gemacht haben. Wir 4trösten uns womöglich mit der Tatsache, dass das, was wir gerade tun, auf irgendeine bekannte Weise funktioniert. Wir wollen dieses Gelingen nicht über den Haufen werfen - es nur ein bisschen zwicken. Indem eine Organisation an alten Arbeitsweisen festhält, kann sie Scrum sabotieren. Das etablierte Organisationsdesign steht vielleicht in Konflikt mit den Scrum-Prinzipien. Ein Vorstandsmitglied fordert beispielsweise einen bestimmten Termin oder Umfang, wodurch dem Team unbefriedigende Beschränkungen auferlegt werden. Das führt wahrscheinlich zu unbeabsichtigten Konsequenzen, wie schlechter Qualität oder Burn-out. Ein anderes Beispiel ist, wenn der Projektmanager tägliche Berichte vom ¶14 Entwicklungsteam verlangt. Das signalisiert eher Argwohn als Vertrauen, verschwendete Zeit statt Effizienz und Kontrolle statt Autonomie.

In Scrum sollte das Entwicklungsteam ein Autonomes Team sein, und auch ein ¶17 Selbstorganisierendes Team. Es gibt innerhalb des Teams keine Hierarchie. Das ist leichter gesagt als getan, weil bestehende Hierarchien sich hartnäckig halten können. Ein Beispiel auf Unternehmensebene ist, wenn ein Manager versucht, die Scrum-Implementierung zu "verbessern", indem er das Entwicklungstracking-Tool des Teams nutzt, um individuelle Leistungen zu beurteilen. Der Fokus verlagert sich von den Teams auf einzelne Personen, und solche Kennzahlen sind bestenfalls Messungen aus zweiter oder dritter Hand, die wesentliche Beiträge verschleiern, die über die Anzahl der verlegten Steine pro Tag hinausgehen. Das wirkt Teamautonomie und Selbstorganisation entgegen und kann die Arbeitsweise des Teams stören (Personen handeln im Hinblick auf die Messungen statt entsprechend ihrer Effektivität, vielleicht auch um ihre finanzielle Vergütung zu optimieren), sodass es hinter seiner potenziellen Leistungsfähigkeit zurückbleibt. Ein weiteres Beispiel ist, wenn ein Ressourcenmanager die Zusammensetzung des Teams in jedem ¶46 Sprint ändert, um das benötigte Wissen für jeden Sprint zu optimieren. Das nimmt dem Team natürlich die Möglichkeiten zur Selbstorganisation und zerstört seine Autonomie.

In Scrum geht es um Teamwork, aber einige...