Scrum und Kanban - Doppelter Erfolg durch Kombination (Aktualisiert für Scrum Guide V. 2020) E-Book

Paul C. Müller

• Herausgeber: Books on Demand
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 87

Beschreibung

Warum nicht das Beste aus zwei Welten kombinieren und damit noch erfolgreicher entwickeln? Scrum.org als einer der international größten Zertifizierer hat mit der Professional Scrum Kanban (PSK I)-Zertifizierung einen Ansatz vorgelegt, der sich mit der erfolgreichen Kombination von Scrum und Kanban auseinandersetzt. Diesen Ansatz stellt der Autor vor, der selbst seit Jahren als Berater und Trainer in diesem Bereich tätig ist. Der Aufbau des Buches richtet sich dabei am Themenkatalog der Prüfung aus. Das Buch legt aber großen Wert darauf, nicht nur reine Prüfungsvorbereitung zu leisten, sondern den Fokus auf die Umsetzbarkeit im täglichen Leben zu legen. Das vorliegende Buch ist kein offizielles Lehrwerk der Scrum.org und unabhängig davon entstanden - Professional Scrum Kanban (PSK I) ist ein eingetragenes Warenzeichen der genannten Organisation. Das vorliegende Buch ist kein offizielles Lehrwerk der Scrum.org - Professional Scrum KanbanTM (PSK I) ist ein eingetragenes Warenzeichen der genannten Organisation. Es wurde basierend auf den Aussagen der Scrum Guide V. 2020 aktualisiert und angepasst.

Leseprobe

Inhalt

Vorbemerkung

Vorwort

Das Scrum-Framework verstehen und anwenden

Das agile Manifest

Zwölf Prinzipien des Agilen Manifests

Empirische Prozesssteuerung

Werte von Scrum

Rollen in Scrum

Scrum-Events

Scrum skalieren mit Nexus

Kanban und Scrum

Kanban: Definition

Kanban-Prinzipien

Die Prinzipien

Die Kernpraktiken

Kanban-Workflow

Push- und Pull-Systeme

Push-Systeme

Pull-Systeme

Theory of Constraints

Bedeutung für den Einsatz von Kanban

WIP-Limits

Aktives Management laufender Arbeitseinheiten

Service Level Expectation

Inspect und Adapt – Überprüfung und Anpassung

Der Einfluss von Kanban auf die Scrum-Events

Der Sprint

Sprint-Planning

Daily-Scrum

Sprint-Review

Sprint-Retrospektive

Der Einfluss von Kanban auf die Scrum-Rollen

Metriken

Work in Progress (WIP)

Zykluszeit – englisch: Cycle Time

Alter der Arbeitseinheit – englisch: WIP Age oder Work Item Age

Durchsatz – englisch: Throughput

Visualisierung mit einem CFD (Cumulative Flow Diagram)

Little’s Law

Die PSK-1 Zertifizierungsprüfung

Literaturliste

VORBEMERKUNG

Professional ScrumTM with Kanban Level I (PSK I) ist wie auch die weiteren im Buch genannten Scrum-Zertifizierungen Eigentum der Scrum.org. Das vorliegende Buch ist ohne Einflussnahme oder Auftrag der Scrum.org als Ausdruck der eigenen Auseinandersetzung des Autors mit den dargestellten Themen entstanden. Der einfacheren Lesbarkeit halber wurde im Text auf die Auszeichnung von Marken und Warenzeichen verzichtet. Diese sind aber jeweils mit gemeint und sollen so verstanden werden.

Grundsätzlich ist es sinnvoll, dass der Leser sich vor der Lektüre dieses Buches mit Scrum auseinandergesetzt hat. Dies muss nicht zwingend im Rahmen einer Zertifizierung sein; wer allerdings eine Scrum.org PSK-1-Zertifizierung anstrebt, dem sei eine vorgängige Ausbildung und Zertifizierung auf Ebene Product Owner oder Scrum-Master der Scrum.org ans Herz gelegt. Für all jene, welche diese Kenntnisse nicht besitzen, habe ich mich entschlossen, im Sinne eines Bonus das Kapitel “Das Scrum-Framework verstehen und anwenden” aus meinem Buch zur Agilen Leadership einzubinden.

Das bereits vorgelegte Buch wurde im Dezember 2020 basierend auf der Scrum Guide der Version 2020 (November 2020 erschienen) durchgesehen und wo notwendig angepasst.

Anmerkungen: Auch wenn die deutsche Übersetzung der Scrum-Guide die Rollen inzwischen mit Product Owner:innen etc. bezeichnet behalte ich der besseren Lesbarkeit die männliche Form bei.

VORWORT

Kanban oder Scrum? Manche Firmen führen darüber langwierige Diskussionen. Dabei verkennen sie allerdings, dass sich beide Herangehensweisen in keiner Weise widersprechen, sondern ganz im Gegenteil sehr gut kombiniert werden können. Der iterative Scrum-Prozess und die in Kanban praktizierte Prozess-Visualisierung und Optimierung lassen sich geradezu ideal verbinden. Dies kann insbesondere das Entwicklungsteam dabei unterstützen, seinen Entwicklungsprozess laufend zu optimieren, die dabei ermittelten Kennzahlen helfen aber auch darüber hinaus bei der Planung und der Kommunikation mit Stakeholdern.

