On Lean and Agility

Bild: Unsplash / Fabio Bracht - Lizenz

Patrick McKenzie: Seeing like a Bank

Karl Scotland: A Simple Resolution to the Agile Transformation Conundrum

Roman Pichler: Decoding Product Leadership

Leadership ist immer ein schönes Thema, vor allem im Umfeld selbstorganisierter Teams, in denen eine direkte Weisungsbefugnis nicht mehr oder nur eingeschränkt gegeben ist. Roman Pichler beleuchtet das Konzept von verschiedenen Seiten und beschreibt unter anderem charismatische Führung (allerdings ohne diesen Begriff zu verwenden), informelle Führung und emergente Führung. Interessant sind auch seine verschiedenen Dimensionen von Product Leadership: Trust-building, Empathising, Communication, Goal Setting, Collaborative Decision-Making, Conflict Resolution und Self-Leadership. Was das im Anwendungsfall bedeutet, wird zwar jeder für sich erarbeiten müssen, es ist aber eine gute Übersicht über die Felder, in denen man Führungsqualitäten entwicklen kann.

Chris Alderson: Beyond Scaled Agile Frameworks

John Cutler: How to Troubleshoot Status Updates and Syncs

Bild: Unsplash / Will Francis - Lizenz

Vor kurzem bin ich halb im Scherz als "Podcaster ohne Podcast" bezeichnet worden, da ich mittlerweile in mehreren zu Gast gewesen bin. Ganz soweit würde ich zwar nicht gehen (es sind bisher gerade einmal sechs solche Gastauftritte zusammengekommen), aber wer weiss was noch kommt. Hier sind erstmal die beiden neuesten.

Der hier ist schon einige Wochen her, und er dürfte das vielleicht kontroverseste Thema haben, mit dem ich bisher an die Öffentlichkeit gegangen bin. In André Claassens OKR-Podcast habe ich mit ihm darüber gesprochen, warum ein Scrum Master kein Coach sein kann (u.a. wegen keiner Auswahl durch die Coachees und keiner eigenen Agenda-Freiheit). Da viele Inhaber dieser Rolle sich aber explizit als (Agile) Coaches sehen habe ich in Folge einige lebhafte Feedbacks erhalten.

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Die neueste Aufnahme ist wieder eine zu einem meiner Lieblingsthemen, zu dem ich auch schon Konferenzvorträge und eine andere Podcast-Aufnahme gehabt habe: Transformations-Metriken, an denen das Management auch die Ergebnisse der eigenen Arbeit messen kann, und nicht nur die der Ausführungsebene. Mit Miriam Sasse und Ellen Duwe vom Agile World News-Podcast hatte ich diesesmal gleich zwei Gesprächspartnerinnen um mich darüber auszutauschen.

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Das schönste Missverständnis zum Begriff CI habe ich einmal mit einer UX-Designerin erlebt, die der festen Meinung war, die Entwickler in ihrem Team würden über Corporate Identity sprechen. Clare Sudbery dürfte über dieses Level an Verständnis weit, weit hinausgekommen sein. Richtigerweise ist es bei ihr Continuous Integration, oder wie es ihrer Meinung nach heissen müsste "Continuous Trunk Based Development" (CTBD).

Wer CI kennt, wird vor allem nickend vor dem Bildschirm sitzen, einige kleine Erkenntnisse sind aber sicherlich für jeden dabei. Mir war zum Beispiel nicht klar, dass Kent Beck bereits im Rahmen von Extreme Programming CI (noch unter einem anderen Namen) beschrieben hat.

Bild: Pexels / Ketut Subiyanto - Lizenz

Zu den Überraschungen, die man in grossen Firmen aus dem Silicon Valley erleben kann, gehört die fast vollständige Abwesenheit von Scrum Mastern, Agile Coaches, People Managern und vergleichbaren Rollen. Das erscheint zunächst merkwürdig, schliesslich gelten Google, Facebook, Netflix & Co doch als Vorzeige-Beispiele gelungener Agilität. Und es wirft die Frage auf, welche Führungsrollen es dort stattdessen gibt. Eine auf die man dabei immer wieder stösst, ist die des "Tech Lead Managers" (TLM).

