Birgit Mallow zu ScrumBut, den negativen Auswirkungen und möglichen Ansätzen zur Lösung der Probleme. Vortrag auf der Lean EAM 2017 in München.

1. München, 17. Oktober 2017
Wir machen Scrum, aber …

2. Scrum ist ein Framework zur Entwicklung und
Erhaltung komplexer Produkte
2
Quelle:
https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf
Quelle:
http://de.slideshare.net/johannhartmann/vom-entwickler-zur-fuhrungskraft
Johann-Peter Hartmann, GF Mayflower GmbH; Bierdeckel von it-agile
Passt auf einen Bierdeckel

3. Scrum ist leichtgewichtig, einfach zu verstehen
Planning
1
2
3
4
5
6
7
8
Product
Backlog
Retros-
pektive
Review
Develop-
ment
&
Test
Product Increment
Sprint
Product Owner
Team
Scrum Master
Sprint Burndown
Daily Scrum
5 Ereignisse
3 Artefakte
3 Rollen
Vision
To Do OnGoing Done
Sprint Backlog
3

4. Scrum ist leichtgewichtig, einfach zu verstehen
4
Scrum ist mit 85% die derzeit
am weitesten verbreitete
agile Vorgehensweise.
Quelle: Prof. Dr. Ayelt Komus
„Status Quo Agile 2016/2017“

5. Status Quo Agile 2016/2017
5
Quelle: Hochschule Koblenz „Status Quo Agile 2016/2017“

6. 5 Ereignisse
3 Artefakte
3 Rollen
Scrum ist leichtgewichtig, einfach zu verstehen
Planning
Vision 1
2
3
4
5
6
7
8
Product
Backlog
Retros-
pektive
Review
Develop-
ment
&
Test
Product Increment
Sprint
Product Owner
Team
Scrum Master
Sprint Burndown
Daily Scrum
To Do OnGoing Done
Sprint Backlog
6

7. 5 Ereignisse
3 Artefakte
3 Rollen
Scrum ist leichtgewichtig, einfach zu verstehen
Planning
Vision 1
2
3
4
5
6
7
8
Product
Backlog
Retros-
pektive
Review
Develop-
ment
&
Test
Product Increment
Sprint
Product Owner
Team
Scrum Master
Sprint Burndown
Daily Scrum
To Do OnGoing Done
Sprint Backlog
7

8. ScrumBut
 Der Einsatz von Scrum verstärkt ein bestehendes
Problem, das schwer zu beheben ist.
ScrumBut macht das „erträglich“ durch eine
Änderung von Scrum.
 Einfache Syntax (ScrumBut)(Reason)(Workaround)
Beispiel:
 (Wir machen Scrum, aber)
(jeden Tag ein Daily Scrum machen, ist so einfach zu viel Overhead),
(deshalb machen wir das nur einmal pro Woche.)"
8
Quelle: https://www.scrum.org/resources/what-scrumbut

9. ScrumBut
 Der Einsatz von Scrum verstärkt ein bestehendes
Problem, das schwer zu beheben ist.
ScrumBut macht das „erträglich“ durch eine
Änderung von Scrum.
 Einfache Syntax (ScrumBut)(Reason)(Workaround)
Beispiel:
 (Wir machen Scrum, aber)
(jeden Tag ein Daily Scrum machen, ist so einfach zu viel Overhead),
(deshalb machen wir das nur einmal pro Woche.)"
9
Effekt:
Vorteile von Scrum
sind eingeschränkt !
Quelle: https://www.scrum.org/resources/what-scrumbut

10. Beispiel ScrumBut I
„… deshalb lassen wir Scrum Meetings weg“
10
Planning
Retros-
pektive
Review
Develop-
ment
&
Test
Sprint
Daily Scrum

11. Beispiel ScrumBut I
„… deshalb lassen wir Scrum Meetings weg“
11
Planning
Retros-
pektive
Review
Develop-
ment
&
Test
Sprint
Daily Scrum
Nutzen des Daily:
• Transparenz über den
gemeinsamen
Arbeitsfortschritt
• Team-Synchronisation
• Kurzfristige Absprachen
zur Fein-Planung
• Stärkt Collective
Ownership des Teams
To Do OnGoing Done
Sprint Backlog
Sprint Burndown
Team

