Kommentierte Links (CXXXI)

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

Gregor Hohpe: Transformation Gremlins

Um einem Missverständnis vorzubeugen: die "Transformation Gremlins", über die Gregor Hohpe hier schreibt, sind nicht etwa Verwandte der Konzern-Trolle, sondern beziehen sich auf das in den 70ern gebaute Auto AMC Gremlin, aus dem Hohpe eine ganze Produkt(anti)kategorie ableitet - die der Produkte, die entstehen, wenn man versucht ein bestehendes Produkt halbherzig und mit möglichst wenig Aufwand an völlig andere Kundenbedürfnisse anzupassen.

Tim Ottinger: Why is working faster not working?

Ein neuer Take auf ein klassisches Thema: das der Arbeitsfluss-Optimierung, bzw. der negativen Folgen die entstehen wenn man nicht etwa die Engpässe beseitigt, sondern an anderen Stellen des Systems mehr Arbeit anordnet. Tim Ottingers wenig überraschende Erkenntnis: geschieht das vor einem Engpass entsteht Stau, geschieht das nach einem Engpass entsteht Leerlauf. Eigentlich Common Sense, aber in grossen Organisationen erstaunlich wenig verbreitet.

John Cutler: Vertical vs. Horizontal Org Coupling

Was bekommt man, wenn man das Ausmass der Steuerung eines Teams durch das Management mit den Abhängigkeiten zu anderen Teams ins Verhältnis setzt? Im Fall von Jahn Cutler eine Matrix aus vier Feldern, die jeweils eine bestimmte, häufig auftretende Ausprägung von Produkt- oder Feature-Teams beschreiben. Wichtig dabei ist, dass keines der Felder besser oder schlechter ist als das andere, es sind vielmehr Typen zwischen denen viele Teams mit der Zeit hin- und herwechseln können.

Kent Beck: Programming Deflation

Kent Beck gehört zu den wenigen Menschen, deren Artikel über den Einfluss von künstlicher Intelligenz auf den Beruf des Software-Entwicklers ich freiwillig lese. Ganz unabhängig von den sonst vorherrschenden Jubel- oder Untergangs-Szenarien beschreibt er einige der gerade stattfindenden Dynamiken - was gerade leichter verfügbar wird, was knapper wird und wie Entwickler sich angesichts dieser Entwicklungen positionieren sollten.

Jamil Zaki: Every Team Needs a Super Facilitator

Auf den ersten Blick ein typisch amerikanischer Management-Magazin-Artikel, voller Superlative und Heldengeschichten. Auf den zweiten Blick dagegen ein differenziert geschriebener Artikel über ein interessantes Phänomen. Unter Verweis auf die Arbeit verschiedener Forscher identifiziert Jamil Zaki die (inoffizielle) Rolle des "Super Facilitators" der sein Team dadurch stärkt, dass er so mit den anderen Mitgliedern interagiert, dass diese ihre jeweilen Stärken optimal einbringen können.

BIC Limit

Zu den wichtigsten Kompetenzen eines Agile Coach, Scrum Master, Agile Consultant oder ähnlicher Rollen gehört es, die Idee agilen Arbeitens so zu erklären, dass sie auch von Menschen für gut befunden wird, die sich wenig mit dem Thema beschäftigt haben. Ein Patentrezept gibt es dafür natürlich nicht, aber einen Ansatz mit dem ich immer wieder sehr gute Erfahrungen gemacht habe: das Buzzwords in Conversation Limit, kurz BIC Limit.

Zur Erklärung: selbst für die Management-Sprache sind die agilen Frameworks mit sehr vielen so genannten Buzzwords überladen, also ungewöhnlich klingenden Begriffen oder Phrasen, die Sachverhalte kurz und prägnant wiedergeben sowie bei der Zielgruppe Interesse und Wiedererkennen hervorrufen sollen. Beispiele dafür sind Agil(e) und Framework selbst, aber auch leichtgewichtig, crossfunktional, iterativ-incrementell und viele weitere mehr. 

