Agile vs

ManagementHallo zusammen. Willkommen zum Talk Agile vs Management. Guten morgen. Ich hoffe, Sie sind alle gut angekommen.

Wissens- vermittlung

Wenn sie noch ein bisschen erschöpft sind ist das kein Problem, in diesem Talk brauchen Sie sich nichts zu merken - denn es geht nicht um Wissensvermittlung.

Nicht-Wissens-

vermittlung

Sondern um Nichtwissensvermittlung. Wir reden schliesslich über Management. Und das ist genau der Punkt.

Hier haben wir einen der Menschen, die Nichtwissen popularisiert haben.

Donald Rumsfeld

Das ist Donald Rumsfeld, seines Zeichens ehemaliger Verteidigungsminister der USA, Erfinder von Bio- Atom- Chemiewaffen im Irak, und einer der profiliersten Nichtwisser der Welt.

„We do know of certain knowledge that Osama

Bin Laden is either in Afghanistan, or in some other country, or dead.

And we know of certain knowledge that we don't

know which of those happens to be the case."

Donald Rumsfeld

Um einmal ein Beispiel zu geben - 2001 begann der Afghanistankrieg, um mit Osama Bin Laden den Verantwortlichen hinter dem World Trade Center Attentat zu finden. Glücklicherweise wusste man genau, wo er sich befand: In Afghanistan - praktisch, denn man hatte die Truppen ja schon da - in einem anderen Land (eher unpraktisch) oder er war schon tot. Faktisch hatte man also keine Ahnung, wo er war. Aber man wusste immerhin sicher dass man nicht wusste wo er war.

„But there are also unknown unknowns –

there are things we do not

know we don't know.“

Donald Rumsfeld

Und Donald Rumsfeld war nicht nur ein Praktiker des Nichtwissens, er hat auch am theoretischem Unterbau der Ahnungslosigkeit gearbeitet. Und nicht nur die einfache Ahnungslosigkeit, sondern auch die Ahnungslosigkeit, dass man Ahnungslos ist. Wer sich noch erinnern kann - Rumsfeld galt damals als mächtiger Idiot. Kann jemand so ahnungslos wie er sein?

„Wie lange würde ein kompletter Rewrite mit node.js dauern?“

Aber schauen wir doch mal auf unsere eigene Welt. Und nehmen wir eine Frage, die heutzutage jedem dritten Entwickler von seinem Chef gestellt wird. „Wie lange würde ein kompletter Rewrite der Software auf Basis von Node.Js und MongoDB bauen? Und was sagen wir, wenn wir das gefragt werden? „Vermutlich ziemlich genau zwischen 3 Monaten und 3 Jahren.“

Wir kennen die Software.

Wir kennen alle Features.

Wir haben sie schon alle einmal implementiert.

Wir kennen node.js gut.

!

Wir wissen es trotzdem nicht.

Das muss man sich mal auf der Zunge zergehen lassen: wir kennen schon alle Features, wir wissen wie es aussieht, trotzdem haben wir in Wahrheit keine Ahnung. Und der Vorgesetzte fragt uns, warum wir das nicht wissen.

!Wir können nicht einmal gut erklären, warum

wir das nicht wissen.

Und dann gucken wir irritiert und sagen ihm: Ja, weil es nicht geht. Ich könnte schon was sagen, aber das würde dann vermutlich nicht stimmen. Das war immer so.

" 4 % Successful 47 % Challenged 49 % Failed

Rewrites

Die Standish-Group - ja, die mit dem Chaos-Report - hat auch mal eine Auswertung über den Erfolg von solcher Komplett-Rewrites gemacht. Und nur 4% schaffen es in Zeit und Budget, 47% verreissen Zeit und Budget, und 49% werden ganz eingestellt.

"Selbst wenn wir es wieder und wieder gezeigt haben.

Wir haben es also empirisch wieder und wieder gezeigt, dass die Schätzungen sogar auf bekanntem Terrain massiv daneben liegen. Trotzdem glauben Manager häufig, dass es eigentlich anders sein muss, und hier einfach besser geschätzt und kalkuliert werden muss.

?Pair Programming

Zwei Programmierer werden effizienter wenn einer arbeitet und der andere zuguckt

Dieses Unverständnis gilt auch für die Methoden, die wir einsetzen. Zum Beispiel Pair Programming: Ich setzte zwei Developer an die gleiche Aufgabe, und am Ende sind sie effizienter. Für einen Manager ist das völlig unplausibel. Wenn einer eine Aufgabe alleine schon machen kann, warum wird der schneller, wenn jemand anderes daneben sitzt und mitdiskutiert? Warum spart das Zeit, und ist keine grosse Zeitverschwendung?

27 %more productive

!Eine akademische Case-Study von Jensen aus 2003 hat einen Produktivitätsvorsprung von 27% durch Pair Programming nachgewiesen. Das waren echte Projekte, und man kann ihnen vorwerfen, dass sie zufällig passiert sind und es unter Laborbedingungen ganz anders ausgesehen hätte.

101 %more productive

!Und in der Tat sieht es unter Laborbedingungen ganz anders aus: In einem Experiment von 2006, von Xu und Rajlich, wurde sogar eine Produktivitätssteigerung von 101 Prozent gegenüber einzelner Programmierung nachgewiesen.

?Ein Programmierer leistet mehr in 8 Stunden als in 14 Stunden?

OverhoursEin ähnliches Beispiel sind Überstunden. Wenn jemand 8 Stunden arbeitet, und dann noch mal 6 hinterher, dann sollte das zumindest grob in Richtung des anderthalbfachen an Arbeitsleistung gehen, oder? Faktisch wird ein Entwickler deutlich weniger produktiv, wenn er mehr als 8 Stunden im Mittel arbeitet.

