SlideShare ist ein Scribd-Unternehmen logo
1
Es geht nicht um Velocity.
Ich glaube sogar, dass das Konzept der Velocity kontraproduktiv ist.
Deshalb erzähle ich auch nichts von Hyperproductive Teams. Das macht Jeff
Sutherland.
2
Es geht um Business Value.
High Performance Teams produzieren Business Value. Und zwar mehr davon als
andere Teams.
Das Blöde ist nur, dass die meisten Organisationen den Business Value nicht messen
können.
Deshalb messen sie das Team. Das ist eigentlich traurig.
Velocity ist eine Metrik, Business Value ist ein Wert.
Das ist der Unterschied. Metriken kann ich fälschen, Werte nicht.
3
Auf der Agile World 2013 gab es einen Vortrag zum Thema Flow.
Danach entstand eine Diskussion, in der viel über Taylorismus gesprochen wurde.
Da kam nach meinen Gefühl viel Angst zum Ausdruck.
Angst vor zu viel Flow, davor ausgebeutet zu werden.
4
Was der Mann gemacht hat, hat Peter F. Drucker mal gut zusammengefasst:
Durch Management-Methoden die Produktivität der Industrie um den Faktor 50
gesteigert.
Das war die große Leistung des 20 Jahrhunderts.
Der Punkt ist, und das hat Peter F. Drucker auch gesagt:
Im 21. Jahrhundert muss so eine Steigerung im Bereich der Wissensarbeit geschehen.
Deshalb glaube ich, dass ein Taylor heute das Agile Manifest unterzeichnet hätte.
5
6
Ich kam einmal zu einem Team, das in einem großen Scrum Projekt arbeitete.
Das Team musste sich an Regeln halten, die für alle Teams im Projekt galten, weil so
ein Projekt nur durch das strikte Einhalten gemeinsamer Regeln funktionieren kann.
Eine der Regeln war, dass alle Tasks im Planning mit Stunden geschätzt werden
mussten und im JIRA dokumentiert werden mussten.
Das Team startete einen zwei Wochen-Sprint mit 20 geschätzten und dokumentierten
Tasks.
Was passierte? Genau, der Sprint ging schief.
In der Retrospektive wurde dann beschlossen, was getan werden muss, um das zu
ändern.
7
Die Änderung war: noch genauer Schätzen.
Das ist natürlich Käse, und deshalb kamen am Ende nur noch 10 Tasks raus.
Der Sprint ging natürlich wieder schief.
Ein linearer Forecast hätte im nächsten Sprint zu 0 Tasks geführt.
Als ScrumMaster platzt man in so einer Situation fast.
Es ist aber wichtig, das Team solche Fehler machen zu lassen.
8
Ich kenne viele ScrumMaster, die wissen wie‘s geht.
Die sagen dann ihren Teams: Macht es so und so und dann macht ihr es richtig.
Wenn ich dann zu ihnen sagen: was Du da treibst, ist nicht agil, das ist genau das
tayloristische, gegen das Du immer wetterst, gucken sie mich entsetzt an.
ScrumMaster haben auch einen Coaching-Auftrag.
Coaching heißt, jemanden zur Erkenntnis zu führen.
Der Punkt ist: Wenn ich jemandem sage, wie er etwas machen soll, erreiche ich
bestenfalls eine Verhaltensänderung durch Nach-ahmung.
Was für ein High Performance Team notwendig ist, ist eine Verhaltensänderung durch
Nach-denken.
Man muss einen Fehler gemacht haben, um den Lösungsweg schätzen zu können.
Natürlich soll der ScrumMaster dem Team Best Practices an die Hand geben.
Und: Nein, das dauert nicht länger, es ist nur anstrengender für den ScrumMaster.
Der Trick ist: kontrolliertes Scheitern.
9
In der folgenden Retro habe ich dem Team gesagt, sie sollten darüber nachdenken,
dass ein Task nicht länger als einen Tag dauern sollte.
Im Team war ein Physiker, man sieht, was da raus kam.
Zwei Wochen Sprint. Das sind 10 Arbeitstage (normalerweise).
Bei einem 7-Personen-Team sollten mindestens 70 Tasks am Board hängen.
Das wurde in der Retro akzeptiert. Klingt auch erstmal logisch. Ist aber gar nicht so
einfach.
Hindernisse:
Schätzen dauert lang, Dokumentieren dauert lang.
Das hält das Team von guten Tasks ab.
Das ist ein Impediment, das wir eliminieren müssen.
Problem: Organisationsregel, projektweit gültig.
10
Die Lösung ist, den Wert und die Kosten dieser Aktivitäten zu messen.
Hier hilft uns unverhoffterweise Taylor höchstselbst.
11
Also ermitteln wir mal, was uns so eine Aufgabe kostet.
Ich habe dann die Zeit gestoppt, die das Team mit den Schätzungen verbracht hat und
die Zeit gestoppt, die für das Eintragen und Verwalten der Tasks benötigt wurde.
Mit den marktüblichen Tagessätzen habe ich dann einen Preis pro Task im Tool –
nennen wir es J. – ermittelt.
Der war ganz schön hoch – und das bei Lean Management!
100 Tasks kosten uns da ungefähr 1700 Euro. Pro Sprint.
Das sind mindestens zwei Personentage bezahlt für – ja, wofür eigentlich?
12
Das Ziel agiler Methoden sind nicht glückliche Teams.
Das Ziel ist Business Value, die glücklichen Teams entstehen dann automatisch.
Mit Business Value kann der ScrumMaster unglaublich viel durchsetzen.
Das ist auch sehr anstrengend, aber das ist es wert.
Damit kauft der ScrumMaster die Freiheit für das Team, die es braucht, um ein High
Performance Team zu werden.
13
Nach einer Weile hatte das Team 200 Tasks am Board.
Im Sprint hatten die richtig Flow, konnten parallelisieren und sich selbst organisieren.
14
15
Die Anzahl der Tasks pendelte sich zwischen 100 und 150 pro Sprint ein.
Das Planning dauerte nur noch zwei Stunden – das Team hatte plötzlich Zeit, sich mit
Business Value zu beschäftigen.
16
Der erste Schritt ist vollbracht 
Wir wissen jetzt, wie so ein Team lernt und wie man die Organisation dazu bringt, das
Team etwas Sinnvolles machen zu lassen.
17
Die große Frage, die sich immer wieder stellt ist: Welche Leute sind in so einem
Team?
Das Ganze ist mehr als die Summe seiner Teile.
Das mag bei Lego Duplo zutreffen.
Bei Teams ist man ganz schnell an dem Punkt, bei dem das Ganze weitaus weniger ist,
als jedes Teil für sich allein.
18
Link zum Bild: http://www.focus.de/fotos/ein-mann-gegen-eine-armee-fuer-john-
carter-taylor-kitsch-ein-ganz_mid_1038533.html
Eine Firma, mit der ich gerarbeitet habe, hatte mal ein Scrum Team aus ihren 10
besten Consultants zusammengestellt.
Jeder hatte den Ruf, eine 1-Personen-Armee zu sein.
Das Team ist grandios gescheitert, weil sie keinen Team-Spirit entwickeln konnten.
Solche Leute sind bewundernswert und extrem wertvoll, wenn sie allein Probleme
lösen.
Im Team stehen sie sich aber oft gegenseitig im Weg, da kann man auch als
ScrumMaster oft nicht viel ausrichten.
Der Glaube, 10 solche Leute wären als Team die Überflieger, ist ein typischer
Management Brainfuck.
19
Erfahrung ist in der Wissensarbeit nur die halbe Miete.
Letztens war ein Artikel im HBR, dessen Fazit war, dass man sich beim Recruiting von
Leuten nicht primär auf deren Erfahrung sondern auf deren Potential konzentrieren
sollte.
Link: http://hbr.org/2014/06/21st-century-talent-spotting/ar/1
Dass das mit den 10 Top-Entwicklern nicht klappt, habe ich ja gerade schon erzählt.
Aber wie kann ich Leute identifizieren, die ein hohes Potential haben?
Gleich vorweg: es ist weder der IQ noch der GMAT-Score, der einem da irgendwas
hilft.
Assessment Center sind dafür auch totaler Blödsinn.
Die wichtige Eigenschaft ist: Neugier!
Neugierige Menschen habe ich als Menschen mit Potential kennengelernt.
Und als kommunikative Menschen, Neugier setzt Kommunikationsfähigkeit voraus.
20
Veränderung im Team sind ein heikles Thema.
Oft bekomme ich zu hören: Probleme muss der ScrumMaster lösen, das Team muss
stabil bleiben.
Teamstabilität ist nicht gleichzusetzen mit dem Nichtverändern der
Teamzusammensetzung!
Teamstabilität bedeutet, Sustainable Pace.
Ich habe dreimal Leute aus Teams nehmen lassen – und mich einmal geweigert,
jemanden ins Team aufzunehmen.
Als ScrumMaster.
Das fühlte sich nicht gut an…
21
Wann muss man Leute aus dem Team nehmen?
Erstens:
Wenn jemand trotz Coaching die nötige Leistung nicht bringen kann, muss man ihn
austauschen.
Ich glaube fest, dass es richtige Aufgaben für jeden Mensch gibt.
Aber: Nicht jeder Mensch hat für jede x-beliebige Aufgabe das gleiche Potential.
Das zu erkennen ist gute Führung.
Ein ScrumMaster muss dabei mit dem Management zusammenarbeiten, wenn ein High
Performance Team entstehen soll.
Zweitens:
Wenn jemand kein agiles Mindset entwickeln kann, muss man ihn austauschen.
Das kann auch bedeuten, dass man auf Qualifikationen im Team vorübergehend verzichtet.
Vielleicht tut das mal kurz weh.
Aber dauerhafte Störenfriede tun viel mehr weh.
Das Team wird dann aber stabiler, das Vertrauen wächst und auch die Fähigkeiten.
Und drittens – ihr werdet es kaum glauben:
Wenn jemand zu gut ist, sollte man ihn austauschen.
Seniore Entwickler, graue Eminenzen, so gut sie sein mögen, bremsen oft – ohne es zu wollen
– das Team in seiner Entwicklung.
Ein Kollege wusste alles, war sogar im Urlaub erreichbar.
Der stand kurz vor dem Burn Out, aber man wollte ihn nicht austauschen, weil das Team
Angst hatte.
Irgendwann hat es doch geklappt – und das Team wurde produktiver.
Ein Wunder…?
22
23
Auch der ScrumMaster sollte nicht ewig beim Team bleiben.
Irgendwann kann er dem Team nichts mehr geben.
Das ist so, das kann man nicht ändern.
Der ScrumMaster sollte dann gehen.
Aber es sollte einen Nachfolger für den ScrumMaster geben, sonst…
24
…drohen Gefahren.
Die drohen übrigens auch mit ScrumMaster.
Zum Beispiel wird die Zuverlässigkeit des Teams, die hohe Produktivität, als normal
empfunden.
Es gibt Organisationen, die streichen dann die Stelle des ScrumMasters.
Das ist selten dämlich, denn dann geht das Team kaputt.
Habe ich zweimal erlebt.
Auch das Team läuft Gefahr, die eigenen Produktivität als normal zu empfinden und
hört auf, besser zu werden.
Hier muss man gegensteuern.
Und dann gibt es doch Momente, in denen was schief läuft.
Die ganze Organisation steht Kopf und der neue Chief Executive Business Kasper führt
Command & Control ein statt eine Retrospektive zu machen.
Das kann ein High Performance Team zerstören, daran kann ein ganzes Unternehmen
kaputt gehen.
Das habe ich auch erlebt. Leider.
25
26

