Die Diskussion über New Work findet meist entlang der Perks und der Autonomie der Kollegen statt. Aber lässt sich damit alleine Effizienz, Effektivität, Innovation und Adaptionsfähigkeit verbessern? Wie aligne ich die Firma, wenn die Kollegen und ihre Teams autonom arbeiten? Muss ich meine Organisationsform ändern? Scheitere ich an meiner Firmenkultur oder meinen Managern? Ein Bericht aus zehn Jahren Theorie und eigener Praxis.

1. 10 Jahre „NewWork“
in Theorie und Praxis
Willkommen zum Talk über 10 Jahre NewWork in Theorie und Praxis. Wie man an dem Bild schon erkennen kann, geht es mir hier nicht um einen heroischen Vortrag, bei
dem wir stolz über unsere Erfolge und Erfolgsrezepte reden. Hey, wir machen IT, da gibt es das gar nicht.

2. $ Beratung
Coaching
Strategie
Workshops
Inzwischen treiben sich sehr viele Leute auf dem Feld NewWork herum, und bieten Beratung an, sie bieten Coaching an, am liebsten Strategiecoaching, weil man da
direkt mit der Leitung reden kann, Workshops zu allen Themen von Holacracy bis Management 3.0, über agile Führung und future Leadership. Denn damit kann man
heute Geld verdienen. Da liegt also was in der Luft.
Die Leute, die das anbieten, sind selbst aber gar nicht von Geld motiviert, sondern von der tiefen Überzeugung, bessere Varianten von Arbeit und Unternehmertun zu
kennen, die sie gerne zu Wirklichkeit werden lassen wollen. In fremden Unternehmen :-)

3. $ Beratung
Coaching
Strategie
Workshops
Ich selbst verdiene damit leider kein Geld, das Geldverdienen machen die Kollegen in meiner Firma mit richtiger Arbeit, die entwickeln Software. Wir dürfen zwar
inzwischen sehr regelmässig Vorträge und Workshops zu diesen Themen halten, bekommen aber im Gegensatz zu den oben genannten Consultants und Coaches nie
Geld dafür, sondern müssen meist sogar etwas dafür bezahlen :-) Dafür habe ich das Recht, ehrlich zu sein.

4. New Work sind eher solche Sachen. Diese Karte ist die Tag-Cloud vom NewWork-Lexikon vom Xing-Spielraum. Und wenn man sich das so anguckt, dann sollten wir uns
tatsächlich auch damit auskennen.
Ich weiß, dass Wikipedia da einer anderen Definition folgt, nämlich der vom Frithjof Bergmann. Die ist aber für uns ITler weniger nützlich. Also nehme ich lieber das
Sammelsurium von Xing.

5. Selbstorganisation
Freiberuflichkeit
keine oder flache Hierarchien
Kollaboration
dezentrales Arbeiten
Selbstverantwortung
Social Media
Netzwerk
Jobnomaden
Vertrauen
Selbstbestimmung
Wenn ich da willkürlich Begriffe rausgreife, dann kann ich praktisch überall sagen „Ja, klar, haben wir gemacht.“.
Selbstorganisation mit völliger Eigenverantwortung. Freiberuflichkeit, das Unternehmen nach draussen ist nur noch die Marke. Es gibt gar keine Hierarchien. Es wird
dezentral gearbeitet, jeder entscheidet als Jobnomade wann und wo der sinnvollste Arbeitsort für ihn zu finden ist. Die Koordination findet vollständig über Chat und Wiki
statt, und dort finden sich lose wie feste Mitglieder des Verbundes. Alles ist selbstbestimmt, auch das Gehalt, die Position und die Aufgaben. Und wie funktioniert das
alles? Mit Vertrauen, klar.
Wenn sich jemand damit auskennt, dann also wir. Also sollten wir tatsächlich auch einen Vortrag darüber machen.

6. Das ist 15 Jahre her.
4-7 Freelancer
1 GmbH
Der Haken an der Geschichte: das ist 15 Jahre her. Konkret: als das Unternehmen so aussah, da war Gerhard Schröder Bundeskanzler und Wikipedia noch nicht
gegründet. Da waren wir - je nach Betrachtungsweise - faktisch 4-7 Freelancer mit einem GmbH-Mantel.

7. Selbstorganisation
Freiberuflichkeit
keine oder flache Hierarchien
Kollaboration
dezentrales Arbeiten
Selbstverantwortung
Social Media
Netzwerk
Jobnomaden
Vertrauen
Selbstbestimmung
Und faktisch war damals gar nichts NewWork, sondern schlicht alles lose organisiert.
Und faktisch war das nicht Selbstorganisation, sondern die Abwesenheit von höherer Organisation, die Abwesenheit von Firma, die Abwesenheit von Hierarchie, die
Abwesenheit von zentraler Verantwortung, die Abwesenheit von zentraler Bestimmung.
Das war kein super-Masterplan, das ist einfach nur passiert, weil die Beteiligten nicht dumm waren.

8. New-Work-Learning 1
Wenn es mit 10 Leuten gut & agil
funktioniert, dann liegt das
an den guten Leuten, nicht an der
brillanten Organisationsform.
Und da sind wir schon beim ersten Learning zu New Work, das ich gemacht habe. Alles unter 40-50 Leute bekommt man noch hin, ohne dass man einen brillanten Plan
braucht.
Wenn ich doch einen brillanten Plan habe, dann funktioniert der Laden _trotz_ meines brillanten Plans, weil da gute Leute sind. Die machen, dass es funktioniert, nicht
meine Organisationsstruktur.

9. Ja, ich rede über Dich, Holacracy.
Warum ich das extra erwähne - weil Holacracy in der eigenen Geschichte gerne die Ternary Software Incorporated erwähnt, bei der Holacracy als Mischung von
Soziokratie und Scrum entstand - die Firma war nämlich nicht grösser.
Ich habe tatsächlich schon mit Leuten zu tun gehabt, die Holacracy mit 2 Freelancer gemacht haben.

10. 2001ff
Büros
Abteilungen
Teams
- Leitungen
Hierarchie
Karrierepfade
Bonussystem
Standardprozesse
Jetzt neu!
Mit „professionell“!
Aber während die Jungs von Holacracy immerhin rechtzeitig gemerkt haben, dass vieles nicht gut mit Software funktioniert, haben wir das gemacht, was alle machen.
Wir haben eine „richtige“ Firma aufgebaut.
Und schwups hatten wir feste Arbeitsplätze in echten Büros, wir hatten Teams und Abteilungen, wir hatten eine funktionale Organisation und eine Hierarchie, in der man
Karriere machen konnte. Und damit wahlweise Teamleiter oder Abteilungsleiter werden. Und natürlich hatten wir ein Bonussystem, um die Kollegen noch über das Gehalt
hinaus zu motivieren.
Wir haben uns selbst eine Dilbert-Welt gebaut.

11. Erfolg!
Weil wir es so wie alle machen.
Esst mehr Mist!
Tausende von
Fliegen können
nicht irren!
Und tatsächlich hat das geklappt, das Unternehmen wuchs und gedieh.
Und wir wussten natürlich, woran das liegt: nämlich an unserer Professionalität. Und ausserdem: alle anderen machen es auch so, es muss also gut sein.

