Agilität und Disziplin

Vor einiger Zeit haben wir ein Scrum@Scale Training mit dem Co-Schöpfer von Scrum, Jeff Sutherland gegeben. Irgendwann wies ein Trainingsteilnehmer, ein langjährig erfahrener agiler Coach, Jeff darauf hin, doch nicht zu sehr bei den Teams auf ständige Verbesserung zu pochen. Es gab eine kurze Diskussion, die jemand mit dem Hinweis "this is a philosophical debate" abbrach.

Dieses Erlebnis klingt noch in mir nach. Daher diese kurze Geschichte über Disziplin und Kreativität in einer agilen Umgebung.

Ein Teamkonflikt.

Einige Jahre her. Sechs Teammitglieder, crossfunktional, regional verteilt, nicht ausschließlich dem Team zugeordnet. Nicht immer stabil, schmerzlicherweise.

Sie versuchten sich in Scrum, benutzten einige Elemente, wesentliche Elemente fehlten.

Das Team arbeitete in einwöchigen Sprints. Da sie im Land verstreut waren, sich nicht oft sahen, nicht hauptsächlich an gemeinsamen Dingen arbeiteten, organisierten sie sich in einer leichtgewichtigen einstündigen Sitzung, jeden Montagmorgen. Über's Telefon.

Die Sitzung begann mit einem Sprint Review, in dem das Team prüfte, ob es das gemeinsame Sprint Ziel erreicht hatte. Anschließend tauschten die Teammitglieder Lernerfahrungen des vergangenen Sprint aus. Danach fragte sich das Team, welche Auswirkungen diese Lernerfahrungen auf das Product Backlog hatten. Inwiefern beeinflusste das Tagesgeschäft die langfristige Strategie? Das war ein sehr kurzes Product Backlog Refinement.

Sprint Review und Backlog Refinement machten einen großen Teil der Sitzung aus. Spätestens bis zu diesem Zeitpunkt zerbrach die Sitzung ab und zu. Denn es entwickelte sich häufig eine Diskussion über die gemeinsame Vision bzw. über die Abwesenheit einer gemeinsamen Vision. Sie hätten darüber in der Sprint Retrospektive sprechen können. Da aber nicht jeder immer in der Montagssitzung dabei war, kam das Team nicht richtig voran. Aus der ungeklärten Diskussion entwickelten sich handfeste Konflikte.

Jemand hat mal gesagt, man könnte die Kultur eines Unternehmens sehr schnell erkennen, sobald man ein Meeting besucht (/1/). Die Kultur dieses Teams könnte man ungefähr so wie in dem Quadranten unten rechts in der Abbildung (/2/) beschreiben:

Es gab eine große Autonomie im Unternehmen und im Team. Jeder genoss es, die Dinge zu tun, die ihn am meisten interessierten und in denen er den meisten Sinn sah. Es gab niemanden, der für die Priorisierung der Aufgaben oder für eine gemeinsame Vision verantwortlich war.

Das Team tat sich auch überhaupt sehr schwer mit der Formulierung einer gemeinsamen Vision. Die Teammitglieder teilten zwar die gemeinsamen Werte, fühlten sich auch sonst miteinander verbunden, aber sie hatten Schwierigkeiten eine gemeinsame nächste Richtung zu finden.

Das Team hat keine Ursachenanalyse gemacht, warum es ihnen so schwer fiel. Aber es entdeckte eine Sache, bei der es in jedem Fall Hilfe benötigte: Besser zuhören.

Jeder wusste, dass kein Problem mit der Sichtweise gelöst werden könnte, die das Problem ursprünglich verursacht hat. Der Teilzeit Scrum Master, der eigentlich Coach des Teams sein sollte, war auch keine Hilfe, da er als Teil des Teams mitarbeitete und keine neutrale Perspektive hatte. Also holte sich das Team Hilfe von außen und engagierte einen Coach.

Zuerst hat der Coach in der Session gemeinsame Regeln mit dem Team für die Session vereinbart. Wie wollte das Team miteinander interagieren? Z.B. "Jeder bringt sich ein," oder "Zuhören und Fragen stellen, statt seine Meinung durchkämpfen."

Diese Regeln brachten in der Session und eine kurze Zeit danach einen Durchbruch, aber das Team konnte die Regeln nicht dauerhaft einhalten. Irgendwie verschwand das gemeinsame Verstehen wieder. Da auch nicht jeder an den wöchentlichen Retrospektiven teilnehmen konnte, hat das Team die Regeln schnell wieder vergessen.

Was war die eigentliche Ursache für den Konflikt des Teams?

