SlideShare uma empresa Scribd logo
1 de 89
Baixar para ler offline
Kennt jemanden diesen Menschen?
Das ist Peter F Drucker, einer der Päpste der Betriebswirtschaftslehre schlechthin. Er hat uns
erfunden. Wir, das sind nämlich Wissensarbeiter - wir arbeiten mit geistigen Moves, nicht mit
körperlicher Arbeit.
Er hat Worte wie „Wissensarbeiter“ oder „Kernkompetenz“ überhaupt erst erfunden. Und er
hat nicht nur das Wort erfunden, er ist auch massgeblich, wie man mit diesen Sachen
umzugehen hat.
Die wichtigste und wahrlich einzigartige
Leistung des Managements im
20. Jahrhundert bestand darin, die
Produktivät des manuellen Arbeiters in der
Fertigung um das 50fache zu steigern.

Peter Drucker hat folgenden Satz gesagt: ...
Die wichtigste und wahrlich einzigartige
Leistung des Managements im
20. Jahrhundert bestand darin, die
Produktivät des manuellen Arbeiters in der
Fertigung um das 50fache zu steigern.

Automatisierung
Spezialisierung

?

Ist das wirklich passiert?
Ja, ist es - durch die Industrialisierung oder konkreter, durch die Automatisierung. Die
Zerlegung der Arbeit in kleine Schritte, die Fliessbandarbeit, die Spezialisierung und die
Maschinen haben dazu geführt, dass pro Arbeiter heute tatsächlich mehr als das 50fache von
dem produziert wird, was 1900 der Fall war.
Die wichtigste und wahrlich einzigartige
Leistung des Managements im
20. Jahrhundert bestand darin, die
Produktivät des manuellen Arbeiters in der
Fertigung um das 50fache zu steigern.
Die wichtigste Leistung, die das
Management im 21. Jahrhundert erbringen
muss, besteht darin, auf ähnliche Weise die
Produktivität der Wissensarbeit und der
Wissensarbeiter zu steigern.
Das Zitat hat aber eine zweite Hälfte, und die ist für uns, und für unser Jahrhundert.
Den Satz muss man erst mal verdauen. Auf ähnliche Weise, das heisst um Faktor 50. Wir sind
die Wissensarbeiter, der Satz könnte also genauso gut heissen ...
Könnt Ihr Eure
Produktivität
um Faktor 50
steigern?
Aber mal im Ernst - können wir das? In der Industrialisierung haben die das mit den beiden
Tricks Arbeitsteilung und Automatisierung hinbekommen.
Wer glaubt, dass das möglich ist?
Welche Tricks sind das, die zu solchen Steigerungen führen können?
Dann würde
Faktor 25
mehr Gehalt
OK sein, oder?
Stellen wir uns mal vor, ich könnte das heute schon, mit meinem Team. Und wäre Faktor 50
effektiver als die Durchnittsteams da draussen. Dann wäre es in Ordnung, Faktor 25 mehr
Gehalt zu bekommen, oder? Der Auftraggeber würde immer noch nur die Hälfte bezahlen und
damit ein Bombengeschäft machen ...
Kennt jemand diesen Herren? Das ist Jeff Sutherland, einer der Väter von Scrum.
The highest performing (SCRUM) Team
ever recorded was a Borland Team audited

by Bell Labs. They were 50 times faster
than waterfall Team industry average.

Und der hat folgendes gesagt. Das ist echt gemessen, das ist echt untersucht worden. Weder
Borland, noch Bell Labs, noch Jeff Sutherland sind als Amateure oder Lügner verschrien.
The highest performing (SCRUM) Team
ever recorded was a Borland Team audited

by Bell Labs. They were 50 times faster
than waterfall Team industry average.

?

Weder Jeff Sutherland selbst, noch Bell Labs oder Borland sind als Lügner oder Spinner
verschrien. Trotzdem behaupten die das. Mal ehrlich, Hand aufs Herz: Wer von Euch glaubt
das?
The highest performing (SCRUM) Team
ever recorded was a Borland Team audited

by Bell Labs. They were 50 times faster
than waterfall Team industry average.

?

WTF

Als ich das das erste Mal gesehen habe, habe ich gedacht: WTF? Wie kann das zustande
gekommen sein?
Ich habe sogar auf dem CTO-Stammtisch in München eine Umfrage gemacht, wer das für
echt hält - und niemand von ihnen hat das für möglich gehalten.
Das ist eine Motivation für diesen Vortrag. Wie geht das? Was haben die gemacht?
Ich will das auch, wo muss ich anfangen?


50 Times

Faster

Vermutlich liegt der Grund in der Komponente von IT-Systemen, die zu 70% aus Wasser
besteht. Nämlich den biologischen Teilen eines Softwaresystems, also schlicht uns, den
Developern, den Stakeholdern, den Nutzern. Aber was passiert mit der Wetware, dass sie 50
mal produktiver wird?
Warum sind
wir heute nicht
so produktiv?



Drehen wir die Frage doch einmal um. Warum sind wir heute 50 mal weniger produktiv?
Was hindert uns daran, wie das Team bei Borland damals 50 mal produktiver als der
Branchenschnitt zu sein?
"Im Angebot fehlt noch, dass wir den Release
nicht per Puppet deployen.



Das machen wir auf keinen Fall, da schreiben
wir rein, dass es auf jeden Fall wie
gehabt .tar.gz und entpacken bleibt.
Die Fachabteilung nutzt das sonst skrupellos
aus und will gleich alles haben."

Schauen wir uns doch einmal eine typische Situation in unserer Arbeit an. Das ist eine
typische Situation, wie sie bei uns vorkommen könnte. Hier der Kollege, der offensichtlich
schlechte Erfahrungen mit Kunden gemacht hat.
„Du immer mit Deinem Misstrauen.
Selbst wenn die Puppet wollen habe ich Dir
das in 2 Stunden hinkonfiguriert.



Das zahlt sich schon während der
Entwicklung 3 mal aus.“

Und hier der Kollege, der auch schlechte Erfahrungen mit Kunden hat, aber mit
ungebremsten Optimismus weitersegelt.
"Poah, du weisst genau, dass Deine
Schätzungen nie stimmen.



Wenn wir schon SCM machen, dann lieber
Chef, und nicht Puppet".

Entgegnet wird daraufhin das hier. Offensichtlich kennen sich die beiden schon länger, und
kennen die gegenseitigen Vorlieben und Schwächen.
"Im Angebot fehlt noch, dass wir den Release
nicht per Puppet deployen.



„Need for Closure“

Wir steigen direkt ein mit der Diskussion eines Features, das nicht im Angebot ist, dessen
Abwesenheit aber explizit in das Angebot genommen werden soll. Warum will ich das haben?
Weil mir als Mensch Unsicherheiten nicht gefallen, ich möchte lieber die Dinge unter Dach &
Fach haben. Alles sollte so früh wie möglich festgelegt werden, Unsicherheiten möchte ich
gerne vermeiden.


Das machen wir auf keinen Fall, da schreiben
wir rein, dass es auf jeden Fall wie
gehabt .tar.gz und entpacken bleibt.

„Status Quo Bias“

Eine bevorzugte Variante Closure zu erreichen ist einfach - es bleibt so wie es ist. Wir mögen
Dinge, die so bleiben wie sie sind, das finden wir im Default erst mal gut, weil wir damit
Risiko vermeiden. Das heisst „Status Quo Bias“ und hat erst mal nichts mit der Band zu tun.
So wählen wir häufig auch da den gleichen Platz, wo wir freie Platzwahl haben.
„Naïve Cynism“



Die Fachabteilung nutzt das sonst skrupellos
aus und will gleich alles haben."

Das ist naiver Zynismus. Wir neigen dazu, die anderen für Egoisten zu halten. Uns selbst aber
nicht.
„Theory X“
Der Mensch hat eine angeborene Abneigung
gegen Arbeit und versucht ihr aus dem Wege
zu gehen wo irgendwie möglich.



Vielleicht mal ein konkretes Beispiel: Wer kennt McGregors Theory X und Theory Y?
Theory X sagt: der Mensch arbeitet nur, weil er Geld bekommt. Wenn er kein Geld bekommen
würde, würde er nicht arbeiten, und ohne Kontrolle würde er vermutlich die Zeit mit
irgendwas verbringen.
„Theory X“
Der Mensch hat eine angeborene Abneigung
gegen Arbeit und versucht ihr aus dem Wege
zu gehen wo irgendwie möglich.



„Theory Y“

Für den Menschen hat Arbeit einen hohen
Stellenwert und ist wichtige Quelle der
Zufriedenheit, denn er ist von Natur aus
leistungsbereit und von innen motiviert.

Die Theory Y wiederum besagt, dass jeder Mensch gerne arbeitet, und seine Zufriedenheit
daher kommt. Er ist von Natur aus leistungsbereit und arbeitet auch dann effektiv, wenn die
Tür zu ist.
„Theory X“
Der Mensch hat eine angeborene Abneigung
gegen Arbeit und versucht ihr aus dem Wege
zu gehen wo irgendwie möglich.



„Theory Y“

Für den Menschen hat Arbeit einen hohen
Stellenwert und ist wichtige Quelle der
Zufriedenheit, denn er ist von Natur aus
leistungsbereit und von innen motiviert.

Welche Gruppe haltet Ihr für weiter verbreitet? Wer denkt es wäre Theory X? Wer denkt es
wäre Theory Y?
„Theory X“
Der Mensch hat eine angeborene Abneigung
gegen Arbeit und versucht ihr aus dem Wege
zu gehen wo irgendwie möglich.



„Theory Y“

Für den Menschen hat Arbeit einen hohen
Stellenwert und ist wichtige Quelle der
Zufriedenheit, denn er ist von Natur aus
leistungsbereit und von innen motiviert.

Zu welcher Gruppe zählt ihr Euch selbst? Wer ist selbst eher Theory X? Wer ist eher Theory Y?
„Naïve Cynism“
Ganze Management-Strategien
basieren auf dieser
kognitiven Verzerrung.

Im Regelfall sehe ich die anderen als Egoistisch, mich selbst aber nicht. Deshalb kontrolliere
ich, halte es aber für unnötig, selbst in umgekehrter Richtung kontrolliert zu werden.
„Du immer mit Deinem Misstrauen.



„Attribution error“

Situativ versus Verhalten

„Du immer mit Deinem Misstrauen“ - das ist der Attribution Error, wir neigen dazu, die
Standpunkte anderer eher als ihr typisches Verhalten zu sehen, und wenig dem aktuellen
Kontext geschuldet. Für uns selbst gilt das Gegenteil: wir erleben uns als situativ, urteilen
aber faktisch sehr häufig verhaltensbasiert.
Selbst wenn die Puppet wollen habe ich Dir
das in 2 Stunden hinkonfiguriert.



„Planning Fallacy“

Bei einem eigenen Plan neigt man dazu die Zeit die er braucht zu unterschätzen. Wir werden
in dem Moment zu Optimisten und nehmen das beste für uns selbst an. Und, mal ehrlich wem von uns ist das schon passiert? Mir durchaus häufig. Meine pläne gehen immer ganz
erstaunlich schnell, während ich bei denen von den Kollegen immer etwas konservativ bin.


Das zahlt sich schon während der
Entwicklung 3 mal aus.

„Optimism Bias“

Das gilt auch für die Auswirkungen des Plans. Ich erwarte viel mehr Benefit als der Plan
realistischerweise realisieren kann. Wem ist das hier schon passiert?
"Poah, du weisst genau, dass Deine
Schätzungen nie stimmen.



„Illusory superiority“

Noch so eine Macke von unserem Gehirn: wir halten uns zunächst einmal für schlauer als die
anderen. Irgendwie, sagt uns das Bauchgefühl, sind wir vermutlich ein bischen überlegen.
Wer von Euch nutzt ein eigenes Framework? Wer von Euch hat schon selbst einen Shop, ein
CMS etc entwickelt, das nicht auch von vielen anderen genutzt wird?
Dazu kommt meist Post-Purchase-Rationalization: Nachträglich erkläre ich mir die
Entscheidung durch Zeiteinsparung, Einlernaufwand oder Spezialisierungsaufwand.
Wer glaubt, dass er zu
den schlechteren 50%
Autofahrern hier im
Raum gehört?

