Agilität? Haben wir probiert! Funktioniert nicht! – Teil 4

“Agilität um der Agilität willen” ist meiner Erfahrung nach selten eine gute Idee. Generell ist es kein gutes Zeichen, wenn ein Modell oder eine Methode zum Selbstzweck wird, wenn es also nicht mehr hinterfragt wird, wenn niemand mehr weiß, warum bzw. wofür man etwas tut bzw. genauso zu tun hat. Das durfte ich mit klassischem Projektmanagement erleben: Projektleiter, die nach grandios gescheiterten Projekten mit den Schultern zucken und entgegnen, sie hätten doch alles richtig gemacht, alle Regeln und Prozesse befolgt, genauso wie es im PM-Handbuch steht. Spätestens dann sollte auffallen, dass etwas schief läuft.

Im ersten Artikel meiner kleinen Serie über Agilität in Unternehmen ging es vor allem um die Frage, ob Agilität überhaupt der passende Ansatz für Organisationen ist und falls ja, welcher konkrete Ansatz auf welche Situation passen könnte. Im zweiten Teil ging es vor allem um typische Probleme bei der Einführung und Umsetzung von Agilität. In dieser dritten Folge lag der Fokus vor allem auf den Menschen selbst. In dieser nunmehr bereits vierten Folge, möchte ich einige gefährliche Missverständnisse anreißen.

Umso mehr gilt: Auch dieses Mal werde ich weder universelle Lösungen noch Kochrezepte für erfolgreiche Agilität liefern können. Die eine oder andere aufmerksame Leserin wird vielleicht erkennen, dass sich meine Argumente teilweise sogar widersprechen. Willkommen in der Realität: Mehrdeutigkeit bzw. Ambiguität ist – je nach Experte – eine Ausprägung oder ein Begleiter von Komplexität, auf jeden Fall: unvermeidbar. Und dennoch bin ich überzeugt, dass der geneigte Leser mit dem einen oder anderen meiner Impulse etwas anfangen können wird.

Und bevor es losgeht noch einmal der Hinweis: Auch dieser Beitrag kann wieder Spuren von Ironie beinhalten!

Sie verwechseln Agilität mit Anarchie, Teil 1: Ohne Planung und Messung ist alles ein Glücksspiel!

Wahrscheinlich ein Klassiker unter den Missverständnissen über Agilität: Vor ein paar Jahren traf ich noch häufig auf Aussagen wie “Agilität, das ist doch das mit den bunten Zetteln, wo jeder machen kann, was er will, ohne Planung und ohne Dokumentation, oder?” Heute höre ich solche Aussagen zwar immer seltener, doch – umso schlimmer – ich sehe Teams, die sich unbewusst oder aus Gründen der Bequemlichkeit tatsächlich so ähnlich verhalten.

Ich sehe beispielsweise Scrum Teams, die zwar den nächsten Sprint planen, zum Ende des Sprints die Ergebnisse aber kaum jemals konsequent messen und etwaige Abweichungen nicht ernsthaft analysieren.

Einige dieser Teams würden jetzt vermutlich protestieren: “Natürlich schauen wir, ob wir alle geplanten User Storys geschafft haben. Und es ist doch ganz normal, dass nicht alles wie geplant läuft, schließlich haben wir es hier ja mit Komplexität und Unsicherheit zu tun (siehe dazu Teil 1). Und in der Retrospektive definieren wir dann Maßnahmen, um besser zu werden.”

Doch – Hand auf’s Herz – viele Teams bleiben in der Analyse der Abweichungen eher oberflächlich und vertrauen darauf, dass Ihnen gemeinsam schon die richtigen Dinge auffallen werden, die es zu verbessern lohnt. Ich sehe leider nur selten Teams, die regelmäßig ihre Story Point-Schätzungen kontrollieren, Abweichungen ernsthaft analysieren und auf Basis der Erkenntnisse ihre Referenzstorys neu justieren (so sie denn welche haben und nutzen), um so künftig besser schätzen zu können.

