Agile Welt

Die letzten Wochen habe ich wieder verstärkt in Gesprächen ein Verhalten beobachtet, was ich als „Cargo Cult Scrum“ identifiziere. Dazu gibt es auch andere Artikel im Internet, offenbar ist meine Beobachtung gar nicht so selten.

Unter einem „Cargo Cult“ versteht man allgemein ein Verhalten, bei dem versucht wird, einen positiven Effekt durch die Simulation der „Symptome“ herbeizuführen. Ursprünglich stammt dieser Begriff aus der Beobachtung von Bewohnern einiger pazifischer Inseln, die während des zweiten Weltkriegs von den Zwischenlandungen amerikanischer Flugzeuge auf ihren Inseln profitiert hatten, und nach dem Krieg die ausbleibenden Flieger durch den Bau von Landebahnen und (hölzernen) Funk- bzw. Radarstationen wieder herbeiholen wollten.

Im Scrum-Umfeld beobachte ich nun wieder, wie durch die Verwendung von Scrum-Begriffen für ansonsten gegenüber früheren Methoden weitgehend unveränderten Aufgaben oder Werkzeugen ein agiles Entwickeln quasi herbeigezaubert werden soll.

Klassische Führungskräfte nennen sich jetzt „chief product owner“. Aus den Entwicklern werden einzelne herausgegriffen und als „product owner“ bezeichnet. Sie müssen sich aber gegenüber dem chief product owner und allen möglichen Gremien aus früheren Zeiten mit zum Teil recht kreativen neuen Titeln nicht nur verantworten, sondern sich Entscheidungen wie früher in einer hierarchischen Unternehmensstruktur genehmigen lassen.

Aufgabenlisten heißen jetzt „product backlog“. Frühere Projektleiter werden als „scrum master“ bezeichnet, nur sollen sie nach dem Willen der Führungskräfte wie früher dafür sorgen, dass die Teams tun, was angesagt wird. Ein solcher scrum master, der eventuelle Probleme in Teams nicht durch entsprechende Anweisungen beseitigt, wird abgesetzt.

Regelmäßige Team-Meetings sind nun Retrospektiven, nur sagt dann der product owner und der scrum master was geändert wird.

Allen diesen Benennungen ist gemeinsam, dass der Sinn, die genaue Funktionsweise und das Zusammenspiel dieser Rollen und Werkzeuge in Scrum nicht wirklich verstanden werden. Das Verhalten ist ganz ähnlich dem der Polynesier, die nicht wissen wozu eine Radarstation dient und deren rein äußerliche Nachbildung genauso wenig funktioniert wie im Unternehmen die Verwendung der Begriffe. Scrum ist sehr leichtgewichtig, aber alle Teile müssen zusammenwirken, damit das große Ganze funktioniert.

Nach einer Weile stellt man dann fest, dass Projekte nicht besser oder gar schneller vorankommen, und kommt zu dem Schluss Scrum funktioniert für das Unternehmen einfach nicht so, und man muss es verbessern, indem neue Abstimmrunden und Genehmigungsprozesse für die Bearbeitung von „tickets“ eingeführt werden.

Leider scheint es, dass Unternehmen, die diesen Weg weit genug gegangen sind, für agile Entwicklung verloren sind. Die entstandene negative Belegung des Begriffs „Scrum“ ist wohl kaum korrigierbar.   „

Macht den Selbst-Test und prüft etwa folgende Checkliste !

Judith Görs stellt in ihrem Artikel https://www.n-tv.de/politik/Warum-Europas-Genossen-am-Tropf-haengen-article20773788.html die These auf, dass der Niedergang der SPD und allgemein der Linken Parteien von ihren eigenen Erfolgen gefördert wird. Danach haben sich die Verhältnisse der klassisch links wählenden Arbeiterschaft in den vergangenen 100 Jahren so sehr verbessert, dass diese heute mehr an der Wahrung der errungenen Verbesserungen interessiert sind als an weiteren Kämpfen gegen die ehemals als besitzende Bürgerschicht bezeichnete „Klasse“. Der klassische Arbeiter existiert nicht mehr, heute sind viele eher auch Bürger und wählen auch „bürgerliche“ Parteien.

