Dr. Wolfgang Brandhuber 24. Februar 2015

Agile Moves: Selbstorganisation trainieren durch Augenhöhe

Die entscheidende Fähigkeit, die Integration der Arbeitsschritte voranzubringen, ist Zusammenarbeit auf Augenhöhe. © depositphotos.com / yellow2j — Agile Moves: Selbstorganisation trainieren durch Augenhöhe © depositphotos.com / yellow2j

Das Fundament der agilen Entwicklung

Selbstorganisierende Teams sind meiner Meinung nach das Fundament jeder agilen Entwicklung. Nach meiner Erfahrung hängt der Erfolg agiler Projekte direkt davon ab, wie gut Teams sich selbst organisieren können und vor allem dürfen. Aber auch wenn ich glaube, dass jeder Mensch gewisse Fähigkeiten besitzt sich selbst zu organisieren, braucht es in aller Regel in unserer Gesellschaft viel Ermutigung, Training und das Vorleben funktionierender Selbstorganisation durch Vorgesetzte, um diese Fähigkeiten in einem Umfang auszubilden, der dem Projekt einen messbaren Mehrwert bringt.

Genauso wie ich ins Fitness-Studio gehe, um meine Muskulatur zu trainieren, braucht es aus meiner Sicht gezieltes Training, um meine innere Muskulatur zur Selbstorganisation aufzubauen. Kindheit und Jugend verbringen wir in unserer Gesellschaft in einem Schulumfeld, in dem selbstorganisierende Teams kaum eine Rolle spielen. Und auch wenn das Studium die eigene Selbstorganisation in einem gewissen Umfang fördert, werden keine Fähigkeiten vermittelt, um besser mit anderen in Teams zusammenzuarbeiten. Spätestens mit der Arbeit in einer traditionellen Linienorganisation, in der das eigene Vorankommen wesentlich stärker davon abhängt, Vorgesetzten zu gefallen, als ein guter Teamspieler zu sein, bleibt Teamfähigkeit zugunsten der Karriere auf der Strecke.

Aber warum ist ausgerechnet Selbstorganisation das Herz der agilen Entwicklung?

Das Riemann-Integral

Als jemand, der schon immer von Mathematik fasziniert war, hat der Übergang vom klassischen Projektmanagement zu agilen Methoden für die Softwareentwicklung aus meiner Sicht eine ähnliche Bedeutung wie die Einführung der Infinitesimalrechnung [1] durch Leibniz & Newton für die Mathematik. Um diese Parallele zu veranschaulichen, verwende ich eine stark vereinfachte Form der Summenzerlegung einer Fläche nach Darboux [2].

Wenn ich die Größe einer Fläche unter einer Kurve bestimmen möchte, kann ich diese Fläche durch Rechtecke gleicher Breite annähern. Je schmaler ich die Rechtecke wähle, um so genauer wird meine Annäherung. Aber egal wie schmal ich die Rechtecke wähle, solange sie noch eine gewisse Breite haben, wird die Summe der Rechteckflächen immer ein wenig kleiner sein als die tatsächliche Fläche unter der Kurve. Erst mit der Überschreitung der Grenze von endlicher Breite hin zu unendlich schmalen Rechtecken kann ich die Fläche richtig berechnen. Diese Berechnung wird als Riemann-Integral [3] bezeichnet und dieser Grenzübergang ist eine der großen Errungenschaften der Infinitesimalrechnung.

Abb.1: Das Riemann-Integral – Je schmaler die Rechtecke sind, umso genauer wird meine Annäherung. © Milenko Buguneo

Softwareentwicklung nach dem Wasserfall-Modell besteht ebenfalls aus vielen Stufen. Was in einer Stufe erarbeitet wurde, wird als Arbeitspaket an die nächste Stufe weitergegeben. Bei konservativer Betrachtung werden zuerst alle Arbeiten einer Stufe fertig gestellt und die Ergebnisse als Gesamtpaket an die nächste Stufe weitergegeben, sodass immer nur eine Stufe hauptverantwortlich am Projektfortschritt arbeitet. Eventuell muss ein Arbeitspaket noch einmal zurückgegeben werden, wenn es fehlerhaft oder unklar ist, was vielleicht einzelne Teammitglieder blockiert. Bei jeder Übergabe entsteht also immer eine gewisse Unterbrechung des Arbeitsflusses.