(Hinweis: Ich möchte an dieser Stelle nicht tiefer in den Sinn und Unsinn des Schätzens einsteigen. Ich kann die Argumente der #Noestimates-Bewegung gut nachvollziehen. Ich sehe aber auch positive (Neben-) Wirkungen des Schätzens, gerade für das Team. Vielleicht gehe ich im nächsten Artikel noch näher darauf ein.)

Was ich mit “ernsthaft” analysieren meine: Sich gemeinsam die Zeit nehmen, bei identifizierten Problemen und Abweichungen zunächst die Ursachen herauszufinden, statt direkt in die Lösungsfindung zu springen. Es klingt profan, aber eine gängige und wirklich wirkungsvolle Methode heißt nicht umsonst “5 Whys” statt “Why”, denn die eigentliche Ursache findet man selten direkt in der Antwort nach dem Grund eines Problems.

Ohne “ernsthafte” Ursachenanalyse ist die Wahl von Verbesserungsmaßnahmen nichts anderes als ein Glücksspiel mit begrenzter Gewinnwahrscheinlichkeit: In vielen Fällen kaschieren die spontan gefundenen Maßnahmen nur die aktuellen Symptome, die eigentlichen Ursachen bleiben unangetastet und werden über kurz oder lang neue Symptome verursachen und so langfristig die Produktivität des Teams limitieren.

Das Schätzen, Planen und Messen von Sprint-Ergebnissen ist dabei nur ein Beispiel. Gleiches gilt allzu oft auch für die Verbesserungsmaßnahmen selbst, die bspw. in einer Sprint Retrospektive beschlossen wurden: Meiner Beobachtung nach ist es nicht allzu weit verbreitet, schon direkt bei der Definition der Maßnahme festzulegen, wie man später feststellen – also: messen – kann, ob die Maßnahme 1) umgesetzt wurde und 2) dann auch den erhofften Effekt hatte oder nicht. Wie oft werden Maßnahmen beschlossen, um ein Problem zu lösen, die alle im Team ganz toll finden, man ist gut gelaunt und setzt gedanklich einen Haken hinter das Problem – um sich dann später zu wundern, dass das Problem wieder auftaucht …

Doch 1. bedeutet Planung und Messung Arbeit und verlangt Disziplin. Und 2. ist es wichtig, dass man Abweichungen vom Plan (in komplexen/dynamischen Situationen) als Normalfall und als Lernchancen begreift. Es geht unter Unsicherheit gerade nicht darum, einen Plan möglichst perfekt einzuhalten, es geht darum, möglichst schnell zu lernen und zu adaptieren – entweder also das Vorgehen anpassen oder den Plan, meistens sogar beides! Und zwar umso schneller, je unsicherer und dynamischer das Umfeld bzw. der Markt, in dem man sich bewegt. Die Geschwindigkeit des Lernens ist dann entscheidend für den Erfolg!

Zur Erinnerung, im Scrum Guide heißt es ziemlich zu Beginn:

“Scrum basiert auf der Theorie empirischer Prozesssteuerung oder kurz „Empirie“. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden. Scrum verfolgt einen iterativen, inkrementellen Ansatz, um Prognosesicherheit zu optimieren und Risiken zu kontrollieren. Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz, Überprüfung [Inspection] und Anpassung [Adaptation].”

Und auf Wikipedia wird Empirie folgendermaßen definiert:

“Empirie (von ἐμπειρία empeiría ‚Erfahrung, Erfahrungswissen‘) ist eine methodisch-systematische Sammlung von Daten. Auch die Erkenntnisse aus empirischen Daten werden manchmal kurz Empirie genannt.”

Sie beschäftigen sich zu sehr mit sich selbst: Ohne direktes Kundenfeedback ist kein Lernen, keine Agilität möglich

Einer meiner Kunden berichtete mir vor ein paar Monaten, dass er (Geschäftsführer eines B2C-Unternehmens) seine Product Owner zum Innovationsworkshop eingeladen hatte. Alle waren sehr engagiert und kreativ und viele spannende Ideen entstanden in den ersten Stunden. Dann lud er seine Product Owner ein, gemeinsam raus auf die Straße zu gehen, um die neuen Ideen direkt an potenziellen Kunden zu testen. Dies war der Auslöser, um noch viel kreativer zu werden! Allerdings wurde die kreative Energie dazu verwendet, um Gründe zu (er-) finden, warum es keinen Sinn machen würde, jetzt raus auf die Straße zu gehen. Tatsächlich hat an diesem Tag niemand die Chance genutzt, so früh direktes Feedback von Kunden einzuholen.

Zugegeben: Feedback i. S. v. Kritik kann in der Tat sehr schmerzhaft sein. Es kann wirklich weh tun, zu erfahren, dass der Kunde das neue Feature gar nicht so toll findet wie man selbst.

Doch 1. ist der befürchtete Schmerz in der eigenen Phantasie meist wesentlich schlimmer als das, was dann wirklich passiert. In der Realität ist es sogar gar nicht so einfach, ehrliches und ungeschöntes Feedback zu erhalten – nachzulesen bspw. im kleinen aber mehr als empfehlenswerten Buch “Der Mom Test”.