Schauen wir doch einfach einmal nach. Wer von Euch glaubt, dass er zur schwächeren Hälfte
der Autofahrer hier im Raum gehört, von denen, die einen Führerschein haben?
Lake Wobegon Effekt:
80% der Leute
denken sie wären
überdurchschnittlich.
Statistisch glauben 80% der Leute, sie persönlich wären überdurchschnittlich.


Wenn wir schon SCM machen, dann lieber
Chef, und nicht Puppet".

„Reactance“

Und hier wirds endgültig unsinnig. Reactance ist das Widerstand auf eine einschränkung
meiner Möglichkeiten. Einfach nur weil ich mich einschränkt fühle möchte ich das Gegenteil
von dem tun, was der andere will. Hier haben wir also einen Kollegen der gerade eben noch
gar kein Konfigurationsmanagement wollte, jetzt aber dafür gleich die dickere Lösung.

WTF?

Warum macht unser Gehirn so einen Unsinn? Warum macht es nicht einfach seinen Job und
eine schlaue Lösung? Hey, so kompliziert kann das doch nicht sein. Warum mach das so
einen Unsinn?
Urteilsheuristiken
Die Welt ist kompliziert/komplex,
ich habe nicht die Zeit alles zu verstehen,
ich kann mich nicht um alles kümmern.

Das Hirn macht das aus einem einfachen Grund: es hat nur begrenzt viel Ressourcen, und es
will seine Arbeit trotzdem schaffen. Also werden Heuristiken eingesetzt, die ein schnelles
Urteil erlauben, und das schon irgendwie oft klappt.
Wir haben gar nicht die Wahl, immer rational zu agieren, denn unsere Welt ist komplex. Wir
Softwareentwickler arbeiten zum Beispiel immer mit einem nicht zusammegesetzten Puzzle denn wir können immer nur Teile vom Code sehen, und sind geistig gar nicht in der Lage,
alle Code-Teile gleichzeitig parat zu haben. Sondern wir schauen uns Puzzleteil für Puzzleteil
an, um dann an den Teilen des Puzzles etwas zu korrigieren, wo der Fehler war.
Es ist also gar nicht möglich, immer alle Faktoren zu berücksichtigen.
Urteilsheuristiken
Default

sind der
:
unbewusst, absichtslos,
unwillkürlich und mühelos

Das gemeine: Das ist der Default, das ist das Normalverhalten unseres Hirns. Das machen wir
die ganze Zeit über. Das kontrollierte Denken passiert nur, wenn ein Problem deutlich mehr
Aufmerksamkeit will, erst da werden wir reflektiert und vernünftig.
Wir sind also nur in
Ausnahmesituationen
vernünftig.
Das muss man sich mal verdeutlichen - wir ticken die meiste Zeit auf Basis einfacher
Heuristiken, die weder situation noch rational begründet sind - und nur in
Ausnahmesituationen bemüht sich unser Gehirn überhaupt, vernünftig zu agieren.
Urteilsheuristiken
Aber natürlich
bei jedem anders.

Und, um das ganze noch gemeiner zu machen, verhalten wir uns da natürlich alle anders. Wir
haben alle unsere Erfahrungen, unsere Schwerpunkte, unsere Hirnchemie belohnt andere
Dinge. Wer von Euch läuft, jogged, macht Marathons? Wer auf gar keine Fall? Weil uns die
Hirne unterschiedliche belohnen, und unsere Erfahrunge anders aussieht.
Psychologische
Typen

Wie unterschiedlich das aussehen kann hat dieser schon länger ziemlich tote Mann, Carl
Gustav Jung, in seinen psychologischen Typen mal untersucht. Ich nutze hier die Typisierung
von Myers Briggs, die zwar als völlig pseudowissenschaftlich verschrien ist, aber mir immer
hilft, Dinge zu verstehen.
Introversion

Extroversion
Sensorik: Die machen das über 4 Achsen, bei denen man sich jeweils immer mehr auf der
einen als auf der anderen befindet. Die erste Achse ist Introversion zu Extroversion als
Motivation, Dinge zu erfahren. Die extrovertierten sind vor allem an der Aussenwelt und
breiter interessiert, und wollen neue Informationen. Die Introvertierten mögen eher ruhige
und selbstdenkend, sie bekommen ihren input durch das verfolgen der eigenen Ideen.
Etwa gleichverteilt.
Intuition

Sensing
Die nächste Achse kümmert sich um die Verarbeitung der Sinneseindrücke: Wer Intuitionmässig unterwegs ist verlässt sich auf seinen sechsten Sinn, ob es in sein Gesamtbild passt.
Der sensorische Geist interessiert sich für die Details, und ist eher konkret.
Sensing macht den grösseren Teil aus.
Feeling

Thinking
Nächste Achse Entscheidungsfindung- von Feeling zu Thinking. Der Feeling-Mensch
orientiert sich an seinem persönlichen Wertesystem - an seiner Moral. Er möchte die anderen
mitnehmen und versucht Konsens zu erzeugen. Der Thinker ist der Vulkanier unter den
Persönlichkeitstypen, und eher an richtigen Resultaten interessiert.
Frauen sind deutlich häufiger Feeling-orientiert.
Judging

Perceiving
Hier geht es um Strukturierung: Judging-Typen entscheiden sich gerne früh und bleiben bei
Ihrer Meinung. Sie sind kalkulierbar und verlässlich, der dominiert und kontrolliert gerne. Die
Perceiving-Typen lassen sich gerne Türen offen und sind lange offen für neue Eindrücke und
Änderungen. Etwa gleichverteilt.
Agent J
Extravert

78 %

Sensing

38 %

Feeling

81 %

Judging

11 %

Ich habe mal einfach zwei Kollegen genommen, um die Verhaltensmuster anzugucken. Agent
J ist klar am äusseren interessiert, kümmert sich eher um die Details, hat klare persönliche
moralische Werte und neigt vernachlässigbar mehr zur Planung als zur Adaption. Es ist
auffällig, wie sehr er sich um alle anderen sorgt, und seine Werte sind 100% klar und
verlässlich. Hat jemand eine Ahnung, was er als 17jähriger gemacht hat?
Agent F
Introvert

67 %

Intuition

38 %

Thinking

12 %

Perceiving

33 %

Agent F ist eher der Typ fürs tiefe durchdenken von Themen, er macht die schlauesten
Puppet-Manifeste, ist Haskell-Guru und hat als 16jähriger den ersten Commit in den LinuxKernel gemacht, spricht aber nicht selbst davon. Er verfolgt die Vision vom „richtigen“ System
gerne ausdauernd, ist eher rational unterwegs und hat kein Problem damit seine Meinung zu
ändern.
Introvert

67 %

Extravert

78 %

Intuition

38 %

Sensing

38 %

Thinking

12 %

Feeling

81 %

Perceiving

33 %

Judging

11 %

Technik
richtig

Personen
glücklich

Weil die Schwerpunkte so unterschiedlich sind, gibt es bei den beiden auch Divergenzen. Bei
allen technischen Themen will Agent F natürlich die technisch richtige Lösung. Die ist Agent J
egal - so lange die Leute zufrieden sind. Sobald beide Punkte in Widerspruch stehen sind sie
sich nicht einig. Agent J will den Leuten entgegenkommen, Agent F die technisch konsistente
Lösung liefern.
Introvert

67 %

Extravert

78 %

Intuition

38 %

Sensing

38 %

Thinking

12 %

Feeling

81 %

Perceiving

33 %

Judging

11 %

Meetings
nerven

Meetings
entscheiden

Während Agent F denkt, dass Meetings nur stören und ihn aus der Arbeit holen freut sich
Agent J auf sie, weil für ihn da der wichtigste Teil vom Geschäft passiert - gemeinsamer
Abgleich, Planung, Entscheidungen. Die technischen Aspekte werden immer schlecht
abgebildet, die Konzeptteile währenddessen gut, weil Agent J sich in den Meetings natürlich
bewegt.
Introvert

67 %

Extravert

78 %

Intuition

38 %

Sensing

38 %

Thinking

12 %

Feeling

81 %

Perceiving

33 %

Judging

11 %

Adaptieren!

Planen!

Agent J will planen, er will sich verlassen können und die Details möglichst sauber vorbereitet
haben. Das geht Agent F völlig ab. Er will beginnt einfach und bewegt sich auf sein
Gesamtziel vor, das er schon vor Augen hat.
Agent F ist genervt, weil Agent J so viele Dinge schon im voraus festlegen möchte, Agent J
geht es auf den nerv, dass die Ansagen von F immer vage und unverlässlich sind.
Wir werden von
gegensätzlichen
Heuristiken gesteuert.
Fazit also: wir werden sogar von sich widersprechenden Heuristiken gesteuert. Das eine
Gehirn wird für Objektivität belohnt, das zweite für Emotionalität. Das eine für das Festhalten
an einem Plan, das zweite für Adaptionsfähigkeit.
 
Kann man alleine
agil arbeiten?
Mal eine Frage in die Runde: Kann man alleine agil arbeiten?
Nein, kann man nicht, nur einige wenige agile Praktiken - wie TDD oder Continuous
Integration - lassen sich überhaupt alleine anwenden. Agiles Arbeiten ist das aber noch nicht.
Warum wollen die agilen Jungs, dass man in einem Team arbeitet, und nicht alleine?
Anforderungen
unvorhersagbar

Chaotisch

Ko
m

pl

Anforderungen
vorhersagbar

i

Einfach
Lösung
vorhersagbar

Komplex

zi
er
t
Lösung
unvorhersagbar

Das hängt mit unserer Sorte Probleme zusammen. Das hier ist das Stacey-Diagramm, und mit
ihm lassen sich Problemwelten beschreiben. Die X-Achse sind die Anforderungen, wie weit
sind die vorhersagbar? Die Y-Achse wiederum beschreibt die Lösungen, wie weit diese
vorhersagbar sind. Je nachdem, wo sich unsere Aufgaben hier verteilen haben wir es mit
einfachen, komplizierten, komplexen oder chaotischen Welten zu tun.
Anforderungen
unvorhersagbar

Chaotisch

Ko
m

pl

Anforderungen
vorhersagbar

i

Einfach
Lösung
vorhersagbar

Komplex

zi
er
t
Lösung
unvorhersagbar

Unsere Probleme befinden sich im Webdevelopmentbereich meist hier, sprich: sie sind mit
etwas glück nur kompliziert, im Regelfall aber komplex. Und komplex heisst, dass wir das
alleine nicht lösen können.
Anforderungen
unvorhersagbar

Chaotisch

Ko
m

pl

Anforderungen
vorhersagbar

i



Einfach
Lösung
vorhersagbar


Komplex

zi
er
t

Lösung
unvorhersagbar

Einfach können wir alleine, kompliziert manchmal, komplex nicht. Da sind zu viele
Abhängigkeiten, Schleifen, unbekannte Kausalketten etc, als dass ich als Einzelkämpfer
wirklich gut vorankommen könnte.
Möglichst großes
mentales Modell des Systems:



• Zusammenhänge erkennen
• Veränderungen wahrnehmen
• Chancen erkennen
• Risiken erkennen
Konkret arbeite ich mit einem mentalen Modell des Systems. Ich habe meine eigenen Bilder
über die Strukturen, die Zusammenhänge des Systems - und die brauche ich, um überhaupt
agieren zu können, weil ich zum Beispiel eine neue Komponente entwickle.
Aber nicht nur bei allen planerischen Tätigkeiten brauche ich das - ich brauche es auch um
dazulerne zu können. Im Stacey-Diagram sind viele Dinge unbekannt, und genau diese
Unbekannten muss ich in Wissen überführen - und das bedeutet die Veränderungen
wahrzunehmen und die Zusammenhänge zu verstehen.

