Kommentierte Links (CIII)
Bild: Unsplash / Fabio Bracht - Lizenz |
Agile, Scrum, Kanban, Change Management. Und der Rest.
Bild: Unsplash / Fabio Bracht - Lizenz |
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,1 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.
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,1 wodurch in der Gesamtbestrachtung die erwähnte Vielfalt und Uneinheitlichkeit entsteht. Hier sind die häufigsten dieser Teil-Aspekte in der Übersicht.
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.
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).
An dieser Stelle verschwimmt die Rolle des Agile Coach mit der des Scrum Masters, Flow Masters2 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.
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 Mentees3 wesentlich unerfahrener sind als ihr Mentor und seinen Rat suchen.
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.4
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.
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,5 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.
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.
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.
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.
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.
Bild: National Archives / Combined Military Service Digital Photographic Files - CC0 1.0 |
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.
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.
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.1 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.2
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.