Und 2. wird der Schmerz umso heftiger, je ausgereifter die eigene Idee schon ist. Je frischer die Idee und je weniger Zeit, Aufwand und Herzblut hineingeflossen ist, desto schneller vergeht der Schmerz auch wieder. Umgekehrt: Wenn ich eine Idee über Wochen und Monate im stillen Kämmerlein hege und pflege, dann kann mir heftige Kritik durchaus den Boden unter den Füßen wegreißen. Ich finde, das Motto von Ash Maurya trifft den Nagel auf den Kopf: “Love the Problem, Not Your Solution!” Man verliebt sich sehr schnell in die eigene Idee und verschließt dann gerne die Augen vor der Realität, verschließt die Ohren vor Kritik. Bis man irgendwann anfängt, ein passendes Problem für die eigene Lösung zu suchen – ein allzu oft unmögliches Unterfangen.

Die gute Nachricht: Diesen Teufelskreis kann man bewusst durchbrechen, man kann einfach in das kalte Wasser springen und sich der Kritik aussetzen. Je öfter man das tut, desto geringer die Schmerzen. Man gewöhnt sich daran. Und sogar das Gegenteil passiert: Sehr oft sehe ich leuchtende Augen, nachdem Menschen zum ersten direkt mit Anwendern gesprochen haben!

Auch hier gilt: Je höher die Frequenz des Kundenfeedbacks, desto geringer das jeweilige Schmerzpotenzial. Kürzere Iterationen sind somit Risikoreduzierung.

Ein anderes Beispiel: Ich kenne Banken, die ihre Systeme maximal quartalsweise aktualisieren, um mit einem hochkomplizierten Prozess möglichst alle Risiken und Nebenwirkungen der Änderungen durch diverse Integrationstests ausschließen zu können. Vor einem solchen Release sind viele der Beteiligten dann jedes Mal ziemlich aufgeregt – denn wenn doch etwas schief gehen sollte, dann ist im schlimmsten Fall die Arbeit eines Vierteljahres in mehreren Teams betroffen.

Barclaycard dagegen, mit Transaktionen in Höhe von 600 Milliarden Pfund jeden Tag ein Unternehmen, das Ausfälle und gravierende Fehler unbedingt vermeiden möchte, aktualisiert die eigenen Systeme inzwischen mehrmals pro Tag. (Quelle: Jonathan Smart.)

Das klingt hoch riskant, ist aber genau das Gegenteil: Je kleiner die Änderungen, desto geringer das Schadenspotenzial, desto schneller und einfacher kann man eine missglückte Änderung auch wieder rückgängig machen, ohne alle anderen Änderungen (und damit eventuell sogar gesetzlich vorgeschriebene Änderungen) ebenfalls rückgängig machen zu müssen, wie es bei einem großen Quartalsrelease der Fall wäre.

Einige denken nun vielleicht, dass das zwar toll klingt, man dafür aber noch ganz andere Voraussetzungen benötigt – zum Beispiel eine modulare Softwarearchitektur, Testautomatisierung etc. pp. Das stimmt bestimmt.

Was aber immer geht: Gehen Sie raus aus Ihrem Elfenbeinturm und sprechen Sie direkt mit Ihren Kunden und Nutzern. Oder laden Sie sie zu sich ein, z. B. zum Sprint Review. Dieses Scrum Ereignis hat den Zweck, “das Produktinkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen.” [Scrum Guide] Um diesen Zweck zu erfüllen sind u. a. mit dabei: “wichtige Stakeholder”, die vom Product Owner eingeladen werden. Und wer ist wichtiger als Kunden und Anwender? Jedenfalls wenn man das Produkt wirklich kundenorientiert entwickeln möchte.

Leider sehe ich nur sehr selten echte Endanwender im Sprint Review. Manchmal sehe ich immerhin Auftraggeber und andere Stakeholder – vor allem interne, seltener externe Auftraggeber und Stakeholder. Zu oft ist das Sprint Review dagegen eine rein interne Veranstaltung des Scrum Teams. Wie genau sollen so neue Erkenntnisse zur Produktentwicklung entstehen?

Ich möchte an dieser Stelle noch einmal die Kernaussage des ersten Abschnitts wiederholen: Ohne Planung und Überprüfung ist es schwer, neue Erkenntnisse zu gewinnen. Solange ich im eigenen Elfenbeinturm verbleibe, solange bekomme ich auch keine neuen Erkenntnisse, ob unser Plan, die Anwender und Kunden mit dem neuen Produkt glücklich zu machen und damit einen Verkaufsschlager zu landen, so auch aufgehen wird. Solange bleibt Produktentwicklung reines Glücksspiel. Manche können sich das auch leisten, viele nicht.

