Wie funktioniert sanftes agilisieren bei bestehenden Teams?

Nehmen wir mal an, wir haben ein Team von Entwicklern, die schon jahrelang zusammenarbeiten. Sie haben eine Führungskraft bei der „das Glas immer halb leer ist“ und bevor ein Problem gelöst werden kann wird immer das große Ganze in Frage gestellt. Wenn eine Anforderung aus dem Business kommt wird die Umsetzung erschwert, weil erst ein großes Konzept erwarte wird, wozu Business jedoch gar nicht in der Lage ist. Durch diese „Nebelkerzen“ wird auch die Führung immer wieder die vorhandene Energie gebremst und die Kommunikation mit den Businessabteilungen blockiert. E-Mail Ping-Pong ist die Folge. Gerne entsteht daraus das beliebte „Finger Pointing“. Das Team hat sich geteilt und bildet kleine Fachgruppen. Jeder versucht sich gut wie möglich durch zu kämpfen…

Wie lässt sich so eine verfahrene Situation auflösen?

Natürlich hat das auch mit Führung und Management zu tun. Als Coaches versuchen wir die Führungskraft zu bewegen, „los zu lassen“, Aufgaben in kleinere Pakete zu zerlegen, die Kommunikation zwischen allen Beteiligten zu fördern, „Command and Control“ abzulegen. Das klappt jedoch meistens nur suboptimal. Leider erlebe ich immer wieder, dass die Führungskräfte nicht in der Lage alte Frustrationen hinter sich zu lassen und Verantwortung abzugeben. Das Management kommt dann unweigerlich in die Situation sich von der Führungskraft trennen zu müssen, damit die Blockaden und „Energiebremsen“ im Team gelöst werden. Das ist schmerzhaft aber manchmal notwendig.

Unabhängig davon lassen sich aber eingefahrene Team mit der Einführung eines Task-Boards sanft an agile Methoden heranführen. Hierzu ist nach meiner Erfahrung allerdings ein externer Coach notwendig, um jahrelange Blockaden und Historie aufzulösen.

Einführung eines Task-Boards

Im ersten Schritt wird ein interdisziplinäres Team aufgebaut. Softwareentwickler, wenn vorhanden Architekt, Operations- und Business-Vertreter werden in ein Team zusammen geholt. So können durch Interaktionen erste Blocken schon im Gespräch gelöst werden. Die Zusammenarbeit im Team braucht dann noch ein gemeinsames Problembewusstsein. Folglich muss zuerst eine Gesprächsebene gefunden werden in der die vorhandenen Themen, Issues, incidents, Service Request (oder wie die Themen im Unternehmen auch immer genannt werden) geklärt und verstanden werden. Mir hilft dabei immer wieder sich zuerst über Kommunikationsregeln im Team zu verständigen. Beispielsweise. „Keiner redet für den anderen“ oder „Wir lassen die Anderen ausreden und unterbrechen uns nicht gegenseitig“. Der Coach hat die Aufgabe darauf zu achten, dass die Regeln eingehalten werden. Durch diese Kommunikation gemeinsam im Team entsteht bei den Problembeschreibungen eine Art Storytelling, die in eine „Verständnisdiskussion“ hinein moderiert wird.

Haben alle Beteiligten ein gemeinsames Verständnis der Themen und Problembewusstsein über die Situation gewonnen, werden die Issues, gemeinsam, nach Wichtigkeit priorisiert. Beim Priorisieren ist es wichtig, dass niemand seinen Wahrheitsanspruch durchsetzt. Auch dann nicht, wenn die Person hierarchisch überstellt ist.

Priorisierungen müssen begründet werden, nur dann ist Zusammenarbeit möglich

Mit der Priorisierung wird das Task-Board eingeführt. Dabei habe ich immer drauf geachtet es KANBAN- oder SCRUM-Board so zu nennen und keine Hintergrunderklärungen zu liefern. Meiner Erfahrung nach ist der Beginn mit PostIT’s an der Wand ein sehr guter Weg. So werden Issues haptisch, eine Priorisierung und das weiter schieben ist eine gemeinsame Aktion. Durch dieses gemeinsame, haptische arbeiten wir eine gemeinsame Identifikation geschaffen.