Das Problem von Buzzwords: um ihren prägnanten Charakter zu behalten, müssen sie zwangsläufig auf Details, Genauigkeit und Kontext und Klarheit verzichten. Das macht auch Sinn, kommt aber mit einem Preis - um sie im Sinn der ursprünglichen Intention voll zu verstehen, benötigt man entsprechendes Vorwissen. Hat man das nicht, klingen Buzzwords schnell wie leere Worthülsen, was eine im Umfeld agiler Frameworks durchaus häufige Aussenwahrnehmung ist.

Gleichzeitig können Buzzwords durch ihre minimalistische Natur sehr schnell zum Gegenstand von Interpretationen, Missverständnissen und Umdeutungen werden, ohne dass das zwangsläufig auffällt. Servant Leadership zum Beispiel kann auf derartig viele verschiedene Weisen verstanden werden, dass selbst innerhalb einzelner Unternehmen die Bedeutungen und Anwendungen so weit auseinanderlaufen, dass kaum noch Gemeinsamkeiten bestehen.

Beides, sowohl die (ohne Vorwissen scheinbar gegebene) Inhaltslosigkeit als auch die mitunter willkürlich und erratisch wirkenden Deutungen und Missverständnisse, tragen dazu bei, dass Buzzwords von vielen Menschen misstrauisch betrachtet oder sogar rundheraus abgelehnt werden. Und damit kommen wir zu einem Problem bei der Vermittlung agiler Arbeitsweisen - die Benutzung zu vieler Buzzwords kann hier eher schaden als helfen.

Das BIC Limit ist ein Weg um derartige negative Effekte zu begrenzen. Wenige Buzzwords, dafür aber auch weniger Misstrauen und weniger Ablehnung. Welche Begrenzungsmenge sinnvoll ist kann jeder für sich entscheiden, ich selber halte aber ein BIIC Limit von Eins für sinnvoll. Das heisst: Agil, Framework, leichtgewichtig, crossfunktional, iterativ-incrementell und ähnliche Begriffe benutze ich nach Möglichkeit in einem beruflichen Gespräch nur einmal.

Natürlich kann es dabei vorkommen, dass ein Konzept mehr als einmal thematisiert werden muss, allerdings ist das ab dem zweiten mal auch ohne Buzzword möglich. Agil bedeutet für mich zum Beispiel, in kurzen Zyklen Reaktions- und Lieferfähig zu sein. Das lässt sich auch genau so sagen, und es ist für die meisten Menschen auch sehr gut nachvollziehbar, was damit gemeint ist, und was nicht. Mein Erfahrungswert: Gespräche werden so besser.

Zuletzt noch eine kurze Meta-Betrachtung - ja, mir ist bewusst, dass ein BIC Limit ebenfalls ein Buzzword ist. Ironie der Geschichte.

Der 'agile Jobmarkt' als Teil des IT-Jobmarktes

Wer im Augenblick auf agilen Meetups oder Konferenzen unterwegs ist, findet die dort versammelten Scrum Master, Agile Coaches und Agile Consultants oft in einer pessimistischen Stimmung vor, wie man beispielhaft an der oben zu sehenden Session der letzten Agile Cologne sehen kann. Diese Stimmung ist erst einmal so wie sie ist, wie immer lohnt es sich aber auch hier, den Sachverhalt im grossen Kontext zu betrachten, da sich dann einiges relativiert.

 

Um mit der wichtigsten Differenzierung zu beginnen - wenn agile Methodiker darüber sprechen, dass "Agile tot ist", meinen sie in der Regel nicht, dass schnelle Reaktions- und Lieferfähigkeit in der Software-Industrie nicht mehr wichtig sind (in Krisen ist sogar das Gegenteil der Fall). Was sie meistens tatsächlich meinen ist, dass der "agile Jobmarkt", also der für Scrum Master, Agile Coaches/Consultants und ähnliche Rollen, zu verschwinden droht.¹ Und selbst das ist so nicht ganz richtig.

