Kommentierte Links (CIII)

Bild: Unsplash / Fabio Bracht - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Thomas Michl: Agile Skalierung mit Kanban | Ein Überblick über die drei Skalierungsdimensionen

Nachdem der "Agile Michl" regelmässig in seinem Blog auf mich verweist, freut es mich, das es heute auch mal in die andere Richtung gehen kann. Das Thema mit dem er sich befasst ist eines, das gleichermassen selten wie wichtig ist: die Skalierung von Kanban. Diese kann auf drei Arten stattfinden: durch Verlängerung des Kanban-Systems entlang des Wertstroms, durch Koppelung mehrerer Systeme oder durch Verbindung verschiedener Flughöhen (Granularitäts-Ebenen) miteinander. Während ich diese Unterscheidung schon kannte, ist die griffige Benennung für mich neu - Skalierung in die Breite, in die Tiefe und in die Höhe. Diese Begriffe werde ich von jetzt an auch benutzen.

Jason Yip: Thoughts on role expectations on empowered product teams

"Schlecht definierte Rollen erhöhen die Notwendigkeit von Kommunikation und führen zu mehr Zeit in Meetings." Mit diesem direkt zu Beginn angeführten Zitat macht Jason Yip sehr deutlich, warum Rollenklärung für agil arbeitende Teams wichtig ist. Gleichzeitig ist ihm aber auch bewusst, dass er sich damit in einem Spannungsfeld befindet, denn zu detailliert festgelegte Rollen nehmen Flexibilität weg und können für Bürokratie sorgen. Den richtigen Punkt in der Mitte zu finden (und ununterbochen neu auszuhandeln) gehört zu den wesentlichen Erfolgsfaktoren. Yip fügt dem Ganzen noch eine weitere Dimension hinzu, indem er zwischen individuellen und kollektiven Verantwortlichkeiten und Erwartungen differenziert. Auch das ist in agil arbeitenden Teams immer wieder ein Thema.

Tendayi Viki: It’s more fun to be a pirate in the Navy

Von Tendayi Vikis gibt es das Buch Pirates in the Navy, das ich sehr empfehlen kann (und zu dem ich vor einiger Zeit eine Rezension geschrieben habe). Die titelgebende Kernaussage ist die, dass überzeugte Freigeister (→ Piraten) sich immer schwer tun werden, wenn sie in klar strukturierten Organisationen (→ der Marine) arbeiten sollen. Nicht nur deshalb weil sie gegen deren Regeln verstossen, sondern auch weil sie durch das Umgehen offizieller Prozesse für die anderen, die nur im Rahmen dieser Prozesse arbeiten, unsichtbar werden. In diesem Blogpost baut Viki die Piraten-Analogie weiter aus und empfiehlt, sich eher an den Freibeutern zu orientieren, die zwar autonom agierten, das aber durch eine offizielle Lizenz erlaubt bekommen hatten, wodurch sie legal und sichtbar vorgehen konnten.

Michael Küsters: Leading by Absence

Wer schon einmal dabei war, wenn bisher von einem Manager geführte Teams plötzlich selbstorganisiert sein sollten, wird vermutlich diese Situation kennen: obwohl er weder führen soll noch will orientieren sich die Teammitglieder weiterhin an ihm, berichten was sie tun und fragen um Erlaubnisse oder Freigaben. Dort wo derartige Phänomene auftreten kann es sinnvoll sein, dass die bisherige Führungskraft sich eine gewisse Zeit lang vom Team fernhält, so dass dieses gar nicht anders kann als sich an eigene Verantwortung und eigene Entscheidungen zu gewöhnen. Die von Michael Küsters definierte Begrifflichkeit Leading by Absence trifft diese leicht paradoxe Situation recht gut. Dadurch, dass man fernbleibt führt man die bisherigen Untergebenen in die Selbstorganisation.

Mike Cohn: Top 7 Ways to Engage Stakeholders in Sprint Reviews

Zuletzt ein eher "handwerkliches" Thema. Die Klagen über Stakeholder, die sich nicht dafür interessieren was ihre Scrum Teams im letzten Sprint fertiggestellt haben, ist vermutlich schon so alt wie die Idee der Sprint Reviews selbst. Sinnvoller als sich zu beschweren ist es aber, die Termine so zu gestalten, dass die Stakeholder von sich aus gerne kommen. Einige Ideen dazu wie das gehen kann hat Mike Cohn hier aufgeschrieben. Sie erscheinen banal, würden aber in vielen Fällen zu deutlichen Verbesserungen führen.

The Agile Bookshelf: Why Managers Matter

Bild: Pxhere / Rawpixel - CC0 1.0

Es gibt zwei Informationen, die dabei helfen dieses Buch besser zu verstehen. Zum einen ist Why Managers Matter - The Perils of the Bossless Company von zwei Wissenschaftlern geschrieben, Prof. Nicolai J. Foss von der Wirtschafts-Hochschule Kopenhagen und Prof. Peter G. Klein von der amerikanischen Baylor University. Zum anderen ist es eine Streitschrift gegen die in der agilen Bewegung verbreitete Ansicht, möglichst ohne Manager auskommen zu können.