Weitere ähnliche Inhalte

Andere mochten auch

lebensmittelverschwendung im handel
lebensmittelverschwendung im handellebensmittelverschwendung im handel
lebensmittelverschwendung im handel
bkdeutztastethewaste
 
Hsp aufgabenohne tr
Hsp aufgabenohne trHsp aufgabenohne tr
Hsp aufgabenohne tr
kkreienbrink
 
EJERCICIOS JOSE GREGORIO MELENDEZ
EJERCICIOS JOSE GREGORIO MELENDEZEJERCICIOS JOSE GREGORIO MELENDEZ
EJERCICIOS JOSE GREGORIO MELENDEZ
Jose Gomez
 
52 Wochen Erfolg mit Geschäftskunden - Kapitel 02
52 Wochen Erfolg mit Geschäftskunden - Kapitel 0252 Wochen Erfolg mit Geschäftskunden - Kapitel 02
52 Wochen Erfolg mit Geschäftskunden - Kapitel 02
Stephan Heinrich
 
Social Media Services
Social Media ServicesSocial Media Services
Social Media Services
SMTravelers
 
FMK2015: FileMaker Grundlagen Formeln by Longin Ziegler
FMK2015: FileMaker Grundlagen Formeln by Longin ZieglerFMK2015: FileMaker Grundlagen Formeln by Longin Ziegler
FMK2015: FileMaker Grundlagen Formeln by Longin Ziegler
Verein FM Konferenz
 