Wenn man das (durchaus reale) Schrumpfen des agilen Jobmarkts betrachtet, sollte man sich zunächst bewusst machen, dass er trotz des Übergreifens agiler Vorgehensweisen in andere Bereiche im Wesentlichen noch immer ein Teil des IT-Jobmarktes ist, und der ist bedingt durch die Rezession als Ganzer in der Krise. Es ist für die Betroffenen zwar nur ein schwacher Trost, aber (agilen und nicht-agilen) Entwicklern, Testern, Architekten und IT-Managern geht es gerade auch nicht besser.

 

Aus dieser vergleichbaren Situation anderer IT-Berufe ergeben sich aber besondere Folgen für die agilen Methodiker. Eine davon, die fast immer übersehen wird: in Zeiten eines schwierigen Arbeitsmarktes sind die Entwicklungsteams tendenziell weniger rebellisch als zu Fachkräftemangel-Zeiten, in dem sie schnell andere Jobs hätten. Und wenn Widerstände gegen kurze Lieferzyklen, hohe Transparenz und häufige Kommunikation zurückgehen, dann bedeutet das auch, dass es weniger Bedarf für agile Coaching gibt.

 

Ebenfalls zu beachten ist, dass während wirtschaftlicher Krisen sparsam mit Budgets umgegangen wird. In Folge dessen werden weniger Projekte neu gestartet und weniger neue Mitarbeiter eingestellt, was wiederum erneute Auswirkungen auf den Bedarf nach agilen Methodikern hat - es gibt weniger Trainings, Schulungen und Teambuilding-Workshops die gehalten werden müssen, und es gibt weniger Teams die durch ihe Storming-Phase begleitet werden müssen.

 

Zuletzt gibt es in vielen Firmen die Tendenz, (vorrübergehend) Dysfunktionen in den Entwicklungsteams in Kauf zu nehmen, wenn sich dadurch Geld einsparen lässt. Eine typische Ausprägung dieses Phänomens ist es, Rollen ohne unmittelbare eigene Wertschöpfung zu streichen oder mehreren Teams gleichzeitig zuzuordnen. Das betrifft häufig Scrum Master und Agile Coaches/Consultants, aber z.B. auch UX Designer, Product Owner, Architekten und weitere "Meta-Rollen".

 

Um die zentrale Botschaft zu wiederholen: für viele agile Methodiker mag es sich zur Zeit anfühlen, als würde die "Nachfrage nach agilem Arbeiten" zurückgehen. Das ist aber eine Verwechselung, was zurückgeht ist lediglich die Anzahl der Scrum Master-, Agile Coach- und Agile Consultant-Jobs. Und selbst die verschwinden auch nicht wesentlich stärker als der Branchenschnitt, bzw. ähnlich abstrakte Stabs- Koordinations- und Management-Jobs.

 

Was im Umkehrschluss angenommen werden kann: sobald die Wirtschaft wieder anzieht, neue Vorhaben gestartet und neue Mitarbeiter eingestellt werden, wird das auch zu einer Verbesserung auf dem "agilen Jobmarkt" führen, sei es weil der Fachkräftemangel wieder zu rebellischeren Teams führt, weil es wieder mehr zu begleitende Storming-Phasen gibt oder weil wieder eigesehen wird, dass es Sinn macht, jemanden zu haben, der regelmässig aus dem Hamsterrad heraustreten kann.

¹Diese etwas unglückliche Gleichsetzung ist dann nochmal ein problematisches Thema für sich selbst

DevOps is for Product Engineers, too

Ich gestehe, als Lesley Cordero ihren Vortrag damit begann, dass sie soziotechnische Systeme auf ihre einzelnen Teile herunterbrechen möchte, war ich schon angetan. Und als sich herausstellte, dass sie dabei über die Dichotomie von Produktentwicklung und Platform Engineering spricht, war ich überzeugt, dass es sich lohnt, bis zum Ende dabeizubleiben.

Inhaltlich geht es um eine Vielzahl von Aspekten, vom Organisationsaufbau über Architektur-Paradigmen und Führungsstile bis hin zu autonomen Teams und robustem Systemdesign. Ein guter Rundumschlag, in dem auch ganz nebenbei der Unterschied zwischen Platform Engineering und DevOps erklärt wird.