Inhaltlich besteht es aus zwei Teilen: im ersten, The Bossless Company, beschäftigen sie sich ausführlich mit den Argumenten, die für eine weitgehende Abschaffung von Management-Rollen ins Feld geführt werden, und untersuchen dabei auch mehrere Firmen, die immer wieder als Beispiele für eine derartige Struktur genannt werden. Im zweiten, Why Hierarchy Works, begründen sie, warum sie Manager weiterhin für unverzichtbar halten.

Die Kernaussage des ersten Teils ist, dass fast alle Argumente für eine "Bossless Company" lediglich auf anekdotischer Evidenz beruhen und nicht statistisch oder sonstwie wissenschaftlich untermauert sind. Unter hunderttausenden von Unternehmen weltweit wird in den Regel nur eine kleine Zahl als Beispiel angeführt (u.a. Valve, Semco, W. L. Gore, Zappos, Wikimedia, Morning Star), und selbst in diesen Fällen sind die tatsächlich verfügbaren Informationen meist oberflächlich und lückenhaft.

In dieser dünnen Informationsdichte sehen Foss und Klein einen Hauptgrund für die Verklärung dieser Unternehmen. Anhand der verfügbaren Informationen zeigen sie auf, dass die oft genannten Beispiel-Unternehmen keineswegs "bossless" sind, sondern lediglich andere Strukturmerkmale aufweisen. Statt auf formellen Hierarchien beruhen sie auf informellen Hierarchien und charismatischer Führung, was bedeutet, dass es dort sehr wohl Management und Bosse gibt, nur in weniger sichtbarer Form.

Neben diesen weichen Faktoren identifiziert das Buch auch strukturelle Gründe dafür, dass der Eindruck entstehen kann, bestimmte Firmen kämen ohne Management aus. Digitalisierung, Standardisierung, Modularisierung und Outsourcing ermöglichen seit den 80er Jahren ein Systemdesign, in dem die einzelnen Mitarbeiter in ihrem Beruf nur noch wenige, klar vordefinierte Handlungsoptionen haben. Die Notwendigkeit von direkter Anleitung und Kontrolle geht dadurch deutlich zurück, die Tätigkeit der Manager verlagert sich stärker auf die Arbeit an Prozessen.

Die Kernaussage des zweiten Teils ist, dass die Sinnhaftigkeit von strukturiertem Management nicht nur gegeben, sondern auch belegbar ist. In einem bewussten Gegenentwurf zu der zuvor genannten anekdotischen Evidenz werden seine Aussagen mit Verweisen auf wissenschaftliche Werke untermauert, die zum Teil grundlegend sind,¹ sich zum Teil auf die Betrachtung prominenter Fallbeispiele beziehen und zum Teil auf Erhebungen in hunderten von Unternehmen beruhen.

Aufbauend auf der Entstehungsgeschichte moderner Unternehmen werden zentrale Vorteile von Management-Strukturen herausgearbeitet: hohe Effizienz (bzw. geringe Transaktionskosten), die Fähigkeit Entscheidungen schnell zu treffen, die Bereitschaft Risiken einzugehen (und zu verantworten) und die Fähigkeit unternehmensinterne Konflikte (auf einer höheren Hierarchie-Ebene) zu lösen, wenn die jeweiligen Konfliktparteien untereinander zu keiner Einigung finden können.

Dass all das durch Management-Strukturen möglich wird begründen Foss und Klein sowohl abstrakt (Management-Rollen schaffen Sichtbarkeit und Zuständigkeit) als auch am Beispiel verschiedener Hierarchie-Ebenen: während das Top-Level grosse Entscheidungen möglich macht, finden im Mittel-Management Brokerage and Bridging statt, also das Vermitteln, Ausdetaillieren und Konsolidieren von Informationen, so dass diese für die jeweilige Zielgruppe überschaubar und verständlich werden.

Umgekehrt zeigen sie an verschiedenen Fällen auf, dass zu viel Dezentralisierung und Delegation negative Folgen haben kann, bis hin zur strukturellen Unfähigkeit abteilungsübergreifend zusammenzuarbeiten. Als Beleg dafür werden verschiedene prominente Beispiele aufgeführt, von US-amerikanischen Bundesbehörden über die gescheiterte Daimler-Chrysler-Fusion bis hin zu wirkungslos bleibenden sozialen Grasswurzel-Protestbewegungen.

Wie zu Beginn gesagt, man muss The Bossless Company als Streitschrift verstehen, die an vielen Stellen pointiert und leicht überspitzt ist. Den Autoren sind die Schwächen von (zu viel) Management durchaus bewusst und diese werden auch immer wieder thematisiert und eingeordnet. Und ein ganzes Kapitel bezeichnet Hierarchie als etwas explizit Schlechtes, das nur deshalb zu bevorzugen ist, weil die Alternativen deutlich schlechter sind. Ein kassischen Bonmont.