!Productivity

6h > 8h > 14h

Für Wissensarbeiter liegt der Peak sogar bei 6h - wenn er 6 Stunden am Tag aktiv arbeitet ist das Maximum erreicht (Quelle: Why Crunch Modes Doesn’t Work: Six Lessons) Eine einfache Addition gilt nicht.

Text

http://www.lostgarden.com/2008/09/rules-of-productivity-presentation.html

Man weiss sogar, dass jede Überstundenarbeit nach ein paar Wochen zwangsläufig in Erholungsphasen mit kleinerer Produktivität endet, ob man daheim oder im Büro sitzt. Und dass diese Erholung grösser ist als die Arbeitsphase. Das heisst, dass der Entwickler in der sechsten Woche zwar 14 Stunden im Büro sitzt, aber die Produktivät einer Halbtagskraft liefern kann.

Team Size?Wenn ich ein

Team deutlich größer mache wird es nicht deutlich produktiver?

Es gibt in Brooks Law auch eine Ausprägung davon: Adding people to a late project makes it later. Das ist seit den 80er Jahren bekannt und dokumentiert, trotzdem passiert der Fehler heute noch regelmässig.

!100.000 LOC

<5 Personen: ca 9 Monate

>20 Personen: ca 9 Monate

Doug Putnam von QSM ist neben der Standish Group der Mensch, der am meisten Statistik über Softwareprojekte betreibt. Und dort haben sie die Produktivät von grossen und kleinen Teams bewertet, anhand von 100.000 equivalent source lines of code. Und heraus kam, dass mittlere Teams mit 5 bis 9 Leuten nur knapp weniger Code schaffen als grosse Teams mit mehr als 20 Leuten. Auch hier gilt eine einfache Addition nicht.

!Estimation

Die Produktivität ist höher

wenn ich nicht schätze wie lange ich brauche.

Und wenn ich nicht schätze wie lange ich brauche bin ich schneller als wenn ich schätzen würde.

!http://davidfrico.com/agile-book.htm

Oder man wendet sich direkt an den Experten, was empirisches Wissen angeht. David F Rico hat im Rahmen seiner Forschung einmal alle Studien auf dem Gebiet gesammelt und zusammengefasst, und stellt netterweise auch auf seiner Website die Daten zur Verfügung. Das Buch leider nicht.

"Selbst wenn wir es wieder und wieder gezeigt haben.

Aber, wie bereits oben - das reicht nicht. Es reicht nicht, dass jede Studie, jede akademische Untersuchung, jede Untersuchung von IBM oder Consulting-Unternehmen beim gleichen Ergebnis herauskommt.

"Man kann es Managern

nicht erklären.Wir kommen einfach nicht zu den Managern durch. Dieses empirische Wissen hat die gleiche Qualität wie die „Amerikanische Wissenschaftler haben herausgefunden“-Einspaltenartikel in der Bildzeitung.

?Wer arbeitet mit Storypoints?

Wer schätzt seine Aufwände in Storypoints?

?Warum nicht einfach Stunden?

Warum schätzen wir nicht einfach in Stunden, wie damals vorm Krieg. Warum sagen wir nicht einfach: das dauert 3 Tage, und dann dauert es eben drei Tage? Weil das eine Kontrollillusion erzeugen würde. Denn was passiert?

!„Mein Debugger funktioniert

bei den Unit-Tests nicht.“

„Vagrant startet die virtuelle Maschine nicht mehr.“

„Der Bug ist erst in der neuen Library gefixed.

Die braucht andere Updates.“

Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?

Ich wusste die Antworten

auf diese Fragen vorher nicht.

Ich wusste sie vorher nicht. Und nicht nur das.

Ich wusste vorher nicht, dass ich diese Fragen habe.

Ich wusste sie vorher nicht. Und nicht nur das.

Ich wusste nicht, was ich nicht wusste.

Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste. Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.

Orders of Ignorance

Orders of Ignorance

Das offizielle Organ der Association for Computing Machinery, die Communications of the ACM, haben sich mal einen Kopf darüber gemacht, was man so alles nicht wissen kann. und das ganze Ausformuliert. Genannt haben sie es die Orders of Ignorance.

Orders of Ignorance

Ignoranz 0ter Ordnung:

Ich weiß etwas.

Abwesenheit von Ignoranz

Das klingt zwar jetzt unnötig, macht aber durchaus Sinn. Wenn ich etwas sicher weiß, bin ich nicht ignorant.

Orders of Ignorance

Ich ändere in style.css die Farbe auf #ffffff

Ignoranz 0ter Ordnung:

Wenn ich alles weiß, ist mein Leben einfach. Ich mache es einfach. In diesem Fall weiß ich den Wert, und ich weiß, wo ich ihn eintragen muss.

Orders of Ignorance

Ich weiss etwas bestimmtes nicht.

Abwesenheit von Wissen

Ignoranz 1ter Ordnung:

Wenn ich etwas nicht weiß, geht das auch ok. Solange ich weiß, was ich nicht weiß - und wie ich zu dem Wissen komme.

Orders of Ignorance

Ändere die Farbe in style.css auf den

Default-Wert

Ignoranz 1ter Ordnung:

Wenn in meiner Anforderung steht „Backgroundcolor bitte aus dem Styleguide.“, dann weiss ich zwar die Farbe nicht, ich kann aber nachgucken, nachfragen oder ähnliches.

Orders of Ignorance