Etwas liberaler interpretiert können auch mehrere oder alle Stufen gleichzeitig aktiv sein. Zwischen den Stufen werden dann kleinere Arbeitspakete weitergereicht. Somit nähert man sich an einen kontinuierlichen Arbeitsfluss an, genauso wie sich die Darboux-Summe bei schmaleren Rechtecken dem Integral annähert. Oft wird schon diese Sicht des Wasserfall-Modells als agile Entwicklung bezeichnet und der Entwicklungsprozess als um so agiler angesehen, je kleiner die weitergereichten Pakete geschnürt werden. Aber egal wie klein diese Pakete auch sind, es bleibt immer ein Wasserfall.

Abb.2: Ein integrierter kontinuierlicher Workflow. © Milenko Buguneo

Was also wäre das Quantensprungäquivalent zum Riemann-Integral in der agilen Welt? Was wäre das exakte Integral unter der Kurve?

Ein integrierter Workflow. Weg von einzelnen Work Steps hin zu einem kontinuierlichen Arbeitsfluss. Erst die Auflösung der Arbeitsschritte und die Verschmelzung aller notwendigen Arbeiten macht die agile Entwicklung deutlich schneller als alle traditionellen Methoden.

Von Work Steps zum Workflow

Dabei stehen wir aus meiner Sicht mit der Integration der Arbeitsschritte, die in einem Software-Projekt anfallen, erst ganz am Anfang. Ein Beispiel ist die Integration von Programmierung und Test. Im Wasserfall-Modell ganz klar zwei getrennte Schritte. In agilen Projekten werden bestimmte Tests bereits parallel zur Entwicklung ausgeführt, um die Feedbackzyklen zu verkürzen. Ein anderes Beispiel ist Behavior Driven Development (BDD) [4]. Dabei können schon während der Spezifikation durch eine standardisierte Beschreibung automatisiert Tests angelegt werden, gegen die dann später entwickelt wird. Continuous Integration [5] und Testautomatisierung [6] wären weitere Beispiele, genauso wie User Story Mapping Workshops [7], in denen die Entwickler gemeinsam mit den Auftraggebern die Weiterentwicklung der Software immer wieder neu festlegen.

Jede Verschmelzung und Automatisierung von Prozessschritten bringt das Projekt einem kontinulierlichen Workflow näher und eröffnet gleichzeitig neue Möglichkeiten für weitere Integrationen. Wer ernsthaft daran interessiert ist, Software schneller und effizienter zu entwickeln, wird meiner Meinung nach nicht daran vorbeikommen, dieses Prinzip der kontinuierlichen Integration von Prozessschritten in den Mittelpunkt der Weiterentwicklung seines Projekts zu stellen.

Solange man nur mit einem Team arbeitet, wie zum Beispiel in der ursprünglichen Variante von Scrum, mag diese Integration der Arbeit einfach erscheinen. Mit dem Idealbild der cross-funktionalen Teams, in denen theoretisch jeder die Aufgaben aller anderen Teammitglieder übernehmen kann, die alle im selben Büro sitzen und Zugang zu den selben Informationen haben, käme man diesem Idealbild der integrierten Prozessschritte vielleicht oberflächlich schon sehr nahe. Aber zum einen entspricht dieses Idealbild keinem realen Projektalltag und zum anderen müssten auch in diesen Teams bestimmte Work Steps abgearbeitet werden, je nachdem welche Technologien und Methoden zum Einsatz kommen.

Spätestens aber bei skalierten Projekten mit mehreren Teams und stark unterschiedlichen Fähigkeiten der einzelnen Projektmitglieder wächst die Anzahl der einzelnen Arbeitsschritte zu einem Berg an, der für den einzelnen Mitarbeiter unüberschaubar wird. Jeder ist dann Teil einer Vielzahl von Arbeitsketten, deren einzelne Schritte nur von bestimmten Personen oder Teams erledigt werden können und deren Ergebnisse nach fest definierten Vorgaben an andere übergeben werden.