Sie können einfach nicht loslassen, Teil 2: Sie verwenden einfach neue Kennzahlen, um weiterhin Menschen zu steuern

Im ersten Abschnitt ging es um Empirie, um Planung/Zielsetzung und (Kontroll-) Messung. Das klingt zunächst vertraut: Kennzahlen, KPIs und andere Metriken gab es ja auch schon, bevor alle von “Agilität” gesprochen haben. Richtig. Also müssen wir da gar nicht so viel ändern. Falsch. Na gut, dann ersetzen wir halt traditionelle Kennzahlen wie “Personentage” durch agile Metriken wie “Story Points”. Bitte nicht!

Agilität basiert – neben der Empirie, die in den beiden vorherigen Abschnitten betont – u. a. auf Selbst-Organisation und Ermächtigung. Und dahinter liegt ein ganz bestimmtes Menschenbild (siehe Teil 3): Ich gehe erst einmal davon aus, dass sich alle Beteiligten engagieren und ihr Bestes für das gemeinsame Ziel geben. Als Führungskraft habe ich vor allem die Aufgabe, die Voraussetzungen dafür zu schaffen, dass die Teams erfolgreich arbeiten können.

Kennzahlen gehören dann dorthin, wo sie benötigt werden und interpretiert werden können. Also dorthin, wo man den Kontext kennt, um Entscheidungen treffen zu können. Ein gutes Beispiel dafür ist die “Velocity”, also die Geschwindigkeit oder der Durchsatz eines Scrum Teams. Ein gutes Scrum Team möchte selbst immer produktiver werden, also mehr Outcome pro Sprint erreichen. Dafür behält es die eigene Velocity im Blick, analysiert etwaige Abweichungen nach unten und ergreift Maßnahmen, um schneller und besser zu werden. Manchmal liegen die Ursachen für Negativtendenzen außerhalb des Spielraumes des Teams, dann braucht es dazu die Unterstützung und wendet sich z. B. an die zuständige Führungskraft mit der Bitte um Unterstützung.

Wenn ich dagegen meine Rolle als Führungskraft weiterhin unter dem Motto “Vertrauen ist gut, Kontrolle ist besser” verstehe und lebe, dann lasse ich mir natürlich nach jedem Sprint die aktuelle Kennzahl “Velocity” berichten. Bei Abweichungen nach unten gebe ich schnell Feedback, dass das in die falsche Richtung geht und fordere eine Erklärung. Wobei mich die Ausreden ja eigentlich gar nicht interessieren. Denn schließlich ist das Team ja agil und somit selbst voll verantwortlich! Also erhöhe ich langsam den Druck, damit sie nicht denken, ich ließe es ihnen einfach durchgehen, dass sie immer fauler oder nachlässiger werden, und mache klar, dass ich bis Ende des Quartals wieder eine steigende Velocity erwarte. Was dann passieren kann, zeigt die folgende kleine Abbildung aus meiner Sicht sehr schön:

Das eigentliche Problem dabei ist nicht, dass das Scrum Team das Kennzahl-Berichtswesen “hackt” und somit die Führungskraft täuscht, sondern die damit einhergehenden Risiken und Nebenwirkungen:

Die wichtige Kennzahl “Velocity” ist damit für die Selbst-Steuerung des Teams unbrauchbar geworden. Entweder muss es nun eine zweite, echte Velocity nur für den internen Gebrauch erheben – was zum einen zusätzlichen Aufwand erzeugt und zudem streng geheim bleiben muss – oder das Team lässt es einfach bleiben: Warum sollte man sich die Mühe machen, selbst immer besser zu werden, wenn einem doch nur misstraut wird?

Steuerung über Kennzahlen ist somit eine sehr effektive Methode, um intrinsische Motivation zu zerstören und Agilität zu verhindern!

Wenn Feedback eine Schlüsselrolle für den Erfolg von Agile hat, liegt der Schlüssel zur effektiven Agile-Messung darin, Messung im Sinne von Feedback zu begreifen – nicht aber als traditionelles Mittel im Sinne eines Hebels, um bestimmte Verhaltensweisen zu motivieren. Das Feedback hilft, die eigenen Leistungen zu verbessern. Hebel werden eingesetzt, um andere zu beeinflussen. Der Unterschied liegt demnach mehr in der Art und Weise, wie man die Messung einsetzt, als in der Messung selbst. [heise.de]

