Schlagwort-Archive: Selbstorganisation

Selbstorganisation ist eines der Kernprinzipien für agile Organisationen bzw. agiles Arbeiten. Der Begriff ist auch aus der Systemtheorie bekannt, wo sie eine emergente Eigenschaft komplexer Systeme beschreibt.

Agiler Wandel ganz einfach

Agiler Wandel und Star Wars

Allein die Einführung agiler Frameworks macht noch keine agile Kultur aus. Agiler Wandel ist nötig, um die Kultur des Unternehmens in Richtung Agilität zu bewegen.  Alles, was wir für einen Wandel brauchen – und das ist ggf. viel weniger, als man zunächst vermuten mag – finden wir in einer weit, weit entfernen Galaxis…

In der Einleitung zu „15 Zitate aus Star Wars für den Alltag“ steht:

„Star Wars strotzt ja geradezu vor wichtigen Themen und Lehren, die wir auf unser Leben übertragen können. Viele dieser großen Gedanken sind in wunderbar knappen und zitierfähigen Sätzen zusammengefasst.“

Agiler Wandel und die MachtWie schaffen es Filme, die vor allem auf Verkauf von Merchandising ausgerichtet sind, große Gedanken zu vermitteln? Die Antwort müsste eigentlich gar nicht lauten, denn die großen Gedanken entpuppen sich schnell als kurze Phrasen, die keinen wirklichen Sinnzusammenhang haben. Star Wars schafft es aber trotzdem im Kontext großer Gedanken genannt zu werden und dies funktioniert gerade nicht durch Inhaltsschwere. Die Filme vermitteln keine geschlossene Jedi-Religion, sie funktionieren über die perfekte Inszenierung. Einzelne Szenen mit authentischen Hauptfiguren schaffen einen Rahmen, in den der Zuschauer seine eigene Jedi-Religion in das Star Wars Universum hineindenken kann. „Möge die Macht mit Dir sein“ wird so von einem kleinen Satz zu einem großen Gedanken, auch wenn niemand so richtig weiß, was diese Macht denn nun sein soll und wie sie mit einem sein kann.

Unsere Galaxis funktioniert zum Glück genauso platt. Agiler Wandel bzw. Kulturwandel im allgemeinen braucht m.E. keine ausformulierte Kultur und Werte und kein aufgesetztes Change Projekt. Agiler Wandel braucht einige Schlüsselszenen, die von den Hauptfiguren authentisch vorgetragen werden. Hier ein Beispiel aus der Praxis:

Kulturwandel in der Praxis

Im Rahmen eines groß angelegten Kulturwandels duzt OTTO sich jetzt bekanntlich. Die Initiative ging vom Vorstand aus, was auf jeden Fall schon mal die richtigen Hauptpersonen sind. Inhaltlich finde ich das Du eine gelungene Aktion im oben genannten Sinne. Im Mittelpunkt steht eine ganz simple, losgelöste Geste, die aber eine sehr große Kraft entfalten kann – möge das Du mit uns sein. Leider wurde nur nicht an die richtige Inszenierung gedacht.

Die Info, dass der Vorstand allen das Du anbietet, wurde über das Intranet verbreitet. Ich vermute mal, dass die digitale Kommunikation die entsprechende Strategie unterstreichen sollte. Und die vielen #s sollten wohl einen modernen Social Media Kontext schaffen. Wer weiß…

Ganz ohne #, in einem öffentlichen Termin oder vielleicht sogar in guter alter Michael Otto Tradition, der zu Weihnachten persönlich über alle Flure ging, um jedem ein frohes Fest zu wünschen, wäre die Aktion ein Volltreffer gewesen. So aber bleibt, zumindest bei mir, der Beigeschmack einer akademisch fundierten Change-Initiative.

Agiler Wandel und die Rolle der Führung

Durch die geforderte authentische Inszenierung der Hauptpersonen kommt der Führung eine ganz besondere Rolle zu. Ähnlich stellt es auch Frederic Laloux  in Reinventing Organizations dar, der eine der zentralen Voraussetzung für eine selbstorganisierte Organisation darin sieht, dass der „CEO“ hinter dem Konzept steht und es lebt. Ich bin der Überzeugung, dass dies nicht nur für selbstorganisierte, sondern auch für agile Unternehmen gilt. Agil wird eine Organisation nicht durch zertifizierte Coaches, sondern durch die agile Einstellung und Vorbildfunktion der Führung. Agil werden, weil das Management es als vermeintliche Notwendigkeit erkannt hat, wird nicht funktionieren. Es werden dann ggf. agile Prozesse eingeführt, wobei die Betonung aber auf Prozesse und leider nicht auf Individuen und Interaktion liegt. Agiler Wandel ist das dann nicht, entsprechend wird keine agile Organisation entstehen.

