Agiles Projektmanagement und Scrum E-Book

Patric Eid

• Herausgeber: Books on Demand
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2019

Seitenzahl: 134

Beschreibung

Das Praxishandbuch Agiles Projektmanagement und Scrum vermittelt einen Überblick über das agile Framework Scrum. Zudem wird aufgezeigt, wie sich Scrum im Rahmen eines Projektes einsetzen lässt. Die Phasen eines agilen Projekts werden beschrieben und der Workflow von der Projektbeauftragung bis hin zur Umsetzung skizziert. Durch praxisnahe Beispiele und Erfahrungen ergänzt, liefert das Buch einen Ausblick auf erfolgreiches Projektmanagement mit Hilfe von agilen Praktiken.

Leseprobe

„Richtig ist, was funktioniert“

Inhaltsverzeichnis

1.

Einleitung

1.1 Das Konzept dieses Buchs

1.2 Das Ziel

2.

SCRUM - Definition

2.1 Was ist Scrum?

2.2 Das agile Manifest

2.3 Wie ist Scrum entstanden?

3.

Das SCRUM 3 x 3 x 5

3.1 Rollen

3.1.1 Scrum Development Team

3.1.2 Scrum Master

2.I Stolperfallen

3.1.3 Product Owner

3.I Stolperfallen

3.1.4 Kunden

3.1.5 Management

3.2 Scrum Ereignisse

3.2.1 Sprint

3.2.2 Sprint Planning 1 – was soll umgesetzt werden?

2.I Zusammenfassung

2.II Was sind User Stories?

3.2.3 Sprint Planning 2 – wie wird es umgesetzt?

3.I Zusammenfassung

3.II Was sind Tasks?

3.2.4 Sprint Review

4.I Zusammenfassung

3.2.5 Sprint Retrospective

5.I Teil 1 – Team-Metriken

5.II Teil 2 – was lief gut?

5.III Teil 3 – Gedanken-Reset

5.IV Teil 4 – was lief noch nicht optimal?

5.V Teil 5 – Aktionsplan aktualisieren

5.VI Zusammenfassung

5.VII Stolperfallen

3.2.6 Backlog Refinement

6.I Zusammenfassung

3.2.7 Daily Scrum

7.I Zusammenfassung

7.II Stolperfallen

3.2.8 Scrum-of-Scrums

8.I Zusammenfassung

3.3 Artefakte

3.3.1 Product Backlog

1.I Vereinfachte Berechnung der Priorität

1.II Komplexe Prioritätsberechnung

1.III Was ist der Business Value?

3.3.2 Sprint Backlog

3.3.3 Release Backlog

3.3.4 Impediment Backlog

3.3.5 Definition of Ready (DoR)

3.3.6 DoR mittels INVEST

3.3.7 Definition of Done (DoD)

3.3.8 Increment

3.3.9 Dokumentation als Increment

4.

Zusammenfassung

4.1 SCRUM 101

4.1.1 Inkrement am Ende des Sprints

4.1.2 Product Owner

4.1.3 Scrum Master moderiert das Daily Scrum

4.1.4 Empowerment des Product Owners

4.1.5 Sprint Backlog

4.1.6 Aufgabe des Managements in SCRUM

4.1.7 Development Team

4.2 Wie erkenne ich MURCS?

4.3 In a nutshell

5.

Alternative agile Prozesse

5.1 Extreme Programming

5.2 Kanban

5.3 Weitere agile Prozesse

6.

Agile Teams

6.1 Definition von „Team“

6.1.1 Gemeinsames Ziel anstatt persönliches Ziel

6.1.2 Inspect & Adapt

6.1.3 Wissensaustausch

6.1.4 Offene Feedback-Kultur

6.1.5 Optimaler Kundennutzen

6.1.6 Kundenfeedback einfordern

6.2 Die Stufen der Team-Entwicklung

6.3 Maßnahmen zur Team-Entwicklung

6.4 Der Team-Vertrag.

6.4.1 Grundgerüst Team-Vertrag

6.5 Zusammenfassung