Jede einzelne Automatisierung oder Integration zweier oder mehrerer Arbeitsschritte kann die Geschwindigkeit und Effizienz der Projektarbeit deutlich erhöhen. Um aber Automatisierung und Integration zu einem festen Bestandteil der Weiterentwicklung eines Projekts zu machen, braucht es nach meiner Erfahrung vor allem eines: Augenhöhe zwischen allen Projektmitgliedern.

Augenhöhe trainieren...

Die entscheidende Fähigkeit die Integration der Arbeitsschritte voranzubringen ist Zusammenarbeit auf Augenhöhe. Solange ich in einer Hierarchie arbeite, werde ich tun, was von mir verlangt wird. Wenn bestimmte Prozesse einmal definiert wurden, muss ich sie einhalten, bis sie von höherer Stelle geändert werden. Vielleicht sind meine Vorgesetzten an meinen Ideen interessiert, vielleicht existiert sogar ein Anreizsystem, um gute Ideen zu fördern. Aber selbst in diesen günstigen Fällen werden meine Ideen von Dritten bewertet und selektiert. Welche Idee sich am Ende durchsetzt, entscheiden andere. Menschen, die meine Arbeit nicht machen.

Formen emotionaler Inkontinenz

In selbstorganisierten Arbeitsgruppen entscheidet das Team und es entscheidet über seine eigene Arbeit. Jeder Arbeitsschritt innerhalb des Teams kann auf den Prüfstand gestellt werden. Jede Idee, Arbeitsschritte miteinander zu verschmelzen oder zu automatisieren, kann weiterverfolgt werden. Wenn alle im Team ihre innere Muskulatur gut genug trainiert haben, um auf Augenhöhe miteinander arbeiten zu können, werden sich am Ende die besten Ideen durchsetzen. Wenn... Denn allzu oft entstehen auch in explizit hierarchiefreien Teams versteckte Rangordnungen, meist durch "emotionale Inkontinenz". Jemand möchte seine Idee durchsetzen und übt emotionalen Druck aus. Ein anderer findet sich und seine Ideen sowieso grundsätzlich schlecht und fängt gar nicht erst an, sie mit anderen zu teilen. Und wieder einem anderen ist das Team völlig egal. Er macht lieber sein Ding und hofft von den anderen in Ruhe gelassen zu werden. Alles Formen emotionaler Inkontinenz. Alles kein Problem, wenn der Wille dazu da ist, sein Teamspiel zu trainieren und einem guten Plan zu folgen.

...im Team

Meiner bisherigen Erfahrung nach lässt sich Augenhöhe innerhalb eines Teams am besten mit einer passenden Variante des Ideen-Moves trainieren. In meinem letzten Artikel über Agile Moves ("Agile Moves: Agilität trainieren") habe ich bereits einen einfachen Trainingsplan zum Ideen-Move aufgelistet. Im Grunde geht es bei diesem Move immer nur darum, dass alle Teammitglieder ihre Ideen aufschreiben und gegenseitig bewerten, zum Beispiel mit ein bis fünf Sternen. Die Ideen mit den besten Bewertungen werden dann vom Team weiterverfolgt.

Wenn es im Team große Schwierigkeiten mit emotionaler Inkontinenz einzelner Teammitglieder gibt, könnte in der Anfangszeit zum Beispiel auch eine Variante helfen, in der jeder seine Ideen entweder anonym in einem geeigneten Computer-Programm aufschreibt oder sie auf Karteikarten druckt, um den Autor nicht an der Handschrift erkennen zu können. Oder das Team beschließt, dass jedes Teammitglied bis zu einem gewissen Zeitpunkt seine Bewertung abgeben haben muss. Auch in Sprint-Retrospektiven regelmäßig über die Auswertungen dieses Ideen-Moves zu sprechen kann helfen, solange diese Informationen ausschließlich team-intern verwendet und nicht nach außen weitergegeben werden.