In meinem letzten Projekt habe ich das Bord etwas umstrukturiert: „Backlog“ (alle vorhandenen Themen), „Umsetzung“ (hier kommen nur die Prio 1 Themen rein), „In Arbeit“, „Gelöst“. Mit Absicht ist in der Einführungsphase Qualitätssicherung und „in Arbeit“ noch in einem Punkt um die Komplexität gering zu halten. Im Laufe des Projektes entwickelt sich die Forderung nach Trennung in Arbeit und QS i.d.R. von selber.

Nach dem Priorisieren kommt das Schätzen des Aufwands. Hier ziehe ich ein Komplexitätsschätzen in Form von Story Points vor. Ich nutzen dazu gerne die Methode „Planning Poker“. Es ist leicht zu verstehen und macht moderiert auch Spaß.

Nun werden die Issues genauer beschrieben. Manche sind schon sehr detailliert, manche Anforderungen liegen in Form von User Stories vor und manche sind nur Überschriften. Bei der Diskussion im Team um die Detaillierungen der Inhalte kommt das Team schnell zum gemeinsamen Verständnis, dass ein Standard für Anforderungsbeschreibungen etablieren werden muss. Ich empfehle dann immer User Stories, da hier im Kern, um etwas geschrieben verhandelt wird und damit das miteinander sprechen im Mittelpunkt steht. Das „Nichtreden“ stand ja schließlich früher oft der Umsetzung im Weg. Wenn Akzeptanzkriterien richtig eingesetzt werden erleichtern diese auch später das Testen. Wir schulen alle Mitarbeiter und fangen an zu üben. Es ist in dieser Phase meine Aufgabe als Coach dabei zu helfen zu erkennen, dass Anforderungsbeschreibungen geübt werden muss, erinnere daran, dass wir zu Beginn niemals alle Information haben und dass genau diese Tatsache den Raum für Kreativität in der Lösungsgestaltung lässt. Die Tasche des nicht alles Wissens ist damit was Gutes.

Parallel dazu beginnt schon die Umsetzung einiger Themen. Jetzt wird ein StandUp (Daily) mit dem gesamten Team eingeführt. Nach den klassischen Regeln was habe ich gestern getan, was habe ich heute vor und hatte ich Blockaden, wenn ja welche.

Empowern, um das Team lernen zu lassen

Ob später dann noch Entwicklungszyklen einbaute oder gar SCRUM lässt sich jederzeit im Team diskutieren und auch gemeinsam entscheiden. Getreu einem zentralen Prinzip aus der SCRUM-Welt: „Selbstorganisation der Teams“. Manchmal entsteht zu Beginn des Transformationsprozesses der Wunsch nach einem Dispatcher, der die unsicheren Teammitglieder, die sich zu Beginn überfordert fühlen, anleitet, die Tasks zu übernehmen, bzw. zu verteilen Diese Rolle übernimmt somit die Vorselektion für das Team. Auch das ist gut. Allein die Tatsache, dass es im Team aktiv gefordert wird, ist der erste Schritt zur Selbststeuerung. Wenn später der Wunsch entsteht sich selber die Tasks aus dem Board zu nehmen ist es wichtig, dass zu zulassen und nicht auf der Rolle des Dispatchers zu bestehen. Wichtig ist es immer wieder neue Methoden vorzustellen und dann das Team entscheiden zu lassen, was sie sich als Tool herausnehmen. Die Coachingrolle wird ergänzt durch Methodenangebot und Training.

Marketing nach innen

Jetzt kommt ein kritischer Punkt: Die gesamte Organisation teilhaben lassen. Nur wie? Kommunikation nach innen läuft über Menschen. Menschen kommunizieren über Überzeugungen und Leidenschaft. Wenn Menschen wissen warum sie etwas machen und von dem überzeugt sind, was sie tun, werde sie zu einem Botschafter. Damit ist für mich als Coach eines der wichtigsten Ziele Teammitglieder zu befähigen zufrieden ihren Job zu machen. Nur so können sie mit Überzeugung mit Ihren Kolleginnen und Kollegen die Erfahrung das Richtige zu tun, teilen. Jedes Teammitglied wird so zum Botschafter und Gesprächspartner im Unternehmen.