Ich denke, da ist etwas dran. Die alten Themen soziale Gerechtigkeit, Schutz der Arbeiter vor Ausbeutung und ähnliches sind zwar immer noch präsent, jedoch nicht mehr existentiell für viele Menschen.

Es gibt immer noch „prekäre“ Verhältnisse und es ist wichtig, hier weiter aktiv zu sein und für die Betroffenen Verbesserungen zu schaffen. Dies sind jedoch nicht die Arbeiterscharen vom Anfang des letzten Jahrhunderts, der Organisationsgrad oder auch nur die Erreichbarkeit dieser Menschen durch Organisation ist viel geringer. Diese Gruppe gewinnt keine Wahlen, schon gar nicht für linke Parteien.

Vor kurzem beging Deutschland den hundertsten Jahrestag der Ausrufung der Republik durch Philip Scheidemann. Damals haben sich die Sozialdemokraten an die Spitze einer Bewegung gestellt, nicht jedoch von sich aus etwa den Matrosenaufstand ausgelöst.

Das Festhalten an den Themen und Zielen vergangener Tage bringt keinen Erfolg. Die Themen sind ausgelaugt, die Parolen der linken Parteien erscheinen antiquiert. Auch die Gewerkschaften in Deutschland sind nicht mehr so stark wie früher. Sie repräsentieren ebenfalls nicht mehr die Massen der Wähler. Es gibt allerdings viele Spartengewerkschaften, die jeweils für sich mit zum Teil abenteuerlichen Forderungen immer wieder für Schlagzeilen sorgen. Da hier jedoch immer relativ kleine Gruppen auftreten, wird bei der größeren Menge der Wähler eher Unmut erzeugt und keine Gemeinschaft.

Ich glaube allerdings nicht an die These „Die Sozialdemokratie heute ist zu liberal“. Eine radikal linke Partei gewinnt auch keine Wahlen. Es ist für mich viel mehr so, dass die Linken Parteien heute nach wie vor versuchen, die Diskussionsthemen selber zu benennen anstatt die Themen, die die Mehrheiten bewegen, wirklich aufzugreifen.

Wir sehen im europäischen Ausland und darüber hinaus, dass es vielmehr Bewegungen „von unten“ sind, die Wahlen gewinnen. Emmanuel Macron ist in Frankreich Präsident geworden an der Spitze einer neuen Bewegung. In den USA haben die Republikaner einen Mann an ihre Spitze gesetzt, der aus einer ähnlich agierenden Bewegung kam, die allerdings ganz andere Ziele aufgegriffen hat als Macron

Meiner Meinung nach werden die früher linken Wähler in Deutschland nicht mehr „abgeholt“ in ihren wirklichen Sorgen und Bedürfnissen.

Die Grünen in Deutschland sind hier weiter, sie versuchen tatsächlich flexibel zu sein und auf Fragestellungen zu reagieren. Die Wahlergebnisse honorieren dies. Die Grünen haben jedoch auch einen Traditionsanteil, der Partei wird grundsätzlich Engagement für Umwelt und Frieden zugeschrieben. Das sind wieder eher abstrakte Probleme für viele Wähler.

Die AFD ist auch eine Bewegung, sie greift Stimmungen und Ängste auf und gewinnt damit Wähler. Den Beweis des „besser können“ braucht sie nicht anzutreten, die Gefahr einer Regierung durch die AFD besteht zur Zeit (noch) nicht.

Ich befürworte keineswegs einen Populismus, der irgendwelchen Wählern vorgaukelt, es würde alles gut, wenn nur alle ihr Kreuz hier machen. Die Menschen und Wähler sind jedoch emanzipiert. Parteien werden nicht mehr gewählt „weil man immer schon sein Kreuz dort gemacht hat“. Wähler sind agil und wenden sich demjenigen zu, von dem sie sich ernst genommen fühlen und der vertrauenswürdig erscheint.