12. Inzwischen machen wir wieder einen ganzen Stapel von diesen Dingen, und werden bei intrinsify.me sogar zusammen mit ein paar wirklich coolen Firmen wie DarkHorse,
elbdudler, it-agile, oose und wibas gelistet. Die sind erwiesenermassen schlauer als wir, aber immerhin, wir sind auch auf der Liste.

13. Ok, wenn das doch
vorher schon super war,
warum macht Ihr heute
NewWork-Sachen?
Weil Hipster oder so?
Da stellt sich natürlich die Frage - warum macht Ihr heute so viel Kram mit NewWork? Marketing? Hipster-Status? Consulting verkaufen?

14. Das ist uns passiert.
Ehrliche Antwort: das ist uns so passiert. Da gab es keinen Masterplan und keine Super-Entscheidung dahinter.

15. 2005
Geschäftsführungsentscheidung:
Neuer Standardprozess: SCRUM.
Und so fing das an.
Wir haben schon immer viel und gerne mit MySQL - heute MariaDB zusammengearbeitet. Die haben 2003 Scrum eingeführt. Und wir dachten so: klingt cool. Wollen wir
auch. Weil: professionell. Und weil wir inzwischen ja unsere selbstgebaute Dilbert-Welt hatten, haben wir Scrum auch nach Dilbert-Regeln eingeführt.

16. 2005
Strategiedokument
Workshop allen
Führungskräften
Natürlich gab es ein Strategiedokument dazu, und es wurde den Team- und Abteilungsleitern vorgestellt. Und die bekamen als Ziel, überall Scrum einzuführen.

17. 2006
Alle Teamleiter und Geschäftsführer
werden zu Scrum-Mastern
ausgebildet.
Im Ernst.
Was für Idioten wir
doch waren.
Und um ganz auf Nummer sicher zu gehen wurden auch noch mal alle Teamleiter und Geschäftsführer - bitte nicht lachen - zu Scrum-Mastern ausgebildet.

18. Jeder von Euch hier kennt vermutlich die Seite mit dem schlimmstdenkbaren Videofilter-Hintergrundbild, agilemanifesto.org. Da steht eigentlich eine ganz nette
Formulierung, nämlich, dass man Kooperieren soll, dass man sich an laufender Software lang bewegen soll, dass man Zusammenarbeiten soll und Änderungen
willkommen heissen soll.
Das klingt, wenn man länger Software entwickelt, alles ganz plausibel. Deshalb mögen wir Softwareentwickler ja auch meist die Grundidee.

19. Zeitraum zwischen dem ersten Vortrag
und dem Verstehen von diesen 4 Punkten:
7 Jahre.
Meinen ersten Vortrag über agile Methoden habe ich im Jahr 2006 gehalten. Da haben wir selbst schon Scrum, Extreme Programming und Teile von Crystal Clear
eingesetzt. Und trotzdem habe ich danach noch 7 Jahre gebraucht um zu verstehen, warum die Individuen und Interaktion, warum die Working Software,
Zusammenarbeit mit dem Kunden und Reaktion auf Änderung in den Vordergrund stellen.

20. AGIL VERSTEHEN HEISST
NEW WORK VERSTEHEN
Jetzt muss ich einmal ausholen, aber es ist wichtig um die betriebswirtschaftlichen Motivationen hinter New Work greifbar zu bekommen. Und das geht leider nicht ohne
etwas Theorie. Deshalb : seien sie bitte geduldig mit mir, ohne kann ich es einfach nicht erklären.

21. Komplexität
Der erste Grund ist Komplexität - das sollte inzwischen jedem hier untergekommen sein.
Wer kennt das Cynefin Framework? Genau. Ich gehe für die wenigen, die es noch nicht kennen, trotzdem noch mal über das Thema - schlicht weil es zum Verständnis
von New Work notwendig ist.

22. Kompliziert
Ich weiß, was ich nicht weiß.
Und ich kann es recherchieren.
Komplizierte Dinge kennen wir alle - von Mathearbeiten bis zu Kreuzworträtseln. Wir wissen ziemlich genau, welche Informationen uns noch fehlen, und wenn wir genug
Zeit investieren, dann bekommen wir auch raus, was wir wissen müssen. Auch wenn die Zeit für die Mathearbeit oder unsere Geduld gelegentlich vorher schon
aufgebraucht ist.

23. Komplexität
Da, wo die unbekannten
Unbekannten wohnen.
Bei Komplexität sieht das anders aus - da können wir nicht alles im Vorhinein wissen, denn es gibt unbekannte Unbekannte - Dinge von denen wir noch nicht wissen,
dass wir sie noch nicht wissen. Auch wenn wir noch so viel recherchieren.

24. Komplexität
Unbekannte Unbekannte:
fehlerhafte Dokumentation,
reales Nutzerverhalten
Typische Beispiele dafür sind fehlerhafte Dokumentation, neue Bugs, das wirkliche Nutzerverhalten bei einer innovativen Software, die Bugs, die zukünftige Updates
haben werden und vieles mehr.

25. einfach schwierig
UnklarKlar
Anforderung
Lösung
Landscape Stacey Diagram
Offensichtlich
In unsere Welt hilft das Stacey-Chart dabei, die Art unserer Projekte zu greifen, indem man sowohl Anforderungen als auch die Lösungsansätze klassifiziert. Wenn ich
sowohl die Anforderungen als auch die Lösungen gut verstanden habe, dann habe ich es mit einem einfachen problem zu tun - und es ist fast egal, wie ich vorgehe.

26. einfach schwierig
UnklarKlar
Anforderung
Lösung
Landscape Stacey Diagram
Komplex
Das sieht anders aus, wenn sowohl die Anforderung als auch die Lösung unklar ist. Wenn ich dort mit der Klärung beginne hat das immer Wirkung auf die andere Achse.
Wenn ich mich auf eine bestimmte Nutzerinteraktion festlege, dann kann ich zB nur noch die JavaScript-Libraries einsetzen, die das erlauben. Und das hat wiederum
eine Folge auf andere Anforderungen, die bei dieser Library eben auf eine bestimmte Art implementiert sind.

27. Komplexe
Welten
Man kann sie nicht
vollständig im Vorhinein
beschreiben
Pflichtenheft?
Standardprozess?
Bonusziel?
Als Folge kann ich meine Aufgabe nicht vorher beschreiben. Weil ich eben nicht weiß, was mir noch fehlt. Dinge wie Pflichtenhefte, wie Standardprozesse, wie Bonusziele
können damit nicht funktionieren. Weil die nicht für die Probleme gemacht sind, von denen ich noch gar nicht weiß, dass ich sie haben werden.

28. Bei der Umsetzung werden aus
unbekannten Unbekannten
bekannte Unbekannte.
Und wie gehe ich damit um? Ich beginne einfach mit der Arbeit. Wenn ich nämlich zu Arbeiten beginne finde ich heraus, was ich nicht wusste. Welche Library funktioniert,
welche nicht funktioniert. Welche Dokumentation stimmte, welche Fehler enthielt. Welche Bugs die Komponenten haben, mit denen ich umgehen muss.

29. Probieren.
Erkennen.
Reagieren.
Komplexe
Welten
In Cynefin heisst die Strategie in komplexen Systemen deshalb Probieren - erkennen - reagieren. Der Deming-Cycle - Plan-Do-Check-Act ist zB eine Ausprägung von so
einer Strategie.

