Archiv der Kategorie: Alignment

Das Große Ganze – Komplexität

Organisationen sind komplexe Systeme. Man kann sie nicht aufschrauben und einfach umbauen, wie Maschinen. Wenn man es doch versucht, scheitert man in der Regel. Deswegen sollte man verstehen was die Unterschiede zwischen komplizierten, komplexen und anderen Systemen sind und welche Herangehensweise jeweils angemessen ist.

Dave Snowden hat mit dem Cynefin Framework ein Modell erarbeitet, anhand dessen man vier Arten von Systemen unterscheiden kann.

 

Offensichtlich: Die Milch kocht über? Ich schalte den Herd aus und nehme den Topf von der heißen Platte. Über offensichtliche Systeme muss man nicht lange nachdenken. Man erkennt es, beurteilt es und reagiert. Es gibt in der Regel nur eine beste Lösung, die sogenannte Best Practice.

Kompliziert: Befindet man sich in einem komplizierten System, braucht man einen Experten. Sein Auto lässt man vom Kfz-Mechaniker reparieren, mit Zahnschmerzen geht man zum Zahnarzt. Diese analysieren das Problem, wählen die passendste Lösung aus und setzen sie um. Schon hier gibt es keine Best Practice mehr, sondern nur noch Good Practices, Optionen die jeweils Vor- und Nachteile haben.

Chaotisch: Die Cynefin-Beispiele für den chaotischen Bereich sind bürgerkriegsähnliche Zustände oder Natur-Katastrophen. Erfolgreiches Vorgehen besteht in diesen Situationen im Stillen der Blutung durch klare Führung, also z.B. Ausgangssperren oder großflächige Evakuationen.

Komplex: Bei organisatorischen Veränderungen hat man es in der Regel wie gesagt mit einem komplexen System zu tun. In diesen Systemen gibt es kein einfaches Erkennen von Ursache und Wirkung mehr. Sie sind unvorhersehbar und instabil. Hier hilft nur, Dinge auszuprobieren, Experimente zu machen und dann zu schauen, wie das System reagiert.

Ich möchte dies an einem Beispiel illustrieren: Ein Team kommt nach Empfinden des Management nicht schnell genug voran. Es stellt die Vermutung auf, dass es an Expertenwissen fehlt und ein Experte aus einer anderen Abteilung wird in das Team versetzt. Nach einigen Wochen stellt man fest, dass das Team noch langsamer geworden ist. Daraufhin beschließt das Management den Experten wieder zu entfernen, weil es ja vorher zumindest etwas besser war. Das Team wird nun noch langsamer als es mit dem Experten war. Zudem kündigt ein Mitarbeiter und einer wird über mehrere Wochen krank geschrieben.

Was war passiert? Die Einarbeitung des vermeintlichen Experten hatte so viel Zeit gekostet, dass wichtige Dinge liegen geblieben waren, wodurch das Team langsamer wurde. Dennoch war die Motivation im Team gut, weil man durch die zusätzliche Person Licht am Ende des Tunnels sah. Gerade als der Experte eingearbeitet war, riss dem Management der Geduldsfaden und es entfernte den Experten wieder. Nun musste das restliche Team allein die liegengebliebenen Dinge aufholen und war zudem frustriert, weil die gegebene Unterstützung wieder zurückgezogen worden war. Frustration und Überlastung führten zu Kündigung und Krankheit.

Im Nachhinein findet man für solche komplexen Vorgänge oft plausible Erklärungen. Die Situation könnte sich aber auch ganz anders entwickeln. Vielleicht ist fehlende Expertise gar nicht das Problem, sondern Konflikte im Team, ein schlechter Prozess oder fehlende Mitbestimmung. Vielleicht passt der Experte persönlich nicht gut ins Team und würde dieses auch langfristig bremsen.

Bei Experimenten im Umgang mit komplexen Systemen sollte man stets darauf achten, dass die Experimente safe-to-fail sind, also die Firma am Leben bleibt, selbst wenn es fehlschlägt.