Doch wie ich in den ersten beiden Abschnitten schon ausdrücken wollte: Empirie, also zu planen und zu messen und daraus zu lernen, ist eine wesentliche Komponente von Agilität. Es wäre somit der falsche Weg, Kennzahlen per se zu verteufeln, nur weil man Kennzahlen intuitiv vielleicht mit “Command & Control”-Management verbindet. Alle Werkzeuge, Modelle und Prinzipien und somit auch Kennzahlen sind erst einmal neutral, es kommt immer darauf an, wie Menschen sie konkret einsetzen.

Und man kann Kennzahlen durchaus mit einer agilen Haltung nutzen:

Um Kennzahlen richtig interpretieren und somit als Grundlage für gute Entscheidungen verwenden zu können, muss man den jeweiligen Kontext kennen. Entscheidungen und Kennzahlen sollten so dezentral wie möglich bleiben. (Die Kunst besteht dann darin, trotzdem teamübergreifende Muster zu erkennen, ohne selbst in “alte” Verhaltensweisen zurück zu fallen.) Manche gute Kennzahlen sind daher vor allem Katalysatoren für klärende Gespräche.

Kennzahlen sind zudem immer nur Mittel zum Zweck, nie Selbstzweck. Und da sich die Welt verändert und wir gemeinsam stetig lernen, gehört es zur kritischen agilen Haltung, auch Kennzahlen immer wieder in Frage zu stellen, ob sie noch nützlich sind oder nicht mehr oder inzwischen sogar kontraproduktiv.

Sie verwechseln Agilität mit Anarchie, Teil 2: Ohne Ausdauer und Disziplin geht Ihnen schnell die Luft aus

In den ersten Absätzen klang es schon kurz an: Agilität lebt von der Disziplin der Beteiligten! Meiner Erfahrung nach braucht es sogar mehr Disziplin als im klassischen, auf den ersten Blick streng geregelten Projektvorgehen. Zumindest in den klassischen Projekten, also solchen mit Wasserfall-ähnlichen Phasen und Meilensteinen, in denen ich involviert war, gab es zwischenzeitlich große Freiheiten, in denen man ohne großen Druck arbeiten konnte, auch an Themen, die vielleicht nicht unbedingt notwendig gewesen wären, ohne ständig beobachtet zu werden. Erst zum Projektende oder kurz vor einem wichtigen Meilenstein oder Lenkungskreis wurde es hektisch.

Sie kennen dieses Phänomen vielleicht als “Studentensyndrom” – Eliyahu M. Goldratt prägte diesen Begriff und schlägt im von ihm entworfenen Critical Chain Projektmanagement vor, die impliziten Puffer, die ein Aufschieben und nicht notwendige Arbeiten überhaupt erst ermöglichen, aus dem Projektplan zu streichen und explizit an das Ende zu legen.

In Scrum geht man einen ähnlichen Weg, indem nicht auf ein fernes Ziel hingearbeitet, sondern ständig (alle 1-4 Wochen) etwas geliefert und kontrolliert wird, ob es wie gewünscht bzw. geplant wirkt. Nicht umsonst steht im Scrum Guide, dass jeder Sprint als (kurzes) Projekt zu verstehen ist. Dadurch wird eine Kontinuität des Arbeitens erzeugt. Hinzu kommen die maximale Transparenz und die enge Zusammenarbeit im Team. Das Resultat: Es bleibt schlicht keine Zeit für ungeplante Zusatzaufgaben, Extrawürste, goldene Wasserhähne oder bloßes Herumtrödeln. Und falls es doch jemand versucht, dann fällt das im Team zumeist schnell auf und wird (hoffentlich und spätestens) in der nächsten gemeinsamen Retrospektive angegangen.

Meiner Erfahrung nach wirkt der informelle soziale Druck in selbstorganisierten Teams viel stärker auf die Disziplin als es ein formaler Projektmanager jemals könnte. (Und das kann man auch durchaus kritisch sehen, was ich aber hier und heute nicht weiter diskutieren möchte.)

Übrigens ist Herumtrödeln und freies Experimentieren nicht per se schlecht, es ist sogar eine gute Voraussetzung für Innovation. Es kommt halt immer darauf an, eine gute Balance zu finden und vor allem, Transparenz zu schaffen, um Vertrauen zu ermöglichen. Hackathons, Barcamps, Marktplätze der Macher, Design Sprints oder Slack Time sind Möglichkeiten, explizit Zeit für freie Innovation und Austausch einzuräumen.

Doch zurück zur scheinbar agilen Realität: Wenn jeder tut, was er gerade tun möchte, wenn ein Großteil des Team unpünktlich zu den Meetings erscheint, wenn die Scrum Events ständig verschoben und die Themen miteinander vermischt werden, wenn Sprints verlängert werden, weil man noch nicht ganz fertig geworden ist, wenn Vereinbarungen im Team nicht eingehalten werden, dann hat das mit Agilität nicht mehr viel zu tun. Wenn man damit dennoch irgendwie erfolgreich ist: wunderbar! Wenn auf diese Art und Weise jedoch der Erfolg ausbleibt, dann sollte man bitte nicht der vermeintlichen Agilität dafür die Schuld geben.