Um so größer das
gemeinsame Mental Model ist,
um so effektiver
ist die Zusammenarbeit.
Die Armee von Singapur hat sich mal angeschaut, wie sich diese Mentalen Modelle auf
Teamarbeit auswirken. Sie haben die Übereinstimmung der Mental Models gemessen, und
dann die Teams auf Missionen mit komplizierten Aufgaben geschickt.
Und tatsächlich sind die Teams deutlich effektiver, wenn sie ein gemeinsames Mental Model
haben, also von den gleichen Bildern reden und gemeinsam Wissen erarbeiten können.

Frontend
Backend

Und genau deshalb gibt es cross-funktionale Teams, die eben nicht nach Frontend und
Backend getrennt sind, sondern gemeinsam arbeiten. Durch die direkte Zusammenarbeit
überschneiden sich die mentalen Modelle stark, und das Team wird effizienter.
Ihr kennt vermutlich die Konkurrenz zwischen den Frontend- und Backend-Leuten, oder? Wer
ist Backend-Mensch, wer ist Frontend-Mensch? Der Punkt ist: die Zusammenarbeit ist nur
dann effektiv, wenn man ein grosses gemeinsames Modell der Realität hat, allem
Spezialwissen zum trotz. Deshalb machen Firmen Feature-Teams, oder Firmen wie Facebook
Bootcamps - um von Anfang an, und auch später, ein gemeinsames Mentales Modell zu
haben.

Brauchen wir denn
überhaupt noch Spezialisten?
Wenn das am effizientesten ist, dann stellt sich natürlich die Frage: brauchen wir überhaupt
noch Spezialisten? Wäre es nicht am besten, wenn man gleiche Leute mit gleichen Fähigkeiten
und den gleichen mentalen Modellen hätten?
Anforderungen
unvorhersagbar

Chaotisch

JA!
Ko
m

pl

Anforderungen
vorhersagbar

i

Einfach
Lösung
vorhersagbar

Komplex

zi
er
t

Lösung
unvorhersagbar

Ja, natürlich brauchen wir die. Denn wir sind ja gar nicht mehr in der Lage, alles zu sehen, zu
verstehen und zu machen. Und wenn alle gleich wären, würden sie alle gleich wenig bewirken
können.

Komplementäre Fähigkeiten
Gemeinsames mentales Modell
Wir sind also genau dann effektiv, wenn wir komplementäre Fähigkeiten haben, aber
möglichst viel gemeinsames mentales Modell. Wenn wir einen möglichst breiten Bereich an
Aufgaben mit Skills abdecken, aber gleichzeitig auf einer gemeinsamen Basis stehen.

Widerspruch?!
Komplementäre Fähigkeiten
Gemeinsames mentales Modell
Das klingt erst mal wie ein Widerspruch, ist aber eigentlich eher eine Frage der
Zusammenarbeit und der Kommunikation. Das gemeinsame Modell ist nicht die Schnittmenge
der Fähigkeiten, sondern die gleichen Worte und die gleichen Bilder. Ich kann mit jemanden
mit ähnlichen Skills völlig divergente Bilder haben, die eine Zusammenarbeit unmöglich
machen. Und ich kann mit jemandem mit völlig anderen Skills trotzdem schnell zu einer
guten gemeinsamen Lösung kommen. Kennt das jemand aus der Praxis?
Introvert

67 %

Extravert

78 %

Intuition

38 %

Sensing

38 %

Thinking

12 %

Feeling

81 %

Perceiving

33 %

Judging

11 %

Komplementäre Fähigkeiten
Gemeinsames mentales Modell
Kommen wir doch mal zurück auf unsere beiden Agenten. Was fällt Euch hier auf? Exakt, die
sind komplementär. Der eine ist gut in technischem Gesamtbild und Adaption, der zweite in
Sorgfalt und dem Umgang mit Menschen. Die komplementären Fähigkeiten sind also nicht
nur eine Frage der fachlichen Skills, sondern auch der Urteilsheuristiken. Und wir brauchen
beides, um unsere Welt beurteilen zu können.
Introvert

67 %

Extravert

78 %

Intuition

38 %

Sensing

38 %

Thinking

12 %

Feeling

81 %

Perceiving

33 %

Judging

11 %

Gegensätzliche Verhaltensmuster
sind eine Stärke!
Und es ist in Wahrheit ein Vorteil, wenn man dort divergent ist. Wer von Euch hat Leute im
Team, bei denen er permanent im Klinch liegt, weil sie einfach anders denken?
Genau das sind Eure komplementären Mitspieler, zusammen mit ihnen habt ihr die größte
Effektivität - _wenn_ die mentalen Modelle nahe beeinander sind. Und wenn man eine
Methode gefunden hat, die beide Perspektiven mit einbringen.
Forming
Storming
Norming
Performing
Tuckman Model
Das Modell kennt ihr vermutlich schon - das wurde schon 1965 von Bruce Tuckmann
entwickelt. Bei Forming findet das Team sich als Gruppe zusammen, es gibt nicht nur kein
gemeinsames Modell, man hat noch nicht mal Ahnung davon, was die anderen gut können.
Bei Storming findet man das heraus, man Benchmarkts Skills, Vorlieben und
Entscheidungsstratetegien. Bei Norming kommen wir endlich zum gleichen Modell der
Realität, das aber noch nicht gross sein muss, es reicht aber zum Zusammenarbeiten.
Forming
Storming
Norming
Performing
Tuckman Model
Nur ein paar Teams kommen aus dem Norming-Status heraus und landen tatsächlich in
Performing. Das sind genau die Teams, bei denen es ein grosses gemeinsames Mental Model
gibt. Aber was heisst das konkret?
Tuckman Model
Spannend wird das ganze tatsächlich, wenn man es in Performance anschaut, wie es der Herr
Katzenbach getan hat. Beginnen wir mit einer einfachen Arbeitsgruppe, dann sind wir so
performant wie die Summe der Leute. Jeder macht seinen Teil, auf Basis seines mentalen
Modells, im Rahmen seines Teilwissens und seiner kognitiven Ausrichtung. Beim Storming
geht es runter, weil man Stärken und Schwächen nicht kennt, und die Machtverhältnisse noch
nicht klar sind. Erst mit einem shared Goal gibt es wieder Performance, und als richtiges
Teams, das eingespielt ist ist man dann auch wieder performanter als die Gruppe von Leuten.
High Performance Teams wiederum, mit einem grossen komplementären Fähigkeitenset,
guten Teammechanismen und einem gemeinsamen Modell liegen Faktoren darüber.
e
p

o
N

Hyperperformance =

gemeinsames mentales Modell
+
komplementäre Skills?

Reicht es also aus, wenn ich ein gemeinsames Modell habe und komplementäre Skills? Bin ich
dann schon hyperperformant? Reicht das? Kommt mir irgendwie komisch vor.
Aufgaben
und Fähigkeiten
zusammenbringen.
Das wäre ja auch zu einfach gewesen. Was hier noch fehlt ist klar: die Leute müssen nicht nur
die Fähigkeiten haben, etwas zu lösen, sie müssen es auch tun. Und hier wird es gemein. Es
ist uns selbst in Wahrheit unklar, was wir können und was wir nicht können.
Wie immer hat der Pointy Haired Boss nicht recht, und es ist oft gar nicht das, was man mag
oder denkt.
Introvert

67 %

Intuition

38 %

Thinking

12 %

Perceiving

33 %

Scrum Master?
Eine Geschichte aus unserer Praxis ist ein Scrum-Master, der bei einem ähnlichen Profil wie
Agent F herauskommt. Er wollte gerne Scrum-Master werden, weil ihm das als logischer
Karriereschritt vorkam. Die Kollegen fanden das auch gut, weil er als Entwickler als Senior
akzeptiert war, und man sein Wissen und seine Professionalität schätzte. Und weil er auch
noch verantwortungsvoll war, fand das auch die Unternehmensleitung, also unter anderem
ich, gut. Und jetzte ratet mal: ist das gut gegangen? (Agent F würde btw. nicht von selbst auf
die Idee kommen :-) )
Extravert

78 %

Sensing

38 %

Feeling

81 %

Judging

11 %

Scrum Master?
Und was meint ihr zu Agent J? Sollte der Scrum-Master werden?
Wenn es nach mir geht: Extravert: check, sensing: check, feeling: check, Judging: check.
Er sorgt sich um die einhaltung von Planung, er kümmert sich um die Details, und, am
wichtigsten: er redet mit den Leuten und weiss, was Phase ist. Kann sich trotzdem jemand
vorstellen, wo es Probleme geben kann? Ich persönlich würde davon ausgehen, dass objektive
Team-Performance nicht so seine Sache ist, denn er ist deutlich im Feeling-Bereich, und auch
Adaption wird anderen einfacher fallen als ihm.
With
 A
 
Little
 Help
 
From
 My
 Friends.

Extravert

78 %

Sensing

38 %

Feeling

81 %

Judging

11 %

Scrum Master?
Also doch ein schlechter Scrum-Master? Nein, er ist schliesslich teil eines Teams, er muss
sich die fehlende Teile einfach von den Kollegen holen, und mit denen Kooperieren, zB mit
einem mit Dominanz auf Thinking. Beim realen Agenten J ist das btw. garantiert kein
Problem.
 
Es kommt auf die
angewandten Fähigkeiten
des Teams an, nicht auf die
individuellen Fähigkeiten.
Und genau das ist der Punkt. Entscheidend ist, was das Team, nicht was das Individuum
liefert. Entscheidend ist, was das Team versteht, nicht was das Individuum versteht. In der
Psychologie ist das Transactional Knowledge, also das angewandte Wissen.
Noch mal zum mitschreiben: Die individuelle Fähigkeit ist egal. Es zählt nur, was vom
gesamten Team auf die Strasse gebracht wird.
Team-Fähigkeiten

Individuelle
 Fähigkeiten

Tuckman Model
Und zwar genau deshalb. Wenn jemand sich selbst in den Vordergrund stellt, und es ihm / ihr
um seine eigenen Fähigkeiten geht, hat er in einer komplexen Welt ein Problem - denn er
kann immer nur unten links landen. Wer wiederum versucht Teil eines Teams zu sein kann er
deutlich performanter sein - nur dass die Performance dann wieder nicht klar individuell
zuzuordnen ist.
The highest performing (SCRUM) Team
ever recorded was a Borland Team audited

by Bell Labs. They were 50 times faster
than waterfall Team industry average.

Der Punkt ist aber - genau da oben rechts in der Ecke wohnen die Hyperperformanten Teams.
Die Frage ist natürlich, warum findet das ausgerechnet in unserer Branche statt, und nicht
woanders?
Die wichtigste Leistung, die das
Management im 21. Jahrhundert erbringen
muss, besteht darin, auf ähnliche Weise die
Produktivität der Wissensarbeit und der
Wissensarbeiter zu steigern.

Automatisierung
Teams für Komplexität

?

Und wie machen wir das?
Die Antwort ist ganz einfach: wir sind die Maschinenbauer des Informationszeitalter.
Die Industrialisierung hat über Maschinen die manuelle Arbeit automatisiert, wir
automatisieren über Software die Wissensarbeit. Damals war der Preis dafür die
Spezialisierung, heute ist der Preis die Komplexität - und Komplexität ist etwas, mit dem
Individuen nicht umgehen können, sehr wohl aber Teams mit kontinuierlicher Verbesserung
und Adaption.


„Ok, aber jetzt mal in Echt,
bekomm ich das auch?
Oder ist das nur Theorie-Blah?“
Die eigentliche Frage für uns ist aber nicht, ob Peter Drucker am Ende des Tages Recht hatte,
sondern ob es daraus für uns was zu schlussfolgern gibt. Wir wissen jetzt, dass wir
komplementäre Kompetenzen, möglichst viel gemeinsames mentales Modell und die
bewusste Ausnutzung der Teamfähigkeiten benötigt wird. Wie komme ich dahin?

