Kommentierte Links (CXIII)

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: Why is it so hard to admit there’s uncertainty in our work?

Meine Theorie ist, dass ein grosser Teil der oft fehlenden Akzeptanz agilen Arbeitens darin begründet ist, dass die Menschen es sich nicht eingestehen wollen, in einer nur eingeschränkt planbaren Arbeitsumgebung tätig zu sein. Jeff Gothelf geht an dieser Stelle tiefer ins Detail und versucht zu ergründen, warum das schwerfallen kann. Verkürz gesagt: weil (das Eingeständnis von) Ungewissheit unangenehm ist und weil man einmal geäusserte Annahmen und Zusagen ungerne zurücknimmt. Warum man einen guten Grund hat, diese inneren Widerstände zu überwinden, begründet er gleich mit - wer von Anfang an von Ungewissheit ausgeht, wird sein Vorhaben resilienter organisieren, wodurch es nicht so schnell aus der Bahn geworfen werden kann.

Charles Lambdin: What Does 'Iterate' Mean?

Es ist ein Vergehen, dessen sich jeder berufliche Spezialist früher oder später schuldig macht - man benutzt bestimmte Fachbegriffe irgendwann ganz automatisch, ohne darüber nachzudenken wie sie eigentlich ursprünglich gemeint waren. Einer dieser Begriffe, der im Rahmen von agilem Arbeiten immer wieder genutzt wird, ist das Iterieren. Charles Lambdin hat sich die Mühe gemacht und ist dem Ursprung dieses Wortes nachgegangen, mit der überraschenden Erkenntnis, dass er bereits von den Verfassern des Manifests für agile Softwareentwicklung uneinheitlich benutzt worden ist. Vielleicht ist das auch einer der Gründe dafür, dass sich der alternative Begriff des Sprints durchgesetzt hat.

Michael Mankins, Patrick Litre: Transformations That Work

Ein Longread, aber einer, der die investierte Zeit lohnt. Michael Mankins und Patrick Litre haben zu dem Thema der Unternehmenstransformationen (agil, digital, etc) geforscht und kommen zu erstaunlichen Zahlen: die Hälfte der von ihnen befragten Unternehmen hat in den letzten fünf Jahren mehrere derartige Veränderungsprogramme durchlaufen, von denen führten aber nur zwölf Prozent wirkliche Veränderungen herbei. Interessant ist, was diese kleine Erfolgsgruppe gemeinsam hat - die Transformationsvorhaben waren keine zeitlich begrenzten Projekte sondern wurden langfristig und als Teil der täglichen Arbeit beschlossen und umgesetzt, sie waren nicht mit Sparprogrammen verbunden, die Organisation wurde nicht durch zu viele gleichzeitige Veränderungen gestresst, und es wurden ambitionierte Ziele gesetzt, den unteren Ebenen aber Freiheiten in der Ausgestaltung gelassen.

Maarten Dalmijn: Why OKRs Often Slowly Wither Away

Was Maarten Dalmijn hier über OKRs schreibt, trifft auch auf jede andere Form von agilem Arbeiten zu: damit es funktionieren kann sind bestimmte Rahmenbedingungen nötig. Sind diese noch nicht vorhanden, wird die neue Vorgehensweise nicht die gewünschten Ergebnisse bringen, sondern nach und nach wieder absterben. In diesem Problem liegt aber auch bereits die Lösung: wenn man die notwendigen Vorbedingungen einmal verstanden hat, kann man sich fragen, was man tun kann um sie herbeizuführen. Daran zu arbeiten sorgt dann oft für mehr Agilität als die Einführung von OKRs (oder Scrum, oder sonstwas) selbst.

Biplab Subedi: 5 Product Discovery Pitfalls Leading to Scrum Failures

Als letztes mal wieder eine kleine Liste. Biplab Subedi hat fünf häufige Product Discovery-Fehler zusammengetragen, wegen denen eine Scrum-Einführung schiefgehen kann. Hier sind sie:
Mehr Detailsgibt es drüben bei ihm. Ich würde nur noch ergänzen, dass er sich Fälle bezieht, in denen Product Discovery tatsächlich nötig ist. Es gibt auch Fälle, in denen das nicht so ist.