30. Ich lerne kontinuierlich Dinge, von denen ich
noch nicht wissen konnte.
Und genau deshalb gibt es diese beiden Werte in agiler Softwareentwicklung. Das Erzeugen von echter Software sorgt dafür, dass ich meine unbekannten Unbekannten
zu bekannten Unbekannten mache, und sie damit tatsächlich bearbeiten kann. Und damit ändern sich zwangsläufig meine Annahmen - denn jetzt weiß ich ja, was ich
nicht weiß, und muss dieses Wissen einbeziehen. Damit lerne ich kontinuierlich, was ich bislang noch nicht wusste. Und nicht nur ich, sondern auch meine Kunden.

31. Kontinuierlich Lernen
Meine alten Annahmen
stimmen nicht mehr.
Meine alten Methoden
passen nicht mehr.
Und so gut kontinuierlich Lernen auf den erste Blick klingt, so unpraktisch ist es dann doch in der Realität.

32. Kontinuierlich Lernen
Unsere mentalen Modelle werden
kontinuierlich refactored.
Unser Gehirn hatte sich nämlich ganz wohnlich bei unserem Problem eingerichtet, und sich mehrere kleinere Modelle der Realität gebaut, um mit unserem Projekt
umgehen zu können.

33. Mentale Modelle
Object-Action-Model
GET /user/12
Use Case mit
Scribbles
Zum Beispiel haben wir ein Object-Action-Modell. Wenn ich zur Glocke greife und sie schüttele, dann gibt es einen Ton. Wenn ich den Namen zu einer Nutzer-ID 12
haben will, dann rufe ich den User-Mikroservice mit dem Parameter 12 auf.
Wer benutzt StackOverflow? Die typische Copy & Paste-Programmierung auf Basis von Stackoverflow ist ein Beispiel für Object-Action.
Oder, wenn ich auf die Nutzerseite schaue, ein detaillierter Use-Case mit Scribbles. Ich habe es richtig implementiert, wenn es das macht, was dort angefordert wurde.

34. Mentale Modelle
Mapping Models
GET /user/…
GET /product/…
GET /cart/…
User-Journey
Wenn ich nicht nur das eine Objekt mit der einen Karte verstehe, sondern mir ein detailliertes Bild über meine Applikation gemacht habe nutzt mein Hirn ein Mapping-
Model. Ich weiß jetzt, dass es nicht nur einen User-Service, sondern auch einen Service für die Produktdaten oder meinen Warenkorb gibt. In Requirements gesprochen
würde ich hier verstehen, wie sich der Nutzer durch die Applikation bewegt.

35. Mentale Modelle
State-Transition-Model
GET /user/[1-6]
Persona & Goals
Wenn ich mich noch länger mit dem Thema auseinandersetze, dann bekomme ich ein State Transition Model - ich beginne zu verstehen, wie das Ding, das ich nutze, im
inneren funktioniert und welche Zustände es hat. Ich mache zB Bulk-Requests auf den Microservice, weil ich ihn nicht überlasten will. Ich biete dem Nutzer
Komfortfunktionen an, mit denen er nicht gerechnet hat, und trotzdem davon begeistert ist - weil es seinen Beweggründen entgegen kommt.

36. Neuer Code
Bestehenden Code ändern
Analyse von bestehendem Code
Wie wichtig diese mentalen Modelle für die Produktivität unserer Arbeit sind kann man schnell beurteilen, wenn man sich anschaut womit wir Entwickler unsere Zeit
verbringen - nämlich massgeblich mit dem Verstehen von bestehendem Code. Oder, besser formuliert: mit dem Aufbau mentaler Modelle.

37. Unbekannte
Unbekannte
bekannte
Unbekannte
bekannte
Unbekannte
Und genau das passiert bei agiler Softwareentwicklung - wir iterieren fröhlich vor uns hin, und realisieren bei jeder Arbeit, die wir machen, unbekannte unbekannte zu
bekannten Unbekannten - und können die dann zu bekannten machen. Und weil ich immer etwas dazulerne, wird aus mein mentales Modell immer besser.

38. Zu gross für ein Hirn
Und jetzt kommen wir zur zweiten Gemeinheit von Softwareentwicklung. Sie ist im Regelfall zu gross für ein Hirn. Das gilt schon für die Software selbst, wird aber noch
deutlicher, wenn man Bereiche wie Nutzerverhalten & Erwartungen, Qualitätssicherung, Security, Produktion, Hardwarebedarf, Interaktion mit anderen Systemen,
Skalierbarkeit oder Performance dazunimmt.

39. Geteilte Mentale Modelle
Equipment-Model
Welche Werkzeuge
nutze ich wie?
Wie mache ich Dinge
in dieser Software?
Deshalb spielen an dieser Stelle shared mental Models bei der Softwareentwicklung eine grosse Rolle. Dazu gehören die gesamten Werkzeuge, die man auf dem Weg
gemeinsam einsetzt - von den Bibliotheken zu der IDE, von der Datenbank zum Jenkins für die Integration - und natürlich auch, wie man sie einsetzt.

40. Geteilte Mentale Modelle
Task-Model
Was ist die gemeinsame Aufgabe?
Woran erkenne ich Erfolg?
Neben den Werkzeugen, die ich für meine Arbeit einsetze habe ich ein gemeinsames Verständnis über das Ziel, das ich erreichen möchte. Das findet sich im Task Model.
Besonders in komplexen Umgebungen spielt es eine wichtige Rolle, weil es den Massstab für die Adaption stellt. Ohne es wäre es nicht möglich zu beurteilen ob eine
Änderung eine Verbesserung des Erreichen des Tasks darstellen kann, und ob das Ziel überhaupt erreicht werden kann.

41. Geteilte Mentale Modelle
Team-Interaction—Model
Wer hat welche Rolle inne?
Wie kooperieren wir?
Um die Arbeit miteinander schaffen zu können benötigt man natürlich auch ein Verständnis davon, wer was macht, und wie man kooperiert. Welche Aufgaben liegen bei
welcher Person, wen spricht er wann an?

42. Geteilte Mentale Modelle
Team—Model
Wer hat welche Fähigkeiten?
Wer hat welche Interessen?
Um die Arbeit miteinander schaffen zu können benötigt man natürlich auch ein Verständnis davon, wer was macht, und wie man kooperiert. Welche Aufgaben liegen bei
welcher Person, wen spricht er wann an?

43. Equipment-Model Welche
Werkzeuge?
Retrospektive &
Daily, Pairing
Task-Model Welches Ziel? Sprint-Goal
Team-Interaction-
Model
Wer hat welche
Rolle?
Retrospektive
Team-Model Wer kann & will
was?
Retrospektive
Es ist klar, dass gemeinsame mentale Modelle nicht alleine erzeugt werden können - sie entstehe immer nur durch Kommunikation. Agile Prozesse bieten
dementsprechend Rituale, um diese Modelle zu erzeugen. Zum Beispiel in der Interaktion - mit jedem Sprint lerne ich in meinem Team-Model etwas. Zum Beispiel, dass
der neue Junior sich super mit Angular auskennt. Und im Resultat in der Retrospektive bei den nächsten Frontend-Architekturaufgaben dazugeholt wird.