Fast- and slow-thinking Teams

Heute gibt es einmal mehr ein Praxisbeispiel, diesesmal von Airtable, einem KI Startup aus dem Silicon Valley. Wie alle Startups muss auch dieses hier agil im eigentlichen Sinn sein, also in der Lage, schnell auf sich ändernde Kundenwünsche und Marktbedingungen zu reagieren. Anders als man denken könnte sind dort aber nicht alle Teams mit dem Ziel einer schnellen Reaktionsfähigkeit aufgesetzt, wie Firmengründer Howie Liu in Lenny's Podcast erklärt.

Es gibt bei Airtable zwei verschiedene Arten von Teams, deren jeweiliges Organisationsmodell an die zwei Arten des Denkens aus Daniel Kahnemans Bestseller Thinking, Fast and Slow angelehnt ist - auf der einen Seite die Fast-thinking Teams, die schnell, proaktiv, intuitiv und experimentgetrieben vorgehen sollen und auf der anderen Seite die Slow-thinking Teams, die abwägend, analytisch, strukturiert und sorgfältig arbeiten.

Wichtig für das Verständnis dieses Ansatzes ist, dass keine der beiden Team-Kategorien grundsätzlich besser oder schlechter ist als die jeweils andere (weder Kahnemann noch Liu sehen in dem Konzept des "langsamen Denkens" etwas Negatives), beide haben in ihrem jeweiligen Kontext ihre Vorzüge. Und diese unterschiedlichen Kontexte (und die Zuordnung der Kategorien zu ihnen) sind es auch, die die Idee der Fast- and slow-thinking Teams so interessant machen.

Fast-thinking Teams werden dort eingesetzt, wo neue Features und Produkte entwickelt werden, was besonders auf dem Markt für KI-Produkte hochgradig anspruchsvoll ist. Ein geradezu rasender technischer Fortschritt, ständige Innovationen, starker Wettbewerb und volatile Kundenbedürfnisse machen schnelles Agieren und Reagieren nötig, weshalb in diesem Bereich eine iterativ-incrementelle Auslieferung von Features im Wochenrhythmus vorgesehen ist.

Slow-thinking Teams sind dagegen dort angesiedelt, wo die Infrastruktur entwickelt wird, die die Basis dafür bildet, dass die von den Fast-thinking Teams entwickelten Features von einer rapide wachsenden Nutzerbasis in hoher Frequenz genutzt werden können. Hier stehen eher Verlässlichkeit, Skalierbarkeit, Resilienz und Berechenbarkeit im Focus, wodurch die Entwicklungsschritte hier deutlich langsamer, dafür aber mit grösserer Sorgfalt und Planung erfolgen.

Dieses bewusste gleichzeitige Aufsetzen von zwei verschiedenen und komplementären Vorgehensmodellen ist in modernen Tech-Unternehmen eher selten, viel häufiger wird versucht, alles nach einem gleichen Muster zu organisieren, dass dann im Einzelfall unpassend ist. Der Denkanstoss, den sich viele mitnehmen können, ist, dass Uneinheitlichkeit durchaus Sinn machen kann. Die kann dann in Form von Fast- and Slow-thinking Teams auftreten, ggf. aber auch ganz anders.

Ein Bild sagt mehr als 1000 Worte (LI)

Sieh dir diesen Beitrag auf Instagram an

Ein Beitrag geteilt von Sam Lau (@samlauhaus)

 

The Cult of the agile Amateur (II)

Kommen wir noch einmal zurück zum Cult of the agile Amateur, also zu dem Phänomen, dass ein Grossteil der Agile Coaches, Scrum Master und Agile Consultants nur eine eher schmale Datenbasis zur Untermauerung ihrer Konzepte vorweisen kann und stattdessen sein Vorgehen vor allem auf Buchwissen, starke Meinungen (eigene und andere), subjektive Erfahrungen, unvalidierte Hypothesen, anekdotische Evidenz und ähnliche nicht-empirische Ansätze aufbaut.