Bei größeren Veränderungen in Unternehmen gibt es viele Fallen in die man tappen kann. John P. Kotter hat schon 1995 die acht größten herausgearbeitet:

  1. Die Dringlichkeit der Veränderung wird nicht genügend motiviert
  2. Eine zu schwache Koalition der Willigen, die die Veränderung antreiben
  3. Die Vision für die Veränderung fehlt
  4. Die Kommunikation der Vision wird massiv versäumt
  5. Hindernisse, die der Vision entgegenstehen, werden nicht beseitigt
  6. Kurzfristige Erfolge werden nicht systematisch geplant und erreicht
  7. Der Abschluss der Veränderung wird zu früh gefeiert
  8. Die Veränderung wird nicht in der Organisationskultur verankert

Dies war der dritte und letzte Abschnitt zum Thema „das Große Ganze“. Die Beiträge zum Thema Interessen und Organisationsstrukturen finden Sie hier:

Literatur:

(1) Kotter, John P. 2012: Leading Change*: Harvard Business Review Press

(*) Affiliate-Links.

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Das Große Ganze – Organisationsstrukturen

Es gibt keine guten oder schlechten Organisationsstrukturen. Es gibt nur angemessene und unangemessene.  – Harold Kerzner

Nach der Betrachtung der Interessen organisatorischer Akteure, werden wir uns nun um Organisationsstrukturen kümmern. Es gibt einige grundsätzliche Konzepte dazu, die man kennen sollte, wenn man seinen Blick für „das Große Ganze“ schärfen möchte.

Gruppen, Teams und ihre Ausprägungen

Sobald man mehrere Mitarbeiter hat, kann man diese als Gruppe organisieren. Vielleicht haben sie denselben Chef, machen dieselbe Arbeit oder sind im selben Monat eingestellt worden. Gruppen haben eine Reihe von Vorteilen:

  • Ausfallsicherheit (Vertretung bei Urlaub und Krankheit)
  • Motivation: Zusammengehörigkeitsgefühl stärkt die sozialen Beziehungen

Ein Team wird aus einer Gruppe erst, wenn an einem gemeinsamen Ziel gearbeitet wird, was Zusammengehörigkeitsgefühl und Motivation nochmal vervielfachen kann.

Oft hört man die Empfehlung, dass man Cross-Funktionale Teams braucht, also Teams, in denen Mitarbeiter unterschiedlicher Expertise gemeinsam an einem Ziel arbeiten. Solche Teams sind besonders dort unschlagbar, wenn es um komplexe innovative Aufgaben geht. Zum Lösen solcher Aufgaben muss viel experimentiert werden und dafür hat sich intensive direkte Kommunikation bewährt. Es ist kein Wunder, dass Cross-Funktionale Teams gerade in Methoden für Software-Entwicklung wie Scrum gefordert werden.

Braucht man für seine Buchhaltung deshalb ein Cross-Funktionales Team? Wahrscheinlich meistens nicht.

Führungsstrukuren

In vielen Firmen ergibt sich automatisch ein sogenanntes Einliniensystem, eine klassische Hierarchie, in der es jeden genau einen Chef gibt, der für alle Belange Weisungsbefugnis hat. Der Geschäftsführer setzt Manager ein, die dann für Teilbereiche des Unternehmens Weisungsbefugnis haben. Diese setzen dann weitere Manager für noch kleinere Bereiche ein. Alle Bereiche sind überschneidungsfrei. Wikipedia beschreibt sehr schön was entsteht:

Das Ergebnis dieses Konzeptes ist eine straffe, übersichtliche Organisation, in der Kompetenzüberschneidungen vermieden werden. Durch die klare Abgrenzung von Verantwortungsbereichen lässt sich die Umsetzung von getroffenen Entscheidungen gut verfolgen und kontrollieren. (Wikipedia)

Mit Personen zu sprechen, mit denen man keine direkte Verbindung über die Linie hat, ist dann in der Reinform des Systems schon eine Kompetenzüberschreitung.

In Mehrlinien-Systemen wie einer Matrixorganisation kann man für unterschiedliche Themen mehrere Chefs haben, z.B. einen Vorgesetzten für die disziplinarische Leitung und einen Projektmanager für die fachliche Weisungsbefugnis. Das führt natürlich in der Praxis zu Konflikten, wenn beispielsweise der disziplinarische Chef entscheidet, jemandem von einem Projekt abzuziehen.

Wenn man nicht genau hinguckt, wirken auch agile Systeme wie Mehrlinien-Systeme. Im Scrum-Framework ist der Product Owner zuständig für die fachlichen Inhalte und der Scrum Master für die Organisation des Teams. Manche Firmen benennen ihre Projekt-Manager und Team Leads einfach um, machen ansonsten aber so weiter wie bisher und verschlimmbessern ihre Organisation dadurch eher.

