scrum das agile framework - dswin.synology.medswin.synology.me/projekte/scrum/horizont_scrum...

SCRUMDAS AGILE FRAMEWORK

FRANK WINTER

In a Nutshell

Frank Winter

Scrum Master/

Projektmanager

FRANK WINTER

DOCUMENT CONTROL

Security level

Company

Department PMO

Author Frank Winter

Reviewed by Date DD / MM / YYYY

Approved by Date DD / MM / YYYY

Version Date Change Comment By

1.0 25.10.2016 New F.Winter

1.1 07.01.2017 Add Translation F.Winter

AGENDA

FRANK WINTER

• Scrum Framework• Scrum Rollen• Scrum Meetings

• Scrum Artefacts• Team Setup / building (new )

• Others• Continious Integration…

123

45

67

Das Agile – Scrum Framework1

FRANK WINTER

FRANK WINTER

1. DAS AGILE – SCRUM FRAMEWORK

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge2. Funktionierende Software ist wichtiger als umfassende Dokumentation3. Zusammenarbeit mit dem Auftraggeber ist wichtiger als Vertragsverhandlung4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Die vier Leitsätze des Agilen Manifest

FRANK WINTER

THE AGILE – SCRUM FRAMEWORK

Wir folgen diesen Prinzipien:

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

2. Heiße Anforderungsänderungen selbst spätin der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

3. Liefere funktionierende Softwareregelmäßig innerhalb weniger Wochen oder Monate undbevorzuge dabei die kürzere Zeitspanne.

4. Fachexperten und Entwickler müssen während des Projektestäglich zusammenarbeiten.

Prinzipien hinter dem Agilen Manifest

FRANK WINTER

DAS AGILE – SCRUM FRAMEWORK


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.

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

7. Funktionierende Software ist das wichtigste Fortschrittsmaß. 8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und

Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.


FRANK WINTER



9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. 10. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. 11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch

selbstorganisierte Teams. 12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und

passt sein Verhalten entsprechend an.


FRANK WINTER


Scrum Rollen2

FRANK WINTER

Die wichtigsten Beteiligten

FRANK WINTER

• Pigs and Chickens• Product Owner• Team• Scrum Master• Stakeholders & Users

SCRUM ROLLEN

• In Scrum werden direkt am Prozeß beteiligte Personen Pigs (Schweine) genannt, Außenstehende heißen Chickens (Hühner). Das hat seinem Ursprung in einem englischen Witz. Jeder Scrum-Jünger kennt ihn – Ihr auch in Kürze,

• Der Witz klingt übersetzt ins Deutsche nicht mehr so pointiert, daher im Original:

Pigs and Chickens

FRANK WINTER

SCRUM ROLLEN

A chicken and a pig were brainstorming...• Chicken: Let's start a restaurant!• Pig: What would we call it?

• Chicken: Ham 'n' Eggs!• Pig: No thanks. I'd be committed, but you'd only be involved!

Pigs and Chickens

FRANK WINTER

SCRUM ROLLEN

Kleine Wortkunde• to be committed to something

• hinter etwas stehen

• sich dafür einsetzen, etwas zu tun• to be involved in/with something

• an etwas beteiligt sein• mit etwas befaßt sein• mit etwas beschäftigt sein

Pigs and Chickens

FRANK WINTER

SCRUM ROLES

Product Owner

FRANK WINTER

• Product Owner (PO) ist der Vertreter des Kunden

• Definiert die Funktionen des Produkts

• Entscheidet das Release-Datum und Inhalt

• Priorisiert Features nach Marktwert

• Ist Verantwortlich für die Rentabilität des Produkts

• Akzeptiert oder lehnt work items ab

SCRUM ROLES

• Immer, wenn Software entwickelt wird - egal ob im Kundenprojekt oder für ein Standardprodukt -gibt es einen Auftraggeber, der die fachliche Sicht vertritt, Anforderungen stellt und die spätere

Umsetzung seiner Wünsche im Hinblick auf Funktionalität, Benutzbarkeit (Usability), Performanz und Qualität beurteilt.

In Scrum ist das der Product Owner.

Product Owner

FRANK WINTER

SCRUM ROLES

• Aufgaben und Verantwortlichkeiten des Product Owners

• Pflege des Product Backlogs• vertritt die fachliche Auftraggeberseite und somit sämtliche Stakeholders

• priorisiert die Product Backlog Items so, daß der Business Value des Produkts maximal wird und die Möglichkeit früher Releases von Kernfunktionalität besteht, um einen schnellen Return on Investment zu erreichen

• wohnt nach Möglichkeit den Daily Scrums bei, um sich (passiv) zu informieren

• steht für Rückfragen des Teams bereit

Product Owner

FRANK WINTER

SCRUM ROLES

Aufgaben und Verantwortlichkeiten des Product Owners

• Manchmal wird der Product Owner im Jargon auch scherzhaft als SCN (single chokable neck) bezeichnet, um klar (und überhaupt nicht scherzhaft) herauszustellen: Er trägt die Verantwortung dafür, daß die richtigen Anforderungen im Product Backlog stehen und daß sie in einer sinnvollen Reihenfolge abgearbeitet werden. Dadurch hat er maßgeblichen Einfluß auf das Arbeitsergebnis und ist, so gesehen, wirklich die eine Person, deren "Hals gewürgt wird", wenn das Team - gemäß Vorgabe - Mist produziert.

Product Owner

FRANK WINTER

SCRUM ROLES

Was der Product Owner NICHT tut

