Lean Change Management

Im Modul AO40 Agile Transformation hatten wir die Gelegenheit, mit Pit in die Prinzipien von Lean Change Management, einzutauchen. Kurz erklärt basiert LCM auf dem Prinzip, dass ein Problem gelöst werden soll. Weiter baut das Modell auf folgenden Pfeilern auf:

  • Das Veränderung ist von einem Zweck und einem Sinn getrieben.
  • Die Veränderung findet in einer Iteration von Planung und Umsetzung statt.
  • Bestehende Methoden werden adaptiert.
  • Die betroffenen Personen stehen im Vordergrund.
  • Veränderungen werden zusammen ausgelöst.

Als Dach über diesen 5 Pfeilern steht die Feedback Kultur.

Weiter lebt LCM von der coolsten Methode, welche ich im CAS Agile Organisation kennengelernt habe, nämlich von der “Mojito Methode”. Spass beiseite, die Methode nennt sich wirklich so. Sie soll aber zeigen, dass durchaus mehrere Methoden und Modelle wild gemixt werden können, um eine Transformation anzugehen und durchzuführen. Dieser Ansatz gefällt mir. Jedes Problem, jedes Team und jeder Kontext hat seine Spezialitäten, seine Stärken und seine Schwächen, und LCM zeigt auf, dass nicht nach dem Motto “One fits all” ein Vorgehen für alles passt.

Wenn dieser Rahmen abgesteckt ist, kann die LCM Engine gestartet werden. Dabei geht es um einen Kreislauf, bei dem zuerst Grundlagenwissen erarbeitet werden muss, sogenannte Insights. Ziel ist es, nicht wie wild an vielen Schrauben zu drehen und am Schluss nicht zu wissen, was jetzt eigentlich funktioniert hat und was nicht. Mit den Insights wird das Wissen aufgebaut, um Optionen auszuarbeiten. Somit erhält man zielgerichtet einen Katalog von Möglichkeiten, welche Sinn machen, daraus Experimente abzuleiten. Bei den Experimenten ist es wichtig, sich im Vorfeld Gedanken darüber zu machen, was sich wie verändern sollen. Diese Hypothesen müssen auch überprüfbar sein, damit gemessen werden kann, ob ein Experiment erfolgreich war oder nicht. Und auch diese Messung erfolgt in einem Kreislauf, bei welchem ein Experiment zuerst vorbereitet, anschliessend durchgeführt und zum Schluss reviewed wird. Und wenn diese Iteration in der Iteration abgelaufen ist, beginnt die Aufnahme von neuen Insights und somit der erneute Start der nächsten Iteration.

Ich möchte dieses Mal im Blog weniger darauf eingehen, was alles im Modul vermittelt wurde, sondern, wie ich das neue Wissen in meine Arbeit übertragen kann.

Mein konkreter Fall

Ich bin Scrum Master in einem Team von Software Entwicklern bei der Mobiliar. Wir arbeiten nach der SAFe Methode und innerhalb vom Team mit einem Scrum Board in Jira. Damit sind alle Change Stories des Teams sauber abgebildet.

Neben den Change Aufgaben haben wir auch Run Aufgaben. Diese werden in der Regel nicht mit Stories abgebildet, da sie meistens nicht geplant werden können. Aus diesem Grund haben wir die Grundkapazität mit einem Slack von 40 % reduziert. Bei Produktionsabbrüchen wird vom System direkt ein Bug in Jira erfasst, diese Bugs werden aber nicht geschätzt und laufen somit auch im Slack mit. Weiter haben wir ein nicht an Jira angebundenes Ticketing System sowie eine Arbeiten “auf Zuruf”. Die Run Aufgaben werden also nicht zentral administriert.

Dieses Vorgehen ist für die Mitarbeiter einfach in der Handhabung, da fast kein administrativer Aufwand entsteht. Leider haben wir dadurch auch keine Übersicht, was wir wo in Run Aufwände investieren. Zudem ist nie klar, ob ein Problem nur als Hack für dieses Mal aus der Welt geschafft wurde, oder ob eine nachhaltige Lösung erzielt werden konnte. Wenn ein Hack das Problem gelöst hat, geht die nachhaltige Lösung aber meistens verloren, da diese auf keinem Radar mehr erscheint.

Zwar ist allen klar, dass für solche nachhaltige Lösungen Stories im Change Bereich erstellt werden sollen, aber es geht meistens unter. Somit verlieren wir hier viele Möglichkeiten, unsere Betriebsaufwände auf längere Zeit zu reduzieren.

Um das Problem anzugehen, will ich diese Thematik im Team durch Visualisierung in den Mittelpunkt rücken. Die Change Stories werden wir wie gewohnt in elektronischer Form in Jira weiterbearbeiten. Daran haben sich alle gewohnt und das funktioniert auch sehr gut.

Mit den Run Themen möchte ich zurück zum Ursprung unserer agilen Arbeitsform, nämlich zu einer physischen Visualisierung an einer Wand. Damit können wir im Daily alle RUN Issues kurz ansprechen, neue Probleme aufnehmen und den Fortschritt der Problemlösungen zusammen anschauen. Damit die Nachhaltigkeit der Problemlösungen erhöht werden kann, will ich nach Abschluss eines Problems mit dem Team überprüfen, ob noch etwas getan werden kann oder muss, damit das Problem nie wieder auftreten kann. Wenn ja, wird daraus eine Story im Change-Teil gemacht und mit dem PO zusammen besprochen, damit die nötige Prio vergeben werden kann. Durch das physische Board verschwindet ein Problem nicht einfach durch die Anpassung von einem Status, das Problem bleibt am Board!

Und hier kommt jetzt die Verbindung zu den Canvases, welche wir bei Pit kennengelernt haben. Meine obenstehende Motivation für diese Veränderung will ich nicht einfach dem Team auf’s Auge drücken. Hier bietet sich die Gelegenheit, mit der Erarbeitung von einem Canvas weitere Insights in den Prozess der Run Aufgaben zu beleuchten und zu diskutieren. Und zudem generieren wir so die Möglichkeit, unser Tun immer wieder gegenüber dem zusammen erarbeiteten Canvas zu prüfen und zu hinterfragen. Dem PO und dem Release Train Eingineer können wir aufzeigen, dass der eingeplante Slack von 40 % gerechtfertigt ist, und dass sie aktiv auf die mittelfristige Reduktion des Slacks Einfluss nehmen können, wenn sie kurzfristig in Change Stoires für nachhaltige Problemlösungen investieren. Und da die Verteilung der Run Tasks im Team nicht gleichmässig ist, haben auch Mitarbeiter mit vielen Run Tasks die Möglichkeit, ihre Arbeit besser zeigen zu können.

Ich bin gespannt, wie das Team diesen Vorschlag zur Prozessoptimierung bzw dieser Transformation aufnehmen wird und wie die Resultate daraus sein werden. Durch die Aufarbeitung des Themas durch die Erstellung eines Canvas wird die Problemlösung zu einer Teamdisziplin, welche das Team selbst herbeigeführt hat. Wir haben gelernt, dass der Mensch Veränderungen aus eigener Motivation viel besser annimmt aus vorgegebene Veränderungen. Und genau diesen Effekt soll das Vorgehen auch auslösen. Zudem bin ich gespannt, wie viel Aufmerksamkeit das Board in der ganzen Organisation generieren wird.

Weitere Methode aus dem Werkzeugkoffer

Die Erstellung einer Value Stream Map scheint mir ein sehr gutes Mittel für die Ermittlung von Engpässen in einem teamübergreifenden Prozess zu sein. Da sich alle beteiligten einbringen können, kommt die Erkenntnis von der Basis und wiederspiegelt das IST, und nicht die Annahme vom mittleren Management, wie es sein könnte. Es wird bewusst visualisiert, wo und wie ein Auftrag durch eine Unternehmung läuft. Dabei wird analysiert, wie lange die Durchlaufzeit und die tatsächliche Arbeitszeit von Prozessschritt zu Prozessschritt ist.

Da hier nicht nur ein Team, sondern alle betroffenen Personen zu einem Prozess involviert werden müssen, bedarf es einer gründlichen Vorbereitung. Man muss wissen, was man am Ende eines solchen Workshops haben muss und jeder beteiligte muss sich auf seine Aufgabe vorbereiten können. Ich kann mir gut vorstellen, eine solche Value Stream Map zusammen mit den Kollegen aus dem Business aufzuzeichnen, um feststellen zu können, warum ein Epic zuerst sehr lange Runden dreht, bis er endlich in er Entwicklung zur Umsetzung eingeplant werden kann.

Fazit

Das Thema Transformation bringt das Gelernte aus dem ganzen CAS zusammen. Aus diesem Grund habe ich mich entschieden, den Hauptfokus des Blog-Eintrages auf den Transfer des angeeigneten Wissens in meine Aufgabe als Scrum Master zu legen. Das ganze Modul war abwechslungsreich, und die Bezugspunkte zur Praxiserfahrung von Pit haben mir sehr gut gefallen. Es gäbe noch viele spannende Punkte, insbesondere alles rund um den Menschen in einer Transformation, aber das würde den Rahmen des Blogs sprengen. Es zeigt aber auch auf, dass ich noch einiges aus diesem Modul in meine Arbeit mitnehmen werden kann.

Mit einem Besuch der Medienmacher und einem letzten Halbtag mit Peter geht dieses CAS bereits wieder zu Ende. Nicht alles war optimal, aber das hatte ich bei der ersten Durchführung von einem CAS auch nicht erwartet. Ich wurde aber positiv überrascht, wie viel ich in meine Arbeit mitnehmen kann. Vielen Dank dafür!

Modul 5: Agile Transformation:
Motto: Was möchte ich meinem Kollegen aus dem letzten Modul weitergeben? Was
war für mich wichtig? Was habe ich gelernt?

Aus dem Teil Lean Change-Management, «Fokus Mensch»:

Hier nehme ich viele gute Wiederholungen mit; vor allem die Art und Weise der Präsentation der Themen, die Herangehensweise hat mir gefallen. Nuggets zum Mitnehmen und bei zukünftigen Changeprozessen (sorry; Transformationsprozessen… siehe meinen letzten Blog und die Definition von Thomas wegen der Terminologie):

