Johann-Peter Hartmann, profile picture
Hochgeladen vonJohann-Peter Hartmann
PDF, PPTX1,878 aufrufe

NewWork in der Praxis

Der Vortrag reflektiert über zehn Jahre 'New Work' in Theorie und Praxis, wobei der Fokus auf der Entwicklung flexibler Arbeitsweisen sowie der Organisation von Freelancern ohne strikte Hierarchien liegt. Es wird betont, dass erfolgreiche Arbeitsmodelle oft keine großartigen Pläne erfordern, sondern aus der Qualität der beteiligten Personen resultieren. Der Referent zieht Parallelen zwischen vergangenen Erfahrungen und der heutigen Bedeutung von agilen Methoden sowie dem kontinuierlichen Lernen in komplexen Systemen.

Präsentation einbetten

Als PDF, PPTX herunterladen
1 / 109
2 / 109
3 / 109
4 / 109
5 / 109
6 / 109
7 / 109
8 / 109
9 / 109
10 / 109
11 / 109
12 / 109
13 / 109
14 / 109
15 / 109
16 / 109
17 / 109
18 / 109
19 / 109
20 / 109
21 / 109
22 / 109
23 / 109
24 / 109
25 / 109
26 / 109
27 / 109
28 / 109
29 / 109
30 / 109
31 / 109
32 / 109
33 / 109
34 / 109
35 / 109
36 / 109
37 / 109
38 / 109
39 / 109
40 / 109
41 / 109
42 / 109
43 / 109
44 / 109
45 / 109
46 / 109
47 / 109
48 / 109
49 / 109
50 / 109
51 / 109
52 / 109
53 / 109
54 / 109
55 / 109
56 / 109
57 / 109
58 / 109
59 / 109
60 / 109
61 / 109
62 / 109
63 / 109
64 / 109
65 / 109
66 / 109
67 / 109
68 / 109
69 / 109
70 / 109
71 / 109
72 / 109
73 / 109
74 / 109
75 / 109
76 / 109
77 / 109
78 / 109
79 / 109
80 / 109
81 / 109
82 / 109
83 / 109
84 / 109
85 / 109
86 / 109
87 / 109
88 / 109
89 / 109
90 / 109
91 / 109
92 / 109
93 / 109
94 / 109
95 / 109
96 / 109
97 / 109
98 / 109
99 / 109
100 / 109
101 / 109
102 / 109
103 / 109
104 / 109
105 / 109
106 / 109
107 / 109
108 / 109
109 / 109
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.
$ 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 :-)
$ 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
Das ist uns passiert. Ehrliche Antwort: das ist uns so passiert. Da gab es keinen Masterplan und keine Super-Entscheidung dahinter.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
„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?“
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?
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.
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.
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.
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.
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.
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
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.
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.
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 :-)
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?“
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.
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.
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.
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.
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.
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.
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?“

Weitere ähnliche Inhalte

PDF
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 
PDF
Von Kutschern, Managern und Systemadministratoren
vonJohann-Peter Hartmann
 
PDF
Agile versus Management WJAX 2014
vonJohann-Peter Hartmann
 
PDF
Das Ende der Karriere
vonJohann-Peter Hartmann
 
PDF
Warum die it nicht um new work herumkommt
vonJohann-Peter Hartmann
 
PDF
Leadership in der IT
vonJohann-Peter Hartmann
 
PDF
Die Architektur, die man kann
vonJohann-Peter Hartmann
 
PDF
Vom Entwickler zur Führungskraft
vonJohann-Peter Hartmann
 
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 
Von Kutschern, Managern und Systemadministratoren
vonJohann-Peter Hartmann
 
Agile versus Management WJAX 2014
vonJohann-Peter Hartmann
 
Das Ende der Karriere
vonJohann-Peter Hartmann
 
Warum die it nicht um new work herumkommt
vonJohann-Peter Hartmann
 
