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 Tewis ist Agile Enterprise Coach
www.holgertewis.de

Pipeline – ein Teambuilding Spiel

Letztes Jahr konnte ich leider nicht dabei sein, aber dieses Jahr habe ich ihn mir nicht entgehen lassen: Der Agile by Nature Play Day will für die tägliche Arbeit spielerische Formen finden und fördern, um beim Lernen zu helfen. 24 Spielwillige trafen sich in den Räumen von sitegeist in Hamburg, stellten sich gegenseitig Spiele vor und networkten über kalten Getränken. Bilder von dem Tag gibt es auf der Webseite von Agile by Nature zu sehen.
Von den vielen interessanten Sessions stelle ich hier als erstes ein Spiel aus der Session „Teambuilding Spiele“ von Hendrik vor.

Pipeline
Bei Pipeline geht es darum, im Team eine rollende Kugel in ein Ziel zu befördern. Dazu bekommt jedes Team einige Rinnen. Die Anzahl variiert mit der Anzahl der Teammitglieder. Es sind immer deutlich weniger Rinnen als Mitspieler. Das Team muss schnell und geschickt Rinne an Rinne reihen, während die Kugel durch diese rollt. Leider ist die Gesamtlänge aller Rinnen kürzer als die zu überwindende Strecke …

Es gibt die folgenden einfachen Grundregeln:

• Die Kugel muss jederzeit vorwärts durch eine Rinne rollen.
• Kein Teilnehmer darf die Kugel berühren.
• Eine Rinne darf nur von genau einem Team-Mitglied gehalten werden.
• Wenn jemand eine Rinne mit der Kugel in der Hand hat, dann darf diese Person sich nicht mit der Rinne im Raum bewegen.

Material:

• Mehrere Rinnen (z.B. Regenrinnen aus dem Baumarkt)
• Eine Kugel, die in die Rinne passt

Lernziel ist es, dass sich das Team koordinieren muss, um die Kugel ins Ziel zu bringen. Die Kugel kann alles mögliche repräsentieren, z.B. ein Software-Artefakt, das erstellt und deployed werden soll.
Das Spiel lässt sich leicht an den jeweiligen Kontext anpassen, z.B. durch Hinzufügen oder Anpassen von neuen Regeln oder durch Aufteilung in mehrere Teams, die gegeneinander antreten müssen. Auch die Aufgabe kann angepasst werden, z.B. indem ein Team mehrere Kugeln ins Ziel bringen und deren Durchlaufzeit kontinuierlich reduzieren muss.
Eine weitere Variationsmöglichkeit ergibt sich durch die Art des Zielbehälters. In unserem Fall war dies eine flache Plastikbox. Das hat den Schwierigkeitsgrad erhöht, da die Kugel leicht über das Ziel hinausschießen kann. Eine breite Tonne oder ein Eimer als Ziel wäre meiner Meinung nach einfacher gewesen.

Hier eine Aufnahme von einem unserer grandiosen (Fehl-) Versuche:

Mein Fazit zum Play Day

Der Play Day ist eine super Veranstaltung, auf der man viel lernt und neue Bekanntschaften macht.

Besonders empfehlenswert ist er für Agile Coaches und solche, die es werden wollen. Im kommen Jahr will ich unbedingt wieder dabei sein und möglichst ein eigenes Spiel vorstellen. So kann man in freundlicher Umgebung die Moderation eines Spiels üben, bevor man es am eigenen Team ausprobiert.

Also, einen Daumen hoch für die Veranstaltung!

Ich werde in ein, zwei Blog Posts noch weitere Spiele vorstellen, die ich kennenlernen durfte.

Struktur eines agilen Transitionsteams

Die Durchführung einer größeren organisatorischen Veränderung kann von einem Transitionsteam begleitet werden, das die Transition vorantreibt und für eine Umgebung sorgt, die im Sinne der Transition erwünschte Muster verstärkt. Im Zuge der agilen Transition der Web Development Abteilung bei Goodgame Studios durchlief unser Transitionsteam verschiedene Organisations-Formen, über die ich hier berichten möchte.

Ende 2014 hat sich Goodgame Studios (im Folgenden GGS) entschieden die Software-Entwicklung im zentralen Bereich Web Development auf agile Vorgehensweise umzustellen (Scrum/Kanban). Mit dem Mandat des CTO haben wir dazu von Anfang an ein Team etabliert, das diesen Prozess begleiten und vorantreiben sollte.

