The World Depends on 60-Year-Old Code: COBOL

Heute ein etwas abseitiges Thema: COBOL. Es handelt sich dabei um eine Programmiersprache aus den 50er Jahren (!), auf der bis heute (!!) der Grossteil der Kern-Anwendungen in Banken, Versicherungen, der öffentlichen Verwaltung und vielen anderen grossen Organisationen beruht. In Coding mit Dee gibt es dankenswerterweise einen Überblick darüber was COBOL ist, und was man zu seiner Geschichte und Anwendung wissen muss.

Was mir an Dees Ausführungen besonders gefällt ist die neutrale Einordnung, samt aller Vor- und Nachteile. Sie legt Wert darauf, dass nicht die veraltete Programmiersprache selbst das Problem ist, sondern dass es stattdessen Faktoren wie fehlende Dokumentation, die Verrentung der Wissensträger und die "historisch gewachsenen" Systemstrukturen sind, die zu den Schwierigkeiten führen, über die sich bei COBOL häufig beklagt wird (und wegen denen oft behauptet wird, COBOL-Anwendungen nicht agil weiterentwickeln zu können).

Welchen Zweck haben Meetings?

Bild: Pexels / Tima Miroshnichenko - Lizenz

Wenn es ein Dauerbrenner-Thema in jeder halbwegs grossen Organisation gibt, dann sind es Meetings. Und der Tenor ist immer der selbe: es sind zu viele, sie sind zu lang, sie sind langweilig und ein Grossteil der Anwesenden kann nichts beitragen. Auf die Frage wie es besser ginge folgt dann meistens ein undifferenziertes "einfach weniger Meetings!", was aber nicht hilfreich ist. Lässt man nämlich einfach einige weg, entstehen meistens Verzögerungen oder Unterbrechungen im Informationsfluss.

Dass ein Grossteil aller Meetings gleichzeitig unerträglich und unersetzlich erscheint, ist dabei Teil des Problems - sehr viele der eingestellten Termine haben keinen inhaltlichen Focus, sondern es handelt sich um die Regelmeetings von Organisationseinheiten (die legendären Team-, Abteilungs-, Projekt- oder Technik-Runden). In ihnen wird alles abgehandelt was irgendwo gerade anliegt, mit der Folge, dass auch Nicht-Betroffene es sich anhören müssen, nur weil sie Teil der selben Organisationseinheit sind.

Da jedes dieser Themen aber für irgendeinen Zweck wichtig ist, ist ein einfaches Abschaffen keine praktikable Lösung. Zielführender ist es, diese Zwecke zu identifizieren und danach gleichartige Themen in Meetings zu konzentrieren, zu denen dann nur diejenigen eingeladen werden können, die benötigt werden oder ein Interesse haben. Bestenfalls werden die für den einzelnen Teilnehmer dadurch sowohl weniger als auch relevanter. Also: welche Kategorien könnte es geben?

Teilnehmer-Status sichtbar machen

Man mag davon halten was man will, aber Meetings können Statussymbole sein, denn in einem Führungskreis oder einer Expertenrunde eingeladen zu sein kann als Bestätigung der eigenen Bedeutung oder Expertise verstanden werden. Wenn sie nur diesen Zweck haben sind derartige Termine wenig sinnvoll aber politisch bedeutsam. Wenn man sie nicht abschaffen kann, kann man sie zumindest seltener stattfinden lassen oder verkürzen (z.B. zu einem 15-minütigen "Leadership Daily").

Berufliche Existenzberechtigung sichern

Ein weiterer etwas schräger Fall. Viele Führungsrollen (manche Manager, aber auch einige Scrum Master) laden vor allem deshalb zu Meetings ein, um sich durch deren Moderation oder durch dort festgestellte Unterstützungsbedarfe selbst Arbeit zu erzeugen, die man später als Nachweis der eigenen Mehrwertstiftung vorweisen kann. Auch das ist inhaltlich verzichtbar aber politisch heikel, ggf. müssen diese Rollen bei einer Abschaffung dieser Termine andere sinnstiftende Tätigkeiten bekommen.

Reporting und Controlling

Vermutlich der Klassiker unter den Meeting-Formaten. Irgendwer hat irgendwelche Aufgaben aus einem der letzten Termine mitgenommen und berichtet wie weit er gekommen ist. Das ist vor allem dann problematisch, wenn es in generische Meldungen wie "ich bin weiter dran" verflacht. Ein sinnvoller Umgang kann sein, nur dann einen Bericht abzugeben wenn es einen Fortschritt gibt, und den ggf. auf den Hinweis zu beschränken, dass es für alle Interessierten einen separaten Termin gibt.

Ein Ventil bieten

Auch das darf man nicht unterschätzen: für viele Menschen, die sonst weitgehend alleine arbeiten, bieten Meetings die Möglichkeit Luft abzulassen und sich Frust und Sorgen von der Seele zu reden. Diese Funktion kann durchaus hilfreich sein, es besteht aber das Risiko, dass das Ranten und Jammern alle anderen Themen überlagert. Ein sinnvoller Weg kann sein, das bewusst einzuplanen, es aber auch mit (Zeit-)Grenzen zu versehen (hier ein Beispiel dafür).

Kommunizieren

Eine der positiveren Kategorien. Meetings können genutzt werden um Informationen zu verteilen. Wichtig ist dabei, dass es sich nicht nur um Einweg-Kommunikation handelt (dann würde meistens eine Email reichen), sondern durch Nachfragen und Erklären ein besseres Verständnis möglich wird. Ebenfalls hinterfragen kann man, ob alles kommuniziert werden sollte "was gerade so anliegt" oder ob kleinere themenspezifische Termine mehr Focus und Mehrwert stiften würden.

Entscheiden

Vielleicht der idealtypische Meeting-Zweck. Während Vorarbeiten oder Informationsbeschaffung meistens dezentral und asynchron erfolgen können, ist das bei Entscheidungsfindungen (bzw. den dazugehörenden Diskussionen) nur schwer möglich. Alle Beteiligten in einen Raum oder Call zu holen, alle Argumente zu hören und eine Management- oder Mehrheitsentscheidung herbeizuführen ist der bei Weitem effektivste und effizienteste Weg damit umzugehen.

Lernen

Egal ob Retrospektive, Kaizen-Event, Post Mortem, Schulterblick oder Near Miss - es gibt eine grosse Vielfalt von Meetings die dem Thema Lernen gewidmet sind (und idealerweise auch die darauf aufbauende Arbeit an Verbesserungsschritten enthalten). Man kann auch nicht viel dagegen sagen, mit vielleicht einer Ausnahme - aus Fehlern zu lernen ohne daran zu arbeiten (oder daran arbeite zu dürfen) sie in Zukunft zu vermeiden, ist auf Dauer frustrierend. Aber das kommt zum Glück selten vor.

Zusammenarbeiten

Ein Grenzfall, da viele Menschen zwischen Meetings und "der eigentlichen Arbeit" unterscheiden. Zumindest in Kreativ- und Wissensberufen ist diese Trennung aber nicht aufrechtzuerhalten, hier kann es auch Arbeitstermine geben, in denen von Brainstorming bis Mob Programming alles Mögliche stattfinden kann. Und in Remote-Settings ist der Kalendereintrag für eine gemeinsame Arbeit an irgendetwas nicht mehr von einem Meeting zu unterscheiden.

Alleine Arbeiten

In Unternehmen mit vollen Kalendern kann auch diese ungewöhnliche Form von Terminen auftreten: in ihnen (oder in ihrem ersten Teil) findet keine Interaktion zwischen den Teilnehmern statt, stattdessen sind sie ein Blocker um alleine (aber in einem Raum mit den anderen) eine Tätigkeit zu erledigen, die dann für einen weiteren, interaktiven Teil benötigt wird. Das bekannteste Beispiel dürften die PR/FAQ-Dokumente sein, die zu Beginn jedes Meetings bei Amazon von jedem gelesen werden müssen.

Beziehungen entwickeln

Eigentlich ein Nebeneffekt, der vor allem in Umgebungen wichtig ist, in denen sich die Menschen zwischen ihren Meetings nur selten oder gar nicht sehen. Da der nachvollziebare Wunsch nach persönlichem Kennenlernen und Austauschen nicht mehr durch Kantinengespräche o.Ä. erfüllt werden kann, tauchen private Themen hier auch in beruflichen Meetings auf. Ein sinnvoller Umgang damit kann sein, spezielle Meetings nur für diesen Zweck einzurichten.¹

Anerkennung geben und Erfolge feiern

Ob Projekt-Resultate, steigende Kennzahlen oder andere Erfolge - die meisten Menschen freuen sich darüber, ihre Arbeitsergebnisse zeigen zu können, Anerkennung dafür zu bekommen oder anderen Anerkennung dafür zu geben. Auch das kann in Meetings passieren, entweder explizit mit diesem Zweck oder implizit, z.B. wenn bei Ergebnis-Präsentationen bestimmte Beiträge besonders lobend hervorgehoben werden.

Wie immer bei derartigen Aufzählungen liessen sich sicher noch weitere Kategorien finden, die wichtigsten dürften aber enthalten sein. Wie zu Beginn gesagt, sobald die Identifikation dieser Kategorien, bzw. Meeting-Zwecke stattgefunden hat, kann man bei einer Neustrukturiereung versuchen, die Meetings so zu restrukturieren, dass sie nur noch einem oder wenigen dieser Zwecke dienen, um so klarer zu machen, wer wo benötigt wird und wer nicht.

¹Was in vielen Unternehmen zu der Frage führt, ob das bezahlte Arbeitszeit ist oder nicht.

Affordanz

Bild: Pixabay / Benjamin Nelan - Lizenz

Wenn irgendwo eine Methode zur Organisation von Arbeit ausprobiert wird, und das Ergebnis nicht den Erwartungen entspricht, ist eine Aussage meistens nicht fern: die Methode selbst könne man nicht dafür verantwortlich machen, sie wäre nur ein Werkzeug. Bei anderer Benutzung hätte sie auch andere Ergebnisse gebracht. Das ist auch nicht falsch, es ist aber auch nicht völlig richtig, denn bis zu einem gewissen Grad verleiten Methoden ihre Anwender zu bestimmten Handlungen.