• Rolle des Chefs für das Team übernehmen

• Daily Scrums moderieren oder ungefragt dort reden

• Während des Sprints den Sprint Backlog beeinflussen (Zusatzanforderungen, Streichung von Aufgaben etc.)

• im Projekt als Team Member (z.B. Entwickler, Software-Architekt) mitarbeiten (Interessenkonflikt!)

• versuchen, gleichzeitig den ScrumMaster zu mimen (Interessenkonflikt!)

• seine Aufgabe nur zu Beginn und am Ende der Sprints wahrnehmen

Product Owner

FRANK WINTER

SCRUM ROLES

Muß der Product Owner ein Manager oder Vorgesetzter sein?

• Wer so viel Verantwortung trägt, muß doch mindestens Abteilungsleiter oder gar Vorstand sein. Es wäre auch praktisch, wenn das Projekt-Team ihm direkt disziplinarisch unterstellt wäre, damit er besser seine Anweisungen geben kann.

Product Owner

FRANK WINTER

SCRUM ROLES

Muß der Product Owner ein Manager oder Vorgesetzter sein?

• Richtig?

• Falsch!

• Der Product Owner darf ein Manager sein, aber notwendig ist das nicht, sofern er in der Lage ist, die Auftraggeberseite fachlich kompetent zu vertreten und das Product Backlog so zu gestalten, daß das Team daraus die Funktionalität machen kann, welche dem Auftrag gerecht wird. Manchmal ist es sogar hinderlich, wenn die Team Members einen Vorgesetzten als Product Owner haben, weil sie sich dadurch in ihren Kompetenzen eingeschränkt fühlen könnten. Wie auch immer: Im Scrum-Projekt erteilt der Product Owner dem Team keine direkten Anweisungen - sonst greift der ScrumMaster ein.

Product Owner

FRANK WINTER

SCRUM ROLES

Team

FRANK WINTER

• 5-9 Entwickler incl. Tester

• Selbstorganisierende, High-Performance-Team

• Produziert ein gewinn bringendes Produkt• Arbeitet Gemeinsam und teilt sich die

Verantwortung

• Cross functional team

SCRUM ROLES

Merkmale und Eigenschaften eines Scrum-Teams• besteht aus fünf bis zehn Personen (ideal sind sieben)• größere Gruppen werden in mehrere unabhängige, aber miteinander kommunizierende Teams aufgeteilt

(Scrum of Scrum /SAFe)

• ist interdisziplinär zusammengesetzt (Entwickler, Architekten, Tester, technische Redakteure), wenn von Vorteil - und das ist meistens der Fall

• ist sein eigener Manager (Self-Organisation)

Team

FRANK WINTER

SCRUM ROLES

Merkmale und Eigenschaften eines Scrum-Teams• Entscheidet selbständig über das Zerlegen von Requirements (Epics, Stories) in Tasks und deren

Verteilung an einzelne Mitglieder (Erstellung des Sprint Backlog aus dem aktuell anstehenden Teil des Product Backlog)

• Trifft sich täglich zum Daily Scrum, in dem die Team Members einander jeweils einen kurzen Statusbericht liefern (Nur für sich)

• Liefert nach jedem Sprint ein Increment of Potentially Shippable Functionality ab und präsentiert dieses im Sprint Review Meeting

• Jedes Team Mitglied kennt das Big Picture des Projekts

• Jedes Team Mitglied aktualisiert täglich die Restaufwände seiner Tasks im Sprint Backlog

Team

FRANK WINTER

SCRUM ROLES

Was ein Scrum-Team NICHT tut• Fachkonzepte schreiben - dafür gibt es das Product Backlog des Product Owners• Sich vom Product Owner seine Arbeitsweise vorschreiben lassen

• Im Daily Scrum dem ScrumMaster und/oder dem Product Owner berichten - die Team Members berichten einander

• Das Sprint Backlog vernachlässigen

• Ungestörtes Arbeiten während des Sprints verwechseln mit dem Sitzen im Elfenbeinturm

Team

FRANK WINTER

SCRUM ROLES

Scrum Master

FRANK WINTER

• Trainer für das Scrum-Team

• Steht ein für die Scrum Werte

• Sorgt für die Produktivität das Teams

• Build winning team• Apply agile principles and make system

effective

SCRUM ROLES

• Agile Prozesse zeichnen sich - deshalb auch diese Bezeichnung - durch eine hohe Dynamik aus. Damit der Prozeß zielgerichtet verläuft und aus Dynamik nicht Chaos wird, gibt es den ScrumMaster. Er ist sozusagen die Seele des Prozesses und sorgt dafür, daß die Regeln eingehalten werden.

Scrum Master

FRANK WINTER

SCRUM ROLES

• Aufgaben und Verantwortlichkeiten des ScrumMasters

• trägt Verantwortung für den Scrum-Prozeß und dessen korrekte Implementation

• ist ein Vermittler und Unterstützer (Facilitator)

• strebt maximalen Nutzen und ständige Optimierung an

• beseitigt Hindernisse(!)

• sorgt für Informationsfluß zwischen Product Owner und Team

• moderiert Scrum-Meetings

• hat die Aktualität der Scrum-Artefakte (Product Backlog, Sprint Backlog, Burndown Charts) im Blick

• schützt das Team vor unberechtigten Eingriffen während des Sprints

Scrum Master

FRANK WINTER

SCRUM ROLES

• Was der ScrumMaster NICHT tut

• Rolle des Chefs für das Team übernehmen