Dieser Zustand hat sich mittlerweile in grossen Teilen verflüchtigt oder wenigstens abgeschwächt, da zumindest die grossen agilen Frameworks (Scrum, Kanban und SAFe) mittlerweile auf eine Anwendungsdauer von mehreren Jahrzehnten und eine Anwenderbasis von tausenden verschiedener Organisationen zurückblicken können, die auch in zahllosen Studien, Konferenzvorträgen, Fachartikeln und Erfahrungsberichten dokumentiert wurden.

Unabhängig davon gibt es aber weiterhin ein Phänomen, auf das der Name des Cult of the agile Amateur zutreffend ist: die Überzeugung, dass man den Job des Scrum Masters, Agile Coaches oder Agile Consultant nicht nur ohne technisches, fachliches und betriebswissenschaftliches Vorwissen ergreifen kann, sondern dass es auch dauerhaft unbedenklich möglich ist (oder sogar erstrebenswert ist), ihn ohne derartige Kenntnisse auszuüben.

Egal ob auf Konferenzen, auf Meetups oder in den Unternehmen selbst - regelmässig kann man hier agilen Methodikern begegnen, die nicht nur offen gestehen, die genannten Wissensgebiete nicht einmal in Ansätzen durchdrungen zu haben, sondern die es sogar als für ihre Berufsausübung als förderlich ansehen, diesen Zustand beizubehalten, um sich ausschliesslich auf die menschlichen und zwischenmenschlichen Aspekte ihrer Arbeit konzentrieren zu können.

Das mag zwar auf den ersten Blick irgendwie rational wirken, schliesslich gibt es für diese Wissensgebiete bereits Spezialisten, deren Berufs sich explizit um diese dreht. Was aber bei einer solchen Betrachtung vergessen wird, ist, dass technische, fachliche und betriebswissenschaftliche Aspekte sich in einem agilen Arbeitsmodus ändern müssen, und dass das jemandem in einem eher traditionellen Arbeitsmodus sozialisiert wurde nicht immer von alleine klar wird.

Egal ob es sich um continuous Integration, modulare Architektur, outcome-orientierte Anforderungen, Minimum Viable Products oder incrementelle Auslieferung handelt - im Vergleich zu klassischen Prozessen sind diese Ideen so anders und ungewohnt, dass oft grössere Erklär- und Überzeugungsarbeiten zu leisten sind, bevor sich darauf eingelassen wird. Und um diese leisten zu können, braucht es zumindest ein Grundverständnis in diesen Bereichen.

Das heisst natürlich nicht, dass man das alles von Beginn an können muss. Es heisst aber, das man bereit sein muss, sich in diese Wissensgebiete einzuarbeiten und sie sich anzueignen. Und die Bereitschaft dazu sinkt, wenn einem von den Anhängern des Cult of the agile Amateur eingeredet wird, dass das unnötig oder sogar nicht zielführend wäre. Wer daher auf Konferenzen, Meetups oder in Unternehmen derartige Aussagen hört, tut sich und Anderen einen Gefallen, wenn er ihnen wiederspricht.

Agile Bang for the Buck

Bild: Unsplash / Ibrahim Boran - Lizenz

Reden wir über Geld. Genauer gesagt, reden wir über das Geld, das eine eine Firma ihren Agile Coaches, Scrum Mastern und sonstigen agilen Methodenmenschen bezahlt, und reden wir über den Gegenwert, den die Organisation dafür zurückbekommt. Denn eines sollte eigentlich allen klar sein - nur wenn der Gegenwert dem Wert der Gehälter entspricht oder ihn übertrifft, werden diese Rollen langfristig in einem Unternehmen bestehen bleiben.

Relativ einfach ist es bei dem ersten Teil: abhängig von verschiedenen Faktoren¹ ermitteln Portale wie Stepstone oder Kununu Gehälter, die irgendwo zwischen 50.000 € und 80.000 € liegen. Zu denen kommen allerdings noch die freiberuflichen Agile Coaches und Scrum Master, deren Tagessätze meistens zwischen 500 € und 800 € liegen, was sich bei 200 Tagen pro Jahr auf 100.000 € bis 160.000 € addiert und den Kosten-Durchschnitt entsprechend hebt.²