Allen Befürwortern von flachen Hierarchien und dezentralen Entscheidungen kann man dieses Buch empfehlen, weil es verbreitete Glaubenssätze in Frage stellt. Man muss die Schlussfolgerungen von Foss und Klein nicht teilen, aber dass z.B. straff geführte Unternehmen wie Apple oder Marvel sich auf umkämpften Märkten behaupten können, während dezentralisierte wie Valve und Morning Star oft in Märkten mit wenig Innovation oder Wettbewerb entstehen, ist kaum zu bestreiten. Derartige Fälle zu kennen und einordnen zu können kann in Diskussionen nur hilfreich sein.

Zuletzt ist noch einmal die wissenschaftliche Arbeitsweise hervorzuheben. Auf ihren letzten 22 Seiten haben die Autoren ein umfangreiches Quellenverzeichnis zusammengetragen, dass ihre Untersuchungen, Analysen und Thesen untermauert und mit weiterführender Literatur anreichert. Ein Vorgehen, das man sich von vielen "Thougt Leadern" der Anti-Hierarchie- und Anti-Management-Bewegung auch wünschen würde.

¹Dazu gehören u.a. die von John Smith, Max Weber und Friedrich Hayek, aber auch die von Wirtschafts-Nobelpreisträgern wie Ronald Coase oder Oliver Wiliamson

Agile Coach (III)

Dafür, dass der Agile Coach mittlerweile eine zentrale und fast überall anzufindende Rolle geworden ist, ist seine Tätigkeit erstaunlich wenig ausdefiniert. Es gibt zwar die verbreitete Meinung, dass er irgendwie wichtiger oder breiter aufgestellt als ein Scrum Master ist, und es gibt mittlerweile auch viel Literatur (zwei bekannte Beispiele sind Coaching Agile Teams von Lyssa Adkins und Extraordinarily Badass Agile Coaching von Bob Galen), ein etabliertes Verständnis hat sich aber noch nicht herausgebildet.

Was bei der Betrachtung verschiedner Unternehmen auffällt ist aber, dass es eine begrenzte Menge an Teil-Aspekten gibt, die der Rolle immer wieder zugeordnet werden. Dass das trotzdem nicht zu einem einheitlichen Verständnis geführt hat, liegt daran, dass fast immer nur einige von ihnen genommen und kombiniert werden,¹ wodurch in der Gesamtbestrachtung die erwähnte Vielfalt und Uneinheitlichkeit entsteht. Hier sind die häufigsten dieser Teil-Aspekte in der Übersicht.

Berater (Team- oder Projekt-Ebene)

Vor allem am Anfang agiler Transitionen anzutreffen. Ein derartiger Agile Coach wird geholt um dabei zu helfen, die Rahmenbedingungen zu definieren, die von agil arbeitenden Teams benötigt werden, und um bei ihrer Schaffung zu unterstützen. Berater ist hier im eigentlichen Sinn zu verstehen: es ist jemand der weiss wie es geht und auf dessen Rat die Umsetzung beruht.

Trainer

Ein Trainer-Agile Coach ist in der chronologisch nächsten Phase anzutreffen. Die Rahmenbedingungen sind (mehr oder weniger) da, jetzt sollen die ersten Teams befähigt werden, in ihnen zu arbeiten. Zu diesem Zweck finden die Trainings aller Beteiligten in den ausgewählten agilen Frameworks statt (ggf. verbunden mit einer Zertifizierung).

Scrum Master / Flow Master / Team Coach

An dieser Stelle verschwimmt die Rolle des Agile Coach mit der des Scrum Masters, Flow Masters² oder Team Coach. Die Tätigkeiten sind praktisch die gleichen, was oft nicht etwa ein Versehen ist, sondern gewollt. Für viele Unternehmen ist ein Agile Coach einfach jemand der in der Lage ist, auf Team-Ebene mit verschiedenen Frameworks zu arbeiten.

Mentor

Mentoring durch einen Agile Coach kann in verschiedenen Formen auftreten, von einer Eins-zu-Eins-Beziehung mit einem Scrum Master/Team Coach über die Betreuung ganzer Gruppen bis hin zu Sprechstunden-artigen Beziehungen. Gemeinsam ist ihnen allen, dass der oder die Mentees³ wesentlich unerfahrener sind als ihr Mentor und seinen Rat suchen.

Coach

Die Grundform des Coaches. Obwohl es bei diesem Begriff ein breites Feld möglicher Bedeutungen gibt, ist die häufigste Bedeutung, die z.B. von der International Coaching Federation vertreten wird, die, dass der Coach eher bei der Selbsterkenntnis verhilft als Rat zu geben, z.B. durch bestimmte Fragetechniken. Anders als beim Mentor ist ein Coach nicht zwingenderweise erfahrener als der Coachee.⁴

Berater (Skalierung)