• das Projekt in dem Sinne leiten, daß er anschafft, wer welche Arbeit auf welche Weise zu erledigen hat

• Doppelfunktion als Team Member oder Product Owner übernehmen (Interessenkonflikte!)

Scrum Master

FRANK WINTER

SCRUM ROLES

• Wer ist ein geeigneter ScrumMaster?• Zunächst sollte der ScrumMaster natürlich Scrum kennen, und zwar nicht nur so, daß er diese Webseite oder ein Buch von Ken Schwaber durchgelesen

hat. (Anmerkung: Gleichwohl versucht diese Einführung, Scrum zumindest so verständlich zu machen, daß Sie entscheiden können, ob die Methode "etwas für Sie ist" und es sich lohnt, sich weiter damit zu beschäftigen und evtl. eine entsprechende Beratung in Anspruch zu nehmen.)

• Scrum zu kennen und es wirklich so zu verstehen, daß man in der Lage ist, einen Scrum-Prozeß als ScrumMaster zu begleiten, ist nicht dasselbe. Scrum als Team Member oder Product Owner zu leben, ist hingegen etwas einfacher (aber deswegen noch lange nicht einfach), weil man einen ScrumMaster als Coach, Mentor, Moderator und Vermittler mit im Boot hat.

Scrum Master

FRANK WINTER

SCRUM ROLES

• Wer ist ein geeigneter ScrumMaster?• Zum ScrumMaster kann man sich projektbegleitend coachen lassen, nachdem man einen ca. zweitägigen Einführungslehrgang absolviert hat. Ähnliches

gilt übrigens auch für den Product Owner und das Team. Ob jemand als Person geeignet ist für die ScrumMaster-Rolle, hängt von unterschiedlichen Faktoren ab: Wird der potentielle ScrumMaster sowohl vom durch den Product Owner vertretenen Fachbereich als auch vom Team (Entwickler, Software-Architekten, Tester, technische Redakteure) akzeptiert? (Ob er dann auch respektiert wird, hängt von ihm selbst ab - Respekt muß man sich erarbeiten.)

• Komplikationen kann es geben, wenn der ScrumMaster Vorgesetzter des Teams ist. Das muß nicht zum Problem werden, erfordert aber einige Disziplin aller Beteiligten, um im Scrum-Projekt nicht wieder in die alten Rollen zurückzufallen und nach dem Command-and-Control-Muster zu handeln. Hier ist in der Einstiegsphase ein Coaching durch einen anderen ScrumMaster wichtig, damit die neue Rollenverteilung in Scrum auch so gelebt wird, daß der Prozeß erfolgreich sein kann.

• Es kommt übrigens nicht selten vor, daß eine Person aus dem Kreis des Teams zum ScrumMaster bestimmt wird. Auch das ist möglich, birgt aber auch Potential für Komplikationen. In jedem Fall wichtig ist, daß der ScrumMaster dann nicht in Versuchung gerät, gleichzeitig als Team Member mitzuarbeiten. Warum Doppelrollen in Scrum problematisch sind, würde hier den Rahmen sprengen und verdient einen eigenen Artikel in der Scrum-Kolumne (kommt demnächst).

Scrum Master

FRANK WINTER

SCRUM ROLES

Stakeholder

FRANK WINTER

• A stakeholder is anyone that is potentially affected by the outcome of the project. The term is usually used to name the management or the customers

SCRUM ROLES

Scrum Meetings3

FRANK WINTER

Confi

denti

al

RESTRICTED

Scrum Activities

FRANK WINTER

• Sprint Planning

• Daily Scrum

• Sprint Review

• Sprint Retrospective• Product Backlog Refinement

SCRUM MEETINGS

Sprint Planning

FRANK WINTER

Description

• Product owner present the backlog items in priority order for review.• Review and clarify user Backlog items/stories.

• Breakdown larger stories and each story into task and acceptance criteria.

• Task are estimated in hours by team.

• Developer and tester assigned to task.

• Process continue until all available hours are used for the sprint.• Output of sprint planning is Sprint backlog, Estimated tasks, etc.

SCRUM MEETINGS

Sprint Planning

FRANK WINTER

• Goal: Team to plan and agree on backlog items they can complete and confirm the tasks required tosupport acceptance.

• Who: Scrum Team, Scrum Master, Product owner.

• When: Beginning of the Sprint.

• Duration: 4 Hours for 2 weeks sprint.

• How: In 2 parts.

• Part 1: Define what needs to be done.

• Part 2: How to achieve goal.

• Input: Priority, Product Backlog, Acceptance criteria, Capacity.

• Output: Sprint goal, Sprint Backlog, Tasks and their estimates, burn down chart, DOD (Definition ofDone), Development plan/ Strategy.

SCRUM MEETINGS

Planning Poker - Aufwandsschätzung in spielerischer Form

FRANK WINTER

• Gruppendynamische AspekteDas Verfahren ist eine Schätzmethode, die weitestgehend anonym vorgenommen wird, indem die einzelnen Gruppenmitglieder den jeweiligen Aufwand mit verdeckten Planning Poker Karten schätzen. So besteht die Möglichkeit, innerhalb der Gruppendynamik sehr dominanten und sehr devoten Typen (ruhige Mitarbeiter, die sich nicht gerne in der Vordergrund drängen) entgegenzuwirken. Das Ziel ist es also, dass jedes Gruppenmitglied sich aktiv an der Schätzung beteiligt und sein Wissen beiträgt.