7.

Prozess der Aufgabenplanung

7.1 Story Points anstelle von Aufwandsschätzungen

7.2 Requirements-Engineering

7.3 Erkennen von unklaren Anforderungen

7.4 Einsatz von Burn-Down-Graphen

7.5 Ermitteln der Team-Velocity

8.

Agile Projektentwicklung

8.1 Was ist ein Projekt?

8.2 Agiles Projekt

8.2.1 Project Inception und Master Stories

8.2.2 Projekte mit Scrum

8.3 Von der Idee bis zum Release und der Wartung

8.4 Master Stories und Epics

8.5 Project Inception

8.5.1 Projekt-Name

8.5.2 Elevator Pitch

8.5.3 Prioritäten-Schieber

8.5.4 Projektinhalt

8.5.5 Nicht-funktionale Requirements

8.5.6 Risikominimierung

8.5.7 Rollen

8.5.8 Stakeholder

8.5.9 Release-Plan

8.6 Project Inception Vorlage

8.7 Werkzeuge

8.7.1 Burn-Up-Chart

8.7.2 Release Rollout Plan

8.7.3 Test Plan

8.7.4 Projekterfolgsrechnung

8.7.5 Vereinfachte Projekterfolgsrechnung

9.

Projekt-Workflow

9.1 Vision

9.2 Project Inception

9.3 Backlog füllen

9.4 Vorbereitung Sprint 1 durch SPIKE

9.5 Der Sprint-Zyklus beginnt

9.6 Parallel dazu: Roadmap

9.7 Das Produkt entsteht inkrementell

10.

Mut zum Spielen!

10.1 Scrum spielerisch lernen mit Lego Duplo

10.2 LeSS Duplo

10.3 Sin-Obelisk

10.4 Synergie-Effekte erkennen

10.5 Klavierstimmer in Chicago

10.6 Ball Point Game

11.

Resümee

11.1 Scrum erfolgreich einsetzen

11.2 Scrum im Projektmanagement einsetzen

11.3 Agil eignet sich nicht immer

11.4 Voraussetzungen für agiles Arbeiten

11.5 Agile Führungskraft als Servant Leader

11.6 Scrum im skalierten Umfeld

12.

Glossar

13.

Literaturverzeichnis

14.

Zum Autor

1 Einleitung

SCRUM ist ein Konzept für eine interagierende und transparente Arbeitsweise, die ein hohes Maß an Selbstorganisation fördert und fordert und die Mitarbeiter aktiv in die Produktentwicklung integriert. Es besteht aus wenigen aber dafür klaren Regeln. Die Mitarbeiter eines agilen Teams erhalten die Verantwortung über den Produkterfolg und es gibt keine Hierarchie innerhalb des Teams.

Doch Scrum kann sein Potential nur entfalten, wenn es richtig eingesetzt wird. Schnell wird aus der tollen Idee Scrum zu machen nur „Murcs“. Denn nicht überall wo Scrum drauf steht, ist auch wirklich Scrum drinnen. Und so steht auch auf diesem Buch „Scrum“ drauf und was werden wir darin finden?

Scrum eignet sich sehr gut für die Produktentwicklung, wo ein Team über einen sehr langen Zeitraum hinweg konstant zusammenarbeitet. Ferner gibt es eine klare Produktvision und mehr Spielraum bzgl. Zeit und Inhalt als es bei einem klassischen Projekt der Fall ist. Die Definition eines Projektes wiederum scheint dem agilen Gedanken zu widersprechen, denn ein Projekt soll planbar sein mit einem klaren Ziel; zudem spezifisch, messbar und abgrenzbar. Qualität, Zeit und Kosten werden in Konstellation zueinander gebracht.

Was bedeutet agil?

Mit agilen Methoden reagieren wir auf änderbare und anpassbare Situationen, wenn die Anforderungen zu Beginn zum Teil oder noch ganz unklar sind und wir uns in einem dynamischen Umfeld bewegen. Passen Agilität und Projektmanagement zusammen?

