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ß.«