Echte Agile Organisationen haben aber einen Paradigmen-Wechsel vollzogen. Es wird nicht mehr in Linien, Weisungen und Kompetenzüberschreitungen gedacht, sondern in Selbstorganisierten Teams, Coaching und Lernen durch Fehler.

Selbstorganisierte Teams entscheiden selber wie sie arbeiten möchten und welche Prozesse sie dafür nutzen. Kein Manager darf von Außen vorschreiben wie sie zu arbeiten haben. Im Gegenteil muss das Management dafür sorgen, dass ein Team die Rahmenbedingungen bekommt um optimal zu arbeiten. In gewisser Weise dreht sich dadurch die Hierarchie um und der Manager wird zum Servant Leader, der seine Führung kompromisslos auf die Interessen der Geführten ausrichtet.

Agiles Arbeiten und Selbst-Organisation sind anspruchsvoll und funktionieren dann optimal, wenn Konflikte und Probleme schnell sichtbar und bearbeitet werden. In der klassischen Hierarchie werden insbesondere persönliche Probleme selten direkt dem Chef gemeldet, aus Angst sich die Karriere zu ruinieren. Besser funktioniert der Einsatz von Coaches, die mit Teams und einzelnen Mitarbeitern an Konflikten und Selbst-Organisation arbeiten. Sie behalten die Details von Konflikten für sich, so dass offen und frei über Fehler gesprochen und lösungsorientiert über Verbesserungen diskutiert werden kann. Ein Agiler Coach kennt sich zudem mit agilen Methoden und Arbeitsformen wie Scrum oder Kanban aus.

Eine eigene Organisationsstruktur bauen

Anstatt das Rad neu zu erfinden kann man sich erfolgreiche Organisationen als Vorbild nehmen. Besonders Toyota und Spotify werden hier häufig genannt. Toyota war einer der Vorreiter für Produktivitätssteigerung in der Autoindustrie. In dem Bewusstsein, dass dies vor allem durch die Toyota-Kultur ermöglicht wurde, hatte die Firma nie ein Problem damit, Außenstehenden ihre Prozesse und Strukturen offen zu legen. Auch Spotify hat sehr transparent beschrieben wie seine internen Strukturen mit Tribes und Squads aussehen. Andere Firmen haben versucht die Strukturen von Toyota und Spotify zu kopieren und sind damit so oft und krachend gescheitert, dass mittlerweile viele Präsentation mit einer Warnung beginnen:

Kopieren Sie nicht einfach die Organisationsstruktur von anderen, sondern entwickeln sie selber eine Struktur, die zu ihrem Unternehmen passt. (siehe z.B. Mgmt3.0-Blog)

Ein Tool um die eigene Unternehmensstruktur neu zu gestalten ist Meddlers aus dem Management3.0-Kanon. Hier baut man seine Organisation aus Sechsecken und Quadraten auf und kann sie spielerisch verändern. Die Sechsecke repräsentieren Teams und die Quadrate Rollen. Größe und Form dieser Vielecke laden dazu ein, einem Team nicht zu viele Schnittstellen nach außen zu geben und die Teamgröße nicht zu groß werden zu lassen.

Hier ein paar Daumenregeln, die im Management3.0-Training empfohlen werden:

  • Teams klein halten (3-7 Personen)
  • Eher Cross-funktionale Teams als Funktionalen Teams bauen
  • Von Mitarbeitern ausgehen, die sowohl spezialisiert sind als auch generalisiert arbeiten können (T-Skill)
  • Teams und größere Organisations-Einheiten als Value Units bauen, sie also so schneiden, dass sie ihre Dienstleistungen unabhängig von anderen anbieten können.

Das Material für Meddlers kann man auf der Management3.0-Seite herunterladen (LINK).

Im nächsten Beitrag betrachten wir das Thema Komplexität.

Literatur:

(1) Appelo, Jurgen 2010: Management 3.0* Leading Agile Developers, Developing Agile Leaders: Addison-Wesley

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Das Große Ganze – wie alles ineinander greift

“Erfolgreiche Führungskräfte haben einen klaren Blick auf das große Ganze und schaffen es, diese Vision auf so prägnante und passende Weise zu übermitteln, dass sie andere Menschen inspiriert und motiviert.“ – Alistair Cox