Der Fachbegriff für dieses Phänomen lautet Affordanz und lässt sich folgendermassen erklären: zum Gebrauch gedachte Subjekte haben Charakteristika, die bestimmte Anwendungen möglich oder unmöglich, anstrengend oder einfach und effektiv oder ineffektiv machen. Am Beispiel eines Hammers erklärt - das Einschlagen eines Nagels ist möglich, einfach und effektiv, das Eindrehen einer Schraube unmöglich, das Einreissen einer Wand möglich aber anstrengend und ineffektiv.

Auch auf die Methodenwelt lässt sich das Affordanz-Konzept übertragen, schliesslich sind auch Methoden zur Anwendung gedacht. Auch hier ein Beispiel: mit Scrum lässt sich die Arbeit eines einzelnen Software-Entwicklungsteams einfach und effektiv organisieren, der Betrieb einer Fabrik nach Scrum geht gar nicht, und im Regelbetrieb eines Call Center wäre es zwar möglich, aber durch die vielen (und in diesem Kontext unnötigen) Meetings hochgradig ineffektiv. 

Das alles scheint bisher noch wenig bemerkenswert, hat aber an einer Stelle weitreichendere Implikationen als man auf den ersten Blick denken könnte, nämlich dort, wo eine Anwendung möglich aber ineffektiv ist. Der Erfinder des Affordanzkonzepts, der amerikanische Psychologe James J. Gibson, erkannte durch seine Forschung, dass alleine die Möglichkeit einer Anwendung dazu verleitet, sie wahrzunehmen - und zwar auch dann, wenn das wenig sinnvoll ist. Mit seinen eigenen Worten:

The affordances of the environment are what it offers [...], what it provides or furnishes, either for good or ill.

James J. Gibson, The Theory of Affordances, 1979

Und mit diesem Wissen im Hinterkopf können wir die Betrachtung einer Methode als neutrales Werkzeug nicht mehr aufrechterhalten, ihr Angebotscharakter verleitet zu bestimmten Umsetzungs-Arten. Scrum bietet die Möglichkeit, sich durch harte Definitions of Ready in Wasserfall-artige Phasen aufzuteilen? Die Wahrscheinlichkeit ist gross, dass genau das passieren wird. In SAFe lassen sich bis zu drei Hierarchie-Ebenen einrichten? Mit hoher Wahrscheinlichkeit wird genau das passieren. Etc.

Um nicht missverstanden zu werden: Affordanz impliziert keine deterministische Gesetzmässigkeit, es ist also möglich, gegenzusteuern und eine unnötig schwerfällige Methodenumsetzung zu verhindern. Um das tun zu können ist es aber hilfreich, wenn man sich unterschwelliger psychologischer Mechanismen wie eben der Affordanz bewusst ist.

Der agil-industrielle Komplex (II)

Wir müssen noch einmal zu einer der unschöneren Gruppen hauptberuflicher Agilisten kommen, dem agil-industriellen Komplex. Zur Erinnerung: er umfasst Zertifizierungsorganisationen, die von Trainings-Anbietern finanziert werden, welche von Unternehmensberatungen für wirkungslose Pseudo-Transformationen instrumentalisiert werden, die wiederum von Unternehmen beauftragt werden, deren interne Prozesse eher auf schnelle Scheinerfolge als auf nachhaltige Veränderungen ausgelegt sind.

Die problematischen Auswirkungen dieser Kommerzialisierungs-Maschinerie dürften mittlerweile in allen Bereichen des agilen Arbeitens spürbar sein, hier soll es aber um eine besonders folgenschwere gehen: die Aufblähung der ursprünglisch schlanken agilen Frameworks zu umfangreichen, schwergewichtigen Regelwerken, die von ihren (oft unfreiwilligen) Anwendern eher als Belastung und weniger als Hilfe empfunden werden - und schon gar nicht als Erleichterung.

Die Hauptursache dieser Entwicklung sind einmal mehr die Zertifizierungen, die die Haupt-Einkommensquelle und den Haupt-Ergebnistyp des agil-industriellen Komplexes bilden. Der für sie zu entrichtende drei- bis vierstellige Preis muss gerechtfertigt werden, was bedeutet, dass in allen von ihnen relevantes Wissen vermittelt werden muss. Relevant wird das durch seinen offiziellen Status, und um den zu erreichen, muss das Wissensgebiet (halb-)offizieller Teil eines Frameworks werden.

Wie diese Aufblähung aussieht, kann sich von Fall zu Fall unterscheiden, der offensichtlichste Weg ist aber, möglichst viel in den offiziellen Umfang eines zu vermarktenden Vorgehensmodells aufzunehmen. Das bekannteste Beispiel dafür ist SAFe, dessen Dokumentation mittlerweile eine deutlich dreistellige Seitenzahl umfassen dürfte, auch Disciplined Agile entwickelt sich seiner Übernahme durch PMI erkennbar in diese Richtung.

Einen anderen Weg sind Scrum Alliance, Scrum.org und Kanban University gegangen, deren eigentliche Regelwerke (Scrum Guide und Kanban Guide) sind mit ca 10 Seiten noch immer sehr komprimiert. Was bei ihnen aber dazukommt ist eine grosse Menge an "offiziellem" Zusatz-Material für die sinngemässe Auslegung, Anwendung oder Einbettung in andere Kontexte (z.B. Scrum + OKRs oder Kanban + Legal), wodurch der Gesamtumfang auch hier erheblich angewachsen ist.

Eine dritte Variante Kommerz-getriebener Aufblähung kann man schliesslich bei Frameworks beobachten, die keiner Organisation zugeordnet sind, sondern gewissermassen Open Source. Hier erfinden Beratungen und Schulungsanbieter ständig neue Elemente, kopieren sie voneinander und erklären sie zur notwendigen "best Practice". Der bekannteste derartige Fall sind zur Zeit die OKRs, deren Kommerz-Variante stark mit Meetings, Rollen und Regeln überfrachtet ist.

Eine spezielle und in allen Varianten vorhandene Art der Aufblähung besteht schliesslich in Form von prozessunterstützender komerzieller Software, die im Rahmen vieler "agiler Transitionen" den Anwendern der agilen Frameworks zwingend vorgeschrieben wird (Beispiele sind Jira für Scrum oder Workboard für OKRs). Da in diesen Kontexten das Vorgehen und die Software untrennbar miteinander verknüpft sind, wird das Wissen um die Software-Funktion de facto Teil des Methodenwissens.

Wie oben erwähnt, für die Anwender ist eine derartige Aufblähung in der Regel eine Belastung. Zum einen dadurch, dass alleine die Aneignung und das in Erinnerung halten eines derartig umfangreichen Wissensumfangs mit Aufwand und Anstrengung verbunden ist, zum anderen dadurch, dass der aufbauend darauf gestaltete Arbeitsalltag von zahlreichen Pflicht-Meetings, komplizierten Regeln und restiktiven Workflows der jeweiligen Anwendungen geprägt ist.

Häufige Reaktionen auf diese Belastung sind Frustration, Dienst nach Vorschrift, der heimliche Aufbau von "Schattenprozessen", mit denen sich die ungeliebten offiziellen Methoden umgehen lassen (deren unnötige Aufblähung den meisten gar nicht bewusst ist) oder ganz einfach der Verlust von Freude an der Arbeit und der Identifikation mit dem eigenen Unternehmen. Konsequenzen deren sich jeder bewusst sein sollte, der sich mit dem agil-industriellen Komplex einlässt.

Um mit einer positiven Note zu enden: es gibt einen Ausweg aus dieser Situation, und der besteht ganz schlicht daraus, zuerst aufzuzeigen, wie die jeweiligen agilen Frameworks eigentlich gedacht sind, und was alles nicht notwendig ist um sie so wie gedacht einzusetzen. Dieser überschüssige Teil, der z.B. im Fall von Kanban oder OKRs alle (!) neu eingeführten Rollen, Meetings und Software-Tools umfassen kann, kann einfach weggelassen werden - und nur dadurch wird bereits vieles einfacher und schneller.

Natürlich braucht es auch dazu in der Regel die Unterstützung von Experten, was eine wichtige Frage aufwirft: wie lässt sich sicherstellen, dass nicht auch die dem agil-industriellen Komplex angehören? Die einfache Antwort: man sollte nur diejenigen in die nähere Auswahl nehmen, deren Lösungen werder Zertifizierungen, noch prozessunterstützende Software, noch umfangreiche Regelwerke oder zahlreiche neue Rollen enthalten. Less is more.

Who Does What by How Much?

Zwei der bekanntesten internationalen OKR-Experten sind Jeff Gothelf und Josh Seiden, die seit etlichen Jahren als Berater, Buchautoren und Konferenz-Speaker bekannt geworden sind. Für die Agile India Conference haben sie nicht nur ihre Sicht auf das Thema OKRs zusammengefasst, sondern sind in einer darauf folgenden Diskussion auch auf verschiedene weiterführende Aspekte eingegangen, wodurch ihre Sicht auf dieses Thema nochmal besser nachvollziehbar wird.

Was man beim Ansehen des Videos im Hinterkopf behalten sollte: es gibt nicht die eine richtige Art OKRs zu verfassen, sondern viele verschiedene Varianten, die parallel nebeneinander koexistieren (siehe hier). Gothelf und Seiden haben starke (und fundierte) Meinungen, und das was sie sagen dürfte dem State of the Art entsprechen. Andere Umsetzungen sind aber nicht falsch - nur anders.

Kommentierte Links (CXVII)

Grafik: Pixabay / Geralt - 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.

Jeff Gothelf: How to build a high-performance culture without culling the herd