Um diese Rolle einordnen zu können: die klassische Silicon Valley-Rollenteilung ist die in Engineering Manager und Tech Lead.¹ Den Engineering Manager kann man sich dabei wie eine Mischung aus Abteilungs-Leiter und Product Owner vorstellen, mit der Besonderheit, dass er selbst einmal Softwareentwickler gewesen sein muss.² Der Tech Lead oder Lead Developer ist ein teaminterner oder -externer Experte, der den Entwicklern Entwicklungsprozesse und -standards vorgibt.

Beide Rollen haben im Vergleich zu einem Scrum Master, Product Ower, Agile Coach oder People Manager eine relativ hohe Weisungsbefugnis gegenüber ihren Teammitgliedern. Der Grund dafür sind zwei weitere Besonderheiten: die Entwickler sind im Durchschnitt eher jung, und sie wechseln verhältnismässig häufig (mitunter jährlich) den Job. Beides liegt daran, dass für viele das stressige Silicon Valley nur ein "Karriere-Sprungbrett" ist, mit dem sie sich für andere Firmen empfehlen.³

Bedingt dadurch sind viele Teams eher unerfahren und befinden sich in einer permanenten Storming-Phase, was durch die eher anleitende Ausgestaltung der Rollen kompensiert werden soll. Das kann auch funktionieren, bringt aber das Risiko mit sich, dass die beiden leitenden Rollen sich aufgrund ihrer unterschiedlichen Interessen gegenseitig blockieren. Dort wo Geschwindigkeit wichtig ist, werden sie daher oft zum Tech Lead Manager zusammengefasst, der alle Entscheidungen alleine treffen kann.

Im Vergleich zu den aus dem Osten der USA stammenden Ansätzen Scrum und Extreme Programming mag das auf den ersten Blick wenig agil wirken, da diese Rolle die Selbstorganisation der Teams stark einschränken kann. Wird Agilität aber einfach als schnelle Reaktions- und Lieferfähigkeit verstanden, kann dieser eher hierarchische Ansatz in derartig volatilen Teams der zielführendere sein (was übrigens nicht bedeutet, dass hier Micro-Managing stattfindet, das wäre nochmal etwas Anderes).

Zu bedenken ist dabei allerdings, dass diese Doppelrolle für ihren Inhaber sehr fordernd und belastend sein kann, was auf Dauer zu neuen Problemen führt. Aufgrunddessen ist es z.B. bei Google so, dass sie vor allem in kleinen, neu zusammengestellten, oder in instabilen Umgebungen arbeitenden Teams geschaffen wird, während stabiliere oder erfahrenere Teams eher wieder die klassische Doppelspitze aus Engineering Manager und Tech Lead haben (siehe hier).

Was erkennbar wird: die Rolle des Tech Lead Manager kann durchaus entscheidend für einen agilen Arbeitsmodus sein, sie ist aber so spezifisch für das Silicon Valley, dass sie nur schwer übertragbar ist. Man kann sie zwar auch in Europa oder an der US-Ostküste einführen, hier würde aber das starke Risiko bestehen, dass sie zu einem Flaschenhals wird und das in den Teams vorhandene Wissen nicht ausreichend nutzt, und infolgedessen eine eher anti-agile Wirkung hätte.

Bild: Pexels / Anna Tarazevich - Lizenz

Eigentlich sind Learning & Development-Angebote grossartig: Firmen wollen die Aus- und Weiterbildung ihrer Mitarbeiter fördern und stellen ihnen darum kontinuierlich neue Lerninhalte zur Verfügung. Gerade in grösseren Organisationen kippt dieser eigentlich gute Ansatz aber immer wieder ins Dysfunktionale. Ein aktueller Fall, den man den Medien entnehmen kann, ist der von Slack, bzw. Salesforce. Das Drama, das hier wohl stattgefunden hat, ist leider exemplarisch für vieles was häufig schiefläuft, und verdient daher eine nähere Betrachtung.