In gewisser Weise ein Sprung zurück zum Anfang. Agiles Arbeiten auf Ebene einzelner Teams oder kleiner Projekte funktioniert, jetzt soll es auf Grossprojekte oder Abteilungen ausgerollt werden. Wieder wird jemand gebraucht, der weiss wie es geht und auf dessen Rat die Umsetzung beruhen kann. Ein beratender Skalierungs-Agile Coach kann ggf. Experte für einzelne Skalierungsframeworks sein.

Chief Scrum Master / Release Train Engineer / Scrum of Scrums Master

Ein zweites Mal verschwimmt die Rolle des Agile Coach mit anderen, diesesmal mit dem Chief Scrum Master, dem Release Train Engineer oder dem Scrum of Scrums Master,⁵ also Methoden- oder Prozessmanagement-Rollen für grössere Organisationseinheiten. In vielen Firmen ist das auch der nächste Karriereschritt für Scrum Master und Team Coaches.

Auditor

Eine relativ seltene Ausprägung eines Agile Coaches. Es handelt sich um einen externen (oder zentral im Unternehmen verorteten) Experten, der überprüft ob Einführung und Umsetzung des agilen Arbeitens den zugrundeliegenden Ideen und den Vorgaben der gewählten Frameworks entsprechen. Enthält der Auditierungsbericht Verbesserungsvorschläge, gibt es eine Schnittmenge zum Berater.

***

Wie oben gesagt, die hier genannten Ausprägungen sind solche, die häufig anzutreffen sind, es sind aber nicht alle. Weitere könnten z.B. solche mit einem Schwerpunkt auf Innovation, einem technischen Focus oder einem Produkt-Focus sein, wobei diese Themen wenn überhaupt nur indirekte Bezüge zum Thema Agilität haben. Und nochmal zur Erinnerung: die allermeisten Agile Coaches decken nur einen Teil dieser Ausprägungen ab, nicht alle.

Dass das der Fall ist hat seinen Grund unter anderem darin, dass einige Teil-Aspekte der Agile Coach-Rolle so gegenläufige Zielsetzungen haben, dass sie nur schwer miteinander vereinbar sind, z.B. der Scrum Master und der Coach. Aber das wäre nochmal ein separates Thema.

¹Manchmal kommt dazu noch eine Kombination mit klassischen Rollen, z.B. einem Projekt- oder Prozess-Manager
²Diesem Titel hat die Lean Kanban University in ihrem Essential Kanban Condensed Guide dem Kanban-Gegenstück zum Scrum Master gegeben
³Mentee: eine Person, die von einem Mentor lernt
⁴Coachee: eine Person, deren Selbsterkenntnisprozess von einem Coach unterstützt wird
⁵Ja, das ist ein echter Titel, aus dem Skalierungsframework Scrum@Scale

Agile Transformations Using The 'Spotify Model'

Wenn es um das so genannte Spotify Model geht, bin ich durch vermutlich den gleichen Hype Cycle gegangen wie viele andere auch. Zu Beginn fand ich es spannend und cool, habe es später abgelehnt als etwas, was nicht einmal Spotify selbst macht und bin mittlerweile an dem Punkt angekommen, an dem ich es für einen nicht überall anwendbaren aber grundsätzlich sinnvollen Ansatz halte. Dieser Vortrag von Joakim Sunden, einem der ersten Agile Coaches bei Spotify, bestätigt mich in dieser Ansicht.

Seine Ausführungen basieren im Wesentlichen auf der agilen Transition des norwegischen Telekommunikationsunternehmens Telenor, dass er in einem späteren Job auf das Spotify Model umgestellt hat. Die wichtigsten Erkenntnisse (wenn man sie hören will): das Spotify Model kann ein funktionierendes "agiles Betriebssystem" sein, dass man in Firmen einführen kann, Es ist mehr als nur Tribes, Squads, Chapters und Gilden, und für viele sicher überraschend - es ist kompatibel mit SAFe.

Don't worry, be happy

Bild: Pxfuel - Lizenz

Wer dort unterwegs ist, wo mehr oder weniger nach den agilen Frameworks gearbeitet wird, wird früher oder später etwas Erstaunliches feststellen: ein Grossteil der Menschen hier befindet sich mehr oder weniger durchgehend in einem Zustand des Sarkasmus, des Zynismus oder der Ironie, wenn es zum Gesprächsthema Agilität kommt. Komisch eigentlich, schliesslich sollte man denken, das Verbessern der Arbeitswelt sollte doch eine freudige Angelegenheit sein.

Und doch ist es so. Ich bin mittlerweile seit über 10 Jahren in agilen Projekten und Transitionen unterwegs, habe mehr als 100 Meetups und User Groups organisiert oder besucht und bin auf mehr als 20 Konferenzen Speaker und Teilnehmer gewsen. Und in dieser gesamten Zeit habe ich überall einen signifikanten Anteil von Product Ownern, Scrum Mastern, Agile Coaches und sonstigen Agilisten vorgefunden, die durchgehend diese negativen Einstellungen hatten.