Um zu zeigen, wie man zu einer Hochleistungskultur kommt, kann es schon ausreichen, das Gegenteil zu beschreiben - und genau das tut Jeff Gothelf in seinem Artikel zunächst. Förderung von konkurrierenden Einzel-Leistungen, eine Angstkultur durch ständige Kündigungs-Androhungen und ein Nicht-Einschreiten gegen toxisches Management-Verhalten können jede Leistungbereitschaft nachhaltig zerstören. Umgekehrt sind eine Belohnung guter Zusammenarbeit, ein respektvoller Umgang mit den Mitarbeitern und die Beförderung entsprechend handelnder Menschen in Management-Positionen hochgradig förderlich für Hochleistungen. Eigentlich sollten alle Punkte dieses Artikels Selbstverständlichkeiten sein.

Nick Brown: Escaping Story Points with Right-sizing

Ich muss gestehen, dass mich die vor allem im Kanban-Umfeld anzutreffende Community, die an der durch historische Daten unterfütterten Prognose von Umsetzungsdauern arbeitet, zutiefst fasziniert. Hier ist alles gegeben, was man sich als überzeugter Agilist wünscht: empirisches Vorgehen, differenzierte Einschätzungen, Visualisierung von Daten, Wiederholbarkeit und Nachvollziehbarkeit des Vorgehens, etc. Und jemandem wie Nick Brown nimmt man es auch ab, dass er mit voller Überzeugung hinter dem steht was er hier schreibt. Das Einzige was mir noch fehlt, damit aus Faszination Begeisterung wird - ich möchte es einmal funktionieren sehen.

Charles Lambdin: A Persona How-To

Personas gehören zu den sinnvollsten Werkzeugen, die man bei der Produktentwicklung benutzen kann, vor allem dort wo echte Anwender nur schwer zu erreichen sind. Das Risiko dabei ist aber, dass diese Beschreibungen idealisierter Nutzer zu sehr auf Bauchgefühl beruhen und damit kognitiven Verzerrungen unterliegen. Charles Lambdig zeigt auf wie es besser geht, indem er einen mehrstufigen Prozess modelliert, in dem nach und nach aus Marktforschungsdaten validere Personas entstehen. Das ist natürlich aufwändiger als blosses "Empathiesieren", bringt aber auch deutlich bessere Ergebnisse.

Matt Philip: Team size is a polarity to be managed, not a problem to be solved

Im Grunde sagt die Überschrift dieses Blogposts von Matt Philipp alles Wichtige bereits aus: die Grösse eines Teams (egal welche das ist) ist erstmal weder gut noch schlecht, selbst wenn das in der agilen Community mit ihrer Fixierung auuf Teamgrössen von fünf bis zehn Personen mehrheitlich anders gesehen wird. Sein pragmatischer Ansatz besteht (verkürzt gesagt) aus drei einfachen Fragen, die man sich stellen kann: welche Vorteile bringt mir eine bestimmte Teamgrösse, welche Nachteile bringt sie mir, und in welcher Relation stehen diese beiden Zahlen zueinander. Ein wunderbarer Weg um diese Diskussion zu versachlichen und neutral bewertbar zu machen.

Melissa Suzuno: Why Ramsey Solutions Rotates Engineers in Their Product Trios

Als letztes noch ein weiterer Kontrapunkt zu einer verbreiteten starken Meinung - der, dass erfolgreiche (agile) Teams über einen möglichst langen Zeitraum stabil (d.h. in ihrer Zusammensetzung unverändert) bleiben sollten. Am Beispiel eines echten Unternehmens zeigt Melissa Suzuno auf, dass sogar das Gegenteil richtig sein kann, wenn es einen Zweck gibt, der sich so am besten erreichen lässt. Auch hier wieder - eigentlich eine Selbstverständlichkeit. Eigentlich.

1000

Es ist eine Zahl, die mir selber extrem unwirklich vorkommt, aber hier ist sie: dieser Eintrag ist der tausendste, den ich auf dieser Seite schreibe. Immerhin verteilt über fast zehn Jahre, aber auch das ist eine Zahl die leicht surreal wirkt. Rechnet man beides zusammen kommt man auf über 100 Einträge pro Jahr, und nochmal tiefer heruntergebrochen auf einen bis drei pro Woche. Seit Anfang 2015 hat es keine Woche gegeben, in der ich nicht mindestens einen veröffentlicht habe.

Was mich im Rückblick fast am meisten erstaunt ist dabei, dass mir nicht irgendwann die Themen ausgegangen sind (als ich losgelegt habe war ich mir nicht einmal sicher, dass ich genug Stoff für ein Jahr haben würde). Da praktisch alles, was ich aufgeschrieben habe, in irgendeinem Bezug zu meinem Beruf steht, ist auch das eine Erkenntnis - er ist so vielfältig und abwechselungsreich, dass sich aus ihm eine praktisch unbegrenzte Menge an Texten generieren lässt.

Dabei ist es übrigens nicht so, dass ich eine Art "Redaktionsrhythmus" habe, und immer zu bestimmten Zeitpunkten schreibe (die einzige Ausnahme sind die am Ende jedes Monats erscheinenden Kommentierten Links). Zum Teil findet das Verfassen (ganz oder in Teilen) mit zeitlichem Vorlauf statt, zeitweise können über 10 fertige Texte in der Pipeline stehen. Zum Teil sind die Themen aber auch solche, die mir erst am Tag der Veröffentlichung eingefallen sind. Das kann stark schwanken.

Da ich manchmal gefragt werde - was ich nicht habe, sind genaue Statistiken zu den verschiedenen Einträgen. Weder zur durchschnittlichen Länge (irgeneine vierstellige Zeichenzahl), noch zur Verteilung der Themengebiete (wie oben zu lesen - fast immer geht es um: Agile, Scrum, Kanban, Change Management. Und den Rest.), noch zu den durchschnittlichen Aufrufzahlen (ich weiss nur, dass der populärste Text über 16.000 Views hat). So wichtig sind diese Zahlen aber für mich auch nicht.

Ich lasse diese Zahl jetzt erstmal sacken. Ob es irgendwann 2000 Einträge werden? Keine Ahnung, vom Gefühl her nicht. Auf der anderen Seite - als ich losgelegt habe, bin ich nicht davon ausgegangen, dass es mal 1000 werden könnten. Mal sehen.

Tight Loose Tight

Eine der Besonderheiten der agilen Community sind die "Insider-Hypes", die von Zeit zu Zeit aufkommen. Es handelt sich dabei um in der breiten Öffentlichkeit eher unbekannte Frameworks, Praktiken und Methoden, die unter Agile Coaches und Scrum Mastern aber eine Zeit lang als "heisser Geheimtip" gelten, bevor sie irgendwann wieder in der Versenkung verschwinden. Einer dieser Insider-Hypes der letzten Jahre ist ein Management-Framework namens Tight Loose Tight.

Für einen Hype ist Tight Loose Tight dabei relativ alt, es wurde bereits um das Jahr 2000 herum von der amerikanischen Unternehmensberatung Mercer Delta erfunden (siehe hier). Formalisiert und popularisiert wurde es dann ab ca 2010 von dem Norweger Rune Ulvnes, was mittlerweile zu dem verbreiteten Missverständnis geführt hat, es handele sich um eine "Führungsmethode aus Norwegen". Aber unabhängig von ihrem Ursprung - was ist das eigentlich?

Liz Guthridge, eine Unternehmensberaterin, die den Ansatz schon vor über 20 Jahren bei Mercer Delta kennengelernt hat, beschreibt seine drei Bestandteile so:

• Tight for purpose and goals: The organization’s executive team set the purpose and goals and tightly controlled them.
• Loose for execution: The business units and functions had autonomy in how they implemented and delivered on the goals, often under resource constraints from the executive team.
• Tight for results: The executive team also defined and measured the results they expected.

Oder mit anderen Worten: einer klaren Zielsetzung folgt eine möglichst grosse Freiheit bei der Umsetzung, gefolgt von einer genauen (und möglichst empirischen) Überprüfung, ob das Ergebnis tatsächlich erreicht wurde. Tight steht dabei für enge Führung, Loose für Delegation und Autonomie.

Rune Ulvnes hat diese Grundstruktur weitgehend übernommen, ihr aber zusätzliche Elemente hinzugefügt. Die Execution-Phase ist bei ihm nochmal unterteilt in Sprints von ein bis vier Wochen, und nach ihnen erfolgt jeweils Feedback zu Umsetzbarkeit, Zielgruppenakzeptanz und anderen Aspekten an das Management, das basierend darauf seine Zielsetzungen anpassen kann. Die Anlehnung an Scrum mit seinen Sprints, Sprint Reviews und Retrospektiven ist hier sehr offensichtlich.

Was ausserdem zur "norwegischen Variante" gehört ist eine Einordnung in ein Raster, in dem anhand der beiden Variablen der Verantwortungs-Delegation und der Arbeitsteiligkeit vier Extremtypen identifizierbar sind: das Steve Jobs-artige Genie mit dem Führungsstil tight tight tight, die nur auf Ressorcen-Optimierung konditionierte Führung mit dem Stil loose tight loose, die Feature Factory mit dem Führungsstil loose loose loose und ein agiles Vorgehen mit dem Führungsstil tight loose tight.

Jede dieser Zuordnungen kann zwar für sich genommen kritisch hinterfragt werden, löst man sich aber von den (in diesem Zusammenhang z.T. nicht unproblematischen) Begrifflichkeiten, kann das Raster ein durchaus sinnvolles Werkzeug sein, anhand dessen man sowohl eine Analyse des Ist-Zustandes als auch eine kontinuierliche Überprüfung der Bewegung zum angestrebten Zielzustand (in diesem Fall in der rechten oberen Ecke) durchführen kann.

Wie so oft bei derartigen Denkmodellen kann die Bewertung weit auseinandergehen, von "ein Augenöffner" bis hin zu "ist doch total banal" habe ich über Tight Loose Tight schon alles Mögliche gehört. Ich würde es aber so sehen: wem das Ganze nichts bringt, der kann es ignorieren, wem es hilft, der kann es benutzen. Und wer in der agilen Community an seinem Status als Thought Leader arbeiten will, der kann auf diesen Insider-Hype aufspringen, und damit sogar Anderen etwas Gutes tun. Also nur zu.