Um mit einem Zitat aus Star Wars zu enden: „Tu es oder tu es nicht. Es gibt kein Versuchen.“

Bild: Day 190 von Pascal auf flickr, Verwendung unter CC0

Agile Coach und Festanstellung

Die agile Industrie hat den Beruf des „Agile Coach“ hervorgebracht. Dieser ist normalerweise für ein bis wenige Teams zuständig. Ich selber habe auch mal kurz als Agile Coach für zwei Teams gearbeitet und mir dabei recht schnell die Frage gestellt, ob diese Rolle sinnvoll ist.Coach

Interpretiert man den Agile Coach aus der Scrum Perspektive, d.h. als Scrum Master, dann macht die Rolle als Job-Beschreibung nur bedingt Sinn. Der Scrum Master ist eine Vollzeitbeschäftigung nur während der Setup Phase, danach soll die Rolle bzw. Aufgabe aber aus dem (Entwickler-)Team übernommen werden kann. (Hier zeigt sich deutlich, wie durchdacht Scrum als Geschäftsmodell ist, denn die Scrum Rollen bringen direkt den Bedarf nach Zertifikaten und Beratern mit sich.) Scrum Master in Festanstellung passen also eigentlich nicht ins Konzept.

Aber wir reden ja nicht vom Scrum Master sondern vom Agile Coach. Und der kann nicht nur Scrum, sondern mindestens auch noch KANBAN. Ändert das den Sachverhalt? Nein.

Der Hauptgrund gegen Agile Coaches in Festanstellung, die nur für wenige Teams zuständig sind, ist die Selbstorganisation, die sie fördern sollen. Denn Selbstorganisation erfordert Freiraum. Bei aller guter Absicht, wird dieser Freiraum aber nicht dadurch gefördert, dass ein Agile Coach einen breiten Methodenkoffer auspackt und das Team in seinen eigenen Prozessen damit indirekt lenkt. Wenn ein Agile Coach in Festanstellung sagen wir für drei Teams verantwortlich ist, wird er darauf achten, 1/3 seiner Zeit für jedes Team einzusetzen. Der Coach versteht sich als Teil des Teams und will dieses aktiv entwickeln. Wie soll das Team da lernen selbstorganisiert zu arbeiten?

Bedeutet dies also, dass Agile Coaches an sich keine sinnvolle Rolle sind? Nein. Natürlich ist es sinnvoll auf Erfahrungen zurückgreifen zu können und nicht alle Fehler immer selber machen zu müssen. Es geht aber um die Aktivität bzw. Passivität der Rolle. Ein Agile Coach sollte dann aktiv werden, wenn das Team es anfragt. Die Grundeinstellung ist also passiv.

Buurtzorg als ein Paradebeispiel für ein Unternehmen, das auf Selbstorganisation aufbaut, hat für seine selbstorganisierten Teams „Regional Coaches“ installiert. Ein Coach betreut hier 40-50 Teams. Diese sind somit nie direkt Teil des Teams, sondern treten eher als externe Berater auf. Sie haben keine Weisungsbefugnis, sind nicht an die Performance der Teams gekoppelt. Dies zwingt die Teams zur Selbstorganisation, lässt sie gleichzeitig aber nicht alleine. Unterstützend gibt es ein sehr aktiv genutztes Intranet, über das sich Mitarbeiter schnell und direkt über aufkommende Fragen, Best Practices etc. austauschen können. Dies unterstützt Selbstorganisation im Tagesgeschäft, gänzlich ohne Coaches.

Ein Agile Coach ist dann sinnvoll, wenn er es Teams ermöglicht selbstorganisiert zu arbeiten. Dafür brauchen Teams vor allem Freiraum und nicht 24-7 Unterstützung und Beobachtung.

Bild: Coach Don Lear von Ed Uthman auf flickr, Verwendung unter cc Lizenz

Von der Timebox zur Valuebox

TimeboxEine der Kernideen von Scrum ist das Arbeiten in Timeboxes. In einer Timebox gibt es einen klar definierten Start- und Endzeitpunkt. Es geht also um Arbeiten nach der Stoppuhr? Das Bild der Stopp- oder Sanduhr trifft nicht wirklich den Kern von Timeboxing im agilen Kontext. Denn über der Timebox steht nach wie vor der Hauptauftrag der Werterzeugung. Eigentlich sollte man die Timebox also besser als Valuebox bezeichnen.

Das Verständnis der Timebox als Valuebox rückt das eigentliche Ziel in den Vordergrund und stellt auch klar, wieviel Organisation in agilen Methoden notwendig ist. Seine Zeit so zu planen, dass am Ende ein vorzeigbares Ergebnis entsteht, ist nicht einfach. Dabei hilft das hohe Engagement und das Commitment des Einzelnen. Wer will schon am Ende eines Sprints nichts zu präsentieren haben! Agile Arbeiter wollen wollen etwas bewegen, sie wollen Wert erzeugen und zwar in sinnvollen Zeiteinheiten.

