E-Book, Deutsch, 239 Seiten
ISBN: 978-3-593-44432-1
Verlag: Campus Verlag
Format: EPUB
Kopierschutz: Wasserzeichen (»Systemvoraussetzungen)
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.
Weitere Infos & Material
Kapitel 2
Wie 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. Nun betritt der Scrum Master die Bühne. Klingt nach einer seltsamen Stellenbezeichnung, nicht wahr? Tatsächlich habe ich bei meinem Vater, dem Mitschöpfer von Scrum, dafür plädiert, sie durch so etwas wie »Coach« zu ersetzen. Er entgegnete, dass sie bereits fester Bestandteil der Kultur sei. Meine Intervention komme also zu spät. Nun denn. Der Scrum Master ist in den meisten Unternehmen jedoch eine ganz neue Position. Seine Aufgabe besteht ausschließlich darin, den Teams eine raschere Arbeitsausführung zu ermöglichen. Tempo lautet der Kernbegriff ihres Wirkens. Warum sollte man einen Menschen für diese Aufgabe bezahlen? Nun, wenn er dafür sorgt, dass ein Team seinen Wertschöpfungsbeitrag doppelt so schnell erbringen kann, dann hat er sein Geld mehr als verdient. Es ist immer besser, ein Team zu beschleunigen, als neue Leute oder Teams einzustellen. Der Scrum Master hilft also einem Team, seine Arbeitsgeschwindigkeit (in Scrum als Velocity bezeichnet) zu steigern, und dem Product Owner obliegt es, diese Geschwindigkeit in einen Wertschöpfungsbeitrag umzumünzen. Es gibt wenig Traurigeres, als wenn eine Gruppe ganz ausgezeichneter Leute unter Hochdruck Dinge herstellt, die niemand braucht. Erinnern sie sich noch an Nokia-Handys? Die Firma unterhielt einige gute Scrum-Teams, die in rasendem Tempo Mobiltelefone herstellten – die allerdings niemand, der einmal ein iPhone gesehen hatte, kaufen wollte. In nur wenigen Jahren sank der Marktwert des ehemaligen Marktführers Nokia auf null. Der Scrum Master ist also mit dem Coach einer Sportmannschaft vergleichbar. Er unterstützt das Team beim Scrum-Prozess und bemüht sich, alle Hindernisse zu beseitigen, die seine Arbeitsgeschwindigkeit senken. Nur darin besteht seine Aufgabe – jeden Tag. Im Verlauf der Arbeit an einem Sprint Backlog muss sich das Team bisweilen mit dem Product Owner kurzschließen. Diese Treffen im Verlauf eines Sprints werden als Backlog Refinement bezeichnet. Sie entscheiden meiner Meinung nach über den Erfolg oder Misserfolg von Scrum. Hier sammelt der Product Owner alle großartigen Ideen der Teammitglieder für künftige Sprints und bereitet sie gemeinsam mit ihnen so auf, dass sie umgesetzt werden können. Das Team entscheidet, was ein Element im Einzelnen beinhaltet und – wichtiger noch – nach welchen Kriterien später beurteilt wird, ob das Element erfolgreich abgearbeitet wurde oder nicht. Betrachten wir dazu eine Tätigkeit, die ich sehr häufig ausübe: das Abfassen eines Blog-Eintrags. Ich könnte nun einfach sagen: Hier, ich habe ihn geschrieben, er ist fertig. Doch stimmt das wirklich? Er muss lektoriert werden und ein Korrektorat durchlaufen. Er benötigt eine Illustration. Er muss auf die Website gestellt werden. Mein Blog-Eintrag ...