Bei näherer Betrachtung ist auch nachvollziehbar, wo das herkommt. Die Umstellung von (gerade grösseren) Organisationen auf agiles Arbeiten kann den Beteiligten wie eine Sisyphos-Arbeit vorkommen. Überall gibt es Missverständnisse, Widerstände und Hindernisse, statt klarer Entscheidungen gibt es oft nur halbgare Kompromisse und immer wieder gibt es Versuche alles wieder rückgängig zu machen. Wie soll man da nicht frustriert werden?

Selbst wenn es darauf keine für alle Kontexte gültige Antwort gibt, glaube ich eine gefunden zu haben, die zumindest mir dabei hilft, positv und optimistisch zu bleiben. Sie ist (wenig überraschend) der Ratschlag sich die Erfolgserlebnisse zu vergegenwärtigen, und zwar vor allem die kurzfristigen und langfristigen. Die dazwischen liegenden "Mühen der Ebene" bleiben zwar bestehen, sie erhalten aber durch das was davor und danach kommt ein neues Framing.

Kurzfristige Erfolgserlebnisse gibt es bei agilen Transitionen viele. Um das vermutlich häufigste zu nennen: wenn Teams nach einer Umstellung ihres Arbeitsmodus auf Scrum zum ersten mal selbst bestimmen dürfen, wie viel Arbeit sie in den nächsten Sprint nehmen, gibt es in der Regel einen Schub plötzlich steigender Arbeitsmoral, und wenn es in den nächsten Monaten zu einer höheren Liefergeschwindigkeit kommt, einen weiteren. Und das ist nur ein Beispiel.

Ich habe immer wieder die fast schon kindliche Freude von Stakeholdern erlebt, die mit einem dringenden Anliegen zum Product Owner gekommen sind und es bereits zwei Wochen später umgesetzt hatten, statt wie vorher mehrere Monate darauf warten zu müssen. Und auch einem Entwickler zuzuhören, der mit leuchtenden Augen davon erzählt, wie er nach 30 Jahren isolierter Arbeit in einer Konzern-IT das Pair Programming für sich entdeckt hat, ist etwas Besonderes.

Langfristige Erfolgserlebnisse muss man sich dagegen bewusst vor Augen halten, am besten durch den Vergleich der Ist-Situation mit der vor mehreren Jahren. Sobald Fachabteilung, Entwicklung, Qualitätssicherung und Betrieb in einem Team zusammenarbeiten wird das z.B. erstaunlich schnell als so normal wahrgenommen, dass in Vergessenheit geraten kann, wie revolutionär das in Relation zum Ausgangszustand ist, in dem nur über das Management miteinander kommuniziert wurde.

Und dass Refactorings, Abbau technischer Schulden und Bugfixing nicht hoch genug priorisiert werden, ist zwar ärgerlich, dass die umzusetzenden Anforderungen aber überhaupt einsehbar sind, dass sie umpriorisiert werden können, und dass für diese Umpriorisierung Wünsche und Hinweise geäussert werden können, ist etwas, das in den meisten klassisch geführten Unternehmen für utopisch oder gefährlich gehalten werden würde.

Ein einfacher Weg, sich selbst zu einem derartigen positiven Framing zu verhelfen, ist in Retrospektiven, Communities of Practice, Meetups und sonstigen Veranstaltungen darauf zu achten, dass dort nicht nur die gerade drängenden Probleme diskutiert werden, sondern auch das was gut läuft, was erreicht wurde und was sich gerade in eine positive Richtung entwickelt. Alleine die Beschäftigung damit kann ein Abgleiten in Sarkasmus, Zynismus oder Ironie vermeiden.

Gerade wenn man als Scrum Master oder Agile Coach arbeitet, hat man hier besondere Möglichkeiten, aber auch eine besondere Verantwortung. Da in einem agilen Setting die meisten Termine von diesen Rollen (mit)vorbereitet und moderiert werden, kann man besonderen Einfluss darauf nehmen, wie sie sich entwickeln. Man kann also selbst zu konstruktiver Stimmung beitragen. Auch das übrigens etwas, was ein guter Grund dafür ist, den eigenen Job und seinen Kontext positiv zu sehen.

Der virtuelle Agile Coach

Grafik: Pixabay / Alexandra Koch - Lizenz

Einer der grossen Hypes des Jahres 2023 ist die künstliche Intelligenz (KI), mit einem spezifischen Focus auf Programmen wie ChatGPT, denen das Potential nachgesagt wird, ganze Berufe der Wissensarbeit ersetzen zu können, darunter auch den Scrum Master und Agile Coach. Obwohl derartigen absoluten Aussagen immer mit Vorsicht zu begegnen ist, ist die Frage grundsätzlich spannend - welche Teile dieser Berufe könnte eine KI übernehmen?

Ein erster und naheliegender Teil wäre die Gestaltung von Retrospektiven. Man muss dazu wissen, dass diese bereits jetzt von vielen Scrum Mastern per Zufallsgenerator aus dem Retromat-Generator zusammengestellt werden. Bedenkt man dazu noch, dass für Remote-Retrospektiven für jedes Retromat-Modul ein entsprechendes Miro-Board bereitsteht, dann ahnt man, dass die Vorbereitung dieses Meetings problemlos automatisierbar ist (wenn auch auf Kosten der Individualität).