44. Ok, und wie
beurteilen wir,
ob & wie
wir unsere
Modelle ändern?
?
Aber nur weil die Retrospektive die Aufgabe hat die gemeinsamen Modelle anzupassen und die Learnings zu realisieren heisst es noch nicht, dass das auch funktioniert.
Dazu brauche ich auch eine gemeinsame Interpretation der Realität, und gemeinsame Folgerungen daraus.

45. Situationsbewusstsein
Diese gemeinsame Interpretation der Realität nennt sich Situation Awareness im englischen, Situationsbewusstsein im deutschen. Wer kennt das Gleichnis von den
blinden Männern und dem Elefanten?
Ein paar blinde Männer fassen einen Elefanten an, und jeder beschreibt, was er fühlt. Einer fasst das Bein an und beschreibt es als Säule, der nächste den Schwanz, der
als Seil beschrieben wird, der nächste erkennt den Rüssel als Ast, ein weiterer den Bauch als Wand und zuletzt wird der Stosszahn als Rohr interpretiert.
Für die Informatiker unter uns: das Gleichnis ist rekursiv über Religionen, der Hinduismus, der Buddhismus und der Islam haben das gleiche Gleichnis, ziehen jedoch
völlig unterschiedliche Lehren daraus.

46. Situationsbewusstsein
1. Die Objekte in der Umgebung
werden wahrgenommen
Das, was die blinden Männer wahrnehmen, ist das Situationsbewusstsein erster Ebene: ich spüre die Wand, das Rohr, das Seil etc.

47. Situationsbewusstsein
2. Ihre Bedeutung wird verstanden
Wenn die blinden Männer sich jetzt über diese Wahrnehmungen unterhalten und herausfinden, dass es sich um einen Elefanten handelt, dann erreichen sie das
Situationsbewusstsein der Ebene 2 - sie verstehen, dass es sich um einen Elefanten handelt.

48. Situationsbewusstsein
3. Veränderungen und zukünftiger
Zustand wird für eine bestimmte
Zeit vorhergesagt
Wenn die blinden Männer jetzt noch weiter reflektieren, dann stellen sie fest, dass sie gerade einen Elefanten praktisch an allem gezogen und angefasst haben. Und dass
dies das Tier vermutlich sauer gemacht hat, und er vermutlich ziemlich sauer ist. Die Flucht vor dem wilden Elefanten wäre dann die Ebene 3 - man schliesst auf die
Zukunft und wechselt lieber den Ort.

49. Retrospektiven & SA
Setting the Stage
Gather Data Level 1
Generate Insights Level 2
Decide what to do Level 3
Closing the
Retrospective
Diese 3 Ebenen von Situationsbewusstsein finden sich genau so im 5-Schritte-Format von Retrospektiven wieder. Gather Data sammelt die Daten, Generate Insights fügt
ihnen Bedeutung bei, Decide what to do extrapoliert auf die Zukunft.

50. Ich adaptiere kontinuierlich die
gemeinsamen Modelle -
inkl. Rollen, Zielen & Methoden.
Das sind die beiden anderen Zeilen im agilen Manifest - ich fokussiere auf Individuen und ihre Interaktion, und auf Zusammenarbeit mit dem Kunden, um zum Ziel zu
kommen. Konkret: ich passe meine mentalen Modelle hinsichtlich Zielen, Aufgaben, Rollen und Methoden an.

51. Wahrnehmung der Situation
Deutung der Situation
Prognose der Situation
Schnell, adaptierbar
& maximal informiert
An Ort & Stelle
Diese mentalen Modelle baue ich an Ort und Stelle, also dort, wo die Arbeit mit der Software selbst geschieht. Dort habe ich am meisten Daten zur Verfügung, wie die
Situation aussieht. Ich kann auf der Grundlage auch die beste Deutung der Situation vornehmen. Und, im Resultat, sind meine Prognosen auf die Zukunft auch am
wirksamsten.

52. Wahrnehmung der Situation Reporting
Deutung der Situation Gemeinsam mit Teamleiter
Prognose der Situation Gemeinsam mit Teamleiter
Langsam, indirekt und
schlecht informiert.
Hierarchisch
Wenn ich das nicht an Ort und Stelle mache, sondern zB über eine klassische Hierarchie, dann sieht das ganze schlechter aus. Dann habe ich nur die individuelle
Wahrnehmung der Situation - je nach Elefantenblinden ist die Aussagekraft dort rudimentär. Mit diesen Basisinformationen wird auch die Qualität der Deutung kleiner,
und im Resultat die Qualität der Prognose. Die Dinge, die ich erwarte, treffen so nicht mehr ein.

53. Hierarchie: der Versuch, die
wichtigsten Entscheidungen am Ort
maximaler Inkompetenz zu treffen
Ursache ist
Komplexität & Dynamik,
nicht Inkompetenz
Das führt zu einem seltsamen Widerspruch:
das hierarchische Vorgehen versucht die wichtigsten Entscheidungen am Ort maximaler Inkompetenz zu treffen. Das liegt natürlich nicht an den Betroffenen selbst,
sondern an der Komplexität und der Dynamik unserer Branche.

54. New-Work-Learning 2
Entscheidungen sind keine
hierarchische Funktion.
Und eigentlich ist dieses Learning offensichtlich, aber trotzdem: wenn Entscheidungen dezentral getroffen werden, dann sind sie keine hierarchische Funktion mehr. Ok,
das ist erst mal fatal.

55. „Wenn ich alle Informationen
habe, dann kann ich doch die
Entscheidung auch
alleine treffen, oder?“
Erfahrener Senior, überall.
Weil wir Entwickler sehr schlaue Jungs sind und schon immer waren, passiert uns, und gerade den erfahrenen Seniors dementsprechend gerne so etwas.
„Können wir nicht einfach die Entscheidung treffen? Ich meine, ich weiß alles relevante, habe auch alle Leute mit Punkten befragt, das sollte ich doch jetzt alleine machen
können, oder?“

56. Ich weiß nicht,
was ich nicht weiß.
Was passiert mit
der Entscheidung,
wenn sich etwas
ändert?
In unserer Welt gibt es gleich zwei Punkte, warum man das nicht machen sollte. Der erste ist, dass wir ohnehin schon festgestellt haben, dass wir es mit unbekannten
unbekannten zu tun haben - und die kann ich nicht wissen. Etwas offensichtlich mir unbekanntes Unbekanntes sind die Dinge, von denen ich nicht weiß, dass der
Kollege sie weiß.
Der zweite verhält sich ähnlich - was passiert denn, wenn auf dem Weg so eine unbekannte Unbekannte realisiert wird? Wie ist dann die Entscheidung anzupassen? Und
wer macht das?

57. Schnell, adaptierbar
& maximal informiert
Mentale Modelle anpassen
Zielstellung anpassen Task Model
Werkzeuge anpassen Equipment Model
Aufgabenverteilung &
Kooperationsformen
Team- Interaction-Model
Team-Kompetenzen &
Entwicklung
Team-Model
Der bessere Weg ist, die gemeinsamen mentalen Modelle anzupassen. Das gilt für die Arbeitsaufgaben, für die Werkzeuge, die für Arbeitsweise und für das Wissen im
Team über das Team.

58. New-Work-Learning 3
Es geht um die Maximierung von
wirksamen mentalen Modellen bei
der Arbeit,
nicht um Partizipation. Partizipation
ist ein Outcome, kein Selbstzweck.