Ich weiß nicht, was ich nicht weiß.

Abwesenheit von Erkennen.

Ignoranz 2ter Ordnung:

Hier kommen wir bei Donald Rumsfeld an, oder bei unserem Business- uns fehlt nicht nur eine Antwort, wir wussten vorher noch nicht mal, dass wir fragen müssen.

Orders of Ignorance

Mach die Library kompatibel.

Ignoranz 2ter Ordnung:

Wenn ich zum Beispiel eine Library kompatibel machen soll, weiss ich vorher nicht, was ich genau tun muss - denn ich weiss noch nicht mal, welche Anpassungen erforderlich sind. Aber ich kann es herausfinden, und ich weiss, was ich dazu tun muss - Library einbinden und Fehler angucken.

Orders of Ignorance

Ignoranz 3ter Ordnung:

Ich weiß nicht, wie ich herausfinde was ich

nicht weiß.

Abwesenheit von Vorgehen

Und was ist, wenn wir es nicht ausprobieren können?

Orders of Ignorance

Finde die beste Library auf Github.

Ignoranz 3ter Ordnung:

Das ist ein solches Problem. Ich weiss nicht nur nicht, was die beste Library auf github ist, ich weiss auch nicht, was ich tun kann, um das herauszufinden. Es gibt sicherlich eine beste Library auf Github. Aber ich weiss nicht, was ich tun könnte, um sie zu finden.

Orders of Ignorance

Ignoranz 4ter Ordnung:

Ich weiß nicht, dass es unterschiedliche Arten von

Nichtwissen gibt.

Das wird die anwesenden Informatiker freuen - es gibt auch Meta-Ignoranz, wenn ich nicht weiss, dass es unterschiedlichen Arten von Nichtwissen gibt.

Orders of Ignorance

Es gibt nur 1te Ordnung: !

Ich weiss etwas bestimmtes nicht.

Ignoranz 4ter Ordnung:

Und genau da liegt eines der Management-Probleme: es gibt in Ihrer Welt nur Nichtwissen erster Ordnung. Ich muss vorher alle richtigen Fragen stellen, dann weiss ich alles und kann nach Plan vorgehen.

Orders of Ignorance

Und wir?

Wie sieht es bei uns ITlern aus?

Aber welche Form der Ignoranz ist bei uns denn massgeblich?

Orders of Ignorance

Und wir?

Nichtwissen erster Ordnung kann man im Vorfeld klären.

Schauen wir doch einmal nach. Wissen erster Ordnung ist welches wie die Stylesheet-Farbe. Ich kann es einfach im Vorfeld klären, indem ich recherchiere. Also müsste ein Big Upfront Design gut funktionieren, denn dort findet die Fragenklärung statt.

CHAOS REPORT 2012 KLASSISCH

29 %

57 %

14 %

SuccessfulChallengedFailed

Quelle: Standish Group Chaos Report 2012

Die größte Studie zum Thema Softwareprojekte ist der Standish Group Chaos Report, den es seit über 20 Jahren gibt. Und der dokumentiert die traurige Wahrheit, die uns Softwareleuten seit 20 Jahren Sorge macht und als „Softwarekrise“ quasi zu einem Dauerbrenner geworden ist. Nur 14% Prozent aller Projekt sind in Time & Budget. 57 % laufen aus dem Budget und / oder der Zeitline, und 29 % werden nie fertiggestellt.

CHAOS REPORT 2012 AGILE

9 %

49 %

42 %

SuccessfulChallengedFailed

Quelle: Standish Group Chaos Report 2011

Bei agilen Projekten sehen die Zahlen besser aus - 42% sind erfolgreich, und nur 9% scheitern vollständig. Immer noch nicht besonders, aber besser als vorher. Wie kann das denn sein? Ich verspreche Deadlines mehr sondern schaffe sie ab, und trotzdem halte ich sie besser? Dabei gab es doch gar keine vernünftige Planung!

STANDISH GROUP

REWRITES

49 %47 %

4 %

SuccessfulChallengedFailed

Ja, Planung. Das wird sogar noch schlimmer. Wenn ich einen Rewrite machen habe ich praktisch den High Score von Planung. Die Software, ihre Anforderungen, ihre Implementierung, alles ist schon da. Und trotzdem sinken die Chancen sogar noch einmal deutlich, was das Einhalten von Time & Budget angeht.

Scope Creep +(fehlendes Erkennen auf Kundenseite)

Dark Matter (fehlendes Erkennen auf Developmentseite)

=50% Ignorance 2ter Ordnung

Wenn man tatsächlich auf die Projekte und auf die Projektstatistik schaut - in diesem Fall ist die Quelle David J Andersons agile Manager - dann leuchtet er sehr ein. Es gibt zwei Sorten von Unknown Unknows, die bei uns eine grosse Rolle spielen - Scope Creep, das sind die Features, von denen der Nutzer vorher noch nicht weiss, dass sie ihm fehlen werden - und Dark Matter, Programmierung von der wir bei Beginn der Entwicklung noch nicht Wissen, dass wir sie brauchen, um die Features bereitzustellen.

Was mache ich in so einer Branche?

Wie gehe ich damit um, wenn ich so viele Dinge habe, die ich nicht weiss? Mit Dingen die ich nicht weiss kann ich ja nichts machen, oder? Oder kann ich damit Arbeiten, wenn ich unknown unknowns habe?

Das wollte auch diese Firma wissen.

Dave Snowden

Und die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales und forscht an der Komplexitätstheorie im Bereich Sensemaking.

Study the

actual, not the

official management practice