Podcasting (IV)

Bild: Pexels / Fox1004 -

In letzter Zeit bin ich mal wieder "ausser Haus unterwegs gewesen". Genauer gesagt durfte ich in den letzten beiden Monaten in zwei Podcasts zu Gast sein, zuerst bei Agile Soul von Susanne Jung und Tim Müller (aus dem Gespräch sind sogar gleich zwei Folgen entstanden) und danach in einem zweiten mit dem schönen Namen No Bullshit Agile.

Bei Tim und Susanne ging es um das Thema Veränderungsmüdigkeit oder Change Fatigue, ein Phänomen das dort auftritt, wo Menschen das Gefühl haben, in unnötige oder unnötig häufige Veränderungs-Programme hineingezogen zu werden. Wir sind dabei auf verschiedene Aspekte eingegangen: was das ist, welche verschiedenen Ausprägungen es gibt, wie es entsteht, wie man damit umgehen kann und inwiefern man als Change Agent selbst davon betroffen sein kann.

In No Bullshit Agile habe ich mit dem Host Thomas über die Agilität im grossen Massstab gesprochen, und darüber wie sich die Arbeit an diesem Thema von der auf Teamebene unterscheidet. Dabei sind wir nur sehr kurz auf die Skalierungsframeworks wie LeSS oder SAFe eingegangen, im Mittelpunkt stand eher, wie man grundlegende Rahmenbedingungen schaffen kann, und in welchen Bereichen das überhaupt nötig ist (Budgeting, Compliance, etc).

Ein Bild sagt mehr als 1000 Worte (XLIV)

Bild: Comic Agile - CC BY-NC 4.0

Falls jemand mit diesem Bild noch wenig anfangen kann, da er den Begriff des "Team Cognitive Load" nicht kennt - Matthew Skelton und Manuel Pais. die Erfinder der Team Topologies, haben das Thema in diesem Artikel hier sehr gut erklärt.

Goodhart's Law

Zu dem Bild über diesem Text gibt es folgende Legende: in einer Schulung verteilte der Dozent Plastikröhren und Tennisbälle an die Teilnehmer und forderte sie auf, möglichst viele Bälle in eine der Röhren zu stecken. Das Ziel dieser Übung war es, Kapazitätsgrenzen zu erkennen. Irgendetwas lenkte den Dozenten dann aber kurz ab, und als er sich wieder den Teilnehmern zuwandte war es geschehen - sie hatten die Bälle zerschnitten um sie besser stapeln zu können. Übung erfolgreich, Bälle kaputt.

Was meistens mit dieser Geschichte verdeutlicht werden soll, sind die praktischen Auswirkungen eines Erfahrungswertes, der den Namen Goodhart's Law trägt, benannt nach Charles Goodhart, der ihn erstmals 1975 in seinem Aufsatz Problems of monetary management : the U.K. experience veröffentlichte. Er lautet im Original "Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes", wurde aber später zur heute bekannten Form vereinfacht:

"When a measure becomes a target, it ceases to be a good measure"

Goodhart's Law

Um dieses Gesetz zu verstehen, müssen wir kurz ausholen: wenn versucht wird, unübersichtliche, komplexe oder vernetzte Systeme oder Abläufe zu verändern, stösst man fast immer auf das selbe Problem - es ist nur schwer zu erkennen, ob die Veränderung auch wirklich eintritt, da die dafür notwendigen Informationen verteilt, abstrakt oder nur im Zusammenhang verständlich sind. Um trotzdem zu Erkenntnissen zu kommen, definiert und überprüft man meistens bestimmte Kennzahlen.

Welche das sind ist je nach Kontext unterschiedlich. In der Produktion können das Stückzahlen gefertigter Güter sein, in der Werbung Reichweiten, in der Politik Beliebtheitswerte, in der Unternehmensführung Gewinnsteigerungen, etc. Ihnen allen ist gemeinsam, dass sie die Wirksamkeit von Veränderungs-Programmen wahrnehmbar machen können, gleichzeitig aber auch, dass sie mit Vorsicht betrachet werden sollten. Der Preis für ihre Erstellung ist nämlich die Ausblendung anderer Informationen.

Produktivitätssteigerungen können z.B. Überproduktion und Marktübersättigung zur Folge haben, Reichweite und Beliebtheitswerte können im wahrsten Sinn des Wortes durch Werbekampagnen teuer erkauft sein und Gewinnsteigerungen können auf die Einsparung von Qualitätssicherungs-Massnahmen zurückgehen. Diese (und viele weitere) Zusatzinformationen sind für das Gesamtverständnis elementar, werden aber bei blosser Kennzahlen-Betrachtung unsichtbar.

Wenn jetzt der von Goodhart erwähnte Kontrolldruck einsetzt, der nur noch das Ziel hat, die definierten Kennzahlen zu verbessern, dann ist eine sehr häufige Folge die, dass das auf Kosten der Bereiche stattfindet, die durch die Kennzahlen-Fixierung unsichtbar geworden sind. Besonders wenn mit der Erreichung der Kennzahlen Geld verbunden ist (Bonus, Beförderung, o.ä.), kann es sogar dazu kommen, dass Schäden am Gesamtsystem dabei bewusst in Kauf genommen werden.

Dieses erschreckend häufige Phänomen ist es, dass Charles Goodhart zur Verfassung seiner "Gesetzmässigkeit" gebracht hat, die sich darum auch so formulieren liesse: Wenn aus einem unübersichtlichen, komplexen oder vernetzten System einzelne Kennzahlen herausgelöst und unter Optimierungsdruck gesetzt werden, dann sind Schäden am Gesamtsystem sehr wahrscheinlich. Das trifft sowohl im Grossen (Unternehmen) als auch im Kleinen (Tennisbälle, siehe oben) zu.

Daraus ergibt sich auch automatisch, wie es besser ginge: statt zu versuchen, nur einzelne Werte zu verbessern und alles andere weitgehend zu ignorieren, sollte immer das grosse Ganze im Blick bleiben, mit allen seinen Zusammenhängen, Abhängigkeiten und Dynamiken. Dabei können Kennzahlen hilfreiche Indikatoren sein, aber eben nicht mehr als das. Es ist sogar ok an ihrer Optimierung zu arbeiten, aber nur bei Mitberücksichtung von Kontext und Seitenauswirkungen. Dann tritt Goodhart's Law nicht ein.

Nachtrag:

Grafik: xkcd - CC BY-NC 2.5

Agile Success Stories: Side Project Time

Karte: Open Street Map - CC BY-SA 2.0

Weiter geht es mit den "agilen Erfolgsgeschichten". Der Grund für ihre Veröffentlichung bleibt der gleiche: wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen, und schlimmstenfalls eine negative Weltsicht entwickeln. Wer sich die durch agile Praktiken und Methoden erzielten Erfolge und Fortschritte vergegenwärtigt, wird sich dagegen leichter damit tun, erfolgreich für sie zu werben.

Zu den Mythen die seit einiger Zeit durch die Arbeitswelt wabern, gehört der, dass Silicon Valley-Firmen (vor allem Google) ihren Mitarbeitern angeblich 20 Prozent ihrer Arbeitszeit zur freien Verfügung stellen, und dass zentrale Produkte wie Adsense und Google News in dieser Zeit "selbstorganisiert entstanden" sind. Zum Wahrheitsgehalt dieser Aussagen findet man unterschiedliche Aussagen, wahr ist aber, dass viele Firmen inspiriert davon ihren Mitarbeitern eine ähnliche, so genannte "Side Project Time" gewähren.

Eine dieser Firmen durfte ich eine Zeit lang begleiten. Die Zeit, die den Entwicklern hier für selbstgewählte Nebenprojekte (→ Side Projects) zur Verfügung stand, war vier Stunden pro Woche, plus längeren Zeiträumen für die in den Ferien arbeitenden Rumpfteams. Die Sinnhaftigkeit dieser Regelung wurde von anderen Abteilungen regelmässig in Frage gestellt, was irgendwann dazu führte, dass die Ergebnisse aller derartigen Seitenprojekte gesammelt und zur Überprüfung veröffentlicht wurden.

Angesichts der Grösse von mehreren hundert Entwicklern war natürlich ein gewisser Anteil an Unsinn dabei, wie z.B. ein Chatbot, der auf alle Fragen zu Konkurrenzunternehmen mit wüsten Beschimpfungen antwortete, oder ein Zufallsgenerator für die Erstellung möglicht absurder User Stories, es gab aber auch einige Ergebnisse, die auch den grössten Kritikern Respekt und Anerkennung abnötigten, und dafür sorgten, dass die Side Project Time erhalten blieb.

Einige Entwickler hatten sich z.B. gemeinsam der Aufgabe verschrieben, die technischen Probleme zu beseitigen, die bis dahin dazu geführt hatten, dass ein Grossteil der Meetings deutlich verspätet begonnen hatte. Als Lösung hatten sie jeden Meetingraum mit einem Computer versehen, der fest mit Beamer und Internet verbunden war und einen eigenen Videoconferencing-Account hatte. Ab da musste man nur den Raum betreten, den Rechner anschalten, und es konnte losgehen.

Ein Team hatte eine Intranet-Website gebaut, auf der alle, die sich dort anmeldeten, zu nach Zufallsprinzip erstellten Mittagessens-Verabredungen zusammengebracht wurden. Auf diese Seite entstanden Bekanntschaften kreuz und quer durch das ganze Unternehmen, wodurch abteilungübergreifende Zusammenarbeit und die Suche nach Ansprechpartnern für selten behandelte Themen deutlich vereinfacht und beschleunigt werden konnten.

Eine weitere Gruppe hatte ein Wiki zu den Kantinen, Restaurants und Imbissbuden der Umgebung aufgesetzt, mit Informationen zu Auswahl und Qualität, aber auch zu Stosszeiten, Geschwindigkeit der Bedienung und der Möglichkeit zu bargeldlosem Bezahlen. Das durch Umfragen festgestellte Ergebnis waren kürzere Mittagspausen, in denen gleichzeitig aber mehr Zeit für Essen und Unterhaltungen zur Verfügung stand als vorher.