1.1 Das Konzept dieses Buchs

Das „Praxishandbuch Agiles Projektmanagement und Scrum“, welches Sie in den Händen halten, liefert einen Überblick über das agile Framework Scrum und beleuchtet mit Kanban noch ein zweites agiles Modell. Anschließend erfolgt ein Schnelleinstieg in agiles Projektmanagement, bevor es zu einer Verschmelzung von agilem Projektmanagement und Scrum kommt.

Das erwartet Sie in diesem Praxishandbuch

Theorie: Scrum und agiles Projektmanagment werden theoretisch dargestellt. Die Rollen und Meetings werden definiert und erklärt und ein Gesamtbild entsteht.

Praxisbezug: In allen Kapiteln werden über Scrum hinaus weitere Methoden, Tipps und Handlungsempfehlungen gegeben, die eine Übernahme der Methodiken in die Praxis erleichtern soll.

Das Buch beginnt mit der Definition der Rollen in Scrum, die Meetings werden erklärt und die Besonderheiten von Scrum herausgestellt.

Anschließend erfolgt der Projekteinstieg mit dem Projektauftrag und dem Aufsetzen eines agiles Projekts. Scrum wird in das Projekt integriert und es werden weitere Artefakte hinzugefügt.

Am Ende des Buches werden Sie einen Überblick über folgende Themen erhalten haben:

Agile Softwareentwicklung: Begriffe und Methoden

Definition von Scrum, dem Scrum Flow und den Rollen in Scrum

Scrum-Meetings (Daily Scrum, Sprint Planning 1 und 2, Sprint Retrospective, Sprint Review)

Die Auswirkung von Scrum auf Team-Zusammenhalt, Interaktion mit Vorgesetzten und Kunden, gemeinsame Planung und transparente Umsetzung von Aufgaben

Agiler Werkzeugkasten (Praktiken und Methoden)

Agiles Projektmanagement: Rolle des Projektleiters, Meilensteine, Stakeholder, Aufgabenplanung und Fortschrittsvisualisierung

Anmerkung des Autors:

Ich bitte Sie um Verständnis, dass ich im gesamten Buch die traditionelle männliche Schreibweise gewählt habe. Dies soll Sie keineswegs diskriminieren oder demotivieren, sondern es dient lediglich der Lesbarkeit des Textes.

1.2 Das Ziel

Das große und ehrgeizige Ziel dieses Buches ist es, Ihnen in nur wenigen Seiten die Vorteile des Einsatzes von agilem Projektmanagement näher zu bringen und aufzuzeigen, dass Scrum auch im Projektmanagement eingesetzt werden kann.

Doch Vorsicht: nicht jedes Projekt ist für das agile Projektmanagement geeignet. Allerdings können gewisse Vorzüge aus dem agilen Projektmanagement auch in klassischen Projekten integriert werden, so dass ein hybrides Projektmanagement entsteht.

2 SCRUM - Definition

2.1 Was ist Scrum?

Scrum ist ein agiler Prozess. Der Begriff Scrum hat seinen Ursprung in der Sportart Rugby und heißt aus dem Englischen übersetzt „Gedränge“. Das angeordnete Gedränge ist dabei die Standardsituation, das Spiel nach Unterbrechungen fortzusetzen. Im Rugby geht es sehr rau zu, allerdings werden die Rugby-Regeln dabei stets verfolgt. Ähnliches ist bei Scrum zu beobachten: es gibt nicht viele Regeln im Scrum-Alltag, doch diese werden durch die Beteiligten eingehalten und machen Scrum aus. Begriffe wie Transparenz, Kommunikation und Team-Arbeit stehen für Scrum und prägen das agile Arbeiten.

Abbildung 1: Mindmap mit typischen Scrum-Begriffen

2.2 Das agile Manifest

Als agiler Prozess verkörpert Scrum die Werte des Agilen Manifests (engl. Agile Manifesto) [AGILE01]. Diese Werte der agilen Softwareentwicklung wurden 2001 festgehalten und beinhalten:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Ins Deutsche übersetzt:

Individuen und Interaktionen

mehr als Prozesse und Werkzeuge

Funktionierende Software (bzw. Produkte)

mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden

mehr als Vertragsverhandlung

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.“

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

Daraus wurden zwölf Prinzipien abgeleitet, denen die Unterzeichner folgen wollten.

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Heißen Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

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.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Aus diesen zwölf Prinzipien lässt sich für viele klassiche Vorgehensweisen bereits erahnen, dass für die Implementierung agiler Methoden ein Paradigmenwechsel notwendig ist. Darauf wird in den nachfolgenden Kapiteln, vor allem im Bereich des Resümees nochmals eingegangen.

2.3 Wie ist Scrum entstanden?

Ikujirō Nonaka und Hirotaka Takeuchi gelten als bedeutende Mitbegründer des Wissensmanagements. Im Jahr 1986 erschien ihr Artikel „The New New Product Development Game“ in der Harvard Business Review, welcher als Grundstein für das moderne Projektmanagement gilt. In diesem Artikel wurden die Worte Scrum und Sprint verwendet, welche aus Rugby entlehnt worden waren.

Jeff Sutherland hat in den 1980er Jahren Erfahrungen mit gut und weniger gut laufenden Projekten gesammelt. Dies veranlasste ihn dazu, die gut gelaufenen Projekte näher zu beleuchten und das, was gut klappte, auf andere Projekte zu übertragen. Im Laufe der Jahre wurde die Methode formalisiert, bevor sie in den 1990er Jahren erste Anwendung fand. Das erste Scrum-Projekt wurde 1993 durchgeführt [RPILC09].

3 Das SCRUM 3 x 3 x 5

Wie bereits erwähnt, bringt Scrum an sich nur wenige Regeln mit. Im Grunde basiert Scrum auf 3 Rollen, 3 Artefakten und 5 Ereignissen. Die jeweiligen Rollen, Artefakte und Ereignisse werden im Anschluss in entsprechenden Kapiteln näher erläutert.

3 Rollen

Scrum Master

Product Owner

Development Team

3 Artefakte

Product Backlog

Sprint Backlog

Increment

5 Ereignisse

Sprint

Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

3.1 Rollen

Im Kern besteht Scrum aus den drei Rollen des Scrum Development Teams, des Scrum Masters und des Product Owners. Bisweilen (z.B. in der Literatur von Boris Gloger [BGLOGER]) werden darüber hinaus noch die Rollen User, Kunden und Management beschrieben, die für die erfolgreiche Implementierung von Scrum in Unternehmen eine entscheidende Rolle spielen. In diesem Buch werden zu den drei Scrum-Rollen noch Kunde und Management betrachtet.

Die drei Rollen Scrum Development Team, Scrum Master und Product Owner bilden das Scrum-Team. Alle drei Rollen arbeiten eng zusammen, um gemeinsam das Produkt zu entwickeln. Product Owner und Scrum Master werden jeweils durch eine Person repräsentiert, die zu 100% in der Rolle für das Scrum Team fungieren kann. Das Scrum Development Team besteht aus den Experten, die benötigt werden, um das Produkt entwickeln zu können. Um die drei Rollen schnell zu erklären, kann man sagen, dass das Scrum Development Team für die eigentliche Entwicklung des Produkts, der Scrum Master für die erfolgreiche Umsetzung des Prozesses und der Product Owner für das Bereitstellen der definierten Aufgaben zuständig ist.

Unrealistische 100%-Besetzung?

Idealerweise sind sowohl Product Owner als auch Scrum Master zu je 100% für das Scrum Team abgestellt und nehmen keine andere Funktion im Unternehmen ein.

Doch in der Praxis ist dies meist nicht möglich. So kann es sein, dass ein Mitglied des Scrum Development Teams auch die Rolle des Scrum Masters einnimmt. Oder dass der Scrum Master auch gleich der Product Owner ist.