• Komplexe AufgabenPlanning Poker eignet sich besonders bei Projekten und Aufgabenstellungen, die viele unbekannte Variable beinhalten und bei denen Fachwissen aus mehreren Bereichen aufeinandertrifft. So kommt es überwiegend im IT-Bereich zum Einsatz. Dabei besteht ein Entwickler-Team häufig aus Programmierern, Web-Designern, Testern, Anwendern und anderen, die für die Zeit der Projektarbeit aus Ihren Expertenbereichen zusammenkommen. So können unterschiedliche Sichtweisen verschiedenster Fachleute einbezogen werden.

SCRUM MEETINGS

Vorteile von Planning Poker

FRANK WINTER

• Aufwandsschätzung ist keine leichte Aufgabe - vor allem wenn Wissen und Erfahrung verschiedenster Experten aufeinander trifft.

• Aufwandsschätzungen sind zumeist ein undankbarer Aspekt im Projektmanagement. Viele wollen sich erst gar nicht bei der Schätzung beteiligen und andere wiederum sind der Meinung alles zu wissen. Was passiert also? Bisherige Schätzverfahren dauern, was eine optimale Zeitplanung vernichtet und in den seltensten Fällen wird ein Konsens im Team erreicht.

SCRUM MEETINGS


FRANK WINTER

Spaß an der Aufwandsschätzung• Und hier kommt Planning Poker ins Spiel. Anstatt Experten iterativ eine

Auflistung von Punkten oder Aufgaben schätzen zu lassen, können diese im Team auch einfach, schnell und mit Spaß einen Konsens erreichen, indem sie gemeinsam mit Hilfe der Planning Poker Cards den Aufwand kalkulieren.

Diskutieren bringt mehr Wissen für alle• Ein weiterer positiver Aspekt der sich durch das Schätzen mit Planning

Poker ergibt, ist wohl, dass über die Aufgabenstellung diskutiert wird. So können Fragen gestellt, Annahmen getroffen sowie Risiken aufgezeigt werden, wodurch das Wissen aller Beteiligter vereinheitlicht wird und so gegebenenfalls Ängste oder ähnliches vorab reduziert werden können.

SCRUM MEETINGS


FRANK WINTER

Unterschiedliche Expertenmeinungen• Planning Poker vereint die Meinungen verschiedenster Experten

innerhalb eines crossfunktionalen Teams. So können die jeweiligen Gruppenteilnehmer aufgrund unterschiedlicher Annahmen (resultierend aus dem Wissen ihres Fachbereichs) verschiedenste Meinungen vertreten. In Diskussionen und Schätzrunden werden diese Meinungen angenähert.

Alle sind beteiligt• Ein wichtiger Gesichtspunkt, der sich zwangsläufig ergibt, ist der, dass

durch die Anonymität des Spiels alle Charaktertypen des Teams an der Entscheidung mitwirken. So tragen auch weniger selbstbewusste Typen, die in einer offenen Schätzrunde sich wahrscheinlich zurückgehalten hätten, zu der Entscheidungsfindung bei und zu dominante Persönlichkeiten können gebremst werden.

SCRUM MEETINGS

Daily Scrum I

FRANK WINTER

• Goal: Plan for the day, Inspect and Adapt daily towards reachingthe sprint goal.

• Who: Scrum Team, Scrum Master.

• When: Daily throughout the sprint.

• Duration: 15 minutes maximum.

• How: Team members form a group to focus on daily plan, Discuss on issues faced yesterday.

• Input: Current status, risks, and done work.

• Output: Plan for the day, task to work.

SCRUM MEETINGS

Daily Scrum II

FRANK WINTER

• Description:

• Daily development Team standup for 15 minutes in circle andtalk only on three points.

o What I did since last daily scrum meeting?o What I am planning to work on today?o Impediments (Issue/blocker) if any?

• Scrum master protect the team and facilitate for being effective.

• This give an opportunity to team to inspect and adapt daily on the sprint goal.

SCRUM MEETINGS

Sprint Review

FRANK WINTER

• Goal: Get feedback on product development. Inspect and adapton the product feature.

• Who: Scrum Team, Scrum Master, Product owner, Stakeholders.

• When: Last day of sprint.

• Duration: 2 hours for a 2 week sprint.

• How: Demonstrate the working product to all.

• Input: Sprint goal, 100% done stories, acceptance criteria.

• Output: Acceptance, feedback on demonstrated stories.

• Description:

• During this meeting team demonstrate 100% completed work.

• Scrum master facilitate the environment.

• In case any changes or new request, Product owner (PO) noteand updates the product backlog as required.

• Product owner is final decision maker on acceptance.

SCRUM MEETINGS

Sprint Retrospective I

FRANK WINTER

• Goal: To inspect and adapt to become more effectiveand efficient on process, people, culture aspect.

• Who: Scrum Team (anyone participation is decided bythe scrum team on invite basis only).

• When: Last day of sprint.

• Duration: 2 hours for a 2 week sprint.

• How: Close room discussion of observer pattern anddesire results/improvements.

• Input: Observation, issues, experience, pattern in behavior, recommendations, feedback and information.

• Output: List of activities/steps/suggestions that help tomake more effective and efficient. Action items on theteam

SCRUM MEETINGS

Sprint Retrospective II

FRANK WINTER

• Description:

• Participation in the discussion to inspect and adapt asscrum team

• Scrum master play vital role in sprint retrospective, Scrum master bring in the culture of openness, trustand respect as people discuss the improvement areas, facilitate and focus on improvement and changes thatpointing fingers at others.

• This is platform to scrum master to help team resolveineffectiveness in the systems

