Direkt zum Hauptbereich

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

Kommentare

Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.