Sonntag, 30. April 2023

Kommentierte Links (C)

Bild: Unsplash / Fabio Bracht - 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. Hier ist die mittlerweile hundertste (!!) Monatsübersicht über die erwähnenswertesten unter ihnen. Irre, was da zusammengekommen ist.

Kent Beck: “Friction” >> “Debt”

Carl von Clausewitz wäre begeistert, denn Kent Beck, einer der Erfinder von Extreme Programming, greift hier eine seiner Ideen auf. Ausgangspunkt ist die Überlegung, dass der Begriff der Technischen Schulden mittlerweile etwas in die Jahre gekommen ist, eine gewisse Unschärfe in der Bedeutung entwickelt hat und zum Teil konflikthaft aufgeladen ist. Auf der Suche nach etwas Besserem ist Beck bei der Friktion (Reibung) gelandet, jenem vor langer Zeit von Clausewitz eingeführten Begriff, dessen Aussage ist, dass viele kleinteilige Störungen grosse Vorhaben nachhaltig behindern und verzögern können. Ob dieser neue Begriff tatsächlich besser ist als der alte sei dahingestellt, zumindest kann er aber dort verwendet werden wo technische Schulden vorbelastet sind.

Christoph Roser: On the Team Structure at Toyota

Dafür, dass Toyota als Vorzeigefirma für Lean Management gilt, weiss man in Europa erstaunlich wenig darüber wie es intern strukturiert ist. Christoph Roser lüftet den Schleier an einer kleinen aber bedeutsamen Stelle und lässt uns einen Blick auf die Struktur der Teams auf der untersten Hierarchie-Ebene werfen. Die hier anzutreffenden Einheiten sind relativ klein (vier bis sechs Mitglieder) und werden von einem Vorarbeiter geleitet, der diesen Job nur in Teilzeit ausübt, in seiner restlichen Zeit aber der selben Arbeit nachgeht wie die restlichen Teammitglieder (u.a. als Springer, der dabei hilft Arbeitsspitzen abzufedern). Er hat keine (!) Weisungsbefugnis über die anderen, schreibt aber ihre jährlichen Bewertungen und pflegt die Skill-Matrix des Teams. Für die Methoden-Nerds: der Chapter Lead im Spotify Model ist erkennbar an den Toyota-Teamleiter angelehnt.

Emil: When Scrum Masters and Agile Coaches Unleash Their Team Building Madness

Ich lehne mich weit aus dem Fenster mit der folgenden Einschätzung: Emil von der Sarcastic Society ist zur Zeit der beste Satiriker der gesammten Agile Community. Seine Texte sind extrem überzeichnet, stellen aber gerade dadurch einige unter agilen Teams und Methodikern verbreitete Dysfunktionen ins Rampenlicht. In diesem Text hat er sich die verbreitete Unsitte vorgenommen, Teambuilding-Workshops derartig übermässig verspielt (und für introvertierte Personen latent übergriffig) zu machen, dass das Ergebnis für alle Beteiligten nur noch unangenehm ist. Wer schon ein bisschen in agil arbeitenden Unternehmen herumgekommen ist wird einiges wiedererkennen. Bitterböse und zutiefst witzig.

Philip Rogers: A Fresh Perspective on Forecasting in Software Development

Ob die Perspektive von Philip Rogers auf die Aufwandsschätzungen in der Software-Entwicklung frisch ist, hängt vermutlich vom Stand des eigenen Vorwissens ab, auf jeden Fall ist sie aber ausführlich. Aufbauend auf verschiedenen psychologischen Studien (die sich mit der allgemeinen Fähigkeit befassen, Prognosen abzugeben) identifiziert er drei Faktoren, die zu besseren Ergebnissen bei Aufwands- oder Zeitschätzungen führen: Training, Teamarbeit und Zusammenarbeit mit anderen Menschen, die ebenfalls gut im Aufwandsschätzen sind. Zusätzlich dazu arbeitet er die beiden schwerwiegendsten Ursachen für Fehleinschätzungen heraus, nämlich kognitive Verzerrungen und Signal-Rauschen. Vereinfacht gesagt fasst er nicht zusammen wie man besser schätzt, sondern wodurch. Ein feiner Unterschied.

Kurt Bittner, Pierre Pureur: Agility and Architecture

Ein bewusst kontrovers gehaltener Artikel, der sich unter anderem an der unter agil arbeitenden Entwicklern weit verbreiteten Ansicht abarbeitet, dass architektonische Entscheidungen zum letztmöglichen Zeitpunkt gefällt werden sollten. Ohne alle Argumente vorwegzunehmen - ganz so einfach ist es nicht, unter anderem deshalb weil niemals ganz klar ist, was der letztmögliche Zeitpunkt ist. Das an die Idee des Minimum Viable Product (MVP) angelehnte Gegenkonzept ist die Minimum Viable Architecture (MVA). Ein interessanter Ansatz.

Related Articles