Das (intern ) bekannteste Ergebnis erzielte aber das Nebenprojekt, in dem einige Entwickler im Firmen-eigenen Auslieferungslogistik-Leitsystem das für betriebliche Anwendungen kostenpflichtige Google Maps durch das kostenlose Open Street Maps ersetzt hatten. Besonders ein Feature erregte Aufsehen: ein Dashboard, mit dessen Hilfe man für beliebige Zeiträume überprüfen konnte, wieviel Geld durch die Ersetzung von Google Maps gespart worden war - er waren auf Dauer erhebliche Summen.

Wass all diese Side Projects gemeinsam hatten, entsprach genau den Gründen, wegen denen ihnen selbstorganisiert abrufbare Zeit eingeräumt worden war: sie wären im Rahmen des offiziellen Priorisierungsverfahren niemals auf den Roadmaps der Teams gelandet, sie lösten konkrete Probleme, mit denen die Entwickler regelmässig zu kämpfen hatten, und sie sorgten in erkennbarem Ausmass für Effektivitätssteigerungen, Kostenersparnisse und höhere Mitarbeiterzufriedenheit.

Ein Manager fasste es irgendwann passend zusammen: "Sich darauf einzulassen war am Anfang ein Wagnis, und ein bisschen unheimlich ist es mir bis heute. Aber wenn ich mir die Ergebnisse ansehe, dann kann ich gar nicht anders, als dafür sein, dass wir das weitermachen - und das selbst dann, wenn wir auch die nicht so gut verlaufenden Nebenprojekte in die Gesamtbetrachtung mit einbeziehen." Sehr viel besser kann man es vermutlich nicht formulieren.

Continuous Improvement at Scale

Agile Produktentwiclung hat sich weitgehend etabliert, agiles Change Management ist im Vergleich dazu noch eher selten. In beiden Bereichen besteht eine der grössten Herausforderungen aber darin, das Ganze nicht nur mit einzelnen Teams durchzuführen, sondern in grossem Massstab. Dabei gibt es bereits vielversprechende Ansätze, und einige aus dem Bereich des agilen Change Management stellt Chris Stone in diesem Vortrag vor.

Zum besseren Verständnis muss man Change Management dabei differenzieren: gemeint ist hier nicht, eine im Voraus gefasste und nicht veränderbare Entscheidung umzusetzen, sondern im Rahmen des Prozesses Änderungsbedarfe zu erkennen und Lösungsansätze zu testen. Vor allem in diesem Umfeld werden die hier vorgestellten Ansätze funktionieren.

Kommentierte Links (CXVI)

Grafik: Pixabay / Geralt - 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.

Carlos Arguelles: How Amazon and Google view CI/CD in an entirely different way

Je weiter man vom Silicon Valley entfernt ist, desto mehr neigt man dazu, die dortigen grossen agilen Vorzeigefirmen zu glorifizieren und zu mystifizieren. Carlos Arguelles' Erfahrungsberichte aus seiner Zeit bei Amazon und Google wirken in diesem Zusammenhang wie ein Realitätsschock, schliesslich beschreiben sie, dass in beiden Unternehmen Vorgehensweisen verbreitet sind, die eigentlich nicht State of the Art sind - geringe Testabdeckung bei Amazon, Flaky Tests bei Google. Die sehr unterschiedlichen Wege zur Kompensierung dieser Probleme zeigen, dass es nicht nur einen Weg zu technischer Exzellenz gibt. Es gibt mehrere, die nur in sich konsistent sein müssen.

Vladimir Kalmykov: How to Use an MVP Razor to Build Features

Die Dabatte darüber, was eigentlich ein MVP ist, ist Jahrzehnte alt und wird vermutlich noch Jahrzehnte weitergehen. Und selbst wenn man sich auf eine der vielen Varianten festgelegt hat bleibt die Frage, wie man in der Praxis Anforderungen und Systeme so schneiden kann, dass das Ergebnis (im positiven Sinn) "minimal" ist. Vladimir Kalmykov führt zu diesem Zweck das Ausschlussmodell des "MVP Razor" ein, das aus einer schlichten Frage besteht: "Kann man das Produkt oder Feature noch stärker verkleinern, ohne seine Grundfunktionalität einzuschränken?" Das scheint zunächst banal, anhand anschaulicher Beispiele zeigt Kalmykov aber auf, dass mehr dahinter steckt als man zunächst denken könnte.

David Pereira: 12 Product Principles

Zu den Büchern in meinem immer länger werdenden "Lese-Backlog" gehört auch Untrapping Product Teams von David Pereira, über das ich schon viel Gutes gehört habe. In diesem Artikel greift er einen zentralen Inhalt seiner Buches auf, die 12 Produkt-Prinzipien. Aufgeteilt in die vier Kategorien Strategy, Discovery, Delivery und Collaboration ergeben sie ein kompaktes Set an Leitprinzipien, die einem Team dabei helfen können, nicht versehentlich in eines der verbreiteten Antipattern abzurutschen. In einem an den Artikel angehängten Kurzinterview durch Paweł Huryn werden sie danach noch weiter vertieft und eingeordnet. Vielleicht sollte ich die Reihhenfolge meiner noch ungelesenen Bücher ändern.

Adrian Baker: Agile and deadlines - How to align Agile delivery with long-term planning

Zu den verbreiteten Mythen über agiles Arbeiten gehört, dass es nicht in Kontexten funktioniert, in denen es Deadlines und feste Planungshorizonte gibt. Adrian Baker entkräftet dieses Vorurteil nachhaltig, indem er eine ganze Reihe von Ansätzen aufzählt, mit denen es doch gelingen kann. Was seine Ausführungen von vielen anderen abhebt: statt sich in wolkige Richtlinien und abstrakte Konzepte zu flüchten, hebt er konkrete Praktiken und Funktionen aus Scrum, SAFe, XP, Day One und (Huch!) Jira hervor, die man zu diesem Zweck nutzen kann. Das ist Praxisnähe im besten Sinne des Wortes, selbst wenn es bei dem einen oder anderen "agilen Puristen" zu Herzrasen führen mag.

Itamar Gilad: The Lifecycle of Goals - Research, Discover, Deliver, Monitor

Zum Abschluss einige Gedanken zum Thema Zielsetzungen. Anders als oft angenommen sind die in der (agilen) Produktentwicklung nicht zwangsläufig fix und unveränderbar, sondern sie können (und müssen) sich mit der Zeit ändern. In Analogie zu den Produkt- und Projekt-Lebenszyklen entwirft Itamar Gilad hier den Lebenszyklus der Entwicklungsziele, in dessen Verlauf sie nach und nach ihre Natur ändern. Der Begriff des "Moving Target" bekommt dadurch nochmal eine neue Bedeutungs-Dimension.

The Agile Bookshelf: Kritik der grossen Geste

Bild: Wikimedia Commons / Romanist Dewiki - CC BY-SA 4.0

Zu den Problemen agiler, digitaler und sonstiger Unternehmenstransformationen gehört, dass sie kaum wissenschaftlich erforscht sind, da die meisten Firmen sich aus Sorge vor Wettbewerbern und Industriespionen nach aussen abschotten. Zum Glück gibt es aber andere, besser erforschte Transformationsprogramme, aus deren Erforschung man Rückschlüsse auf die Wirtschaft ziehen kann, zum Beispiel politisch-gesellschaftliche.

Mit derartigen politisch-gesellschaftlichen Transformationen beschäftigt sich das Buch Kritik der großen Geste - Anders über gesellschaftliche Transformation nachdenken des Soziologie-Professors Armin Nassehi. Sein Untersuchungsgegenstand sind die grossen Veränderungsprogramme der Regierungen, z.B. zur Eindämmung des Klimawandels oder zur Wiederaufrüstung. Die von ihm beschriebenen Effekte und Dynamiken lassen sich aber auch auf andere Themengebiete übertragen.

Eine der bemerkenswertesten Thesen des Buches ist die, dass Veränderungswiderstand oft erst durch die Veränderungsprogramme entsteht. Diese setzen an einem irgendwie unbefriedigenden Ist-Zustand an, müssen zu dessen Überwindung aber zuerst eine Bestandsaufnahme machen, um danach entscheiden zu können, was geändert werden soll. Dass erst dadurch anderen Menschen bewusst wird, wie der Ist-Zustand funktioniert, und was sie an ihm erhaltenswert finden, entbehrt nicht einer gewissen Ironie.

Eine weitere Beobachtung Nassehis, von der sein Buch auch ihren Namen hat, besteht darin, dass in grossen Transformationsprogrammen Zielverschiebungen stattfinden können. Um öffentlichkeitswirksam für die eigene Sache zu werben, werden eingängige Slogans und starke Bilder gesucht und kommuniziert, was dazu führen kann, dass unverhältnismässig viel Zeit und Energie in diese Tätigkeiten fliessen und im Folgenden der eigentlichen Veränderungsarbeit nicht mehr zur Verfügung stehen.

Gleichzeitig führt diese Art der grossen Botschaften schnell zu Vereinfachungen, zur Ausblendung komplexer Realitäts-Aspekte und zu moralischen Aufladungen, was fast schon zwangsläufig Widerstand erzeugen muss: wer auf inhaltliche Unstimmigkeiten und Umsetzungsprobleme hinweist wird (bewusst oder unbewusst) als unmodern, unverständig oder ähnliches eingeordnet, was bei denen die davon betroffen sind das Gefühl erzeugt, ungerecht und willkürlich behandelt zu werden.

Zuletzt leidet auch die Umsetzung der Veränderungsvorhaben unter der grossen Geste, mit der ihnen eigentlich zum Erfolg verholfen werden soll. Die zur besseren Verständlichkeit und Kommunizierbarkeit stark vereinfachten Lösungsansätze scheitern an der vernetzten und vielschichtigen Realität, gleichzeitig sind für differenzierte, evolutionäre oder lokal unterschiedliche Vorgehen kaum Ressourcen vorgesehen (und wenn doch werden sie oft als Abweichung vom grossen Ziel angesehen und bekämft).