Wer hat wie viele Ideen aufgeschrieben?
Wer hat insgesamt wie viele Bewertungssterne abgegeben?
Wie viele Ideen von welchen Teammitgliedern werden weiterverfolgt?

Je nachdem, an welcher Stelle im Team der Schuh am meisten drückt, können die Fragen erweitert oder andere Varianten des Moves ausprobiert werden.

...in unterschiedlichen Rollen

Wenn bestimmte Rollen im Projekt mehr Gewicht haben als andere, kann es auch helfen, Augenhöhe zu trainieren, indem man diese Rollen explizit auf eine Ebene stellt. Sind zum Beispiel in einem Scrum-Projekt bei der Erweiterung eines Altsystsems mit fachlichen Entscheidungen des Product Owners auch oft wichtige technische Entscheidungen verbunden, kann man für eine gewisse Zeit alle Entscheidungen des Product Owners durch einen technischen Architekten bestätigen lassen und umgekehrt. Beiden ein Veto-Recht einzuräumen trainiert Augenhöhe im Projektalltag. Genauso könnte man dem Product Owner für begrenzte Zeit bei bestimmten Entscheidungen einen Scrum Master zur Seite stellen. Wenn diese Zusammenarbeit reibungsfrei klappt und damit das Trainingsziel erreicht wurde, die Abstimmung zwischen diesen Rollen also zu einem ganz normalen Teil des Projektalltags geworden ist, hat das Projekt insgesamt an Augenhöhe gewonnen und damit auch einen höheren Grad der Selbstorganisation erreicht.

Dieses Prinzip der Gewaltenteilung oder "Balance of Power" [8] sollte in gut funktionierenden agilen Projekten ohnehin eine Selbstverständlichkeit sein. Gibt es Widerstand bei der Einführung oder läuft der Projektalltag aus Sicht einiger Projektmitglieder dadurch weniger rund, ist das ein sehr guter Indikator dafür, dass auf Augenhöhe im Projektalltag bisher wohl nicht allzuviel Wert gelegt wurde. Das Maß an Augenhöhe zwischen allen Kollegen ist immer ausschlaggebend für die Fähigkeit zur Selbstorganisation und damit auch für die Integration der Arbeitsschritte zu einem kontinuierlichen Arbeitsfluss.

...in skalierten Projekten

In Projekten mit mehreren Teams entstehen durch zusätzliche Management-Ebenen neue Herausforderungen auf Augenhöhe zusammenzuarbeiten. Einerseits ist es wichtig eine Ebene zu haben, die die Arbeit der einzelnen Teams koordiniert und verbindliche Entscheidungen trifft. Andererseits wird die Agilität des gesamten Projekts durch die Agilität dieser Management-Ebene hart begrenzt. Wenn es eine Hierarchie in meinem Projekt gibt, kann die Agilität der Untergebenen immer nur so groß sein wie die Vorgesetzten Agilität verstehen und vorleben. Deshalb ist ein Training der Augenhöhe in diesen Projekten besonders wichtig.

Sehr effektiv ist ein Managementteam, das genauso hierarchiefrei arbeitet wie im klassischen Scrum [9]. Entscheidungen müssen wie in den Entwicklerteams auch von allen getroffen werden. Zum einen baut jeder Einzelne im Managementteam dadurch innere Muskulatur auf, die ihm hilft, auch mit den Mitarbeitern der untergeordneten Teams gleichberechtigt zusammenzuarbeiten, zum anderen nimmt die Anbiederung durch Untergebene deutlich ab, wenn sie sich nicht nur bei einem Vorgesetzten, sondern gleich bei einem ganzen Team lieb Kind machen müssen.