1. Wenn wir auf das System schauen, fehlt ein wesentliches Element, die Rolle Product Owner. Kein Wunder, dass das Team in ewigen Diskussionen gefangen war.
2. Ein weiterer Punkt in der Struktur sind die nicht ausreichenden Retrospektiven. Wenn nicht alle regelmäßig mitmachen, verliert die Retrospektive ihre Wirkung und das Team kann sich nicht entwickeln.
3. Oder fehlt etwas, was in einem agilen Kontext häufig sehr unsexy ist: Disziplin?

Der Coach, der im Team die Fähigkeit zuzuhören deutlich verbessert hat, hat eine "Konversations Disziplin" etabliert. Die bestehende Kultur, seine Meinung durchzukämpfen, wurde durch echtes Zuhören und Nachfragen abgelöst. Leider konnte das Team diese Disziplin nicht halten.

Was nützt denn Disziplin, wenn ein System gebrochen ist?

Wir erinnern uns, es gibt kein Product Ownership, keine Vision, keine Priorisierung. Reparier' das, und der Konflikt verschwindet.

Agil arbeitet man häufig in einem komplexen Umfeld, in dem kreatives Arbeiten notwendig ist. Disziplin wird da häufig eher als muffiger Geruch aus der alten Arbeitswelt wahrgenommen. Etwas, was einengt und kreative Arbeit verhindert.

Genauso wie Führung (Alignment) und Autonomie (Autonomy) sich nicht gegenseitig ausschließen, sind Kreativität und Disziplin auch keine Gegensätze. Im Gegenteil: Ohne Disziplin kann kreative Arbeit überhaupt nicht stattfinden.

Die Mischung ist entscheidend: Wenn wir in der Matrix von oben Alignment und Autonomy durch Kreativität und Disziplin ersetzen, bekommen wir dieses Bild:

• Eine Organisation ohne Disziplin und Kreativität ist eher schlampig, ohne Regeln, ohne Fortschritt,
• Eine Organisation mit viel Disziplin ohne Kreativität empfinden wir eher als eng und starr,
• Eine kreative Organisation ohne jegliche Disziplin ist diffus und chaotisch,
• Eine kreative Organisation mit dem richtigen Maß an Disziplin fokussiert sich auf die richtigen Dinge.

Gerade in einem agilen Kontext, in dem sich Teams selbst organisieren sollen, ist Disziplin essentiell. Disziplin spielt in der Geschichte von Agilität sogar eine besonders wichtige Rolle.

"Ohne Standard gibt es keine Verbesserung"

Agilität stammt ursprünglich aus dem "Lean Product Development". Die 17 Personen, die das Agile Manifest geschrieben haben, einigten sich auf den Namen "Agil", weil jemand ein Buch gelesen hatte, das "Agile Competitors" hieß. (/3/) Darin sind Unternehmen beschrieben, die "lean" Produkte entwickelt und bereits in die Entwicklung der Produkte den Kunden einbezogen haben.

Ein Prinzip in Lean ist die Etablierung eines Arbeitsstandards. Der Erfinder des Toyota Production Systems, der Basis von Lean, Taiichi Ohno sagte: "Ohne Standard gibt es keine Verbesserung." (/4/) Hinter Agilität steckt das Prinzip "Inspect & Adapt", Überprüfen & Anpassen. Kontinuierlich überprüfen wir, ob unser Produkt die Bedürfnisse unsere Kunden erfüllt und wir überprüfen den Arbeitsprozess, der für die Ergebnisse verantwortlich ist. Wenn es eine Abweichung von den gewünschten Ergebnissen gibt, verändern wir den Prozess. Erfüllt das Produkt nicht die Bedürfnisse des Kunden, passen wir es an. Beständig versuchen wir das gesamte Arbeitssystem besser zu machen. Den nächsten kleinen Schritt zu mehr Agilität zu finden.

Es hilft also sehr, einen gemeinsamen Standard, z.B. "Zuhören und Fragen stellen, statt seine Meinung durchkämpfen" zu definieren und dafür zu sorgen, dass der Standard gelebt wird. Beständig überprüfen wir, ob der Standard zu den richtigen Ergebnissen führt. Ohne Standards wird das Team immer erfolglos nach einer gemeinsamen Basis suchen.

Standards anzuwenden ist eine Form von Disziplin. Eine andere, nicht müffelnde Perspektive auf Disziplin habe ich von einem Yoga Meister gelernt: Do your daily practice and the rest will follow. Mach Deine täglichen Übungen und der Rest kommt von selbst. 

Anmerkungen:

• /1/ Schein, Edgar: Organizational Culture and Leadership, 2nd Edition, 1992
• /2/ Von Henrik Kniberg: http://blog.crisp.se/wp-content/uploads/2014/03/unproject.pdf
• /3/ Nagel, Steven: Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer, Wily, 1994
• /4/ Ohno, Taiichi: Taiichi Ohno's Workplace Management, Special 100th Birthday Edition; 2012, McGraw-Hill Edition