Wer weiß, wie autoritäre Systeme funktionieren, weiß auch, dass ein solches System immer ein Feindbild braucht,
, um von den Schwächen im eigenen System abzulenken.
Ein Feindbild schafft ein gemeinsames Ziel und täuscht darüber hinweg, dass es keine echten, erreichbaren internen Ziele gibt.
PSPI ?
Potentially Shippable Product Increment
Das Nexus Integration Team (NIT) ist ein Scrum Team, bestehend aus:
▪ einem Product Owner (zur Erinnerung: Es gibt nur ein Product Backlog.).
▪ einem Scrum Master (mindestens einer aus den teilnehmenden Teams).
Der Nexus Scrum Master ist für Coaching, die Moderation der Kommunikation und die Unterstützung der Nexus-Ergebnisse zuständig (durchführungsverantwortlich) – genau wie in einem Sprint.
▪ den Mitgliedern des Nexus Integration Teams, die die teilnehmenden Teams repräsentieren.
Der Fokus eines Nexus Teams liegt mehr auf Abhängigkeiten, Interoperabilität, Geschäftsergebnissen und dem Wert, den es schöpft. Das NIT stellt sicher (ergebnisverantwortlich), dass in jeder Iteration ein integriertes Inkrement erzeugt wird. Die Scrum Teams entwickeln Inkremente, die in der Summe das Nexus-Ziel erfüllen.
User Stories
User Stories beschreiben (eher in Form einer Geschichte) was der Nutzer will. „Keep it short and simple“, leichtverständlich auch für Fachfremde. Sie gelten als Versprechen, dass man über die Inhalte weiter spricht.
Als ein <Rolle (Art von Benutzer)> möchte ich, dass <das
was der Anforderung (ein Ziel)>, damit ich
<das WARUM der Anforderung (Begründung)>
Epic‘s
Epic‘s sind sehr große, noch unklare User Stories, die meist nur als grobformulierte
Anforderung vorliegen. Sie werden nach und nach verfeinert und dann in mehrere
kleinere User Stories zerlegt.
Themes
Themes sind eine Sammlung zusammenhängender
User Stories. Sie zeigen auf, dass mehrere User Stories
etwas gemeinsam haben, sie bilden einen Überbegriff.
Wann ein Projekt mit scrum ?
▪ Nutze ein agiles Vorgehen (hier: Scrum), wenn
das Unbekannte das Bekannte überwiegt.
▪ Nutze ein klassisch sequenzielles Vorgehen
(Wasserfall), wenn das Bekannte das Unbekannte
überwiegt.
DSDM hat 9 Prinzipien
DSDM verfolgt einen iterativen, inkrementellen Ansatz und betont die kontinuierliche Einbindung der Anwender.
Die 9 Prinzipien sind:
1. Der Kunde wird aktiv in die Arbeit des Teams einbezogen.
2. Die Entscheidungsgewalt liegt (zumindest in großen Teilen) beim Team.
3. Der Fokus liegt auf der häufigen Lieferung von Produkten
4. Jede (Teil-)Lieferung muss einen Geschäftswert für den Anwender darstellen,
was auch das relevante Abnahmekriterium (Business-Value-Driven) darstellt.
5. Eine iterativ inkrementelle Entwicklung ist notwendig, um eine adäquate Lösung zu erzielen.
6. Alle Änderungen während der Entwicklung sind zurücknehm-/ oder umkehrbar.
7. Anforderungen werden auf einem relativ hohen Niveau festgeschrieben.
8. Testen ist integraler Bestandteil des gesamten Prozesses.
9. Die kooperative Zusammenarbeit aller Projektbeteiligten ist überaus wichtig.
Kanban kennt 5 Metriken
Kanban kennt fünf Metriken, mittels derer Scrum Teams sicherstellen sollten, dass Arbeit besser und schneller fertiggestellt wird; bei diesen Metriken handelt es sich um:
1. Laufende Arbeit (WIP): WIP steht für die Menge der Arbeit, die begonnen wurde, aber bislang nicht fertiggestellt ist. Die Gründe für die Nichtfertigstellung sind unwichtig.
Wichtig ist, dass andere Aufgaben nicht abgeschlossen oder gar nicht begonnen werden können, bevor die laufende Arbeit fertiggestellt ist, entweder weil sie von laufenden Arbeitselementen abhängig sind oder weil die Entwickler schon an der laufenden Arbeit arbeiten.
2. Zykluszeit: die Zeitspanne zwischen Beginn und Abschluss eines Arbeitseintrags.
3. Alter des Arbeitseintrags: die Zeitspanne zwischen Beginn eines Arbeitseintrags und der aktuellen Zeit. Das Alter gilt nur für Einträge mit noch laufender Arbeit.
4. Durchsatz: die Zahl der pro Zeiteinheit fertiggestellten Arbeitseinträge.
5. Service Level Erwartung (SLE): Eine SLE prognostiziert, wie lange ein bestimmter Artikel braucht, um den gesamten Arbeitsfluss des Scrum Teams von Anfang bis Ende zu durchlaufen.
„Scaled Scrum“.
Viele Teammitglieder werden benötigt. Daher arbeiten mehrere Teams parallel, das nennt sich „Scaled Scrum“.
Es gibt verschieden Wege Scrum zu scalieren, wie z. B. folgende Frameworks zeigen:
• Nexus™
• Scrum@Scale™
• LeSS™
• SAFe™
LeSS – Framework „Large Scale Scrum“
LeSS eignet sich für folgende Fälle:
▪ Für eine spezifische Entwicklung sind mehrere Teams erforderlich.
▪ Mehrere Teams arbeiten zusammen an einem gemeinsamen Ziel.
▪ Mehrere Teams arbeiten gleichzeitig an einem Produkt oder Service.
Erfüllt Ihr Projekt diese Anforderungen nicht, ist es besser, die Standardvariante von Scrum zu verwenden.
LeSS verfolgt 10 Prinzipien
1. Ein größenskaliertes Scrum.
2. Transparenz: Hauptergebnisse sind für alle sichtbar.
3. More with Less (Weniger ist mehr): Komplexität beseitigen, einfache Problemlösungen.
4. Focus auf das ganze Produkt: Einzelteile des Produktes haben keinen Wert, erst wenn sie zum Endprodukt zusammengefügt werden.
5. Kundenzentrierung: PO ist Bindeglied zwischen Kunden/Benutzern und Team.
6. Kontinuierliche Verbesserung in Richtung Perfektion: Veränderung findet kontinuierlich statt.
7. Lean-Mindset: Respekt vor den Menschen und kontinuierliche
Verbesserung sind zentrale Konzepte von Lean.
8. Systemdenken: Langfristige, dauerhafte Systemveränderungen sind über
Quick-Fix-Lösungen vorzuziehen.
9. Empirische Prozesskontrolle: Zyklus →Transparency, Inspection and Adaption.
10. Warteschlangentheorie: Ziel ist es große Arbeitschargen zu bewältigen.
Die 9 Lean-Agile-Prinzipien von SAFe
1. Einnehmen einer wirtschaftlichen Sichtweise.
2. Systemdenken anwenden.
3. Variabilität annehmen, Alternativen/Optionen beibehalten oder offen halten.
4. Inkrementelle Vorgehensweise mit schnellen, integrierten Lebenszyklen.
5. Meilensteine auf Basis objektiver Auswertung funktionierender Systeme setzen.
6. Visualisiere und begrenzen die laufenden Arbeiten (WIP), reduzieren die Batch-Größen
und verwalten die Länge der Warteschlangen.
7. Halte einen Rhythmus ein, (Timing) anwenden und mit der domänenübergreifenden Planung synchronisieren.
8. Erschließe die wesentliche Motivation von Wissensarbeitern.
9. Entscheidungsfindung dezentralisieren.
Lean Management hat 5 Prinzipien
1. Wert: Identifiziere und spezifiziere den Wert deines Produktes aus Sicht des Kunden.
2. Wertstrom: Erkenne und Verstehe den Wertstrom und eliminiere Verschwendung. Value Stream Mapping (VSM)
3. Flow: Erzeuge einen Wertstromfluss ohne Unterbrechungen. Dies führt zu einer Verbesserung des Cashfows (optimierte Lagerhaltung).
4. Pull: Lasse den Kunden den Takt der Bearbeitung bestimmen, d.h. lass ihn abrufen was er braucht und liefere genau zum richtigen Zeitpunkt (Pullprinzip).
5. Perfektion: Verbessere die Dinge kontinuierlich, strebe nach Perfektion (Kaizen).
Ziele:
▪ Maximieren des Business Value für den Kunden.
▪ Kontinuierliches optimieren der Prozesse, was zu höherer Qualität und kürzeren Lieferzeiten führt.
▪ Verbessern des finanziellen Nutzens durch das Reduzieren von Verschwendung (Waste).
In großen Projekten
Die Scrum Master Rolle:
Sie muss nicht Vollzeit besetzt werden. Eine einzelne Person kann der Scrum Master mehrerer
Teams sein (ist in der Praxis üblich).
Die Product Owner Rolle:
Hierzu gibt es zwei unterschiedliche Ansätze in den Frameworks:
1. Es gibt nur einen Product Owner für alle Teams. Dadurch soll zum einen die
Einheitlichkeit der PBIs und deren Priorisierung im Product Backlog sichergestellt werden.
Zum anderen gibt es damit eine klare Verantwortung für das Product Backlog.
2. Es gibt einen Product Owner je Team (ein Product Owner kann mehrere Teams betreuen).
Alle Teams werden übergreifend durch einen Chief Product Owner begleitet, der die
Einheitlichkeit im Backlog sicherstellt.
Die kontinuierliche Pflege und Weiterentwicklung des Product Backlogs wird als Backlog Refinement (oder alternativ Backlog Estimation oder Backlog Grooming*) bezeichnet. Es ist ein regelmäßiger Prozess, bei dem Product Owner und Entwickler das Backlog auf den aktuellen Stand bringen. Typische Tätigkeiten im Backlog Refinement sind:
Aufnahme von neuen User Storys, Features und Epics in das Backlog
Verfeinerung von vorhandenen Epics, Features und User Storys und gegebenenfalls Aufteilung in mehrere kleine Backlog Items
Zusammenfassen von User Storys
Diskussion der Akzeptanzkriterien, Annahmen und Einschränkungen
Identifikation von Abhängigkeiten
Korrektur von Aufwandsschätzung aufgrund neuer Erkenntnisse
Veränderung der Priorisierung aufgrund neuer Erkenntnisse
Entfernen von irrelevanten User Storys, Features oder Epics aus dem Backlog
Beseitigung von Unklarheiten durch gemeinsame Diskussion, wobei es um das “was” und nicht das “wie” geht
Affinity Estimating / Affinity Estimation
Bei der Affinity Estimation werden die Anforderungen (meist in Form von User-Stories) ihrem Umfang folgend geordnet. Zu Beginn wird dem gesamten Team jede User Story vorgelesen.
User-Stories mit geringem Umsetzungsaufwand werden links angeordnet, solche mit größerem rechts.
Für jede User-Story wird bestimmt, ob sie größer, kleiner oder gleich umfangreich wie jede andere ist, wodurch sich eine nach dem Umsetzungsaufwand sortierte Folge ergibt.
Diese Stories werden anschließend noch gruppiert und den Elementen jeder Gruppe die jeweils gleiche Anzahl an Story Points zugeordnet.
Der Scrum Guide definiert ein Inkrement als:
„Ein konkretes Etappenziel auf dem Weg
zum Produkt-Ziel, wobei jedes Inkrement
additiv zu allen vorherigen Inkrementen
ist und gründlich verifiziert wird, um
sicherzustellen, dass alle Inkremente
zusammenwirken.
Um einen tatsächlichen Wert darzustellen,
muss das Inkrement nutzbar sein“.
Das Inkrement ist ein Scrum Artefakt.
Drei Säulen von Scrum
Die Adaption ist das Herzstück aller agilen Systeme.
Transparenz
Überprüfung
Anpassung
Die primären Projektbeschränkungen
Umfang
Zeit
Kosten
Qualität
Festlegung DSDM
DSDM schreibt daher Zeit, Kosten und Qualität fest und verändert den Umfang
dynamisch.
https://www.agilebusiness.org/page/
ProjectFramework_03_PhilosophyFundamentals
MoSCoW Priorisierung
Must-Have: Ein Must-Have-Feature muss im Endprodukt enthalten sein, da das
Produkt ohne dieses Feature nutzlos wäre (z. B. Bremsen in einem Auto).
• Should-Have: Ein Should-Have-Feature ist für das Endprodukt sehr wichtig. Fehlt dieses Feature werden Probleme auftreten. Die Probleme lassen sich allerdings umgehen und das Produkt kann auch ohne das Feature genutzt werden (z. B. eine Klimaanlage in einem Auto).
• Could-Have: Ein Could-Have-Feature ist ein hilfreiches Feature, das wir gerne in
unserer Lösung hätten. Sollte das Feature in unserem Produkt jedoch fehlen, so ist
dies auch kein Problem (z. B. eine Rückfahrkamera in einem Auto).
• Won‘t-Have-This-Time: Ein Won‘t-Have-Feature ist zwar möglicherweise
interessant, aber zum aktuellen Zeitpunkt werden wir nicht in dieses Feature
investieren.
Inhalte von Abnahmen:
Die MoSCoW-Priorisierung ist eine großartige Methode, um sich auf den Geschäftswert zu konzentrieren, d. h. die wirklichen Bedürfnisse und nicht die Extra-Features (die Could-Have-Einträge)
Ein abnahmefähiges Produkt muss mindestens alle Must-Have-Features enthalten.
• Das Produkt, das wir erwarten, enthält alle Must-Have- und alle Should-Have-
Features.
• Das ideale Produkt enthält alle Must-Have-, Should-Have- und Could-Have-Features.
Verteilung MosCow …
Die Regel lautet, dass höchstens 60% aller Einträge Must-Have- und mindestens
20% aller Einträge Could-Have-Einträge sein sollten. Dies dient als Orientierung zum Verständnis der Logik, die dieser Methode zugrunde liegt.
Die nachfolgenden Merkmale zählen zu den wichtigsten von Kanban:
1. Arbeit sollte visualisiert werden.
2. Laufende Arbeit (WIP) sollte begrenzt werden.
3. Die Arbeit sollte vom Team in das System gezogen (Pull) nicht von außen in das
System geschoben (Push) werden
Werte
XP definiert fünf zentrale Werte
Kommunikation
Einfachheit
Feedback
Mut
Respekt
Agiles Manifest
Prinzip #1
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.
Prinzip #2
Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen.
Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Prinzip #3
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Prinzip #4
Fachexperten und -expertinnen sowie Entwickler:innen müssen während des Projekts täglich zusammenarbeiten
Prinzip #5
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.
Prinzip #6
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht
Prinzip #10
Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
Prinzip #11
Die besten Architekturen, Anforderungen und Entwürfe entstehen
durch selbstorganisierte Teams
Prinzip #12
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an
Prinzip #7
Funktionierende Software ist das wichtigste Fortschrittsmaß.
Prinzip #8
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber,
Entwickler:innen und User (Benutzer und Benutzerinnen) sollten
ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können
Prinzip #9
Ständiges Augenmerk auf technische Exzellenz und gutes Design
fördert Agilität
Busfaktor
Stellen Sie sich vor, ein:e Entwickler:in verlässt das Gebäude, wird bedauerlicherweise
von einem Bus überfahren und stirbt. Legt dieses Unglück nun das gesamte Projekt
lahm, weil es Aspekte gibt, die kein anderes Projektmitglied versteht, so hat das Projekt
einen Busfaktor von 1. Sind für den Worst Case, d. h. um das Projekt zu blockieren, zwei
Busunfälle erforderlich, so spricht man von einem Busfaktor von 2 usw. Ein niedriger
Busfaktor ist also immer risikobehaftet
Doomsayers
Eine weitere Rolle ist die des Doomsayers oder des Schwarzmalers bzw. der Schwarzmalerin. Er oder sie bestärkt die anderen Teammitglieder darin, auch an die Risiken und Probleme zu denken. Danach arbeitet das gesamte Team zusammen und prüft, wie es diese Risiken und Probleme beherrschen oder bewältigen kann
Spiking
Deshalb beschäftigt man sich bei XP manchmal mit Spiking anstatt die eigentliche Arbeit zu erledigen. Beim Spiking programmieren Sie einfach drauf los, ohne die Praktiken zu befolgen. Sie schreiben schnell einen Code, um eine Idee oder eine Technologie auszuprobieren. In der Regel sollten Sie diesen Code nicht behalten. Wenn Sie mit dem Ausprobieren fertig sind und wissen, was Sie wissen wollten, löschen Sie den Code und arbeiten wieder nach den festgelegten Standards und Praktiken.
INVEST
Independent (unabhängig):
Die Einträge dürfen untereinander keine Abhängigkeiten aufweisen, damit wir sie auf der Basis ihrer Wichtigkeit und ihres Werts entwickeln können und uns nicht über eventuelle Abhängigkeiten sorgen müssen.
• Negotiable (verhandelbar):
Product Backlog-Einträge (Product Backlog Items, PBI) sind gleichzeitig auch Kommunikationswerkzeuge und sollten daher verhandelbar sein.
• Valuable (wertvoll):
Jeder Eintrag leistet einen Wertbeitrag. Dieser bestimmt in der Regel die Reihenfolge der Entwicklung.
• Estimateable (schätzbar):
Wir brauchen für jeden Eintrag eine einfache Schätzung der Größe; erscheint ein Eintrag nicht schätzbar, so ist er möglicherweise nicht korrekt ausgearbeitet.
• Small (klein):
Nur die Einträge, die im Product Backlog ganz oben angeordnet sind, müssen klein sein; die anderen dürfen groß und können sogar unklar sein.
• Testable (testbar):
Erscheint es unmöglich, einen Eintrag zu demonstrieren oder zu testen, dann ist der Eintrag nicht korrekt ausgearbeitet
User Story
Als {Rolle} möchte ich {etwas tun}, [um {Zweck}]
Dauer
Die Sprint Retrospective dauert bei einem Sprint mit einer Länge von 1 Monat maximal …
Die Sprint Retrospective dauert bei einem Sprint mit einer Länge von 1 Monat maximal 3 Stunden. Bei kürzeren Sprints ist sie in der Regel kürzer. In der Regel ist die Sprint
Retrospective zeitlich begrenzt (timeboxed) und die festgelegte Dauer gilt für alle
Sprint Retrospectives bis wir uns entschließen, diese Dauer zu ändern.
Das Sprint Review dauert bei einem Sprint mit einer Länge von 1 Monat maximal
Das Sprint Review dauert bei einem Sprint mit einer Länge von 1 Monat maximal 4
Stunden. Bei kürzeren Sprints ist das Review in der Regel kürzer. Das Review ist zeitlich begrenzt (timeboxed). In der Regel legen wir die Timebox einmal fest und nutzen diese dann für jedes Review, es sei denn wir entscheiden uns ausgehend von den aus dem Projekt gewonnenen Erkenntnisse dafür, die Dauer zu ändern
Die Messung des Projektfortschritts insgesamt erfolgt durch den Product Owner,
Die Messung des Projektfortschritts insgesamt erfolgt durch den Product Owner, weil diese:r die Einträge im Product Backlog und die künftigen Möglichkeiten am besten kennt.
Nur zur Erinnerung: Die Messung des Sprintfortschritts ist Aufgabe der Entwickler:innen.
Nur zur Erinnerung: Die Messung des Sprintfortschritts ist Aufgabe …
Genau wie beim Sprintfortschritt kommt auch hier häufig
Genau wie beim Sprintfortschritt kommt auch hier häufig ein Burn-Down-Chart zur
Visualisierung des Projektfortschritts zum Einsatz.
Verpflichtend ist dies aber nicht
Sprint Retrospective
Die Sprint Retrospective ist eine strukturierte Methode zur Prozessverbesserung. Für uns stellt die Sprint Retrospective jedoch nur eine Mindestanforderung dar. Unsere Bemühungen hinsichtlich der Prozessverbesserung gehen weit darüber hinaus. Verbesserungen können jederzeit stattfinden.
Bei adaptiven Systemen geht es darum, das Produkt an seine Umgebung anzupassen.
Das Sprint Review ist dabei eines der wichtigsten Events. Daneben müssen wir jedoch auch unsere Arbeitsweise entsprechend an die Umgebung anpassen. Letzteres beschränkt sich allerdings nicht auf adaptive Projekte, sondern ist stets notwendig.
Agile Projekte nehmen dies jedoch ernster und halten in der Regel am Ende einer
Iteration reflexive Besprechungen ab mit dem Ziel, die Arbeitsweise zu verbessern.
Dieses Meeting wird bei Scrum als Sprint Retrospective bezeichnet
Artefakte
Bei Scrum gibt es drei Artefakte:
1. Das Inkrement: Dieses ist die neueste Version des Produkts, die wir für den Kunden erstellt haben.
2. Das Product Backlog: Das Product Backlog ist unser Gesamtprojektplan. Es umfasst das Produktziel und eine geordnete Liste an Einträgen (wie z. B. Features), die wir unserem Produkt hinzufügen möchten.
3. Das Sprint Backlog: Unser kurzfristiger Projektplan, der in einem einzigen Sprint
umgesetzt wird. Das Sprint Backlog umfasst das Sprintziel, eine Liste mit Product-
Backlog-Einträgen (Product Backlog Item, PBIs) und eine Reihe von Aufgaben, die
durch Zerlegen der Einträge erstellt wurden
Für jedes Artefakt gibt es ein Commitment, mit dem das Artefakt interpretiert und die Bemühungen gelenkt werden.
• Das Commitment für das Inkrement ist die Definition of Done (DoD), die klar macht, was wir meinen, wenn wir sagen, etwas sei fertig.
Product Backlog
Das Commitment für das Product Backlog ist das Produktziel. Es verdeutlicht, was
mit der Entwicklung der Einträge (Items) erreicht werden soll.
Das Produktziel ist unsere Produktvision oder leitet sich von dieser ab
sPRINT bACKLOG
Das Commitment für das Sprint Backlog ist das Sprintziel. Es verdeutlicht, was wir
im Sprint durch die Entwicklung der PBI erreichen wollen. Für jeden Sprint gibt es
ein eigenes Sprint Backlog und Sprintziel.
Jeder Eintrag (Item) auf dem Product Backlog hat folgende Attribute:
• Beschreibung: Hierbei handelt es sich um eine kurze Beschreibung des Eintrags
(Items). Versuchen Sie nicht alle Einzelheiten des Eintrags abzudecken, da diese
teilweise erst während der Arbeit zutage treten. Die Meinung, die Einträge seien nur eine Ausrede dafür, vollständige Spezifikationen durch Unterhaltungen zu ersetzen, ist weitverbreitet.
• Größe: Der Umfang der einzelnen Einträge muss für mehrere Zwecke bekannt sein: (Darauf gehen wir in Kürze noch näher ein.)
• Reihenfolge: Die Reihenfolge der einzelnen Einträge ergibt sich aus ihrer Position
im Product Backlog
– Risiken, Abhängigkeiten, etc.
Die korrekte Definition von „Wert” berücksichtigt die Größe (den Aufwand), die Risiken,
die Abhängigkeiten und andere Elemente. Damit würde der Wert alleine ausreichen, um die Einträge in eine Reihenfolge zu bringen.
Da die Fachliteratur zu Scrum die beiden Definitionen von „Wert” jedoch vermischt, wird in der Regel vorgeschlagen, die Einträge im Backlog nach Wert, Größe, Risiken, Abhängigkeiten etc. zu ordnen.
Zur Skalierung von Scrum gibt es nicht nur einen gültigen Weg, sondern mehrere
Frameworks wie zum Beispiel:
• Nexus™: Ein Framework von Scrum.org, das sich durch eine einfache und klare
Struktur auszeichnet.
• Scrum@Scale™: Ein Framwork von Scrum Inc.
• LeSS™: Eine leichte und übersichtliche Skalierungsmethode, die tendenziell auch
die Ebene des Programmmanagements abdeckt.
• SAFe™: Eine durchaus komplizierte, von vielen großen Organisationen (z. B. Banken)
bevorzugte Methode, die zwar nicht mit allen Agilen Konzepten kompatibel ist, aber
die allgemeinen Erwartungen von Managern in großen Organisationen erfüllt.
Burn-Up-Chart
Eine Möglichkeit, die Menge der fertiggestellten Arbeit zu visualisieren, besteht darin, die Summe der geschätzten Größen der vollständig fertiggestellten Einträge im Verhältnis zur Zeit darzustellen
Ergänzen oder entfernen wir Einträge im Product Backlog bewegt sich das Ziel nach oben und unten.
Bei der Betrachtung eines solchen Diagramms denken die meisten Menschen automatisch an die Entwicklungsgeschwindigkeit und stellen sich vor, wann das Ziel erreicht sein wird (möglicher Fertigstellungstermin). Damit dies für alle einfacher wird, können wir im Diagramm eine Trendlinie ergänzen
Burn-Down-Chart
Dieses Diagramm zeigt nicht die fertiggestellte, sondern die Menge der noch
verbleibenden Arbeit. Da die Kurve im Laufe der Zeit nach unten geht, spricht man von einem Burn-Down-Chart.
Burn-Down-Charts sind in Scrum-Projekten populär und trotz ihrer großen Schwächen nach wie vor die beliebteste Methode zur Darstellung des Projektfortschritts. Sie sind so weit verbreitet, dass die Agile Community, ein normales Diagramm (wie im vorherigen Abschnitt beschrieben) als Burn-Up-Chart bezeichnet, weil es die umgekehrte Form eines Burn-Down-Charts hat
Burn-Down-Bar
Während Burn-Down-Charts bei Sprints mehr oder weniger gut funktionieren, da
es festgelegte Ziele gibt, sind sie bei Gesamtprojekten problematisch, weil sich das Product Backlog ständig verändert.
Erstens ist es schwierig, die Y-Achse ständig anzupassen und zweitens wird die Geschwindigkeit der Veränderung selbst dann nicht aus dem Diagramm ersichtlich. Eine mögliche Lösung besteht darin, Anpassungen unten am Diagramm vorzunehmen, indem wir Balken hinzufügen, die die Menge der verbleibenden Arbeit anzeigen
wohingegen Programme stets adaptiv sein müssen.
Der Grund hierfür ist, dass
es bei Projekten um Produkte und bei Programmen um Ergebnisse geht.
Sprint Planning
zur Planung des bevorstehenden Sprints durch Erstellen eines
Sprint Backlogs
Sprint Review
zur Bewertung der jüngsten Inkremente und der Informationen
zum Projektfortschritt sowie zum Einholen von Feedback
zur Bewertung der Arbeitsweise und Planung von Verbesse-
rungen im nächsten Sprint
Product Owner
Er oder sie ist dafür verantwortlich, den Wert des Produkts zu maximieren und das Produktziel zu erreichen. Dies geschieht in erster Linie durch die Erstellung und Pflege des Product Backlogs.
Der Product Owner …
▪ ist eine Person, Business-orientiert
▪ entwickelt das Produkt-Ziel als langfristige Zielsetzung für das Scrum Team.
▪ kommuniziert das Produkt-Ziel umfassend, verständlich und macht es sichtbar.
▪ achtet auf festgelegte Ziele und finanzielle Vorgaben.
▪ erstellt, pflegt und priorisiert die Product Backlog-Einträge und kommuniziert diese klar und verständlich und managt damit den Produktlebenszyklus.
▪ erstellt die Produkt Roadmap und den Releaseplan.
▪ steuert durch die Verfolgung und Prognose des Fortschritts.
▪ kann die oben genannten Aufgaben delegieren, bleibt jedoch weiterhin
rechenschaftspflichtig (accountable).
▪ ist vom Unternehmensmanagement dazu bevollmächtigt Entscheidungen bezüglich Anforderungen und Funktionsumfang zu treffen.
Scrum Master
Er oder sie sorgt für die vollständige und korrekte Einhaltung des
Scrum Frameworks. Dies erfordert Coaching, Schulungen und Problemlösung
Der Scrum Master ist ergebnisverantwortlich für die Einführung von Scrum (gemäß Scrum Guide) und die Effektivität („die richtigen Dinge tun“) des Scrum Teams.
Er ist …
▪ eine Person, eine echte Führungskraft, für das Scrum Team und die Gesamtorganisation.
▪ verantwortlich dafür, dass die Scrum Theorie, Praktiken und Regeln verstanden und eingehalten werden.
▪ Coach, Unterstützer, Vermittler, Moderator und Prozessbegleiter bei der Zielerreichung.
▪ jemand, der Hindernisse beseitigt und die Zusammenarbeit fördert, indem er eine vertrauensvolle, offene Arbeitsatmosphäre fördert.
▪ Feedback-Geber und bei Bedarf spricht er unproduktives Verhalten an.
▪ kein Vorgesetzter mit Weisungsbefugnis und Entscheidungsgewalt.
▪ der Unterstützter des Teams und hilft ihnen die „beste Version“ von sich selbst zu sein.
▪ langfristig gesehen darauf aus sich selbst „abzuschaffen“.
Der Scrum Master unterstützt das Scrum Team
unter anderem durch das …
▪ Coachen der Entwickler hin zu Selbstmanagement und funktionsübergreifender Teamarbeit.
▪ Unterstützen der Entwickler bei der Schaffung hochwertiger Produkte, die der Definition of Done entsprechen.
▪ Beseitigen von Hindernissen, die das Scrum Team aufhalten.
▪ Sicherstellen, dass alle Scrum Events stattfinden, produktiv sind und innerhalb der Timebox bleiben.
▪ Unterstützen bei der Durchführung von Scrum Events bei Bedarf oder auf Anfrage.
▪ besondere Unterstützen der Entwickler in Organisationen, in denen Scrum noch nicht vollständig angenommen und verstanden wird.
Der Scrum Master unterstützt den Product Owner
unter anderem durch das…
▪ Suchen nach Techniken zur effektiven Definition des Produkt-Ziels.
▪ Vermitteln von Kenntnisse, wie eine gute Anordnung der Product Backlog Items dabei hilft den größtmöglichen Wert zu erzeugen. Dadurch wird eine effektive Verwaltung des Produkt Backlogs ermöglicht.
▪ Vermitteln eines Verständnisses für die Notwendigkeit klarer, prägnanter
Product Backlog Einträge im Scrum Team.
▪ Sicherstellen, dass Ziele, Umfang und Produktdomäne von allen im Scrum Team, so gut wie möglich, verstanden werden.
▪ Schaffen eines Verständnisses für eine Produktplanung in einem empirischen Arbeitsumfeld.
▪ Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung.
Der Scrum Master unterstützt die Organisation
▪ Leiten, Schulen und Coachen der Organisation bei der Einführung von Scrum.
▪ Planen und Empfehlen der Scrum Implementierung innerhalb der Organisation.
▪ Unterstützen von Kollegen und Stakeholdern, damit sie Scrum und die empirische Produktentwicklung verstehen und umsetzen können.
▪ Auslösen von Veränderungen zur Produktivitätssteigerung des Teams.
▪ Zusammenarbeiten mit anderen Scrum Mastern, um die Effektivität von Scrum
Implementierungen innerhalb der Organisation zu verbessern.
▪ Beseitigen von Barrieren zwischen Stakeholdern und dem Scrum Team.
Die Entwickler sind ergebnisverantwortlich dafür, …
▪ einen Plan für den Sprint zu erstellen, das Sprint Backlog.
▪ die Qualität durch die Einhaltung einer Definition of Done einzubringen.
▪ täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen.
▪ sich wechselseitig als Experten zur Verantwortung zu ziehen.
Die Entwickler
▪ Es gibt keine spezifischen Titel.
▪ Es gibt keine Sub-Teams.
▪ Das Team ist interdisziplinär, das heißt im Team sind alle Fähigkeiten enthalten, um das Inkrement zu erstellen.
▪ Das Team ist Cross-funktional (Designer, Tester, Vertriebler, Marketingmitarbeiter,…).
▪ Einzelne Mitglieder können spezialisierte Fähigkeiten oder Spezialgebiete haben,
aber die Rechenschaftspflicht obliegt allen als Ganzes.
▪ Ein Stabiles Team, Full-Time im Einsatz, wird empfohlen.
▪ Größe: bis 8 Personen
Der Scrum Prozess und seine Artefakte.
Die Scrum Artefakte und ihre Commitments
▪ Product Backlog → Produktziel
▪ Sprint Backlog → Sprintziel
▪ Inkrement → Definition of Done
Entwickler:innen
Dies sind die technischen Experten und Expertinnen, die das
Produkt entwickeln
Scrum Team: Wird das Team zu
groß, funktioniert es folglich nicht.
in Scrum Team umfasst in der Regel höchstens 10
Mitarbeiter.
Erfordert ein größeres Projekt mehr Mitarbeiter, so können diese in mehreren Teams arbeiten
Ein Setup mit mehreren Teams nennt man Skaliertes Scrum
Selbstmanagement
Ein Scrum-Team muss befugt sein, selbständig Entscheidungen bezüglich des Projekts treffen zu können. In den früheren Versionen des Scrum Guides wurde dies als Selbstorganisation bezeichnet. Der Scrum Guide aus dem Jahr 2020 nennt es nun Selbstmanagement. Mit anderen Worten, es handelt sich schlicht um zwei verschiedene Bezeichnungen für ein- und denselben Begriff.
Der Unterschied zwischen Zuständigkeit und Verantwortung lässt sich einfach
erklären:
Zuständigkeit bedeutet, dass man etwas tun soll. Hat man dagegen die Verantwortung, so ist man für das Ergebnis verantwortlich. Mit anderen Worten, wenn Sie die Verantwortung tragen, die Zuständigkeit aber lieber delegieren, werden Sie die Arbeit dennoch überwachen, um sicherzugehen, dass sie ordnungsgemäß erledigt wird.
muss der Product Owner selbst unternehmerisch denken sowie
die Produktvision und die Produktziele verstehen.
Der Product Owner nutzt diese
Informationen zur Verwaltung des Product Backlogs und um:
• neue Einträge (Items) für das Backlog zu erstellen,
• die vorhandenen Einträge genau zu beschreiben und
• die Einträge in die entsprechende Reihenfolge zu bringen.
Um schnellstmöglich einen größtmöglichen Wert zu erzielen, ordnet der Product Owner die Einträge so an, dass Einträge, die am ehesten zum Wert des Produkts beitragen, im Product Backlog ganz oben stehen und zuerst entwickelt werden. Dies ist eine der wichtigsten Methoden, mit denen der Product Owner für Wertmaximierung sorgt
– Angliederung
Wird ein Projekt für einen externen Kunden durchgeführt, so wird manchmal der
Kundenvertreter bzw. die Kundenvertreterin als Product Owner bezeichnet. Dies ist jedoch meist keine gute Idee. Besser ist es, wenn ein Mitarbeiter aus Ihrer Organisation diese Rolle übernimmt.
– Wie viele Product Owner gibt es?
Diese Rolle wird stets nur von einer Person ausgeführt, ganz gleich, wie groß Ihr Projekt
ist. Der Grund hierfür ist, dass es bei mehreren Personen eventuell zu Ungereimtheiten
im Product Backlog oder in den Informationen kommen könnte, die den Entwicklern
und Entwicklerinnen bereitgestellt werden
– Messung des Fortschritts
Der Product Owner ist für die Ermittlung des Projektfortschritts zuständig.
Diese Tätigkeit fällt in die Zuständigkeit des Product Owners, weil es einen hohen Grad an Verständnis für den gesamten Arbeitsumfang und alle damit verbundenen Möglichkeiten erfordert und niemand über mehr Informationen in diesem Bereich verfügt als der Product Owner. Die Entwickler:innen konzentrieren sich auf die Arbeit in den Sprints und die technischen Aspekte des Projekts und der Scrum Master befasst sich eher mit dem Kontext als dem Inhalt.
– Ownership (Führungsverantwortung)
Der Product Owner ist für das Product Backlog verantwortlich, d. h. er oder sie trägt die Ergebnisverantwortung. Veränderungen am Product Backlog dürfen nur vom Product Owner oder allenfalls von Mitarbeitern und Mitarbeiter:innen durchgeführt werden, denen vom Product Owner bestimmte Zuständigkeiten (Durchführungsverantwortung) übertragen und die entsprechend autorisiert wurden
– Delegation von Aufgaben
Product Owner dürfen manche Zuständigkeiten (Durchführungsverantwortungen)
an andere (in der Regel die Entwickler:innen) delegieren. Beispielsweise ist es nicht ungewöhnlich, dass der Product Owner die Entwickler:innen bittet, die Zuständigkeit (Durchführungsverantwortung) für die Erstellung der technischen Product-Backlog- Einträge (Product Backlog Items, PBI) zu übernehmen. In der Regel ist es jedoch am besten, wenn der Product Owner die Zuständigkeiten (Durchführungsverantwortung) selbst behält.
Der Scrum Master
Scrum Master sind Scrum-Experten, die beim Verständnis und der Anwendung von Scrum behilflich sind. Darüber hinaus helfen sie, ein für das Team angenehmes Arbeitsumfeld sicherzustellen.
– Coaching und Training
Der Scrum Master coacht und schult das Team bezüglich der Anwendung von Scrum und, was noch wichtiger ist, er oder sie schult und coacht möglicherweise den Kunden und die Managementebenen der Organisation darin, wie man mit einem Scrum Team arbeitet.
Bitte beachten Sie stets, dass Scrum Master den Teammitgliedern nichts vorschreiben können, sie können lediglich Überzeugungsarbeit leisten.
Last changed3 months ago