Leadership in der IT
vonJohann-Peter Hartmann
 
Die Architektur, die man kann
vonJohann-Peter Hartmann
 
Vom Entwickler zur Führungskraft
vonJohann-Peter Hartmann
 

Was ist angesagt?

PDF
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
vonGerrit Beine
 
PDF
Agile Führung - echt jetzt?
vonAgile Usergroup Unterfranken
 
PDF
Management brainfucks
vonJohann-Peter Hartmann
 
PDF
Lügen, schlimme Lügen und IT-Verträge
vonJohann-Peter Hartmann
 
PDF
Performancemessung, jetzt in echt
vonJohann-Peter Hartmann
 
PDF
Einfangen eines technisch kaputten projektes
vonJohann-Peter Hartmann
 
PDF
Legacy php - Sanieren oder Ablösen?
vonJohann-Peter Hartmann
 
PDF
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
PDF
Erfolgreiche rewrites
vonJohann-Peter Hartmann
 
PDF
RoofTop Brains & BBQ: Ein Gästbuch für China
vonJohann-Peter Hartmann
 
PPTX
Arbeitswelt2020 pecha kucha
vonUniversity St. Gallen
 
PDF
Arbeitswelt2020PechaKucha
vonElsy Zollikofer
 
PDF
Wetware Bugs and Refactoring
vonJohann-Peter Hartmann
 
PDF
DevOps jenseits der Tools
vonJohann-Peter Hartmann
 
PPTX
Google 2013 ist viel mehr als nur Suche oder G+ - was Sie jetzt kennenlernen...
vonNicole Simon
 
PDF
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
vonTechDivision GmbH
 
PDF
Surviving Complexity
vonJohann-Peter Hartmann
 
PDF
Rewrites überleben
vonJohann-Peter Hartmann
 
PDF
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
PDF
Whitepaper digitale Teamkultur
vonAnatoli Fichtner
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
vonGerrit Beine
 
Agile Führung - echt jetzt?
vonAgile Usergroup Unterfranken
 
Management brainfucks
vonJohann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
vonJohann-Peter Hartmann
 
Performancemessung, jetzt in echt
vonJohann-Peter Hartmann
 
Einfangen eines technisch kaputten projektes
vonJohann-Peter Hartmann
 
Legacy php - Sanieren oder Ablösen?
vonJohann-Peter Hartmann
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
Erfolgreiche rewrites
vonJohann-Peter Hartmann
 
RoofTop Brains & BBQ: Ein Gästbuch für China
vonJohann-Peter Hartmann
 
Arbeitswelt2020 pecha kucha
vonUniversity St. Gallen
 
Arbeitswelt2020PechaKucha
vonElsy Zollikofer
 
Wetware Bugs and Refactoring
vonJohann-Peter Hartmann
 
DevOps jenseits der Tools
vonJohann-Peter Hartmann
 
Google 2013 ist viel mehr als nur Suche oder G+ - was Sie jetzt kennenlernen...
vonNicole Simon
 
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
vonTechDivision GmbH
 
Surviving Complexity
vonJohann-Peter Hartmann
 
Rewrites überleben
vonJohann-Peter Hartmann
 
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
Whitepaper digitale Teamkultur
vonAnatoli Fichtner
 

Andere mochten auch

PDF
How not to screw the operating system of your startup
vonJohann-Peter Hartmann
 
PDF
JavaScript Security
vonJohann-Peter Hartmann
 
PDF
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
vonJohann-Peter Hartmann
 
PDF
Java script security for java developers
vonJohann-Peter Hartmann
 
PPTX
Javascript Security
vonjgrahamc
 
PDF
DevOps beyond the Tools
vonJohann-Peter Hartmann
 
How not to screw the operating system of your startup
vonJohann-Peter Hartmann
 
JavaScript Security
vonJohann-Peter Hartmann
 
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
vonJohann-Peter Hartmann
 
Java script security for java developers
vonJohann-Peter Hartmann
 