Ebenfall an eine KI übertragbar sind Teile der Meeting-Moderation. Egal ob in einem Daily ein Ticket nach dem anderen durchgegangen wird oder ein Team-Mitglied nach dem anderen - in beiden Fällen könnte auch ein Computerprogramm um ein kurzes Update bitten. Es könnte sogar darauf hinweisen wenn jemand zu lange redet oder an keinem Ticket auf dem Board arbeitet und Meeting-Ergebnisse zusammenfassen. Derartige Programme gibt es bereits, mit all ihren Möglichkeiten und Begrenzungen.

Erstaunlicherweise ebenfalls in Teilen automatisierbar sind Coaching-Gespräche. Bedenkt man, dass die bei vielen Agile Coaches aus einem überschaubaren Set von immer ähnlichen Fragen bestehen ("Was willst Du damit erreichen?", "Woran messt Ihr, ob es funktioniert hat?", "Wie fühlst Du Dich dabei?", etc.), dann ist eine Übertragung an eine KI gut vorstellbar. Einen ersten Erfahrungsbericht dazu gibt es in der FAZ (leider hinter einer Paywall). Sicher der kontroverseste Aspekt.

Auch das Erheben vieler Metriken kann ein Computerprogramm genau so gut wie ein Mensch - oder sogar noch besser. Velocity, Lead Times, Cyle Times, WIP Age, Throughput, Code Coverage, Deployment Frequency, Batch Size und Mean Time to Recovery werden in vielen DevOps-Teams bereits jetzt automatisch erhoben, die Verknüpfung mit einem Programm, das Auffälligkeiten erkennt und darauf hinweist, wäre problemlos machbar.

Was in absehbarer Zeit noch dazu kommen dürfte ist die Administration von Tools wie Jira oder Azure Boards. Bereits jetzt kann KI ganze Webseiten programmieren, das Konfigurieren von digitalen Kanban-Boards oder das Vergeben von Berechtigungen sind im Vergleich dazu relativ einfache Aufgaben. Auch eine Beschränkung der KI auf bestimmte zulässige Berechtigungen oder Konfigurationen wäre einfach umsetzbar.

Natürlich kann man diskutieren, ob das alles gute Ideen sind (bei der Meeting-Moderation ist das z.B. fraglich), und selbstverständlich gibt es Tätigkeiten, die eine KI noch nicht übernehmen kann (z.B. das Erkennen gemeinsamer Organisationsdesign-Root Causes von auf den ersten Blick unterschiedlichen Impediments oder die Verknüpfung von Softwarearchitektur-Entscheidungen mit langsamem Arbeitsfortschritt), vieles wird sich aber doch automatisieren lassen.

Zur Wahrheit gehört zuletzt auch, dass es viele Scrum Master und Agile Coaches gibt, deren Tätigkeit mit Retrospektiven-Vorbereitung, standardisierter Meeting-Moderation, Jira-Konfiguration und schablonenhaften Sinnfragen abschliessend beschrieben ist. Diese Menschen könnten fast ohne Qualitätsverlust von einer KI ersetzt werden. Für jeden, der zu dieser Gruppe gehört, wäre es daher ein guter Zeitpunkt, den eigenen Wirkungsradius deutlich zu erweitern.

Computer Aided Design und Digital Prototyping

Bild: National Archives / Combined Military Service Digital Photographic Files - CC0 1.0

Eine der grundlegenden agilen Praktiken ist das in kleinen Schritten vorangetriebene Inspect & Adapt. Man bringt eine neue Produkt-Version zum Kunden oder Anwender und schaut sich an was der damit macht. Wenn dieser Realitätstest überstanden wird kommt die nächste Version, wenn nicht wird die letzte überarbeitet. Aber was macht man, wenn das nicht geht oder es sehr teuer wäre?

Vor allem im Hardware-Bereich gibt es immer wieder derartige Fälle, was nicht nur die Entwicklung von Prototypen von Maschinen, Fahrzeugen und Geräten umfasst, sondern auch die von Bauwerken und Gebäuden. Zum Einen können die eingebauten Rohstoffe teuer sein, zum anderen sind die Einzelteile fest miteinender verbunden, um Belastbarkeit und Stabilität zu gewährleitsten. Ein "Auseinandernehmen und neu Zusammensetzen" geht also nicht so einfach.

Will man sich nicht darauf verlassen, alles beim ersten mal richtig zu machen (was, wenn es nicht klappt, gerade bei Bauwerken richtig teuer werden kann)  braucht man also eine Alternative, mit der man einem Inspect & Adapt zumindest nahe kommen kann. Eine mittlerweile weit verbreitete ist das so genannte Computer Aided Design (CAD), bei dem ein neues Gebäude-, Maschinen- oder Gerätebau-Vorhaben vor der eigentlichen Umsetzung durch mehrere digitale Simulations-Durchläufe geht.