Und IBM hat ihm einen sehr schönen Auftrag gegeben: die echten Managementmethoden, die praktiziert wurden, und nicht die offiziellen anzugucken. Und da gab es ein interessantes Ergebnis. Mit einem interessanten Namen.

Cynefin

Lebensraum, Platz

Und zwar mit dem Cynefin-Framework. Ich hoffe ich spreche es richtig aus, mein walisisch ist etwas eingerostet. Cynefin beschreibt meine Umgebung, die Welt, in der ich lebe - und zwar inklusive Ort, Kultur und Leuten.

Komplex Kompliziert

Chaotisch Einfach

Verwirrung

Und so sieht das aus. Und mit diesen Quadranten kam herr snowden am ende heraus Er sagt: Manager nehmen ihre Arbeitswelt als komplex, kompliziert, chaotisch oder einfach wahr. Und je nach Wahrnehmung agieren sie anders.

Einfach

Der Zusammenhang zwischen Ursache und Wirkung ist

bekannt, vorhersagbar und wiederholbar.

Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine Überraschungen zu erwarten. Ignoranz 0ter Ordnung: ich weiss alles.

Einfach

Beispiele: Email schreiben

Browser bedienen !

Es ist keine Rückfrage notwendig

Im Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oder ein zusätzliches Formular braucht Rückfragen. Für Entwickler sind E-Mail schreiben und Browser bedienen solche Tätigkeiten.

Einfach

Erkennen Kategorisieren

Reagieren

Best Practice

Ignoranz 0ter OrdnungWeil man auf bekanntem Gelände ist kommt man gut und planbar voran. Das sind genau die Tasks, die wir gut schätzen können, ohne erst groß spezifizieren und planen zu müssen. Also arbeitet man nach dem System erkennen - kategorisieren - reagieren. Das Reagieren ergibt sich zwangsläufig aus dem Kategorisieren, und es gibt eine bekannte Best Practice, wie zu reagieren ist.

Kompliziert

Ursache und Wirkung sind über Zeit und Raum getrennt,

aber nachvollziehbar und wiederholbar.

Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es ist besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable genannt, man kann es also sicher wissen, wenn man will. Hier habe ich Ignoranz erster Ordnung: ich weiss, dass ich etwas bestimmtes noch nicht weiss.

Beispiele: CRUD

Layout anpassen !

Es kann immer wie geplant umgesetzt werden.

KompliziertFür solche Tätigkeiten brauche ich spezielles Knowhow und ich muss recherchieren. Es ist die Domäne von Experten und ausgebildeten Personen. Wenn ich mich mit dem Thema auskenne, und wenn ich mich vorbereite kann ich die Aufgabe verbindlich in der erwarteten Zeit umsetzen.

Erkennen Analysieren

Reagieren

Kompliziert

Good Practice

Ignoranz 1ter OrdnungBei solchen Problemen gehe ich nach Erkennen - Analysieren - Reagieren vor. Das heisst, dass ich in Analysieren Zeit stecken muss, bevor ich reagieren kann. Und dass es keine Best Practice gibt, sondern nur gut practice - denn die konkrete Reaktion ergibt sich aus dem Vorwissen und der Analyse, und beides kann sich unterscheiden.

Chaotisch

Der Zusammenhang zwischen Ursache und Wirkung ist

nicht erkennbar.

In Chaotisch wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung. Chaotisch ist dominiert von Ignoranz dritter Ordnung, also: ich weiss nicht, was ich nicht weiss, und ich habe auch keinen Weg, mit dem ich es verlässlich herausfinde.

Beispiele: Heisenbugs

Software ohne Source !

„Hoffentlich bringt das jetzt was.“

ChaotischIn der Praxis gibt es auch regelmässig solche Situationen. Es gibt keine Sache die man tun könnte die wahrscheinlich zu einem Erfolg führt. Sondern ich probiere einfach Dinge aus und gucke, ob sie geholfen haben.

Handeln Erkennen Reagieren

ChaotischNovel Practice

Ignoranz 3ter OrdnungUnd genau so ist der Vorgehen - Ich mache etwas - quasi ohne Nachdenken zuvor - und erkenne, was es bewirkt hat, und reagiere dann darauf. Shotgun-Debugging oder Chicken Voodoo sind Antipattern in der Softwareentwicklung, die darauf basieren. Ich probiere einfach solange, bis es funktioniert.

Komplex

Im Nachhinein ist ein Zusammenhang zwischen

Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber eine

Wiederholung kann passieren.

Komplex ist gemein. Bei Komplexen Welten habe ich es mit Second Order Ignorance zu tun, also mit Unknown Unknowns. Im Nachhinein kann ich den Zusammenhang zwischen Ursache und Wirkung nachvollziehen, denn die Unknown Unknowns sind zunächst zu Known Unknowns geworden, also zu bekannten Problemen - und mit der Lösung selbst sind sie dann zu Knowns geworden. Ich kann es aber nicht vorhersagen. Denn beim nächsten Mal müssen es ganz andere Unknown Unknowns sein, denn sie sind nach Definition nicht bekannt.

Beispiele: Schachspiel

Innovative Software Komplexe Software

Ich weiß am Anfang nicht, was am Ende genau herauskommen wird.

KomplexIgnoranz 2ter OrdnungKomplexe Tätigkeiten sind unser tägliches Brot.

Einfach

Einfach

Chaotisch

Einfach

Komplex

Kompliziert

KomplexWeiss jemand, was ein komplexes System ist? Zunächst einmal besteht ein komplexes System aus mehreren Elementen. Diese Elemente selbst können ebenfalls komplex sein - aber auch einfach, kompliziert oder chaotisch. Und sie verhalten sich jeweils individuell.