Social Media Services rw
Social Media Services rwSocial Media Services rw
Social Media Services rw
SMTravelers
 
Grüne Märkte
Grüne MärkteGrüne Märkte
Grüne Märkte
jhuber_
 
Interieur12 draft willembossier
Interieur12 draft willembossierInterieur12 draft willembossier
Interieur12 draft willembossier
wbossier
 
FMK2014: FileMaker Plugin erzeugen by Christian Schmitz
FMK2014: FileMaker Plugin erzeugen by Christian SchmitzFMK2014: FileMaker Plugin erzeugen by Christian Schmitz
FMK2014: FileMaker Plugin erzeugen by Christian Schmitz
Verein FM Konferenz
 
Cloud Computing - Technologie und Missbrauchspotentiale
Cloud Computing - Technologie und MissbrauchspotentialeCloud Computing - Technologie und Missbrauchspotentiale
Cloud Computing - Technologie und Missbrauchspotentiale
adesso AG
 
Firmenpräsentation dankl+partner consulting
Firmenpräsentation dankl+partner consulting Firmenpräsentation dankl+partner consulting
Firmenpräsentation dankl+partner consulting
dankl+partner consulting gmbh
 
Schulung power designer
Schulung power designerSchulung power designer
Schulung power designer
Alicengiz78
 
Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...
Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...
Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...
Virenschleuder-Preis
 
Gottes bedingungslose liebe - God's Unconditional Love
Gottes bedingungslose liebe - God's Unconditional LoveGottes bedingungslose liebe - God's Unconditional Love
Gottes bedingungslose liebe - God's Unconditional Love
Freekidstories
 
Scala und Lift
Scala und LiftScala und Lift
Scala und Lift
adesso AG
 
Screencasts erstellen - Wie, Warum und Wozu?
Screencasts erstellen - Wie, Warum und Wozu?Screencasts erstellen - Wie, Warum und Wozu?
Screencasts erstellen - Wie, Warum und Wozu?
Wolfgang Wagner
 
Die nacht, in der die engel sangen
Die nacht, in der die engel sangenDie nacht, in der die engel sangen
Die nacht, in der die engel sangen
Freekidstories
 

