Kommentierte Links (XXX)

Grafik: Pixabay / Geralt - Lizenz

• Joshua Kerievsky: Size teams for few to no handoffs

  Ein schönes Beispiel dafür wie sich Lean und Agile überschneiden. Übergaben zwischen Teams führen zu Wartezeiten, Wartezeiten führen zu langsamen Produktionsvorgängen und langsame Produktionsvorgänge sind nicht mehr agil. Joshua Kerievsky definiert die Freiheit von Übergaben (→ Crossfunktionalität und Autonomie) als so wichtig, dass dafür im Zweifel sogar relativ große Teams (größer als zehn Mitglieder) in Kauf genommen werden sollten. Ein interessanter Gedanke, selbst wenn ich glaube, dass in der täglichen Arbeit mit hoher Wahrscheinlichkeit ein Zerfall in Subteams stattfinden würde.

• Michael Küsters: How splitting work kills companies

Der gleiche Gedankengang aus einer anderen Perspektive. Dass selbst kleine und gut gemeinte Aufgabenteilungen zwischen mehreren Teams zu Bürokratie und Verlangsamung führen können ist auf einer abstrakten Ebene klar, das ganze Ausmaß erschließt sich aber erst an konkreten Beispielen. Das in diesem Fall genannte ist besonders anschaulich, da es sich nicht um Softwareproduktion handelt sondern um einen outgesourcten Kundenservice. Und auch ein weiterer Aha-Effekt ist enthalten: wenn Bürokratie selbst in einem so begrenzten Fall bereits entstehen kann - was passiert dann erst in komplexen Umgebungen?

• Claire Lew: The Culture Cliché

  An der Universität habe ich gelernt, dass Kultur die Summe der impliziten und expliziten Konventionen, Normen, Werte und gemeinsamen Erinnerungen ist, aus der eine soziale Gruppe ihre Identität konstruiert. Claire Lew formuliert es einfacher: “Culture is the way we do things around here.” Was beiden Definitionen gemeinsam ist - man kann Kultur nicht verordnen oder einführen. Sie ist einfach da und überlagert früher oder später alles andere. Wenn im Rahmen einer Unternehmenstransition nicht auch die Kultur geändert wird ändert sich im Zweifel gar nichts, zumindest nicht so wie gewünscht.
  

• Leon Tranter: Technical debt — or technical bankruptcy?

  Vermutlich muss man eine ausser Kontrolle geratene technische Schuld selbst erlebt haben um ihre Tragweite erfassen zu können. Wenn selbst kleinste Änderungen zu umfangreichen Arbeiten in allen Anwendungsteilen, systemweiten Ausfällen und langwierigem Bugfixing führen ist dieses Endstadium erreicht, das Leon Tranter sehr anschaulich als "technischen Bankrott" beschreibt. Sowohl die Ursachen als auch mögliche Lösungen sind gut zusammengefasst, jetzt müsste sie nur noch jemand lesen, der den Entwicklern seines technisch bankrotten Projekts/Unternehmens erlauben kann sie umzusetzen.

• Patrick Beuth: Feindbild Algorithmus

  Kurz nachdem die Digitalbranche zum größten Arbeitgeber in Deutschland geworden ist zeigt der Staat, dass er diesen Wandel leider noch immer nicht versteht. Wenn Bundesjustizministerium, wissenschaftlicher Dienst des Bundestages und weitere Politiker jetzt fordern, dass den Nutzern von Google, Facebook & Co offengelegt wird welche Algorithmen einem Suchergebnis oder Newsfeed zugrundeliegen, dann wird deren Volatilität verkannt. Alleine im letzten Jahr wurden in der Web-Suche von Google 9800 Modifikationen im Livebetrieb getestet, von denen dann 1600 dauerhaft eingeführt wurden (Bericht hier). Soll dann jeder Benutzer 27 Benachrichtigungen pro Tag erhalten? Vielleicht würden dem Bundestag und der Regierung eine Einführung in die Grundlagen agiler Softwareentwicklung gut tun.