Insgesamt liegen dieser Durchschnitt vermutlich sogar noch höher. In grossen Konzernen, in denen es oft eine regelmässige de facto-Beförderungsgarantie gibt, können Scrum Master & Co mit der Zeit Gehälter von 150.000 und mehr erreichen, was sich wegen der meist dauerhaften Betriebszugehörigkeit aber kaum in den oben genannten Recruiting- und Ehemaligen-Portalen wiederspiegelt, wodurch deren Durchschnittswerte zu niedrig sein dürften.

Schwieriger wird es bei der Ermittlung des Gegenwerts, den eine Organisation für die Schaffung eigener agiler Methodenrollen zurückbekommt. Potentiell ist dieser immens, schliesslich können höhere Effizienz und Effektivität, weniger Bürokratie und Verschwendung und besserer Product Market-Fit schon bei kleinen Teams in sechs- oder manchmal sogar siebenstellige Beträge gehen. Da Agile Coaches und Scrum Master nur indirekt darauf einwirken, ist das allerdings kaum bezifferbar.

Was eher möglich ist, ist die Bewertung der Entwicklung, die ein Team nach dem Hinzufügen oder Entfernen eines agilen Methodikers nimmt. Auch das mit Vorsicht, da schnell Korrelation für Kausalität gehalten werden kann, aber mit steigender Aussagekraft, wenn mehr Teams in diese Betrachtungen einbezogen werden. Und das Beste - eine derartige Bewertung kann auf Basis bereits und anerkannter etablierter Metriken erfolgen.

Der Klassiker darunter sind die Effizienz-Metriken, die auch aus dem Lean Management bekannt sind, vor allem Lead Time und Cycle Time. Mit ihnen wird gemessen, wie schnell Arbeits- oder Wertschöpfungs-Pakete die Wertschöpfungskette von der Idee bis zur Auslieferung durchlaufen. Der Anspruch: mit einem Agile Coach oder Scrum Master im Team sollten diese Durchlaufzeiten sich mit der Zeit oder im Vergleich zu anderen Teams reduzieren.

Eine andere Möglichkeit sind aus dem DevOps-Bereich kommende Messgrössen, wie die Deployment-Häufigkeit, die durchschnittliche Menge des pro Deployments veränderten Code, die Durchschnittszeit einer Fehlerkorrektur oder des Zurücknehmens einer fehlerhaften Änderung oder ganz einfach der Betriebskosten. Um hier Wirkung zu erzielen ist eher die Spezialform eines Technical Coach nötig, der dann aber zu bedeutenden Verbesserungen führen kann und sollte.

Als letztes (zumindest in dieser kurzen Aufzählung) kommen Nutzungs- bzw. Akzeptanzmetriken dazu. Wie sind Verkaufszahlen, Nutzungs-, Absprung- und Konversionsraten, wie entwickeln sich die Anwender-Zufriedenheit und die Menge der Support-Calls, etc. Auch hier ist der Anspruch, dass sich diese Zahlen nach dem Hizufügen eines Agile Coach oder Scrum Master zum Team verbessern sollten, sowohl mit der Zeit als auch im Vergleich zu anderen Teams.

Um es zusammenzufassen: es ist zwar kaum möglich, den Mehrwert eines agilen Methodenmenschen separat zu beziffern, was dagegen oft geht ist aber eine Messung der besseren oder schnelleren Wertschöpfung oder der geringeren Bürokratie- oder Verspätungskosten eines gecoachten Teams. Und dann gilt die Faustregel, dass der so erzeugte oder eingesparte Wert mindestens den Ausgaben für den jeweiligen Agile Coach oder Scrum Master entsprechen sollten (siehe oben), damit der sich rentiert.