Einfach

Einfach

Chaotisch

Einfach

Komplex

Kompliziert

KomplexUnd diese Elemente interagieren, sie wirken aufeinander. Die Ausgabe eines Elementes ist der Eingangskanal des anderen, beim nächsten verbraucht sie gemeinsame Ressourcen und limitiert so dessen Wirkung.

Einfach

Einfach

Chaotisch

Einfach

Komplex

Kompliziert

Komplexverstärkend

dämpfend

Diese Beziehungen können verstärkend wirken, oder auch Abschwächend. Es kann Zyklen geben, die deutlich mehr Verstärkung erzeugen. Und es gibt Schleifen. Und es gibt Schleifen, die sich verstärken und hochpendeln. Weiß jemand wie das hochpendeln genannt wird, wenn mit sehr wenig Input ein sehr grosser Effekt erzielt wird?

KomplexGenau, das ist ein Schmetterlingseffekt. Mit sehr wenig Ressourceneinsatz - zB dem Flügelschlag eines Schmetterlings - werden woanders auf der Welt Wirbelstürme in Gang gebracht.

KomplexWir in der IT sind eher für den umgekehrten Schmetterlingseffekt bekannt. Wir setzen endlos viele Ressourcen ein, und am Ende gibt es nur ganz wenig Effekt.

Einfach

Einfach

Chaotisch

Einfach

Komplex

Kompliziert

Komplexverstärkend

dämpfend

Und natürlich kommen auch noch äussere Einflüsse dazu, und auch diese können wieder bidirektional sein, und auch dort können sich wieder Schleifen ergeben.

Ein klassisches Beispiel für ein Komplexes Adaptives System ist eine Ameisenkolonie. Die einzelne Ameise versteht nicht die ganze Kolonie, und kann auch nicht einordnen, welche Rolle sie im Gesamtsystem spielt. Faktisch hat so einen Ameise nur einige wenige Sensoren und einige wenige Regeln, nach denen sie ihr Verhalten ausrichtet. Trotzdem kommen Ameisenhaufen zustanden. Weil die Königin das steuert? Nein :-)

Team

Scrummaster

Product Owner

Senior Dev

Junior Dev

QA

User Experience

In einem Softwareteam agieren die Parteien autonom. Niemand hat das Gesamtbild, aber als Team kann man die Gesamtsituation beurteilen und damit arbeiten, und am Ende kommt eine Software heraus.

#

$

%

&

'