Welchem Zweck dienen all die einzelnen, kleinen Maßnahmen, die in Ihrer Firma passieren? Passen sie zu einem gemeinsamen Ziel? Oder stellt sich Frust ein, weil die Organisation in Kleinkram erstickt?

Erfolgreiche Personen schaffen es, übergreifende Muster zu erkennen, sie im Blick zu behalten und wirkungsvoll zu kommunizieren. Durch ihre systemische Kompetenz und ihr Wissen über komplexe Systeme und Organisations-Strukturen können sie zielführend auf neue Situationen reagieren und ihr Unternehmen aktiv mitgestalten. Um den Blick für “das Große Ganze” zu schärfen, muss man sich mit drei Bereichen beschäftigen:

Interessen: Die systematische Beschäftigung mit Akteuren in einer Organisation, ihren Erwartungen und Zielen.

Strukturen: Betrachtung von organisatorischen Strukturen, ihren Vor- und Nachteilen.

Komplexität: Die Einordnung von Systemen und der Umgang mit ihrer Veränderung.

Interessen

Kleine Kinder können sich nicht vorstellen, dass andere Menschen die Welt anders sehen, als sie selbst. Die meisten von uns lernen aber bald, dass es zur eigenen Perspektive Alternativen gibt. Ein nützliches Instrument ist, sich die Interessen der Kollegen und Manager in der Organisation bewusst zu machen.

Interesse: Eine Konstellation von Akteuren oder von Akteur und begehrtem Gut, die durch – in bestimmten Bedürfnissen verwurzelte – Anteilnahme und Neigung, aber auch durch Erwartung eines Nutzens oder Vorteils geprägt ist. (1)

Die Stakeholder Adoption Matrix hilft dabei sich die Interessen von Akteuren strukturiert zu betrachten und daraus Handlungen abzuleiten. Nutzen Sie diese, wenn Sie eine Veränderung bewerten oder durchführen wollen. So gehen Sie vor:

  1. Sammeln Sie die wichtigen Akteure als Post-Its. Je nach Einstellung zur Veränderung auf grünen, blauen oder roten post-its.
  2. Ordnen Sie die Post-Its horizontal in 5 Adoption Gruppen: Wer sind die Innovatoren, die sich für neue Idee begeistern? Wer sind die Meinungsführer, die offen für Neues sind (Early Adopters)? Wer gehört zur aufgeschlossenen oder skeptischen Mehrheit und wer ist eher ein Laggard (Zauderer)? Grüne Post-Its hängen wahrscheinlich weiter links, rote weiter rechts.
  3. Sortieren Sie die Post-Its nun vertikal danach, wieviel Einfluss die Akteure auf die Transition nehmen (können).

Jetzt haben Sie ein Bild der potentiellen Unterstützer und wer sich möglicherweise gegen die Veränderung stellt und können angemessene Handlungen ableiten.

Weiter Infos zur Matrix: LINK

In den nächsten Beiträgen folgen Organisationsstrukturen und Komplexität.

Literatur:

(1) Schmidt, Manfred G. 2010:  Wörterbuch zur Politik*: Alfred Kröner Verlag

(*) Affiliate-Links.

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Nordstern Board – True North visualisieren

Schon die Wikinger haben den Polarstern zur Navigation genutzt. Agile Teams können das jetzt auch ;-).

Nordsterne helfen selbst-organisierten Teams ihre Fähigkeiten im Sinne der Organisation zu verbessern. Im Gegensatz zu klassischen Unternehmenszielen wie „Steigerung des Umsatzes um 20%“ oder „Verdopplung der Page Impressions“ fokussieren Nordsterne auf die Fähigkeiten der Organisation bzw. deren Mitarbeitern und Teams. Beispiele für Nordsterne aus der Praxis:

  • Jede Tätigkeit ist wertschöpfend
  • Jeder macht Vertrieb
  • Zero Bugs
  • Alle Teams sind vollständig autonom