• Inspect and Adapt: Try everything that makes sense, reject things that didn’t work even after repeated trails. Shape your culture, process and practice

SCRUM MEETINGS

Examples

SPRINT RETROSPECTIVE/ LESSONS LEARNED

FRANK WINTER

1.Intro

2.Set theStage

3.Gather Data

4. GenerateInsights

5.Dicide What to Do

6.Closing theRetrospectiv

1. Intro

FRANK WINTER

SECHS PHASEN DER RETROSPEKTIVEN

• Moderator/innen-Zeit• Agenda• Oberste Direktive• Vegas-Regel• Beschlusskontrolle

1. SPIELREGELN DER RETRO

FRANK WINTER

1. INTRO

• Wir gehen davon aus, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen, Gewisse und Kenntnisstand gehandelt haben.

2. Oberste Dirktive

FRANK WINTER

1. INTRO

Alles, was wir hier besprechen, bleibt unter uns.

Es sei denn, wir beschließen etwas Anderes

3. Vegas Regel

FRANK WINTER

1. INTRO

1.Intro

2.Set theStage

3.Gather Data

4. GenerateInsights

5.Dicide What to Do


2. Set the Stage

FRANK WINTER


• Stimmung klären• Erwartungshaltung teilen• Jeder erhebt einmal die Stimme

1. Ankommen

FRANK WINTER

2. SET THE STAGE

• Jeder setzt den Satz fort:“ Wenn ich nicht hier wäre, wäre ich…“ Jeder begründet kurz, warum er/ sie dort wäre. Niemand kommentiert, Gesagtes bleibt so stehen und wirkt.

1. Wenn ich nicht hier wäre,…

FRANK WINTER

2. SET THE STAGE

1.Intro

2.Set theStage

3.Gather Data

4. GenerateInsights

5.Dicide What to Do


3. Stimmung / Fakten erfassen

FRANK WINTER


• Was läuft gut?• Was hält uns auf?• „Höre auf Deinen Bauch!“• Ungesagtes aussprechen


FRANK WINTER

3. GATHER DATA


FRANK WINTER

• Was zieht, was bremst? Jede/r trägt Punkte bei. Schweigend. Wer fertig ist, hängt seine Punkte auf. Bei Unklarheiten werden Karten erläutert. Clustern in der Gruppe. Titel dafür vergeben.

3. GATHER DATA

1.Intro

2.Set theStage

3.Gather Data

4. GenerateInsights

5.Dicide What to Do


1. Intro

FRANK WINTER


• Ursachen finden, nicht über Symptome jammern• Prozessfehler suchen, Konkretes benennen• Was kann ich anders machen?• Was kann das Team anders machen?

1. Verstehen was los ist

FRANK WINTER

4. GENERATE INSIGHTS

• Macht ein Brainstorming in vier Kategorien, um schnell auf eine Liste von Themen zu kommen, die der Gruppe wichtig sind.