Um am Ende einen häufigen Einwand gegen eine solche Betrachtung aufzugreifen - ja es kann sein, dass der agile Methodiker alles richtig macht, dass aber keiner auf ihn hört, und es damit nicht an ihm liegt, dass sich nichts verbessert. Aus einer wirtschaftlichen Betrachtung heraus ist das aber kein starkes Argument. Denn wenn eine Ausgabe keinen entsprechenden Gegenwert erzeugt, dann ist sie in Frage zu stellen - unabhängig von Schuldfragen, allein aufgrund ökonomischer Sachzwänge.

 

Nachtrag:

Ein Feedback zu diesem Artikel hat einen weiteren Aspekt aufgeworfen: ein zusätzlicher betriebswirtschaftlicher Mehrwert, der durch Agile Coaching oder Scrum Mastering erzeugt werden kann ist, dass selbstorganisierte Team weniger Management brauchen - wodurch Manager von der Gehaltsliste verschwinden. Auch ein valider Punkt.

¹Z.B. ob eine Aufschlüsselung in Junior, Senior, etc. erfolgt oder nicht
²Das ist die "Kosten-Perspektive", der beauftragenden Unternehmen. Viele Freiberufler sind nicht lückenlos beauftragt und verdienen entsprechend weniger

Kommentierte Links (CXXX)

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

Martin Eriksson: Strategy into Action - Organising Teams to Execute at Pace

Ratgeber zum optimalen Aufsetzen einer Entwicklungsorganisation gibt es viele, dieser hier von Martin Eriksson ist aber aus einem bestimmten Grund besser als viele andere: statt detaillierte Anleitungen zu geben (die dann in vielen Umsetzungsfällen nicht passen werden) gibt er dem Leser einige Prinzipien mit, deren Befolgung viel bewirken kann - Vergegenwärtigung des Unterschieds zwischen Aufbau- und Ablauforganisation, crossfunktionale, mit Handlungsvollmacht versehene Teams, eine Systemarchitektur die dem Teamschnitt entspricht (und ihn definiert) und kontinuierliche Arbeit am Abbau von Abhängigkeiten.

Rudolf Gysi: Was ist der Zeitgeist in deiner Organisation?

Mal wieder ein nützliches Werkzeug, diesesmal die "Zeitgeist Empathy Map" von Rudolf Gysi. Benutzen kann man sie um festzuhalten, welche Themen eine Organisation gerade bewegen, sei es auf betriebswirtschaftlicher, technischer, sozialer oder sonstiger Ebene. Das Ganze natürlich nicht als Selbstzweck, sondern um aufzuzeigen wo gerade ein akuter Klärungs- oder Handlungsbedarf besteht, den man als nächstes angehen sollte.

Jessica Wolfe: Beyond Story Points - Estimating with Time, Complexity, and Risk

Ich halte das seit einigen Jahren in der agilen Community um sich greifende Story Point-Bashing zwar für übertrieben, muss aber eingestehen, dass das Konzept für viele Anwender zu abstrakt zu sein scheint. Für derartige Fälle hat Jessica Wolfe eine gute Alternative entworfen - die drei klassischen Story Point-Teildimensionen Aufwand, Komplexität und Ungewissheit lassen sich auch separat schätzen und festhalten. Für sich genommen ist jede von ihnen deutlich konkreter.

Chris Belknap: You Say You’re Agile? Show Me Your Release Frequency

Dieser Text erinnert mich an den Nokia Test, der um 2010 herum populär war, und in dem (unter anderem) ermittelt wurde, wie regelmässig ein Team fertige Software an seinen Kunden ausliefert. Chris Belknap fügt dieser Metrik noch weitere Dimensionen hinzu, klärt auf warum sie wichtig ist und gibt Ratschläge zu ihrer Optimierung. Ganz im Sinn der legendären Formulierung aus dem agilen Manifest: Working software is the primary measure of progress.

Paulo Caroli: Team OKRs in Action

Als letztes ein Longread. In grosser Sorgfalt und Ausführlichkeit führt Paulo Caroli aus, was Objectives and Key Results (OKRs) sind, wie sie auf Teamebene eingesetzt werden können und wie sie die Arbeit des Teams mit übergreifenden Zielen verbinden können. Insgesamt eine gute Umsetzungsvariante, die sich zum Ausprobieren im eigenen Team anbietet.