Um gleichzeitig als Vorbild zu dienen, haben wir uns entschlossen dieses Transitionsteam auf agile Art zu organisieren und uns am Scrum-Framework orientiert. Als Produkt des Transitionsteams betrachteten wir die vollständig agilisierte Abteilung, auf die wir uns in wertschaffenden Sprintinkrementen zubewegen wollten. Zu besetzen waren nun die drei Rollen Scrum Master (bzw. Agile Coach), Product Owner und Team. Product Owner wurde der Abteilungsleiter, Scrum Master eine erfahrene externe Coachess und das „Dev“-Team setzte sich zusammen aus Führungskräften und Vertretern der einzelnen Positionen (Projekt Manager, Produkt Manager, Entwickler).

Wir begannen mit einer Sprintlänge von zwei Wochen, wobei wir Sprintplanung, Review und Retro komplett am Mittwochnachmittag durchführten. Standups gab es zwei die Woche, am Dienstag und Donnerstag. Transitions-Backlog und Sprint-Backlog haben wir nicht als physisches Board aufgesetzt, sondern in Jira, vor allem um den auf dem GGS-Gelände weit verteilten Entwicklungsteams einfachen und transparenten Zugriff zu gewährleisten.

Nachdem wir dies circa ein halbes Jahr ausprobiert hatten, stießen wir auf eine Reihe von Problemen:

• Das Transitionsteam konnte nicht alle Entwicklungsteams gleichzeitig adressieren, so dass sich manche Teams vernachlässigt fühlten, insbesondere da wir öffentlich versprochen hatten, dass das Transitionsteam für die ganze Abteilung da sein würde.
• Parallel zum Transitionsteam trafen sich wöchentlich die Teamleads des Bereichs und verfolgten eine eigene Agenda, die zum Teil im Widerstreit mit den Zielen des Transitionsteams stand. Obwohl in beiden Teams der Abteilungsleiter als Product Owner fungierte, gab es immer wieder Alignment-Schwierigkeiten zwischen den beiden Führungsteams.

In Summe gab es Entwicklungsteams, die gar nicht adressiert wurden und dann wiederum solche, die von beiden Führungsteams mit z.T. widersprüchlichen Zielen angesprochen wurden.

Um dieses Problem zu lösen, schwenkten wir um auf das von uns sogenannte Flower-Modell:

Dazu ordneten wir die ganze Abteilung in drei Cluster, aus denen Product Owner (PO), Teamlead (TL) und Agile Coaches (AC) der Entwicklungsteams ein für ihren Cluster verantwortliches Transitionsteam bildeten (POTLAC). Das alte Transitionsteam, verwandelte sich in eine Art Product Owner Team und entsandte Delegierte als Transitions-Product Owner in die drei POTLACS. Die Treffen der Teamleads wurden abgeschafft.

Die POTLACS führten 4-Wochen-Sprints durch, jeweils um eine Woche versetzt, so dass sich das Transitions-Product-Owner-Team in der 4. Woche mit Koordinationsthemen beschäftigen konnte.

Mit dem Flower-Modell schafften wir es tatsächlich, näher an die Teams heranzurücken. Nur die 4-wöchigen Sprints fühlten sich zu lang an. Dieses Problem lösten die Teams unterschiedlich: Einer der Cluster entschloss sich auf Kanban umzustellen. Statt längerer Scrum-Meetings alle 4 Wochen führte dieses Team tägliche Standups durch, zu denen der Product Owner bei Bedarf dazustieß und im Anschluss Stories priorisieren bzw. abnehmen konnte. Der freigewordene Meeting-Slot am Mittwoch ermöglichte den anderen beiden POTLACS auf 2-Wochen-Sprints zu wechseln.

Retrospektiv betrachtet lag die größte Herausforderung beim Aufsetzen der Struktur des Transitionsteams darin, ein für die Größe der zu agilisierenden Abteilung angemessenes Alignment zu finden. Das Spannungsfeld sah dabei ähnlich aus wie Henrik Knibergs Autonomy/Alignment Matrix:

Das Management strebte Quadrant A an, also hohes Alignment bei hoher Autonomie der Teams. Im Laufe der Zeit wurde aber immer wieder darum gerungen, was das bedeutete.

Für einige Teams sah es so aus, als wäre man zu weit in Quadrant B gerutscht, da die Arbeit mit dem Transitionsteam zusätzlichen Aufwand erzeugte, der als Overhead oder gar Micro-Management wahrgenommen wurde. Neben den Transitions-Meetings waren dies vor allem vorgeschlagene Standards (z.B. ein einheitliches Format für Roadmaps), für die manche Teams keinen direkten Mehrwert zu bekommen glaubten.

Aus Perspektive des Managements sah es gerade am Anfang so aus, als rutschten die Teams zu stark in den Quadranten C, zum einen weil sie unterschiedliche Schwerpunkte bei der Agilisierung setzten, zum anderen weil manche Teams in der ursprünglichen Aufstellung des Transitionsteams unter dem Radar flogen.