Wenn die Zeit, die zur Verfügung steht, durch eine Timebox ein klar definiertes Ende hat und am Ende gleichzeitig einen sinnvollen Wert vorzeigbar sein soll, dann muss innerhalb der Timebox ggf. der Wert selber angepasst werden. Aus dem Projektmanagement kennen wir das Dreieck aus Time, Budget und Scope:

  • Die Dimension Zeit ist beim Timeboxing wie schon beschrieben fest. Der einzelne Sprint hat eine klar definierte Länge. Zeit wird damit nur verhandelbar, wenn zusätzliche Sprints geplant werden.
  • Das Budget ist normaler Weise auch klar begrenzt, wenn unter Budget vor allem Manpower gemeint ist. Natürlich kann man das Team kurzfristig erweitern, häufig jedoch ist dies aufgrund der hohen Initialkosten im Sinne der Anlernphase nicht sinnvoll.
  • Damit bleibt nur der Scope, also der geplante Umfang bzw. der abzuliefernde Wert, der innerhalb der Timebox angepasst werden kann. Wenn Komplikationen oder Aufwände sichtbar werden, die in der ersten Schätzung nicht erkennbar waren, dann muss darauf mit Anpassung des Scopes reagiert werden.

Product Owner und Stakeholder müssen dies akzeptieren bzw. fördern. Am Ende ist es für das Produkt und das Unternehmen wichtig, dass möglichst früh ein nutzbarer Wert entsteht, auch wenn dieser zunächst unter den ersten Erwartungen bleibt. Durch agile Methoden wollen wir verhindern, dass einzelne Arbeitspakete über Monate verzögert werden und somit auch über Monate kein Wert am Markt geschaffen wird. Wer schnell Wert produzieren will, der muss akzeptieren, dass dieser Wert in kleinen Einheiten erbracht wird. Ohne dieses Verständnis bleibt die Timebox als leere Methodik zurück. Erst durch das Verständnis der Timebox als Valuebox lassen sich agile Methoden mit Mehrwert praktizieren.

Bild: In Search Of Lost Time von Alexander Boden auf flickr, Verwendung unter cc Lizenz

Scrum ist auch nur ein Produkt

Scrum hat als leichtgewichtiges Framework für IT-Projekte eine Erfolgsgeschichte geschrieben, die mittlerweile deutlich über die Software-Branche hinaus geht. Dabei basiert der Ansatz im wesentlichen auf den Prinzipien des agilen Manifest. Dessen erster Leitsatz ist für mich dabei der zentralste:

  • Wir schätzen und Individuen und Interaktionen mehr als Prozesse und Werkzeuge.

Wenn man diesen Leitsatz ernst nimmt, dann schließt dies einen fest vorgegebenen prozessualen Rahmen für agiles Arbeiten aus. Statt sich auf Prozesse und Werkzeuge zu konzentrieren, sollte man auf die Individuen eingehen, die als Team zusammenarbeiten. Besucht man Konferenzen oder Workshops, stellt man aber schnell fest, wie sehr sich die agile Community über Tools und Prozesse unterhält. Es wird über Rollen diskutiert, es wird nach den Top 10 Ratschlägen für einzelne Artefakte und Routinen gesucht, aufgrund der Größe kaum noch druckbare Modelle sollen zeigen, wie man agil skalieren kann. Nur irgendwie fragt niemand nach den Menschen, um die es ja eigentlich gehen soll…

Das Aufwändige an der agilen Idee ist, dass sie zum selbständigen Denken und Handeln zwingt.

  • Das perfekte Board, das jeden Fluss und alle Probleme visualisiert
  • das eine Schema für die Retro, das in jeder Situation funktioniert
  • die 10 Grundregeln für Führung im agilen Kontext

Alles das gibt es nicht! Und deshalb ist es gefährlich Produkte wie Scrum mit Agilität zu verweKaufmannsladenchseln. Ja, Scrum ist ein Produkt! Scrum verkauft Zertifikate. Scrum will über Prozesse sprechen und Tools vermitteln, um Bücher und Beraterstunden an dem Mann zu bringen.

Bitte nicht falsch verstehen, ich halte Scrum für einen guten Ansatz. Aber wir dürfen nicht den Fehler machen, aus einem Produkt eine Art Religion zu machen. Seminare, Zertifikate und Weiterbildungsangebote sind sinnvoll, solange es um Hilfe zur Selbsthilfe geht. Zu schnell tappen wir aber in die Falle, uns an vorgegebene Fahrpläne zur agilen Transformation, an Prozess-Charts und Best Practices zu klammern. Dies ist natürlich auch entsprechend einfacher und verlockend. Aber solange gilt „Individuen und Interaktionen über Prozesse und Tools“, solange müssen wir uns mehr um die Menschen und die Zusammenarbeit in unserem Unternehmen kümmern, als um vorgegebene Prozesse und Tools.