Zunächst einmal: wo steht mein Team gerade? Das Buch Tribal Leadership von den Herr
Logan und King und Frau Fischer-Wright hat das in mehrere Levels verteilt, und diese
beschreiben gut, wie es sich anfühlt, in einem Team diesen Levels zu arbeiten.
Der erste Level sind die Leute feindlich eingestellt, alles wird als unfair wahrgenommen, die
Gesamtsituation ist doof. Beim zweiten Level ist man auf einem „ich kenne das schon und
habe es scheitern sehen“, Sarkasmus dominiert.
Beim dritten Level, der am meisten verbreitet ist, treibt das Ego voran - man gewinnt
individuell, und kommt individuell weiter. Man würde viel mehr leisten, wenn die anderen nur
auch so mitziehen würden.Level 4 ist endlich ein echtes Team. Ich bin nicht besser als meine
Kollegen, sie sind nicht besser als ich. Wir gewinnen zusammen, und mein Team ist besser
als andere Teams. Level 5 ist der Idealzustand: Es geht uns nicht mehr um Konkurrenz,
sondern darum, etwas zu bewegen. Wir machen etwas, was wirklich etwas bewegt, und
Konkurrenz wird als „Hey, geil, mit denen zusammen können wir noch mehr erreichen“
You
 
are
 
here.



Darf ich mal fragen, wer von Euch auf dem Level „Personal Domination“ steht? Statistisch
sollten jetzt 50% der Hände nach oben gehen, dank Illusiory Superiority werden es vermutlich
ein paar weniger sein.
Aber wie kommen wir auf den nächsten Level?

Become a Better Team
Wie komme ich einen Level höher? Wie werde ich ein besseres Team?


1. die kognitiven Verzerrungen erkennen
2. sie als Chancen nutzen

3. ein gemeinsames Bild formen,
Selbstbild===Fremdbild

Become a Better Team
Erster Schritt:
Die Verhaltensmuster der anderen verstehen und als Chance nutzen. Wenn ich wie Agent J
und Agend F am Anfang den anderen nicht verstehe, und deshalb in eine persönliche
Konkurrenz gehe, kann ich nicht über Level 3 - Lone Warrior - hinauskommen, wie es in den
meisten Teams auch so passiert. Damit ich in den „We‘re great“-Modus komme muss ich sie
auf Augenhöhe wahrnehmen, und dazu brauche ich ein gemeinsames Bild, das ihre Vorteile
deutlich macht.


Tools: Moving Motivators

http://www.happymelly.com/an-easy-way-to-talk-about-serious-things/

Become a Better Team
Ein schönes Tool dazu sind die Moving Motivators von Happy Melly / Jurgen Appelo von
Management 3.0 - da findet man, analog zu den Myers-Briggs-Bögen, heraus, was den
Kollegen wichtig ist und welche Prios sie haben. Daraus muss ich keine Schlüsse ziehen, aber
ich habe ein gemeinsames Wissen, auf dem ich arbeiten kann. Wenn jemand Mastery
fokussiert, dann weiss ich, wen ich für komplizierte Tasks einsetze. Wenn jemand Ordnung
braucht, dann sollte er Prozesse maintainen oder Themen wie Qualität, Refactoring oder
Wartung angehen. Jemand der von Ehre motiviert sind sollte die Erfolge des Teams im Review
zeigen. etc.
Tools: Pairing
Pair Programming

http://www.flickr.com/photos/rafaelmob/

Pair „Working“ mit Nondevs
Mob „Programming“

Pair Programming Matrix
Noch ein Tool, das gut wirkt ist Pairing, oder, noch besser mit noch mehr Leuten. Wer macht
hier alles Pair Programming? Wer nur im eigenen Team?
Ich habe es selbst schon in der Praxis gesehen, wer noch Front/Backend oder Development/
Grafik-Trennung hat: macht Pair Programming - oder eben auch Pair Design.
Noch neuer ist Mob Programming, wo wirklich alle - inklusive des Kunden - bei einer
Programmiersession sind. Das ist ein perfekter Weg, um ein gemeinsames Mentales Modell
zu bekommen.


Tools: Peer Review

Fokus: die angewandten
Fähigkeiten im Team
Das nächste wichtige Tool ist Peer Review. Peer Review heisst: meine Kollegen bewerten mich,
und zwar diejenigen, die mich meiner Ansicht nach am besten beurteilen können.
Und im Fokus stehen weder Fähigkeiten technischer noch Sozialer Natur, sondern die
Teilhabe an den angewandten Fähigkeiten im Team. Bei uns gibt es einen Bogen dazu, der
nur darauf abzielt, wie jemand im Team wirkt. In der Praxis ist es ja auch egal, was jemand
könnte - entscheidend ist, wie er tatsächlich wirkt.

Mais conteúdo relacionado

Mais procurados

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 NotizenGerrit Beine
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?Johann-Peter Hartmann
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer SchuldFrank Düsterbeck
 
Meine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen TeamsMeine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen TeamsFrank Düsterbeck
 
Software-Entwicklung Im Team
Software-Entwicklung Im TeamSoftware-Entwicklung Im Team
Software-Entwicklung Im TeamStephan Schmidt
 
Mythos High Performance Teams
Mythos High Performance TeamsMythos High Performance Teams
Mythos High Performance Teamsadesso AG
 
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen solltenStephan Schmidt
 
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen solltenStephan Schmidt
 
Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"
Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"
Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"Online Erfolg Expert / VAMC GmbH
 
Alles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenAlles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenTechDivision GmbH
 
Pecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolPecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolStefan ROOCK
 
Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Frank Düsterbeck
 

Mais procurados (20)

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
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer Schuld
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Meine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen TeamsMeine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen Teams
 
Portfolio Kanban
Portfolio KanbanPortfolio Kanban
Portfolio Kanban
 
Software-Entwicklung Im Team
Software-Entwicklung Im TeamSoftware-Entwicklung Im Team
Software-Entwicklung Im Team
 
Mythos High Performance Teams
Mythos High Performance TeamsMythos High Performance Teams
Mythos High Performance Teams
 
Planlos mit Plan
Planlos mit PlanPlanlos mit Plan
Planlos mit Plan
 
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
 
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
 
Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"
Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"
Effektives E-Mail Management | Tutorial MS Outlook "QuickSteps"
 
Alles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenAlles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 Minuten
 
Pecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolPecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in Cool
 
Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?Hurra wir werden agil - aber wie?
Hurra wir werden agil - aber wie?
 
Agil ist nicht genug
Agil ist nicht genugAgil ist nicht genug
Agil ist nicht genug
 

Destaque

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 herumkommtJohann-Peter Hartmann
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererTobias Schlüter
 
Humble inquiry the gentle art of asking instead of telling (1)
Humble inquiry the gentle art of asking instead of telling (1)Humble inquiry the gentle art of asking instead of telling (1)
Humble inquiry the gentle art of asking instead of telling (1)Anil GROVER
 
New Lean-Agile Coach Self-Assessment - detailed descriptions v3
New Lean-Agile Coach Self-Assessment - detailed descriptions v3New Lean-Agile Coach Self-Assessment - detailed descriptions v3
New Lean-Agile Coach Self-Assessment - detailed descriptions v3Luca Minudel
 
KNJohnson: The Art of Asking Questions
KNJohnson: The Art of Asking QuestionsKNJohnson: The Art of Asking Questions
KNJohnson: The Art of Asking QuestionsKaren N. Johnson
 
the art of creativity: asking provocative questions
the art of creativity: asking provocative questionsthe art of creativity: asking provocative questions
the art of creativity: asking provocative questionsJoyce Hostyn
 
Transform the employee experience
Transform the employee experienceTransform the employee experience
Transform the employee experienceJoyce Hostyn
 

Destaque (10)

DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Agiles Schätzen - AgileUG Unterfranken
Agiles Schätzen - AgileUG UnterfrankenAgiles Schätzen - AgileUG Unterfranken
Agiles Schätzen - AgileUG Unterfranken
 
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
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
Humble inquiry the gentle art of asking instead of telling (1)
Humble inquiry the gentle art of asking instead of telling (1)Humble inquiry the gentle art of asking instead of telling (1)
Humble inquiry the gentle art of asking instead of telling (1)
 
New Lean-Agile Coach Self-Assessment - detailed descriptions v3
New Lean-Agile Coach Self-Assessment - detailed descriptions v3New Lean-Agile Coach Self-Assessment - detailed descriptions v3
New Lean-Agile Coach Self-Assessment - detailed descriptions v3
 
KNJohnson: The Art of Asking Questions
KNJohnson: The Art of Asking QuestionsKNJohnson: The Art of Asking Questions
KNJohnson: The Art of Asking Questions
 
the art of creativity: asking provocative questions
the art of creativity: asking provocative questionsthe art of creativity: asking provocative questions
the art of creativity: asking provocative questions
 
Transform the employee experience
Transform the employee experienceTransform the employee experience
Transform the employee experience
 
Helping
HelpingHelping
Helping
 

Semelhante a 50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwickler will

Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftMayflower GmbH
 
7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der Zukunft7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der ZukunftHenrik Zaborowski
 
Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in BewegungBjörn Schotte
 
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]Markus Harrer
 
AYCON Festschrift - 2-te Auflage 2021
AYCON Festschrift - 2-te Auflage 2021AYCON Festschrift - 2-te Auflage 2021
AYCON Festschrift - 2-te Auflage 2021AYCON e.K.
 
Die Macht der Innensicht
Die Macht der InnensichtDie Macht der Innensicht
Die Macht der InnensichtSimon Heereman
 
Umsetzen, testen, lernen - Produktentwicklung und Prototyping
Umsetzen, testen, lernen - Produktentwicklung und PrototypingUmsetzen, testen, lernen - Produktentwicklung und Prototyping
Umsetzen, testen, lernen - Produktentwicklung und PrototypingRainer Gibbert
 
Denkraum-Führung - Herstellen von Balance zwischen Geben und Nehmen
Denkraum-Führung - Herstellen von Balance zwischen Geben und NehmenDenkraum-Führung - Herstellen von Balance zwischen Geben und Nehmen
Denkraum-Führung - Herstellen von Balance zwischen Geben und NehmenConny Dethloff
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenJohann-Peter Hartmann
 
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-LockdownDer 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-LockdownTechDivision GmbH
 
ERP Wunderland christian h. leeb
ERP Wunderland  christian h. leebERP Wunderland  christian h. leeb
ERP Wunderland christian h. leebChris H. Leeb
 
Newsletter 8 - Lego statt Ego
Newsletter 8 - Lego statt EgoNewsletter 8 - Lego statt Ego
Newsletter 8 - Lego statt Egoemotion banking
 
UX-Methoden im Projektmanagement
UX-Methoden im ProjektmanagementUX-Methoden im Projektmanagement
UX-Methoden im ProjektmanagementUwe Thimel
 
Der Frechmut - Spirit im Personalmarketing
Der Frechmut - Spirit im PersonalmarketingDer Frechmut - Spirit im Personalmarketing
Der Frechmut - Spirit im PersonalmarketingJörg Buckmann
 
Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Roman Rackwitz
 
Wie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kannWie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kannBjörn Schotte
 