Ich glaube, wenn sich die Sozialdemokratie ernsthaft mit den konkreten Sorgen wie Dieselskandal, Arbeitsplätze der Zukunft, Flüchtlingen und Integration und den Ängsten der Wähler davor, befassen würde und hier realistische Lösungen glaubwürdig anbieten würde, dann kämen auch die Wähler wieder. Dann wäre die Tradition und der Name SPD auch wieder eine Hilfe und keine Last.

Eines der ersten Bücher, die ich über agile Entwicklungsmethoden gelesen habe, war von Craig Larman: Agile & Iterative Development (erschienen bei Addison-Wesley). Der Untertitel dieses Buchs lautet „A Manager’s Guide“, und es enthält neben den Beschreibungen verschiedener agiler Methoden viele Hinweise auf Fallstricke bei der Umsetzung. Besonders Manager beziehungsweise Führungskräfte, klassische Team- und Projektleiter werden angesprochen und ihr Einfluss auf Erfolg oder Misserfolg agiler Entwicklung wird betont.

10 Jahre später schreibt Ian Mitchell in einem Aufsatz über die seiner Meinung nach 20 häufigsten Fehler agiler Führung, das Thema scheint heute aktueller denn je. Auch die sonstige Literatur zu Scrum und anderen agilen Methoden dreht sich aktuell weniger um die Entwicklungsmethoden an sich, sondern um die Probleme bei der Einführung in Unternehmen.

Die oft so genannte agile Transformation stellt Unternehmen insgesamt vor Herausforderungen, weil es zum Teil lange gewachsene Entscheidungs- und Führungsstrukturen gibt. Die meisten agilen Methoden, insbesondere Scrum, betonen die Eigenständigkeit der Teams, die Entscheidungsverantwortung eines „product owners“. So etwas stellt die gewachsenen Hierarchien praktisch auf den Kopf. Welche Rolle soll dann ein Abteilungsleiter, ein Bereichsleiter oder ähnlich benannte Positionen insbesondere im mittleren Management noch haben?

Diese Hierarchien bestehen aus (Plan-)Stellen, Organisationseinheiten und Stellenbeschreibungen. Das wäre leicht zu ändern. Allerdings bestehen diese Strukturen nicht nur auf dem Papier. Diese „Posten“ werden von Menschen besetzt, die menschlich verständlich um ihre Existenzberechtigung im Beruf fürchten, wenn Entscheidungen nun anderswo getroffen werden sollen. Wer ist denn für die Arbeit eines Teams verantwortlich? Das geht doch nicht ohne einen Projektleiter?

Eine erfolgreiche agile Transformation eines Unternehmens kann nur gelingen, wenn diese Menschen einbezogen werden und weiter sinnvolle Beiträge liefern können. Selbstverständlich braucht ein Unternehmen weiter ein Management. Auch Manager im mittleren Bereich werden gebraucht. Es gibt auch in agilen Unternehmen genügend Aufgaben im Bereich der Personalentwicklung, der strategischen Ausrichtung der Entwicklung, der Markt- und Kundenbeobachtung und so weiter. Jemand muss im Unternehmen die Richtung vorgeben.

Ian Mitchell spricht in einigen Punkten von einem Management-Verhalten, welches ich auch gut kenne. Ich nenne das Pseudo-Agilität. Dabei werden Begriffe aus agilen Methoden so umgedeutet, dass sie zu den bisher geübten Verhaltensweisen passen. Dadurch muss der Manager eigentlich nichts ändern, vor allem nicht sich selbst.

Beliebt scheint mir dabei insbesondere der Umgang mit einem product backlog und der Rolle des product owners zu sein. Dazu habe ich ein aktuelles Beispiel: die Kürzung des backlogs auf die für das Management relevanten Top 5-Themen.