Als weiteren Schritt im internen Marketing habe ich gute Erfahrungen damit gemacht, das Task-Board an einem öffentlichen Ort permanent hängen zu lasen. Das schafft Neugierde. Kolleginnen und Kollegen können sich mal zu einem Daily dazu gesellen und zuhören.

So lernt das Team Schritt für Schritt agile Methoden ohne das ein Mal „Buzzwörter“ wir SRCUM, Agil oder gar Design Thinking verwendet werden. Mit jedem Tag vor dem Bord, mit jedem selbstständigen Gespräch macht das Team einen weiteren Schritt in eine agile Welt.

Das letzte Wort soll Nicolas Chamfor bekommen:

»Durch die Leidenschaften lebt der Mensch, durch die Vernunft existiert er bloß.«

Zusammenarbeit als Kern des agilen Handelns

Am Anfang meiner Gedanken stand eine Frage: Warum gibt es Unternehmen?

Die Antwort lautet schlicht: Weil es Aufgaben gibt die man nur zusammen bewältigen kann![1]

Das zentrale Wort in dieser Antwort kommt unscheinbar daher: „zusammen“.

Vor mehr als 10 Jahren tauchte in meiner Arbeitswelt der Begriff SCRUM auf. Hier habe ich das erste Mal den Ausdruck Agilität unter einem neuen Blickwinkel kenngelernt. Im Mittelpunkt des agilen Manifest und jedem Buchs zum Thema versteckte sich nämlich auch das schmale Adverb „zusammen“.

Beim Schätzen von Aufwänden wird „zusammen“ geschätzt. Bei Problemlösungen wird zusammen, interdisziplinär, nach Lösungen gesucht. Und nicht zuletzt beim Anforderungsmanagement ist das Erstellen von User Stories ein „zusammen“ mit Nutzern, Kunden, Entwicklern, Requirements Engineers, Produkt Ownern oder Produkt Managern etc.

Die gewollte Interdisziplinarität ist nichts anderes als ein Zusammenarbeiten von Menschen mit verschiedenen Fähigkeiten.

Ich möchte hier nicht eine weitere Abhandlung über Agilität und den Sinn und Zweck agiler Methoden schreiben. Ich möchte nur kurz vorweg stellen warum agiles Handeln so wichtig geworden sind.

In unsicheren Zeiten müssen gerade bei langlebiger Software schnell und fundiert Entscheidungen getroffen werden. Vor allem die Abhängigkeit und das Gleichgewicht von Kundensicht, Technologie und Wirtschaftlichkeit müssen im Fokus bleiben. Langwierige und hierarchische Entscheidungswege verlieren jedoch den Kunden aus dem Blick. Das zentrale Problem ist, dass eine Person, ein Produktmanager oder ein Produkt Owner alleine nicht die vielfallt der komplexen Abhängigkeiten berücksichtigen kann. Nur wenn das Produkt als Ganzes unter Berücksichtigung des Zielmarktes im Blick gehalten wird, können sinnvolle Entscheidungen getroffen werden. Wird jedoch ein Produkt in einzelne Projekte oder Funktionalitäten zerlegt geht der Blick auf das ganze Produkt[2] sowohl fachlich als auch wirtschaftlich verloren. Damit einher geht auch der Verlust des Blicks auf die Kundenbedürfnisse.

Doch wer hat im Produkt denn nun die Verantwortlichkeit?

SCRUM geht da ganz hierarchisch und absolut vor. Der Produkt Owner hat die alleinige Verantwortung.

Diese Meinung teile ich inzwischen nicht mehr. Interdisziplinarität ist auch auf der Verantwortlichkeitsebene eine Möglichkeit das „Richtige, richtig“ zu machen.