Wie man schnell erkennt, sind Nordsterne in der Regel nicht erreichbar. Aber sie geben eine Richtung vor, mit der Mitarbeiter das eigene Handeln verändern können. Orientiert sich ein Team z.B. am Nordstern „Jede Tätigkeit ist wertschöpfend“ und stellt in der Retrospektive fest, dass sehr viel Zeit im letzten Sprint durch wiederkehrende manuelle Schritte beim Deployment verschwendet wurden, könnte eine Maßnahme für den nächsten Sprint sein, diese Schritte zu automatisieren. Solche konkreten Maßnahmen nennt man Target Conditions. Sie sollen nach wenigen Wochen, z.B. nach einem Sprint erreicht werden und überprüfbar sein.

Bei Tchibo haben wir im Rahmen eines Pilot-Teams Nordsterne eingeführt und dafür neben unserem Kanban-Board ein eigenes Nordstern-Board erarbeitet.

Norstern Board

Ziel dieses Boards ist es, nicht nur die Team-bezogenen vier Nordsterne dauerhaft transparent gegenüber Teammitgliedern und Stakeholdern zu machen und für den nötigen Fokus darauf zu sorgen, sondern auch den Fortschritt im Sinne eines Information Radiators zu verdeutlichen.

Der Aufbau des Boards folgt einer einfachen Tabelle, bei dem jede Zeile für einen der vier Nordsterne des Teams steht; damit folgt das Prinzip einer Swimlane-Logik und wird zusätzlich durch eine Farb-Codierung unterstützt, denn jeder Nordstern hat seine eigene Farbe. Die Spalten der Tabelle auf dem Board folgen einer Ableitung der Demig-Kreis Phasen „Plan-Do-Check-Act“:

  • Plan: Die Plan-Spalte beinhaltet jeweils eine oder mehrere Target Conditions, die sich das Team in zweiwöchigen Iterationen passend zum Nordstern selbst-organisiert ableitet.
  • Do: Die Target Conditions werden in die Do-Spalte gezogen, sobald die Arbeit an der Maßnahme beginnt. In einigen Fällen entstehen aus einer Target Condition auch zusätzliche kleinere Tasks, die ebenfalls in der Spalte sichtbar gemacht werden können.
  • Check: Am Ende jeder Iteration findet als Teil der Reflexion eine Überprüfung hinsichtlich der Erreichung der Target Conditions durch das Team statt. In Abhängigkeit der Ergebnisse werden in dieser agilen Zeremonie dann auch gleich die Target Conditions für die nächste Iteration festgelegt (Act).
  • Progression: Anstatt einer Spalte „Act“ hat sich das Team für eine ergänzende Spalte „Progression“ entschieden. Anhand von gemeinsam im Team verabschiedeten Metriken zur Messung, wird der Fortschritt in Richtung der Nordsterne transparent, fördert Commitment und Zusammenarbeit.
    Als zusätzliche Information werden auf dem Board der übergeordnete Arbeitsauftrag des Teams sowie die Erreichungsgrad der Target Conditions über alle Iterationen hinweg dargestellt.

Fazit:

Für das Team hat sich das zusätzliche Board als hilfreiches Tool zur konsequenten Navigation gen Nordsterne gut etabliert. Regelmäßig sind wir am Board folgende Fragen durchgegangen:

  • Was haben wir zuletzt erreicht?
  • Was wollen wir als nächstes erreichen?
  • Stehen unsere Maßnahmen immer im Fokus unseres übergeordneten Arbeitsauftrages?

Durch die physische Visualisierung und die ritualisierte Auseinandersetzung des Teams mit den Fragen finden agile Werte wie z.B. Transparenz, Kollaboration, Workflow, Verbesserung und Vereinbarung praktischen Einzug bei Tchibo.

Theda Howaldt ist Agile Coach bei Tchibo

 

 

 

 

holgerHolger Tewis ist Agile Enterprise Coach (Freiberufler)

Alignment von agilen Teams

Dies ist der dritte Teil einer Beitragsserie, die sich mit der Notwendigkeit des Austarierens von Autonomie und Alignment bei agilen Organisationen auseinandersetzt.

Nach dem ersten Artikel, der sich auf die Frage fokussiert, warum das Gleichgewicht von Alignment und Autonomie wichtig ist und dem zweiten Artikel mit konkreten Beispielen für gelebte Autonomie, beschreibt dieser Blog Post nun Techniken, mit denen wir bei meinem Arbeitgeber CoreMedia  das Alignment der verschiedenen Teams sicherstellen.

Wie schon im vorhergehenden Beitrag erhebt auch dieser keinen Anspruch auf Vollständigkeit, sondern soll nur als Beispiel für mögliche Ausprägungen für andere dienen.

