Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: UVK
- Kategorie: Fachliteratur
- Serie: Projektmanagement neu denken
- Sprache: Deutsch
- Veröffentlichungsjahr: 2021
Agile Projektmanagement-Methoden, die vor allem in Startups zu finden sind, werden im Zuge der digitalen Transformation auch für größere Organisationen immer interessanter und wichtiger. In diesem Buch wird untersucht, welche konkreten Herausforderungen es bei der Einführung der Projektmanagement-Methode Scrum gibt und wie man diese bewältigen kann. Folgende Fragen werden mit dem Buch beantwortet: Was genau ist bei der Einführung der Scrum-Prozesse zu beachten? Wie ist das Scrum-Rollenverständnis und wie etabliert man diese Rollen in bestehenden Organisationen? Wie erreicht man, dass die Scrum-Events erfolgreich durchgeführt werden? Welche Metriken eignen sich besonders gut, um den Fortschritt agiler Projekte zu messen? Wie können Projektrisiken minimiert und Probleme frühzeitig erkannt werden? Welche Skalierungsframeworks gibt es, um Scrum auch für größere Projektteams und Organisationen nutzen zu können?
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 291
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Jörg Brüggenkamp / Peter Preuss / Tobias Renk
Der Scrum-Reiseführer
Herausforderungen in der Praxis meistern
Umschlagmotiv: © iStockphoto pixdeluxe
© UVK Verlag 2021– ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KGDischingerweg 5 • D-72070 Tübingen
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetztes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Internet: www.narr.deeMail: [email protected]
ISSN 2748-4629
ISBN 978-3-7398-3117-6 (Print)
ISBN 978-3-7398-0142-1 (ePub)
Inhalt
1Geleitworte
1.1Hanna Hennig (Siemens AG)
Unsere VUCA-Welt verlangt Unternehmen einiges ab: Sie sollen mit zunehmend komplexen und unsicheren Bedingungen umgehen lernen. Sie sollen resilienter werden. Sie sollen mit der digitale Transformation Schritt halten und Zukunft vorausdenken können. Verändern sich die Zukunftsbedingungen, sollen sie die neuen Parameter zügig in ihr „System“ adaptieren. Was dies tatsächlich bedeuten kann, hat nicht zuletzt die Corona-Pandemie drastisch vor Augen geführt. Von jetzt auf gleich waren Betriebe gefordert, Zusammenarbeit neu zu denken. Wer sich schnell ein- und umstellen konnte, hatte einen klaren Vorteil am Markt.
Wo Zukunft sich auf Tagesbasis verändern kann, ist Flexibilität Schlüssel zum Erfolg. Agile Konzepte wie Scrum stellen dafür ein methodisches Gerüst. Doch „Agile“ ist längst mehr als nur flexibles, prozessorientiertes Arbeiten. Es hat sich von einer Methode zu einer Kultur entwickelt, die Unternehmen durch und durch prägen kann. Als „Business Agility“ nimmt es nun auch Einfluss auf die strategische Ausrichtung und auf das Verständnis von Leadership.
Auch bei Siemens setzen wir auf Agilität. Die Digitalisierung eröffnet großartige Chancen zur Innovation, von denen unsere Kunden und wir vielseitig profitieren können. Indem wir unsere Software- und Produktentwicklung und das Projektmanagement agil aufsetzen und begleitende Abläufe digital optimieren, können wir die Go-to-Market-Time für Produkte, Lösungen und Services wesentlich beschleunigen.
Das digitale Zeitalter ist agil geprägt. Gerade großen Konzernen mit komplexen, oft verfestigten Strukturen bietet Scrum ideale Instrumente, die Neues zulassen, das Bewährte jedoch nicht gefährden. Und Startups ermöglicht Scrum eine hoch effiziente Methode der Ideenentwicklung bis zur Marktreife. Bei der Einführung agiler Methoden sind jedoch manche Hürden zu nehmen, das haben auch wir „by doing“ gelernt: von falsch verstandenen Rollen, über Probleme in der Kommunikation und Kooperation bis zum gänzlichen Abhandenkommen des „Big Picture“.
Es gilt, Gründer, Entscheider, Projektmanager und Innovationstreiber auf diese neue, agile Art von Arbeiten besser vorzubereiten. Ich freue mich, dass sie in diesem Leitfaden eine wunderbar komprimierte Einführung in die Scrum-Methodik mit sehr wertvollem, anwendungsorientiertem Know-how finden.
Hanna Hennig
CIO Siemens AG
1.2Dr. Silvia Rummel (Festo SE & Co. KG)
Aufgrund von Digitalisierung und Datenverfügbarkeit ändern sich mit atemberaubendem Tempo die Kundenanforderungen und die Wettbewerbsbedingungen. Die heute zur Verfügung stehenden digitale Produkte und Services ermöglichen es den Kunden, ein noch nie dagewesenes Spektrum an Funktionalitäten zu nutzen. Dabei ist es egal, an welchem Ort sich die Nutzer befinden oder zu welcher Zeit die Services benötigt werden, den Möglichkeiten sind keine Grenzen gesetzt.
So faszinierend und beeindruckend es auch ist, diesen Wandel zu beobachten, so herausfordernd ist es gleichzeitig für die Unternehmen, die diese Produkte herstellen. Wo bis dato das physische Produkt und dessen einmaliger Erwerb im Vordergrund stand, rücken nun Services mit der Generierung von Mehrwerten in den Mittelpunkt für die Konsumenten. Dieser drastischen Veränderung des Produkt- und Konsumentenverhaltens sind bisherige Organisationsansätze kaum gewachsen. Über Dekaden hinweg wurden Entwicklungsprozesse dahingehend optimiert, physische Produkte in Form von Projekten innerhalb von kürzester Zeit und mit technischer Raffinesse zu realisieren. Mit Erfolg – doch nun gilt es, dieses Vorgehen auf ein neues Level zu bringen und Software als Bestandteil des Produktes zu sehen, um den veränderten Kundenanforderungen gerecht werden.
Durchschreitet eine Organisation diese Veränderung und nimmt sich der digitalen Transformation in all ihren Facetten an, wird dies auch zu einem Umdenken bei der Projektarbeit führen. Erfahrene Teams kommen mit traditionellen Projektmanagement-Methoden hier schnell an ihre Grenzen. Um dennoch den vorgegebenen Zielkorridor (Zeit, Budget und Qualität) zu erreichen, sind alternative Methoden erforderlich. Die Lösung: Scrum als agile Form des Arbeitens. Dies ermöglicht ambitionierten und motivierten Teams schnell Erfolge zu erzielen und dennoch strukturiert vorzugehen.
Mit dem vorliegenden Buch bekommen Führungskräfte, Projektmanager und Projektleiter in Organisationen, welche sich dem Thema digitale Transformation bereits angenommen haben oder sich gerade auf dem Weg dahin befinden, einen Praxisleitfaden an die Hand. Es wird ein umfangreicher Einblick in das Scrum Rollenverständnis, die Scrum Artefakte und die Scrum Events gegeben. Dabei wird viel Wert auf Verständlichkeit und Praxisbezug gelegt.
Den Autoren ist mit dem „Scrum-Reiseführer“ ein übersichtliches und zugleich zielgerichtetes Buch für die Unternehmenspraxis gelungen. Ich wünsche mir für die Autoren, dass das Verständnis und die Anwendbarkeit agiler Projektmanagement-Methoden in Organisationen weiter zunehmen. Mit diesem Buch wird Managern und Projektteams die „Hürde der Veränderung“ hin zu mehr agilem Vorgehen genommen und durch Systematik und anschauliche Erläuterungen zugänglich gemacht.
Dr. Silvia Rummel
Head of Energy Efficency & CO2 Footprint Portfolio
Festo SE & Co. KG
2Prolog – Agilität als Kernkompetenz für moderne Unternehmen
Man hört, sieht und liest es überall. Unsere Welt ist im ständigen Wandel. Das war schon immer so und ist nicht überraschend. Der Wandel selbst verändert sich stetig und erhöht seine Geschwindigkeit merklich. Bis in die 1990er Jahre war es üblich, strategische Pläne zu erstellen, deren Umsetzung sich über mehrere Jahre erstreckte. Am Ende des letzten Jahrzehnts im alten Jahrtausend geschah jedoch eine technische Revolution, die den Stein des immer schneller werdenden Wandels ins Rollen brachte: Die Kommerzialisierung des Internets. Dies führte dazu, dass viele Annahmen, die noch einige Jahre vorher durchaus sinnvoll und langlebig waren, nun in Frage gestellt werden mussten. Informationen waren nun für jeden zugänglich. Smartphones führten einige Jahre später dazu, dass jeder Nutzer das Internet in der Hosentasche bei sich trug und damit jederzeit und überall auf der Welt erreichbar war. Die sich entwickelnde Cloud-Technologie bot jedem einen Supercomputer an. Das hatte zur Folge, dass plötzlich Eintrittsbarrieren in ganze Branchen wegfielen oder erheblich minimiert wurden. Wenn plötzlich Konkurrenz sprichwörtlich aus dem Nichts kommen kann, weil ein smarter Student am Küchentisch eine Software schreibt, dann kann die Antwort darauf nicht mehr lauten, mehrjährige Strategiepläne zu entwickeln. Unternehmen müssen sich seitdem so aufstellen, dass sie schnell und flexibel auf Änderungen im Unternehmensumfeld reagieren können. Es kommt noch eine Herausforderung dazu: Die soeben beschriebenen Veränderungen treten in Zyklen auf, die sich nicht nur öfter als in der Vergangenheit an der Oberfläche zeigen – Nein. Auch die Abstände zwischen den Zyklen werden kürzer. Eric Schmidt und Jonathan Rosenberg beschreiben die Situation in ihrem Buch „How Google Works“ so, als ob Moores Gesetz Amok läuft.
Die beiden Gegebenheiten – schnelle Veränderungen in kürzer werdenden Abständen – haben zu einer neuen Begriffsbildung geführt. Der Ausdruck VUCA beschreibt diese neue Welt. VUCA ist dabei ein Akronym für die englischen Begriffe Volatility (Unbeständigkeit), Uncertainty (Unsicherheit), Complexity (Komplexität) und Ambiguity (Mehrdeutigkeit). Die Vorhersehbarkeit bestimmter Ereignisse ist sehr schwierig, wenn nicht gar unmöglich geworden. Wer konnte schon vorhersehen, dass eine Revolte eines Händlers, wie es sie viele gibt, zu einer der größten Revolutionsbewegungen, dem Arabischen Frühling, wird – weil sie von einer zufällig anwesenden Person mit einem Smartphone gefilmt und online gestellt wurde. Das gleiche Prinzip gilt auch auf Unternehmensebene. Die Vorhersagbarkeit nimmt ab und führt zu Verunsicherungen. Gleichzeitig nimmt die Komplexität im Unternehmensumfeld zu und unterschiedliche Perspektiven vermischen sich. Trennungen, die früher eindeutig waren und aufgrund derer es zumindest mit großem Aufwand möglich war, einigermaßen gesicherte Annahmen zu treffen, gibt es heute nicht mehr. Immer häufiger gibt es unübersehbare Geflechte aus Reaktionen und Gegenreaktionen. Vielzitierte Best Practice-Erfahrungen sind nutzlos geworden, da sich gesuchte Antworten nicht mehr von bereits gestellten, ähnlichen Fragestellungen ableiten lassen. In anderen Worten: Wo genau die Reise hinführt, ist nach der Abfahrt eigentlich noch gar nicht klar.
Wie lautet nun die Gegenantwort auf VUCA? Wie können Unternehmen mit dieser neuen Situation umgehen? Was können sie tun? Auf der Internetseite vuca-welt.de wird eine Antwort geliefert, die sich ihrerseits selbst mit dem Akronym VUCA abbilden lässt. Nur stehen die Buchstaben diesmal für Vision, Understanding (Verstehen), Clarity (Klarheit) und Adaptability (Anpassungsfähigkeit) oder Agility (Agilität). Wer ein konkretes Ziel vor Augen hat, kann Sinn stiften, Mitarbeiter für sich gewinnen und diese auf ein gemeinsames Ziel einschwören. Nachvollziehbare Zusammenhänge, Klarheit durch Offenheit und Transparenz sorgen dafür, dass sich Mitarbeitende auf das, was wirklich zählt, fokussieren können. Und da die Zukunft trotz aller Bemühungen nicht exakt vorhersagbar ist, müssen Unternehmen – und damit auch die Mitarbeitenden – in der Lage sein, sich schnell auf Veränderung einzustellen und neue Erkenntnisse, die während der Reise erlangt werden, in den noch verbleibenden Weg einzuarbeiten. Damit wird Agilität zu einer echten Kernkompetenz moderner Unternehmen. Mehr noch, Agilität wird zu einem wichtigen Wettbewerbsvorteil.
Mit dieser Anpassungsfähigkeit bzw. Agilität befasst sich dieser Reiseführer. Die Autoren haben sich dabei für das Scrum-Rahmenwerk entschieden. Dieses beschreibt eine Methode, wie Agilität in Unternehmen eingeführt werden kann. Die Auswahl von Scrum fiel den Autoren dabei leicht. Scrum, oder adaptierte Versionen davon, die im Verlauf dieses Buches behandelt werden, ist in der Praxis die beliebteste und am häufigsten verwendete agile Methode. Diese Methode soll Unternehmen in die Lage versetzen, produktiv und kreativ Produkte mit höchstmöglichem Wert zu entwickeln und sich zügig an sich ändernde Rahmenbedingungen anzupassen. Der Begriff Scrum hat seinen Ursprung im Rugby und leitet sich aus dem englischen Begriff für Gedränge ab. Hiermit soll verdeutlicht werden, dass die Entwicklungsteams, die sich dem Scrum-Modell bedienen, insbesondere durch kooperatives, selbstverantwortliches und selbstorganisiertes Verhalten erfolgreich sind. Die beiden Scrum-Erfinder Ken Schwaber und Jeff Sutherland beschrieben ihr Rahmenwerk erstmals im Scrum Guide im Jahr 2010. Die Ausführungen in diesem Buch basieren auf dem Scrum Guide, der im November 2020 veröffentlicht wurde. Diese siebte Auflage trägt den Titel „The Scrum Guide. The Definite Guide to Scrum: The Rules of the Game“, was als Indiz interpretiert werden kann, dass in näherer Zukunft keine Aktualisierungen geplant sind.
Lassen Sie sich nun verzaubern, was in der Theorie alles möglich ist und wie es in der agilen Wirklichkeit zugeht. Freuen Sie sich auf ein beeindruckendes agiles Team auf dem Weg zum Erfolg und bestaunen Sie die Scrum Artefakte in ihrem ganzen Glanz der praktischen Nutzbarkeit. Erleben Sie, wie jedes einfache Scrum Meeting zu einem Event des Austausches und der Erkenntnis wird. Erkunden Sie in einer einmaligen Tour die tiefen Höhlen der Reports und bereiten Sie sich auf größere Dinge vor, die vor Ihnen liegen könnten, auf der Reise in die weite Welt der Agilität.
3Scrum Framework – Eine kurze Einführung
In diesem Kapitel werden in einem Schnelldurchlauf die Werte und Prinzipien sowie die Rollen, Artefakte und Events des Frameworks vorgestellt, auf denen Scrum basiert. Es dient dazu, sich schnell einen Überblick zu verschaffen, bevor die angerissenen Themen in den nachfolgenden Kapiteln tiefergehend und insbesondere in Hinblick auf die praktische Anwendbarkeit behandelt werden.
3.1Das Fundament
Scrum basiert auf der empirischen ProzesssteuerungEmpirische Prozesssteuerung. Ziel dieser Empirie ist es, Wissen aus gewonnen Erfahrungen abzuleiten und so bessere Entscheidungen zu treffen. Damit man in kurzen Zeitabständen die Möglichkeit zur Prüfung und Anpassung hat, verfolgt Scrum einen iterativen, inkrementellen Ansatz für die Produktentwicklung. So wird nicht nur erreicht, dass die Erfahrungswerte schneller in klügere Entscheidungen münden. Mit dieser Vorgehensweise können auch mögliche Risiken frühzeitig identifiziert und angegangen werden. Die empirische Prozessteuerung spiegelt sich in drei Säulen, auf denen Scrum basiert, wider: Transparenz, Überprüfung und Anpassung.
Säulen und Werte von Scrum
Scrum wurde ursprünglich für das Softwareumfeld entwickelt. Mittlerweile bewegt sich dieses Vorgehensmodell jedoch nicht mehr nur in seinem originären Bereich, sondern kann allgemein im Bereich Produktentwicklung eingesetzt werden. Dem Entwicklungsprozess von Software wird unterstellt, so umfassend zu sein, dass eine detaillierte Planung der einzelnen Schritte vorab nicht möglich ist. Somit sind regelmäßige Prüfungen und Transparenz zentrale Elemente. Sämtliche Prozessschritte sind dann für alle Beteiligten ersichtlich. Das sind Grundvoraussetzungen, um zum einen unerwünschte Veränderung umgehend festzustellen und zum anderen schnell korrigierend eingreifen zu können. Das erscheint zunächst nicht sehr neu. Was allerdings bei Scrum und anderen Methoden, wie beispielsweise dem Lean Start-up, mehr in den Vordergrund rückt, ist die Dauer bis zu einer Prüfung. Diese ist deutlich kürzer als bei traditionellen Projektmethoden, wie zum Beispiel beim Wasserfall. Auf diesen Aspekt wird in diesem Buch noch näher eingegangen, sobald wir uns dem Thema Sprint widmen.
Neben den drei Säulen besteht der Scrum Guide seit 2016 aus fünf Werten, die das Rahmenwerk unterstützen und komplettieren: Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt (siehe Abbildung 1). Die Personen im Entwicklungsteam verpflichten sich gemeinsam, die Ziele zu erreichen und schaffen dadurch eine kollektive Selbstverpflichtung. Durch Mut sollen komplexe Aufgabenstellungen mithilfe kreativer Lösungen realisiert werden. Der Fokus des Entwicklungsteams liegt ausschließlich auf dem Erreichen des gemeinsamen Ziels. Dabei sollen sich die Tätigkeiten auf die wesentlichen Aktivitäten konzentrieren, um Kapazitäten nicht zu verschwenden. Durch Offenheit soll Herausforderungen und Erfolge verdeutlichen. Diese fünf Werte sollen zu kontinuierlichen Verbesserungen beitragen. Agile Entwicklung nach Scrum setzt einen verständnisvollen Umgang innerhalb des Entwicklungsteams voraus. Dieser umfasst gegenseitigen Respekt, Wertschätzung und die Berücksichtigung von individuellen Befindlichkeiten.
3.2Scrum Rollen
Ein Scrum Team hat immer einen Product Owner, einen Scrum Master und mehrere Entwickler. Die Verantwortung für das zu entwickelnde Produkt liegt beim Product Owner. Er ist daher insbesondere verantwortlich für die Wertmaximierung und die Qualität des Produkts. Das Entwicklungsteam arbeitet selbstorganisiert und in iterativen Schleifen am Projektprodukt. Ein Entwicklungsteam sollte mindestens drei und nicht mehr als neun Mitglieder haben, da der Kommunikationsaufwand mit jedem zusätzlichen Teammitglied erheblich zunimmt. In Abbildung 2 sieht man, dass bei einem Team mit sieben Mitgliedern 21 mögliche Beziehungen bestehen. Erweitert man das Team um nur zwei weitere Mitglieder ergeben sich bereits 36 Beziehungen. Bis zu 105 stolze Kommunikationsvariationen erreicht ein Team mit 15 Mitgliedern. Auf den Aspekt der Teamgröße wird in einem späteren Kapitel nochmals eingegangen, wenn die Zwei-Pizzen-Regel von Amazon vorgestellt wird.
Beziehungen innerhalb eines Teams
Die Kernaufgaben des Scrum Masters bestehen darin, im Team Verständnis für das Scrum Framework zu schaffen und dafür zu sorgen, dass das Regelwerk eingehalten wird. Zudem ist er Ansprechpartner, um alle Probleme zu beseitigen, die das Team an der Zielerreichung behindert. Dabei ist der Punkt Regelwerk ein Thema für sich. Während mit dem Begriff eine gewisse Starrheit und Gehorsam in der Führung assoziiert werden könnten, steckt darin bereits ein Grund, weshalb in der Praxis die Einführung von Scrum Probleme bereitet. Es geht weniger darum, Scrum à la Textbuch einzuführen, sondern die Gegebenheiten der Organisation miteinzubeziehen und die passende Variante von Scrum zu finden. Letztendlich ist das doch der Kern einer agilen Organisation, oder?
Bisher gab es mit dem Product Owner, dem Scrum Master und dem Development Team drei Scrum Rollen, die zusammen das Scrum Team bildeten. Im Scrum Guide 2020 wurde das Development Team gestrichen und die Rollen durch die drei Verantwortungen (Accountabilities) Scrum Master, Product Owner und Developer ersetzt. So kommt es nicht mehr zu der häufigen Frage, ob der Scrum Master oder der Product Owner nicht Teil des Teams sind. In Großunternehmen hat die bisherige Team-im-Team-Struktur häufig zusätzlich dazu geführt, dass unnötige Hierarchieebenen in die Scrum Teams einbezogen wurden und die Development Teams an ihre Product Owner berichten mussten. Mit der Abschaffung des Development Teams wird hervorgehoben, dass alle Mitglieder eines Scrum Teams gemeinsam für die produktbezogenen Aktivitäten verantwortlich sind. Dazu muss das Scrum Team so aufgestellt sein, dass es alle notwendigen Fähigkeiten vereint, um mit jedem Sprint mindestens ein neues Produktinkrement zu schaffen. Der Verantwortungsbereich eines Developers ist hierbei nicht auf die Softwareentwicklung begrenzt. Grafikdesigner, Experten aus dem Fachbereich oder Linienmanager können beispielsweise auch inhaltlichen Mehrwert liefern.
Das Scrum Team ist selbstverwaltend (self managing) und nicht mehr selbstorganisierend (self organised). In der Folge bedeutet das nicht nur einen Austausch der Begrifflichkeiten. Der Fokus wird dadurch noch stärker auf die Eigenverantwortung des Scrum Teams gelenkt. Allein das Team ist verantwortlich für alle produktbezogenen Aktivitäten. Hierfür muss es sich selbst verwalten. Es muss also dazu befähigt werden, selbst entscheiden zu können, welche Arbeiten wie zu erledigen sind und wer sich wann darum kümmert.
3.3Scrum Artefakte
Unter Artefakten versteht man Prozessdokumente, die während eines Projekts erstellt werden. Scrum kennt die drei Artefakte Product Backlog, Sprint Backlog und Produktinkrement. Das Product Backlog listet die priorisierten Anforderungen an das zu erstellende Produkt auf. Diese Aufstellung ist niemals vollständig und existiert in der Regel so lange, wie das Projektprodukt entwickelt wird. Der Product Owner ist für das Product Backlog verantwortlich und überarbeitet kontinuierlich die Backlog-Anforderungen und deren Prioritäten. Das bedeutet, dass er die Einträge regelmäßig verfeinert, das Backlog um neue Anforderungen erweitert und obsolet gewordene Anforderungen aus der Aufstellung löscht. Je wichtiger eine Anforderung ist, desto detaillierter muss sie ausformuliert und desto größer muss deren Priorität sein. Beschrieben werden die Anforderungen häufig in Form von User Stories. Das Sprint Backlog enthält die Product Backlog-Einträge, die in der aktuellen Projektiteration umgesetzt werden sollen. Diese Einträge werden auch als Sprint Backlog Items bezeichnet. Die Verantwortung für das Sprint Backlog liegt beim Entwicklerteam. Das bedeutet insbesondere, dass das Team entscheidet, welche Product-Backlog-Einträge es in der nächsten Iteration bearbeitet und wie diese in detaillierte Aufgaben (Tasks) unterteilt werden können. Während eines Sprints wird das Sprint Backlog nach der Erledigung eines Tasks vom Entwicklerteam aktualisiert. Das Ergebnis einer Iteration bezeichnet man als Produktinkrement. Dieses Artefakt besteht somit aus den in der aktuellen Iteration umgesetzten User-Stories und allen Anforderungen, die bereits in den vorherigen Iterationen realisiert wurden. Wichtig ist, dass jedes Produktinkrement release-fähig ist, also potenziell an den Kunden ausgeliefert werden kann.
Im neuen Scrum Guide wird das ProduktzielProduktziel (Product Goal) als zusätzliche Begrifflichkeit eingeführt. Dieses Ziel beschreibt, was der Sinn des zu erstellenden Produkts ist. Eine konkrete Benennung des Sinns vermeidet eine willkürliche Ansammlung von Features, Tasks und Defects. So steht das Produktziel als Leitbild über dem Product Backlog und mit jedem Sprint wird das Produkt näher an dieses Produktziel herangebracht.
Die Einführung des Produktziels ermöglicht es, jedem Scrum Artefakt eine klare Zuordnung (CommitmentCommitment) zuzuweisen: Das Produktziel gehört zum Product Backlog, das SprintzielSprintziel zum Sprint Backlog und die Definition of Done zum Produktinkrement. Diese drei Commitments sollen die Transparenz erhöhen und den Entwicklungsfortschritt sicht- und messbarer machen. Das Produktziel wird vom Product Owner entwickelt und gilt für das gesamte Scrum Team. Das Sprintziel wird vom Scrum Team festgelegt und ist die selbstverpflichtende Zielvorgabe für den aktuellen Sprint. Die Abschlusskriterien für ein Produktinkrement (Definition of DoneDefinition of Done) werden vom Scrum Team in Einklang mit den Organisationsvorgaben erstellt. Die Entwickler verpflichten sich dazu, diese Kriterien bei der Erstellung des Produktinkrements zu erfüllen.
Der Scrum Guide 2020 ermöglicht die Erstellung mehrerer Produktinkremente in einem Sprint. In der Vergangenheit war es notwendig, bis zum Sprintende zu warten, um ein neues Produktinkrement produktiv setzen zu können. Stattdessen gilt nun: Jedes Mal, wenn ein Product Backlog Item die Definition of Done erfüllt, gibt es ein neues Produktinkrement. Diese Inkremente können also auch während eines Sprints abgenommen und theoretisch ausgeliefert werden. Dadurch wird nicht nur eine kontinuierliche Auslieferung ermöglicht, die Änderung führt hoffentlich auch dazu, dass das Sprint Review nicht mehr als „Freigabe-Veranstaltung“ missinterpretiert wird. Ziel des Sprint Reviews ist es vielmehr, anhand der Prüfung der erstellten Produktinkremente neue Impulse für das Product Backlog zu bekommen, um so die zukünftigen Sprintziele noch besser am Produktziel ausrichten zu können. Damit sind wir bereits mittendrin in den Scrum Events.
3.4Scrum Events
Das Vorgehensmodell Scrum beinhaltet fünf Ereignisse mit festgelegter Dauer. Dazu gehören der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Der ein- bis vierwöchige Sprint repräsentiert einen vollständigen Iterationslauf. Innerhalb dieser Zeitspanne findet die eigentliche Entwicklungsarbeit statt und es werden die übrigen vier Ereignisse praktiziert. Endet ein Sprint, startet direkt im Anschluss die nächste Iteration. Ein Sprint kann vom Product Owner jederzeit abgebrochen werden. Der Sprint wird mit dem Ereignis Sprint Planning eröffnet. In diesem Meeting stellt der Product Owner das Ziel des Sprints vor. Das Entwicklungsteam erstellt das Sprint Backlog, indem es so viele Anforderungen aus dem Product Backlog übernimmt, wie es in einem Sprint umsetzen kann. Während des Sprints findet täglich zur gleichen Zeit das Daily Scrum statt. Dies ist ein kurzes Meeting, in dem jeder Entwickler auf seine aktuelle Arbeit eingeht und den Fortschritt bis zum nächsten Daily Scrum prognostiziert. Hierzu beantworten die Entwickler üblicherweise nacheinander folgende drei Fragen:
Was war mein Beitrag zum Sprintziel seit dem letzten Daily Scrum?
Welche Aktivitäten plane ich bis zum nächsten Daily Scum?
Sehe ich Hindernisse, die mich oder das Entwicklungsteam vom Erreichen des Sprintziels abhalten?
Die beiden übrigen Ereignisse folgen am Ende eines Sprints. Zunächst wird im Sprint Review das erstellte Produktinkrement vorgestellt. An dieser Veranstaltung nehmen das ganze Scrum Team und die Projekt Stakeholder teil. Ziel ist es, von den Stakeholdern ein Feedback über das Produktinkrement zu erhalten. Dieses wird anschließend genutzt, um das Product Backlog anzupassen und um neue Anforderungen aufzunehmen. In der abschließenden Sprint Retrospektive reflektiert das Team den Verlauf und diskutiert Verbesserungsmöglichkeiten für den nächsten Sprint.
Während eines Sprints findet die Entwicklungsarbeit an den Sprint Backlog Items statt. Gestartet wird mit dem Sprint Planning Meeting. In dieser Besprechung fokussiert man sich auf folgende zwei Fragestellungen: Was kann in diesem Sprint realisiert werden und wie wird diese Arbeit umgesetzt? Das Entwicklungsteam übernimmt im ersten Teil der Planungssitzung so viele User Stories aus dem Product Backlog in das Sprint Backlog, wie es im Sprint umsetzen kann. Hieraus abgeleitet formuliert das gesamte Scrum Team das Ziel des Sprints. Im zweiten Teil überlegt das Entwicklungsteam, welche Tasks zum Erreichen ihres Sprintziels und zur Abarbeitung der ausgewählten Product Backlog-Items notwendig sind.
Im Sprint Planning ging es bisher um die Beantwortung von zwei zentralen Fragestellungen: Die Entscheidung, welche Product Backlog Items im nächsten Sprint bearbeitet werden sollen und wie diese realisiert werden können. Im aktuellen Scrum Guide kommt nun eine dritte Fragestellung hinzu: Warum ist der Sprint sinnvoll bzw. wie kann der Wert des Sprints am effektivsten maximiert werden? Mit der genauen Beschreibung dieses Sprintziels bekommt das selbstverwaltende Team eine klare Richtschnur für den Sprint.
In Abbildung 3 wird das Zusammenspiel der Scrum Rollen, der Scrum Events, der Scrum Artefakte und der zugehörigen Commitments dargestellt.
Scrum Framework
4Scrum Rollen – Die Idealbesetzung eines Scrum Teams
Unsere Reise in Scrum ist weniger auf den Individualtouristen ausgerichtet, sondern erlangt seine volle Pracht erst in einer Gruppe, die zu einem echten Team werden soll. Lernen Sie daher die Wege kennen, die auch abseits grauer Theorie einen perfekten Blick auf das Wesentliche bei der Teamzusammensetzung geben.
4.1Passende Rollenbesetzung als Erfolgsschlüssel
Wie in jedem Team ist die passende Rollenbesetzung wichtig. Eine Reisegruppe zu den Pyramiden Südamerikas hat viel mehr Spaß, wenn ein kenntnisreicher Reiseführer dabei ist. Eine Fußballmannschaft ohne Torwart dürfte es schwer haben, Spiele zu gewinnen. Und auch ein American Football Team dürfte vor großen Herausforderungen stehen, ohne Quarterback im Super Bowl zu brillieren. Auch Scrum „benötigt“ bestimmte Rollen, damit es in der Praxis gut funktionieren kann.
Scrum macht es sich dabei sehr einfach, denn es gibt nur drei RollenScrum Rollen: Den Product Owner, den Scrum Master und das Entwicklungsteam. Wie die Rollenbezeichnungen schon andeuten, sind der Product Owner und der Scrum Master jeweils eine Person, das Entwicklungsteam jedoch eine Gruppe (siehe Abbildung 4).
Rollen in einem Scrum Team
Ein wesentlicher Aspekt von Scrum ist, dass es prinzipiell keine Hierarchien innerhalb des Teams gibt. Zwar hat jede Rolle die ihr zugeordneten Aufgaben, für die sie jeweils auch verantwortlich ist, aber ein hierarchisches Gefälle, in dem eine Person Anweisungen erteilt, die dann nur noch von anderen ohne Hinterfragen umgesetzt werden, wird klar vermieden. Diese Freiheit hat Vor- und Nachteile. Einerseits wird das Wissen aller Teammitglieder eingebracht, was in der aktuellen VUCA-Welt sinnvoll und notwendig ist – die notwendige Expertise für eine Produktentwicklung konzentriert sich auf Grund der Komplexität nicht in einem Individuum. Andererseits gibt es in der Praxis Momente, in denen der eine oder die andere sich ein bisschen „Basta“-Mentalität zurückwünscht, um längere Diskussionen abwürgen zu können. Und damit sind wir schon bei einem Kernthema von Scrum und von agilen Arbeitsmethoden im Allgemeinen: Kommunikation. Agile Arbeitsmethoden benötigen zwingend deutlich mehr Kommunikation und Abstimmung als Wasserfall-Methoden.
Wenn es keine Hierarchien innerhalb des Teams gibt, bedeutet das zusätzlich, dass das Team sich selbst organisieren muss. Selbstorganisierende Teams sind derzeit äußerst beliebt und finden als Schlagwort Eingang in viele Reden, Präsentationen und Veröffentlichungen (wie auch in diese). Aber was bedeutet Selbstorganisation überhaupt für ein Scrum Team? Wo liegen die Schwierigkeiten? Wie sieht das in der Praxis aus? Und kann das überhaupt funktionieren oder ist es eine Wunschvorstellung vom idealen, aber nie zu erreichenden Team Utopia? Die gute Nachricht ist, es kann funktionieren. Die Schlechte ist, es gestaltet sich oft schwieriger als es oft erwartet wird. Selbstorganisation bedeutet, dass das Scrum Team die Art und Weise der Zusammenarbeit innerhalb eines vorgegebenen Frameworks selbst definiert. Orchestriert wird das Ganze vom Scrum Master. In der Praxis kann dies eine Herausforderung für den Scrum Master sein. Dafür gibt es zwei Gründe: Erstens befürchten viele Manager einen gewissen Kontrollverlust, wenn sie dem Scrum Team nicht die Art und Weise der Zusammenarbeit vorgeben können. Zweitens fällt es manchen Mitarbeitern schwer, mit der neugewonnenen Freiheit umzugehen. Dies ist umso verständlicher, wenn man berücksichtigt, dass viele Unternehmen die letzten Jahre oder Jahrzehnte in einer Wasserfallwelt zuhause waren, in der sich eine Kultur der Compliance entwickelt hat. In einem solchen Umfeld wurde den Mitarbeitenden wenig Freiheit gegeben, um eigene Ideen voranzutreiben und auszuprobieren. Wird nun Selbstorganisation über Nacht per Dekret eingeführt, weil das Wort häufig in Verbindung mit agilen Arbeitsweisen fällt, kann dies schnell zu einer Überforderung der Mitarbeitenden führen, die noch kein Vertrauen in die neue Herangehensweise entwickeln konnten. Die Ursache beider Punkte liegt im agilen Mindset, das sich erst noch im gesamten Unternehmen ausbilden muss. Dieser Vorgang benötigt Zeit und sollte durch einen umfassenden Veränderungsprozess begleitet werden.
Scrum Teams sind crossfunktional, was bedeutet, dass innerhalb des Teams alle Fähigkeiten vorhanden sind, die für die Erreichung des Produktziels notwendig sind. Nehmen wir als Beispiel eine Webapplikation, die unter Verwendung von Wetter- und Verkehrsdaten die Besuchszahlen für einen Zoo vorhersagen will. Ein solches Scrum Team könnte aus einem Product Owner, einem Scrum Master und Entwicklern bestehen, die folgende Fähigkeiten bereithalten: UX/UI-Design, Frontend- und Backendentwickler, Testentwickler, Datenbankentwickler, Data Scientist.
Das obige Team würde aus circa sieben Mitgliedern bestehen (abhängig davon, ob bestimmt Fähigkeiten in einer Person vereint sind oder, ob bestimmte Kompetenzen mehrfach vorhanden sein müssen). Die Frage nach der Größe eines Scrum Teams wird vor dem Beginn des Projektes beantwortet. Folgende Faustregel kann dabei verwendet werden: Das Scrum Team sollte klein genug sein, um flexibel agieren zu können und den Kommunikationsaufwand nicht zu groß werden zu lassen. Gleichzeitig sollte es groß genug sein, um einen signifikanten Fortschritt zu erzielen. Typischerweise liegt die Zahl zwischen sieben und neun Teammitglieder. Kleine Teams sind meist produktiver und kommunizieren effizienter. Jeff Bezos hat bei Amazon die Zwei-Pizzen-Regel eingeführt, um die ideale Teamgröße für ein produktives Arbeiten zu bestimmen (siehe Abbildung 5).
Performance – Teamgröße
Sie besagt, dass an einem Meeting nur so viele Mitarbeiter teilnehmen dürfen, wie von zwei Pizzen satt werden. (Achtung, gemeint sind amerikanische Pizzen, die im Gegensatz zu europäischen Pizzen einen Durchmesser von 40 cm anstatt von 26 cm haben. Von einer amerikanischen Pizza werden vier Personen satt.) Die Anzahl an Teilnehmern ist demnach auf acht beschränkt. So willkürlich diese Zahl erscheinen mag, sie ist wissenschaftlich fundiert und wird auch von Bob Sutton in seinem Buch Scaling Up Excellence: Getting to More without Settling for Less bestätigt. Wird ein Team zu groß, sollte das Team in kleinere Einheiten zerteilt werden. Ab jetzt betreten wir den Bereich der Skalierung von agil, der wir uns später in einem separaten Kapitel widmen. So viel sei bereits an dieser Stelle gesagt: Wird das Thema Skalierung nicht umfänglich durchdacht, was in der Praxis häufiger vorkommt, kann dies mittel- und langfristig sowohl zu funktionalen als auch technischen Problemen führen, die nur mit einem enormen Zeit- und Kostenaufwand wieder beseitigt werden können.
Scrum Teams kümmern sich um alles Produktbezogene. Das umfasst unter anderem das Stakeholder Management, das Erfassen und die Verifikation von Anforderungen (in Form von Epics und User Stories), die Entwicklung eines wert- und sinnvollen Produktinkrements am Ende eines Sprints, den operativen Betrieb und was sonst noch alles anfallen könnte. In einem solchen Szenario kann es zu Situationen kommen, in denen die Teammitglieder eigenverantwortlich Entscheidungen im Sinne des Produktes treffen müssen. Um die Produktivität des Teams durch aufwendige Rücksprachen dazu nicht zu behindern, ist ein gewisser Spielraum förderlich, indem selbst Entscheidungen getroffen werden dürfen. Hierbei spricht man von Empowerment. Es ist ein wesentlicher Erfolgsfaktor von agilen Teams, wenngleich sich dieser Aspekt auf Grund der bereits oben genannten Herausforderungen als schwierig in der Praxis erweisen kann.
4.2Entwickler als T-Shaped Professionals
Die Hauptaufgabe der Entwickler ist es, ein nutzbares Produktinkrement am Ende eines Sprints erzeugt zu haben. Wir werden in Kapitel 5.5 und 5.6 noch einmal intensiv auf diesen Punkt eingehen, da er ein essenzieller Bestandteil von Scrum ist und in der Praxis manches Mal falsch umgesetzt wird. Die Betonung liegt insbesondere auf nutzbares Produktinkrement, also etwas, was Fachabteilungen im operativen Geschäft verwenden können und das einen Nutzen, einen Mehrwert, bringt.
Die lediglich drei vorhandenen Rollen in Scrum erwecken den Eindruck, dass Vorgehensmodell sei einfach umzusetzen und strukturiert. In der praktischen Anwendung führt ebendiese Einfachheit jedoch gelegentlich zu Verwirrungen. Das Verständnis für das Konzept crossfunktionaler Teams ist deshalb umso wichtiger. Crossfunktional bedeutet, dass in einem Entwicklerteam alle notwendigen Kenntnisse, um ein Produktinkrement zu erzeugen, vorhanden sind. Zerlegen wir als Beispiel einen Softwareentwicklungsprozess in drei Schritte: Analyse, Programmierung, Testen. Ein Scrum Team würde mindestens diese drei Fähigkeiten abbilden müssen. Im Idealfall wird jeder Schritt von einem Experten begleitet, der über zusätzliches Know-how in den anderen Bereichen verfügt. Solche Teammitglieder bezeichnet man als T-Shaped ProfessionalsT-Shaped Professional (siehe Abbildung 6). Der große Vorteil besteht darin, dass T-Shaped Professionals Tiefenwissen (Expertenwissen) in einem Bereich besitzen und zeitgleich über ein Breitenwissen aus anderen Bereichen verfügt. Solche Mitarbeiter haben in der Regel einen scharfen Blick für das große Ganze und greifen die Gesamtzusammenhänge schnell; eine Fähigkeit, die besonders in dynamischen und agilen Arbeitsumgebungen von Vorteil ist.
T-Shaped Professionals
Um die oben beschriebene Hauptaufgabe, ein nutzbares Produktinkrement am Ende eines Sprints zu erzeugen, erreichen zu können, sind folgende Tätigkeiten ebenfalls in der Verantwortung des Entwicklerteams: Das Team erzeugt einen Plan für den Sprint, das sogenannte Sprint Backlog. Hierin werden alle Aufgaben, die innerhalb des Sprints erledigt werden sollen, transparent aufgelistet. Um jedoch eine zielgerichtete Erledigung der Aufgaben zu gewährleisten, ist es notwendig, Abhängigkeiten bereits im Vorfeld zu identifizieren und die Planung entsprechend anzupassen. Wird dieser Punkt nicht beachtet, könnten einzelne Aufgaben die Tätigkeiten anderer Teammitglieder blockieren und somit die Erreichung des Sprintziels gefährden. Das Entwicklerteam ist maßgeblich für die Qualität des Produktes zuständig. Hierbei ist vor allem die Definition of Done wichtig, die konkret definiert, wann eine bestimmte Aufgabe oder User Story fertiggestellt ist. Qualität sollte dabei bereits als integraler Bestandteil des Entwicklungsprozesses gesehen werden, um sie von vornherein in das Produkt zu integrieren und nicht erst anschließend in aufwendigen Testphasen zu ergänzen. Dieser Umgang mit Qualität ist eine Umsetzung des Andon Cords, dass bei Toyota Verwendung findet und zu einer enormen Steigerung der Qualität geführt hat. Das Andon Cords ist eine Leine, die jeder Mitarbeiter entlang der Produktionsstrecke ziehen kann – und damit die gesamte Produktion stoppt –, sobald ihnen Qualitätsmängel auffallen. Als Folge werden Probleme und Qualitätsmängel frühzeitig im Prozess erkannt und können kostengünstiger korrigiert werden, als wenn man diese nach der Produktion feststellt. Die tägliche Anpassung des Plans gehört deshalb zu den Aufgaben eines Entwicklerteams. Die Korrekturen finden im Rahmen der Daily Stand-ups statt. Sie dienen dazu, den Weg zum Sprintziel zu optimieren und somit das Ziel schneller, effizienter oder günstiger zu erreichen. Veränderungen, die keinen Einfluss auf die Erreichung des Sprintziels haben sind obsolet. Darüber hinaus trägt jedes Teammitglied die Verantwortung, sich selbst und die anderen immer wieder aufs Neue in die Pflicht zu nehmen, die vereinbarten Ergebnisse im Rahmen eines Sprints zu erreichen.
4.3Scrum Master als Servant Leader
Die Rolle des Scrum MastersScrum Master