Javascript Security
vonjgrahamc
 
DevOps beyond the Tools
vonJohann-Peter Hartmann
 

Ähnlich wie NewWork in der Praxis

PDF
New Work Impulse Teil 2 - Zwischen „Next Work“ und Gesellschaft 4.0 - Treiber...
vonCompetence Books
 
PDF
"New Work" - Revolution der Arbeitswelt?
vonSebastian Hollmann
 
PDF
Digitalisierung alles in Bewegung
vonBjörn Schotte
 
PDF
MeCracy 2019 - New Work bei Me & Company
vonMe & Company GmbH
 
PDF
Unternehmen ticken anders oder warum "wie im Netz" nicht funktioniert
vonNicole Simon
 
PDF
New Work zwischen Arbeitsplatz- Hedonismus und neuer System- Logik – was brin...
vonCompetence Books
 
PDF
Agil ist nicht genug
vonFrank Düsterbeck
 
PDF
go[ing] mad New Work 2016 Part 1
vonaddWings Services
 
PDF
E-Commerce Organisationsstrukturen
vonBjörn Schotte
 
PDF
ATRUVIA@NEW WORK in 20 Minuten ...
vonMarc Wagner
 
PDF
Agil als Organistations- und Arbeitsprinzip - auch für KMU
vonUniversity St. Gallen
 
PDF
Design Thinking: Besser vernetzt arbeiten
vonClaudia Nicolai
 
PPTX
Arbeitswelt der Zukunft und die Konsequenzen für das Employer Branding
vonDoD!fferent
 
PDF
New Work Impulse - Zwischen „Next Work“ und Gesellschaft 4.0 - Treiber, Parad...
vonJosephine Nickel
 
PDF
Das agile Unternehmen - Sind Sie bereit für die digitale Zukunft?
vonUwe Weng
 
PDF
The Art of Scaling People (German)
vonendymi0n
 
PDF
go[ing] mad Arbeitsorganisation 3.0 - 2018
vonaddWings Services
 
PDF
Wie Agilität im Unternehmen zum Risiko werden kann_AAC2019
vonAgile Austria Conference
 
PDF
Agilität in Bibliotheken
vonBeat Mattmann
 
PDF
New Work Impulse Teil 1 - Zwischen „Next Work“ und Gesellschaft 4.0 - Treiber...
vonCompetence Books
 
New Work Impulse Teil 2 - Zwischen „Next Work“ und Gesellschaft 4.0 - Treiber...
vonCompetence Books
 
"New Work" - Revolution der Arbeitswelt?
vonSebastian Hollmann
 
Digitalisierung alles in Bewegung
vonBjörn Schotte
 
MeCracy 2019 - New Work bei Me & Company
vonMe & Company GmbH
 
Unternehmen ticken anders oder warum "wie im Netz" nicht funktioniert
vonNicole Simon
 
New Work zwischen Arbeitsplatz- Hedonismus und neuer System- Logik – was brin...
vonCompetence Books
 
Agil ist nicht genug
vonFrank Düsterbeck
 
go[ing] mad New Work 2016 Part 1
vonaddWings Services
 
E-Commerce Organisationsstrukturen
vonBjörn Schotte
 
ATRUVIA@NEW WORK in 20 Minuten ...
vonMarc Wagner
 
Agil als Organistations- und Arbeitsprinzip - auch für KMU
vonUniversity St. Gallen
 
Design Thinking: Besser vernetzt arbeiten
vonClaudia Nicolai
 
Arbeitswelt der Zukunft und die Konsequenzen für das Employer Branding
vonDoD!fferent
 
New Work Impulse - Zwischen „Next Work“ und Gesellschaft 4.0 - Treiber, Parad...
vonJosephine Nickel
 
Das agile Unternehmen - Sind Sie bereit für die digitale Zukunft?
vonUwe Weng
 
The Art of Scaling People (German)
vonendymi0n
 