12. Rückblick
Beispiel ScrumBut I
„… deshalb lassen wir Scrum Meetings weg“
12
Planning
Retros-
pektive
Review
Develop-
ment
&
Test
Sprint
Daily Scrum
Nutzen der Retro:
• Transparenz über die Qualität von
Prozess und Zusammenarbeit
• Voraussetzung für Lernschleifen und
Prozessverbesserung
• Stärkt Selbstverantwortung und
Selbstorganisation
• Fördert Teamentwicklung
Product Owner
Team
Scrum Master

13. Scrum ist ein wirksamer PDCA-Zyklus –
jedoch nur, wenn alle Meetings wie vorgesehen
durchgeführt werden
13
PLAN
CHECK
& ACT
PROCESS
CHECK
& ACT
PRODUCT
Sprint
DO

14. Scrum ist ein wirksamer PDCA-Zyklus –
lebt von den Agilen Prinzipien
14
PLAN
CHECK
& ACT
PROCESS
Sprint
DO
Transparenz
Time-Boxing
Ermächtigung und
Selbstorganisation
Regelmäßig liefern
CHECK
& ACT
PRODUCT
Inspect & adapt

15. Beispiel ScrumBut II
„… deshalb verlängern wir den Sprint, wenn wir
nicht fertig werden. “
15
Sprint
1 – 4 Wochen
immer gleich lang
Nutzen der einheitlichen Sprint-Länge:
• Reduziert Planungs- und
Organisationsaufwand
• Voraussetzung für eine stabile
„Velocity“ des Teams, d.h. für die
entscheidende Metrik und Basis der
Selbstkontrolle des Teams
• Voraussetzung für zuverlässige
Vorhersagbarkeit von Lieferungen
• Voraussetzung für die Release
Planung des Product Owners
0
500
1000
1500
2000
1 5 10 15
Release Burndown
VerbleibendeArbeit
Sprints
Geplantes
Release-
Ende

16. Beispiel ScrumBut III – „… deshalb haben wir
keinen Scrum Master / keinen Product Owner.“
16
Planning
Retros-
pektive
Review
Develop-
ment
&
Test
Sprint
Daily Scrum
1
2
3
4
5
6
7
8
Product
Backlog
Product Increment
Sprint Burndown
Product Owner
Team
Scrum Master
Vision
To Do OnGoing Done
Sprint Backlog

17. Fokus: „Was“
• Prio nach Kunden-Wert
• Wirtschaftlicher Erfolg des
Produkts
Fokus: „Wie“
• Liefern des
Produktinkrements
• Hohe Qualität
Fokus: „Prozess“
• Coach, Facilitator
• Teamentwicklung
• Schützt das Team nach außen
Framework Scrum –
Führung durch „Gewaltenteilung“
17
Fokus: Strategie & Mitarbeiter
• Strategie, Sinn, Orientierung
• Rahmenbedingungen
• Mitarbeiterentwicklung
3 „Management-Rollen“
im Scrum Team
Product Owner
TeamScrum Master
Führungskraft

18. 5 Dysfunktionen im Team
Der Scrum Master hilft dem Team, sich zu verbessern und
Störungen in der Zusammenarbeit zu beseitigen.
18
Keine Verantwortung
übernehmen
Mangelnder Einsatz
Angst vor Konflikten
Kein Vertrauen haben
Ergebnisse
nicht beachten
 Nur mittelmäßige Team-Leistungen;
Key Deadlines im Projekt werden meistens verpasst
 Keine Motivation, Aufgaben termingerecht fertig zu stellen.
 Das Team fokussiert sich auf die Leistungen von Einzelnen,
nicht auf die gemeinsame Team Performance.
 Das Team Lässt sich leicht ablenken und verliert
leistungsorientierte Mitarbeiter.
 Im Team bestehen Unklarheiten in