Diese und andere Folgeerscheinungen gross angelegter und kommunizierter Transformationsprogramme kann man Nassehis Buch entnehmen. Nicht alles ist auf Unternehmens-Transformationen übertragbar, die Auswirkungen fehlgeleiter Veränderungsprogramme auf das Wahlverhalten der Menschen oder die Tendenz, im Kapitalismus die Ursache aller Probleme zu sehen, dürften z.B. in der Wirtschaft kaum eine Entsprechung haben. Gleichzeitig findet man aber auch viele Parallelen.

Absolut übertragbar ist auf jeden Fall die Idee, wie Veränderungen besser funktionieren können: dezentral, pragmatisch, praxisnah und sich immer wieder an die aktuellen und lokalen Gegebenheiten anpassend. Oder in Nassehis Worten: als "konkrete Gegenwarten, die je ihre eigenen Probleme lösen müssen." Dadurch ist zwar eine grosse und umfassende Mobilisierung möglichst aller Beteiligten und Betroffenen nicht mehr möglich, die Erfolgsaussichten sind dafür aber erheblich grösser.

Allen, die vor dem manchmal etwas gestelzten Sprachgebrauch der deutschen Wissenschaft nicht zurückschrecken, kann man die Kritik der grossen Geste nur empfehlen. Es ist ein interessanter Blick über den Tellerrand, der dabei helfen kann, Transformationsprogramme in Wirtschaft und Gesellschaft besser zu verstehen und ggf. auf eine zielführendere Art aufzusetzen als das üblicherweise der Fall ist.

Spät auftretende Verspätungen

Bild: Rawpixel - CC0 1.0

Es ist eines der Phänomene, mit denen man hochrangige Manger so wahnsinnig machen kann wie mit kaum einem anderen, und gleichzeitig ist es erstaunlich häufig: es geht um Projekte, von denen lange Zeit behauptet wird, dass sie im Plan liegen, in denen aber kurz vor dem geplanten Ende auf einmal erhebliche Verspätungen entstehen. Wer verstehen will, wie es meistens zu diesem Ärgernis kommt, kann es sich an einem bekannten Beispiel erklären lassen - den Zügen der Deutschen Bahn.

Regelmässige Zugreisende kennen sehr ähnliche Abläufe: vor dem Beginn ihrer Reise, z.B. von Bonn nach Köln, überprüft man in der App den Reiseplan, und der Zug ist pünktlich. Auf dem Weg zum Bahnhof nochmal, noch immer keine Verspätung. Eine Viertelstunde vor der geplanten Abfahrt empfängt man die erste kleine Verzögerungsmeldung von fünf Minuten, aus denen werden bald 10, dann 15, dann 20 ... irgendwann fährt der Zug schliesslich mit 45 Minuten Verspätung ein. Was ist da passiert?

Die vom freundlichen Schaffner durchgegebene Erklärung lautet, dass es kurz vor dem Bahnhof eine grössere Baustelle gibt, wegen der die Gleise nur langsam befahrbar sind. Dadurch verspätet sich irgendwann der erste Zug des Tages. Der zweite Zug muss hinter ihm halten und warten bis die Gleise frei sind, und danach auch langsam weiterfahren. Hinter dem wartet der dritte, bevor auch er verlangsamt weiterfährt, hinter dem der vierte, und je mehr es werden, desto mehr Verspätung kommt zusammen.

Jetzt kommt der entscheidende Punkt: bis zu diesem Stau auf den Gleisen sind alle dort feststeckenden Züge pünktlich gewesen. Sie haben diese Stelle in der selben Zeit erreicht, die nötig gewesen wäre, wenn die gesamte Strecke frei befahrbar gewesen wäre. Und da nur der aktuelle Streckenstand überprüft wird um die Pünktlichkeit zu ermitteln, kommt es ab dort zum genannten Phänomen: bis kurz vor Bonn sind alle Züge pünktlich, sammeln auf den letzten Metern aber noch erhebliche Verspätungen an.

Die Parallelen zu Grossprojekten dürften offensichtlich sein: auch die passieren oft ein Stage- oder Quality-Gate nach dem nächsten in Time und in Budget, bis sie gegen Ende durch eines müssen, das viel mehr Zeit beansprucht als ursprünglich angenommen (häufig sind das Integration, QA, Rollout oder Inbetriebnahme). Und das Verrückte daran: Obwohl diese Verzögerungen absehbar sind, sind bis zu ihrem Eintreten alle Ampeln grün - schliesslich ist bis dahin noch alles im Zeitplan.

Der Weg es besser zu machen ist bei Zügen und Projekten der Gleiche: sobald absehbar ist, dass es in einem späteren Abschnitt zu Verspätungen kommen wird, müssen diese mit ihrem voraussichtlichen Wert zu der aktuellen Pünktlichkeits-Vorhersage addiert werden, auch (und gerade) dann, wenn bisher alle Zwischenziele dem Zeitplan entsprechend erreicht wurden. Nur dann hat die Pünktlichkeitsmessung überhaupt irgendeine Aussagekraft und Verwendbarkeit.

Eine wichtige Voraussetzung dafür, dass das passiert, ist übrigens, dass derjenige, der Verspätungen meldet, nicht dafür bestraft wird. Ist das doch der Fall, ist das für alle Beteiligten der frühen Phasen ein handfester Anreiz, nur Pünktlichkeitsmeldungen durchzugeben und die Verspätungsmeldung irgendwem möglichst weit hinten auf der Strecke zu überlassen. So entstehen aufgrund falscher Anreizgebung Wassermelonen-Projekte und Arschkarten-Lücken (mehr dazu hier).

Wenn derjenige, der die absehbar näherkommende Verspätungsursache meldet, nicht dafür bestraft wird, können bestenfalls noch Gegenmassnahmen ergriffen werden, schlimmstenfalls kann man aber zumindest die Verspätung mit ausreichendem Vorlauf kommunizieren. Den an der nächsten Station wartenden Menschen wird es dadurch möglich, sich darauf einzustellen, den eigenen Plan anzupassen und die durch die Verspätung freiwerdende Zeit anders zu benutzen als durch blosses Warten.

P.S.: der eine oder andere wird es sich schon gedacht haben - die Erklärung des Phänomens der spät auftretenden Verspätungen anhand der Züge von Bonn nach Köln kommt nicht von ungefähr. Wenn hier jemand von der Bahn mitliest: für den Reparaturbedarf auf der Strecke könnt Ihr nichts, aber realistische Verspätungs-Ankündigungen wären etwas, was vielen Reisenden wirklich helfen würde.

LeSS veröffentlicht eigenen Scrum Guide

Unter den agilen Frameworks ist LeSS (Large Scale Scrum) vermutlich das mit der kuriosesten Entstehungsgeschichte. Ursprünglich entwickelt um das eigentliche Scrum ohne inhaltliche Veränderungen in Skalierungs-Kontexte übertragen zu können, haben sich seine Urheber gegen 2017 entschlossen, sich vom original-Scrum abzukoppeln und ihre eigene, inhaltlich abweichende Version zu entwickeln. Diese Entwicklung ist seit Juli 2024 abgeschlossen, es gibt jetzt einen "LeSS Scrum Guide".

• Scrum Guide (offizielle Version)
  
• Scrum Guide (LeSS Version)

Die Abweichungen zum offiziellen Scrum Guide lassen sich dabei in zwei Kategorien einteilen: zum einen sind es Themen, zu denen die LeSS-Erfinder Craig Larman und Bas Vodde eine andere Meinung haben als die Scrum-Erfinder Jeff Sutherland und Ken Schwaber, zum anderen sind es redaktionelle Änderungen, die den formalen Aufbau des Scrum Guides (Reihenfolge und Gruppierung der Themen) verändern, inhaltlich aber alles beim Alten lassen.

Bei der ersten Kategorie, den inhaltlichen Abweichungen, ist vor allem das (Development-) Team zu nennen. Aus dem offiziellen Scrum wurde es 2020 entfernt und durch "the Developers" ersetzt, um zu verhindern, dass ein Teil-Team innerhalb des Scrum Teams entsteht, dem Product Owner und Scrum Master nicht angehören. LeSS geht in die andere Richtung - diese beiden Rollen sind hier ausserhalb der Teams auf einer übergreifenden Ebene (und nehmen dadurch z.B. auch nicht an den Retrospektiven teil).

Die zweite wichtige Abweichung ist das Zielbild: im offiziellen Scrum findet sich seit 2020 das übergreifende Product Goal, zu dessen Eigenschaften gehört, dass es erreicht und abgeschlossen werden kann (es kann danach ggf. durch ein neues ersetzt werden). Abweichend davon gibt es in LeSS die Product Vision, die deutlich abstrakter ist. Als Folge dessen ist ein abschliessendes Beenden der Arbeit am Product Backlog hier ausdrücklich nicht vorgesehen (und wird sogar explizit ausgeschlossen).

Die dritte Abweichung dreht sich um das Backlog Refinement. Im offiziellen Scrum ist es eine durchgehend stattfindende Tätigkeit, deren Anlass, Umfang und Teilnehmer nicht erwähnt werden. In LeSS ist es abweichend davon als optionales Meeting beschrieben, einschliesslich der Teilnehmer (Scrum-Rollen und ggf. Stakeholder), des Ablaufs und des möglichen Umfangs (maximal 10 Prozent des Sprints, eine Regel, die 2020 aus dem offiziellen Scrum Guide entfernt wurde).

Darüber hinaus gebt es verschiedene weitere, eher abstrakte Abweichungen. Beispielsweise enthält das Product Backlog im offiziellen Scrum "Work for a complex Problem", in LeSS dagegen "Ideas for incrementally creating a Product"; Scrum basiert laut offiziellem Scrum Guide auf "Empiricism and Lean Thinking", laut LeSS-Scrum Guide dagegen nur auf "Empiricism"; die Definition of Done ist offiziell ein Committment, in LeSS dagegen ein Agreement. Den meisten Lesern dürfte das kaum auffallen.