Ausgangspunkt ist anscheinend die Digitalisierung und Automatisierung von Lern-Angeboten, die Salesforce irgendwann durchgeführt hat, vermutlich um die Einheitlichkeit der vermittelten Inhalte sicherzustellen, um sich von der Verfügbarkeit von Trainern und Schulungsleitern unabhängig zu machen, um Reiseaufwände zu den Schulungszentren zu sparen und um durch die beliebig häufige Wiederholbarkeit des einmal erstellten Materials Kosten einzusparen. So weit, so gut.

Ebenfalls betriebswirtschaftlich getrieben dürfte eine zweite Entscheidung gewesen sein: als interne Lernplattform wurde Trailhead gewählt, ein bereits vorhandenes Tool, das eigentlich dafür gedacht ist, Anwendern beizubringen, wie die Salesforce-Anwendungen funktionieren. Ein wesentliches Element dieses Tools sind Gamification-Elemente, das heisst, Lern-Punkte, die man für das Bewerten von Kursen und das Abschliessen von Wissenstests sammeln kann. Ebenfalls erstmal ok.

Eher humanistisch motiviert war vermutlich die dritte Entscheidung: Im Sinn eines Studium Generale wurden auch Inhalte in die "Lehrpläne" einbezogen, die keinen unmittelbaren Bezug zur täglichen Arbeit haben, etwa Eräuterungen der "vierten Industriellen Revolution" (Industrie 4.0) oder zur gesunden Ernährung. Auch daran kann man für sich genommen nur Gutes finden, ein Blick über den Tellerrand schadet nie und beugt dem Entstehen von Fach-Idiotie vor.

Was anscheinend nicht bedacht wurde, war der durch diese Art der Wissensvermittlung entstehende Zeitaufwand. Die verschiedenen Inhalte erreichten in Summe einen bemerkenswerten Umfang, und durch die Gamification-Elemente liessen sie sich nicht mehr im Hintergrund abspielen, sondern erforderten ständige Interaktion. Um die vorgegebenen Lernziele zu erreichen musste daher Zeit im Umfang von mindestens 40 Stunden investiert werden.

Man kann jetzt versuchen, sich in die Mitarbeiter der Salesforce-Tochtergesellschaft Slack hineinzuversetzen. In ihrem Learning & Development-Portal fanden sie Inhalte, die zum Teil generisch und zum Teil beruflich irrelevant waren, nur mit hohem Zeitaufwand konsumierbar waren, in einem Tool angeboten wurden, das eigentlich erkennbar einem anderen Zweck dienen sollte, ohne die Möglichkeit Verständnis- oder Vertiefungsfragen zu stellen. Kaum einer nahm diese Lern-Angebote an.

Peinlich wurde das aus Sicht des Unternehmens dadurch, dass es für jeden offensichtlich war. Die Gamification Elemente sorgten nicht nur dafür, dass die einzelnen Mitarbeiter Lern-Punkte sammeln konnten, dadurch dass die Ranglisten intern öffentlich waren, wurde klar, dass kaum jemand Punkte sammelte, was im Umkehrschluss bedeutete, dass kaum jemand die Learning & Development-Angebote wahrnahm. Ein offensichtliches und verheerendes Feedback.

Ebenfalls verheerend war die Reaktion des Unternehmens: das Lernen wurde erzwungen, indem angeordnet wurde, dass alle anderen Tätigkeiten eingestellt werden mussten, bis vorgegebene Mindest-Punktzahlen im Lern-Tool erreicht waren. Und das am Ende des Jahres, mitten in der Phase, in der viele damit voll ausgelastet gewesen sein dürften, an der Erreichung ihrer (gehaltsrelevanten) Jahresziele zu arbeiten. Die Nicht-Begeisterung angesichts dieses "Lern-Zwangs" kann man sich vorstellen.

Aber wo Frustration entsteht, da wird nach Auswegen gesucht. Und da Software-Entwickler das Lösen technischer Probleme als Beruf haben, kam es bald zur absehbaren Pointe der Geschichte: die Mitarbeiter programmierten sich ihre eigenen Tools, die automatisiert die Gamification-Elemente in Trailhead durchklickten. So konnten die geforderten Lern-Punkte erzeugt werden, ohne dass man sich mit den aufgezwungenen Themen beschäftigen musste. Formalismus erfüllt, Lerneffekt gleich null.