Andere mochten auch (20)

lebensmittelverschwendung im handel
lebensmittelverschwendung im handellebensmittelverschwendung im handel
lebensmittelverschwendung im handel
 
Hsp aufgabenohne tr
Hsp aufgabenohne trHsp aufgabenohne tr
Hsp aufgabenohne tr
 
EJERCICIOS JOSE GREGORIO MELENDEZ
EJERCICIOS JOSE GREGORIO MELENDEZEJERCICIOS JOSE GREGORIO MELENDEZ
EJERCICIOS JOSE GREGORIO MELENDEZ
 
52 Wochen Erfolg mit Geschäftskunden - Kapitel 02
52 Wochen Erfolg mit Geschäftskunden - Kapitel 0252 Wochen Erfolg mit Geschäftskunden - Kapitel 02
52 Wochen Erfolg mit Geschäftskunden - Kapitel 02
 
Social Media Services
Social Media ServicesSocial Media Services
Social Media Services
 
FMK2015: FileMaker Grundlagen Formeln by Longin Ziegler
FMK2015: FileMaker Grundlagen Formeln by Longin ZieglerFMK2015: FileMaker Grundlagen Formeln by Longin Ziegler
FMK2015: FileMaker Grundlagen Formeln by Longin Ziegler
 
Social Media Services rw
Social Media Services rwSocial Media Services rw
Social Media Services rw
 
Grüne Märkte
Grüne MärkteGrüne Märkte
Grüne Märkte
 
Interieur12 draft willembossier
Interieur12 draft willembossierInterieur12 draft willembossier
Interieur12 draft willembossier
 
FMK2014: FileMaker Plugin erzeugen by Christian Schmitz
FMK2014: FileMaker Plugin erzeugen by Christian SchmitzFMK2014: FileMaker Plugin erzeugen by Christian Schmitz
FMK2014: FileMaker Plugin erzeugen by Christian Schmitz
 
Cloud Computing - Technologie und Missbrauchspotentiale
Cloud Computing - Technologie und MissbrauchspotentialeCloud Computing - Technologie und Missbrauchspotentiale
Cloud Computing - Technologie und Missbrauchspotentiale
 
Firmenpräsentation dankl+partner consulting
Firmenpräsentation dankl+partner consulting Firmenpräsentation dankl+partner consulting
Firmenpräsentation dankl+partner consulting
 
Schulung power designer
Schulung power designerSchulung power designer
Schulung power designer
 
Wolverine
WolverineWolverine
Wolverine
 
Ivenacker eichen
Ivenacker eichenIvenacker eichen
Ivenacker eichen
 
Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...
Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...
Präsentation von Germar Tetzlaff auf dem Kick-off für den Virenschleuder-Prei...
 
Gottes bedingungslose liebe - God's Unconditional Love
Gottes bedingungslose liebe - God's Unconditional LoveGottes bedingungslose liebe - God's Unconditional Love
Gottes bedingungslose liebe - God's Unconditional Love
 
Scala und Lift
Scala und LiftScala und Lift
Scala und Lift
 
Screencasts erstellen - Wie, Warum und Wozu?
Screencasts erstellen - Wie, Warum und Wozu?Screencasts erstellen - Wie, Warum und Wozu?
Screencasts erstellen - Wie, Warum und Wozu?
 
Die nacht, in der die engel sangen
Die nacht, in der die engel sangenDie nacht, in der die engel sangen
Die nacht, in der die engel sangen
 

Ähnlich wie Mythos High Performance Teams

Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
Mayflower GmbH
 
Agile Führung - echt jetzt?
Agile Führung - echt jetzt?Agile Führung - echt jetzt?
Agile Führung - echt jetzt?
Agile Usergroup Unterfranken
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Gerrit Beine
 
Pecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolPecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in Cool
Stefan ROOCK
 
Wie teams selbstorganisiert werden manageagile2019
Wie teams selbstorganisiert werden manageagile2019Wie teams selbstorganisiert werden manageagile2019
Wie teams selbstorganisiert werden manageagile2019
Kai Brausewetter
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
Johann-Peter Hartmann
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management
Agility Brainfucks - Von Menschen, Bildern und Steampunk-ManagementAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management
Gerrit Beine
 
Agile resource managment_AAC2019
Agile resource managment_AAC2019Agile resource managment_AAC2019
Agile resource managment_AAC2019
Agile Austria Conference
 
Das Ende der Karriere
Das Ende der KarriereDas Ende der Karriere
Das Ende der Karriere
Johann-Peter Hartmann
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
Johann-Peter Hartmann
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
Johann-Peter Hartmann
 
Performancesysteme und Relative Ziele (BetaCodex 10)
Performancesysteme und Relative Ziele (BetaCodex 10)Performancesysteme und Relative Ziele (BetaCodex 10)
Performancesysteme und Relative Ziele (BetaCodex 10)
Niels Pflaeging
 
Lean EAM 2017 Wir machen Scrum, aber ...
Lean EAM 2017 Wir machen Scrum, aber ...Lean EAM 2017 Wir machen Scrum, aber ...
Lean EAM 2017 Wir machen Scrum, aber ...
Birgit Mallow
 