Die Scrum.org hat dies längst erkannt und bereits vor einigen Jahren eine eigene Scrum- Kanban-Kombination durch eine Fachpublikation, den “Kanban Guide für Scrum-Teams”, unterstützt und prüft seither das entsprechende Wissen im Rahmen einer eigenen Zertifizierungsprüfung “PSK-1” (Professional Scrum Kanban).

Das vorliegende Buch habe ich für Personen geschrieben, welche ihre ersten Schritte mit der Kombiation beider Methoden machen möchten und sich auch auf die entsprechende Zertifizierungsprüfung vorbereiten. Es soll den Vorbereitungsprozess unterstützten. Dabei wird allerdings empfohlen, sich zusätzlich mit dem auf der Scrum.org-Webseite kostenlos verfügbaren Kanban-Guide für Scrum-Teams sowie den dort vorgeschlagenen Ressourcen auseinanderzusetzen. Ebenfalls sei dem Leser das “Scrum with Kanban Open“ auf der Scrum.org-Webseite ans Herz gelegt. Es ist eine kostenlose Möglichkeit, anhand einer Auswahl von Prüfungsfragen das eigene Wissen zu testen.

Viel Erfolg!

Der Autor

DAS SCRUM-FRAMEWORK VERSTEHEN UND ANWENDEN

Bevor wir uns mit der Frage beschäftigen, was Scrum ist und was agile Führung im Kontext von Scrum bedeutet, scheint es wichtig zu sein, sich zunächst damit auseinanderzusetzen, was Agilität eigentlich bedeutet. Welche Ideen stehen dahinter und welchen Nutzen soll uns Agilität bringen? Um das zu erkunden, ist es sinnvoll, sich zunächst mit dem agilen Manifest, sozusagen der Verfassung der Agilität, auseinanderzusetzen:

Das agile Manifest

Im Februar 2001 trafen sich in den Wasatch-Bergen des amerikanischen Bundesstaates Utah in einer Ski-Lodge siebzehn Menschen, um gemeinsam zu reden, Ski zu fahren und zu entspannen. Sie alle waren mit der Art und Weise, wie Software-Entwicklung stattfand, nicht zufrieden und glaubten, dass Alternativen zu dokumentationsträchtigen, schwergewichtigen Software-Entwicklungsprozessen notwendig seien.

Diese Gruppe organisatorischer Anarchisten, die sich «The Agile Alliance» nannten, formulierten und unterschrieben gemeinsam das «Agile Manifest». Dabei ist zu beachten, dass die anwesenden Personen später ganz unterschiedliche Wege gegangen sind und unterschiedliche Methoden und Frameworks basierend auf der gemeinsamen Grundlage «Agiles Manifest» entwickelt haben. (Mit-) Entwickler von «Extreme Programming», «Scrum», «DSDM», «Adaptive Software Development», «Crystal» und anderen legten hier einen gemeinsamen Grundstein für die weitere Entwicklung von Software-Entwicklung und in vielen Fällen auch für weit über die Software-Entwicklung hinausgehende Fragestellungen.

Weitere Informationen zur Entstehungsgeschichte finden Sie unter: http://agilemanifesto.org/history.html

Manifest für agile Softwareentwicklung

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

In kurzen Worten beschreibt das Manifest damit die Grundlagen agilen Denkens.

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Das Befolgen von Prozessen und der richtige Einsatz von Werkzeugen ist zweifellos ein zentraler Erfolgsfaktor für die Durchführung erfolgreicher Entwicklungsprozesse. Trotzdem stellt ihnen das agile Manifest zu Recht «Individuen und Interaktionen» voran. Nur Individuen sind in der Lage, sich permanent weiterzuentwickeln und damit eine stetige Verbesserung des Entwicklungsprozesses und der entwickelten Produkte zu erzielen. Die Interaktion zwischen Individuen bietet zusätzliches Potential, dass aus der Arbeit eines Teams mehr wird als die Summe der Einzelleistungen. Andererseits kann ein Team nur dann optimal wirken, wenn jedes Teammitglied auch als Individuum mit Stärken, Schwächen und eigener Persönlichkeit wahrgenommen und als solches einbezogen wird.

Funktionierende Software mehr als umfassende Dokumentation