Man kann sich jetzt überlegen, an welcher Stelle der eigentlich gute Learning & Development-Ansatz entgleist ist. Vielleicht bei der Idee, generische Inhalte für alle Mitarbeiter festzulegen, vielleicht beim Versuch, durch die Wiederverwendung eines für einen anderen Zweck konzipierten Tools Geld zu sparen, vielleicht bei der Erstellung einer Punkte-basierten "Lern-Planwirtschaft", vielleicht beim Versuch, den Erfolg des Vorgehens zu erzwingen. Vermutlich war es eine Kombination von allem.

Selbst wenn dieser Fall vermutlich ein extremer ist, die verschiedenen Entgleisungs-Ursachen finden sich in unterschiedlicher Ausprägung in sehr vielen grossen Organisationen wieder, was auch erklärt, dass die internen Lernangebote einen nicht besonders guten Ruf haben. Und ich kann es aus eigener Erfahrung sagen: selbstgebaute Tools, mit denen Entwickler lästige Pflichtkurse "wegautomatisieren", gibt es nicht nur bei Salesforce, sondern auch in anderen Firmen.

Noch einmal zum Thema Velocity. Obwohl diese Metrik kein offizieller Teil von Scrum ist, ist sie in vielen Teams ein wesentliches Element der Umsetzung dieses Frameworks. Was dabei im Mittelpunkt steht, ist in der Regel der Planungs-Aspekt, also die Ableitung zukünftiger Arbeitsleistung aus der durchschnittlichen Story Point-Menge der letzten Sprints (siehe hier). Es gibt aber auch einen zweiten, seltener thematisierten Aspekt: eine Velocity erzeugt auch ein Work in Progress Limit (WIP Limit).

WIP Limits kennt man eigentlich aus Kanban und anderen Lean-Ansätzen, wo sie verwandt werden, um Überlastung und Multitasking zu vermeiden und den Arbeitsfluss zu verbessern. Die Idee ist eigentlich einfach: dadurch, dass eine Obergrenze für gleichzeitig bearbeitete Aufgaben eingeführt wird, werden weniger Arbeitspakete gleichzeitig begonnen, Multitasking und Koordinationsaufwände gehen zurück und Ergebnisse werden schneller fertig.

Das klingt erstmal gut, in der Realität kommt es allerdings regelmässig dazu, dass diese Obergrenzen zu hoch angesetzt werden. Wenn ihre Festlegung durch das Management erfolgt kann das z.B. daran liegen, dass die Kapazität der Umsetzungsebene zu optimistisch eingeschätzt wird (oft verbunden mit Wunschdenken in Bezug auf Fertigstellungstermine), oder dass möglichst vielen Stakeholdern das Gefühl gegeben werden soll, dass ihre Anliegen bearbeitet werden.

Aber auch wenn die Verantwortung für das Setzen der WIP Limits bei den jeweiligen Umsetzungsteams liegt, sind diese häufig zu hoch. Auch das kann daran liegen, dass versucht wird, möglichst viele Stakeholder zu befriedigen, mindestens genauso häufig ist aber eine unrealistisch optimistische Einschätzung der eigenen Leistungsfähigkeit oder eine Unterschätzung des mit bestimmten Tätigkeiten verbundenen Arbeitsaufwands.

Die Verwendung der Velocity sorgt dafür, dass die WIP-Obergrenzen realistischer werden. Wenn der durchschnittliche  Output der letzten Sprints (Yesterdays Weather) bei 18 Punkten liegt, und demzufolge auch maximal diese Menge für den nächsten eingeplant werden soll, dann verschwinden "politische" Handlungsmotive und unsichere Faktoren wie die Selbst- und Fremdeinschätzung der Leistungsfähigkeit eines Teams aus dem Planungsprozess. Alleine dadurch werden die Planungen besser.

Der Vollständigkeit halber sei noch angemerkt, dass Scrum Teams die Planung ihrer Sprints eigentlich nicht an einem Output (in diesem Fall der Velocity) sondern an einem Outcome orientieren sollten, also an dem fachlichen Sprint-Ziel, dessen Umsetzungsaufwand eine gewisse Variabilität haben sollte, um auf ungeplante Entwicklungen reagieren zu können. Wenn aber (warum auch immer) eher Outcome-orientiert gearbeitet wird, kann ein auf der Velocity beruhendes WIP Limit eine gute Idee sein.