• Gefühlsebene, Emotionen: kann ich, können wir im Team selber über eine Veränderung entscheiden, dann sind die zu erwartenden Gefühlen eher positiv. Kann ich, können wir das nicht, dann ist die Wahrscheinlichkeit, dass negative Emotionen «getriggert» werden eher höher. Damit eine Transformation gelingt, ist es matchentscheidend, dass sie von möglichst vielen Betroffenen getragen wird. Löst etwas negative Gefühle aus, wird es eher nicht mitgetragen. Also: «Betroffene zu Beteiligten machen»: Die Wichtigkeit dieses fundamentalen Satzes aus der Organisationsentwicklung wird nochmals deutlich.
• SCARF-Model: Status – Certainty – Autonomy – Relatedness – Fairness. Oder, wie ticken Menschen? Ein kleiner psychologischer Ratgeber für Manager, angereichert mit Erkenntnissen aus der Hirnforschung… Ja! Genau! So laufen diese Prozesse in uns ab. Wir, die wir doch so rational sein möchten und im Speziellen auf Management-Ebene so sehr auf die Sachebene pochen… müssten wir nicht endlich eingestehen, dass wir doch sehr irrational-rational funktionieren und, dass 2.4 Millionen Jahren Entwicklung einfach prägend sind? Das heisst konkret: vor allem in Veränderungsprozessen (aber nicht nur in Veränderungsprozessen) gilt es, diese Einflussfaktoren zu berücksichtigen, diese mit den Menschen zu thematisieren, diese mit den Menschen zu gestalten.
• Ich brauche oft ein ähnliches Modell aus der Salutogenese: das Kohärenz-Gefühl nach Antonowsky (siehe Bild unten; Quelle: adaptiert nach: https://de.wikipedia.org/wiki/Aaron_Antonovsky).

Die Schlüsselwörter sind hier «Verstehbarkeit», «Sinnhaftigkeit» und «Handhabbarkeit». Nur wenn alle diese drei «Schlüsselwörter» bedient werden können, sind Menschen bereit sich auf die Veränderung einzulassen, mitzumachen, mitzugehen. Fehlt eines dieser «Schlüsselwörter» so ist die Gefahr gross, dass die notwendige Energie nicht aufgebracht wird, respektive in Abwehr ummünzen kann. Sehr spannend ist in diesem Konzept, dass Antonowsky damit untersucht hat, was es braucht, um gesund zu bleiben. Keine Managementlehre! Umkehrschluss: fehlt die Verstehbarkeit, die Sinnhaftigkeit, die Handhabbarkeit oder zwei davon oder sogar alle drei, so werden Menschen krank! Aus meiner beruflichen Praxis als Organisationsentwickler durfte ich dieses «Schema» für den Check der neu entwickelten Strategie mit einem GL-Team anwenden. Nach erster Skepsis und Irritation (was hat Strategie mit Salutogenese zu tun?), wurde der Nutzen schnell erkennbar. Die Strategie auf Hochglanzfolien war zwar sehr schön… aber nach dem «Abklopfen» mit den «Schlüsselwörtern» wurde ersichtlich, dass sie schlicht nur für GL oder Managerebene verstehbar war; und, dass das Strategiepapier keinen Hinweis auf Handhabbarkeit hatte. Kurz, die Gefahr war sehr gross, dass das Informationsvorhaben Angst auslösen würde. Die Kommunikation wurde daraufhin überarbeitet. Ein schönes Erlebnis. Und lehrreich, wie auf ersten Blick managementfremde Modelle und Themen dem Management sehr dienlich sein können.

Aus dem Teil Lean Change-Management, «Fokus Gemeinsames Verständnis»:
• Haltung-Verhalten-Kontext: Dieses Zusammenspiel ist ein besonders wichtiges Thema, welches in einer Transformation zu beachten ist. Eine Haltung wird vor allem am Verhalten sichtbar. Ein Verhalten passt mehr oder weniger zu einem spezifischen Kontext. Also: möchte ich zum Beispiel ein agiles Mindset im Team «entwickeln» operiere ich eigentlich auf der Haltungsebene. Dass Haltungen (Charakter einer Person) aber wenig beeinflussbar sind, das ist seit langem erkannt. Somit werde ich es mit Anforderungen und Commitment zu präzisen Verhaltensänderungen schon etwas einfacher haben. Ich kann zum Beispiel agile Teamspielregeln einführen, mit diesen Regeln einen Lernprozess starten, etc. Oder, und da gehe ich einig mit dem im Modul präsentierten Modell, ich kann am Kontext arbeiten. Und das ist meistens der viel einfachere Weg. Bedingung ist, dass ich sehr gut überlege (und das Team dazu einbeziehe), welcher Kontext, dann welches Verhalten fördert. Beispiel: ist Team-Interaktion in einem Workshop mit 20 Personen wichtig, dann kann/wird eine Kinobestuhlung des Workshop-Raumes eher hinderlich wirken. Kleine Arbeitsinseln für Maximum vier Personen und die Definition von und das Commitment zu Interaktionsspielregeln werden eher förderlich wirken.
Ich fasse zusammen:
o Haltung: wir sind, was wir immer wieder denken und glauben!
o Verhalten: wir sind, was wir immer und immer wieder tun!
o Kontext: Kontext prägt Verhalten!

Die Konsequenz lautet: Ein gewisser Kontext ruft ein gewisses Verhalten hervor. Treffe ich andauernd dieselbe Kontext-Realität, reagiere ich auch andauernd mit einem spezifischen Verhalten. Diese Wiederholung führt schlussendlich zu einem impliziten Glauben, welcher wiederum das Verhalten verstärken wird. Das vielleicht anschaulichste Beispiel ist das von den Elefanten, die von ihren Mahuts an einer kleinen Schnur angebunden werden und nicht weglaufen. Und, da sie als Baby-Elefant gelernt hatten, dass diese Schnur unzerbrechlich ist (war sie ja damals für das Baby auch), lassen sie sich auch als erwachsene Elefanten davon «binden».

 

 

Nun: für ein agiles Mindset braucht es meiner Meinung nach unbedingt die Arbeit an allen drei Ebenen (siehe Grafik oben). Und, auch wenn dies jetzt als Widerspruch zur oberen Erläuterung tönt: An der Arbeit mit der Haltung geht keinen Weg vorbei (der rote Pfeil in der Grafik). Ein CEO, eine GL, eine Führungskraft die von den Mitarbeitenden «Agil» einfordert und nicht die entsprechende Haltung dazu hat, nicht das entsprechende, kohärente Verhalten zeigt wird sofort «entlarvt» und löst Unbehagen aus. Warum? Weil er/sie mit dieser nicht kohärenten oder kompatiblen Haltung für die Mitarbeitenden einen KONTEXT kreiert, der das entsprechende Verhalten hervorrufen wird. Was es heisst, ein agiles Mindset, eine agile Haltung als Top-Manager oder Führungskraft zu haben, ist für eine gelungene Transformation extrem wichtig. Diese Arbeit kann nicht delegiert werden; oder von externen Beratern geleistet werden; oder durch die Einführung von agilen Frameworks übernommen werden; oder durch weiss was ich für Methoden und Appelle eingefordert werden. Das ist Managementaufgabe, Bewusstseinsbildung auf obersten Ebenen… ein grosses Stück Arbeit, die oft nicht gerne getan wird. Ein Fehler!

Aus dem Teil Lean Change-Management, «Fokus Lean Change Cycle»:

• «Hot Seat-Übung»: Dieses Tool, diese Übung würde ich nie «Hot – Seat» nennen. Das kann falsche Assoziationen bei den Teammitgliedern, bei den Teilnehmern auslösen. Beim «Hot Seat», «heisser Stuhl» setzt sich ein Teilnehmer auf den (eben heissen) Stuhl in der Mitte eines Stuhlkreises. Dann gibt der äussere Kreis Feedback (mündlich und schriftlich) zu der Person in der Mitte. Sind die Teilnehmer nicht geschult in Feedback geben und/oder haben sie bereits einen gröberen Konflikt mit der Person… wird die Situation wirklich heiss. Und so haben wir es ja nicht gelernt. Im Gegenteil. Die Person auf dem Stuhl hat ein Anliegen. Die Personen herum dienen als Ideengeber, Lösungsmöglichkeiten-Generier, Gedanken-Öffner… ähnlich wie bei einem klassischen kollegialen Teamcoaching oder Intervisionssetting. Das Umdrehen (im kollegialen Teamcoaching sitz der Fallgeber dazu hinter die für ihn arbeitenden Gruppe) hat seine Gerechtigkeit: die Interaktion mit dem Thema-/Fragengeber zu unterbinden. Das «Diskutieren» zu reduzieren. Die unausweichliche und oft unbewusste Bewertung in «gut oder schlecht» der Ideen von dem Menschen, der sich gerade äussert zu unterbinden. Es ist leider so: je nachdem wer was sagt, höre ich anders zu! Die Bewertung der Ideen / der Lösungsmöglichkeiten in Nutzen und Aufwand fand ich auch sehr spannend. Bauch einschalten und die kollektive Intelligenz nutzen! Wunderbar. Eine Variante, von Markus empfohlen, empfehle ich gerne weiter: Magic Estimation (siehe: http://campey.blogspot.com/2010/09/magic-estimation.html). Danke Markus!
• Beim Lean Change Cycle (siehe Grafik unten links; Quelle: Seminarunterlagen, Peter Zurkirchen) fand ich das Diagramm «Cost & Value» für die Bewertung von Optionen sehr hilfreich.

 

 

Wir haben in einem zweiten Schritt das erweiterte Modell «Aufwand-Nutzen-Risiken» (siehe Grafik nebenan; rechts) von Thorsten Scheller (Quelle: Torsten Scheller; Auf dem Weg zur agilen Organisation; Vahlen Verlag; 2017) für die Bewertung der Optionen in unserer Projektarbeit gewählt. Es ist schon so: viel mehr als die genaue «richtige» Positionierung im Diagramm geht es (einmal mehr!) um den Prozess im Team: Welche Option hat welchen Nutzen? Warum hoch, mittel, niedrig? Mit welchem Aufwand und mit welchem Risiko? Die Beantwortung von diesen Fragen im Team und die Positionierung weiterer Optionen relativ zu den bereits gesetzten Optionen… das bringt so viel mehr Erkenntnisse und Klarheit als 1000 Seiten Statistiken über dasselbe Thema! Dieses Tool werde ich sicherlich vielmals in meiner Praxis integrieren.

Von Agile Basics über Personal und Team Agility kommen wir nun zur Agilität der gesamten Organisation. Wir haben die Agilität auf allen Ebenen analysiert und trotzdem, stellt sich die Frage – ist es wirklich die Agilität, was die Lösung aller Probleme in unserer Organisation sein soll? Darauf gibt es ja schon eine vorbereitete Antwort – nein, sicherlich nicht. Es hilft uns aber die Probleme früher festzustellen.

Weiterer oder besser gesagt Hauptsinn der Agilität einer Organisation ist die Fähigkeit sich schnell anpassen zu können um die Veränderungen auf dem Markt folgen zu können. Eine agile Organisation reagiert erfolgreich auf den neuen Wettbewerbern, neue Marktentwicklung, neue Technologien und allgemein auf die veränderten Marktkonditionen. Unter diesen Umständen, in heutiger komplexen Welt, könnte man sogar die Existenz der Unternehmen ohne Agilität in die Frage stellen.

Im Rahmen des Moduls Organizational Agility haben wir uns mit grundsätzlichen Einflüssen auf unsere Organisation auseinandergesetzt und was uns dazu führt die Agilität in gesamter Organisation einführen zu wollen. Es sind folgende Umstände, welche eine ‚neue’ Form und Arbeitsweise bedingen:

  • komplexe Fragestellungen
  • hohe Geschwindigkeit
  • geringe Fehlertoleranz
  • hohe Kompetitivität
  • schnelle Veränderung

Es lässt sich daraus ableiten, dass die folgenden Eigenschaften in einer Organisation notwendig sind um mit oben genannten Themen erfolgreich umgehen zu können:

  • starke Selbstorganisation
  • hohe Kommunikationsdichte
  • dezentrale Entscheide
  • hohe Transparenz
  • fail fast – schnelles Feedback
  • wenig Reibungsverlust
  • schnelle Anpassung

Diese Erkenntnisse führen uns zu im Modul Organizational Agility vorgestellten agilen Organisationsformen Holocracy und Sociocracy. Faszinierende und gleichzeitig erschreckende Formen mit vielen Widersprüchen an sich, welche vielen offenen Fragen und Skepsis-Gefühl hinterlassen. Die offene und selbstorganisierte, aber gleichzeitig höchst strukturierte und von Regeln geprägten Formen. Die Modelle, welche in meinen Augen neben oben erwähnten Eigenschaften einen sehr hohen Niveau des Verstandes und der Reife voraussetzen.

Prozesse und Abläufe in Holocracy und Sociocracy sind wie folgt definiert:

  • die Ausrichtung aller Beteiligten erfolgt durch den purpose der Organisation
  • die Aufbauorganisation besteht aus verschachtelten Kreisen
  • die Kreise sind mittels Doppelvertretung verbunden
  • es wird unterschieden zwischen Governance– und operativen Themen
  • Entscheidungen werden durch Konsent gefällt
  • eine Person kann mehrere Rollen innehaben
  • es wird von jeder Person erwartet, dass sie in ihren Rollen Spannungen zum purpose wahrnimmt und auch kommuniziert

 

Unabhängig von der Organisationsform eine wichtige Frage, die sich bei der Einführung der Agilität in die gesamte Organisation stellt, ist die Skalierung.

In der Praxis kommt sehr oft vor, dass ein Unternehmen mit Agilität in kleineren Teams oder Abteilungen (meistens Entwicklungsabteilung) anfängt und die Erfahrungen sammelt. Danach geht es darum wie man die Agilität in ganzer Organisation verbreiten kann, bzw. in welchem Grad man die agilen Methoden in ganzer Organisation sinnvoll einsetzen kann.

Bei der Skalierung ist es zu überlegen inwieweit lassen sich die agilen Methoden auf mehreren Teams oder sogar ganze Organisation übertragen. (Wie) kann die Zusammenarbeit zwischen den agilen Teams koordiniert werden, so dass erzielte Effizienzgewinn ermittelt werden kann.

Bei der agilen Skalierung unterscheidet man zwischen der vertikalen und horizontalen Skalierung.

Wenn mehrere agile Teams denselben Ausschnitt aus der Wertschöpfungskette abdecken, spricht man von vertikaler Skalierung.

Bei einer horizontalen Skalierung geht es darum, dass die agilen Arbeitsmethoden auch auf andere Aufgaben in der Wertschöpfungskette einer Organisation ausgeweitet werden.

 

Ganz eng zu der Skalierung steht die Definition der Aufbau- und Ablauforganisation. Die Aufbauorganisation bildet das hierarchische Gerüst einer Organisation und ihre Rahmenbedingungen, einfach gesagt das Organigramm. Es befasst sich mit Aufgaben, Rechten, Kompetenzen und Verantwortungen im Unternehmen. Die Ablauforganisation hingegen regelt die ablaufenden Arbeits- und Informationsprozesse. Es ist die räumliche und zeitliche Struktur der Tätigkeiten in einer Organisation.

Beide Bereiche sind eng miteinander verbunden, so dass es in der Praxis oft zu den Abhängigkeiten kommt und dies führt zu langen Entscheidungswegen oder verlangsamt die Produktion. Durch die Agilität in einer Organisation versucht man die aufbauorganisatorischen Überlegungen in den Hintergrund zu stellen und sich mit dem Fokus auf die Kundenbedürfnisse an die Geschäftsprozesse zu orientieren.

Ein weiteres wichtiges Thema in den agilen Organisationen ist die Führung. Die Führung in agilen Organisationen bedeutet viel mehr als nur Abteilungs- oder Teamleiter sein. Die Führung ist in der ganzen Organisation, nicht nur zwischen Mitarbeitern und ihren Vorgesetzten.

Die Führung wird in drei Arten unterteilt:

  • Strukturelle Führung – die Regel, als Unterstützung oder als Restriktion, interne Prozesse, Räumlichkeiten, Infrastruktur
  • Teambasierte Führung – geteilte Führung, geteiltes Verständnis vom Teamziel, emotionale und psychologische Unterstützung im Team, Selbstorganisation
  • Personale Führung – Selbstverantwortung, persönliche Führungskommunikation

Das Verständnis von Vorhandensein allen diesen Aspekten hat meiner Meinung nach nichts direkt mit Agilitätsgrad einer Organisation zu tun, sondern mehr mit ihrem Reifegrad oder Hierarchiestufe. Gleichzeitig kann man aber auch sagen, dass man in agilen Organisationen darauf sensibilisiert ist, dass es um viel mehr als nur um die strukturelle Führung geht und, dass die Selbstverantwortung und Selbstorganisation auf einem höheren Niveau sind als in der Regel in einer traditionellen Organisation.

 

In diesem Modul haben wir interessante Ansätze für Organisationsformen kennengelernt und auch, wie wir in der agilen Welt skalieren können.
Interessant war auch die Vorstellung der Medienmacher, welche als traditionelles Druckunternehmen vor ca. einem Jahr den Schritt in die agile Welt gewagt haben und von ihren Erfahrungen erzählt haben.

Doch ein Zitat von Ed Schein hat bei mir am meisten nachgehallt:

«Führung ist eine Funktion der Organisation und nicht die Eigenschaft eines Individuums. Führung ist über alle Mitglieder der Organisation verteilt.»

Ebenfalls eine wichtige Erkenntnis für mich, war, dass eine Organisation unterteilt werden muss in eine Aufbau-Organisation und in eine Ablauforganisation.

 

Organisationsformen

Wie einleitend erwähnt haben wir interessante und für mich neue Organisationsformen kennengelernt.

Holacracy

https://de.wikipedia.org/wiki/Holokratie

 

Mit Holacracy werden klassisch-hierarchische Organisationsstrukturen über Bord geworfen, indem es keine eigentliche Hierarchie mehr gibt. Die Organisation strukturiert sich über folgendes Regelwerk:

–      Personen übernehmen (auch mehrere) Rollen, die dem Zweck der Organisation dienen

–      Kreisstrukturen als Aufbauorganisation

–      Doppel-Verbindungen zwischen den Kreisstrukturen

–      Unterteilung in Governance- und operative Themen

–      Konsent statt Konsens

In Holacracy steht der Zweck der Organisation über allem. Wenn nun irgendwo Spannungen entstehen, welche dem Zweck zuwiderlaufen, muss die Struktur (Aufbauorganisation) diskutiert werden und allenfalls mit neuen Rollen aufgestockt werden und diese von Personen übernommen werden. Falls die neue Rolle den Zweck nicht erfüllt, wird die Person, welche die Rolle übernommen hat, dies rasch wieder kommunizieren und die Spannung muss anderweitig verringert werden. Nicht die perfekte Lösung wird gesucht, sondern eine brauchbare, und auch nicht für immer, sondern für jetzt mit den aktuell zur Verfügung stehenden Informationen.

Holacracy eignet sich sicherlich besser für kleinere Unternehmungen, wie Start-ups, welche auf der grünen Wiese beginnen können, jedoch lebt mit dem Onlinehändler Zappos eine Firma mit über 1’500 Mitarbeiter diese Organisationsform.

 

Sociocracy 3.0

https://patterns-de.sociocracy30.org/introduction.html


Sociocracy wird schon seit über 150 Jahren eingesetzt und vertrat schon damals das Gedankengut, dass die Individuen gleichberechtigt sind und Entscheide auf dem Prinzip des “Konsent” herbeigeführt werden sollten.

Unter Sociocracy 3.0 versteht man die Weiterentwicklung obigen Gedankenguts und die Bereitstellung einer umfangreichen Sammlung von Ideen (Mustern), die sich in Organisationen als hilfreich erwiesen haben, um Produktivität, Zusammenarbeit und Zufriedenheit zu verbessern.

Der Vorteil von Sociocracy besteht darin, dass sie Mittel zur Verfügung stellt, wie man komplexe Herausforderungen meistern kann, ohne ein Unternehmen grundlegend reorganisieren muss.

Alle Muster basieren auf den sieben Prinzipien:

–      Empirismus: Überprüfe alle Annahmen durch Experimente, achte auf kontinuierliche Revision und Falsifizierbarkeit.

–      Konsent: Handle nur, wenn keiner der Betroffenen einen Einwand hat.

–      Effektivität: Investiere Zeit nur für das, was Dich dem Erreichen Deiner Ziele näherbringt.

–      Gleichstellung: Beziehe Menschen in die sie betreffenden Entscheidungen und deren Entwicklung ein.

–      Transparenz: Mache alle Informationen für jeden in der Organisation zugänglich, es sei denn, es gibt einen wichtigen Grund für Vertraulichkeit.

–      Verantwortlichkeit: Handle, wenn es erforderlich ist; befolge, was Du vereinbart hast und behalte die gesamte Organisation im Blick.

–      Kontinuierliche Verbesserung: Bevorzuge inkrementelle Veränderung, um stetiges empirisches Lernen zu ermöglichen.

Zum Abschluss der Betrachtung der erklärten Organisationsformen möchte ich noch einen Bezug zum Unternehmen, in welchem ich tätig bin, machen:

Als Beratungs- und Engineering-Dienstleister im ICT-Umfeld mit ca. 25 Mitarbeitern wären wir eine ideale Zielgruppe für eine der obigen Organisationsformen. Ganz schwache Versuche in Richtung Sociocracy 3.0 kann ich zwar feststellen, doch scheitern oder dümpeln diese Initiativen immer wieder am daily business. Gerne werde ich Sociocracy 3.0 für mich weiter vertiefen und versuchen bei unserer interessierten Geschäftsleitung zu platzieren.

 

Führung in agilen Organisationen

–      Strukturelle Führung
Hier kann unterschieden werden zwischen restriktiven Strukturen, welche einschränken, verhindern, unnötig oder demotivierend sind (was wir so klassisch unter Bürokratie verstehen) oder aber unterstützenden Strukturen, welche förderlich sind, Dinge vereinheitlichen bzw. Klarheit schaffen oder die Koordination zwischen den Teams/Personen unterstützen.

–      Teambasierte Führung
Unter teambasierter Führung versteht man die geteilte Führung im Team. Hierbei sind folgende Voraussetzungen nötig:
Shared purpose: geteiltes Verständnis der Teamziele; Massnahmen zur Fokussierung

Social support: Mitglieder stärken sich emotional und psychologisch untereinander –möglicherweise eher “verdeckte” Akte der Ermutigung und Anerkennung

Voice: Das Ausmass, in welchem Mitglieder eine Stimme haben bei der Zielerreichung

–      Personale Führung
Unter personalen Führung habe ich verstanden, dass das Individuum gefördert wird, Eigenverantwortung zu übernehmen, aber auch über die Kommunikation klar definiert wird, was vom Individuum gefordert wird.
à fördern und fordern sollte im Gleichgewicht gelebt werden.

 

Scaling

Je nachdem, was skaliert werden muss, kommen verschiedene Methoden zum Einsatz. Nachstehend nur eine Aufzählung von Methoden als Platzhalter bzw. Erinnerung, welche wir im Modul diskutiert haben.

–      Plangetrieben (Wasserfall)

–      Mehrwertoptimiert durch Empirie

–      Flow in KANBAN

–      Five Levels of Planning

–      Methoden-Mix aus allen obigen Vorgehen

 

Strategie

Bei der Strategie muss man sich zuerst einmal fragen, “wozu” man die Veränderung nutzen möchte, anschliessend “wo” (überall) man ansetzen möchte und zuletzt “wen&was” sich verändern soll.


Quelle: Unterrichtsunterlagen, CAS Agile Organisation, Thomas Haas

 


Quelle: Unterrichtsunterlagen, CAS Agile Organisation, Thomas Haas

 

Dieser Blog-Beitrag widmet sich der Modul-Zusammenfassung zum Thema „Agile Organisation“ basierend auf den offiziellen Lernzielen.

Übersicht Agile Organisation

L1: Organisationsformen kennen

Holakratie
Holakratie wurde von Brian Robertson in einem kleinen Start-up Unternehmen entwickelt. Holakratie ist einen selbstorganisierenden, multidisziplinären Ansatz auf Unternehmensebene und erfordert eine radikale Unternehmens-Transformation. Es ist eine Praxis für Organisationen, nicht für individuelle Menschen oder etwa Gruppen von Menschen.

Die folgenden Aspekte sind Bestandteile der Organisationsstruktur:

  • Rollen und Zuständigkeiten
  • Organisation in Kreisen
  • Doppel-Verbindungen zwischen den Kreisen
  • Erforderliche Organisation

Soziokratie 3.0
Für die Entwicklung der agilen Organisationsstruktur bietet die Soziokratie 3.0 eine umfangreiche Sammlung von Ideen (Mustern). Ein Muster ist eine Vorgehensweise, welches an den jeweiligen Kontext angepasst und dann weiterentwickelt werden kann.

Mit verschiedenen Ansätzen können komplexe Herausforderungen Schritt für Schritt und ohne grosse Change-Initiativen gemeistert werden.

Alle Muster basieren auf den sieben Prinzipien:

  • Effektivität
  • Konsent
  • Empirismus
  • Kontinuierliche Verbesserung
  • Gleichstellung
  • Transparenz
  • Verantwortlichkeit

L2: Ablauf- und Aufbauorganisation unterscheiden können

Bei der Organisationsgestaltung in Unternehmen sind Ablauf- und Aufbauorganisation von grundlegender Bedeutung.

Ablauforganisation Die Ablauforganisation strukturiert die Tätigkeiten im Unternehmen räumlich und zeitlich.

Es verbindet die Einheiten der Aufbauorganisation und deren Kompetenzen für die Auftragsabwicklung.

Aufbauorganisation Die Aufbauorganisation ist eine Gliederung im Unternehmen, z.B. in Form eines Organigramms.

Es befasst sich mit der Ordnung von Aufgaben-, Kompetenzen- und Verantwortungsinhalte im Unternehmen.

L3: Skalierung von agilen Vorgehen verstehen

Bei der agilen Skalierung geht es um die Gestaltung einer lernenden Organisation.

Die it-agile GmbH hat das Thema „Agile Skalierung“ in einem illustrierten Kurzfilm zusammengefasst: https://www.youtube.com/watch?v=xlgFunfWDAw

Die agile Skalierung kann auf zwei Dimensionen betrachtet werden:

  1. Bei der vertikalen Skalierung werden zusätzliche agile Teams installiert, die denselben Ausschnitt aus der Wertschöpfungskette abdecken.
  2. Bei der horizontalen Skalierung wird der Bereich der Wertschöpfungskette ausgeweitet, für den das Team verantwortlich ist.

 

Vertikale und horizontale Skalierung ([it-agile GmbH])


Prinzipien agiler Skalierung

Die agilen Prinzipien bilden Leitplanken, um das Entstehen der eigenen agilen Skalierungsstruktur abzusichern.
Die folgenden Prinzipien sollten bei der agilen Skalierung besonders beachtet werden:
  • Persönlicher Kontakt
  • Lieferbare Produktinkremente
  • Inspect & Adapt auf Produkt- und Prozessebene
  • Autonome cross-funktionale Teams
  • Transparenz

Praktiken zur agilen Skalierung
Für die agile Skalierung gibt es unzählige Praktiken, welche sich auch aus den Standard-Praktiken von Scrum und Kanban adaptieren lassen.

Die folgenden Praktiken sollten bei der agilen Skalierung betrachtet werden:

  • Organisation Product Ownership
  • Abstimmung der Entwicklungsteams
  • Software-Architektur
  • Entwicklungspraktiken

Skalierungsframeworks
Für die agile Skalierung über den gesamten Projektlebenszyklus hinweg gibt es verschiedene Frameworks:

  • Disciplined Agile Delivery (DAD)
  • Kanban Flight Levels
  • Large-Scale Scrum (LeSS)
  • Scaled Agile Framework (SAFe)
  • Scrum@Scale

Kanban Flight Levels
Kanban lässt sich durch die Anwendung in einem grösseren Kontext über drei Ebenen skalieren.

Ebene Mehrwert
Level 3: Strategisches Portfoliomanagement

Wieso?

  • Das richtige im richtigen Moment tun
  • Reduktion der Warteschlangen
  • Nachfrage und Verfügbarkeit werden über gesamten Wertstrom berücksichtigt
Level 2: Koordination

Wer und Wann?

  • Nachfrage und Verfügbarkeit werden berücksichtigt
  • Weniger Umpriorisierung
  • Arbeiten am richtigen
Level 1: Operative Ebene

Wie?

  • Einfacher Start
  • Visualisierung der Arbeit
  • Verbesserung der Effizienz

Für die erfolgreiche Einführung von Kanban in Organisationen müssen folgende Schritte berücksichtigt werden:

Visualisiere Prozess Regeln und Messgrössen vereinbaren Prozess im Team gemeinsam verändern
  1. Existierende Prozess-Schritte aufzeichnen.
  2. Prozess-Schritte in Kanban-System(en) abbilden.
  3. Service-Klassen identifizieren.
  1. Zielgrössen für Zweck identifizieren (schneller, günstiger, besser, …).
  2. Rituale (Triage, Daily, Retrospektive, Slack) vereinbaren.
  3. Regeln vereinbaren (Definition of Done).
  1. Veränderungen schätzen.
  2. Co-Kreation und Kollaboration fördern.
  3. Mit Retrospektiven Zusammenarbeit verändern -> jede Woche ein kleines Experiment durchführen.

Scaled Agile Framework (SAFe)
Mit dem Scaled Agile Framework (SAFe) können Lean- und agile Methoden unternehmensweit in grossen Organisationen skaliert werden.

Das SAFe-Framework baut auf folgenden Erfahrungen und Wurzeln auf:

  • Iterative Entwicklung
  • Lean Thinking und Systems Thinking, Produktentwicklungsfluss
  • Agile Entwicklung
  • Praktische Erfahrung in der Entwicklung grosser Systeme

Bei der Skalierung unterscheidet SAFe vier Ebenen:

  • Teamebene
  • Programmebene (Agile Release Train)
  • Solution-Ebene
  • Portfolioebene

Scrum of Scrums (SoS)
Ein „Scrum of Scrums“ ist eine skalierte Variante von Scrum über mehrere Teams hinweg. Jedes Scrum-Team wählt einen Ambassador für den teamübergreifenden Austausch in einem übergeordneten Meeting.

Scrum of Scrums (Kenneth S. Rubin, 2012)

L4: Anforderungen an Führung in agilen Organisationen kennen

Was ist Führung?
Ed Schein gilt als einer der Begründer der Organisationspsychologie und definiert Führung wie folgt:

„Führung ist eine Funktion der Organisation und nicht die Eigenschaft eines Individuums. Führung ist über alle Mitglieder der Organisation verteilt.“

Strukturelle Führung
Führung, z.B. mit:

  • Vergütungs- und Anreizsystem
  • Unternehmensweite Regelungen
  • Digitalisierte Prozesse
  • Büroraumgestaltung

Personale Führung
Führung, z.B. mit:

  • Persönliche Führungskommunikation
  • «Fördern und fordern»

Teambasierte Führung
Führung, z.B. mit:

  • Geteilte Führung, laterale Führung
  • Selbstorganisation im Team

Für die geteilte Führung gibt es folgende Voraussetzungen:

  • Shared Purpose: Geteiltes Verständnis der Teamziele, Massnahmen zur Fokussierung
  • Social Support: Mitglieder stärken sich emotional und psychologisch untereinander – möglicherweise eher „verdeckte“ Akte der Ermutigung und Anerkennung
  • Voice: Das Ausmass, in welchem Mitglieder eine Stimme haben bei der Zielerreichung

Referenzen

WTF???

December 7, 2018 | Knowhow-Transfer  |  Leave a Comment

Was sind die wichtigsten Punkte, die ich aus dem Modul Organizational Agility mitgenommen habe?

Strategie:

  • Veränderung ist immer eine «Bedrohung von aussen»
  • Was ist Agilität: Die Fähigkeit auf Veränderungen reagieren zu können
  • Was ist eine agile Organisation: Eine Organisation, die auf Veränderungen reagieren kann
  • Die wichtigste und massgebende Frage ist immer: Für was mache ich das? Wenn ich diese Frage nicht beantworten kann, einfach sein lassen!
  • Es gibt ein Problem und jetzt suchen wir Lösungen. Was ist das Problem?

Scaling:

  • Aus Ungewissheiten sollen Erkenntnisse gewonnen werden -> Unsicherheiten reduzieren, damit das andere planbarer wird. Ein Beispiel dafür ist der Berliner Flughafen. Dieser kann nicht nur mit dem Framework Scrum gebaut werden
  • Ergebnisorientiert: es gibt «Orte» wo man wachsen muss
  • Zielorientiert: es gibt «Orte» wo man etwas sicherstellen muss
  • Es muss immer klar sein, ob wir etwas Kompliziertes oder Komplexes machen. Man kann dadurch alle Vorgehensmodelle (z.B. je nach Phase) mischen
  • Der PO soll die Probleme und nicht die Lösungen beschreiben -> Shift left. Er soll sich immer fragen, welches Problem gelöst werden will/muss.
  • Am Anfang: kurz planen, dann eine erste Lösung präsentieren. So werden Probleme schneller aufgedeckt

Organisationsformen für Agile:

  • Holacracy: kommt aus der Softwareentwicklung
  • Sociocracy 3.0: kommt aus dem sozialen Bereich -> aus der Arbeit mit schwierigen Jugendlichen
  • Sociocracy braucht ein grosses Know-how
  • Was haben die beiden Methoden gemeinsam: Organisationsaufbau besteht aus Kreisen, Doppellink, Governance und Operativthemen, Konsent Entscheidungen, eine Person mehrere Rollen, Spannungen wahrnehmen und kommunizieren, Purpose
  • Benefit: die Verantwortung wird verteilt. Die Entscheidungsfindung ist anders organisiert. Es gibt keine Reorganisationen mehr bei welcher die Verantwortung neu verteilt wird
  • Wenn eine dieser Methoden in einer grösseren Firma eingeführt werden will, müssen mind. 10-15% der Mitarbeitenden (inkl. Führung) die Ausbildung absolviert und ein vertieftes Wissen haben

Ich kann in diesem Blog-Beitrag nicht auf alle Punkte eingehen und picke deshalb einzelne Punkte heraus.

Der PO soll die Probleme und nicht die Lösungen beschreiben -> Shift left. Er soll sich immer fragen, welches Problem gelöst werden will/muss:

Quelle: Unterlagen aus dem Modul Organizational Agility

 

 

Ein gutes Beispiel: Swisscom TV

Die Swisscom hat es geschafft innerhalb von 10 Monaten das Produkt M-Budget auf den Markt zu bringen (produktiv gesetzt).

Produkt: keine Aufnahmen möglich, Fernbedienung von Conrad, Box aus China, etc.

Es ging darum, dass die Swisscom einmal den ganzen Prozess (E2E) durchspielen konnte, von der Entwicklung bis zur Installation beim Kunden zu Hause.

Anschliessend hatte die Swisscom noch zwei Jahre Zeit um alles zu verfeinern, laufend Kundenfeedback einzuarbeiten und schlussendlich ein sehr erfolgreiches Produkt auf den Markt zu bringen, welches sich bis heute etabliert und bewährt hat.

Ein schlechtes Beispiel: SBB Gotthard Basistunnel

Vieles kam anders als 1992 vor der Abstimmung versprochen wurde. Denn was war ursprünglich das Problem, welches gelöst werden sollte?

Gem. Artikel der Aargauer Zeitung am 27.03.2016: Bundesrat und Parlament verwiesen im Abstimmungsbüchlein darauf, dass die Neat Voraussetzung dafür sei, dass die EG (heute EU) den «vorteilhaften Transitvertrag» akzeptiere, der wichtig sei, damit die «Schweizer Wirtschaft Zugang zum EG-Binnenmarkt habe». Wörtlich hiess es im Abstimmungsbüchlein: «Bei einer Verwerfung der Neat-Vorlage würde die Schweiz (…) mit grösster Wahrscheinlichkeit nach wieder mit der Forderung nach einem 40-Tonnen-Korridor unter Druck gesetzt.» Heisst mit anderen Worten, man wollte die 40T Lastwagen auf die Schienen bringen.

Dieses Problem konnte bis heute nicht gelöst werden denn die angrenzenden Länder Deutschland und Italien sind mit ihren Anschlüssen noch nicht soweit um die 40 t Lastwagen auf den Schienen zu transportieren. Somit hat die SBB das eigentliche Ziel mit dem Bau des Gotthard Basistunnels verfehlt.

Fazit:

  • Zuerst überlegen welches Problem gelöst werden muss
  • Kurz planen (ist bei einem Grossprojekt wie dem Gotthard Basistunnel etwas schwierig) und möglichst schnell eine erste Lösung präsentieren. Anschliessend weiter an der Lösung arbeiten und laufend Feedback einholen

Am Anfang: kurz planen, dann eine erste Lösung präsentieren. So werden Probleme schneller aufgedeckt:

Das haben wir anhand des Mittelalter-Spiels Grossherzogtum Oberes Mittelland gelernt.

Die Klasse wurde in verschiedene Gruppen eingeteilt und jedem Team ein Thema (z.B. Marktplatz) zugeordnet. Im Anschluss hat Tom Haas als Gossherzog seine Vision, den Umfang, welchen er haben möchte, vorgestellt. Jede Gruppe hat einen Timekeeper, einen PO und das Bau-Team bestimmt. Der Ablauf war in 3 Iterationen aufgeteilt. Eine Iteration bestand aus folgenden Punkten:

  • Planen
  • Bauen
  • Konsolidieren mit allen Gruppen
  • Retrospektive mit allen Gruppen
  • Ansage vom Grossherzog, was es haben möchte

Bereits nach der ersten Iteration kamen folgende Hauptpunkte zum Vorschein:

Die Brücke hat nicht standgehalten, es waren massive Grössenunterschiede vorhanden, die Gruppen haben unterschiedliche Figuren/Häuser gebaut (stehende und liegende).

In der Retrospektive haben wir festgestellt, dass die Gruppen untereinander zu wenig kommuniziert haben und auch die Anforderungen des Grossherzogs nicht genügend abgeholt wurden.

Fazit: Jede Gruppe hat etwas geplant und schnell geliefert. Anhand dieses Prozesses hat der Feedbackloop optimal funktioniert. Wir hatten sofort Feedback vom Grossherzog. In der Retrospektive konnten wir dann analysieren, wo es Probleme gab, Massnahmen definieren und diese in der nächsten Iteration umsetzen.

Nach drei Iterationen hatten wir dann ein zufriedenstellendes Ergebnis.

Da ich weder in den Unterlagen noch im Internet die komplette Anleitung für dieses Spiel gefunden habe, werde ich es nicht im Alltag der SBB einsetzen. Ich konnte jedoch ein Team begleiten und habe mich für ein ähnliches Spiel entschieden: Lego City

Wie das Arbeiten in agilen Teams funktioniert, lässt sich meist am besten selbst erleben.

Als ersten habe ich eine kurze Einführung gemacht, damit alle den Sinn des Spiels verstehen. Anschliessend habe ich das Team in zwei Gruppen eingeteilt. In jedem Team wurde ein Product Owner (PO) ein Scrum Master (SM) und das Bau-Team bestimmt. Im Anschluss stellte einer der POs die Product Vision vor.

  1. Gemeinsames Erstellen des Product Backlogs (z.B. Kindergarten, Feuerwehr, Auto, etc.)
  2. Planung der 1. Iteration -> 3 Minuten
  3. Durchführung der 1. Iteration -> 10 Minuten
  4. Review/Demo
  5. Retrospektive -> 5 Minuten

Aus der Retrospektive wurden dann Massnahmen definiert, welche bei der nächsten Iteration umgesetzt werden sollen.

Insgesamt haben wir vier Iterationen durchgeführt. Nach der zweiten Iteration habe ich die Schwierigkeit eingebracht, dass die zwei Citys zusammengebracht werden müssen und daraus eine grosse Stadt entstehen soll. Auf die Folgen kann ich hier nicht weiter eingehen, da es den Rahmen dieses Blogs sprengen würde.

Fazit:

  • Die direkte Kommunikation mit den Beteiligten ist sehr wichtig
  • Enorme Effektivität durch dieses Arbeitsvorgehen

Selbstorganisierte Organisationen[1]
Selbst entscheiden und Verantwortung tragen, fördert die Motivation von Mitarbeiterinnen. Beides bieten Soziokratie und Holokratie in maximaler Form. Selbstorganisierte Organisationsformen stellen jedoch hohe Anforderungen an ihre Mitglieder. Rollen und Funktionen müssen laufen geklärt und Konflikte auf gleicher Ebene gelöst werden. Neben den herkömmlichen fachlichen, sind ausgeprägte Fähigkeiten im Bereich soziale Kompetenz und emotionale Intelligenz zwingende Voraussetzung für den Erfolg und die Nachhaltigkeit von Selbstorganisierten Organisationen. Verantwortung für sich und das Unternehmen zu tragen, erfordert vor allem aber auch Mut und Vertrauen in sich selbst.

Für wen also ist diese Organisationsform geeignet, wer erfüllt diese hohen Anforderungen? Es werden vermutlich eher Personen sein, die sich auch den Schritt in die Selbständigkeit oder Gründung einer eigenen Firma vorstellen können. Was bringt diese Personen dazu, sich dennoch in die Fänge eines Grosskonzerns zu begeben? Vielleicht darum, weil ein Unternehmen Sicherheit und Schutz bieten kann. Im Vergleich zur Selbständigkeit werden in einem Anstellungsverhältnis Risiken, insbesondere finanzielle und rechtlich Risiken, an die Inhaber des Unternehmens übertragen. Sicherheit und Schutz haben jedoch ihren Preis. Sofern eine Mitarbeiterin sich nicht vollständig an den genannten Risiken beteiligt, muss sie in Kauf nehmen, dass die selbstorganisierte Organisation und die damit verbundene Entscheidungskompetenz und Verantwortung, Grenzen haben wird und haben muss.

Es stellt sich die Frage, wie eine Sozio- oder Holokratie mit der Verantwortung umgeht, wenn eine Person die Anforderungen nicht mehr erfüllt und auf dem Arbeitsmarkt kaum mehr Chancen hat. Durch die Gesellschaft wird erwartet und durch die Politik gefordert, dass Unternehmen ihre soziale Verantwortung wahrnehmen. Alle Personen die über eine Arbeitsfähigkeit verfügen, sollen in die Arbeitswelt integriert werden. Für ein Unternehmen das vollständig nach den Prinzipien der Holo- oder Soziokratie organisiert ist, wird dies kaum möglich sein. Es wird vor allem dann schwierig, wenn es um die Integration von Personen mit kognitiven Einschränkungen geht. Diese Personen werden nicht in der Lage sein, ihre Bedürfnisse zu äussern und ihre Interessen durchzusetzen. Sie sind darauf angewiesen, dass diese Aufgabe für sie wahrgenommen wird. Dies kann zwar grundsätzlich über neue Rollen und Kreise organisiert werden. Aus Sicht der betroffenen Mitarbeiterinnen entsteht dadurch jedoch bereits eine Form der Hierarchie.

Dies können mit Gründe sein, warum kaum ein Grossunternehmen zu 100% die Prinzipien einer Selbstorganisierten Organisation lebt und umgesetzt hat[2]. Hingegen kann es sinnvoll sein, einzelne Organisationseinheiten nach den Prinzipien der Selbstorganisierten Organisation zu führen. Wichtig wird es jedoch sein, Rahmenbedingungen und Grenzen festzulegen. Nur dann wird es möglich sein, dass selbstorganisierte und klassische Organisationseinheiten erfolgreich funktionieren und zusammenarbeiten.

Hierarchie
Der Hierarchie wird nachgesagt, dass sie nicht natürlich, sondern angelernt ist. Aber warum existiert sie dann auch in der Tierwelt? Agilität ist dann gefragt, wenn rasch Entscheide gefällt werden müssen. Rasches Fällen von Entscheiden, war und ist das nicht genau der Grund für das Bilden einer Hierarchie? Was genau führt dazu, dass Hierarchie das Fällen von Entscheiden verlangsamt? Ein Grund dafür kann sein, dass die Aufgaben, Verantwortung und Kompetenzen für die verschiedenen Hierarchieebenen nicht, falsch oder ungenügend definiert sind. Ein anderer Grund kann sein, dass Hierarchiestufen nicht mehr nur zum Zwecke des Führens und Entscheiden definiert werden. Vor allem in grossen Unternehmen wird als Zeichen der Wertschätzung gegenüber von Mitarbeiterinnen eine Beförderung in Aussicht gestellt. Ein Aufstieg in der Hierarchie ist gleichzeitig mit einem höheren Salär verbunden. Die Zahl der für ein effizientes Entscheiden erforderlichen Hierarchieebenen ist begrenzt, die Anzahl Mitarbeiterinnen die Wertschätzung erwarten ist so hoch wie die Anzahl der Angestellten. Dies führt fast zwangsläufig zu Hierarchiestufen, die aus organisatorischer Sicht nicht erforderlich sind.

Wenn es einem Unternehmen gelingt, diese überflüssigen Hierarchieebenen zu vermeiden oder abzubauen, in dem es andere Formen von Wertschätzung und Lohnpolitik findet, dann kann auch Hierarchie effizientes Entscheiden unterstützen.

Fazit
Wie sich ein Unternehmen auch immer organisiert, es wird nie perfekt sein. Wirklich agil ist ein Unternehmen vor allem dann, wenn es in der Lage ist, sich stets der aktuellen Situation und Begebenheiten anzupassen. Hierfür ist die Art der Organisation nicht entscheidend, sondern die Haltung der Menschen innerhalb der Organisation. Agilität kann nur dann entstehen, wenn Menschen anderen Menschen vertrauen und das ist vermutlich die grösste Herausforderung für ein Unternehmen.

[1] Im Text wird mehrheitlich die weibliche Form verwendet, diese schliesst die männliche Form mit ein.

[2] Siehe auch NZZ Artikel «Der agile Mitarbeiter im digitalen Strudel», Nicole Rütti, 06.12.2018

Bei diesem Blog habe ich mich gefragt: Was ist denn eigentlich in einer Agilen Organisation alles drin? Was sind die Inhaltsstoffe einer Agilen Organisation? Dabei bin ich mir immer unsicherer geworden ob es denn richtig ist von einer Agilen Organisation zu sprechen oder ob es mehr Sinn macht einen anderen Begriff zu verwenden. Unter Agilität versteht man heute ja alles und nichts und das stört mich. Agilität ist IN und gleichzeitig schon verbraucht. Das Tüpfelchen auf dem i war dann noch die Aussage eines Studienkollegen zum Abschluss des Moduls Agile Organisation, welche mich noch mehr angeregt hat genauer darüber nachzudenken. Hier die sinngemässe Wiedergabe „Agilität kann nicht überall eingesetzt werden“ Für mich stimmt diese Aussage eigentlich nicht oder vielleicht doch? Dem möchte ich in diesem Blog auf den Grund gehen.

Hier ein Versuch eine Agile Organisation aufzusplitten:

Inspect & Adapt

Dies ist ein Grundsatz der Agilität, allein dieser Aspekt kann meiner Meinung nach in jeder Organisation angewendet werden. Inspect, wie haben wir was in der Vergangenheit gemacht und Adapt, wie können wir daraus für die Zukunft lernen. Was müssen wir verändern, damit wir in Zukunft noch besser funktionieren. Ich kann mir nicht vorstellen wo dies nicht zur Anwendung kommen kann. Nur ist deshalb ein Unternehmen agil, wenn es einfach aus der Vergangenheit lernt? Vielleicht ist es einfach überlebensfähiger als jene Konkurrenten welche dies nicht tun. Was hat dies nun mit Agilität zu tun, werden sich die meisten Fragen, dass kann ich auch in einer klassischen Organisation, absolut einverstanden.

Iterativ

In stetigen Zyklen denken und diese Nutzen um einen stettigen und raschen Kundenfeedback zu erhalten und um aus gewonnen Erkennntnissen zu lernen. Für mich ebenfalls ein Merkmal das jedes Unternehmen einsetzen sollte und sicherlich auch kann. Ob ein Zyklus maximum 4 Wochen sein darf oder auch länger, dies muss wohl jedes Unternehmen für sich beantworten. Es geht ja auch nicht darum Scrum in eine Organisation zu pflanzen sondern Agilität zu verankern. Wenn man von einem leanen Ansatz ausgeht, braucht es vielleicht nicht mal regelmässige Zyklen, sondern sind z.B. die Kundeninteraktionen Eventgetrieben und so in keinem regelmässigen Zyklus. Für mich gibt es im mindesten 2 verschiedene Zyklen, welche voneinander unabhängig sein können. In der Holakratie werden diese unterschieden um <im System> zu arbeiten oder <am System> zu arbeiten. Diese beiden Handlungsfelder können ganz unterschiedlich getaktet sein. Unter <Im System> versteht man das taktische Meeting, dort geht es vereinfacht um die Wertschöpfung die wir generieren. <Am System> zu arbeiten bedeutet an Rollen und Kreisen also an der Struktur der Organisation zu arbeiten. Ich glaube, dass eine Trennung in taktische und strukturelle Veränderungen durchaus Sinn macht und jeder Organisation helfen kann sich bei Veränderungen zu fokusieren und diese auch bewusst voranzutreiben. Wie lange ein Zyklus dauert, habe ich im Unterricht gelernt, hängt auch vom Produktezyklus ab. Sprich vom ROI eines Produktes. Dies ist natürlich sehr vereinfacht und auch nicht einfach zu berechnen. Da ein Produkt in den wenigsten Fällen in einem geschützten Markt ist und eine Firma in der Lage sein muss auf verschiedene Einflussfaktoren reagieren zu können. Dazu passt dann eine weitere Eigenschaft die ich mit Agilität verbinde.

Anpassungsfähikeit

Wie bereits erwähnt, muss eine Organisation in der Lage sein auf verschiedenste Einflussfaktoren reagieren zu können. Dies fällt einer Organisation sicherlich einfacher, wenn sie dies im Alltag bereits übt und nicht erst im Ernstfall eine solche Anpassung vornehmen muss. Konzentriert sich zum Beispiel ein Flugzeughersteller zu sehr auf seinen Lebenszyklus seiner Produkte (welche sehr lange sind) so wird es ihm wohl schwerfallen auf ein unerwartetes Ereigniss innert nützlicher Frist reagieren zu können. Vergleichbar vielleicht mit den Automobilherstellern, welche von Herrn Musk auf dem falschen Fuss erwischt wurden. Langsam aber sicher sind diese nun in der Lage auf Tesla zu reagieren. Innert nützlicher Frist waren sie aber eigentlich nicht in der Lage eine Antwort zu liefern. Man kann nun von Tesla halten was man will, die Automobilindustrie war meiner Meinung nach aber nicht in der Laga, auf diesen äusseren Einfluss zu reagieren, sprich sich in nützlicher Frist entsprechend anzupassen. Ich denke durch eine stetige Anpassung durch die beiden bereits beschriebenen Zyklen, setzt sich eine Firma einem guten Übungsfeld aus und kann seine Organisation so bauen, dass sie eben agil bleibt, also in der Lage ist innert nützlicher Frist auf relevante Veränderungen zu reagieren. Spannender wäre es ja noch, wenn eine bestehende Organisation sich so organisiert, dass sie die Einflüsse auf andere ausübt und nicht reaktiv sein muss.

Collaboration

Aus dem Agilen Manifest wird die Interaktion von Individuen vor den Prozess gestellt und die Zusammenarbeit mit dem Kunden vor die Vertragsverhandlungen. Beim ersten Wertepaar steht das Team im Vordergrund, man geht davon aus, dass ein komplexes Thema nur zusammen gelöst werden kann. Nun gibt es aber ganz viele Arbeiten, in denen vielleicht die Kreativität nicht gefragt ist, es auch kein Komplexes Problem zu lösen gilt. Es vielleicht einfach einen bewährten Prozesse gibt, welcher schon mehrmals einem KVP unterzogen wurde und eigentlich schon fast aufs äusserste optimiert wurde. In einem solchen Umfeld braucht es weder Scrum noch SAFe oder ähnliche Methoden, hier soll einfach weiter optimiert werden. Das macht vielleicht auch wirklich Sinn. Aus solchen Umfeldern entstanden auch die Lean Anwendungen. In Lean Prozessen ist das oberste Gebot eine Verschwendung (Eliminate Waste) zu vermeiden. Sei dies in dem nur das gebaut wird was der Kunde auch braucht. So werden keine Lager angehäuft und man ist schneller fähig auf veränderte Kundenwünsche einzugehen.  Oder sei dies in dem es ein Pull System gibt und kein Push (Stichwort: Schiffchen falten), so entstehen z.B. keine Halbfabrikatslager und der Durchlauf eines Einzelstückes kann verkleinert werden. Es geht hier also um Prozessoptimierungen, genau um Messen und verbessern und genau da liegt der Hund begraben. Sobald ich Messe beinflusse ich die Messung. Unter dem Motte: wer misst, misst Mist. Sobald ich nur Teile von einem Prozess anschaue, kann es zu Teiloptimierungen kommen, die für den ganzen Prozess sogar hinderlich sind. Es ist wichtig, dass die Zusammenarbeit in einem Prozess betrachtet wird und nicht nur die einzelne Arbeit und die Zusammenarbeit zu messen ist schwierig. Ich finde folgender Ted Talk legt dies sehr schön dar: Yves Morieux how too many rules at work keep you from getting things done. Ein Aspekt aus diesem Video möchte ich noch näher beleuchten

Selbstorganisation – Potential von den Mitarbeitern nutzen

Wenn es mir als Organisation gelingt die Strukturen meiner Organisation so zu gestalten, dass sich jeder Mitarbeiter einbringen will und er die Möglichkeit erhält sich einzubringen. So glaube ich besteht eine gute Grundsubstanz, um als Unternehmung erfolgreich zu sein. Bestärkt in dieser Überzeugung hat mich dann noch die Definition von Führung nach Ed Schein: dass Führung eine Funktion der Organisation und nicht die Eigenschaft eines Individuum ist und dass die Führung über alle Mitglieder einer Organisation verteilt ist. Dies war sozusagen ein weiterer Flicken in meinem Patchworkteppich zu Agilen Organisationen. Es muss mir als Organisation gelingen, das Wissen und die Intelligenz meiner Mitarbeiter für die Organisation zu nutzen. Gemäss Brian J. Robertson war dies der Auslöser warum er das Holakratische System entworfen hat. Um den Mitarbeitern es zu ermöglichen, ihr Wissen in die Organisation einzubringen. Dass jedes einzelne Warnlämpchen gesehen und gehört wird. Wenn ich nun an einen Ablaufprozess denke, macht es für mich absolut Sinn dass jener der am Fliessband steht am besten weiss, wie er effektiver wird. Welche Instrumente er anderst braucht, was sein Vorgänger für ihn anderst machen könnte und wenn er von den Problemen von seinem Nachfolger im Prozess hört, kann er vielleicht zu einer Lösung beitragen, die sie nur gemeinsam entwickeln können. Wenn einem solchen Team (obwohl jeder alleine an seinem Teil arbeitet, er aber Interesse am ganzen hat), es auch noch gelingt sich genug nach aussen zu öffnen, um auch unkonventionelle Ideen auszuprobieren, dann wird ein solches Team fast nicht zu schlagen sein. Dazu muss ich als Organisation aber eine Führung schaffen, die jedes Individuum in seinen Fähigkeiten unterstützt und fördert. Es braucht eine psychologische Sicherheit um neue Vorgehensweise ausprobieren zu können. Es braucht Raum in welchem die Mitarbeiter miteinander an Problemen (am und im System) arbeiten können. Damit dies nicht aus dem Ruder läuft, respektive nicht alle in eine andere Richtung laufen, muss es transparent sein, für was die Organisation einsteht. In was sie ihren Sinn sieht.

Sinnstiftend

Wenn ich nun davon ausgehe, dass ich ein Unternehmen habe, welches motivierte und engagierte Mitarbeiter hat. Dann würde ich mal so in den Raum stellen, dass diese nicht sehr lange in dieser Unternehmung arbeiten, wenn der Sinn der Unternehmung darin besteht unser Shareholder zu beglücken indem ich ihnen Ende Jahr höhere Diviedenden ausbezahle. Genau gleich wenn ich eine Unternehmung hätte welche den Sinn ihre Daseins darin sieht, weltweit am meisten Einfluss in irgendeinem Business zu erlangen. Ich glaube es ist zwingend dass eine Unternehmung einen Sinn hat und nicht nur zum Zweck dient. Dass es ohne Zweck nicht geht, davon bin ich überzeugt, respektive ist mir logisch. Ich bin aber überzeugt, dass ein Sinn welcher den Menschen/Kunden hilft früher oder später auch zum Zweck beiträgt. Auch dieser Sinn muss natürlich immer und immer wieder überprüft und auch angepasst werden. Es braucht aber auch immer wieder ein Überprüfung ob unsere Wertschöpfungskette noch dem Sinne dient. Ich bin ebenso überzeugt, dass wenn eine Unternehmung den Sinn genug weit spannt, dies die Mitarbeiter auch zu neuen Ideen anregt, die vielleicht einem Chief Officer of Strategie gar nie eingefallen wären, oder einfallen können. Es kann dann auch sein, dass eine neue Unternehmung entsteht. Es gibt ja keinen Anspruch einfach nur Gross zu sein. Ein Unternehmen muss also eine Führung schaffen, welche den Mitarbeiter befähigt, sein Wissen, seine Skills und auch sich als Person in die Unternehmung einzubringen. Gleichzeitig muss ein Rahmen geschaffen werden, damit jedem klar ist, wohin die Reise gehen soll. Ich sehe dies als extreme Herausforderung für eine Organisation. Sehe aber gleichzeitig z.B. durch die Medienmacher oder auch Beispiele aus Büchern wie Reinventing Organisation, dass es durchaus Möglich ist und es auch in ganz unterschiedlichen Industrien und in den unterschiedlichsten Fertigungsrichtungen funktioniert.

Für mich sind die letzten beiden Inhalte von Agilität Sinnstiftend und Collaboration die Schlüssel zum Erfolg, die anderen Ansätze sind Methoden um diese beiden zu unterstützen und überhaupt zu ermöglichen. Von Methoden gibt es einen ganzen Blumenstrauss, ich denke hier muss sich jede Unternehmung selber im Klaren sein, mit was sie am meisten profitieren kann.

Um auf meine Frage vom Anfang zurück zu kommen: Ja ich glaube Agilität kann überall eingesetzt werden und jede Organisation kann von Agilität profitieren. Ich glaube auch, dass Agilität das richtige Wort ist. Bin aber mittlerweile soweit, dass ich denke dass Scrum, SAFe, Holakratie und andere Populäre Vorgehen, Frameworks so stark mit dem Wort Agilität verbunden sind, dass Agilität kaum bis zu Sinnstiftend reicht. Agilität wird als Buzzwort missbraucht und verbraucht und deshalb braucht es eigentlich eine andere Bezeichnung. Andere Bezeichnungen wie evolutionäre Organisationen oder integrale evolutionäre Paradigmen, wie sie Laloux in Reeinventing Organisation benutzt, sind so nicht sprechend und werfen zur Zeit noch mehr Fragezeichen auf, als Agile Organisationen. Aber wie schön Göthe meinte, Namen sind nur Schall und Rauch und deshalb lasse ich die Suche und bleibe bei Agilen Organisationen.
Was es aber heisst eine Agile Organisation zu werden, das ist keine Reorganisation wie wir es aus der Vergangenheit kennen. Wir zeichnen keine neuen Organigramme und führen diese auf den Tag X ein. Für mich ist es eine Veränderung der Führung einer Organisation. Ich bin überzeugt dass die Führung durch die Struktur der Organisation passieren muss und nicht durch Vorgesetzte Personen in der Organisation und das sehe ich als persönliche Veränderung von den meisten Mitarbeitern und eine solche Veränderung geschieht nicht von heute auf morgen und auch nicht auf den Tag X oder Y. Nur dies wird ja dann das Thema meines letzten Blogs im CAS “Agile Organisationen”.

Das vierte Modul beschäftigte sich mit «Agile Organisation», ich möchte zu den Themen Vorgehensmodelle und Planungslevels eingehen.

Vorgehensmodelle im Vergleich

Beim klassischen Wasserfall-Modell wird das Projekt von Anfang an durchgeplant, die einzelnen Phasen sind vorgegeben und werden nacheinander abgearbeitet. Kann das Projekt nicht in der vorhergesehenen Zeit abgeschlossen werden, und dies ist sehr oft der Fall, wird meist Zeit und Budget nachgeschossen, um das gewünschte Ergebnis zu erzielen. Auf Änderungen kann nur träge reagiert werden, da man am vorgegeben Plan festhalten möchte. Das Modell gibt aber eine gewisse Sicherheit, da das Ergebnis sowie Budget und Zeit bekannt sind.

Agile Modelle arbeiten hingegen empirisch, man nähert sich dem Ergebnis zyklisch an. Das Produkt wird iterativ fertiggestellt, wobei jede Iteration ein auslieferbares Produkt erzeugt, dh. das Produkt ist fertig entwickelt, getestet und einsatzbereit. Mit jeder Iteration wird das Produkt verfeinert und es wird Mehrwert generiert. Durch dieses Splitten von Funktionalitäten wird die Komplexität zwar nicht eliminiert, jedoch in kleinere Einheiten aufgeteilt. Bei diesem Vorgehen, kann auf Veränderungen sehr schnell reagiert werden, man lernt aus Feedback und implementiert nur das, was auch einen Mehrwert schafft. Die groben Themen werden am Anfang zwar festgelegt, die Details werden jedoch erst mit jeder Iteration verfeinert. Das endgültige Produkt entsteht erst durch ständiges Feedback und Veränderungen.

Flow getriebenen Modelle dienen der Wertflussoptimierung. Zu oft wird an mehreren Tasks gleichzeitig gearbeitet, was aber nicht bedeutet, dass man schneller fertig wird. Es ist eher das Gegenteil. Mit Modellen wie Kanban lässt sich der Arbeitsfluss mit Hilfe des Pull-Prinzips steuern. Die Flusseffizienz, also jener Zeitanteil einer Arbeitseinheit, wo aktiv gearbeitet wird, soll verbessert werden. Es bringt jedoch nichts, wenn die Verbesserung nur in den Teams erfolgt, sie muss innerhalb der gesamten Organisation erfolgen.

Ich kämpfe oft noch mit wasserfallgetriebenen Vorgehensweise, obwohl ich sie per se nicht unbedingt schlecht finde. Aber ich sehe immer wieder das Ergebnis, dass wir als Kunden nicht verstanden wurden und die Entwickler etwas Anderes umsetzten. Warum ist das so? Die Anforderungen wurden doch immer klar spezifiziert. Wo ist hier der Gap zwischen «Was erwarte ich mir» und «Was wurde umgesetzt»? Klar, der Lieferant will sich absichern und verlangt daher eine detaillierte Beschreibung der Anforderungen am Anfang des Projektes. Auf Änderungen wird nur ungern eingegangen und es führt oft zu langen Diskussionen. Daher habe ich mir vorgenommen, mehr Wert darauf zu legen, wie die Anforderungen aufgenommen werden und die Akzeptanzkriterien klar für uns und den Entwickler festzulegen. Genauso wie wir es in der Übung «Grossherzogtum Oberes Mittelland» gelernt haben. Auch dort ging klar hervor, dass das Verständnis über das Ergebnis und der Sinn, warum man es macht oder möchte, das Wichtigste sind. Ich habe auch gelernt, dass man in der ersten Iteration bereits etwas Mehrwertbringendes liefern muss. Den Kuchen richtig in Stücke schneiden, zum Beispiel an Hand von Story Mapping, scheint mir ein sehr wichtiger Punkt zu sein. Oft wird zu viel Zeit in den Anfang des Prozesses investiert und das Ende des Prozesses erst in den letzteren Iterationen betrachtet. Dies sollte jedoch nicht passieren, der Prozess muss schon in der ersten Iteration bis zum Ende durchgedacht sein. Auch wenn er vorerst in einer minimalen Ausführung umgesetzt wird.

Fazit

Ich finde es gut, dass man sich eigentlich nicht auf ein Modell festlegen muss, sondern je nach Art und Bereich das am besten geeignete einsetzen kann. Und es geht auch nicht darum, welche Tools man einsetzen möchte, sondern welche Struktur am besten zum Unternehmen passt. So gibt es Projekte, die besser nach Wasserfall durchgeführt werden, wie z.B. Transformationen oder Migrationen. Hier ist klar, was erreicht werden muss und meist muss ein Termin eingehalten werden. Hier machen agile Vorgehensweisen keinen Sinn. Hingegen passt die agile Vorgehensweise besser für Softwareprojekte mit unklaren Zielvorgaben oder wo man schon im Vorhinein mit vielen Änderungen rechnet.

Five Levels of Planning

In jedem Projekt gibt es Änderungen im Projektumfang, dies ist heute eher die Regel als die Ausnahme. Diese Änderungen sind nicht vorhersehbar und können schwer geplant werden. Um auf diese Änderungen reagieren zu können, muss man aber dennoch vorbereitet sein. Daher müssen auch agile Projekte geplant werden. Doch im Gegensatz zu klassischen Wasserfall-Projekten ist die Planung selbst auch agil. Dh. die Planung wird laufend angepasst und die einzelnen Ebenen müssen sich aufeinander abstimmen. Bei der agilen Planung geht man von fünf Planungsebenen aus:

Die oberste Ebene beginnt mit der Vision und repräsentiert die Gesamtsicht für die nächsten Jahre. Mit jedem Level kommen mehr Details für die Planung hinzu, sodass alle fünf Ebenen der agilen Planung ein ganzheitliches Verständnis dafür liefern, was entwickelt werden soll und wie es geplant ist.

Level 1: Produktvision (Strategie)

Wie wir schon so oft gehört haben, beginnt alles mit einer Vision. Die Projektvision ist die höchste Ebene und beschreibt auf oberster Ebene, welches Problem gelöst werden soll. Die Planung umfasst mehr strategische Informationen und weniger Details zu dem Problem. Alle Teams richten ihre Arbeit nach dieser Vision aus.

Level 2: Produkt Roadmap (Leistung) 

Bezugnehmend auf die Produktvision wird die Produkt Roadmap mit Informationen beliefert. Die Produkt-Roadmap definiert die Anforderungen (Backlog) auf hoher Ebene und fasst diese zu Themenbereichen zusammen (Themes). Sie soll helfen, Prioritäten zu setzen und einen Plan für die Freigabe liefern. Diese Roadmap wird zumindest alle 6 Monate aktualisiert.

Level 3: Release Planung (Lösung)

Der Releaseplan definiert die Liste der Features, welche zu festgelegten Zeitpunkten (Releasedaten) als Version dem Kunden freigegeben werden. Hier müssen sich mehrere Teams auf einem gemeinsamen Intervall einigen, häufig ist das alle 1 bis 3 Monate.

Level 4: Iterationsplanung (Story)

Während der Iterationsplanung verpflichten sich die Teams, Produktinkremente bereitzustellen. Dabei werden einzelne Stories zu einem Sprint zusammengefasst, welcher in der Regel 1-2 Wochen dauert.

Level 5: Tagesplan (Task)

Die tiefste Ebene ist der Task, also jene Aufgabe, welcher ein Teammitglied in maximal einen Tag fertigstellt.

Als wir die fünf Levels oder Flughöhen durchgegangen sind, kam mir das recht bekannt vor. Eigentlich habe ich dies verschiedenen Flughöhen auf unseren Boards bereits abgebildet. Ausgehend von unserer Vision oder Ziel, haben wir alle Projekte auf unserem Portfolio-Board abgebildet. Gemeinsam werden am Governance Board mit den Stakeholdern die Prioritäten der einzelnen Projekte festgelegt und in die Release-Planung aufgenommen. Jedes Projekt wird mithilfe von Story-Mapping auf die einzelnen Stories heruntergebrochen und die daraus resultierenden Tasks werden am Task-Board besprochen.

Für mich ist das ein sehr gutes Werkzeug, um die Gesamtübersicht im Auge zu behalten. Ich fange gerne mit dem Big-Picture an und schraube mich dann zu den tieferen Ebenen hinunter. Andererseits benötige ich oft nur das Big-Picture, um die Abhängigkeiten zu den anderen Projekten zu sehen und mit diesen zeitgerecht interagieren zu können. Denn gerade diese Abhängigkeiten werden meistens nicht von Anfang betrachtet, sondern werden erst im Laufe des Projektes angegangen, was zwangsweise zu höheren Entwicklungskosten führt. Und das Modell zeigt mir, dass eine gewisse Planung weiterhin notwendig ist und auch Sinn macht.

Fazit

Dieses Planungsmodell hilft mehrere Teams bzw. mehrere Projekte agil zu skalieren. Denn es hilft nicht, bei den einzelnen Teams die maximale Performance zu erreichen, es müssen alle Teams und Projekte in Einklang miteinander funktionieren. Um das gewünschte Ziel auch zu erreichen, braucht es ein gewisses Mass an Planung, ein paar Indikatoren auf die man sich konzentrieren kann. Die Planung erfolgt nur jeweils soweit, wie man die Dinge weiss. So sollte man sichergehen können, dass man sich dem Ziel nähert, ohne das eigentlich Ziel aus den Augen zu verlieren.

Ausblick auf das nächste Modul

Wenn wir davon ausgehen, dass die Welt weiterhin schnellen Veränderungen ausgesetzt ist, müssen Organisationen geschaffen werden, die schnell auf solche Veränderungen reagieren können. Ein Unternehmen muss mit ständig neue Anforderungen und Einflüssen umgehen können. Daher muss jedes Unternehmen eine Organisationsform finden, um den Wandel bestehen zu können. Dafür ist zuerst eine Strategie notwendig, wozu man auf die Veränderung reagieren möchte. In der Strategie eines agilen Unternehmens muss ein sinnhaftes Ziel sowie ein Zweck deutlich werden, warum das Unternehmen existiert und warum die Mitarbeiter dafür schaffen sollen. Eine Methode, um äussere Einflussfaktoren zu identifizieren und Chancen und Risiken abzuleiten, ist die PEST-Analyse.

Mit der PEST Analyse werden folgende vier Faktoren beleuchtet:

Political – Politische Faktoren
Könnte es neue rechtliche Vorschriften oder Reglementierungen geben?

Economic – Wirtschaftliche Faktoren
Welche wirtschaftlichen Entwicklungen können auftreten?

Socio-Cultural –Sozio-kulturelle Faktoren
Welche Trends existieren?

Technical – Technische Faktoren
Welche neuen Technologien könnten sich entwickeln?

Wenn man das Ziel die Veränderung ist, bleibt wohl nichts Anderes übrig, als dass man die Agilität auf allen Ebenen lebt und eine Transformation dorthin anstrebt. Wie – das erfahren wir im nächsten Modul.

 

Ein weiteres Modul in unserem CAS Agile Organisation haben wir am letzten Wochenende beendet: “Agile Organisation” heisst das Modul, welches dem ganzen Lehrgang den Namen vererbt hat.  Dieses Modul war für mich von Anfang an einer der Beweggründe, um diesen CAS zu absolvieren. Entsprechend gespannt war ich dann auch auf den Inhalt und die Ausführungen der Dozenten.

“Holacracy” oder “Hola – crazy!” ?

Zum Einstieg hat uns Sibylle das Modell Holacracy und die Grundideen und Prozesse davon vorgestellt. Es war durchaus interessant zu sehen, dass ein offenbar auf den ersten Blick doch etwas exotisch erscheinendes Modell durchaus in der realen Welt eingesetzt werden kann. Mir ist bei Holacracy extrem aufgefallen, dass das Modell einen ungewöhnlich hohen Grad an Struktur und ein ausgeklügeltes Regelset vorgibt, welches von den diversen vorgegebenen Rollen im System ausgeführt und eingehalten wird.

Umso erstaunlicher ist die Tatsache, dass man mit diesem mächtigen Regelwerk direkt ein Gegenmodell zu dem in den letzten hundert Jahren in der Industrie und der Armee klassischerweise gelebten Hierarchiemodell der Hierarchie-Silos darstellen will. Strukturen durch Strukturen ersetzen, einfach anders?

Wenn ich die Idee von Holacracy richtig verstanden habe, dann soll es ja darum gehen, dass die Menschen und Teams selbstorganisiert entscheiden und sich so entfalten können.  Diese Grundidee finde ich absolut löblich und ich denke, dass es für eine Unternehmung heute absolut notwendig ist, diesen Mindshift zum Einbringen aller Mitarbeiter zu tun.

Ohne Holacracy jemals wirklich im echten Berufsleben erlebt zu haben, erscheinen meinem Bauchgefühl gewisse Aspekte des Modells aber nicht ganz stimmig. Kann man mit einem derart streng strukturierten Regelwerk wirklich einfacher und strenger auf Veränderung reagieren? Möglicherweise.  Möglicherweise kann ein Team in seinem Circle gesehen auch relativ autonom entscheiden, was eine gute Sache ist. Problematisch sehe ich dann allerdings diesen Prozess, wenn die Organisation skaliert und eine vielschichtige Kommunikation und Abstimmung zu anderen Circles notwendig ist. Die Rolle des Rep scheint mir dort einen potentiellen Flaschenhals darstellen zu können. So ist die direkte Kommunikation und Zusammenarbeit zwischen den Mitarbeitern verschiedener Circles nicht vom Modell speziell gefördert. Dies stellt aus meiner Sicht ein Schwachpunkt dieses Modells dar. Für mich stellt deshalb ein Circle – abstrahiert gesehen – wiederum eine andere Form eines klassischen Silos dar.

Ausserdem  würde ich gerne mal die reale Interpretation der Rolle eines Lead Links erleben. Aus meiner Sicht, hat diese Rolle doch wiederum eine Art hierarchische Stellung innerhalb eines Circles, auch wenn die Rolle vordergründig “demokratisch” vergeben wird. Intersoziale Aspekte werden aber bei dieser Wahl mit Sicherheit immer mitspielen.

Der Gedanke eine Entscheidungsfindung per Konsent sehr schnell und effizient herbeizuführen ist verlockend. Jeder von uns kennt Meetings, welche absolut unnötig und nicht zielführend und entscheidungslos verlaufen. Dennoch, ist es wirklich immer besser eine schnelle Entscheidung zu haben? Sollte nicht viel mehr das Ziel sein, eine gute Entscheidung zu haben? Jeder kann sich dazu seine eigene Meinung bilden.

Für mich bleiben jedenfalls momentan bei dem Modell viele Fragen offen. Alternativ sind für mich Gedanken welche z.B. bei Management 3.0 gezeichnet werden viel schlüssiger und stimmiger. Auffallend jedoch, wie häufig sich die Diskussionen in diesem Modul um Holacracy gedreht haben.

Momentan beschäftige ich mich sehr stark mit Fragen rund um das Thema Skalieren von Organisationen, ich habe bedauert, dass uns die Frameworks wie LESS oder SAFe nicht in diesem Umfang vorgestellt wurden, wie dies bei Holacracy der Fall war. Ich werde mich noch vertiefter selber in die Materie einlesen müssen.

Mehr Medien oder mehr Macher?

Die Vorstellung der jungen Herren der Medienmacher war zugleich beeindruckend wie auch erschreckend. Zum einen war es etwas schwierig, sich mit der gewählten Form der präsentierten Inhalte sich ein genaues Bild zu machen, wie die Organisation nun neu organisiert ist. Zum anderen bekam ich den Eindruck, dass man in sehr sehr kurzer Zeit keinen Stein auf dem anderen gelassen hat (ausser dem effektiven Print-Department). Hier hat sich für mich die Frage gestellt, wie man denn feststellen will, welche Veränderung welchen Erfolg gebracht hat. Für mich war in den Ausführungen nicht ganz klar, welches Zielbild denn mit welchen Aktionen genau erreicht werden will. Man hat sehr viele Aktionen und Änderungen parallel gestartet, ich sehe hier eine gewisse Gefahr von unkoordiniertem Aktionismus gegeben. Zumal ich ein solch ambitioniertes Projekt niemals ohne definierte KPI’s gestartet hätte.

Ich hoffe der Mut der Medienmacher wird schlussendlich belohnt und die Restrukturierung führt zu dem gewünschten Markterfolg und einem überleben der Organisation in irgend einer Form. Allerdings scheint mir das Marktumfeld in der Verlagsbranche als durchaus schwierig.

Die Case Study an sich ist sehr interessant. Ich bin gespannt im Januar beim Besuch des Unternehmens weitere Einblicke in den Fortschritt der Transformationen erhalten zu können.

Alles Lemminge?

Aus meiner Sicht zeigt das Beispiel der Medienmacher aber genau eine der Gefahren, welche sich transformationswilligen Unternehmungen heute stellt. Das Gespenst der Digitalisierung ist allgegenwärtig und wird auch aus unterschiedlichen (oftmals wirtschaftlichen) Interessen bewusst hochgespielt, ohne dass es vielen der selbsternannten Transformations- und Agilisierungsexperten überhaupt bewusst ist, was dies bedeutet. Meiner Meinung nach ist nicht überall Agilität drin, wo Agilität drauf steht. Man sollte sich überall ganz klar von Anfang an bewusst sein – und hier ausnahmsweise ein Kompliment an die Frage nach der Purpose von Holacracy – was denn genau mit einer bestimmten Aktivität erreicht werden soll und wieso. Es ist verlockend, wenn alle Lemminge schreien man müsse jetzt was tun, dem Pfeiffer zu folgen um dann aber blindlings ins Verderben zu laufen.

Be unique!

Ich glaube, entscheidend über Erfolg oder nicht-Erfolg eines Unternehmens ist es, differenziert seine Situation und Ansprüche – welche für jedes Unternehmen unterschiedlich sind – zu analysieren und sich dies dann auch bewusst zu sein. Deshalb bin ich der Überzeugung, dass es nicht getan ist, ein gerade gehyptes Modell einfach hart über eine Unternehmung zu stülpen. Ich bin vielmehr davon überzeugt, dass man sich für seine Bedürfnisse das Beste aus den verschiedenen Frameworks und Modellen holen soll und entsprechend auf seine Bedürfnisse adaptiert. Ich bin überzeugt, diejenigen Unternehmungen welche dies schaffen, haben einen wirklich entscheidenen Wettbewerbsvorteil und gute Chancen sich auf dem schnell ändernden Markt anpassen und behaupten zu können. Kurz: Diese Unternehmungen werden es schaffen agil zu sein.

moor(e) to follow.

 

 

 

keep looking »