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.