Interview zum Buch
Interview zum BuchInterview zum Buch
Interview zum Buch
Niels Pflaeging
 
Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...
Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...
Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...
Dennis Brunotte
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
Johann-Peter Hartmann
 
Die Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen Unternehmen
Die Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen UnternehmenDie Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen Unternehmen
Die Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen Unternehmen
grow.up. Managementberatung GmbH
 
Was tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdfWas tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdf
Oliver Schirmer
 
Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...
Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...
Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...
Heinz Peter Wallner
 
Weiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und MädelsWeiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und Mädels
NETUserGroupBern
 

Ähnlich wie Mythos High Performance Teams (20)

Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Agile Führung - echt jetzt?
Agile Führung - echt jetzt?Agile Führung - echt jetzt?
Agile Führung - echt jetzt?
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
 
Pecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolPecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in Cool
 
Wie teams selbstorganisiert werden manageagile2019
Wie teams selbstorganisiert werden manageagile2019Wie teams selbstorganisiert werden manageagile2019
Wie teams selbstorganisiert werden manageagile2019
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management
Agility Brainfucks - Von Menschen, Bildern und Steampunk-ManagementAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management
 
Agile resource managment_AAC2019
Agile resource managment_AAC2019Agile resource managment_AAC2019
Agile resource managment_AAC2019
 
Das Ende der Karriere
Das Ende der KarriereDas Ende der Karriere
Das Ende der Karriere
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
 
Performancesysteme und Relative Ziele (BetaCodex 10)
Performancesysteme und Relative Ziele (BetaCodex 10)Performancesysteme und Relative Ziele (BetaCodex 10)
Performancesysteme und Relative Ziele (BetaCodex 10)
 
Lean EAM 2017 Wir machen Scrum, aber ...
Lean EAM 2017 Wir machen Scrum, aber ...Lean EAM 2017 Wir machen Scrum, aber ...
Lean EAM 2017 Wir machen Scrum, aber ...
 
Interview zum Buch
Interview zum BuchInterview zum Buch
Interview zum Buch
 
Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...
Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...
Wie Google den "War of Talents" gewinnt. Persönliche Erfahrungen von Laszlo B...
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Die Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen Unternehmen
Die Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen UnternehmenDie Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen Unternehmen
Die Entwicklung junger Unternehmen - Vom agilen Start-Up zum trägen Unternehmen
 
Was tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdfWas tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdf
 
Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...
Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...
Wege aus der Knechtschaft - Führung ohne Management - heinz peter wallner - s...
 
Weiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und MädelsWeiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und Mädels
 

Mehr von adesso AG

SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)
adesso AG
 
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMPSNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP
adesso AG
 
A Business-Critical SharePoint Solution From adesso AG
A Business-CriticalSharePoint SolutionFrom adesso AGA Business-CriticalSharePoint SolutionFrom adesso AG
A Business-Critical SharePoint Solution From adesso AG
adesso AG
 
Was Sie über NoSQL Datenbanken wissen sollten!
Was Sie über NoSQL Datenbanken wissen sollten!Was Sie über NoSQL Datenbanken wissen sollten!
Was Sie über NoSQL Datenbanken wissen sollten!
adesso AG
 
Continuous Delivery praktisch
Continuous Delivery praktischContinuous Delivery praktisch
Continuous Delivery praktisch
adesso AG
 
Agilität, Snapshots und Continuous Delivery
Agilität, Snapshots und Continuous DeliveryAgilität, Snapshots und Continuous Delivery
Agilität, Snapshots und Continuous Delivery
adesso AG
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
adesso AG
 
Getriebene Anwendungslandschaften
Getriebene AnwendungslandschaftenGetriebene Anwendungslandschaften
Getriebene Anwendungslandschaften
adesso AG
 
Google App Engine JAX PaaS Parade 2013
Google App Engine JAX PaaS Parade 2013Google App Engine JAX PaaS Parade 2013
Google App Engine JAX PaaS Parade 2013
adesso AG
 
Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)
Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)
Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)
adesso AG
 
OOP 2013 NoSQL Suche
OOP 2013 NoSQL SucheOOP 2013 NoSQL Suche
OOP 2013 NoSQL Suche
adesso AG
 
NoSQL in der Cloud - Why?
NoSQL in der Cloud -  Why?NoSQL in der Cloud -  Why?
NoSQL in der Cloud - Why?
adesso AG
 
Lean web architecture mit jsf 2.0, cdi & co.
Lean web architecture mit jsf 2.0, cdi & co.Lean web architecture mit jsf 2.0, cdi & co.
Lean web architecture mit jsf 2.0, cdi & co.
adesso AG
 
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDISchlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
adesso AG
 
Zehn Hinweise für Architekten
Zehn Hinweise für ArchitektenZehn Hinweise für Architekten
Zehn Hinweise für Architekten
adesso AG
 
Agile Praktiken
Agile PraktikenAgile Praktiken
Agile Praktiken
adesso AG
 
Java und Cloud - nicht nur mit PaaS
Java und Cloud - nicht nur mit PaaS Java und Cloud - nicht nur mit PaaS
Java und Cloud - nicht nur mit PaaS
adesso AG
 