Die Zusammenarbeit zwischen verschiedenen Disziplinen und Handlungserfahrungen steht demzufolge im Mittelpunkt der weiteren Überlegungen.

Was ist nun eigentlich Zusammenarbeit?

Zusammenarbeit entsteht dann, wenn ein Problem nicht alleine zu bewältigen ist. Die Besonderheit der Zusammenarbeit liegt darin, dass Menschen mit unterschiedlichen Fähigkeiten, Talente, Erfahrungen, Stärken und Schwächen ihre Eigenschaften bündeln, um das Best mögliche Ergebnis zu erzielen. Anders formuliert: Die Zusammenarbeit verschiedener Disziplinen und Handlungserfahrungen ermöglicht unterschiedliche Blickwinkel auf ein Problem. So sind auch Lösungen zu entwickeln die aus einem Blickwinkel alleine nicht zu erkennen sind.

Beschäftigen wir uns etwas genauer mit Interdisziplinarität. Hier liegt ein Schlüssel für die Zusammenarbeit in einem Unternehmen.

Wenn nur Menschen aus den gleichen Disziplinen, mit den gleichen Methoden, Ansichten und Handlungserfahrungen zusammenarbeiten, teilen alle die Gewissheit das richtige zu tun. Habe ich aber Gewissheit bin ich nicht mehr offen für Veränderungen. Zweifel, also ein „Infragestellen“, ist jedoch der Treibstoff für Veränderungen.

In Gruppen, in denen Menschen aus unterschiedlichen Disziplinen, mit unterschiedlichen Erfahrungen und Talente zusammenarbeiten, können neue Dinge gedacht und entwickelt werden.

Damit dies funktioniert gibt es zwei grundlegende Bedingungen, quasi die Spielregeln der Interdisziplinarität:

  1. Gemeinsame Identifikation mit der Sache oder einem zu lösenden Problem: Dies ist möglich durch die Entwicklung einer gemeinsamen Challenge (Vision). Allerdings ist dabei zu beachten, dass möglichst alle Beteiligten, oder Neudeutsch: Stakeholder, einbezogen sind.
  2. Anerkennung der Fähigkeiten und Verantwortung des Anderen. Das bedeutet sehr verkürzt: Niemand im Team setzt (s)einen absoluten Wahrheitsanspruch durch.

Nimmt man diese zwei Spielregeln ernst wird klar, dass sich Teams nicht einfach auf Basis von unterschiedlicher Fachlichkeit zusammenstellen lassen. Hier liegt eine besonders spanende Führungsaufgabe in agilen Organisationen. Die einzelne Fachlichkeit spielt nämlich nicht die entscheiden Rolle. Es geht um die Fähigkeit der Teammitglieder sich untereinander anzuerkennen und nicht eigene Erkenntnisse als objektiv zu inszenieren, um diese als Wahrheit im Team durchzusetzen.

Zu diesem sich gegenseitig anerkennen kommt noch die sinnstiftende, gemeinsame Identifikation oder das gemeinsam Verständnis einer Problemsituation. Dieses Verständnis muss erarbeitet werden. Das funktioniert nur wenn der Problemlösung ein Sinn gegeben wird. Die Situation muss mit Bedeutung aufgeladen werden. Um es mit Sprenger zu sagen, wenn ein Problem erst ein 8 Semester BWL Studium braucht, um es zu verstehen, wird es nicht Sinnstiftend sein.

Wie kann Zusammenarbeit im Unternehmen gefördert werden? Die zentrale Führungsaufgabe um dies zu erreichen beschreibt ein sehr schöner englischer Begriff: Empowerment.

Empowerment ist in der agilen Welt mit Befähigung und Bevollmächtigung zu übersetzen.

Befähigung meint die Menschen mit den neuen Methoden und Leitlinien nicht alleine zu lassen, sie zu schulen, zu begleiten, zu Coachen.

Bevollmächtigen „…steht für den Freiraum zur Selbstorganisation“ (Matthias Grund in „Das demokratische Unternehmen“ S. 159).

 

[1] Vgl.: Dr. Reinhard K. Sprenger; Radikal Führen; 2012