59. Selbstorganisation
Und wie nennt man das, wenn man an Ort und Stelle Entscheidungen trifft, die gemeinsamen Methoden und Arbeitsweisen bespricht und anpasst? Genau,
Selbstorganisation. Aber es geht noch eins weiter.

60. Vertrauen, Sinn, Weisheit der
Vielen, Selbstbestimmung
Diese Kompetenz über die gemeinsame mentale Modelle hat ein paar spannende Effekte. Weil ich weiß, dass mein Wissen mit abgebildet ist, vertraue ich dem Modell,
und den resultierenden Entscheidungen der Kollegen. Und weil ich den Kontext habe, und selbst aus das Kollegenwissen habe, kann ich auch selbstbestimmt arbeiten -
denn die nötigen Informationen stehen mir zur Verfügung.

61. Demokratie?!
Wahlen vergrössern das
gemeinsame Wissen nicht.
Wenn man eine naive Form von der Partizipation anschaut, dann erzeugt es sogar mehr Schaden als nutzen.
Wenn ich zb anonyme Wahlen im Unternehmen abhalte, dann vergrössert es das wissen nicht - wenn man mal vom Team Model absieht, bei dem man mehr über das
Stimmungsbild erfährt. Aber ich kenne die Hintergründe nicht, und es gibt keinen direkten Mechanismus, der mich dieses Wissen realisieren lässt.

62. Demokratie?!
Inkompetenz (aka: kleines mentales
Modell zum Thema X) hat den
gleichen Einfluss wie Kompetenz.
Es wird sogar noch schlimmer. Wenn jeder Kollege - unabhängig davon , welches Wissen er für ein Thema mitbringt - zu gleichen Teilen im Resultat abgebildet wird, dann
sinkt sogar die Entscheidungsqualität. Der kleinste gemeinsame

63. Gruppenentscheidungen mit
Wissenszugewinn
Konsent
/ Decider
Aber es gibt ja auch gute Wege zu Abstimmungen. Zum Beispiel Konsent. Bei Entscheidungen wird nicht mehr Ja / Nein abgestimmt, sondern es wird gefragt:
Wer ist dafür?
Wer toleriert es?
Wer ist dagegen?
Gibt es viele Dafür-Stimmen, ein paar Supporter und keinen dagegen, dann gilt die Entscheidung als angenommen. Wenn es wenige Nein-Stimmen gibt greift der
Decider Resolution Mechanismus - die Nein-Stimmen müssen anbieten, was es braucht, dass sie dabei sind. Damit wird ein Unbekannter Unbekannter - was hat ein
Kollege dagegen - explizit gemacht, und kann im Resolution Protocol zu einem Bekannten gemacht werden.

64. Planning
Poker
Gruppenentscheidungen mit
Wissenszugewinn
Ein anderes Werkzeug zur Wissensvergrösserung ist Planning Poker. Wer kennt alles Planning Poker? Mit der Frage nach dem geschätzten Aufwand bekommt man
heraus, wo grundlegend andere Hypothesen hinter eine Story vermutet werden - und die waren vorher offensichtliche Unknown Unknowns, die mit der Diskussion
erkannt und behandelt werden.

65. Abstimmungen mit
Wissensvergrösserung
Planning
Poker
Deshalb ergibt
Planning Poker
auch bei
#NoEstimates
Sinn.
Das ist eine gute Sache. Und deshalb ergibt Planning Poker sogar dann Sinn, wenn man nach NoEstimates arbeitet. Man muss bloss die Schätzungen danach
verwerfen :-)

66. New-Work-Learning 4
Wenn die gemeinsamen
mentalen Modelle gut sind,
ergeben sich überall richtige Schritte.
„Emergente Praktiken.“
Wenn ich nämlich jeweils den Kontext habe, in dem sich Dinge bewegen, warum eine Aufgabe, eine Arbeitsweise, ein Werkzeug oder die Aufgabenverteilung im Team,
dann bin ich auch selbst in der Lage, nicht nur Dinge nachzuvollziehen, sondern auch zu extrapolieren.
Ein Beispiel dafür sind emergente Praktiken. Die können sich auch dann ergeben, wenn es gar keine Retrospektive dafür gab.

67. Muss das immer sein?
Können da nicht mal
bitte schlicht Entscheider
entscheiden?
Gruppenentscheidungen mit
Wissenszugewinn
Wenn Sie sich diese Verfahren anschauen werden Sie vermutlich denken: ok, das ist ja aufwändig. Muss denn immer jeder alles Wissen? Es gibt doch auch Dinge, die
nur einmal passieren, kann man die nicht schlicht delegieren?

68. Abstimmungen ohne
Wissensvergrösserung
Konsultativer
Einzelentscheid
Klar gibt es dafür auch eine Variante, und die heisst konsultativer Einzelentscheid. Und so läuft es ab: das Thema ist zu dick, damit alle alles verstehen können, und der
Benefit der entstehenden Learnings ist zu klein, dass alle alles verstehen sollten. Also delegiert man - aber nicht an den Boss nach oben, sondern an einen geeigneten
Kandidaten. Der muss, wie ein kluger Boss es auch getan hätte, alle möglicherweise Betroffenen kennen und konsultieren, und unter Berücksichtigung allen
angesammelten Wissens eine gute Entscheidung zu treffen - oder gar keine. Die anderen akzeptieren diese Entscheidung, und vergeben dem Entscheider, wenn er nicht
in Ihrem Sinne entschieden hat.

69. New-Work-Learning 5
Ein HIPPO reicht aus, um eine
Methode und ein Bild dauerhaft zu
verbrennen.
Task Model
Equipment Model
Team- Interaction-Model
Team-Model
Genau dieser konsultative Einzelentscheid war bei uns ebenfalls Ursache für ein wichtiges Learning. Wenn ein HIPPO - highest paid persona opinion - also zB eine
bestehende Führungskraft - bei solchen Methoden nicht mitspielt, dann resultieren daraus gleich 3 Learnings: a) das Werkzeug ist nicht vertrauenswürdig im Equipment-
Model b) das HIPPO muss sich nicht an die Regeln halten und c) das Team hat nur dann einen Wert, wenn das HIPPO gefragt wurde.

70. Führung
- Strategie vorgeben
- Ziele setzen
- Delegieren
- Erfüllung incentivieren
- Kritik & Feedback
Ok, als HIPPO kann ich also stören. Aber was sind denn meine Aufgaben? Früher waren das so Dinge wie Strategie vorgeben, Ziele setzten, Aufgaben delegieren, deren
Erfüllung incentivieren und Kritik und Feedback geben.

71. Führung
- Strategie vorgeben
- Ziele setzen
- Delegieren
- Erfüllung incentivieren
- Kritik & Feedback
In komplexen und dynamischen Umgebungen fehlt mir aber der Einblick, um das gut machen zu können. Weil die Aufgaben ohnehin nur von einem Team
wahrgenommen werden können, brauche ich nicht individuell Ziele zu setzen, zu delegieren, zu incentivieren und Feedback zu geben.