Man baut agile Organisationen auf, um mit Hilfe von Selbstorganisation die wachsende Komplexität in den Griff zu bekommen. Wer sich selbst organisieren soll, der braucht dafür aber Freiheitsgrade und keine vorgefertigten Produkte. Bis zu einem gewissen Grad ist dieser Freiheitsgrad sogar in das Produkt Scrum selbst eingebaut. So soll sich z.B. der Scrum Master im Laufe der Zeit überflüssig machen. Dort, wo für jedes Team „Agile Coaches“ in Festanstellung gesucht werden, liegt somit der Verdacht nahe, dass die agile Idee nicht wirklich ernst genommen oder verstanden wird. Selbstverständlich ist es sinnvoll, erfahrene Scrum Master o.ä. im Unternehmen zu haben, wenn man eine agile Organisation aufbauen oder werden will. Aber weder ist es sinnvoll einfach alle alten Projektmanagement-Planstellen in agile umzuwandeln, noch ist es sinnvoll, Scrum oder andere Methoden / Produkte aus Prinzip einzufordern. Vielmehr muss es darum gehen, die individuellen Bedarfe der eigenen Organisation zu erkennen und zu bedienen.

Scrum ist nicht nur ein tolles Framework, es ist auch ein sehr erfolgreiches und durchdachtes Produkt. Bitte verwechselt es nicht mit Agilität. Um es mit den Worten von Dave Thomas zu sagen: Agile Is Dead (Long Live Agility)!.

Bild: Kaufmannsladen von Anja Leidel auf flickr, Verwendung unter cc Lizenz

Simply the Best? Agiles Management und Personalauswahl

„If you can only have 10 on the team, they’d better be the very best that you can find.“ Dies ist eine von 14 zenralen Aspekte für agiles Arbeiten, die Bob Warfield in seinem SmoothSpan Blog aufführt. Als ich mein erstes agiles Projekt erfolgreiche beendete, fragten mich viele Kollegen nach dem Erfolgsrezept bzw. den Erfolgskriterien, denn es war auch das erste agile Projekt für unseren Bereich. Scrum, damals die Basis für unser Projektvorgehen, war recht leicht zu erklären. Aber was braucht es, um dieses Vorgehen auch zum Erfolg werden zu lassen? Ich fragte mich das natürlich auch, denn es sollte nicht nur bei einem erfolgreichen agilen Projekt bleiben. Als das wesentlichste Erfolgskriterium kristallisierte sich für mich folgendes heraus: Arbeite mit Profis zusammen! Dies ist eine vielleicht abgeschwächte Form des oben genannten Zitats, meint im Kern aber etwas ähnliches.

Nun könnte man sagen: tolle Erkenntnisse, dass man mit guten Leute gute Ergebnisse erzielen kann! Aber so einfach ist das nicht. Agile Methoden bilden einen Rahmen, in dem Arbeit selbstorganisiert ablaufen soll. Das agile Manifest sagt, dass die Konzentration auf Individuen und Interaktion wichtiger sind als Werkzeuge und Methoden. Dies unterstreicht die Bedeutung der zusammenarbeitenden Menschen. Sich selbst organisieren zu können heißt aber auch, dass man sein Handwerk schon verstehen muss. Zudem arbeiten agile Teams in kleinen Gruppen, so dass kein Raum zum verstecken bleibt. All dies passt also zu der Bedeutung der Qualität agiler Arbeiter und zeigt, warum diese Qualität im agilen Kontext besonders wichtig ist.

Trotzdem würde ich heute das Erfolgskriterium anders formulieren: Bring den best möglichen Mix aus Menschen als ein Team zusammen. Ich will damit verdeutlichen, dass es nicht reicht, die zehn besten Individuen auszuwählen, für die dann, wie Bob Warfield schreibt, „pay what it takes“ gilt. Keine Frage, Qualität hat ihren Preis. Entscheidend ist aber das entstehende Team, das Gesamtgefüge. Neben der beruflichen Qualifikation muss dabei auch die Persönlichkeit betrachtet werden. Ein Team funktioniert dann, wenn sich sowohl die fachlichen als auch die persönlichen Merkmale der Teilnehmer gegenseitig so unterstützen, dass das Team mehr wird als die Summe seiner Einzelteile.

Bob Garfield gibt zusätzlich noch folgende Tipps, um das Team best möglich zu unterstützen, bzw. die besten Leute optimal ans Teams / Unternehmen zu binden:

  • Make engineering a first class part of the company.
  • Give them a high performance environment to work in.
  • Parallel Career Tracks for Pure Techies and Management.