Die entsprechenden Erfahrungswerte vorausgesetzt können damit eine ganze Reihe von Annahmen im Voraus überprüft, gegebenenfalls angepasst und erneut überprüft werden, noch bevor die eigentliche Konstruktion begonnen hat. Die häufigsten dertigen Überprüfungen beziehen sich auf Statik und Stabilität, es sind aber auch zahlreiche andere denkbar, vom voraussichtlichen Materialverschleiss bis hin zum Verhalten von Menschenmengen oder Luftströmen in einem Gebäude.

Natürlich kann man auf diese Weise nicht alles vorhersehen, was später in der Realität eintreffen wird, zumindest einen Teil der Validierungen kann man aber vorwegnehmen. Ein Fall, der das nachvollziehbar macht, ist der Wind-Widerstand von Hochhäusern, der erst ab einer bestimmten Höhe des Baus spürbar wird. Da übliche Windrichtungen und -stärken bekannt sind, ist es möglich, den Bauplan so lange zu optimieren, bis zu starke Schwankungen des fertigen Gebäudes im Voraus auszuschliessen sind.

Ein anderer Einsatzbereich ist die Berechnung möglicher Varianten eines bestehenden Hardware-Produkts, z.B. eines Fahrzeugs, einer Maschine oder eines Haushaltgeräts. Sollen diese besonders günstig, leistungsstark, robust, umweltfreundlich oder sparsam im Verbrauch sein, kann auf Basis des bestehenden Produkts ein digitaler Protyp entwickelt werden, mit dem die gewünschte Variante auf Umsetzbarkeit und mögliche Probleme überprüft wird.

Mit Hilfe derartiger Vorgehensweisen lässt sich das erreichen, was der auf dieser Website schon mehrfach erwähnte Grossprojekt-Forscher Bent Flyvbjerg "thinking slow, acting fast" genannt hat, also eine schnelle Umsetzung hochkomplexer Vorhaben durch eine auf Virtualisierung beruhende Validierung von Annahmen noch im Planungszeitraum. Noch mehr Shift Left geht nicht.

Near Miss in SAFe

Bild: Pixabay / Tookapic - Lizenz

Für alle agilen Frameworks gilt grundsätzlich, dass sie für sich genommen nicht gut oder schlecht sind, sondern Werkzeuge. Wie sie eingesetzt werden hängt stark vom Benutzer ab. Es gibt allerdings Unterschiede: Scrum mit seinem Sprint-Rhythmus könnte ein Hammer sein, Kanban mit seiner langsamen Verbesserung eine Feile. Und SAFe? Wenn wir in derartigen Analogien verbleiben wollen passt eine besonders gut - SAFe ist eine Motorsäge.

Um diese Gleichsetzung plastischer werden zu lassen: Motorsägen sind kraftvolle Geräte, mit denen man umfangreiche Arbeiten stark vereinfachen und beschleunigen kann, etwa das Baumfällen. Richtig eingesetzt können sie aber auch filigrane und fragile Ergebnisse erzeugen, z.B. Eis-Skulpturen. Was aber jedem bewusst sein muss - ca. 90 Prozent der Menschheit sollten besser keine Motorsägen bekommen, das Risiko von Unfällen wäre viel zu gross.

Warum das eine passende Analogie auf SAFe ist, dürfte klar sein. Mit dieser Methode lassen sich gut Vorhaben organisieren, die für einzelne Scrum Teams zu klein wären - und die Ergebnisse können durchaus agil sein. Da es aber sehr einfach ist, die SAFe-Regeln versehentlich oder absichlich für Hierarchie-Aufbau, Langfrist-Planung und Gross-Releases einzusetzen, ist die "Unfallwahrscheinlichkeit" sehr hoch, wenn die Beteiligten nicht genau wissen wie Agilität funktioniert.

Für den Fall, dass solche Leute nicht verfügbar sind, SAFe aber trotzdem vorgegeben ist (warum auch immer), zeigt die Werkzeug-Analogie sogar einen Lösungsweg auf: in praktisch alles Firmen, in denen mit tendenziell gefährlichen Werkzeugen und Maschinen gearbeitet wird, gibt es regelmässige (Re)Sensibilisierungsprogramme, mit denen Unfällen vorgebeugt werden soll. Eines der bekanntesten unter ihnen ist der so genannte "Near Miss".

In Near Miss-Programmen werden Mitarbeiter regelmässig (z.B. einmal pro Monat oder Quartal) aufgefordert nachzudenken, wo es zu Unfällen hätte kommen können (Near Miss bedeutet Knapp verfehlt), wie diese Situationen entstanden sind und wie man versuchen kann zu verhindern, dass sie sich nochmal ergeben. Über die individuelle Verbesserung hinaus kann man dabei durch Aggregation der Ergebnisse auch auf verbreitete Probleme und Risiken aufmerksam werden.