Die zweite Kategorie der Abweichungen des LeSS-Scrum Guide zum offiziellen Scrum Guide sind die redaktionellen Änderungen. Der Sprint steht nicht mehr im Abschnitt der Events (Meetings) sondern hat einen eigenen Abschnitt, die drei im Sprint Planning zu beantwortenden Fragen sind nicht mehr nummeriert, etc. Das Ziel ist vermutlich eine bessere Lesbarkeit und Verständlichkeit, erklärt werden die Gründe für diese Neuformatierung nicht näher.

Soviel zum Inhalt, als nächstes drängt sich die Frage auf: braucht denn irgendjemand diesen zweiten Scrum Guide? Aus Sicht der LeSS-Erfinder bestimmt, zumindest dann, wenn man ihr Framework anwendet, in dessen Rahmen mehrere Entwicklungsteams sich einen Product Owner und ein Product Backlog teilen. Aus einer Scrum-puristischen Sicht vermutlich eher nicht, alleine deshalb nicht, weil diese Skalierungs-Praktiken seit 2020 auch (optionale) Teile des offiziellen Scrum sind.

Am Ende wird jedes Unternehmen oder jedes Team selber entscheiden müssen, welchen der beiden Scrum Guides es besser findet und welchen nicht. Erfahrungsgemäss dürfte das in den meisten Fällen aber eine relativ nachrangige Frage sein. In der Praxis werden die Umsetzungen der beiden Varianten (wenn sie denn wie vorgegeben stattfinden) sich ohnehin nur durch Methoden-Experten unterscheiden lassen und sich für die Beteiligten gleich anfühlen.

Was auf jeden Fall kritisch anzumerken ist, ist, dass LeSS durch diesen neuen Guide in sich selbst inkonsistent wird. Auf der offiziellen Website LeSS.works findet sich zum Beispiel in der offiziellen Beschreibung des LeSS-Frameworks noch ein aus zwei Teilen bestehendes Planning, im LeSS-Scrum Guide sind es drei. In der Framework-Beschreibung wird von teambasierten Refinements abgeraten, im LeSS-Scrum Guide sind sie enthalten. Da muss noch aufgeräumt werden.

Zuletzt eine Beobachtung: im Abschnitt Purpose of the Scrum Guide haben die LeSS-Erfinder Larman und Vodde eine Spitze gegen Jeff Sutherland untergebracht - der offizielle Scrum Guide wird hier bezeichnet als "the Scrum Guide by Ken Schwaber". Das ist zwar nicht komplett falsch, dass Sutherland an der letzten Version nicht beteiligt war, ist offiziell bestätigt worden. Seinen Beitrag komplett unter den Tisch fallen zu lassen ist aber zumindest ungewöhnlich, wer weiss was da im Hintergrund passiert ist.

Woran man erkennt, ob einem Unternehmen Respekt und Augenhöhe wichtig sind

Es ist heute der Standard in jeder grösseren Organisation: alle geben sich (explizit oder implizit) Leitwerte wie Respekt, Augenhöhe, Fairness und Ähnliches. Das ist auch erstmal gut so, die Frage, die sich viele Betrachter dabei stellen, ist aber, ob das wirklich ernst gemeint ist oder nur der Aussendarstellung dient. Glücklicherweise gibt es eine einfache Möglichkeit, das herauszufinden - man muss sich nur anschauem, wie dort externe Mitarbeiter behandelt werden.

Zum gemeinsamen Verständnis: unter externen Mitarbeitern versteht man Menschen, die nicht in der Organisation für die sie arbeiten direkt angestellt sind. Stattdessen handelt es sich um Mitarbeiter externer Personaldienstleister und Zeitarbeits-Firmen, kooperierender Zulieferer oder eingebetteter Fremdfirmen für Kantine, Hausmeisterdienste, etc. In einigen Berufen, wie z.B. Pflegedienstleistungen oder Softwareentwicklung, kommen dazu noch zahlreiche solo-selbstständige Freelancer.

Dass diese externen Kollegen nicht komplett gleich behandelt werden können wie die internen ist auch klar, bei Leistungen wie z.B. einem Zuschuss zu einer Betriebsrente wäre das alleine aus juristischen Gründen nicht möglich. Und seit einigen Jahren muss eine erkennbar andere Behandlung erkennbar sein, wenn man verhindern will, dass externe Freelancer plötzlich als nur scheinselbstständig gelten. Was in vielen Firmen passiert ist mit diesen Gründen aber nicht zu rechtfertigen.

Um nur einige Beispiele zu nennen, die sich jetzt im Augenblick in Deutschland zutragen: eine Behörde verlangt von Bewerbern um externe Positionen die schriftliche Versicherung, sich nirgendwo sonst zu bewerben, schaut sich selbst aber in aller Ruhe verschiedene Kandidaten an. Ein Dax-Konzern verlangt von potentiellen externen Mitarbeitern, auf eigene Kosten quer durch Deutschland zu Vorstellungs-Interviews zu reisen, ein anderer teilt danach Absagen nur auf Nachfrage mit.

Ein IT-Systemhaus einer Behörde verlangt zwei Wochen unbezahlte Einarbeitung, da die Externen in dieser Zeit ja "noch keinen Mehrwert liefern", eine Bankengruppe verlangt das Gleiche, bevor ein auslaufender Vertrag verlängert wird. Bei einem Automobil-Hersteller werden die Büros, in denen die Externen sitzen, deutlich seltener renoviert und repariert als die der Internen, und fast überall sind die Kantinenpreise für externe Kollegen deutlich erhöht, zum Teil um das Doppelte.

Und das ist nur das was offiziell verlangt und kommuniziert wird, inoffiziell kommt noch mehr dazu. Es ist eine weitverbreitete Praxis, von externen Kollegen unbezahlte Überstunden zu verlangen, gerade in schlecht bezahlten Berufen, und wenn man weiss, dass diejenigen auf das Einkommen angewiesen sind. In Medien-Redaktionen wird von den so genannten "Festen Freien" oft verlangt, dass sie durchgehend in Warteräumen verfügbar sein müssen, wenn sie die Chance haben wollen, beauftragt zu werden.

Anstrengende, monotone oder Stress erzeugende Arbeiten werden in vielen Agenturen bevorzugt an externe Kollegen weitergereicht, bei Ergebnis-Präsentationen dürfen sie oft nicht mit auf die Bühne, sie werden bevorzugt in die Teams cholerischer und inkompetenter Vorgesetzter geschickt, und wenn die Budgets für ihre Einsätze gekürzt werden, erfahren sie es als letzte, damit sie durch die Hoffnung auf Verlängerung bis zum Schluss überdurchschnittlichen Einsatz zeigen.

Um auch das zu sagen: in vielen Firmen finden derartige Missstände nicht statt, und es gibt sogar einige, die die externen Mitarbeiter besser behandeln als die internen. Trotzdem sind die gerade genannten Phänomene weitverbreitet, wie zuvor gesagt handelt es sich bei jedem der genannten Beispiele für die schlechte Behandlung von Externen um solche, die gerade jetzt in verschiedenen Unternehmen und Behörden in Deutschland stattfinden und weiter stattfinden werden.

Dass all das mit Respekt, Augenhöhe und Fairness nichts zu tun hat, ist offensichtlich, stattdessen werden externe Kollegen in solchen Firmen als Menschen zweiter Klasse behandelt, und das in den meisten Fällen mit einer erstaunlichen Offenheit und mit einem bemerkenswert geringen Schuld- oder Unrechtsbewusstsein. "Das sind ja nur die Externen", heisst es häufig, "die sind ja eh bald wieder weg", oder der Klassiker: "Wenn es denen nicht gefällt, können sie ja gehen."

Was dabei oft nicht erkannt wird ist, dass diese Verhaltensweisen aber auch in der eigenen Belegschaft spürbare Folgen haben. Dass ein derartiger Umgang mit anderen Menschen toleriert oder sogar normalisiert wird trägt früher oder später zu einer toxischen Arbeitskultur bei, die dazu führt, dass die eigenen (fest angestellten) Mitarbeiter entweder verrohen und abstumpfen oder angewidert in die innere oder äussere Kündigung gehen.

Und dass die schönen an der Wand hängenden und in Management-Reden zitierten Leitwerte ernst gemeint sein könnten glaubt in solchen Firmen niemand, womit die Unternehmenskultur nochmals beschädigt wird. Die Betonung dieser Werte wird dort als paradoxe Kommunikation wahrgenommen und führt nicht nur dazu, dass ihnen nicht geglaubt wird, sondern auch dazu, dass jedem der sie einfordert Unaufrichtigkeit und Doppel-Standards unterstellt werden.

Es gibt also viele Gründe dafür, etwas zu tun, das eigentlich eine Selbstverständlichkeit sein sollte: externe Mitarbeiter gut zu behandeln. Das ist dann auch ein erkennbarer Beleg dafür, dass Respekt, Augenhöhe und Fairness ernst gemeint sind, und nicht nur deshalb an der Wand hängen, weil das gerade in Mode ist.

Agile Cookies

Bereits seit einiger Zeit taucht dieses Video von Dorota Mleczko immer wieder in meinen Social Media-Feeds auf. Mittlerweile ist es auch in Youtube verfügbar, so dass man auch  sich dort (und hier) anschauen kann, wie eine Unterhaltung zwischen Scrum, Kanban, Extreme Programming und SAFe aussehen würde.

Ich halte die vier Frameworks trotz aller absichtlichen Überzeichnung für gut getroffen. Wer sich beruflich mit ihnen (und ihrer Wahrnehmung durch ihre Anwender) beschäftigt, wird einiges davon im Video wiedererkennen. Ich sage nur: Fishbone.Diagramm.

Agile Success Stories: Das Compliance-MVP

Man soll ja Erfolge nicht nur feiern, sondern auch in Erinnerung behalten, denn wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann sonst leicht in Frustration abrutschen. Um es nicht dazu kommen zu lassen, möchte ich von einer weiteren "agilen Erfolgsgeschichte" erzählen, die sich einmal im IT-Systemhaus einer grossen Bankengruppe zugetragen hat, bei der Entwicklung eines neuen Onlinebanking-Systems.