All dies kann ich unterschreiben, wobei man den ersten und dritten Punkt verallgemeinern muss, denn man kann und sollte auch außerhalb des IT-Bereichs agil arbeiten. Eine der wichtigsten Aufgaben für agiles Management im Bereich Personalauswahl ist aus meiner Sicht aber die Zusammensetzung des Teams optimal zu unterstützen. Die Personalauswahl muss auf das entstehende Team abgestimmt werden und darf nicht nur isoliert betrachtete Superstars auswählen. Hilfreich ist es z.B. potenzielle Kandidaten auch mit dem Team reden zu lassen. Ich verlasse dafür mit dem HR-Manager den Raum und lasse den potenziellen Kollegen und Teile des Teams sich einfach mal beschnuppern. Dabei soll kein Team entstehen, wo sich alle auf anhieb perfekt verstehen. Ein gutes Team braucht auch Spannungspunkte. Diese zu erahnen ist Aufgabe von HR und Manager. Aber ein unverfängliches Kennenlernen gibt beiden Seite eine gute Chance, in die neue neue Konstellation hineinzufühlen.

Die zweite zentrale Aufgabe für agiles Management ist es dann, für dieses Team passende und gleichzeitig den Wert des Unternehmens steigernde Aufgaben auszuwählen. Das Team so gut verstehen lernen, dass man zu der Teamkompetenz passende Aufgaben auswählen kann, ist dafür die Voraussetzung. Natürlich muss dabei immer auch der Mehrwert für das Unternehmen betrachtet werden. Im Zweifel würde ich aber eine bestimmte Aufgabe runter priorisieren, wenn ich dadurch den Output des jeweils aktiven Teams optimieren kann. Dann können auch Personalwechsel nicht mehr nur als Gefahr gesehen werden, sondern auch als Chance mit einer neuen Teamkonstellation ganz neue Teamkompetenzen zu erreichen und andere Themenschwerpunkte setzen zu können, ohne dabei an Fahrt zu verlieren. Hat man mehrere Teams zur Verfügung, lohnt sich je nach aktuellen Themen also auch die Frage, ob die bestehenden Teams verändert bzw. durchmischt werden sollten. Starre Abteilungsgrenzen sind dabei wenig hilfreich. Agilität muss somit auch in der Organisation der Organisation ankommen.

agiler Statusreport

Auf Paul Klee geht das Zitat zurück: „Kunst gibt nicht das Sichtbare wieder, sondern Kunst macht sichtbar.“ Ich muss gestehen, dass ich diese Zeile nicht kannte, als ich vor einiger Zeit – mal wieder – auf der Suche nach einer Möglichkeit war, den aktuellen Status des Produkts, das ich betreue, auf einen Blick sichtbar zu machen. Mir wurde – mal wieder – recht schnell klar, dass klassische Berater-Logik nicht funktioniert. Ein komplexes Produkt lässt sich nicht MECE (mutuale exclusive and collectively exhaustive) zerlegen; zumindest dann nicht, wenn man schnelle, operativ benutzbare Ergebnisse haben will. Es gibt auch nicht das eine Template, dass für jede Situation passt. Die Realität passt eben nicht auf einen standardisierten, vorstandstauglichen Einseiter.

Auf der Suche nach einem alternativen Ansatz bin ich auf die Idee gekommen, ein Bild zu malen. Wenn ich die Komplexität nicht in logische Strukturen gegossen bekommen (es wäre dann wohl auch keine Komplexität mehr!?), dann verzichte ich doch einfach auf diese Strukturen. Und wenn ich die Zusammenhänge ohnehin nicht übersichtlich und umfassend abbilden kann, dann kann ich auch gleich ganz darauf verzichten. Das Bild das ich gemalt habe war am Ende eine Landkarte des Produktes.

Projektreport_Karte

Eine solche Landkarte, unterliegt nicht der Notwendigkeit Themen nach Logik zu trennen. Einzelne Aspekte können mehrfach unter verschiedenen Namen auftauchen, die Namen und Bezeichnungen können doppeldeutig sein.  Auch ist es irrelevant, die Zusammenhänge abzubilden. Man kann bei Bedarf Themen durch geografische Nähe bewusst zusammenführen oder durch natürliche Grenzen Themenfelder trennen. Aber dies muss nicht sein. Diese künstlerische Freiheit ermöglicht es, einen wirklichen Überblick zu erarbeiten. Zudem kann man bei der Gestaltung nach Belieben (schwarzen) Humor walten zu lassen, was insbesondere dann hilft, wenn es dem Land mal gerade nicht so rosig geht. Und wie bei echten Karten ändert sich auch diese Produkt-Landkarte im Laufe der Zeit, was dann im Zeitraffer betrachtet schon viel über die Entwicklung des Produkts verrät.