72. Führung
- Task Model: Alignment zur Firma
- Equipment Model: Methoden
vorleben
- Team Model: Individuelle
Betrachtung & Kooperation
Transformationale Führung
Ich kann aber durchaus Einfluss auf die Arbeit der Kollegen nehmen. Ich kann zB das mentale Modell für die Aufgabenstellung aufbauen, indem ich Firmenabsichten,
Chancen, Risiken und Interessen plausibel darstelle. Ich kann am Equipment Model mitwirken, indem ich neue Methoden selbst anwende und weitergebe. Ich kann so
auch indirekt am Team Interaktion und am Team Model mitgestalten - indem ich Methoden einbringe oder facilitiere, die den Kollegen ein besseres Miteinander erlauben.
Unserer Erfahrung nach eignet sich transformationales Management als Führungsstil in solchen Umgebungen.

73. Alignment Autonomy
Task Model
In militärischen Kreisen dachte man - wie in vielen Firmen auch - dass man entweder hohes Alignment oder hohe Autonomie haben kann, denn hohes Alignment braucht
klaren und detaillierte Ansagen über das, was zu tun ist. Das hilft einem Einsatztrupp beim Militär aber nicht viel, wenn es nach dem Feindkontakt erst mal beim General
anrufen muss, was denn als nächstes zu tun ist.

74. Alignment
Autonomy
Sweet
Spot
„Autonom das richtige
für die Firma machen.“
Graf von Moltke - und später Steven Bungay in seinem Buch Art of Action - und noch später Henrik Kniberg bei Spotify - nutzen eine andere Sicht. Militärisch macht sie
viel Sinn. Wenn ich hinter feindlichen Linien bin, will ich nicht die Heeresleitung anfunken müssen, was ich jetzt als nächstes tun muss. Hohes Alignment ist also genau
dann gefragt, wenn hohe Autonomie wirkt.

75. Alignment
Autonomy
Cross-Team-Kooperation
(DevOps/CoPs/Gilden)
Culture Work
Story-Telling
Leadership
Damit ich da lande, muss ich ein gemeinsames mentales Modell - zumindest im Task-Modell - haben, das über das meines Teams hinausgeht. Und genau an der Stelle
helfen Kooperationen über Teamgrenzen hinweg - zum Beispiel über DevOps-Teamverschränkungen, über Communities of Practice, über Gilden etc. Es hilft aktive
Kultur-Arbeit durch gemeinsame Events. Futurespectives, Firmenretrospektiven etc. Es hilft aber auch gutes Story-Telling und Leadership.

76. Natürliche Führung
Es ist eine
freiwillige Entscheidung,
ob man sich führen lässt.
Das kann mit der formellen
Führung übereinstimmen. Zufällig.
Und da gibt es noch so eine Sauerei im Komplexen: diese Mitwirkung an den eigenen mentalen Modellen kann man nicht erzwingen. Sie passiert freiwillig. Und dahinter
steht eine Machtumkehr: Führung findet erst dann statt, wenn der Geführte beschliesst, dass er sich führen lassen will.
Das kann mit der formellen Führung übereinstimmen, muss aber nicht.

77. Natürliche Führung
Die tatsächliche Position im
Team-Model ergibt sich aus der
Erfahrung des Teams.
Wer Wirkung auf die mentalen Modelle im Team hat, der führt aktiv, und zwar durch die Konsultation und durch die Einbeziehung. Wer nicht um Rat gefragt wird, der führt
auch nicht.

78. New-Work-Learning 6
Formelle Macht boykottiert Führung
und incentiviert zur Täuschung.
„Unsinn machen, weil der Vorgesetzte es erwartet.“
vs
„Meine Modelle mit den Ideen vom Vorgesetzten erweitern.“
Daraus folgt noch ein New-Work-Learning, das zumindest mir als geschäftsführendem Gesellschafter von paarundsiebzig Leuten keine Freude macht. Wenn ich die
formelle Rolle des Vorgesetzten mit Macht über die Leute bekommen, dann können sich die Leute von mir führen lassen, müssen sie aber nicht. Was sie aber müssen ist
meine Erwartungshaltungen bediene, damit ich meine Macht nicht gegen Sie ausnutze. Und dafür bereit sein, Dinge zu tun, die in Ihren Augen zwar Unsinn sind, aber
vom Vorgesetzten eben so erwartet werden.

79. Team—Model
Wer hat welche Fähigkeiten?
Wer hat welche Interessen?
Team-Interaction—Model
Wer hat welche Rolle inne?
Wie kooperieren wir?
Feste Positionen
Das gleiche Problem gilt natürlich nicht nur für Vorgesetzte, das gilt für alle fixierten Rollen, Aufgaben und Positionen. Wir erinnern uns an die beiden mentalen Modell
über die Aufstellung des Teams - zum einen das Profil der Individuen im Team, zum anderen die Art der Aufgabenverteilung und Kooperation.

80. Feste Positionen
Wenn die Aufgaben &
Rollen ohnehin verteilt
sind, warum soll ich
dann noch bessere
Strukturen finden?
In dem Moment, in dem ich auf formelle Rechte und Privilegien habe, ist das Team nicht mehr aufgefordert, die klügste Aufgaben- und Rollenverteilung durch
Experimente herauszufinden. Das ist eine schlechte Sache, weil es die Potentiale wegnimmt. Aber wie macht man das, dass die Kollegen das schlauste machen, und
nicht das formell richtige?

81. New-Work-Learning 7
Feste Positionen und Strukturen
sind schwer adaptionsfähig.
Dieses Learning ist etwas offensichtlich, aber wichtig. Feste Positionen und Strukturen sind - das liegt schon im Wort - nur schwer adaptionsfähig. Ich muss
restrukturieren, ich muss die alten festen Strukturen durch neue feste Strukturen ersetzen. Und die Beteiligten möchte sich dabei jeweils in der Position und in der
Struktur verbessern.

82. Rollen statt
Positionen
Retrospektiven:
- Bedarf dokumentieren
- Decision Matrix zu Optionen
- intern oder extern?
- Konsent
Team
Wir haben das über die Loslösung von Leuten und Positionen zu Rollen gemacht. Die Rollenverteilung innerhalb des Teams geschieht über Retrospektiven. Oft haben wir
zwei Retrospektivenformate pro Team - einmal die zur Iteration gehörigen normalen Retrospektiven, dazu etwa zweimonatlich Grundsatzretrospektiven, bei denen es um
die Betrachtung des Gesamtsystems geht. Da kann bei uns zB ein Kunde vom Team abgewählt werden. Dort werden auch die Rollen bei Bedarf adaptiert.

83. Rollen statt
Positionen
Rollentausch
Rollenanpassung
Rollenerzeugung
Staffinganforderung
Team
Die Sachen, die dann passieren können ist ein einfacher Rollentausch - wir haben Teams, bei denen der Scrum-Master zum Product Owner wurde, der System-Engineer
die Datenbank geerbt hat etc. Die Rolle kann auch neu definiert werden, es können auch neue Rollen geschaffen werden, die es so noch nicht im Team gab. Es entstehen
auch Staffing-Anforderungen, wenn das Team es nicht alleine kann. Meist handelt es sich dann um Kollegen, mit denen man schon gearbeitet hat, um den Performing-
Level nicht zu zerstören.

84. Rollen statt
Positionen
Wenn es nicht
mehr funktioniert
wird es deaktiviert.
Da ist der Wechsel zu Rollen recht nützlich. Wenn die Umgebung sich so ändert, dass die Position die Aufgaben nicht mehr gerecht wird, dann hat man die Gelegenheit
das ganze zu korrigieren. Es kann also passieren, dass eine gefühlte Herabsetzung passiert.