Semelhante a 50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwickler will (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?
 
7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der Zukunft7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der Zukunft
 
Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in Bewegung
 
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
 
AYCON Festschrift - 2-te Auflage 2021
AYCON Festschrift - 2-te Auflage 2021AYCON Festschrift - 2-te Auflage 2021
AYCON Festschrift - 2-te Auflage 2021
 
Die Macht der Innensicht
Die Macht der InnensichtDie Macht der Innensicht
Die Macht der Innensicht
 
Umsetzen, testen, lernen - Produktentwicklung und Prototyping
Umsetzen, testen, lernen - Produktentwicklung und PrototypingUmsetzen, testen, lernen - Produktentwicklung und Prototyping
Umsetzen, testen, lernen - Produktentwicklung und Prototyping
 
Denkraum-Führung - Herstellen von Balance zwischen Geben und Nehmen
Denkraum-Führung - Herstellen von Balance zwischen Geben und NehmenDenkraum-Führung - Herstellen von Balance zwischen Geben und Nehmen
Denkraum-Führung - Herstellen von Balance zwischen Geben und Nehmen
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
 
Zeitmanagement
ZeitmanagementZeitmanagement
Zeitmanagement
 
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-LockdownDer 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
 
ERP Wunderland christian h. leeb
ERP Wunderland  christian h. leebERP Wunderland  christian h. leeb
ERP Wunderland christian h. leeb
 
Newsletter 8 - Lego statt Ego
Newsletter 8 - Lego statt EgoNewsletter 8 - Lego statt Ego
Newsletter 8 - Lego statt Ego
 
UX-Methoden im Projektmanagement
UX-Methoden im ProjektmanagementUX-Methoden im Projektmanagement
UX-Methoden im Projektmanagement
 
Der Frechmut - Spirit im Personalmarketing
Der Frechmut - Spirit im PersonalmarketingDer Frechmut - Spirit im Personalmarketing
Der Frechmut - Spirit im Personalmarketing
 
Agile resource managment_AAC2019
Agile resource managment_AAC2019Agile resource managment_AAC2019
Agile resource managment_AAC2019
 
Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)
 
Wie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kannWie ein kleiner Product Owner Grossartiges bewirken kann
Wie ein kleiner Product Owner Grossartiges bewirken kann
 

Mais de Mayflower GmbH

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mayflower GmbH
 
JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: SecurityMayflower GmbH
 
Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientMayflower GmbH
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingMayflower GmbH
 
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyMayflower GmbH
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming MythbustersMayflower GmbH
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im GlückMayflower GmbH
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefernMayflower GmbH
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsMayflower GmbH
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalierenMayflower GmbH
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastMayflower GmbH
 
Mongo DB - Segen oder Fluch
Mongo DB - Segen oder FluchMongo DB - Segen oder Fluch
Mongo DB - Segen oder FluchMayflower GmbH
 
Test-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPCTest-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPCMayflower GmbH
 
PHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit ComposerPHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit ComposerMayflower GmbH
 

Mais de Mayflower GmbH (20)

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
 
Why and what is go
Why and what is goWhy and what is go
Why and what is go
 
JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: Security
 
Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native Client
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debugging
 
Usability im web
Usability im webUsability im web
Usability im web
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
Responsive Webdesign
Responsive WebdesignResponsive Webdesign
Responsive Webdesign
 
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming Mythbusters
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im Glück
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 Sprints
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalieren
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce Breakfast
 
Mongo DB - Segen oder Fluch
Mongo DB - Segen oder FluchMongo DB - Segen oder Fluch
Mongo DB - Segen oder Fluch
 
Schnelle Geschäfte
Schnelle GeschäfteSchnelle Geschäfte
Schnelle Geschäfte
 
Test-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPCTest-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPC
 
PHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit ComposerPHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit Composer
 