Neue EBusiness Perspektiven durch HTML5
Neue EBusiness Perspektiven durch HTML5Neue EBusiness Perspektiven durch HTML5
Neue EBusiness Perspektiven durch HTML5
adesso AG
 
CloudConf2011 Introduction to Google App Engine
CloudConf2011 Introduction to Google App EngineCloudConf2011 Introduction to Google App Engine
CloudConf2011 Introduction to Google App Engine
adesso AG
 
Scala 4 Enterprise
Scala 4 EnterpriseScala 4 Enterprise
Scala 4 Enterprise
adesso AG
 

Mehr von adesso AG (20)

SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP (Kurzversion)
 
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMPSNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP
SNMP Applied - Sicheres Anwendungs-Monitoring mit SNMP
 
A Business-Critical SharePoint Solution From adesso AG
A Business-CriticalSharePoint SolutionFrom adesso AGA Business-CriticalSharePoint SolutionFrom adesso AG
A Business-Critical SharePoint Solution From adesso AG
 
Was Sie über NoSQL Datenbanken wissen sollten!
Was Sie über NoSQL Datenbanken wissen sollten!Was Sie über NoSQL Datenbanken wissen sollten!
Was Sie über NoSQL Datenbanken wissen sollten!
 
Continuous Delivery praktisch
Continuous Delivery praktischContinuous Delivery praktisch
Continuous Delivery praktisch
 
Agilität, Snapshots und Continuous Delivery
Agilität, Snapshots und Continuous DeliveryAgilität, Snapshots und Continuous Delivery
Agilität, Snapshots und Continuous Delivery
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
 
Getriebene Anwendungslandschaften
Getriebene AnwendungslandschaftenGetriebene Anwendungslandschaften
Getriebene Anwendungslandschaften
 
Google App Engine JAX PaaS Parade 2013
Google App Engine JAX PaaS Parade 2013Google App Engine JAX PaaS Parade 2013
Google App Engine JAX PaaS Parade 2013
 
Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)
Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)
Wartbare Web-Anwendungen mit Knockout.js und Model-View-ViewModel (MVVM)
 
OOP 2013 NoSQL Suche
OOP 2013 NoSQL SucheOOP 2013 NoSQL Suche
OOP 2013 NoSQL Suche
 
NoSQL in der Cloud - Why?
NoSQL in der Cloud -  Why?NoSQL in der Cloud -  Why?
NoSQL in der Cloud - Why?
 
Lean web architecture mit jsf 2.0, cdi & co.
Lean web architecture mit jsf 2.0, cdi & co.Lean web architecture mit jsf 2.0, cdi & co.
Lean web architecture mit jsf 2.0, cdi & co.
 
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDISchlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
 
Zehn Hinweise für Architekten
Zehn Hinweise für ArchitektenZehn Hinweise für Architekten
Zehn Hinweise für Architekten
 
Agile Praktiken
Agile PraktikenAgile Praktiken
Agile Praktiken
 
Java und Cloud - nicht nur mit PaaS
Java und Cloud - nicht nur mit PaaS Java und Cloud - nicht nur mit PaaS
Java und Cloud - nicht nur mit PaaS
 
Neue EBusiness Perspektiven durch HTML5
Neue EBusiness Perspektiven durch HTML5Neue EBusiness Perspektiven durch HTML5
Neue EBusiness Perspektiven durch HTML5
 
CloudConf2011 Introduction to Google App Engine
CloudConf2011 Introduction to Google App EngineCloudConf2011 Introduction to Google App Engine
CloudConf2011 Introduction to Google App Engine
 
Scala 4 Enterprise
Scala 4 EnterpriseScala 4 Enterprise
Scala 4 Enterprise
 