Das Festhalten von Anforderungen im Vorfeld sowie die Dokumentation der umgesetzten Resultate sind eine Grundlage für die Verständigung über Produktinhalte und die Grundlage für erfolgreiche Wartung und Weiterentwicklung. Gelingt es aber nicht, ein funktionierendes Software-Produkt zu erstellen, ist ihr Nutzen sehr begrenzt.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Verträge und Vereinbarungen zwischen Kunden und Herstellern sind von großer Bedeutung. Sie bilden eine wichtige Basis dafür, sicherzustellen, dass alle Beteiligten einen Auftrag gleich verstehen. Trotzdem können Verträge nicht jedes mögliche Szenario detailliert abbilden und jedes mögliche Ereignis vorwegnehmen. Sie entstehen basierend auf dem Kenntnisstand zu einem bestimmten Zeitpunkt. Im Verlauf eines Projektes entwickeln sich aber sowohl Kunde als auch Lieferant weiter. Das verfügbare Wissen zum gemeinsamen Projekt nimmt zu und auch Rahmenbedingungen verändern sich. Um dieser Entwicklung im Rahmen des Projektes Rechnung zu tragen, ist eine gute und intensive Zusammenarbeit mit dem Kunden unabdingbare Voraussetzung.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Pläne sind wichtig und die Vorstellung, dass agile Vorgehensweisen, wie beispielsweise Scrum, ohne Pläne auskommen würden, ist absurd. Man könnte sogar sagen, dass bei agilen Techniken weit mehr geplant wird. Hauptunterschied ist, dass Planung in agilem Umfeld nicht primär zu (oder vor) Projektbeginn stattfindet, sondern laufend und dies immer mit einem «Just in Time»-Approach. Es macht keinen Sinn, auf Monate und Jahre hinaus detaillierte Pläne zu erstellen, wenn man das Feedback des Kunden und das Reagieren darauf als Grundlage für die Ermöglichung einer maximal wertschöpfenden Entwicklung begreift.

Zwölf Prinzipien des Agilen Manifests

Erstes Prinzip: «Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.»

Die Zufriedenheit des Kunden ist unsere höchste Priorität. Durch wertbasierte Priorisierung in Kombination mit der Auslieferung umgesetzter Lösungsteile schon während des Entwicklungsprozesses schaffen wir nicht nur frühzeitig die Möglichkeit für ein tiefer greifendes Kundenfeedback, sondern tragen auch dabei, dass der Kunde, wenn möglich, schon vor Projektabschluss Nutzen realisieren kann.

Zweites Prinzip: «Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.»

Während in komplett durchgeplanten Projekten jede Änderung eine Störung bedeutet, welche womöglich dazu führt, dass Wochen und Monate intensiver Planungs- und Koordinationsarbeit neu erstellt werden müssen, sind neue und angepasste Anforderungen in agiler Entwicklung nicht nur von vornherein mit eingeplant, sondern auch bewusst gewollt. Während der Entwicklung eines Produktes lernt sowohl der Auftraggeber als auch der Auftragnehmer laufend mehr über das zu entwickelnde Produkt. Die Resultate dieses Lernprozesses sollen nicht erst in einem möglichen Folgeprojekt oder mittels späterer Anpassung (nach Auslieferung) realisiert werden, sondern so früh wie möglich in die Entwicklung einfließen. Das kann heißen, dass bereits vorgesehene Funktionalität angepasst oder sogar weggelassen werden muss oder dass vollkommen neue Anforderungen plötzlich höchste Priorität genießen. Nur so sind wir in der Lage, unserem Kunden baldmöglichst einen größtmöglichen Nutzen zu ermöglichen.

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

Agile Entwicklung geschieht als gemeinschaftliche Leistung von Auftragnehmer und Auftraggeber. Während der Auftragnehmer seine Entwicklungsressourcen einbringt, bringt der Auftraggeber sein fachliches Know-how und seine Kenntnis der existierenden oder künftig gewünschten Prozesse ein. Diese gemeinsame Entwicklung kann dann besonders erfolgreich sein, wenn eine häufige und fundierte Kommunikation stattfindet. Diese wird durch häufige Auslieferung und das daraus entstehende Feedback gefördert. Sie gibt dem Entwickler die Möglichkeit, sicherzustellen, dass sich sein Produkt in die richtige Richtung entwickelt, und bietet dem Auftraggeber die Zuversicht, dass das erstellte Produkt seinen Anforderungen entspricht.

Viertes Prinzip: «Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.»

Agile Software-Entwicklung ist vom laufenden Austausch von Fachexperten und Entwicklern geprägt. Dieser beschränkt sich nicht auf den Projektbeginn in der Anforderungsdefinition und zu Projektende in der Lösungsabnahme, wie das bei herkömmlichem Projektvorgehen oft der Fall ist. Die Zusammenarbeit findet laufend statt, sei es bei der Definition von Anforderungen und den entsprechenden Akzeptanzkriterien oder dann im Feedback bei Iterationsende. Auch dazwischen ist die Einbindung zur Klärung von Fragen und Anforderungen wichtig.

Fünftes Prinzip: «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.»

Agile Software-Entwicklung kann nicht erfolgreich sein, wenn sie von unmotivierten Menschen durchgeführt wird, welche Anforderungslisten abarbeiten. Vielmehr ist wichtig, dass die Entwickler einen Sinn und Nutzen in ihrer Arbeit sehen und den Wunsch haben, etwas Nützliches zu produzieren. Nur so kann auch sichergestellt werden, dass optimaler Kundennutzen realisiert wird.

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