Hilfreich ist auch, die Zuständigkeiten im Managementteam für alle im Projekt transparent zu klären. Grundsätzlich hat das Management ohnehin zwei gegenläufige Aufgaben: “Optimierung” und “Vision”. Optimierung innerhalb festgelegter Rahmenbedingungen bedeutet den Status Quo zu sichern und für einen möglichst reibungsfreien Ablauf im Projektalltag zu sorgen. Auftretende Probleme in den Griff zu bekommen gehört genauso dazu wie die Optimierung der Prozessschritte oder das Schärfen des Rollenverständnisses einzelner Projektmitglieder. Alles, was die gegebenen Rahmenbedingungen stärkt, schützt und sichert. Im Gegensatz dazu fällt unter Vision alles, was die Rahmenbedinungen weiterentwickelt: Das Erarbeiten neuer Perspektiven, wohin sich das Projekt in einem Monat, einem halben oder einem Jahr entwickeln könnte, genauso wie die Entwicklung eines Weges, um möglichst schnell und effektiv dort hinzukommen. Durch die Gleichberechtigung dieser beiden Aufgaben wird vermieden, dass Prozesse nicht mehr eingehalten werden, weil es sowieso bald neue gibt, oder dass Konzepte schon in frühen Phasen als unrealistisch verworfen und den Schwierigkeiten des Projektalltags untergeordnet werden.

Wenn allen im Projekt klar ist, wer im Management für welche dieser Aufgaben zuständig ist und wenn beispielsweise ein Kanban Board für das Managementteam eingeführt wird, aus dem klar hervorgeht, wer im Moment an welchen Aufgaben arbeitet, können für das Management genauso Key Performance Indicators [10] eingeführt werden wie für alle anderen Teams im Projekt. Zusätzlich hilft dem Managementteam auch ein regelmäßiges 360-Grad-Feedback [11], zum Beispiel am Ende jedes Sprints, um Augenhöhe auch mit den Untergebenen zu trainieren.

Ernsthaft agil?

Wenn ich also ernsthaft daran interessiert bin, agil zu arbeiten, reicht es nicht aus, die Arbeitspakete zwischen den einzelnen Stufen des Wasserfalls kleiner zu schnüren. Automatisierung und Integration von Arbeitsschritten hin zu einem kontinuierlichen Arbeitsfluss sollte ein zentrales Prinzip des Projekts werden. Alle Arbeitsschritte, die ich sinnvoll miteinander verschmelzen oder automatisieren kann, sollten auch verschmolzen oder automatisiert werden. Genauso sollten auch alle neuen Arbeitsschritte, die dadurch entstehen, immer wieder auf den Prüfstand gestellt und weiter integriert werden.

Um damit schnell und effizient voran zu kommen, brauche ich die besten Ideen des Projekts. Die bekomme ich nur, wenn alle Teams sich wirklich selbst organisieren dürfen und regelmäßig gecoacht werden, um sich auch selbst organisieren zu können. Jede Form der Selbstorganisation wird hart begrenzt durch die Fähigkeit der Teammitglieder, auf Augenhöhe zusammenarbeiten zu können und durch das Maß an Augenhöhe, dass vom Management täglich vorgelebt wird. Für beides ist es wichtig, Trainingspläne zu erarbeiten und Kennzahlen einzuführen, um die Trainingsfortschritte messbar zu machen.

Mit Hilfe des Prinzips der "Agile Moves" lassen sich Trainingseinheiten erstellen und regelmäßig – nach jeder Woche, jedem Sprint oder jedem Monat – messen, um welchen Betrag genau Augenhöhe, Selbstorganisation und Ideenfluss zugenommen haben. Mit Hilfe eines Übersichtsdiagramms über alle Arbeitsschritte und Arbeitspakete im Projekt lässt sich für alle Projektmitarbeiter transparent dokumentieren, welche Arbeitsschritte als nächstes automatisiert und integriert werden sollen und wie viele Arbeitsschritte das gesamte Projekt umfasst.

Die Kunst, die Menge nicht getaner Arbeit zu maximieren.

Und sollten irgendwann alle diese Werkzeuge und Trainingspläne zu einem selbstverständlichen Teil des Projektalltags geworden sein, ist es wichtig, immer wieder zu hinterfragen, ob sie ihrer ursprünglichen Idee immer noch gerecht werden: "Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell" (10. Prinzip der agilen Softwareentwicklung) [12].