85. Rollen statt
Positionen
Holacracy:
Rollen mit Accountabilities
Teamgewählt bis auf Lead Link
Wenn wir ganz ehrlich sind, haben wir einen Stapel der Ideen bei Holacracy geklaut. Dort werden die Rollen jeweils auch innerhalb des Teams (dort Circle) gewählt und
modelliert.

86. New-Work-Learning 8
Wenn ich fixe Titel und Positionen
zerstöre brauche ich einen Plan für
Karriere, Zeugnisse und Gehalt.
Und schwupps, haben wir schon wieder etwas gelernt. Es klingt zwar auf den ersten Blick sehr reizvoll, fixe Positionen durch etwas überlegtes zu ersetzen, aber
funktionieren tut das deshalb noch nicht.

87. Karriere
Xing-Probe: >50% „Manager“ und „Head of“.
Ausnahmen > 50% „President“s
„Such Dir einfach einen passenden Titel aus.“
Das mit den Titeln ist ehedem ein Problem in unserer Branche. Wir Arbeitgeber wissen, dass man einen Teil des Gehaltes auch mit einem tollen Titel bezahlen kann, der
uns nichts kostet. Also verteilen wir die Titel eifrig, während wir sie selbst nicht ernst nehmen, wenn sie von draussen kommen. Wir haben das so gelöst, dass wir die
Kollegen auffordern, einen passenden Titel auszusuchen. Der kann dann natürlich in Xing und auf die Visitenkarte. Ehrlich gesagt trauern aber noch einige Kollegen der
Illusion von Bedeutung der Titel nach, sie hätten gerne einen beeindruckenden offiziellen Titel, und sei es für den privaten Freundeskreis.

88. Zeugnisse
Niemand in der IT glaubt an sie.
Referenzen zu Rollen statt
Titel & Positionen
On-Demand-Zeugnisse
Kommen wir zur nächsten grossen Lüge: Zeugnisse.
Ehrlich: niemand glaubt an sie. Oft wird den Kollegen gesagt „stell sie selbst aus“, wenn die HR oder der Vorgesetzte es machen muss defaulten sie gerne auf 2 - damit
geht man gerichtlichen Problemen aus dem Weg - oder 1 - damit geht man persönlichen Problemen aus dem Weg. Geht auch in Ordnung, der zukünftige Arbeitgeber
vertraut ihnen eh nicht. Weitaus mehr Vertrauen geniessen die Referenzen auf Ding oder LInkedin, und die kann man natürlich auch unternehmensintern machen. Die
Kollegen von der Andrea AG bzw. Qudosoft sind sogar noch eins cooler, die machen On-Demand-Zeugnisse, die sich jeder jederzeit aus automatisch generieren kann.

89. Individuelle Leistungsbewertung
… kann bei kooperativer &
vernetzter Arbeit nicht objektiv
stattfinden.
Sie stört sogar.
Soll der Hero-Culture-Held mit dem höchsten
Truck-Faktor dafür noch belohnt werden?
Hinter den Zeugnissen steht noch ein anderes Problem - welche Leistung will ich den bewerten? Komplexe und dynamische Aufgaben erfordern vernetzte Kooperation,
und bei dieser wirkt jeder Leistungsbeitrag nicht nur direkt, sondern vor allem indirekt - und das muss nicht immer positiv sein. Wir alle kennen Seniors, die für eine
Legacy-Software, die sie selbst verbrochen haben, unverzichtbar geworden sind- und heute das Nadelöhr für jeden Änderung bilden. Will man das tatsächlich belohnen,
auch wenn die Ausseneffekte eher negativ sind?

90. Gehalt?
Peer based
Salary
Meine Peers und ich bestimmen
mein Gehalt transparent.
Salary
Formula
Es gibt eine transparente Formel
für transparente Gehälter.
Self-selected
Salary
Ich setze mein Gehalt transparent
für alle selbst.
Auf jeden Fall transparent.
Daraus ergibt sich natürlich noch ein Dilemma - woher kommt das Gehalt? Offensichtlich nicht von der individuellen Performance, denn die ist ja böse. Aber woher dann?
Alle das gleiche Gehalt? Es gibt mehrere Modelle, die im Moment populär sind. Zb. die Gehaltsformel von buffer.io, über die sich jeder Kollege sein Gehalt ausrechnen
kann und dieses auch bekommt. Es gibt Peer-basierte Gehälter, bei ich mein Gehalt mit den Kollegen, die meine Arbeit gut bewerten können, bestimme. Es gibt
selbstbestimmte Gehälter. Gemeinsam ist: die Gehälter sind transparent. das ist quasi die Voraussetzung.

91. Gehalt?
Peer based
Salary
Salary Formula
Self-selected
Salary
Wenn ein gutes mentales Modell existiert,
kann jeder eine bessere Gehaltsentscheidung
treffen als bislang der Vorgesetzte.
Und warum sind die transparent? Damit man in der Lage ist, die Gehälter in Relation und mit Kontext-Informationen zu betrachten. Wieder geht es nicht um Partizipation
oder Demokratie, sondern um möglichst qualifizierte Entscheidungen. Und wenn ich irgendeine Stelle habe - seien es gewählte Gehaltschecker, meine Peers, die Formel
oder anders - an der das relevante Wissen zusammenkommt, dann ist praktisch jeder in der Lage, ein gutes und passendes Gehalt zu finden.

92. Team—Model
Wer hat welche Fähigkeiten?
Wer hat welche Interessen?
Team-Interaction—Model
Wer hat welche Rolle inne?
Wie kooperieren wir?
Reminder: es geht um
Effizienz & Effektivität
bei komplexen & dynamischen Aufgaben
Vielleicht ist es noch mal wichtig, das extra zu erwähnen: Es geht hier um die Steigerung von Effizienz und Effektivität bei komplexen und dynamischen Aufgaben.
Zielsetzung ist nicht Demokratie, sondern die passenden Aufstellung für das Problem, mit dem wir uns gerade beschäftigen.

93. Und was ist mit dem
Unternehmen selbst?
Ok, es geht also um Adaptionsfähigkeit auf Team- und Struktebene. Gilt das auch für die Unternehmensebene selbst?

94. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product
Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
CEO
Steuerung
Reporting
Ja, das muss natürlich gelten. Die klassische Unternehmensstruktur in der Wissensarbeit ist immer noch funktional - gerne als Matrix erweitert - und fusst auf der
Grundannahme von Steuerung von oben nach unten und Reporting von unten nach oben. Und weil das Reporting alle Informationen so nach oben bringt, dass man dort
maximal kompetent ist, kann man dort auch steuern.

95. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product
Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
CEO
Steuerung
Reporting
Effizienz & Effektivität
bei komplexen & dynamischen Aufgaben
Diese Struktur ist weder effizient noch effektiv bei komplexen und dynamischen Aufgaben.
Es ist zu teuer, die mentalen Modelle kontinuierlich zentral zusammenzuführen und von dort wieder zu steuern. Bitte nicht missverstehen: diese Struktur klappt prima, nur
eben nicht für komplexe und dynamische Problemstellungen.

96. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
CEO
Team
You built it, you run it.
Wir Softwareleute haben das schon lange gemerkt, und arbeiten deshalb nicht in einer funktionalen Struktur - sondern ganz im Gegenteil in crossfunktionalen Teams, bei
denen ich alles relevante Wissen im gemeinsamen mentalen Modell habe.