• Nachdem die Themen aus Phase 2 besprochen wurden, zeige der Gruppe einen Flipchart mit vier Quadranten beschriftet mit :), :(, "Idee!" und "Wertschätzung". Verteile selbstklebende Notizzettel. Die Teilnehmer dürfen in jedem Quadranten Zettel aufhängen - mit immer nur einem Aspekt / Gedanken pro Zettel.

1. Lernmatrix

FRANK WINTER


• Gruppiere die Zettel.• Verteile 6-10 Klebepunkte und ermuntere die Gruppe, gemeinsam darüber abzustimmen, welches

die wichtigsten Themen sind.• Diese Liste ist euer Auftakt für Phase 4.

2. Lernmatrix

FRANK WINTER


3. Bild Lernmatrix

FRANK WINTER


J L

New Ideas

Appre-ciate

1.Intro

2.Set theStage

3.Gather Data

4. GenerateInsights

5.Dicide What to Do


1. Intro

FRANK WINTER

SECHS RETROSPEKTIVEN PHASEN

• Maximal zwei Maßnahmenpakete / Teamregeln in jeder Retrospektive• Konkrete Maßnahmen• Lösungen im Team suchen

1. FÜR ÄNDERUNG ENTSCHEIDEN

FRANK WINTER

5. DICEDE WHAT TO DO

• 2 Gruppen erarbeiten Handlungsoptionen, stellen Ergebnisse vor. Alle wählen (Klebepunkte) eine Variante aus. Gewählte Variante wird in ToDos überführt

2. Ergebnisse Pitchen

FRANK WINTER

5. DICEDE WHAT TO DO

1.Intro

2.Set theStage

3.Gather Data

4. GenerateInsights

5.Dicide What to Do


1. Intro

FRANK WINTER

SECHS RETROSPEKTIVEN PHASEN

• Gefühlsmäßiges Abholen nach der Sitzung Aufnehmen / Beantworten der• Eingangstimmung• Erfolge feiern• Feedback für Moderator/in

1. ABSCHLUSS FINDEN

FRANK WINTER

6. CLOSING THE RETROSPECTIV

Blitzlicht

FRANK WINTER


• Nur „das Blitzlicht“ spricht, Blitzlicht darf nicht kommentiert werden, Blitzlicht beantwortet drei Fragen:

• „Wie geht es mir?“• „Was nehme ich für mich mit?“• „Was möchte ich der Runde sagen?“

2. BLITZLICHT

FRANK WINTER


• Moderiert (klare Struktur)• Visualisiert (klare Ergebnisse)• Verbindlich sein

LERNEN MÖGLICH MACHEN MIT RETROSPEKTIVEN

FRANK WINTER

SPRINT RETROSPECTIVE

Artefakte4

FRANK WINTER

- Ein Sprint ist im Rahmen der Methode Scrum eine fest definierte Zeitspanne. - Der Sprint verfügt über eine feste Iterationslänge und einen festen Endtermin.- In der Regel beträgt die typische Sprintdauer 2-4 Wochen.- Jeder Sprint umfasst jeweils wieder den Entwurf, die Implementierung der Elemente und einen

abschließenden Test.

Sprints

FRANK WINTER

SCRUM

Product Increment

• Every sprint produces a product increment, the mostimportant Scrum artifact. A product Increment is the "goalline" for each sprint and, at the end of the sprint, it must:

• Be of high enough quality to be given to users.• Meet the Scrum team's current definition of done.

• Be acceptable to the product owner.

SCRUM ARTEFAKTE

FRANK WINTER

Product Backlog I

• This is an ordered list of ideas for the product, which can come from the product owner, teammembers, or stakeholders. A description andestimate of effort complement each product backlogitem.The product backlog is ordered to maximizethe value delivered by the Scrum team. The development teams work comes from the productbacklog, and nowhere else. Every feature, enhancement, bug fix, documentation requirement, every bit of work the team does comes from a product backlog item.

SCRUM ARTEFAKTE

FRANK WINTER

Product Backlog II

• The product backlog may begin as a large or shortlist. Typically it begins short and becomes longerand more defined as time goes on. Product backlogitems slated for implementation soon will be"refined," which means they will further clarified, defined, and split into smaller chunks. Though theproduct owner is responsible for maintaining theproduct backlog, the development team helpsproduce and update it.

SCRUM ARTEFAKTE

FRANK WINTER

DOR: DEFINITION OF READYREADY IS WHEN THE TEAM SAYS: "AH, WE GET IT".• Backlog Stories sind klein genug (z.B. 4-5 User Storys passen in einen Sprint)

• Backlog Stories und Tasks sind für jeden Beteiligten klar verständlich

• Jeder Backlog Task ist geschätzt

• Jede Backlog Story hat Akzeptanzkriterien (Min. 1)

• Akzeptanzkriterien sind von jedem Beteiligten verstanden

• Jedes Backlog Item hat einen Wert (für den Kunden)

• Ursprung eines Backlog Items ist klar (wer hat die Story geschrieben und warum)

FRANK WINTER

Click ’Insert’

branding

Align with bottom line

• The sprint backlog is the list of refined product backlog items chosen for development in the currentsprint, together with the teams plan for accomplishing the work.

• It reflects the teams forecast of what work can be completed. Once the sprint backlog isestablished, the development team begins work on the new product increment.

Sprint Backlog

SCRUM ARTEFAKTE

FRANK WINTER

DEFINITION OF DONE• Das gesamte Team inkl. PO stimmt zu, dass das Feature “done” ist• Das Feature ist entwickelt, der Code ist gereviewt• Das Feature ist ausreichend getestet (basierend auf der Teststrategie des Teams)• Das Feature ist “live”

FRANK WINTER

Team SetupTeam Building

5

FRANK WINTER

BEEINFLUSSEN DER TEAM PERFORMANCE

FRANK WINTER

• Verständnis von Teamperformance

• Teambuilding

• Adaptive Führung

• Emotionale Intelligenz

• Praxis

• Daily stand-ups

• Co- located teams

• Team space

• Agile Werkzeuge

12

3

4567

• Das Tuckman Phasenmodell wird häufig in Teamentwicklungsprozessen zu Beginn herangezogen, um zu bestimmen, an welchem Punkt sich ein Team befindet und welche Maßnahme die beste ist, um den Leistungswirkungsgrad zu erhöhen. So kann es mal sinnvoll sein, besondere Trainings zu veranstalten, in denen Menschen zu einer Gemeinschaft zusammen finden (Forming). Oder es ist geboten, in einem geschützten Workshop-Rahmen konstruktive Kritik und Erwartungen an die Rolle der anderen zu formulieren (Storming). Oder es geht vielleicht darum, im Seminar verbindliche Regeln festzulegen, hinter denen alle stehen (Norming und Performing).

Gradmesser im EntwicklungsprozessTuckman Phasenmodell

FRANK WINTER

• Forming: Die Orientierungsphase, in der sich die Gruppenmitglieder kennen lernen. Vieles ist unklar, die Leistungsfähigkeit eingeschränkt, man ist fixiert auf den Leiter. Fragen wie „Was soll ich tun?“ oder „Wo stehe ich?“ werden gestellt. Führungskräfte sollten in dieser Phase Sicherheit und Orientierung geben, Aufgaben aufzeigen, klare Anweisungen geben und die Arbeitsergebnisse regelmäßig kontrollieren.

• Storming: Die Nahkampfphase, in der die Ziele zunehmend klarer werden. Es gibt unterschiedliche Auffassungen, eine Rollenverteilung bildet sich heraus, erste Machtkämpfe entstehen. Führungskräfte sollten hier auf die Disziplin achten, zu Konflikten ermutigen, jedoch Angriffe unterbinden. Hier bieten sich bestimmte Kommunikationstechniken an. Außerdem können sie mit ersten vom Team erreichten Erfolgen die Motivation aufrechterhalten.

• Norming: Die Organisationsphase, in der klare Strukturen und Verabredungen getroffen werden. Wichtige Fragen sind „Wie können wir das Ziel erreichen?“ oder „Wie wollen wir miteinander umgehen?“. Führungskräfte helfen ihren Mitarbeitern am besten, indem sie z.B. Aufgaben übertragen, Wortführer stärker einbinden, Teambesprechungen ansetzen und Erfolge sichtbar machen.

• Performing: Die Integrationsphase, in der die Selbstorganisation in den Vordergrund tritt. Teams werden kreativer und flexibel im Umgang. Fragen sind „Wer hat was zu tun?“ oder „Wie können wir das Ziel am effektivsten erreichen?“. Führungskräfte sind nun gut beraten, Aufgaben weiter zu übertragen, sich zurückzuziehen und dabei offen für Neuerungen zu sein.

• Die Adjouring Phase gilt explizit nur für temporär zusammenarbeitende Teams. Somit gehört sie nicht zu den anderen vier Phasen, die jedes Team durchläuft. Sie beschreibt ausschließlich Auflösungsprozesse, die beispielsweise beim Abschluss der gemeinsamen Arbeit stattfinden.

FRANK WINTER

• So populär diese Forderung der New-Work-Bewegung ist, so irreführend ist sie auch• Ein Chef muss per Definition andere Ziele verfolgen als ein Coach• Es ist unethisch, wenn dem Mitarbeiter dieser Unterschied nicht verdeutlicht wird• In jüngster Zeit wird unter dem Dach der #NewWork-Bewegung vermehrt gefordert, Führungskräfte

mögen als Coach ihrer Mitarbeiter agieren. Das ist, freundlich formuliert, Unfug. Die Rollen eines Coaches und einer Führungskraft, zumindest in hierarchischen Organisationen, sind hochgradig widersprüchlich. Hier die gekürzte Form einer Coaching-Definition gemäß des Deutschen Verbands für Coaching und Training (dvct e. V.):

• „Professionelles Coaching setzt ganz auf die Entwicklung individueller Lösungskompetenz. Der Klient bestimmt das Ziel des Coachings. Der Coach verantwortet den Prozess, bei dem der Klient neue Erkenntnisse gewinnt und Handlungsalternativen entwickelt.“

Die Führungskraft als Coach?

FRANK WINTER

VERSTÄNDNIS VON TEAMPERFORMANCE

• Der wesentliche Passus ist: Der Klient bestimmt das Ziel des Coachings. Ein professioneller Coach muss den Zielen des Klienten gleichgültig gegenüberstehen, in dem Sinn, dass letztlich alle Ziele gleich gültig sein könnten. Der Klient bestimmt, wo die Reise hingeht, der Coach hilft bei der Erstellung des Reiseplans und beim Verstehen der Landkarte. Aber Sinn und Zweck der Reise müssen vom Klienten kommen – und nur von ihm.

• Der Knackpunkt: Führungskräfte in hierarchischen Organisation können per Definition gerade nicht gleichgültig sein gegenüber den Zielen ihrer Mitarbeiter. Sie haben Zielvorgaben, welche aus den Unternehmenszielen abgeleitet wurden. Auf Basis dieser Zielvereinbarungen werden wiederum Zielvorgaben für die eigenen Mitarbeiter definiert. Dies geschieht bei geschulten Führungskräften heutzutage selbstredend in einem dialogischen Prozess, den Mitarbeitern werden also Gestaltungsspielräume gegeben. Nichtsdestotrotz können sie ihre Ziele nicht frei wählen. Diese systembedingte Abhängigkeit ist mit einer klassischen Coach-Klienten-Beziehung unvereinbar.

• Selbstverständlich können Führungskräfte sich für ihre Führungsaufgabe bestimmter Methoden bedienen, die im oder für den Coachingkontext entwickelt wurden, beispielsweise systemisch orientierte Fragetechniken. Doch ändert das rein gar nichts an der Tatsache, dass die Rechte und Pflichten einer Coach- beziehungsweise Führungsrolle grundverschieden bleiben.

• Manche mögen nun sagen, dass es hier lediglich um eine sprachliche Nuance geht, aber das greift deutlich zu kurz. Es ist unethisch gegenüber den Mitarbeitern, wenn ihnen ihre disziplinarisch verantwortliche Führungskraft als Coach „verkauft“ wird. Denn am Ende des Tages bleibt trotz der Umbenennung eine hierarchische Abhängigkeit, welche mit der Rolle eines wohlwollend-neutralen Begleiters auf Augenhöhe unvereinbar ist.

• 1) Artikel von Dr. Nico Rose veröffentlich in xing