Auf SAFe übertragen bedeutet dass, dass regelmässig darüber reflektiert werden sollte, wo in der letzten Zeit die angestrebten kurzen Entscheidungswege, schnellen Feedback-Schleifen und häufigen Mehrwert-Auslieferungen eher behindert als befördert wurden. Ein naheliegender Zeitpunkt dafür wären die Inspect & Adapt-Events am Ende jedes PI-Zyklus, in die man das Thema als kontinuierlich wiederkehrenden Punkt integrieren könnte.

Natürlich setzt all das voraus, dass Hierarchie-Aufbau, Langfrist-Planung und Gross-Releases im Rahmen der jeweiligen SAFe-Implementierung auch tatsächlich nicht angestrebt werden. Dort wo das offen oder verdeckt doch der Fall ist, wird eine Near Miss-Routine keine Wirkung entfalten. Allerdings ist sie dann auch nicht das wichtigste Thema an dem gearbeitet werden sollte.

Hat Scrum zu viele Meetings?

Bild: Pexels / Diva Plavalaguna - Lizenz

Wenn irgendwo zum ersten mal Scrum eingeführt wird, kann man fast schon darauf wetten, dass man sich früher oder später eine bestimmte Beschwerde anhören kann: seit der Umstellung würde es viel zu viele Meetings geben, man käme jetzt "gar nicht mehr zum Arbeiten". Derartigen Äusserungen nachzugehen lohnt sich, schliesslich können sie schlimmstenfalls dazu führen, dass die ganze Methodik abgelehnt wird. Also: bringt Scrum zu viele Meetings mit sich?

Ein Blick in den offiziellen Scrum Guide bringt erste Erkenntnisse: in einem zweiwöchigen Sprint gibt es ein Planning von vier Stunden, ein Review von zwei Stunden, eine Retrospektive von eineinhalb Stunden und zehn Dailies von jeweils 15 Minuten. Optional kommt das Refinement dazu.¹ Im Durchschnitt kommt man damit auf ca. eine Stunde pro Tag, mit einem Schwerpunkt auf dem Sprintwechsel. Das macht noch nicht wirklich den Eindruck von Meeting-Overhead.

Dort, wo es zu einer Überhandnahme von Terminen kommt, muss es also andere Gründe geben. Einer, den man häufig findet, ist der, dass die Scrum-Meetings deutlich überzogen werden. Dailies dauern dann z.B. jeweils eine Stunde und die Retrospektive den halben Tag. Die Lösung in diesem Fall ist einfach: sich an die vorgegebenen Beschränkungen zu halten, reduziert Meeting-Zeit. Will man das nicht tun ist das zwar auch ok, dann sollte man sich aber auch nicht beschweren.²

Noch häufiger ist es so, dass sich die Meeting-Dichte dadurch ergibt, dass zu den in Scrum vorgegebenen Terminen noch weitere kommen. Dazu können Regeltermine gehören, wie z.B. wöchentliche Abstimmungen mit wichtigen Stakeholdern, aber auch anlassbezogene, z.B. Termine zur Erfassung oder Klärung von neuen Anforderungen. Es liegt damit kein Problem vor, dass sich aus der Methodik ergibt - aber eines, das sich mit Hilfe der Methodik lösen lässt.

Fast alles, was in diesen sonstigen Meetings abgehandelt wird, lässt sich auch in einem der Regeltermine unterbringen. Erfassung und Klärung von Anforderungen können im Refinement stattfinden, Stakeholder-Kommunikation im Review, Architektur-Diskussionen im Planning, eine Klärung von Unstimmigkeiten im Team in der Retrospektive. Geht man so vor gibt es kaum noch Themen, die ein zusätzliches Meeting brauchen - zumindest keine mit Bezug zum Produkt oder zum Scrum Team.

Was nämlich auch immer wieder auftritt, sind Termine völlig ohne Produkt- oder Teambezug, die zu den Scrum-Meetings dazukommen. Die können zu übergreifenden Organisationseinheiten gehören (z.B. wöchentliche Abteilungsrunden), sie können aber auch Teil des zweiten oder dritten Projekts sein, in dem einige oder alle Teammitglieder mitarbeiten müssen. Auch hier ist die Lösung einfach: man muss lediglich aufhören, die Mitarbeiter zu überplanen.

Zurück zur Ausgangsfrage: bringt Scrum zu viele Meetings mit sich? Die Antwort - ja, aber nur dann, wenn die neuen Termine die alten nicht ersetzen, sondern zu ihnen dazukommen, oder wenn für Themen, die in den bestehenden Meetings behandelt werden, könnten neue angesetzt werden. Die sich daraus ergebende gute Nachricht: man kann selbst dafür sorgen, dass der eigene Kalender leerer wird. Man muss es eben nur tun.

¹Eine Zeitvorgabe gibt es im aktuellen Scrum Guide nicht, häufig ist eine Stunde Refinement pro Woche
²Ausserdem ist es wenn man sich nicht an die Vorgaben hält kein Scrum mehr