Eine solche Karte kann als Grundlage für eine Wetterkarte dienen, die für den betrachteten Zeitraum aufzeigt, wie es um das Land / Produkt steht. Ein Statusreport besteht dann z.B. aus Sonne, Regen, Blitzen etc., die über die Karte verteilt werden. Ebenso lässt sich über eine farbige Legende der Status in die Karte einzeichnen. Die Aussage einer solchen Momentaufnahme ist nicht schlechter als ein „ordentlicher“ Statusreport im Berater konformen Template. Allerdings erfordert ein solche Darstellung eine gemeinsame Diskussion bzw. Interpretation und fördert damit die Kommunikation und Interaktion.

Auf den ersten Blick mag die Idee ein Geschäft durch ein Bild zu steuern befremdlich erscheinen, doch damit kann genau das erreicht werden, was Paul Klee über Kunst sagt. Nicht das Sichtbare über Temples und Reports wieder zu geben, sondern Dinge durch gemeinsame Interpretation und Kommunikation sichtbar machen. Gerade im agilen Kontext ist dieses sichtbar machen zwingend, damit selbstorganisierte, interdisziplinäre Teams den notwendigen Gesamtblick auf das Produkt erhalten. Außerdem ist Interaktion ja bekanntlich einer der wesentlichen agilen Werte. Und die hier vorgestellte Form des agilen Statusreport fördert ebene diese Interaktion in besonderem Maße.

Wir nutzen diese Form des agiles Statusreports wöchentlich im Team, um gemeinsam die vergangene Arbeitswoche Revue passieren zu lassen. Anders als in aufpolierten Statusberichten, in denen nur die Top-Prio-Themen auftauchen, verschwinden auf einer Produktkarte keine Themen. Man kann dadurch z.B. erkennen, worum man sich, vielleicht schon viel zu lange, nicht gekümmert hat. Die Diskussion macht aber z.B. auch in anstrengenderen Phase die Sachen sichtbar, die richtig gelaufen sind.

Darüber hinaus nutzen wir die Wetterkarte als Einstieg in unser Sprint Review Meeting. Hier kann mit dem und für das gesamten Team den Status des Produkts diskutieren. Dadurch können die unterschiedlichen Perspektiven, die ein interdisziplinäre Team auf sein Produkt hat, beleuchtet werden, so dass eine Art 360° Blick entsteht.

Selbstorganisation: 1+1=3

Ich habe das Glück mit einem Team aus internen wie auch externen Superhelden zusammenarbeiten zu dürfen. Wie in der richtigen (Comic-)Welt hat jeder seine ganz persönliche Superkraft. Aber wie schafft man es, dass jeder seine Superkraft auch richtig einsetzen kann? So ein Superheld braucht Freiheit, ein Superhelden-Team braucht Teamgeist. Der passende Begriff im Kontext der Agilität ist Selbstorganisation.

Selbstorganisation ist dabei nichts neues oder revolutionäres. Selbstorganisation ist eine emergente Eigenschaft komplexer Systeme, also eine Eigenschaft, die sich nicht allein durch die Eigenschaften der einzelnen Elemente des System erklären lässt. Selbstorganisation ist ein natürliches Phänomen. All die Ökosysteme um uns herum organisieren und regulieren sich selbst. Das Zusammenspiel von Pflanzen, Tieren, Bakterien usw. schafft, ganz ohne Management, ein funktionierendes, florierendes System. Umso spannender, dass wir uns im Zuge der Industrialisierung von diesem Konzept sehr aktiv und weit entfernt haben. Wir haben gelernt das Denken vom Handeln zu trennen, feste Regeln zu formulieren und zu befolgen, die Abläufe und Organisation nicht komplex, sondern Idiotensicher zu gestalten und klar definierte Rollen einzunehmen. Wir haben damit gelernt, gegen alle vier Anforderungen für Selbstorganisation zu arbeiten.

Wohl auch deshalb sind Ansätze wie z.B. die 20% time von Google, die selbstorganisierte Projekte fördert, viel diskutiert. Wenn man auf die Liste der Themen blickt, die aus dieser selbstorganisierten Tätigkeit entstanden sind (z.B. gmail, AdSense), dann wird klar, dass

  • Selbstorganisation eine sehr hohe kreative, innovative Kraft besitzt
  • Selbstorganisation Business Value generieren kann