Die Führungskraft als Coach?

FRANK WINTER

VERSTÄNDNIS VON TEAMPERFORMANCE

Others6

FRANK WINTER

Task Board

• Task boards allow transparency, display what is the live status of the teams work and focus area:

• Simple task board has backlog , To-do, in progress anddone status.

• There are various format.• Team design their best “Information Radiators” that

helps them in self-organizing.

OTHERS - INFORMATION RADIATORS

FRANK WINTER

Burn Down Chart

• For current sprint, it shows the total estimated workremaining for the entire forecasted sprint backlog againsttime

• Updated by team, regularly and continuously.

• Independent of the work, it represents total remainingestimated time to market to achieve sprint goal.

OTHERS - INFORMATION RADIATORS

FRANK WINTER

Continious Delivary7

FRANK WINTER

• CI fokussiert sich auf das Integrieren von Code, sowie die Validierung des Codes auf Unit Tests und eventuell Integration Test Level. Ihre Applikation ist in einer Testumgebung verfügbar.

Was bedeutet es, wenn man wirklich Continuous Integration umsetzt?

FRANK WINTER

• Um dies zu erreichen, umfasst Continuous Integration folgendes:• Entwickler führen mindestens einmal am Tag einen Check-In ihres Codes durch• Der Code wird bei jedem Check-In gebaut• Code wird bei jedem Check-In automatisch mit Unit Tests getestet• Jeder hat Zugriff auf den Build und die Testreports• Der Build ist schnell, sodass Entwickler schnell Feedback bekommen• Tests werden in einer herunterskalierten Version der Produktionsumgebung ausgeführt• Build-Artefakte werden in einem versionskontrollierten Artefakt-Repository abgelegt• Build-Artefakte werden nach jedem erfolgreichen Build automatisch auf eine Testumgebung deployt• Wenn all dies umgesetzt wurde, ist man auf einem reifen CI-Level und bereit für den nächsten Schritt:

Continuous Delivery.

Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment

FRANK WINTER

CONTINIOUS INTEGRATION

• Continuous Delivery (CD) ist der nächste Schritt nach CI. Zur Umsetzung solltest Du folgendes implementiert haben:

• Deine Software ist den gesamten Lebenszyklus hindurch deploybar• Dein Team priorisiert das Sicherstellen von auslieferungsfähiger Software über das Umsetzen neuer

Features• Jeder erhält schnelles, automatisiertes Feedback über den Auslieferungszustand Deiner Systeme, jedes

Mal, wenn jemand eine Änderung daran vornimmt• Sie führen bei Bedarf Deployments jeder beliebigen Version der Software per Knopfdruck durch• Es gibt eine enge, kollaborative Arbeitsbeziehung zwischen allen, die am Auslieferungsprozess beteiligt sind

(häufig als DevOps-Kultur bezeichnet)• Umfassende Automatisierung aller möglichen Bereiche des Auslieferungsprozesses sind umgesetzt,

üblicherweise mit einer Deployment Pipeline.


FRANK WINTER

CONTINIOUS DELIVARY

• Wo liegt nun konkret der Unterschied zwischen Continuous Integration und ContinuousDelivery?

• Um in der Lage zu sein, mit einem Wimpernschlag nach Produktion zu deployen, ist mehr vonnöten. Automatisierung ist der gemeinsame Teil hierbei. Den nächsten Schritt zu nehmen heißt also, noch mehr zu automatisieren. Automatisiere die Regressionstests, sodass Du in der Lage bist, ohne manuelles Testen prüfen zu können, ob Dein Produkt korrekt funktioniert. Außerdem ist auch das Deployment in Produktion automatisiert.

• Der Schritt in die Produktion ist eine Entscheidung der Businessseite. Aber wenn diese Entscheidung getroffen wird, dauert es nicht lange und kostet nicht viel Stress. Es wird ein Knopfdruck sein, der das Produkt-Inkrement in Produktion bringt.


FRANK WINTER

CONTINIOUS DELIVERY

• Was sind die Vorteile über Continuous Integration hinausgehend?• Eine Reduzierung des Risikos von Deployments in Produktion. Da (fast) alles automatisiert ist

(Test, Deployment, Infrastruktursetup und –deployment), ist das Risiko, dass dabei etwas schiefgeht, gering.

• Der Fortschritt des Entwicklungsteams ist transparent. Wenn eine Applikation vollständig getestet und in eine Produktions(-ähnliche)umgebung deployt wird, ist offensichtlich, dass etwas „done“ ist. Somit können Entwickler nicht mehr sagen, dass etwas „done“ ist, wenn danach noch eine Woche vergeht, bis es live gestellt ist.

• Schließlich der wichtigste Punkt, man bekommt schnelles Feedback. Das Risiko, dass eine Idee für Deine Kunden nicht funktioniert, ist reduziert, da Du schnell Feedback bekommst, anstatt erst Monate oder Jahre später.


FRANK WINTER

CONTINIOUS DELIVARY

• Continuous Deployment• Der letzte Schritt ist Continuous Deployment (CD). Die gleiche Abkürzung wie Continuous Delivery

und deswegen denken vielleicht auch viele Leute, dass es dasselbe ist. Es gibt jedoch einen kleinen Unterschied zwischen beiden.

• Machst Du Continuous Delivery, so legst Du fest, wann Du in Produktion gehst. Bei ContinuousDeployment machst Du das nicht.Jeder erfolgreiche Build resultiert in einem automatisierten Deployment in Produktion.

• In beiden Fällen kannst Du leicht in Produktion gehen, aber bei Continuous Delivery ist es eine Wahl.


FRANK WINTER

CONTINIOUS DEPOYMENT

• Vorteile von Continuous Deployment• Jede Änderung geht direkt in Produktion. Somit ist das Zeitfenster für eine verlorene Gelegenheit

sehr klein.• Feedback erfolgt noch schneller.• Durch den Einsatz von Feature Toggles ist es möglich, nach Produktion zu deployen, ohne die

neuen Funktionalitäten zu nutzen. Es sind also Teile, die noch unfertig sind, bereits in Produktion deployt. So kann bereits Feedback über das Deployment der neuen Teile gesammelt werden.

• Daneben ist es auch möglich, eine kleine Nutzergruppe eine neue Funktionalität bereits testen zu lassen, um auch so frühes Feedback zu bekommen.


FRANK WINTER

CONTINIOUS DELIVARY

Danke / Thank you

FRANK WINTER

You can follow us on:

traveltainment.de

scrum das agile framework - dswin.synology.medswin.synology.me/projekte/scrum/horizont_scrum...

Documents