go[ing] mad Arbeitsorganisation 3.0 - 2018
vonaddWings Services
 
Wie Agilität im Unternehmen zum Risiko werden kann_AAC2019
vonAgile Austria Conference
 
Agilität in Bibliotheken
vonBeat Mattmann
 
New Work Impulse Teil 1 - Zwischen „Next Work“ und Gesellschaft 4.0 - Treiber...
vonCompetence Books
 

Mehr von Johann-Peter Hartmann

PPTX
The End of my Career
vonJohann-Peter Hartmann
 
PDF
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
PDF
Serverside Cryptoparty
vonJohann-Peter Hartmann
 
PDF
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
PDF
Profiling for Grown-Ups
vonJohann-Peter Hartmann
 
KEY
Paradigmenwechsel bei webapplikationen
vonJohann-Peter Hartmann
 
The End of my Career
vonJohann-Peter Hartmann
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
Serverside Cryptoparty
vonJohann-Peter Hartmann
 
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
Profiling for Grown-Ups
vonJohann-Peter Hartmann
 
Paradigmenwechsel bei webapplikationen
vonJohann-Peter Hartmann
 

NewWork in der Praxis

  • 1.
    10 Jahre „NewWork“ inTheorie 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 treibensich 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 selbstverdiene 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 sindeher 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 flacheHierarchien 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 15Jahre 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 flacheHierarchien 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 esmit 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 esso 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 wirwieder 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 dasdoch 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 unspassiert. 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 gabes ein Strategiedokument dazu, und es wurde den Team- und Abteilungsleitern vorgestellt. Und die bekamen als Ziel, überall Scrum einzuführen.
  • 17.
    2006 Alle Teamleiter undGeschä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 Euchhier 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 demersten 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 NEWWORK 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 Grundist 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ß, wasich 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 dieunbekannten 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, realesNutzerverhalten 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 StaceyDiagram 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 StaceyDiagram 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 sienicht 
 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 Umsetzungwerden 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 heisstdie 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 kontinuierlichDinge, 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 altenAnnahmen 
 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 mentalenModelle 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 UseCase 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 daspassiert 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ürein 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 WelcheWerkzeuge 
 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 Wasist 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 Werhat 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 Werhat 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 beurteilenwir, 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 Interpretationder 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 Objektein 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 Bedeutungwird 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 undzukü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 Settingthe 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 kontinuierlichdie 
 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 Deutungder 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 SituationReporting 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 sindkeine 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 alleInformationen 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, wasich 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 & maximalinformiert 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 gehtum die Maximierung von wirksamen mentalen Modellen bei der Arbeit, nicht um Partizipation. Partizipation ist ein Outcome, kein Selbstzweck.
  • 59.
    Selbstorganisation Und wie nenntman 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, Weisheitder 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 gemeinsameWissen 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: kleinesmentales 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 Aberes 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 Einanderes 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 Deshalbergibt 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 diegemeinsamen 
 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 immersein? 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 gibtes 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 HIPPOreicht 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 Inmilitä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ürdie 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 ichda 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 isteine 
 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ächlichePosition 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 Machtboykottiert 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 welcheFä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 dieAufgaben & 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 Positionenund 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: - Bedarfdokumentieren - 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 esnicht 
 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 mitAccountabilities 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 ichfixe 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 derIT 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 … kannbei 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 Peersund 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 Wennein 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 welcheFä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 istmit 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 VicePresident 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 VicePresident 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 VicePresident 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 ITlermachen 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, dieOrganisationsform 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 deutschsprachigenWelt 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 zentralenServices. 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 Derzweite 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 dochschon 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 dochschon 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 tochange 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ürdetIhr 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? Malehrlich: 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 Esgeht 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!Slidesmit 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 stelltsich vermutlich jetzt die Frage „Ich mache doch schon agil. Und das funktioniert auch. Warum sollte ich dann noch Methoden aus NewWork übernehmen?“