Generell ist das nicht schlecht. Doch gerade bei neu zusammengesetzten Teams, die zudem noch unerfahren mit Scrum sind, machen 100%-Besetzungen Sinn. Nur so kann der Scrum-Prozess richtig in das Team übernommen werden und der Product Owner genügend Zeit aufbringen und Hilfe für das Wahrnehmen seiner Aufgabe erhalten.

Im Folgenden werden die einzelnen Rollen und deren Aufgaben genauer erläutert.

3.1.1 Scrum Development Team

Abbildung 2: Scrum Development Team

Scrum Development Team im Überblick

Das Kernteam des Scrum Teams besteht aus Experten und ist idealerweise interdisziplinär aufgestellt. Kommunikation und gegenseitige Wertschätzung sind essentiell für ein gut funktionierendes Scrum Team. Ohne das Scrum Development Team geht gar nichts.

Das Scrum Development Team besteht u.a. aus Entwicklern, Testern, Analysten und Grafikern. Das Team ist interdisziplinär aufgestellt und beinhaltet alle Kompetenzen, das es benötigt, um das geforderte Produkt umzusetzen.

Die Mitarbeiter im Scrum Development Team arbeiten eng zusammen und interagieren miteinander regelmäßig, u.a. täglich beim sog. Daily Scrum. Das Scrum Development Team ist selbstorganisiert, verfügt über ausreichende Berechtigungen und Vollmachten, ist im Optimalfall nicht räumlich voneinander getrennt und trägt die Verantwortung für die Qualität der Resultate.

Idealerweise besteht ein Scrum Development Team aus 5 bis 9 Mitgliedern. Generell sollte das Team groß genug sein, um in einem Sprint für das Produkt einen Mehrwert schaffen zu können. Andererseits sollte es nicht zu groß sein, um keine unnötige Komplexität in die Arbeitsabläufe zu bekommen.

Das Scrum Development Team bekommt von niemanden gesagt was zu tun ist und wie es umgesetzt werden soll. Dies geschieht in Eigenverantwortung in Abstimmung mit dem Product Owner.

3.1.2 Scrum Master

Abbildung 3: Scrum Master

Scrum Master im Überblick

Der Scrum Master ist sozusagen Bob der Scrumeister. Er hat die stetige Weiterentwicklung des Teams und der Organisation im Blick. Ohne ihn geht gar nichts.

Der Scrum Master ist der Hüter des Prozesses, er fungiert als Schutzschild für das Scrum Development Team und hilft sowohl dem Product Owner als auch der Organisation, Scrum erfolgreich anzuwenden.

Der Scrum Master ist dabei das Bindeglied zwischen dem Scrum Development Team und dem Management. Es ist die Aufgabe des Scrum Masters das Scrum Development Team zu begleiten und zu unterstützen, auf die Einhaltung der Regeln zu achten, Hindernisse aus dem Weg zu räumen, Meetings zu moderieren und für Transparenz zu sorgen. Ferner ist der Scrum Master dafür verantwortlich, Team-Mitglieder zu schulen, damit diese ihre Rollen optimal einnehmen können, den Scrum-Prozess zu optimieren und in der Organisation zu etablieren.

Der Scrum Master steht ein wenig außerhalb des Teams. Er ist kein direktes Team-Mitglied, aber auch nicht komplett losgelöst vom Team.

Eine (nicht vollständige) Auflistung der Verantwortlichkeiten des Scrum Masters sind:

sorgt dafür, dass Scrum funktioniert

setzt sich für die Organisationsentwicklung ein

hilft bei der Organisation im Team

führt eine kontinuierliche Prozess-Optimierung durch

stimmt sich mit anderen Scrum Mastern ab

sorgt für die Abstimmung mit anderen Teams

pocht auf Regeln und Meetings

unterstützt den Product Owner bei Bedarf

moderiert Meetings

Schutzschildfunktion (schützt das Team vor äußeren Störfaktoren)

Bindeglied zum Product Owner

das gute Herz des Teams

fordert Dokumentation ein und erstellt ggf. Meeting Minutes

beschafft Informationen/Räume/Material

beseitigt Hindernisse (und deckt sie ggf. auf)