Bezug auf das Ziel.
 Sehr viel Zeit auf Analyse verwenden.
 Schwächen werden voreinander verborgen.
 Die Teammitglieder zögern mit der Bitte
um Hilfe.
 Vordergründiges Harmoniestreben,
Scheinkonsens; evtl. Group Thinking.
 Scheu vor berechtigten Konflikten.
Symptome
Quelle: nach Patrick M. Lencioni
Team

19. Fundament von Scrum: 5 Werte
Teams, die Scrum richtig einsetzen, halten sich an diese Werte
19
Offenheit
Selbstverpflichtung
Mut
Respekt
Fokus
 Große Offenheit; die Teammitglieder machen sich Arbeits-
fortschritt und Probleme dabei gegenseitig transparent.
 Fokus beibehalten: das Team konzentriert sich auf
wenige Aktivitäten und achtet sehr genau auf die Ergebnisse.
 Die Teammitglieder verpflichten sich
selbst und stellen sicher, dass das
gesamte Team leistungsbereit ist.
 Die Teammitglieder erwerben sich
gegenseitig Respekt und stellen damit
Vertrauen im Team her.
 Die Teammitglieder entwickeln den Mut,
sich gegenseitig zur Rechenschaft zu ziehen.
Quelle: nach Patrick M. Lencioni und
https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf
Der Scrum Master hilft dem Scrum Team die Scrum Werte
und agilen Prinzipien zu reflektieren und in den
Alltag zu übertragen.
Scrum Master
Team
Product Owner

20. ScrumBut schafft einen Workaround um
ein bestehendes Problem
20
Quelle: https://www.scrum.org/resources/what-scrumbut
Effekt:
Vorteile von Scrum
sind eingeschränkt !

21. Was tun wir gegen ScrumBut?
Eine Möglichkeit: Setzen Sie Scrum ein!
21
Scrum löst Ihre Probleme
nicht, aber
Scrum macht Ihnen
die Probleme transparent!

22. Scrum macht Ihnen die Probleme transparent!
 Die bereits bestehenden Meetings sind
unstrukturiert, weder effizient noch
effektiv.
 Sie werden parallel zu den Scrum
Meetings beibehalten.
22
 Die Scrum Meetings sind zu
viel Overhead.
Symptome Mögliche Ursachen
 Die Scrum Meetings konse-
quent durchführen. Sie sind
fokussiert und time-boxed.
 Welche Regel-Meetings können
wir streichen?
 Das Team plant nicht realistisch.
 Das Team macht Multitasking.
 Die Teammitglieder erhalten zusätzliche
ungeplante Aufgaben.
 Das Team schafft i.d.R. die
geplanten Sprintinhalte nicht.
 Der Scrum Master hilft dem
Team realistisch zu planen,
eine stabile Velocity zu
entwickeln und Multitasking zu
vermeiden.
 Der Scrum Master schützt das
Team gegen Störungen von
außen und eskaliert ggf. ins
Management.
Mögliche Lösungen
 Führungsdefizite, mangelhafte
Personalentwicklung oder fehlendes
Vertrauen in Mitarbeiter.
 Wir haben keine geeigneten
Scrum Master.
 Konsequente Besetzung aller
Scrum Rollen, ggf. Einstellung.
 Führung reflektiert das eigene
Rollenverständnis und
Menschenbild (Theory X/Y).
Beispiele

23. Scrum macht Ihnen die Probleme transparent!
23
Probleme, die wir kennen,
können wir erforschen,
gute Lösungsideen dazu
entwickeln und
ausprobieren.

24. Dogmatismus meiden, Erkenntnis fördern:
Shu Ha Ri – Erlernen der Kampfkunst – 3 Phasen
24
1. Shu 2. Ha 3. Ri
Regeln strikt befolgen
Wirkungsweise verstehen
Eigene Anpassungen machen
Wirkungsweise verstehen
Tiefes Verständnis ist erworben
Eigene Regeln entwickeln
„Scrum ist für Ri-Menschen gemacht.“
(Alistair Cockburn)