Aber im Agilen Manifest heißt es doch, es sei wichtiger auf Veränderungen zu reagieren als einen Plan zu befolgen, oder? Das ist korrekt! Wenn es jedoch bedeutet, dass man alle 5 Minuten alles über Bord wirft und neu plant, dann ist es schlicht sehr unwahrscheinlich, dass überhaupt jemals ein Ergebnis zustande kommt, um die Kunden zufrieden zu stellen.

Agilität bedeutet nicht, das eigene Denken einzustellen! Im Gegenteil!

Scrum nutzt den Sprint als Stabilitätsfaktor: Der Sprint ist geschützt, nur in Ausnahmefällen wird ein Sprint abgebrochen, wenn er komplett obsolet geworden ist. Die Sprintlänge ist dann immer ein Kompromiss zwischen “schnell auf Veränderungen reagieren müssen” und “in Ruhe arbeiten können”. Wenn es gar nicht möglich erscheint, sich zumindest 1 Woche Planungssicherheit zu gönnen, dann ist Scrum wahrscheinlich nicht mehr das passende Framework, dann sollte man eventuell besser auf einem Kanban-Modell aufbauen.

Vielleicht kann man Agilität auch so beschreiben: Es geht darum, schnellstmöglich auf Veränderungen im Nutzerverhalten und auf sich verändernde Kundenwünsche zu reagieren. Und um diese maximale Flexibilität in der Arbeit am Produkt zu ermöglichen, braucht es eine möglichst hohe Stabilität, Verlässlichkeit und Disziplin in der Zusammenarbeit im Team. Indem man sich während der Umsetzung keine Gedanken mehr über Rollen, Meetings und andere Vereinbarungen zur Zusammenarbeit machen muss, kann man sich voll und ganz auf das Produkt und die Kundenbedürfnisse fokussieren.

Und auch hier gilt: Nicht übertreiben! Es gibt nicht nur schwarz und weiß! Denn wenn man die Zusammenarbeit im Team zu selten reflektiert und den sich verändernden Rahmenbedingungen anpasst, fällt das Team irgendwann in sich zusammen oder auseinander.

Im Kern läuft es wie immer darauf hinaus, eine gesunde Balance zu finden. In beiden Dimensionen (Arbeit am Produkt und Zusammenarbeit im Team) braucht es Kompromisse, um produktiv zu bleiben. Zu schnelle Veränderungen in der Produktentwicklung gehen auf Kosten der Produktivität, zu langsame Anpassungen der Zusammenarbeit im Team ebenso.

Sie können einfach nicht loslassen, Teil 3: Nein! Tools machen nicht agil! Sorry, wirklich nicht!

Wunderbar, Sie haben alle Optionen abgewogen, erste agile Piloten gestartet und sind zu dem Entschluss gekommen: Agilität ist unser Weg!

Und wie oft beobachte ich dann den typischen Reflex, den man jahrzehntelang trainiert hat: Welches Tool führen wir dazu ein?

Denn wie kann eine Veränderung an Strukturen, Prozessen, Rollen, Abläufen, Kommunikationsmustern etc. ohne eine adäquate Tool-Unterstützung überhaupt erfolgreich funktionieren? Jede Veränderung bringt neue Tools. Und umgekehrt.

Ich kann das sehr gut mitempfinden. Schließlich habe ich früher einmal mächtige IT-Systeme für Projektmanagement und Multi-Projektmanagement eingeführt. Ich war überzeugt, dass diese Tools mindestens wichtig und nützlich, teilweise sogar absolut notwendige Voraussetzungen für erfolgreiche Projektarbeit sind.

Bis ich im Jahre 2011 beim ersten PM Camp in Dornbirn in der Session “Des Agilen Pudels Kern” von Eberhard Huber erfuhr, dass nach Auswertung von über 300 IT-Projekten der Einsatz von “schweren PM Werkzeugen” statistisch betrachtet minimal negative und von “Kommunikationswerkzeugen” minimal positive Auswirkungen auf den Projekterfolg haben. Die Nutzung von mächtigen PM-Systemen, wie ich sie damals bei Kunden einführte, richtet also nur geringen Schaden an! Das beruhigte mich nur bedingt.