Auch wenn Google die 20% time nicht mehr aktiv zu fördern scheint, haben wir entschlossen, sie einzuführen. Das vermeintlich besondere dabei ist, dass wir die 20% time bei einem Dienstleister eingeführt haben. Das klingt für viele vermutlich mutig bis schwachsinnig, immer hin bezahle ich die Dienstleister ja und dann will ich doch auch wissen, was sie tun!? Aber wissen was sie tun und ihnen sagen, was sie zu tun haben, sind zwei deutlich unterschiedliche Ansätze. Wenn man mit Dienstleistern zusammenarbeitet, die bereit und fähig sind auf Augenhöhe mit zu gestalten, und die als Spezialisten Aspekte des Projekts abdecken, die man selber nicht bedient, dann ist der Raum für Selbstorganisation eine riesige Chance an sonst verschlossene Potentiale zu kommen. Dann wird aus 1+1 eben 3.  An dieser Stelle ganz liebe Grüße an die tollen Kollegen von neuland!

1+1=3

Dass aus einer 20% time Regelung kein planloses „jeder-macht-was-er-will-ohne-auf-das-Gesamtprojekt-zu-schauen“ wird, hängt im wesentlichen davon ab, welche Kultur der Zusammenarbeit und welchen Grad an Transparenz man etabliert hat. Ich bin gespannt, wie erfolgreich die 20% time für uns sein wird und wie gut es uns gelingen wird, den nötigen Freiraum zu erhalten.

Komplexität – darf’s noch etwas mehr sein?

Vor 100 Tagen haben ich den Agilosoph ins Netz gestellt. Zeit also für ein erstes Resümee. Hat sich die Arbeit gelohnt? Hat sich etwas entwickelt oder ergeben, was ohne diesen Blog nicht passiert wäre?

Ich habe z.B. einige Posts verfasst, die sich mit dem Thema Komplexität befassen. Durch die intensive Auseinandersetzung mit verschiedenen Aspekten von Komplexität, hat sich mir gezeigt, dass Komplexität weniger als Herausforderung des Umfeldes sondern viel mehr noch als Chance und Konzept für die eigene Organisation betrachtet werden muss:

  • Wir brauchen Komplexität, um komplexe Probleme lösen zu können.
  • Die komplexen Organisationen, die wir dafür brauchen, können wir nicht mehr beherrschen, weil sie  nicht vorhersagbar sind.
  • Allerdings brauchen wir sie auch nicht zu beherrschen, weil sie sich selbst organisieren können.

Wir brauchen Komplexität (in der eigenen Organisation), um die Komplexität (für unsere Kunden) reduzieren zu können. Wenn wir also unterstellen, dass wir in komplexen Märkten und Situationen arbeiten, dann ist der Ansatz alles zu regulieren, um es vermeintlich möglichst einfach zu gestalten, schon vom Grundsatz her falsch. Wir müssen Komplexität fördern und Selbstorganisation ermöglichen, um echte Problemlösung anbieten zu können. In diesem Sinne ist Komplexität nicht zu bekämpfen, sondern als Konzept für eine agile Organisation zu verstehen.

Vor 100 Tagen hatte ich noch eine anderen Blick auf Komplexität. Insofern hat sich zumindest für mich die Arbeit schon gelohnt. Wie ist es Euch ergangen? Darf’s noch etwas mehr sein? Und wenn ja, wovon?

Geht Selbstorganisation von selbst?

Die agile Idee basiert wesentlich auf der Idee der Selbstorganisation. Warum aber ist die Auseinandersetzung mit entsprechenden Methoden und Vorgehen überhaupt nötig, wenn sich die Organisation doch von selbst organisieren soll? In vielen Unternehmen und Institutionen wird so aktiv gegen Selbstorganisation organisiert, so dass wir sie als Prinzip erst wieder möglich machen müssen. Um sowohl dem Rätsel als auch der Lösung für Selbstorganisation auf die Spur zu kommen, sollten wir uns zunächst anschauen, was Selbstorganisation bzw. selbstorganisierte Systeme auszeichnet. Es gibt vier Bedingungen für Selbstorganisation: Komplexität, Selbstreferenz, Redundanz und Autonomie.

Komplexität kann über die Anzahl möglicher Zustände eines Systems beschrieben werden, wobei die Komplexität zunimmt, je mehr Zustände das System annehmen kann. Die praktische Übersetzung können interdisziplinäre Teams sein, die aufgrund der Mischung an Kompetenzen mehr Lösungsansätze erdenken können als monothematisch aufgestellte Teams.

Selbstreferenz ist nicht etwa ein Widerspruch zur Offenheit eines Systems, sondern vielmehr die Fähigkeit eines Systems innerhalb der eigenen Grenzen Reaktionen auszulösen. Retrospektiven als Teil der agilen Methodik sind ein gutes Beispiel für Selbstreferenz. Das Team diskutiert intern die eigenen Abläufe und Prozesse und beschließt dabei direkt auch das Vorgehen gegen ungewollte bzw. die Verstärkung gewollter Praktiken.