Regelmäßige Firmen-weite Präsentation der Unternehmensstrategie

Damit Alignment überhaupt funktioniert, muss klar sein, auf welches Ziel man sich ausrichtet. Dazu wird regelmäßig die Produkt- und Firmenstrategie an die ganze Firma kommuniziert und Unklarheiten und Anmerkungen diskutiert.

Ziel dieser Veranstaltung ist, dass jeder in der Firma das Ziel Nummer Eins kennt und sein Handeln entsprechend daran ausrichten kann.

Produktplanungsmeetings

Zu den Produktplanungsmeetings treffen sich bei CoreMedia nicht nur Product Owner und Product Manager quartalsweise, um darüber zu diskutieren, was demnächst von Entwicklungsteams gebaut werden soll. Es wirken dabei weitere Stakeholder aus anderen Bereichen der Firma mit und helfen so, das Produkt an der Unternehmensstrategie auszurichten. Für die nicht direkt an der Produktentwicklung beteiligten Stakeholder wird dabei auch klar, was alles nicht gebaut wird und wie es zu dieser Entscheidung kam. Dies ist genauso wichtig wie die Information über die geplanten Dinge.

 Review Meetings der Teams

Nach Scrum sind das Scrum-Team, dessen PO und vom PO eingeladenen Key-Stakeholder Teilnehmer der Sprint Review. Bei CoreMedia haben wir uns dazu entschlossen, dass alle Firmenmitglieder Stakeholder sind, und laden deshalb auch prinzipiell die ganze Firma dazu ein. Naturgemäß ist der Teilnehmerkreis viel kleiner als die Anzahl aller Mitarbeiter, aber immer noch größer als der vom Scrum Guide ursprünglich angedachte Teilnehmerkreis.
Die Review-Meetings dienen vor allem der Präsentation von Ergebnissen und dem Einsammeln von Feedback. Es dürfen aber auch Zwischenstände gezeigt werden, wenn das Feedback dazu für die Entwickler wichtig ist oder die Information darüber, dass es Änderungen geben wird, wichtig für andere Teams ist. Durch die breite Aufstellung entstehen aber auch viele Punkte, die das Alignment mit anderen Teams (auch Nicht-Entwickler-Teams) fördern.

Team-übergreifende Retrospektiven

Ein wichtiger Mechanismus, mit dem man Alignment zwischen mehreren Teams herstellen kann, sind Team-übergreifende Retrospektiven. Immer dann, wenn mehrere Teams gleichzeitig in gemeinsamen Bereichen arbeiten, besteht u.a. die Gefahr, dass aufgrund fehlender Kommunikation oder Missverständnissen mehrere Lösungen für dieselben technischen Probleme gebaut werden, unterschiedliche Architekturmuster angewendet werden oder sich die Teams in  ihren Prozessen in die Quere kommen. In diesen Fällen ist es die einfachste Lösung, zu einer Team-übergreifenden Retrospektive einzuladen, bei der die Teams sich auf gemeinsame Vorgehensweisen einigen können. Dazu werden alle oder einige Team-Mitglieder der beteiligten Teams eingeladen und von einem Moderator durch eine klassische Retrospektive geführt.

Product Owner Collaboration Day

Um mehr Alignment zwischen den einzelnen Product Ownern der Teams sowie der Product Managern herzustellen, treffen sich diese regelmäßig 1-2 Mal die Woche zum Arbeiten in einen großen Raum. Sonst sitzen die POs bei ihren Teams.
Es gibt in der Regel keine vorgegebene oder im Vorwege festgelegte Agenda. Stattdessen finden Gespräche zu Themen spontan statt. Viele Synergien zwischen Aufgaben/Stories der Teams sind in diesen Meetings schon aufgedeckt worden.

 Interne Open Spaces

Bei CoreMedia halten wir regelmäßig firmen-weite Open Spaces ab, bei denen der Firmenvorstand mit konkreten Fragestellungen an die Belegschaft geht. Dies dient neben der Arbeit an Problemen oder Aufgaben auch der Festigung des Verständnisses der Firmenstrategie.

Communities of Practice