(Workflow Engine

ORM

User Management

Business Objects

E-Commerce-Module

SoftwareWeb Frontend

Auch Software selbst ist ein komplexes System. Gerade in der Entwicklung, wenn noch nicht klar ist, wie alle Teile genau aussehen könen bzw welche Konsequenzen die Interaktionen haben.

Software

„When we created Scrum we did not talk about Lean,

we talked about complex adaptive systems.“

Jeff Sutherland

Die ganze agile Welt basiert auf diesem Verständnis der Softwarewelt. Jeff Sutherland, der Erfinder von Scrum, hat das in Scrum zu einer Zeit diskutiert bevor Scrum selbst als Bezeichnung dafür existierte.

Im Nachhinein ist ein Zusammenhang zwischen

Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber eine

Wiederholung kann passieren.

Und wenn man sowas vor Augen hat ist auch das Verhalten plausibel: Wenn ich ein Team wieder so zusammen an ein neues Projekt setzte, kann ein ganz anderes Ergebnis herauskommen. Wenn ich die gleiche Architektur für eine andere Lösung einsetze kann sie funktionieren, muss aber nicht. Sogar im gleichen System muss es nicht mehr funktionieren, weil es sich selbst schon bewegt hat.

Im Nachhinein ist ein Zusammenhang zwischen

Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber

eine Wiederholung kann passieren.

Was ist der richtige Prozess?

Aber dann stellt sich die Frage - was ist denn dann der richtige Prozess? Wenn ich nicht vorhersehen kann was passiert, und Ursache und Wirkung nicht klar sind, wie soll ich dann vorgehen?

Im Nachhinein ist ein Zusammenhang zwischen

Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber

eine Wiederholung kann passieren.

Ausprobieren!Genau, ich muss es ausprobieren. In dem Moment wo ich mit dem System arbeite habe ich Feedback aus dem System, und ich kann an der Wirkung erkennen welche Ursachen es hatte. Und damit vorhersagen über die Zukunft treffen. Die eintreffen können - oder auch nicht.

Probieren Erkennen Reagieren

Emergente Praktiken

KomplexKonkret führt also kein anderer Weg um das Anfangen herum, und erst im Verlauf der Arbeit sammle ich Erfahrungen welche Ursachen welche Wirkungen haben. Wenn ich erkannt habe dass eine Ursache eine bestimmte Wirkung hatte nutze ich sie als Reaktion immer dann, wenn ich diese Wirkung brauche. Und auf diese Weise ergeben sich emergente Praktiken, mit denen ich einen gewünschten Effekt erreichen kann.

KomplexKennt jemand das Kürzel PDCA? Genau, das ist der Deming-Circle aus dem LEAN-Umfeld. Bei ihm handelt es sich um eine Abwandlung von Probieren - erkennen - reagieren. Lean ist - wie die agilen Methoden - ein Toolset das in der Lage ist komplexe Umgebungen zu beherrschen.

Emergente Praktiken

Komplex

Ich habe durch Probieren gelernt, dass B rauskommt wenn ich A mache.

Und wenn ich eine Weile mit so einem komplexen System arbeite sammle ich immer mehr solche Praktiken. Ich kenne nicht alle Zusammenhänge warum das so ist, aber ich weiss aus meiner Erfahrung, dass es statistisch häufig passiert.

Emergente Praktiken

Komplex

Ich habe durch Probieren gelernt, dass gute Qualität rauskommt wenn ich Tests als erstes mache.

Ein Beispiel für so eine emergente Praxis ist zum Beispiel Test Driven Development.

Emergente Praktiken

Komplex

Ich habe durch Probieren gelernt, dass mehr Code rauskommt wenn ich Pair Programming mache.

Oder Pair Programming. Was mache ich, wenn ich sehe, dass die Performance nicht höher ist? Genau, ich mache es nicht.

Komplex

Wenn etwas in 75% der Fälle geholfen hat, werde ich es auch

weiterhin machen.

Oder Pair Programming. Was mache ich, wenn ich sehe, dass die Performance nicht höher ist? Genau, ich mache es nicht.

Continuous Integration Daily Scrum

Sustainable Pace Collective Code Ownership

Story Points Retrospectives

Osmotic Communication Slack Time

!Und genau diese agilen Prinzipien sind emergente Praktiken. Dinge von denen man mal gemerkt hat, dass Software häufig, nicht immer, besser funktioniert wenn man sie macht.

Komplex

Wie nennt man das, wenn ein Team

seinen Prozess selbst entwickelt?

Und was passiert, wenn die Minions selbst Dinge probieren, erkennen und darauf reagieren, um herauszufinden welche Praktiken funktionieren und welche nicht?

Selbst-organisation

Komplex

Probieren Erkennen Reagieren

Genau, das Resultat ist Selbstorganisation. Muss man das als Scrum einführen? Nein, der Zyklus Probieren->Erkennen->Reagieren ergibt schon aus sich heraus Selbstorganisation. Fremdorganisation ist gar nicht möglich. Oder, um mit der Systemtheorie zu sprechen: Selbstorganisation ist das spontane Auftreten neuer, stabiler, effizient erscheinender Strukturen und Verhaltensweisen (Musterbildung) in offenen Systemen.

Komplex

The best architectures, requirements, and designs

emerge

from self-organizing teams.

Die komplette agile Entwicklung basiert auf emergenten Praktiken, das ist insbesondere im agilen Manifest zu finden.

Komplex

Agil ist eine Antwort auf komplexe Aufgaben

Selbstorganisation Lernschleifen

Emergente Praktiken

Und da sind wir eigentlich beim Punkt von Agil. Agil ist schlicht ein Methodenset zur Bearbeitung von komplexen Aufgaben. Alle 3 Teile: Selbstorganisation, Lernschleifen und Emergente Praktiken sind fixe Bestandteile komplexer adaptiver Systeme.

„Insanity: doing the same thing over and over again and expecting different results.“

Und das ist gemein, was das schlicht unser normaler Wissen ausser Kraft setzt. In komplexen Systemen erwarten wir unterschiedliche Resultate, wenn wir mehrfach das gleiche machen.

„You can‘t control what you can‘t measure.“

Tom DeMarcoAuch dieser Ausspruch von Tom DeMarco gilt nicht. Ich kann in einem komplexen System zwar messen, aber ich kann deshalb noch lange nicht kontrollieren.

„You can‘t control what you can‘t measure.“

Tom DeMarcoIn komplexen Systemen bleibt da nur noch „You can’t control“ übrig. Es geht schlicht nicht mehr. Das hat er irgendwann selbst gemerkt, und den Satz daher wieder zurückgenommen.

Emergente Prozesse funktionieren oft, nicht immer

Story Points Avg Hours

1 21

2 52

3 64

5 100

8 111

Velocity Hours

8+8=16111+111=

222

5+3+2+2+2+1+1=16

100+64+52+52+52+21+21=

365

Mike Cohn hat sich mal die Mühe gemacht mittlere Zeiten für Story Points zu ermitteln. Wenn ich die durchschnittlichen Zeiten von Story Points nehme und addiere komme ich auf eine Summe, die aller Statistik nach nicht das gleiche Aussagen kann. Wenn ich eine normale Anzahl Stories über mehr als 10 Sprints nehme gibt mir die Velocity trotzdem mehr Aufschluß über Team-Performance und Releaseplanung als Alternativen.

Komplex Kompliziert

Chaotisch Einfach

Verwirrung

Probieren Erkennen Reagieren

Erkennen Analysieren Reagieren

Handeln Erkennen Reagieren

Erkennen Beurteilen Reagieren

Und jetzt kommen wir zu dem Punkt, wo die meisten Management-Probleme herkommen. Wenn ich nicht weiss, in welchem Quadranten ich arbeite, dann bin ich in der Mitte - in der Verwirrung. Und in dem Fall wird auf den Quadranten zurückgegriffen, in dem man sich am sichersten fühlt.

Methoden aus dem falschen Quadranten.

Verwirrung

Genau diese Verwirrung ist die Quelle der meisten Probleme von IT und Management.

Methoden aus dem falschen Quadranten.

IT ist meistens komplex.

Bei IT-Projekten sind meistens die komplexen Eigenschaften dominant. Das gilt längst nicht für alle IT - die zwölfte CMS-Seite auf der gleichen Basis ist eher einfach, eine Motorsteuerung kompliziert, und im Agenturbereich kurz vor der Messe wird es eher chaotisch.

einfach schwierig

Un

klar

Kla

r

An

ford

eru

ng

Lösung

Einfach

Kompli ziert

Komplex

Chaotisch

Netterweise gibt das Cynefin-Umfeld mit dem Stacey-Diagramm eine einfache Orientierung. Es hat zwei Achsen, die das Problem zu Projektbeginn beschreiben - die eine ist die Klarheit und das Verständnis des Problems, die andere die Klarheit und das Verständnis der Lösung. Bei einem normalen Projekt sind beide zwar nicht 100% unklar, aber eben auch nicht 100% klar. Und weil sie sich aufeinander beziehen ändert die Anforderung die Lösung und diese dann wieder die Anforderung. Also normales komplexes Verhalten.

„Pairprogramming ist langsam.“ „TDD ist Zeitverschwendung.“ „Refactoring ist Fehlerbehebung.“ „Scrum sind viele unnötige Meetings“ !

!

Einfache Wahrnehmung

Wenn ich zum Beispiel einen Manager habe, der sich im einfachen Quadranten wähnt, dann möchte er ohne grosse Analyse zum richtigen kommen. Die Praktiken der Entwickler irritieren ihn. Pairprogramming kann gar nicht schneller sein, egal was die Statistik sagt, und TDD ist Zeitverschwendung. Mit Refactoring versucht man nur frühere Inkompetenz zu korrigieren, und Scrum meetet sich zu Tode.

Standardprozesse Handlungsanweisungen Checklisten Protokollierte Verfahren Baukastensysteme Developer sind frei beweglich

EinfachErkennen Beurteilen Reagieren Best Practice

Er sieht erheblich lieber einfache best Practices, und möchte die verlässlich etabliert haben. Deshalb findet er Standardprozesse, erarbeitet Handlungsanweisungen, Checklisten. Er protokolliert gerne Verfahren, damit sie später nur durch Abtippen wiederholt werden können. Er mag Baukastensysteme und erwartet massive Zeiteinsparungen daraus. Entwickler können spontan Projekte wechseln und mehrere Projekte gleichzeitig bearbeiten.

Autoritäres Management Micromanagement Mushroom Management Cargo Cult Golden Hammer Syndrome

Einfach dysfunktional

Im Resultat führt er die Entwickler über Autoritäres Management, steuert auch gerne mal direkt. Er macht Mushroom-Management: die Developer werden im Dunkeln gelassen und bekommen nur Mist vorgesetzt. Wenn agile Methoden kommen dann als Cargo-Cult: er liest über sie im Flugzeit und ordnet in der nächste Woche an, dass ab jetzt Pair Programming / Kanban / Domain Driven Design gemacht wird. Er bevorzugt Lösungen die einfach für alles taugen.

Agil ist unverlässlich. Es fehlt ein detaillierter Plan. Es fehlt klare Verantwortung. Agil ist eine Wohlfühlveranstaltung. !

!

Komplizierte Wahrnehmung

Der komplizierte Manager rechnet nicht mit einfachen Lösungen, ganz im Gegenteil. Resultate sind das Produkt von Planung, Kompetenz und Disziplin. Ohne diese kann es keine Resultate geben, also ist agil selbst unverlässlich, weil es die Methoden nicht bietet. Ohne Plan, ohne klar verteilte Hüte kann das nicht funktionieren. Und die Meetings mit permanenter Ausleuchtung von allem sind nicht Zielorientiert und kümmern sich offensichtlich um Befindlichkeiten, nicht um Fakten.

Lastenheft/Pflichtenheft Klare Prozesse Architekten & Gremien Meilensteinplan & GANTT-Pläne Verträge & Dokumentation Klare Verantwortung Ziele & Prämien

KompliziertErkennen Analysieren Reagieren Good Practice

Weil er im komplizierten Zuhause ist nutzt er er gerne professionelle Verfahren, die eine gewisse logische Tiefe mitbringen. Eine detaillierte Analyse ist auf allen Ebenen genauso wichtig wie eine detaillierte verlässliche Planung. Gut ausgebildete Leute entscheiden und haben die Verantwortung, und das Ziel wird wie geplant erreicht - wenn nicht jemand auf dem Weg versagte.

Transaktionales Management (MbO) Grosse, bekannte Prozesse Death by Planning Architects Don’t Code Blamestorming Fear of Success

Kompliziert dysfunktional

Die Dysfunktionen sind dementsprechend auch weniger offensichtlich kaputt, sondern benötigen erhebliches Nachdenken. Transnationales Management - also Zielvereinbarungen und Bonus - funktionieren nur in einer Ursache-Wirkung-Welt, und laufen in einer komplexen immer auf einen Kuhhandel zur Bonusermittlung hinaus. Planung und Prozesse werden wie XML und Gewalt eingesetzt: wenn es nicht funktioniert hat mehr davon! Bei Ihnen übernehmen Architekten, Gremien und Planer die Verantwortung, und die anderen haben sich danach zu richten, deshalb sollen die Architekten auch nicht mitprogrammieren. Bei Fehlern muss jemand etwas falsch gemacht haben, aber irgendwie landet man nie bei einer klaren Verantwortung - nicht verwunderlich, denn im komplexen gibt es keine klare Kopplung zwischen Ursache und Wirkung. !http://c2.com/cgi/wiki?DeathByPlanning http://c2.com/cgi/wiki?FearOfSuccess

?Schön und gut, aber wie erkläre ich ihm das jetzt?

Jetzt weiß ich zwar warum mein Manager es nicht versteht, aber das hilft mir nichts - denn ich kann ihm das nicht erklären. Und wäre ich jetzt ein Consultant würde ich sagen: „Kaufen sie mich ein, ich erkläre das dann.“ - aber ich bin keiner. Also Dinge, die in der Praxis tatsächlich funktioniert haben.

!Oberhalb des Radars

Es gibt in der Praxis zwei Wege, einen oberhalb des Radars und einen unterhalb des Radars. Beide sind ein wenig gemogelt, aber man muss dem Management ja auch Gelegenheit geben, mit den neuen Gegebenheiten zurechtzukommen. Und diese Zeit will nicht verschwendet sein.

Rettungs — Projekte

Der Klassiker unter der Einführung agiler Methoden - Projekte, bei denen andere Methoden schon versagt haben. Warum eignen sie sich besser? Zunächst einmal erwartet niemand, dass es von Anfang an alles gut ist. Zum anderen ist in solchen Projektphasen der Grad an Komplexität noch einmal deutlich höher, deshalb bringen agile Methoden hier oft überraschend gute Ergebnisse.

Leuchtturm- Projekte

Das ist die zweite Methode. Ich mache Leuchtturmprojekte. Das ist etwas weniger elegant als ein Rettungsprojekt, weil es sich meistens um kleine Projekte mit überschaubarem Risiko und einer Flexibilitätsanforderung handelt.

100% Managementsupport Managementeinbeziehung

Die agilen Coaches empfehlen in solchen Fällen immer 100% Managementsupport, vermutlich weil die auch über ihr Budget entscheiden. Viel wichtiger ist aber tatsächlich das geduldige Einbeziehen des Managements, damit die durch Teilnahme ein Gefühl dafür gewinnen, wie und warum agil funktioniert.

• Agil initiert durch Development • abgesprochen mit Management • mit internem Coach

Optimal

Optimal läuft es wenn es aus der Entwicklung kommt und dort getragen wird - wenn dort kein Support vorhanden ist brauche ich noch kein Projekt zu machen. Es sollte mit dem Management abgesprochen sein, und wie schon genannt mit viel Kommunikation passieren. Und am besten ist es wenn ich dem Management einen internen Coach zur Verfügung stelle, der sowohl die Unternehmenskultur als auch agile Hintergründe versteht.

!Unterhalb des RadarsUnd jetzt wieder zurück zur Realität: unterhalb des Radars.

U-Boot— Projekte

Ich mache ein Projekt einfach intern agil, und emuliere nach aussen das offiziell gängige Projektverfahren. Ich kenne große Unternehmen, die agil im Projekt arbeiten und nach aussen einen Meilensteinplan mit 218 Zielen kommunizieren. Und alle zwei Wochen ändern sich die Ziele, die in den Meilensteinen enthalten sein werden. Und was ist, wenn ich gar kein Projekt habe?

Emergente Praktiken

Komplex

Ich habe durch Probieren gelernt, dass B rauskommt wenn ich A mache.

Dann probiere ich die Praktiken schlicht trotzdem aus.

Um so weiter weg ein Manager

von agilen Praktiken ist, um so mehr Platz

ist unter seinem Radar.

Glücklicherweise gilt oft die Faustregel, dass unter dem Radar von Managern die mit agil wenig am Hut haben - zumindest wenn sie nicht die unmittelbaren Vorgesetzten sind oder nicht so gut in Micromanagement.

klein hoch

ho

chkl

ein

Ben

efit

Risiko / Kosten

• Scrum Master Role

• Retrospectives

• Continuous Integration

• Test Driven Development

• Pair Programming• KanBan

Wir machen solche Dinge gerne über ein einfaches Kosten-Benefit-Diagramm: wir scoren die Methoden in Risiko und Benefit, und machen die mit hohem Benefit und kleinem Risiko. Und wann komm ich wieder über den Radar?

Resultate

Sobald ich Resultate habe. Resultate funktionieren in allen Quadranten, das ist die eine Währung, die jeder Manager spricht.

Für gute Manager, die ein offenes Ohr, Hirn und Herz haben gibt es glücklicherweise auch einige Managementmethoden, die für komplexe Aufgabenstellung taugen. Insbesondere erfreut sich Management 3.0 hier einiger Beliebtheit, das nicht nur ein Buch, sondern auch einige Werkzeuge und vor allem Kurse anbietet. Das kann ich tatsächlich empfehlen. Generell würde jedes Management, das unter den Oberbegriff der Transformationen Führung fällt helfen- nur leider gibt es davon noch nicht so viele einfach handhabbare Quellen. Radical Management geht ebenfalls in eine ähnliche Richtung, hat aber nie wirklich in Europa abgehoben.

For every complex problem there is an answer that is clear, simple and wrong.

H.L. Mencken

By 2016, the Cynefin Framework will be used in 10% of IT operations organizations as a

sensemaking methodology. Gartner Group 2012

Slides mit Volltext: http://slideshare.net/johannhartmann/

Gute Fragen: @johannhartmann

Andere Fragen: hartmann@mayflower.de

Danke!

Links: !

Cynefin allgemein: http://cognitive-edge.com/blog/entry/5855/cynefin-papers-a-summary/

Cynefin für Entwickler: http://lizkeogh.com/2012/03/11/cynefin-for-devs/

Kleine Teams vs grosse Teams http://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-

than-large-teams/ Agile Methoden empirisch betrachtet:

http://www.amazon.com/Business-Value-Agile-Software-Methods/dp/1604270314 http://davidfrico.com/agile-book.htm

Five Orders of Ignorance http://www-plan.cs.colorado.edu/diwan/3308-s10/p17-armour.pdf

The Waterfall Accident http://pascal.gugenberger.net/thoughts/waterfall-accident.html

Productivity vs Overhours http://lunar.lostgarden.com/Rules%20of%20Productivity.pptx