Agiles Arbeiten steckte dort noch in den Anfängen, und wie in vielen anderen Unternehmen auch wurde noch davon ausgegangen, dass es sich dabei nur um eine neue Arbeitsweise für die Software-Entwicklung handeln würde. Andere Organisationseinheiten reagierten nur mit einer Mischung aus Amüsiertheit und Entrüstung, als angeregt wurde, dass auch sie ihren Arbeitsmodus ändern sollten. Ihre Ideen waren klar: sie wollten im Voraus definieren, was sie wollten, und dann warten bis es fertig war.

Was zu ihrer Überraschung anders war, war aber, dass ihnen schon früh mitgeteilt werden konnte, wie (un)realistisch ihre Vorstellungen waren. Durch feature- statt komponentenorientierte Entwicklung, frühe Integration und automatisiertes Testen war der reale Arbeitsfortschritt klar erkennbar, und durch eine grobe Schätzung der noch offenen Anforderungen auch die noch nötige Zeit, beziehungsweise die vermutlichen Liefertermine der fehlenden Features. Und nätürlich - die waren später als gewünscht.

Die ersten Reaktionen darauf waren abwiegeln und abstreiten. Es wäre doch noch viel zu früh für solche Aussagen, die Roadmap wäre schliesslich von Experten gemacht worden, die Entwicklungs-Teams müssten nur bereit sein, "etwas Gas zu geben", dann würde der Zeitplan wieder passen. Und so weiter. Allein - alle drei Wochen bestanden die Entwickler in den Sprint Reviews auf ihren schlechten Botschaften. Im ersten Quartal, im zweiten, im dritten, und am Anfang des vierten.

Wenige Monate blieben damit noch bis zum geplanten Go Live in der ersten Tochtergesellschaft, und plötzlich wollten auch die anderen Organisationseinheiten agil werden. Besonders ein Begriff hatte es ihnen auf einmal angetan: das Minimum Viable Product (MVP), in ihrem Verständnis ein nur auf das absolut Notwendige reduzierter Funktionsumfang, mit dem der anvisierte Termin noch irgendwie zu halten sein müsste. Den wollten sie haben, und den glaubten die Entwickler auch liefern zu können.

In der Folgezeit wurden die Anforderungen Seite um Seite zusammengestrichen. Opulente Redaktions-Workflows? Erstmal nicht. Der komplette Nachbau aller Features des alten Systems im Neuen? Völlig übertrieben. Die Umstellung aller internen CMS-Seiten auf die Fonts, Formen und Farben des Corporate Design? Unnötig. Etc. Am Ende blieb nur ein letztes der unrealistisch grossen Arbeitspakete übrig, das angeblich nicht verhandelbar war. Das so genannte Reporting Center.

Dieses letzte laut Compliance-Abteilung zwingend nötige Feature sollte sicherstellen, dass sich nachvollziehen liess, welcher interne Mitarbeiter wann welche Änderungen in dem Onlinebanking-System vorgenommen hatte. Zu diesem Zweck sollte es möglich sein, sich alle Änderungen anzeigen zu lassen, sie nach Zeitraum, Bearbeiterrolle oder betroffenem Teilsystem zu filtern und grafisch aufbereitet anzeigen zu lassen. "Wenn es das nicht gibt, macht uns die Bafin den Laden zu", hiess es.

Als zwei Wochen vor Weihnachten absehbar wurde, dass auch diese Drohung nicht zu einer wundersamen schnellen Fertigstellung führen würde, fiel auf einmal auch hier das neue magische Wort. "Gibt es nicht auch davon ein MVP, und wenn ja, welches?" Und es gab eines - eine aus dem System exportierte Tabelle aller Bearbeitungsvorgänge, mit dem Angebot der Entwickler, ggf. beim Verständnis zu helfen. Und ein inoffizielles Vorfühlen bei der Bafin ergab: für die erste Version würde das reichen.

Und damit war es geschafft. Das Go Live in der ersten Tochtergesellschaft konnte wie geplant stattfinden, und nicht nur das. Die dort mit dem MVP-System arbeitenden Mitarbeiter konnten gefragt werden, wie sie mit dem System zurechtkamen, ihnen konnte gesagt werden, welche Features sonst noch geplant waren, und was sie vermutlich kosten würden. Und völlig überraschend kam das Feedback, dass viele davon gar nicht benötigt würden und stattdessen etwas Anderes sinnvoll wäre.

Dem Vernehmen nach ist das etwas überdimensionierte Reporting Center irgendwann doch gekommen, aber trotzdem enthält diese Geschichte einigen von dem, was agiles Arbeiten so wirkungsvoll macht: frühe Auslieferung, hohe Transparenz, ständiges Feedback, ein MVP, aus dem man mehr über die echten Bedürfnisse echter Anwender lernen kann und eine Anpassung der Pläne an die Realität (statt des Versuchs das Gegenteil zu erzwingen). Und all das in einer stark regulierten Branche.

"So sollten wir öfter arbeiten", hatte einer der Bank-Manager mir zum Ende meines Einsatzes gesagt. Ich wünsche ihm und seinen Leuten, dass das seitdem auch passiert ist.

Der dreiteilige Vermerk

Wer hier schon länger mitliest weiss es - ich habe am Anfang meiner Karriere in einer Behörde gearbeitet, in der ich nicht nur viele der bekannten und beklagten Dysfunktionen erleben musste, sondern in der auch vieles einfacher, flexibler und effizienter organisiert war als in vielen Unternehmen, in denen ich später gearbeitet habe. Ein Werkzeug das ich dort kennengelernt habe benutze ich sogar bis heute (wenn auch meistens unter anderem Namen): den dreiteilen Vermerk.

Zum Hintergrund: mein Referat hatte relativ wenige gleichbleibende Regeltätigkeiten und war stattdessen an vielen Projekten, Arbeitsgruppen, Veranstaltungen und weiteren sehr unterschiedlichen Aufgaben beteiligt. Sowohl in der internen Kommunikation als auch in der Zusammenarbeit mit anderen Behörden, externen Partnern und höheren Hierarchieebenen war es daher immer wieder nötig, neue Themen und komplexe Zusammenhänge schriftlich zu kommunizieren.

Die Dokumente mit denen in der öffentlichen Verwaltung normalerweise Kommunikationen stattfanden, hiessen im Behördendeutsch "Vermerk", aber trotz ihrer zentralen Bedeutung für die Informationsverteilung gab es für sie kein standardisiertes Format. Je nachdem von welcher Person oder in welcher Organisationseinheit sie verfasst waren konnten sie lang sein oder kurz, strukturiert oder unübersichtlich, prägnant oder ausschweifend.

Das in meinem Umfeld meistens genutzte Format war das bereits Erwähnte. Der Vermerk bestand dabei in der Regel aus drei Teilen, die immer in der gleichen Reihenfolge angeordnet waren und die inhaltlich aufeinander aufbauten:

1. Worum geht es?
2. Was ist bisher passiert?
3. Was ist als nächstes zu tun?

Gegebenenfalls folgten danach noch weiterführende Informationen, ein freizugebendes Dokument, ein Entwurf eines Rede-Manuskripts oder irgendeine andere Mehrwert stiftende Anlage.

Um auf die drei Hauptbestandteile einzugehen: alleine der erste Teil war bereits wichtiger als man denken könnte. Angesichts vieler verschiedener Themen und ständiger Kontextwechsel konnte nicht davon ausgegangen werden, dass jeder, der in einen Termin eingeladen oder um eine Entscheidung gebeten wurde, sofort alle Ziele, Handlungsbedarfe und Hintergründe parat hatte. In Worum geht es? wurden diese daher möglichst komprimiert auf maximal einer Seite zusammengefasst.¹

Der zweite Teil, Was ist bisher passiert?, sollte verhindern, dass Diskussionen immer wieder von vorne begannen, oder dass Sachstände oder bereits abgeschlossene Aktivitäten redundant oder aufwändig zusammengetragen werden mussten. Im Idealfall enthielt er alle bereits beschlossenen Schritte oder Massnahmen, eine Übersicht darüber, welche bereits angegangen worden waren und ggf. welche davon bereits mit welchem Ergebnis beendet worden waren. Auch das idealerweise auf maximal einer Seite.

Der dritten Teil, Was ist als nächstes zu tun?, diente schliesslich dem Zweck, die anstehende Diskussion oder Entscheidung möglichst effizient zu gestalten. Im einfachsten Fall enthielt er mehrere Entscheidungs-Optionen, von denen nur noch eine gewählt werden musste, es konnten aber auch zu priorisierende Themen sein, Budget-Freigaben oder einfach die Agenda für das kommende Meeting, so dass jeder sich auf die Themen vorbereiten konnte.

Ähnlich wie z.B. die "Press Releases" von Amazon, die ich viel später kennengelernt habe, sind die dreiteiligen Vermerke eine einfache, komprimierte und klar strukturierte Art um komplizierte oder komplexe Themen verständlich aufzubereiten und effiziente Diskussions- und Entscheidungsprozesse zu befördern. Sie auf insgesamt nur ein bis zwei Seiten zu beschränken ist nicht immer einfach, kann aber dabei helfen, sich viele Ineffizienzen und redundante Diskussionen zu ersparen.

Ich habe bereits in verschiedenen Unternehmen mit diesem Format gearbeitet und es auch anderen empfohlen, wenn auch immer mit einer Einschränkung - es sollte nicht kategorisch vorgeschrieben werden, sondern nur da benutzt werden wo es Sinn macht. Auch in der Behörde in der ich es kennen gelernt habe, haben wir bei Bedarf andere Formate genutzt, wenn diese besser gepasst haben. Uns war bewusst, dass alles andere nur zu Bürokratie geführt hätte.

¹Eine DIN A 4-Seite mag nach viel klingen, war im Vergleich zu anderen Dienststellen wenig. Der Durchschnitt lag bei einer halben Seite.