25. In der Ha-Phase Experimente starten
25
Experimente / Ausprobieren von kleinen Anpassungen
 Nehmen den Druck, gleich die 100%-Lösung zu haben.
 Unterstützen das kontinuierliche iterative Lernen.
 Sind agil! Ins Handeln kommen ist wichtiger als Theoretisieren.
Verhalten
Haltung
Überzeugungen
Glaubenssätze
ErfahrungenExperimente

26. 26
Fokus
Mut
Offenheit
Selbstverpflichtung
Respekt
Transparenz
Time-Boxing
Ermächtigung und
Selbstorganisation
Regelmäßig liefern
Inspect & adapt
Scrum Werte
geben Orientierung
und Agile Prinzipien

27. 27
Scrum ist vor allem eine Haltung,
agiles Arbeiten braucht ein agiles Mindset.
Deshalb Scrum Werte und agile Prinzipien
reflektieren!

28. Im Alltag zeigt sich, wie das Scrum Team die
agilen Werte und Prinzipien lebt
28
Scrum
Werte
Scrum Master
Team
Product Owner

29. 29
 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.
Agiles Manifest der Software-Entwicklung 2001
Die Werte

30. 30
 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
Zum Agilen Manifest gehören 12 Prinzipien.
Das Scrum Team reflektiert:
Welche 3 Prinzipien wollen wir jetzt besonders fokussieren?
Menschen & Kommunikation
Schnelle Produktlieferung
Kundenorientierung
Wertschöpfung
Agiles Manifest der Software-Entwicklung 2001
Es geht also vor allem um …

31. Fazit: Gegen ScrumBut ist Kraut gewachsen
31
Und: konsequent dranbleiben!

32. Noch Fragen …
… dann fragen mich doch!
32
Birgit Mallow
Organisationsentwicklung und Prozessberatung
München
und
Dresden
+49 171 / 276 42 61
bma@mallow-consulting.de
www.mallow-consulting.de
LinkedIn: https://www.linkedin.com/in/birgit-mallow-b3812b49
XING: http://www.xing.com/profile/Birgit_Mallow
Twitter: @BirgitMallow

33. Projekterfahrungen (Auswahl)
 Versicherung – IT-Service Management, Business Process Management
 Fertigungsindustrie – Konzernweite Professionalisierung der IT, Aufbau der CIO-Organisation
 Fertigungsindustrie – Business Process Management
 Versicherung – Change Facilitation für den optimierten Schadenregulierungsprozess
 Internationale Bank – Agile Entwicklung fachlicherBankprodukte, interim Scrum Master, Führungskräfte-Coaching
 IT-Dienstleister – Konzeptuelle Vorbereitung agiler Skalierung
 Auskunftei – Agile Skalierung
 Beratungsteam – Agiler Beratungsprozess
 StartUps – Basis schaffen für Wachstum in einer agilen Organisation
 Vertriebsbereich – Agile Vorgehensweisen für den operativen Alltag
 Fertigungsindustrie – Interim Scrum Master und Agile Coach, Vorbereitung agiler Skalierung
 Energieunternehmen – Agile Coaching der Product Owner und Führungskräfte
 Fertigungsunternehmen – Agile Facilitation zum Aufbau interner Agiler Coaches aus OE, Vertrieb/Marketing, Prod.-Vorber.
 IT-Dienstleister – Führungskräfte entwickeln im Selbstversuch das unternehmenseigene agile Framework
Netzwerkpartnerin der wibas GmbH
Birgit Mallow
33
Diplom-Informatikerin der Fachrichtung Psychologie
Management Consulting seit rund 20 Jahren
Organisationsentwicklerin mit dem Fokus
 Agile Facilitation für Agile Vorgehensweisen / Agile Organisation
(Agile Coach, PSM, PSPO, SAFe Program Consultant (SPC4), …)
 Transformationsprozesse & werteorientierter Kulturwandel
(Akkreditierter CTT Consultant, Barrett Values Centre)
 Business Process Management, agile BPM (OECB2)