50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwickler will

  • 1. Kennt jemanden diesen Menschen? Das ist Peter F Drucker, einer der Päpste der Betriebswirtschaftslehre schlechthin. Er hat uns erfunden. Wir, das sind nämlich Wissensarbeiter - wir arbeiten mit geistigen Moves, nicht mit körperlicher Arbeit. Er hat Worte wie „Wissensarbeiter“ oder „Kernkompetenz“ überhaupt erst erfunden. Und er hat nicht nur das Wort erfunden, er ist auch massgeblich, wie man mit diesen Sachen umzugehen hat.
  • 2. Die wichtigste und wahrlich einzigartige Leistung des Managements im 20. Jahrhundert bestand darin, die Produktivät des manuellen Arbeiters in der Fertigung um das 50fache zu steigern. Peter Drucker hat folgenden Satz gesagt: ...
  • 3. Die wichtigste und wahrlich einzigartige Leistung des Managements im 20. Jahrhundert bestand darin, die Produktivät des manuellen Arbeiters in der Fertigung um das 50fache zu steigern. Automatisierung Spezialisierung ? Ist das wirklich passiert? Ja, ist es - durch die Industrialisierung oder konkreter, durch die Automatisierung. Die Zerlegung der Arbeit in kleine Schritte, die Fliessbandarbeit, die Spezialisierung und die Maschinen haben dazu geführt, dass pro Arbeiter heute tatsächlich mehr als das 50fache von dem produziert wird, was 1900 der Fall war.
  • 4. Die wichtigste und wahrlich einzigartige Leistung des Managements im 20. Jahrhundert bestand darin, die Produktivät des manuellen Arbeiters in der Fertigung um das 50fache zu steigern. Die wichtigste Leistung, die das Management im 21. Jahrhundert erbringen muss, besteht darin, auf ähnliche Weise die Produktivität der Wissensarbeit und der Wissensarbeiter zu steigern. Das Zitat hat aber eine zweite Hälfte, und die ist für uns, und für unser Jahrhundert. Den Satz muss man erst mal verdauen. Auf ähnliche Weise, das heisst um Faktor 50. Wir sind die Wissensarbeiter, der Satz könnte also genauso gut heissen ...
  • 5. Könnt Ihr Eure Produktivität um Faktor 50 steigern? Aber mal im Ernst - können wir das? In der Industrialisierung haben die das mit den beiden Tricks Arbeitsteilung und Automatisierung hinbekommen. Wer glaubt, dass das möglich ist? Welche Tricks sind das, die zu solchen Steigerungen führen können?
  • 6. Dann würde Faktor 25 mehr Gehalt OK sein, oder? Stellen wir uns mal vor, ich könnte das heute schon, mit meinem Team. Und wäre Faktor 50 effektiver als die Durchnittsteams da draussen. Dann wäre es in Ordnung, Faktor 25 mehr Gehalt zu bekommen, oder? Der Auftraggeber würde immer noch nur die Hälfte bezahlen und damit ein Bombengeschäft machen ...
  • 7. Kennt jemand diesen Herren? Das ist Jeff Sutherland, einer der Väter von Scrum.
  • 8. The highest performing (SCRUM) Team ever recorded was a Borland Team audited by Bell Labs. They were 50 times faster than waterfall Team industry average. Und der hat folgendes gesagt. Das ist echt gemessen, das ist echt untersucht worden. Weder Borland, noch Bell Labs, noch Jeff Sutherland sind als Amateure oder Lügner verschrien.
  • 9. The highest performing (SCRUM) Team ever recorded was a Borland Team audited by Bell Labs. They were 50 times faster than waterfall Team industry average. ? Weder Jeff Sutherland selbst, noch Bell Labs oder Borland sind als Lügner oder Spinner verschrien. Trotzdem behaupten die das. Mal ehrlich, Hand aufs Herz: Wer von Euch glaubt das?
  • 10. The highest performing (SCRUM) Team ever recorded was a Borland Team audited by Bell Labs. They were 50 times faster than waterfall Team industry average. ? WTF Als ich das das erste Mal gesehen habe, habe ich gedacht: WTF? Wie kann das zustande gekommen sein? Ich habe sogar auf dem CTO-Stammtisch in München eine Umfrage gemacht, wer das für echt hält - und niemand von ihnen hat das für möglich gehalten. Das ist eine Motivation für diesen Vortrag. Wie geht das? Was haben die gemacht? Ich will das auch, wo muss ich anfangen?
  • 11.   50 Times Faster Vermutlich liegt der Grund in der Komponente von IT-Systemen, die zu 70% aus Wasser besteht. Nämlich den biologischen Teilen eines Softwaresystems, also schlicht uns, den Developern, den Stakeholdern, den Nutzern. Aber was passiert mit der Wetware, dass sie 50 mal produktiver wird?
  • 12. Warum sind wir heute nicht so produktiv?  Drehen wir die Frage doch einmal um. Warum sind wir heute 50 mal weniger produktiv? Was hindert uns daran, wie das Team bei Borland damals 50 mal produktiver als der Branchenschnitt zu sein?
  • 13. "Im Angebot fehlt noch, dass wir den Release nicht per Puppet deployen.  Das machen wir auf keinen Fall, da schreiben wir rein, dass es auf jeden Fall wie gehabt .tar.gz und entpacken bleibt. Die Fachabteilung nutzt das sonst skrupellos aus und will gleich alles haben." Schauen wir uns doch einmal eine typische Situation in unserer Arbeit an. Das ist eine typische Situation, wie sie bei uns vorkommen könnte. Hier der Kollege, der offensichtlich schlechte Erfahrungen mit Kunden gemacht hat.
  • 14. „Du immer mit Deinem Misstrauen. Selbst wenn die Puppet wollen habe ich Dir das in 2 Stunden hinkonfiguriert.  Das zahlt sich schon während der Entwicklung 3 mal aus.“ Und hier der Kollege, der auch schlechte Erfahrungen mit Kunden hat, aber mit ungebremsten Optimismus weitersegelt.
  • 15. "Poah, du weisst genau, dass Deine Schätzungen nie stimmen.  Wenn wir schon SCM machen, dann lieber Chef, und nicht Puppet". Entgegnet wird daraufhin das hier. Offensichtlich kennen sich die beiden schon länger, und kennen die gegenseitigen Vorlieben und Schwächen.
  • 16. "Im Angebot fehlt noch, dass wir den Release nicht per Puppet deployen.  „Need for Closure“ Wir steigen direkt ein mit der Diskussion eines Features, das nicht im Angebot ist, dessen Abwesenheit aber explizit in das Angebot genommen werden soll. Warum will ich das haben? Weil mir als Mensch Unsicherheiten nicht gefallen, ich möchte lieber die Dinge unter Dach & Fach haben. Alles sollte so früh wie möglich festgelegt werden, Unsicherheiten möchte ich gerne vermeiden.
  • 17.  Das machen wir auf keinen Fall, da schreiben wir rein, dass es auf jeden Fall wie gehabt .tar.gz und entpacken bleibt. „Status Quo Bias“ Eine bevorzugte Variante Closure zu erreichen ist einfach - es bleibt so wie es ist. Wir mögen Dinge, die so bleiben wie sie sind, das finden wir im Default erst mal gut, weil wir damit Risiko vermeiden. Das heisst „Status Quo Bias“ und hat erst mal nichts mit der Band zu tun. So wählen wir häufig auch da den gleichen Platz, wo wir freie Platzwahl haben.
  • 18. „Naïve Cynism“  Die Fachabteilung nutzt das sonst skrupellos aus und will gleich alles haben." Das ist naiver Zynismus. Wir neigen dazu, die anderen für Egoisten zu halten. Uns selbst aber nicht.
  • 19. „Theory X“ Der Mensch hat eine angeborene Abneigung gegen Arbeit und versucht ihr aus dem Wege zu gehen wo irgendwie möglich.  Vielleicht mal ein konkretes Beispiel: Wer kennt McGregors Theory X und Theory Y? Theory X sagt: der Mensch arbeitet nur, weil er Geld bekommt. Wenn er kein Geld bekommen würde, würde er nicht arbeiten, und ohne Kontrolle würde er vermutlich die Zeit mit irgendwas verbringen.
  • 20. „Theory X“ Der Mensch hat eine angeborene Abneigung gegen Arbeit und versucht ihr aus dem Wege zu gehen wo irgendwie möglich.  „Theory Y“ Für den Menschen hat Arbeit einen hohen Stellenwert und ist wichtige Quelle der Zufriedenheit, denn er ist von Natur aus leistungsbereit und von innen motiviert. Die Theory Y wiederum besagt, dass jeder Mensch gerne arbeitet, und seine Zufriedenheit daher kommt. Er ist von Natur aus leistungsbereit und arbeitet auch dann effektiv, wenn die Tür zu ist.
  • 21. „Theory X“ Der Mensch hat eine angeborene Abneigung gegen Arbeit und versucht ihr aus dem Wege zu gehen wo irgendwie möglich.  „Theory Y“ Für den Menschen hat Arbeit einen hohen Stellenwert und ist wichtige Quelle der Zufriedenheit, denn er ist von Natur aus leistungsbereit und von innen motiviert. Welche Gruppe haltet Ihr für weiter verbreitet? Wer denkt es wäre Theory X? Wer denkt es wäre Theory Y?
  • 22. „Theory X“ Der Mensch hat eine angeborene Abneigung gegen Arbeit und versucht ihr aus dem Wege zu gehen wo irgendwie möglich.  „Theory Y“ Für den Menschen hat Arbeit einen hohen Stellenwert und ist wichtige Quelle der Zufriedenheit, denn er ist von Natur aus leistungsbereit und von innen motiviert. Zu welcher Gruppe zählt ihr Euch selbst? Wer ist selbst eher Theory X? Wer ist eher Theory Y?
  • 23. „Naïve Cynism“ Ganze Management-Strategien basieren auf dieser kognitiven Verzerrung. Im Regelfall sehe ich die anderen als Egoistisch, mich selbst aber nicht. Deshalb kontrolliere ich, halte es aber für unnötig, selbst in umgekehrter Richtung kontrolliert zu werden.
  • 24. „Du immer mit Deinem Misstrauen.  „Attribution error“ Situativ versus Verhalten „Du immer mit Deinem Misstrauen“ - das ist der Attribution Error, wir neigen dazu, die Standpunkte anderer eher als ihr typisches Verhalten zu sehen, und wenig dem aktuellen Kontext geschuldet. Für uns selbst gilt das Gegenteil: wir erleben uns als situativ, urteilen aber faktisch sehr häufig verhaltensbasiert.
  • 25. Selbst wenn die Puppet wollen habe ich Dir das in 2 Stunden hinkonfiguriert.  „Planning Fallacy“ Bei einem eigenen Plan neigt man dazu die Zeit die er braucht zu unterschätzen. Wir werden in dem Moment zu Optimisten und nehmen das beste für uns selbst an. Und, mal ehrlich wem von uns ist das schon passiert? Mir durchaus häufig. Meine pläne gehen immer ganz erstaunlich schnell, während ich bei denen von den Kollegen immer etwas konservativ bin.
  • 26.  Das zahlt sich schon während der Entwicklung 3 mal aus. „Optimism Bias“ Das gilt auch für die Auswirkungen des Plans. Ich erwarte viel mehr Benefit als der Plan realistischerweise realisieren kann. Wem ist das hier schon passiert?
  • 27. "Poah, du weisst genau, dass Deine Schätzungen nie stimmen.  „Illusory superiority“ Noch so eine Macke von unserem Gehirn: wir halten uns zunächst einmal für schlauer als die anderen. Irgendwie, sagt uns das Bauchgefühl, sind wir vermutlich ein bischen überlegen. Wer von Euch nutzt ein eigenes Framework? Wer von Euch hat schon selbst einen Shop, ein CMS etc entwickelt, das nicht auch von vielen anderen genutzt wird? Dazu kommt meist Post-Purchase-Rationalization: Nachträglich erkläre ich mir die Entscheidung durch Zeiteinsparung, Einlernaufwand oder Spezialisierungsaufwand.
  • 28. Wer glaubt, dass er zu den schlechteren 50% Autofahrern hier im Raum gehört? Schauen wir doch einfach einmal nach. Wer von Euch glaubt, dass er zur schwächeren Hälfte der Autofahrer hier im Raum gehört, von denen, die einen Führerschein haben?
  • 29. Lake Wobegon Effekt: 80% der Leute denken sie wären überdurchschnittlich. Statistisch glauben 80% der Leute, sie persönlich wären überdurchschnittlich.
  • 30.  Wenn wir schon SCM machen, dann lieber Chef, und nicht Puppet". „Reactance“ Und hier wirds endgültig unsinnig. Reactance ist das Widerstand auf eine einschränkung meiner Möglichkeiten. Einfach nur weil ich mich einschränkt fühle möchte ich das Gegenteil von dem tun, was der andere will. Hier haben wir also einen Kollegen der gerade eben noch gar kein Konfigurationsmanagement wollte, jetzt aber dafür gleich die dickere Lösung.
  • 31.  WTF? Warum macht unser Gehirn so einen Unsinn? Warum macht es nicht einfach seinen Job und eine schlaue Lösung? Hey, so kompliziert kann das doch nicht sein. Warum mach das so einen Unsinn?
  • 32. Urteilsheuristiken Die Welt ist kompliziert/komplex, ich habe nicht die Zeit alles zu verstehen, ich kann mich nicht um alles kümmern. Das Hirn macht das aus einem einfachen Grund: es hat nur begrenzt viel Ressourcen, und es will seine Arbeit trotzdem schaffen. Also werden Heuristiken eingesetzt, die ein schnelles Urteil erlauben, und das schon irgendwie oft klappt.
  • 33. Wir haben gar nicht die Wahl, immer rational zu agieren, denn unsere Welt ist komplex. Wir Softwareentwickler arbeiten zum Beispiel immer mit einem nicht zusammegesetzten Puzzle denn wir können immer nur Teile vom Code sehen, und sind geistig gar nicht in der Lage, alle Code-Teile gleichzeitig parat zu haben. Sondern wir schauen uns Puzzleteil für Puzzleteil an, um dann an den Teilen des Puzzles etwas zu korrigieren, wo der Fehler war. Es ist also gar nicht möglich, immer alle Faktoren zu berücksichtigen.
  • 34. Urteilsheuristiken Default sind der : unbewusst, absichtslos, unwillkürlich und mühelos Das gemeine: Das ist der Default, das ist das Normalverhalten unseres Hirns. Das machen wir die ganze Zeit über. Das kontrollierte Denken passiert nur, wenn ein Problem deutlich mehr Aufmerksamkeit will, erst da werden wir reflektiert und vernünftig.
  • 35. Wir sind also nur in Ausnahmesituationen vernünftig. Das muss man sich mal verdeutlichen - wir ticken die meiste Zeit auf Basis einfacher Heuristiken, die weder situation noch rational begründet sind - und nur in Ausnahmesituationen bemüht sich unser Gehirn überhaupt, vernünftig zu agieren.
  • 36. Urteilsheuristiken Aber natürlich bei jedem anders. Und, um das ganze noch gemeiner zu machen, verhalten wir uns da natürlich alle anders. Wir haben alle unsere Erfahrungen, unsere Schwerpunkte, unsere Hirnchemie belohnt andere Dinge. Wer von Euch läuft, jogged, macht Marathons? Wer auf gar keine Fall? Weil uns die Hirne unterschiedliche belohnen, und unsere Erfahrunge anders aussieht.
  • 37. Psychologische Typen Wie unterschiedlich das aussehen kann hat dieser schon länger ziemlich tote Mann, Carl Gustav Jung, in seinen psychologischen Typen mal untersucht. Ich nutze hier die Typisierung von Myers Briggs, die zwar als völlig pseudowissenschaftlich verschrien ist, aber mir immer hilft, Dinge zu verstehen.
  • 38. Introversion Extroversion Sensorik: Die machen das über 4 Achsen, bei denen man sich jeweils immer mehr auf der einen als auf der anderen befindet. Die erste Achse ist Introversion zu Extroversion als Motivation, Dinge zu erfahren. Die extrovertierten sind vor allem an der Aussenwelt und breiter interessiert, und wollen neue Informationen. Die Introvertierten mögen eher ruhige und selbstdenkend, sie bekommen ihren input durch das verfolgen der eigenen Ideen. Etwa gleichverteilt.
  • 39. Intuition Sensing Die nächste Achse kümmert sich um die Verarbeitung der Sinneseindrücke: Wer Intuitionmässig unterwegs ist verlässt sich auf seinen sechsten Sinn, ob es in sein Gesamtbild passt. Der sensorische Geist interessiert sich für die Details, und ist eher konkret. Sensing macht den grösseren Teil aus.
  • 40. Feeling Thinking Nächste Achse Entscheidungsfindung- von Feeling zu Thinking. Der Feeling-Mensch orientiert sich an seinem persönlichen Wertesystem - an seiner Moral. Er möchte die anderen mitnehmen und versucht Konsens zu erzeugen. Der Thinker ist der Vulkanier unter den Persönlichkeitstypen, und eher an richtigen Resultaten interessiert. Frauen sind deutlich häufiger Feeling-orientiert.
  • 41. Judging Perceiving Hier geht es um Strukturierung: Judging-Typen entscheiden sich gerne früh und bleiben bei Ihrer Meinung. Sie sind kalkulierbar und verlässlich, der dominiert und kontrolliert gerne. Die Perceiving-Typen lassen sich gerne Türen offen und sind lange offen für neue Eindrücke und Änderungen. Etwa gleichverteilt.
  • 42. Agent J Extravert 78 % Sensing 38 % Feeling 81 % Judging 11 % Ich habe mal einfach zwei Kollegen genommen, um die Verhaltensmuster anzugucken. Agent J ist klar am äusseren interessiert, kümmert sich eher um die Details, hat klare persönliche moralische Werte und neigt vernachlässigbar mehr zur Planung als zur Adaption. Es ist auffällig, wie sehr er sich um alle anderen sorgt, und seine Werte sind 100% klar und verlässlich. Hat jemand eine Ahnung, was er als 17jähriger gemacht hat?
  • 43. Agent F Introvert 67 % Intuition 38 % Thinking 12 % Perceiving 33 % Agent F ist eher der Typ fürs tiefe durchdenken von Themen, er macht die schlauesten Puppet-Manifeste, ist Haskell-Guru und hat als 16jähriger den ersten Commit in den LinuxKernel gemacht, spricht aber nicht selbst davon. Er verfolgt die Vision vom „richtigen“ System gerne ausdauernd, ist eher rational unterwegs und hat kein Problem damit seine Meinung zu ändern.
  • 44. Introvert 67 % Extravert 78 % Intuition 38 % Sensing 38 % Thinking 12 % Feeling 81 % Perceiving 33 % Judging 11 % Technik richtig Personen glücklich Weil die Schwerpunkte so unterschiedlich sind, gibt es bei den beiden auch Divergenzen. Bei allen technischen Themen will Agent F natürlich die technisch richtige Lösung. Die ist Agent J egal - so lange die Leute zufrieden sind. Sobald beide Punkte in Widerspruch stehen sind sie sich nicht einig. Agent J will den Leuten entgegenkommen, Agent F die technisch konsistente Lösung liefern.
  • 45. Introvert 67 % Extravert 78 % Intuition 38 % Sensing 38 % Thinking 12 % Feeling 81 % Perceiving 33 % Judging 11 % Meetings nerven Meetings entscheiden Während Agent F denkt, dass Meetings nur stören und ihn aus der Arbeit holen freut sich Agent J auf sie, weil für ihn da der wichtigste Teil vom Geschäft passiert - gemeinsamer Abgleich, Planung, Entscheidungen. Die technischen Aspekte werden immer schlecht abgebildet, die Konzeptteile währenddessen gut, weil Agent J sich in den Meetings natürlich bewegt.
  • 46. Introvert 67 % Extravert 78 % Intuition 38 % Sensing 38 % Thinking 12 % Feeling 81 % Perceiving 33 % Judging 11 % Adaptieren! Planen! Agent J will planen, er will sich verlassen können und die Details möglichst sauber vorbereitet haben. Das geht Agent F völlig ab. Er will beginnt einfach und bewegt sich auf sein Gesamtziel vor, das er schon vor Augen hat. Agent F ist genervt, weil Agent J so viele Dinge schon im voraus festlegen möchte, Agent J geht es auf den nerv, dass die Ansagen von F immer vage und unverlässlich sind.
  • 47. Wir werden von gegensätzlichen Heuristiken gesteuert. Fazit also: wir werden sogar von sich widersprechenden Heuristiken gesteuert. Das eine Gehirn wird für Objektivität belohnt, das zweite für Emotionalität. Das eine für das Festhalten an einem Plan, das zweite für Adaptionsfähigkeit.
  • 48.   Kann man alleine agil arbeiten? Mal eine Frage in die Runde: Kann man alleine agil arbeiten? Nein, kann man nicht, nur einige wenige agile Praktiken - wie TDD oder Continuous Integration - lassen sich überhaupt alleine anwenden. Agiles Arbeiten ist das aber noch nicht. Warum wollen die agilen Jungs, dass man in einem Team arbeitet, und nicht alleine?
  • 49. Anforderungen unvorhersagbar Chaotisch Ko m pl Anforderungen vorhersagbar i Einfach Lösung vorhersagbar Komplex zi er t Lösung unvorhersagbar Das hängt mit unserer Sorte Probleme zusammen. Das hier ist das Stacey-Diagramm, und mit ihm lassen sich Problemwelten beschreiben. Die X-Achse sind die Anforderungen, wie weit sind die vorhersagbar? Die Y-Achse wiederum beschreibt die Lösungen, wie weit diese vorhersagbar sind. Je nachdem, wo sich unsere Aufgaben hier verteilen haben wir es mit einfachen, komplizierten, komplexen oder chaotischen Welten zu tun.
  • 50. Anforderungen unvorhersagbar Chaotisch Ko m pl Anforderungen vorhersagbar i Einfach Lösung vorhersagbar Komplex zi er t Lösung unvorhersagbar Unsere Probleme befinden sich im Webdevelopmentbereich meist hier, sprich: sie sind mit etwas glück nur kompliziert, im Regelfall aber komplex. Und komplex heisst, dass wir das alleine nicht lösen können.
  • 51. Anforderungen unvorhersagbar Chaotisch Ko m pl Anforderungen vorhersagbar i  Einfach Lösung vorhersagbar  Komplex zi er t Lösung unvorhersagbar Einfach können wir alleine, kompliziert manchmal, komplex nicht. Da sind zu viele Abhängigkeiten, Schleifen, unbekannte Kausalketten etc, als dass ich als Einzelkämpfer wirklich gut vorankommen könnte.
  • 52. Möglichst großes mentales Modell des Systems:  • Zusammenhänge erkennen • Veränderungen wahrnehmen • Chancen erkennen • Risiken erkennen Konkret arbeite ich mit einem mentalen Modell des Systems. Ich habe meine eigenen Bilder über die Strukturen, die Zusammenhänge des Systems - und die brauche ich, um überhaupt agieren zu können, weil ich zum Beispiel eine neue Komponente entwickle. Aber nicht nur bei allen planerischen Tätigkeiten brauche ich das - ich brauche es auch um dazulerne zu können. Im Stacey-Diagram sind viele Dinge unbekannt, und genau diese Unbekannten muss ich in Wissen überführen - und das bedeutet die Veränderungen wahrzunehmen und die Zusammenhänge zu verstehen.
  • 53.  Um so größer das gemeinsame Mental Model ist, um so effektiver ist die Zusammenarbeit. Die Armee von Singapur hat sich mal angeschaut, wie sich diese Mentalen Modelle auf Teamarbeit auswirken. Sie haben die Übereinstimmung der Mental Models gemessen, und dann die Teams auf Missionen mit komplizierten Aufgaben geschickt. Und tatsächlich sind die Teams deutlich effektiver, wenn sie ein gemeinsames Mental Model haben, also von den gleichen Bildern reden und gemeinsam Wissen erarbeiten können.
  • 54.  Frontend Backend Und genau deshalb gibt es cross-funktionale Teams, die eben nicht nach Frontend und Backend getrennt sind, sondern gemeinsam arbeiten. Durch die direkte Zusammenarbeit überschneiden sich die mentalen Modelle stark, und das Team wird effizienter. Ihr kennt vermutlich die Konkurrenz zwischen den Frontend- und Backend-Leuten, oder? Wer ist Backend-Mensch, wer ist Frontend-Mensch? Der Punkt ist: die Zusammenarbeit ist nur dann effektiv, wenn man ein grosses gemeinsames Modell der Realität hat, allem Spezialwissen zum trotz. Deshalb machen Firmen Feature-Teams, oder Firmen wie Facebook Bootcamps - um von Anfang an, und auch später, ein gemeinsames Mentales Modell zu haben.
  • 55.  Brauchen wir denn überhaupt noch Spezialisten? Wenn das am effizientesten ist, dann stellt sich natürlich die Frage: brauchen wir überhaupt noch Spezialisten? Wäre es nicht am besten, wenn man gleiche Leute mit gleichen Fähigkeiten und den gleichen mentalen Modellen hätten?
  • 56. Anforderungen unvorhersagbar Chaotisch JA! Ko m pl Anforderungen vorhersagbar i Einfach Lösung vorhersagbar Komplex zi er t Lösung unvorhersagbar Ja, natürlich brauchen wir die. Denn wir sind ja gar nicht mehr in der Lage, alles zu sehen, zu verstehen und zu machen. Und wenn alle gleich wären, würden sie alle gleich wenig bewirken können.
  • 57.  Komplementäre Fähigkeiten Gemeinsames mentales Modell Wir sind also genau dann effektiv, wenn wir komplementäre Fähigkeiten haben, aber möglichst viel gemeinsames mentales Modell. Wenn wir einen möglichst breiten Bereich an Aufgaben mit Skills abdecken, aber gleichzeitig auf einer gemeinsamen Basis stehen.
  • 58.  Widerspruch?! Komplementäre Fähigkeiten Gemeinsames mentales Modell Das klingt erst mal wie ein Widerspruch, ist aber eigentlich eher eine Frage der Zusammenarbeit und der Kommunikation. Das gemeinsame Modell ist nicht die Schnittmenge der Fähigkeiten, sondern die gleichen Worte und die gleichen Bilder. Ich kann mit jemanden mit ähnlichen Skills völlig divergente Bilder haben, die eine Zusammenarbeit unmöglich machen. Und ich kann mit jemandem mit völlig anderen Skills trotzdem schnell zu einer guten gemeinsamen Lösung kommen. Kennt das jemand aus der Praxis?
  • 59. Introvert 67 % Extravert 78 % Intuition 38 % Sensing 38 % Thinking 12 % Feeling 81 % Perceiving 33 % Judging 11 % Komplementäre Fähigkeiten Gemeinsames mentales Modell Kommen wir doch mal zurück auf unsere beiden Agenten. Was fällt Euch hier auf? Exakt, die sind komplementär. Der eine ist gut in technischem Gesamtbild und Adaption, der zweite in Sorgfalt und dem Umgang mit Menschen. Die komplementären Fähigkeiten sind also nicht nur eine Frage der fachlichen Skills, sondern auch der Urteilsheuristiken. Und wir brauchen beides, um unsere Welt beurteilen zu können.
  • 60. Introvert 67 % Extravert 78 % Intuition 38 % Sensing 38 % Thinking 12 % Feeling 81 % Perceiving 33 % Judging 11 % Gegensätzliche Verhaltensmuster sind eine Stärke! Und es ist in Wahrheit ein Vorteil, wenn man dort divergent ist. Wer von Euch hat Leute im Team, bei denen er permanent im Klinch liegt, weil sie einfach anders denken? Genau das sind Eure komplementären Mitspieler, zusammen mit ihnen habt ihr die größte Effektivität - _wenn_ die mentalen Modelle nahe beeinander sind. Und wenn man eine Methode gefunden hat, die beide Perspektiven mit einbringen.
  • 61. Forming Storming Norming Performing Tuckman Model Das Modell kennt ihr vermutlich schon - das wurde schon 1965 von Bruce Tuckmann entwickelt. Bei Forming findet das Team sich als Gruppe zusammen, es gibt nicht nur kein gemeinsames Modell, man hat noch nicht mal Ahnung davon, was die anderen gut können. Bei Storming findet man das heraus, man Benchmarkts Skills, Vorlieben und Entscheidungsstratetegien. Bei Norming kommen wir endlich zum gleichen Modell der Realität, das aber noch nicht gross sein muss, es reicht aber zum Zusammenarbeiten.
  • 62. Forming Storming Norming Performing Tuckman Model Nur ein paar Teams kommen aus dem Norming-Status heraus und landen tatsächlich in Performing. Das sind genau die Teams, bei denen es ein grosses gemeinsames Mental Model gibt. Aber was heisst das konkret?
  • 63. Tuckman Model Spannend wird das ganze tatsächlich, wenn man es in Performance anschaut, wie es der Herr Katzenbach getan hat. Beginnen wir mit einer einfachen Arbeitsgruppe, dann sind wir so performant wie die Summe der Leute. Jeder macht seinen Teil, auf Basis seines mentalen Modells, im Rahmen seines Teilwissens und seiner kognitiven Ausrichtung. Beim Storming geht es runter, weil man Stärken und Schwächen nicht kennt, und die Machtverhältnisse noch nicht klar sind. Erst mit einem shared Goal gibt es wieder Performance, und als richtiges Teams, das eingespielt ist ist man dann auch wieder performanter als die Gruppe von Leuten. High Performance Teams wiederum, mit einem grossen komplementären Fähigkeitenset, guten Teammechanismen und einem gemeinsamen Modell liegen Faktoren darüber.
  • 64. e p o N Hyperperformance = gemeinsames mentales Modell + komplementäre Skills? Reicht es also aus, wenn ich ein gemeinsames Modell habe und komplementäre Skills? Bin ich dann schon hyperperformant? Reicht das? Kommt mir irgendwie komisch vor.
  • 65. Aufgaben und Fähigkeiten zusammenbringen. Das wäre ja auch zu einfach gewesen. Was hier noch fehlt ist klar: die Leute müssen nicht nur die Fähigkeiten haben, etwas zu lösen, sie müssen es auch tun. Und hier wird es gemein. Es ist uns selbst in Wahrheit unklar, was wir können und was wir nicht können. Wie immer hat der Pointy Haired Boss nicht recht, und es ist oft gar nicht das, was man mag oder denkt.
  • 66. Introvert 67 % Intuition 38 % Thinking 12 % Perceiving 33 % Scrum Master? Eine Geschichte aus unserer Praxis ist ein Scrum-Master, der bei einem ähnlichen Profil wie Agent F herauskommt. Er wollte gerne Scrum-Master werden, weil ihm das als logischer Karriereschritt vorkam. Die Kollegen fanden das auch gut, weil er als Entwickler als Senior akzeptiert war, und man sein Wissen und seine Professionalität schätzte. Und weil er auch noch verantwortungsvoll war, fand das auch die Unternehmensleitung, also unter anderem ich, gut. Und jetzte ratet mal: ist das gut gegangen? (Agent F würde btw. nicht von selbst auf die Idee kommen :-) )
  • 67. Extravert 78 % Sensing 38 % Feeling 81 % Judging 11 % Scrum Master? Und was meint ihr zu Agent J? Sollte der Scrum-Master werden? Wenn es nach mir geht: Extravert: check, sensing: check, feeling: check, Judging: check. Er sorgt sich um die einhaltung von Planung, er kümmert sich um die Details, und, am wichtigsten: er redet mit den Leuten und weiss, was Phase ist. Kann sich trotzdem jemand vorstellen, wo es Probleme geben kann? Ich persönlich würde davon ausgehen, dass objektive Team-Performance nicht so seine Sache ist, denn er ist deutlich im Feeling-Bereich, und auch Adaption wird anderen einfacher fallen als ihm.
  • 68. With
  • 69.  A
  • 73.  My
  • 74.  Friends. Extravert 78 % Sensing 38 % Feeling 81 % Judging 11 % Scrum Master? Also doch ein schlechter Scrum-Master? Nein, er ist schliesslich teil eines Teams, er muss sich die fehlende Teile einfach von den Kollegen holen, und mit denen Kooperieren, zB mit einem mit Dominanz auf Thinking. Beim realen Agenten J ist das btw. garantiert kein Problem.
  • 75.   Es kommt auf die angewandten Fähigkeiten des Teams an, nicht auf die individuellen Fähigkeiten. Und genau das ist der Punkt. Entscheidend ist, was das Team, nicht was das Individuum liefert. Entscheidend ist, was das Team versteht, nicht was das Individuum versteht. In der Psychologie ist das Transactional Knowledge, also das angewandte Wissen. Noch mal zum mitschreiben: Die individuelle Fähigkeit ist egal. Es zählt nur, was vom gesamten Team auf die Strasse gebracht wird.
  • 77.  Fähigkeiten Tuckman Model Und zwar genau deshalb. Wenn jemand sich selbst in den Vordergrund stellt, und es ihm / ihr um seine eigenen Fähigkeiten geht, hat er in einer komplexen Welt ein Problem - denn er kann immer nur unten links landen. Wer wiederum versucht Teil eines Teams zu sein kann er deutlich performanter sein - nur dass die Performance dann wieder nicht klar individuell zuzuordnen ist.
  • 78. The highest performing (SCRUM) Team ever recorded was a Borland Team audited by Bell Labs. They were 50 times faster than waterfall Team industry average. Der Punkt ist aber - genau da oben rechts in der Ecke wohnen die Hyperperformanten Teams. Die Frage ist natürlich, warum findet das ausgerechnet in unserer Branche statt, und nicht woanders?
  • 79. Die wichtigste Leistung, die das Management im 21. Jahrhundert erbringen muss, besteht darin, auf ähnliche Weise die Produktivität der Wissensarbeit und der Wissensarbeiter zu steigern. Automatisierung Teams für Komplexität ? Und wie machen wir das? Die Antwort ist ganz einfach: wir sind die Maschinenbauer des Informationszeitalter. Die Industrialisierung hat über Maschinen die manuelle Arbeit automatisiert, wir automatisieren über Software die Wissensarbeit. Damals war der Preis dafür die Spezialisierung, heute ist der Preis die Komplexität - und Komplexität ist etwas, mit dem Individuen nicht umgehen können, sehr wohl aber Teams mit kontinuierlicher Verbesserung und Adaption.
  • 80.  „Ok, aber jetzt mal in Echt, bekomm ich das auch? Oder ist das nur Theorie-Blah?“ Die eigentliche Frage für uns ist aber nicht, ob Peter Drucker am Ende des Tages Recht hatte, sondern ob es daraus für uns was zu schlussfolgern gibt. Wir wissen jetzt, dass wir komplementäre Kompetenzen, möglichst viel gemeinsames mentales Modell und die bewusste Ausnutzung der Teamfähigkeiten benötigt wird. Wie komme ich dahin?
  • 81.  Zunächst einmal: wo steht mein Team gerade? Das Buch Tribal Leadership von den Herr Logan und King und Frau Fischer-Wright hat das in mehrere Levels verteilt, und diese beschreiben gut, wie es sich anfühlt, in einem Team diesen Levels zu arbeiten. Der erste Level sind die Leute feindlich eingestellt, alles wird als unfair wahrgenommen, die Gesamtsituation ist doof. Beim zweiten Level ist man auf einem „ich kenne das schon und habe es scheitern sehen“, Sarkasmus dominiert. Beim dritten Level, der am meisten verbreitet ist, treibt das Ego voran - man gewinnt individuell, und kommt individuell weiter. Man würde viel mehr leisten, wenn die anderen nur auch so mitziehen würden.Level 4 ist endlich ein echtes Team. Ich bin nicht besser als meine Kollegen, sie sind nicht besser als ich. Wir gewinnen zusammen, und mein Team ist besser als andere Teams. Level 5 ist der Idealzustand: Es geht uns nicht mehr um Konkurrenz, sondern darum, etwas zu bewegen. Wir machen etwas, was wirklich etwas bewegt, und Konkurrenz wird als „Hey, geil, mit denen zusammen können wir noch mehr erreichen“
  • 82. You
  • 84.   here.  Darf ich mal fragen, wer von Euch auf dem Level „Personal Domination“ steht? Statistisch sollten jetzt 50% der Hände nach oben gehen, dank Illusiory Superiority werden es vermutlich ein paar weniger sein. Aber wie kommen wir auf den nächsten Level?
  • 85.  Become a Better Team Wie komme ich einen Level höher? Wie werde ich ein besseres Team?
  • 86.  1. die kognitiven Verzerrungen erkennen 2. sie als Chancen nutzen 3. ein gemeinsames Bild formen, Selbstbild===Fremdbild Become a Better Team Erster Schritt: Die Verhaltensmuster der anderen verstehen und als Chance nutzen. Wenn ich wie Agent J und Agend F am Anfang den anderen nicht verstehe, und deshalb in eine persönliche Konkurrenz gehe, kann ich nicht über Level 3 - Lone Warrior - hinauskommen, wie es in den meisten Teams auch so passiert. Damit ich in den „We‘re great“-Modus komme muss ich sie auf Augenhöhe wahrnehmen, und dazu brauche ich ein gemeinsames Bild, das ihre Vorteile deutlich macht.
  • 87.  Tools: Moving Motivators http://www.happymelly.com/an-easy-way-to-talk-about-serious-things/ Become a Better Team Ein schönes Tool dazu sind die Moving Motivators von Happy Melly / Jurgen Appelo von Management 3.0 - da findet man, analog zu den Myers-Briggs-Bögen, heraus, was den Kollegen wichtig ist und welche Prios sie haben. Daraus muss ich keine Schlüsse ziehen, aber ich habe ein gemeinsames Wissen, auf dem ich arbeiten kann. Wenn jemand Mastery fokussiert, dann weiss ich, wen ich für komplizierte Tasks einsetze. Wenn jemand Ordnung braucht, dann sollte er Prozesse maintainen oder Themen wie Qualität, Refactoring oder Wartung angehen. Jemand der von Ehre motiviert sind sollte die Erfolge des Teams im Review zeigen. etc.
  • 88. Tools: Pairing Pair Programming http://www.flickr.com/photos/rafaelmob/ Pair „Working“ mit Nondevs Mob „Programming“ Pair Programming Matrix Noch ein Tool, das gut wirkt ist Pairing, oder, noch besser mit noch mehr Leuten. Wer macht hier alles Pair Programming? Wer nur im eigenen Team? Ich habe es selbst schon in der Praxis gesehen, wer noch Front/Backend oder Development/ Grafik-Trennung hat: macht Pair Programming - oder eben auch Pair Design. Noch neuer ist Mob Programming, wo wirklich alle - inklusive des Kunden - bei einer Programmiersession sind. Das ist ein perfekter Weg, um ein gemeinsames Mentales Modell zu bekommen.
  • 89.  Tools: Peer Review Fokus: die angewandten Fähigkeiten im Team Das nächste wichtige Tool ist Peer Review. Peer Review heisst: meine Kollegen bewerten mich, und zwar diejenigen, die mich meiner Ansicht nach am besten beurteilen können. Und im Fokus stehen weder Fähigkeiten technischer noch Sozialer Natur, sondern die Teilhabe an den angewandten Fähigkeiten im Team. Bei uns gibt es einen Bogen dazu, der nur darauf abzielt, wie jemand im Team wirkt. In der Praxis ist es ja auch egal, was jemand könnte - entscheidend ist, wie er tatsächlich wirkt.
  • 90.  Tools: Frauen in der IT Frauen sind statistisch besser im Erzeugen und Erhalten von gemeinsamen mentalen Modellen. Ein Tool, was wir in den nächsten Jahre noch deutlich mehr brauchen werden sind Frauen. Das hat mit Geschlechtergerechtigkeit usw gar nichts zu tun, sondern mit einer statischen Stärke: Frauen kümmern sich mehr um die gemeinsame Basis, das Mitnehmen von allen bei Entscheidungen. Wer in Level 3 vom Tribale Leadership steckt sollte sein Team mit Frauen bewerfen.
  • 91. Tools: Kudos  Praise von Kollegen zu Kollegen Ein sehr geiles Tool, vom Kollegen Martin Ruprecht bei uns eingeführt - die Kudo-Wall. Da steht öffentlich in der Küche, welcher Kollege welche Dinge gut und geil gemacht hat, und warum man ihn schätzt.
  • 92. Tools: Kudos  Praise von Kollegen zu Kollegen Da gibt es sogar Bücher, aus denen man direkt die Kudos bekommt, um sie mit Stil zu machen.
  • 93.  Tools: Selektiere Rollen statt Positionen Rollen werden vom Team autonom und selbstorganisiert vergeben und sind auf Zeit. Keine fixen Titel und Rechte. Ein Tool was hilft aber Selbstbewusstsein braucht ist der Verzicht auf fixe Titel und Positionen. Weil ich nach angewandten Fähigkeiten im Team und mit einem gemeinsamen mentalen Modell vorgehe, muss ich an meinen Problemen entlang vorgehen. Die Rollen werden nach gemeinsamen Kompetenzen verteilt, und sind dynamisch, nach Eignung, Kombination und Verfügbarkeit der Leute. Der Scrum-Master ist also derjenige, von denen das Team denkt, es ist am besten, wenn er/sie in diesem Moment diese Position einnimmt. Wie lange? Bis das Team denkt: es ist am besten, wenn das jemand anderes macht. Daher kommen Ideen wie rotierende Scrum-Master.
  • 94. Keine Architekten! Das heisst im Fazit auch, dass es keine klassische Architekten-Entscheider-Rolle mehr gibt. Damit die Teams zusammen arbeiten können, brauchen sie ein gemeinsames Mentales Modell, also müssen sie an der Erstellung beteiligt sein. Und gerade Architekturen sind zu komplex, um sie alleine machen zu können- ich brauche sowohl Personen mit Liebe zum Gesamtbild als auch welche mit Liebe zum Detail. Genau aus der Unfähigkeit, das zu vereinen stammt der schlechte Ruf der Architekten, die im Elfenbeinturm etwas konstruieren, was an der Front nur in Katastrophen münden kann.
  • 95.  Tools: Emergente Verfahren • Architektur • Entscheidungen • Rollen Eine weitere grosse Rolle spielen emergente Verfahren. Emergent heisst, dass es nicht Resultat einer persönlichen Aktion ist, sondern aus dem gesamten System - und damit auch dem Team - entsteht. Emergente Entscheidungen können in einer komplexen Welt im Gegensatz zu persönlichen deutlich mehr Wissen abbilden. Konkret: emergente Architektur entsteht durch Verfahren wie ATAM oder durch Agile Modeling. emergente Entscheidungen sind welche, die durch einen Prozess in der Teamarbeit entstehen.Beispiel ist die Integrative Entscheidungsfindung aus Holacracy oder die Decision Matrix. Emergente Rollen entstehen durch Experimentieren, zB durch rotierende Scrum-Master oder durch die Pair Programming Matrix.
  • 96. Fazit  Wir sind die meiste Zeit über irrational. Aber wir können das zu unserem Vorteil nutzen, wenn wir es in Teams richtig anwenden. Im Gegenzug werden wir mit Performance belohnt. https://joind.in/talk/view/9511 http://slideshare.net/johannhartmann Hier noch mal im schnellen Überblick: wir sind die meiste Zeit über irrational, wenn auch unterschiedlich. Das macht aber nichts, denn wir können das als Vorteil nutzen. Dafür müssen wir uns aber auch aufstellen. Aber, und da wird es spannend, im Gegenzug können wir deutlich mehr Performance liefern. Ihr findet diesen Talk unter slideshare.net/johannhartmann, er enthält auch alle Texte die ich hier so erzähle als Fliesstext. Und Ihr könnt diesen Text natürlich raten, ich freue mich immer über Feedback.
  • 97. Input und Feedback von: Jens Broos, Albrecht Günther, Daniel Hallmann, Franz Pletz, Periklis Tsirakidis und Sebastian Springers AllStars-Team Es wäre ja schön seltsam, so einen Vortrag alleine zu machen. Habe ich auch nicht, das gab viele Diskussionen, Input und Ideen von meinen Kollegen, _bevor_ die Slides begonnen wurden.
  • 98. F*ck You, Individuum! Praise You, Team! Danke! https://joind.in/talk/view/9511 http://slideshare.net/johannhartmann