Im Agilen Manifest heißt es nicht umsonst: Individuen und Interaktion vor Prozesse und Werkzeuge. Denn es sind die Menschen gemeinsam in der Zusammenarbeit, die erfolgreiche Produkte entwickeln. Prozesse und Werkzeuge können und sollen den Menschen dabei helfen, sind aber nie Selbstzweck.

Nun aber zurück zur Ausgangssituation: Wir wollen möglichst schnell möglichst erfolgreich agil arbeiten. Brauchen wir dazu wirklich kein spezielles Tool?

Das Tool direkt am Anfang in den Fokus zu stellen, ist in mancherlei Hinsicht riskant: Sie suggerieren, dass das neue Tool notwendige Voraussetzung für Agilität ist. Manch einer wird also erst einmal abwarten, bis das Tool soweit ist. Und die anstehende Veränderung ist wahrscheinlich gar nicht so besonders und tiefgreifend – als das neue CRM-System eingeführt wurde, hat sich ja sonst auch kaum etwas geändert…

Warum also nicht erst einmal mit dem starten, was vorhanden ist? Eine freie Fläche und ein großer Vorrat an Sticky Notes und guten Stiften reichen in der Regel, damit ein Team loslegen kann. Oder man nutzt die IT-Systeme, die schon da sind. Wenn dann irgendwann der Prozess eine gewisse Stabilität erreicht hat und der Ruf nach einer besseren Tool-Unterstützung aufkommt: Wunderbar!

Eine weitere Falle, in die man dann allzu gerne tappt: Das Tool, das sich bei einem Team als wertvoll erwiesen hat, als einheitlichen Standard für alle zu definieren. Klar, das ist effizient. Und ich verstehe den Reflex, einen Wildwuchs unterschiedlicher Tools (auch aus Sicherheitsgründen) zu vermeiden. Und wenn man sich schon einmal eine Standard-Lösung im Hause geeinigt hat, dann macht es doch auch durchaus Sinn, die Handhabung zu vereinheitlichen. Denn bei identischen Prozessen und Regeln ist es u. a. leichter, von einem zu einem anderen Team zu wechseln. Und bei einheitlicher Handhabung ist es auch viel einfacher, die Zahlen der einzelnen Teams zu verstehen und miteinander zu vergleichen.

Moment: Zahlen unterschiedlicher Teams miteinander vergleichen? Da klingeln meine Alarmglocken! Bei Ihnen nicht? Vielleicht lesen Sie besser noch einmal den Abschnitt über Kennzahlen weiter oben?

Jedenfalls ist die Gefahr groß, dass das neue “agile” Tool auf diese Art und Weise schnell zum Zwang und zum Selbstzweck degeneriert und eben nicht mehr nützlich ist, zumindest nicht für alle.

Rückblick: Damals, als ich noch PM-Systeme einführte, habe ich viele mächtige PM-Tools in Unternehmen gesehen, die zum reinen Zeiterfassungssystem degeneriert waren. Ursprünglich wollte man damit die Projektarbeit unterstützen. Und wenn es schon mal da ist, kann man ja auch gleich die Zeiten mit erfassen. Damit die erfassten Zeiten direkt weiterverarbeitet werden können, z. B. zur internen Leistungsverrechnung oder zur Rechnungsstellung an Kunden, müssen gewisse Strukturen eingehalten werden. Und somit war das Tool zur Planung und Steuerung der meisten Projekte nicht mehr anwendbar. Also hat sich jedes Projekt wieder eine eigene Lösung gesucht. Ob sich die Investition in das mächtige PM-System somit letztendlich gelohnt hat, wage ich zu bezweifeln – es hätte wahrscheinlich günstigere (und bessere) Lösungen zur Zeiterfassung gegeben.

Heute ist das nicht so? Ich habe in letzter Zeit öfter aus “agilen” Unternehmen gehört, dass über die ständig wachsende Bürokratie bei Verwendung des “agilen” Tools gestöhnt wird.

Ein Tool macht eine Organisation nicht agil. Im besten Fall kann es agile Praktiken (“doing agile”) unterstützen. Voraussetzung dafür ist, dass die eigentlichen Anwender einen Nutzen daraus ziehen und es an ihre sich verändernden Bedürfnissen anpassen können. Im schlimmsten Fall führt das Tool dazu, dass man über einige im Tool verankerte agile Praktiken nicht hinaus kommt, dass man agiles Theater spielt, dass man gar keine Chance hat, eine agile Haltung (“being agile”) zu entwickeln!

Übrigens habe ich letztens so etwas wie den umgekehrten Effekt beobachten können: Wenn man gebetsmühlenartig predigt, die beste Art der Kommunikation sei von Angesicht zu Angesicht im selben Raum, dann darf man sich nicht allzu sehr wundern, wenn Teams auf die Idee kommen, eine Retrospektive per Videokonferenz ergebe keinen Sinn.