Redundanz bedeutet für ein selbstorganisiertes Team, dass es keine klare Gewaltenteilung wie z.B. in hierarchischen, industriellen Organisationen gibt, bei denen eindeutig zwischen Organisierenden und Ausführenden getrennt wird. In einem selbstorganisierten Team kann jeder verschiedene Funktionen einnehmen.

Autonomie ist die Fähigkeit eines Systems, seine internen Abläufe frei zu gestalten. Dies soll aber nicht heißen, dass es keinerlei Abhängigkeit bzw. Austausch mit der Außenwelt gibt. So erhalten die Entwickler in einem klassischen Scrum Team zwar von außen ein Ziel, wie dieses aber erreicht wird, kann das Entwickler-Team autonom entscheiden.

Insbesondere die Begriffe Redundanz und Autonomie zeigen recht deutlich, dass Selbstorganisation aktiv etabliert werden muss, da sie zum Teil im Widerspruch mit den klassischen Organisationslehren stehen. Wenn wir Selbstorganisation wollen, dann müssen wir zulassen bzw. ermöglichen, dass sich komplexe Teams mit hoher Autonomie zusammenfinden dürfen, deren Mitglieder in verschiedene Rollen schlüpfen können und die die Organisation aus eigener Kraft weiterentwickeln wollen. Welcher der Aspekte ist aus Eurer Erfahrung die größte Herausforderung?

agile descaling statt scaling agile

Die Vorteile und Erfolge agiler Organisation werden häufig direkt verstanden und akzeptiert, wenn man sie anhand klassischer agiler Teams (ca. 7 Personen) diskutiert.  Zwangsläufig werden aber Zweifel laut, dass dies in diesem kleinen Kontext ja ganz toll funktionieren mag, sich aber nicht darüber hinaus anwenden lässt. Scaling agile ist hier das viel diskutierte Schlagwort. Für mich ergeben sich daraus zwei Erkenntnisse: zum einen scheint es für viele „normal“ zu sein agil zu handeln, solange der Rahmen klein genug erscheint. Zum anderen scheint es aber eine Grenze zu geben, ab der man groß und damit anders denken und handeln muss.

Der erste Punkt lässt sich leicht erklären, denn agiles Vorgehen ist ja an sich nichts neues oder etwas, dass wir im Grundsatz erlernen müssten. Selbstorganisation ist ein Kernprinzip der Natur und des Menschen. Dafür brauchen wir keine agilen Methoden und Konzepte und auch keine besonderen Begriffe. Die Agilität liegt uns so zu sagen im Blut. Man schaues sich z.B. eine Horde Kinder an, die in kürzester Zeit eine umfassende Spielwelt erschafft. Dies passiert ohne Projektplan, geregelte Retrospektiven oder Anleitung. Es sei denn, die Großen mischen sich zu sehr ein 😉

Warum aber können wir uns dies nicht als natürliches Prinzip für eine ganze Organisation vorstellen? Wir verfallen direkt in die alt hergebrachte industrielle Logik und denken in Abteilungen, Hierarchie, Entscheidungs- und Eskalationsstufen. Wir suchen für scaling agile eine Lösung in Form eines denifinierten Prozess und klaren Strukturen und übersetzen somit den agilen Gedanken in die „alte“ Welt bzw. versuchen agil innerhalb der bestehenden Systeme zu denken. Und genau hier liegt das Problem. Wir verlernen scheinbar im Berufsleben unsere natürliche Begabung zum agilen, d.h. selbst organisierten Vorgehen. Dabei sind wir so erfolgreich, dass es uns gar nicht mehr in den Sinn kommt, überhaupt aus dieser Richtung über Dinge nach zu denken.

Was wäre also, wenn wir auf die Frage nach scaling agile mit der Gegenhypothese agile descaling antworten würden? Statt agile Gedanken in unsere bestehenden Welt zu transformieren, sollten wir mit dem agilen Gedanken unser Welt transformieren. Dort wo heute agile Systeme in Organisationen implementiert werden, könnte im Gegenentwurf versucht werden, einen evolutionären Ansatz zu wählen, bei dem sich die Organisation freiwillig von innen heraus verändert. Agile descaling könnte in diesem Sinne also bedeuten, dass die Transformation an sich agil, d.h. selbstorganisiert stattfindet. Wie die Organisation, die Rollen und Verantwortlichkeiten dann aussehen, weiß man dabei natürlich erst am Ende bzw. immer nur im aktuellen Moment der Betrachtung. Aber darf man überhaupt von einer agilen Organisation sprechen, wenn die Strukturen und Prozesse im Grundsatz vorgegeben wird, wie es bei vielen Transformationsprojekten ja der Fall ist? Das klingt doch irgendwie eher nach Wasserfall als nach agil, oder?