In dem Beispiel erlebe ich immer wieder, dass es ein oder sogar mehrere Gremien aus Führungskräften gibt, die über die Aufnahme von Themen in das Backlog entscheiden. Dazu muss der product owner ein „canvas sheet“ ausfüllen und dieses einreichen. Dann wird über dieses Thema separat diskutiert und entschieden. Die Menge der Themen ist limitiert auf maximal 10, oft nur 5. Dabei geht es leider nicht um strategische Entscheidungen zu neuen Produkten, sondern um Details der Weiterentwicklung. Jedes Thema, egal wie klein, muss durch diesen Prozess. Selbst von Kunden gewünschte Verbesserungen, für die das Team nur Stunden oder wenige Tage zur Umsetzung benötigt, sind nicht ausgenommen.

Hier lebt das althergebrachte Control board in vollem Umfang weiter. Manager haben weiter das letzte Wort, auch wenn sie sich jetzt stakeholder nennen. Agil ist dabei nichts, die Reaktionszeiten auf Anforderungen der Kunden ist weiter lang, die Kosten für die Umsetzung durch die vielen Prozessschritte hoch.

Es ist selbstverständlich, dass Teams nicht einfach entwickeln sollen, was ihnen gerade in den Sinn kommt. Hier ist es die Aufgabe der Manager, Richtlinien und strategische Ziele vorzugeben. Die Entscheidung über konkrete Themen innerhalb des gesetzten Rahmens muss allerdings den product owner treffen und verantworten. In letzter Konsequenz haftet dieser mit seiner Position für seine Entscheidungen.

Es ist nicht immer einfach, die Grenze zwischen strategischer Richtlinie und konkreten Anforderungen zu definieren. Diese beiden Positionen gehen ineinander über. Die Entscheidung ,,wir entwickeln jetzt eine Cloud-Anwendung“ ist strategisch. Ebenso wäre etwa ,,wir machen etwas für eine neue Kundengruppe“ klar strategisch, oder auch „jede Neuerung in eine Standardsoftware kostet für die Kunden in Zukunft Geld“. Wie genau solche Ziele umzusetzen sind, ist dann Sache des product owners. Dieser kennt die konkreten Bedürfnisse der Kunden viel besser als ein Manager, er hat viel mehr Kontakte mit Kunden. Welche Funktionen in einer Cloud angeboten werden oder wofür Kunden bezahlen würden muss der product owner entschieden. Eine fachliche Weisungsbefugnis von Führungskräften gegenüber dem product owner oder den Teams zerstört die Agilität. Ich empfehle zur Abgrenzung oft ganz einfach auf den Umfang des Themas zu schauen. Wenn ein Thema mehr als zwei oder drei Sprints zur Umsetzung erfordert, ist das für mich ein Hinweis auf eine strategische Komponente.

Der finanzielle Aspekt eines Unternehmens ist eine weitere Aufgabe für Manager. Ich kann mir nicht vorstellen, wie ein Team beliebig Entwicklungsthemen priorisieren und umsetzen könnte, ohne dass jemand auf den wirtschaftlichen Erfolg des Unternehmens achtet. Irgendwann übersteigen die Kosten einer Entwicklung den Nutzen für die Kunden, es entsteht durch die Entwicklung kein neuer Umsatz. Die Finanzierung des Teams muss dann beendet werden. Auch umgekehrt muss für neue Ideen, neue Produkte oder Strategien ein Businessplan erstellt werden, und die Finanzierung muss entsprechend bereitgestellt werden. Die Herausforderung für Manager liegt dabei wieder in der nötigen Zurückhaltung bei Detailfragen.

Als letzten Aufgabenbereich von agilen Managern gibt es noch die Förderung der Mitarbeiter. Dies beginnt mit der Suche nach neuen Mitarbeitern mit benötigten Skills für die Aufgaben eines Teams und wird gefolgt von der Organisation von Weiterbildungen und ähnlichen Aktivitäten, die die Teammitglieder individuell voranbringen.

Manager werden also weiter gebraucht, nur ändert sich ihr Aufgabenbereich im Rahmen der agilen Transformation genauso grundlegend wie der Bereich der Entwicklungsteams. Ein Unternehmen kann nur erfolgreich agil werden, wenn alle Bereiche einbezogen werden.