Bild: Pexels / Yan Krukau - Lizenz

Seit einigen Jahren werde ich regelmässig auf mein Buch angesprochen und darauf, dass ich es erstaunlich selten erwähne. Der Grund dafür ist einfach - es ist gar nicht von mir. Wie es der Zufall will gibt es einen zweiten Felix Stein, der eine Zeit lang als Unternehmensberater gearbeitet und ein Buch darüber geschrieben hat. Um zumindest zu wissen worum es geht, habe ich es gekauft und muss sagen, es gefällt mir wirklich gut.

Der Name des Buches ist Work, Sleep, Repeat: The Abstract Labour of German Management Consultants, und anders als man angesichts der Einleitung denken könnte ist es weniger ein subjektiver Erfahrungsbericht und mehr eine wissenschaftliche Arbeit geworden, die man in die Disziplinen der Antropologie, Soziologie oder Sozialpsychologie einordnen könnte. Neben eigenen Erfahrungen basiert es auch auf empirischen Erhebungen unter deutschen Management-Beratern.

Inhaltlich beginnt es mit einem kurzen geschichtlichen Überblick über die Entstehung des Berufs des Unternehmensberaters, der aber nicht bloss Daten und Ereignisse aufzählt, sondern bereits Zusammenhänge herstellt, etwa den, dass im frühen 20. Jahrundert die Entkoppelung leitender und ausführender Arbeiten dafür gesorgt hat, dass nicht nur das Management als Berufsgruppe entstanden ist, sondern durch seine Entfremdung von der Ausführungsebene mit ihm der Beratungsbedarf.

Aufbauend darauf konzentriert es sich auf die bereits im Titel prominent genannte "abstrakte Arbeit", die den wesentlichen Teil von Management-Beratung ausmacht. Herausgearbeitet wird, dass es sich bei den "Liefergegenständen" um Dinge wie Organisiertheit, Legitimität und Wissen handelt, deren Wert zwar unbestreitbar ist, die aber schwer zu fassen und zu beschreiben sind, so dass Gegenstand, Ausmass und Wert der damit verbundenen Tätigkeiten von Aussen mitunter schwer nachvollziehbar sind.

In einem parallelen "Erzählstrang" ziehen sich Beobachtungen der Auswirkung dieser Art der Arbeit und des Arbeitens auf die jeweiligen Berater durch das Buch. Effekte wie Gruppen-Identität, -Konformität und -Abgrenzung gehören dazu, aber auch negative Folgen wie Entfremdung von der Arbeit und anderen Menschen, Stress, Krankheiten und Verlust des Privatlebens. Ein ganzes Kapitel widmet sich dann der naheliegenden Frage, warum so viele Menschen trotzdem diesen Beruf ergreifen.

Als jemand der selbst bereits als Management-Berater tätig war, kann ich das was der andere Felix Stein in seinem Buch schreibt verstehen und bestätigen. In vielen der Beispiele und Zitate erkenne ich eigene Erlebnisse wieder. Als Geisteswissenschaftler kann ich ausserdem nur anerkennen, dass er ein Kunststück auf der Meta-Ebene vollbringt: abstrakte Arbeit wird hier aus einer nochmals höheren Abstraktionsebene betrachtet, beschrieben und eingeordnet.

Auch allen die keinen derartigen Hintergrund haben kann ich Work, Sleep, Repeat empfehlen. Wie in ihm beschrieben wird, kann die Arbeit von Management-Beratern massive Auswirkungen auf alle Menschen in einer Organisation haben, ist für die meisten aber unsichtbar oder unverständlich. Vor allem wenn man in grösseren Organisationen arbeitet (wo es nur eine Frage der Zeit ist, bis externe Berater auftauchen), kann es ein wesentlicher Beitrag zu einem verbesserten Systemverständnis sein.

Quelle: Twitter

Agile in a Nutshell, von Alistair Cockburn, einem der Unterzeichner des Manifest für agile Softwareentwicklung.