97. Portal-Team
Client-basiertes Team
MicroServices
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
Team
Wir ITler machen diese Teams inzwischen in vielen Varianten - also Portal-Teams pro Portal, als Client-Basiertes Team, also Microservice-Team und vieles mehr. Weil dort
die lokalen mentalen Modelle massgeblich sind, brauche ich natürlich auch keine klassische hierarchische Struktur mehr, sondern eine Organisation, die diese Teams am
besten bedient.

98. Und klar, die Organisationsform hier mit dem besten Marketing-Department ist Holacracy - hier in einem Screenshot eines Berichtes auf Aljazeera. Diese Form wird also
wirklich ernst genommen.
Rechts sieht man den Kreis von Kreisen, der an Stelle einer funktionalen Organisation und einer Hierarchie wirkt.

99. In der deutschsprachigen Welt gibt es quasi als Konkurrenzveranstaltung aus dem sogenannten BetaCodex-Umfeld, heute in den Büchern „Organisation für Komplexität“
und „Komplexithoden“.
Das sind jeweils Unternehmensformen, die versuchen nicht nur das bessere Wissen zusammenzubringen, sondern auch die passenden Organisationsform zu finden.

100. Dezentrale Organisation
mit zentralen Services.
Bei beiden Formen steht eine dezentrale Organisation im Vordergrund. Es ist klar, dass zentralisierte Steuerung nicht mehr funktioniert, und deshalb wird dezentral
gesteuert - jeweils am Ort des Geschehens. Die zentralen Funktionen werden zu Services „degradiert“ - sie unterstützen die dezentralen Einheiten mit allem, was dort
gebraucht wird, und was nicht elementarer Bestandteil der dort vorhandenen Kompetenz ist.

101. Adaptiertierbare
Organisationsformen mit
gemeinsamer Lernfähigkeit
Der zweite wichtige Punkt ist die Adaptierbarkeit. Diese Formen sind nicht statisch, sondern haben explizit Mechanismen, die die Organisation umgestalten, wenn die
aktuelle Form nicht mehr taugt. Dazu braucht es wiederum eine Lernfähigkeit, die über die lokalen Kompetenzen der dezentralen Einheiten hinausgeht. Aber Achtung:
diese gemeinsame Lernfähigkeit ist keine zentrale Funktion, sondern eine globale. Sie findet organisationsweit statt, nicht zentral.

102. Ich mache doch schon agil.
Brauche ich dann noch
NewWork?
Bei vielen stellt sich vermutlich jetzt die Frage „Ich mache doch schon agil. Und das funktioniert auch. Warum sollte ich dann noch Methoden aus NewWork
übernehmen?“

103. Ich mache doch schon agil.
Brauche ich NewWork?
Effizienz & Effektivität
bei komplexen & dynamischen Aufgaben
Die Antwort ist klar: ja, muss man nicht machen. Ausser man möchte die Effizienz und die Effektivität bei komplexen & dynamischen Aufgabenstellungen erhöhen, indem
man dafür sorgt, dass man mehr Wissen aufbaut, daraus lernt, und die Organisation passend zu diesen Learnings formt.

104. 44 % Inability to change organizational culture
35 %
Not enough personnel with the necessary agile
experience
34 % General organizational resistance to change
32 % Pre-Existing rigid / waterfall framework
29 % Management Support
24 %
Management Concerns about lack of upfront
planning
23 % Business/User/customer availability
22 % Concerns about loss of management control
Und das hilft bei unserer Arbeit, weil wir die Organisation in Sync zu unserer Denkweise bekommen. Wenn man sich die aktuellen Probleme mit agilen Methoden in
Unternehmen anschaut - hier am VersionOne-Survey über die größten Probleme mit agilen Methoden in Unternehmen - dann wird klar, dass agil alleine nicht so weit trägt
wie es tragen könnte - nur 2 Punkte haben nicht unmittelbar mit NewWork-Themen zu tun.NewWork hilft, in Ruhe agil zu arbeiten. Deshalb findet man auch so viele Agil-
Firmen bei NewWork-Veranstaltungen. Und so Leute wie ich müssen sich damit auskennen.

105. Hmm, und, würdet Ihr es
weiterempfehlen?
1. Jepp, wenn man
kulturell nahe ist.
Ok, was heisst das jetzt zusammengenommen? Sollte man das machen? Ergibt das Sinn?
Mal unter uns ITlern gesprochen: ja, schon. Wir sind dank vielen Jahren agil und Kooperation schon ziemlich nah dran. Wir haben viel zu viele schlaue Leute dabei, die
die meisten Konzepte kennen und heimlich machen.
Wenn ich aber bei einem Konzern bin - eher nicht, zumindest nicht, wenn ich im gleichen Gebäude bin. Das wird vermutlich nicht klappen.

106. Wirklich? Also
wirklich-wirklich?
Mal ehrlich: das ist
Beta-Technologie. Also
mehr Spass, wenn man
die Zeit hat.
Und, wenn ich ganz ehrlich bin: das ist noch alles Beta-Technologie. Man muss viel selbst Debuggen lernen, und darf keine Angst haben in den Motor zu greifen. Da ist
vieles unausgegoren und braucht noch einen Moment. Aber es fühlt sich besser an als das alte.

107. Perks != NewWork
Es geht in diesem Talk nicht um Perks. Hier sind die von Facebook zu sehen - Facebook stellt nicht nur die Fahrräder, sondern auch die Reparaturwerkstatt. Es gibt
Automaten für praktisch alle Hardware, die man so braucht, und natürlich gehören auch elektrische Tische zur Ausstattung. Die Kantine heißt EPIC-Cafe und hat einen
Chef, keinen Koch, und es gibt Süssigkeiten for Free. Und einen Friseur, und einen klassischen Spielsalon mit alten Arcades.
Und ja, bei mir in der Firma gibt es auch immer Süssigkeiten, Obst, Salat, für den Grill neben der Lounge-Area auf der Dachterasse gibt es immer einen vollen
Kühlschrank für spontanes grillen, und es gibt 4 Sorten Cola, 2 Sorten Mate und 5 Sorten Gin. Aber das sind Perks, nicht NewWork.

108. Quizfrage:
Wer organisiert
die Selbstorganisierten?
?Danke!Slides mit Tonspur auf
http://slideshare.net/johannhartmann
Danke für Ihre Geduld, die schon wieder mehr als 100 Slides lang gereicht hat. Weil der Content manchmal etwas dichtgedrängt ist bei mir stelle ich die Slides auch
immer mit voller Tonspur auf Slideshare.
Meine Lieblingsfrage zu dem Thema an andere Unternehmer und Führungskräfte ist immer „Wie organisieren Sie eigentlich die Selbstorganisation bei sich im
Unternehmen?“.
Kennt jemand die richtige Antwort auf die Frage? Ja, genau, die organisieren sich selbst.

109. Mal-Anfangen-Links:
http://reinventingorganizationswiki.com/
http://holacracy.org/
http://organizeforcomplexity.com/
http://intrinsify.me/
Bei vielen stellt sich vermutlich jetzt die Frage „Ich mache doch schon agil. Und das funktioniert auch. Warum sollte ich dann noch Methoden aus NewWork
übernehmen?“