Wenn Teams alleine, über die Grenzen von technischen Modulen hinweg, Features implementieren, besteht der Bedarf  zur Koordination zwischen Teams. Hierfür sind bei CoreMedia Communities of Practice (CoP) eingeführt worden. In diesen werden die unterschiedlichsten Themen über Team-Grenzen hinweg diskutiert. Die CoPs bilden sich aus Vertretern einzelner Teams. Für einige CoPs gibt es die von der Leitung der Produktentwicklung vorgegebene Rahmenbedingung, dass aus jedem Team mindestens ein Vertreter entsandt werden muss.

Viele gemeinsame Events

Das meiner Meinung nach Wichtigste für Alignment: viel miteinander reden. Dazu haben wir große und kleine Events. Das geht von gemeinsamen, Team- und Abteilungs-übergreifenden Lunch-Terminen über gemeinsame Sportgruppen bis zu den großen Firmenfeiern. Das wichtige dabei ist die Vernetzung über Team- oder Abteilungsgrenzen hinweg.

Newsletter

Regelmäßige, firmenweite Newsletter von Abteilungsleitern oder der Geschäftsführung sind ein weiteres Mittel, um Alignment über Wissensverteilung herzustellen. Diese Möglichkeit wird trotz der vielen Austausche auf der persönlichen Ebene regelmäßig genutzt und auch gut angenommen.

 

Die vielen einzelnen Methoden, Praktiken und Techniken zahlen gemeinsam darauf ein, dass wir bei CoreMedia Kunden-orientiert und agil arbeiten können, ohne die gemeinsame Ausrichtung zu verlieren.

Agilität, Autonomie und Alignment – Passt das Zusammen?

Das Agile Manifest beschreibt Werte, die als Grundlage für agiles Arbeiten in der Softwareentwicklung dienen. Die im Manifest beschriebenen Werte werden durch 12 Prinzipien ergänzt, die als Leitsätze für die agile Arbeit dienen.  

Längst hat sich dieser Ansatz auch außerhalb von Entwicklerteams herumgesprochen. Doch was bedeutet Agilität für die Arbeitsorganisation von Teams? Stefan Roock fasst dies sehr treffend wie folgt zusammen:

„Agilität  bedeutet Autonome Teams mit Business-Fokus, die ihren Prozess in Besitz und Verantwortung nehmen.“ 

Das heißt, agile Teams sollen möglichst autonom agieren können. Dies ist schön und gut für einzelne  Teams, reicht aber nicht, wenn man Agilität skalieren möchte, also mehr als ein Team agil an einem gemeinsamen großen Produkt arbeiten lassen möchte.

Lokale vs. Globale Optimierung

Wenn man einfach nur viele autonome Teams arbeiten lässt, dann werden diese Teams mit Hilfe von Techniken aus ihrem Agilen Werkzeugkasten kontinuierlich an der Optimierung ihrer Prozesse arbeiten. Dies ist erst mal gut und gewünscht. Es besteht aber die Gefahr, dass man am Ende viele (Team-) lokale Optima hat, die durchaus in Konkurrenz zueinander stehen können und so bei der Organisation insgesamt zu einem Verlust von Business-Fokus führen. Die Frage ist auch ob die Teams dann noch der Firmenstrategie oder einer gemeinsamen Produktion folgen oder eigene, entkoppelte Ideen zu diesen Themen verfolgen.

Was fehlt, ist die eine einheitliche Ausrichtung auf ein gemeinsames, großes, ja Unternehmens-weites Ziel hin. Dies wird als Alignment bezeichnet.

Um ein globales Optimum für eine Firma zu schaffen, muss man daher ein Gleichgewicht aus Autonomie und Alignment der agil agierenden Teams schaffen.

Wie macht man das praktisch?

Die Idee, Autonomie und Alignment, zu kombinieren um bessere Produkte zu schaffen, ist nicht unbekannt. Henrik Kniberg, zum Beispiel,  beschreibt in einem Video über Spotifys Engineering Culture  den Zusammenhang zwischen Autonomie und Alignment.

Kniberg geht dabei so weit, dass er sagt, dass ein hohes Alignment größere Autonomie in den Entwicklungsteams ermöglicht.

In dem vorhergehenden Beitrag von Holger beschreibt dieser, wie wichtig Alignment bei einer agilen Transition ist.

In je einem weiteren Beitrag werde ich schildern, mit welchen Techniken und Prozessen wir bei meinem Arbeitgeber CoreMedia Autonomie und Alignment ins Gleichgewicht bringen.