Sie wünschen sich Diversität und fordern zugleich, dass nun alle offene, extrovertierte Teamplayer sein sollen: Agilität kann Vielfalt!

Die geneigte Leserin wird in den Abschnitten zuvor ein Muster erkannt haben: Übertreibungen und Extreme sind gefährlich! Agilität ist m. E. vor allem auch gesunder Menschenverstand, Reaktion auf Veränderungen und kluges Abwägen.

Umso mehr bin ich immer wieder perplex, wenn im Namen der Agilität über Menschen geurteilt wird: „Der kann das einfach nicht! Die ist einfach nicht Teamfähig!“ Oder so ähnlich.

Zunächst einmal möchte ich noch einmal auf das agile Menschenbild hinweisen, auf das ich im dritten Teil näher eingegangen bin. Auf dieser Basis fallen mir solche Pauschalurteile schwer. Vielleicht stimmt es im einen oder anderen Fall sogar: Doch ein solches Urteil über einen anderen Menschen zu sprechen, fällt mir persönlich schwer, manch anderen offensichtlich nicht so sehr.

In der Beschreibung von Agilität wird zumeist das Team hervorgehoben und (in Abgrenzung zu Management-Ansätzen auch) betont, dass es im Team keine Titel und keine formale Hierarchie gibt. Es ist aber falsch und gefährlich, daraus abzuleiten, dass alle im Team gleich sind oder sein sollten.

Tatsächlich ist das Gegenteil der Fall! Wie schon in Teil 2 meiner Artikelreihe kurz erwähnt: Je komplexer die Situation, desto komplexer sollte das Lösungssystem sein. (Frei nach W. Ross Ashby.) Das bedeutet, wenn wir als Ausgangssituation eine komplexe/dynamische Situation annehmen (siehe Teil 1), dass wir für eine möglichst hohe Komplexität zur Lösung sorgen sollten, mit anderen Worten eine möglichst hohe Vielfalt!

Und Vielfalt bedeutet eben nicht: Gleichmacherei! Sondern Unterschiede: unterschiedliche Lebensläufe und Ausbildungen, unterschiedliche Kulturen, unterschiedliche Perspektiven.

Dazu gehört es m. E. auch, dass es ok ist, wenn jemand im Team z. B. eher introvertiert ist und in den Retrospektiven nicht selbst aktiv wird, um eigene Punkte vorzutragen. Es ist dann die Aufgabe des Teams und insbesondere des Coaches oder Scrum Masters, Wege zu finden bzw. anzubieten, damit jede und jeder sich auf seine bzw. ihre eigene Art und Weise einbringen kann.

Es ist auch erst einmal ok, wenn jemand sich nur eingeschränkt für die Arbeit seiner Kolleginnen und Kollegen interessiert und lieber ganz allein an einem komplizierten Algorithmus arbeitet. Dadurch ist sie kein schlechterer Mensch.

Und ja: Vielleicht passt jemand tatsächlich nicht in das Team. Weil das für alle Beteiligten eine zu große Umstellung wäre. Das kann passieren. Aber vielleicht findet man gemeinsam eine für alle passende Konstellation? Vielleicht eine Art Satellit zum Team? Springer zwischen mehreren Teams? Oder auch eine Sonderposition für Aufgabenstellungen, die sogar besser allein als im Team zu bearbeiten sind?

Die agilen Werte und Prinzipien, die mir spontan dazu einfallen, lauten:

• Offenheit,
• Selbstorganisation und
• Respekt!

Und manchmal gehört auch Mut dazu, neue Lösungen zu finden, um die Individualität zu bewahren und zugleich für das Team nutzbar zu machen!

Ausblick

Auch dieses Mal ist der Artikel wieder viel ausführlicher geworden, als ich geplant hatte. Ich hoffe, ich konnte Ihnen auch in diesem vierten Teil meiner kleinen Serie ein paar Hinweise dazu geben, woran es liegen könnte, wenn Agilität bei Ihnen vielleicht nicht so funktioniert, wie Sie es sich erwünschten. Und eventuell haben Sie auch den einen oder anderen hilfreichen Impuls dazu gefunden, was Sie vielleicht anders machen könnten.

Und übrigens: Ich sehe Licht am Ende des Tunnels. Aber ein weiterer Artikel kommt auf jeden Fall noch. Seien Sie gespannt.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Hier finden Sie weitere Teile der Beitragsserie Agilität? Haben wir probiert! Funktioniert nicht!

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.