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

WorkshopsInzwischen 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

WorkshopsIch 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

Un

klar

Kla

rA

nfo

rder

un

g

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

Un

klar

Kla

rA

nfo

rder

un

g

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 CodeBestehenden Code ändernAnalyse 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 istKomplexitä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.

Align

men

tAutonomy

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.

Align

men

tAutonomy

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

TesterNetSec

Consultant

Product Designer

BackendDeveloper

Test Infrastructure

Performance Consultant

CEO

Steu

eru

ng

Rep

ort

ing

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

TesterNetSec

Consultant

Product Designer

BackendDeveloper

Test Infrastructure

Performance Consultant

CEO

Steu

eru

ng

Rep

ort

ing

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 OwnerFrontend

DeveloperTester

NetSecConsultant

Product Designer

BackendDeveloper

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

BackendDeveloper

Test Infrastructure

Performance Consultant

TeamWir 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?“