Mythos High Performance Teams

  • 1. 1
  • 2. Es geht nicht um Velocity. Ich glaube sogar, dass das Konzept der Velocity kontraproduktiv ist. Deshalb erzähle ich auch nichts von Hyperproductive Teams. Das macht Jeff Sutherland. 2
  • 3. Es geht um Business Value. High Performance Teams produzieren Business Value. Und zwar mehr davon als andere Teams. Das Blöde ist nur, dass die meisten Organisationen den Business Value nicht messen können. Deshalb messen sie das Team. Das ist eigentlich traurig. Velocity ist eine Metrik, Business Value ist ein Wert. Das ist der Unterschied. Metriken kann ich fälschen, Werte nicht. 3
  • 4. Auf der Agile World 2013 gab es einen Vortrag zum Thema Flow. Danach entstand eine Diskussion, in der viel über Taylorismus gesprochen wurde. Da kam nach meinen Gefühl viel Angst zum Ausdruck. Angst vor zu viel Flow, davor ausgebeutet zu werden. 4
  • 5. Was der Mann gemacht hat, hat Peter F. Drucker mal gut zusammengefasst: Durch Management-Methoden die Produktivität der Industrie um den Faktor 50 gesteigert. Das war die große Leistung des 20 Jahrhunderts. Der Punkt ist, und das hat Peter F. Drucker auch gesagt: Im 21. Jahrhundert muss so eine Steigerung im Bereich der Wissensarbeit geschehen. Deshalb glaube ich, dass ein Taylor heute das Agile Manifest unterzeichnet hätte. 5
  • 6. 6
  • 7. Ich kam einmal zu einem Team, das in einem großen Scrum Projekt arbeitete. Das Team musste sich an Regeln halten, die für alle Teams im Projekt galten, weil so ein Projekt nur durch das strikte Einhalten gemeinsamer Regeln funktionieren kann. Eine der Regeln war, dass alle Tasks im Planning mit Stunden geschätzt werden mussten und im JIRA dokumentiert werden mussten. Das Team startete einen zwei Wochen-Sprint mit 20 geschätzten und dokumentierten Tasks. Was passierte? Genau, der Sprint ging schief. In der Retrospektive wurde dann beschlossen, was getan werden muss, um das zu ändern. 7
  • 8. Die Änderung war: noch genauer Schätzen. Das ist natürlich Käse, und deshalb kamen am Ende nur noch 10 Tasks raus. Der Sprint ging natürlich wieder schief. Ein linearer Forecast hätte im nächsten Sprint zu 0 Tasks geführt. Als ScrumMaster platzt man in so einer Situation fast. Es ist aber wichtig, das Team solche Fehler machen zu lassen. 8
  • 9. Ich kenne viele ScrumMaster, die wissen wie‘s geht. Die sagen dann ihren Teams: Macht es so und so und dann macht ihr es richtig. Wenn ich dann zu ihnen sagen: was Du da treibst, ist nicht agil, das ist genau das tayloristische, gegen das Du immer wetterst, gucken sie mich entsetzt an. ScrumMaster haben auch einen Coaching-Auftrag. Coaching heißt, jemanden zur Erkenntnis zu führen. Der Punkt ist: Wenn ich jemandem sage, wie er etwas machen soll, erreiche ich bestenfalls eine Verhaltensänderung durch Nach-ahmung. Was für ein High Performance Team notwendig ist, ist eine Verhaltensänderung durch Nach-denken. Man muss einen Fehler gemacht haben, um den Lösungsweg schätzen zu können. Natürlich soll der ScrumMaster dem Team Best Practices an die Hand geben. Und: Nein, das dauert nicht länger, es ist nur anstrengender für den ScrumMaster. Der Trick ist: kontrolliertes Scheitern. 9
  • 10. In der folgenden Retro habe ich dem Team gesagt, sie sollten darüber nachdenken, dass ein Task nicht länger als einen Tag dauern sollte. Im Team war ein Physiker, man sieht, was da raus kam. Zwei Wochen Sprint. Das sind 10 Arbeitstage (normalerweise). Bei einem 7-Personen-Team sollten mindestens 70 Tasks am Board hängen. Das wurde in der Retro akzeptiert. Klingt auch erstmal logisch. Ist aber gar nicht so einfach. Hindernisse: Schätzen dauert lang, Dokumentieren dauert lang. Das hält das Team von guten Tasks ab. Das ist ein Impediment, das wir eliminieren müssen. Problem: Organisationsregel, projektweit gültig. 10
  • 11. Die Lösung ist, den Wert und die Kosten dieser Aktivitäten zu messen. Hier hilft uns unverhoffterweise Taylor höchstselbst. 11
  • 12. Also ermitteln wir mal, was uns so eine Aufgabe kostet. Ich habe dann die Zeit gestoppt, die das Team mit den Schätzungen verbracht hat und die Zeit gestoppt, die für das Eintragen und Verwalten der Tasks benötigt wurde. Mit den marktüblichen Tagessätzen habe ich dann einen Preis pro Task im Tool – nennen wir es J. – ermittelt. Der war ganz schön hoch – und das bei Lean Management! 100 Tasks kosten uns da ungefähr 1700 Euro. Pro Sprint. Das sind mindestens zwei Personentage bezahlt für – ja, wofür eigentlich? 12
  • 13. Das Ziel agiler Methoden sind nicht glückliche Teams. Das Ziel ist Business Value, die glücklichen Teams entstehen dann automatisch. Mit Business Value kann der ScrumMaster unglaublich viel durchsetzen. Das ist auch sehr anstrengend, aber das ist es wert. Damit kauft der ScrumMaster die Freiheit für das Team, die es braucht, um ein High Performance Team zu werden. 13
  • 14. Nach einer Weile hatte das Team 200 Tasks am Board. Im Sprint hatten die richtig Flow, konnten parallelisieren und sich selbst organisieren. 14
  • 15. 15
  • 16. Die Anzahl der Tasks pendelte sich zwischen 100 und 150 pro Sprint ein. Das Planning dauerte nur noch zwei Stunden – das Team hatte plötzlich Zeit, sich mit Business Value zu beschäftigen. 16
  • 17. Der erste Schritt ist vollbracht  Wir wissen jetzt, wie so ein Team lernt und wie man die Organisation dazu bringt, das Team etwas Sinnvolles machen zu lassen. 17
  • 18. Die große Frage, die sich immer wieder stellt ist: Welche Leute sind in so einem Team? Das Ganze ist mehr als die Summe seiner Teile. Das mag bei Lego Duplo zutreffen. Bei Teams ist man ganz schnell an dem Punkt, bei dem das Ganze weitaus weniger ist, als jedes Teil für sich allein. 18
  • 19. Link zum Bild: http://www.focus.de/fotos/ein-mann-gegen-eine-armee-fuer-john- carter-taylor-kitsch-ein-ganz_mid_1038533.html Eine Firma, mit der ich gerarbeitet habe, hatte mal ein Scrum Team aus ihren 10 besten Consultants zusammengestellt. Jeder hatte den Ruf, eine 1-Personen-Armee zu sein. Das Team ist grandios gescheitert, weil sie keinen Team-Spirit entwickeln konnten. Solche Leute sind bewundernswert und extrem wertvoll, wenn sie allein Probleme lösen. Im Team stehen sie sich aber oft gegenseitig im Weg, da kann man auch als ScrumMaster oft nicht viel ausrichten. Der Glaube, 10 solche Leute wären als Team die Überflieger, ist ein typischer Management Brainfuck. 19
  • 20. Erfahrung ist in der Wissensarbeit nur die halbe Miete. Letztens war ein Artikel im HBR, dessen Fazit war, dass man sich beim Recruiting von Leuten nicht primär auf deren Erfahrung sondern auf deren Potential konzentrieren sollte. Link: http://hbr.org/2014/06/21st-century-talent-spotting/ar/1 Dass das mit den 10 Top-Entwicklern nicht klappt, habe ich ja gerade schon erzählt. Aber wie kann ich Leute identifizieren, die ein hohes Potential haben? Gleich vorweg: es ist weder der IQ noch der GMAT-Score, der einem da irgendwas hilft. Assessment Center sind dafür auch totaler Blödsinn. Die wichtige Eigenschaft ist: Neugier! Neugierige Menschen habe ich als Menschen mit Potential kennengelernt. Und als kommunikative Menschen, Neugier setzt Kommunikationsfähigkeit voraus. 20
  • 21. Veränderung im Team sind ein heikles Thema. Oft bekomme ich zu hören: Probleme muss der ScrumMaster lösen, das Team muss stabil bleiben. Teamstabilität ist nicht gleichzusetzen mit dem Nichtverändern der Teamzusammensetzung! Teamstabilität bedeutet, Sustainable Pace. Ich habe dreimal Leute aus Teams nehmen lassen – und mich einmal geweigert, jemanden ins Team aufzunehmen. Als ScrumMaster. Das fühlte sich nicht gut an… 21
  • 22. Wann muss man Leute aus dem Team nehmen? Erstens: Wenn jemand trotz Coaching die nötige Leistung nicht bringen kann, muss man ihn austauschen. Ich glaube fest, dass es richtige Aufgaben für jeden Mensch gibt. Aber: Nicht jeder Mensch hat für jede x-beliebige Aufgabe das gleiche Potential. Das zu erkennen ist gute Führung. Ein ScrumMaster muss dabei mit dem Management zusammenarbeiten, wenn ein High Performance Team entstehen soll. Zweitens: Wenn jemand kein agiles Mindset entwickeln kann, muss man ihn austauschen. Das kann auch bedeuten, dass man auf Qualifikationen im Team vorübergehend verzichtet. Vielleicht tut das mal kurz weh. Aber dauerhafte Störenfriede tun viel mehr weh. Das Team wird dann aber stabiler, das Vertrauen wächst und auch die Fähigkeiten. Und drittens – ihr werdet es kaum glauben: Wenn jemand zu gut ist, sollte man ihn austauschen. Seniore Entwickler, graue Eminenzen, so gut sie sein mögen, bremsen oft – ohne es zu wollen – das Team in seiner Entwicklung. Ein Kollege wusste alles, war sogar im Urlaub erreichbar. Der stand kurz vor dem Burn Out, aber man wollte ihn nicht austauschen, weil das Team Angst hatte. Irgendwann hat es doch geklappt – und das Team wurde produktiver. Ein Wunder…? 22
  • 23. 23
  • 24. Auch der ScrumMaster sollte nicht ewig beim Team bleiben. Irgendwann kann er dem Team nichts mehr geben. Das ist so, das kann man nicht ändern. Der ScrumMaster sollte dann gehen. Aber es sollte einen Nachfolger für den ScrumMaster geben, sonst… 24
  • 25. …drohen Gefahren. Die drohen übrigens auch mit ScrumMaster. Zum Beispiel wird die Zuverlässigkeit des Teams, die hohe Produktivität, als normal empfunden. Es gibt Organisationen, die streichen dann die Stelle des ScrumMasters. Das ist selten dämlich, denn dann geht das Team kaputt. Habe ich zweimal erlebt. Auch das Team läuft Gefahr, die eigenen Produktivität als normal zu empfinden und hört auf, besser zu werden. Hier muss man gegensteuern. Und dann gibt es doch Momente, in denen was schief läuft. Die ganze Organisation steht Kopf und der neue Chief Executive Business Kasper führt Command & Control ein statt eine Retrospektive zu machen. Das kann ein High Performance Team zerstören, daran kann ein ganzes Unternehmen kaputt gehen. Das habe ich auch erlebt. Leider. 25
  • 26. 26