Kommentierte Links (CVIII)
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.
Die Velocity, also die Durchsatzmenge erledigter Arbeit pro Zeiteinheit, ist häufig ein kontroverses Thema, da viele Teams darin ein Werkzeug sehen, mit dessen Hilfe sie in die Akkordarbeit getrieben werden sollen. Das kommt auch tatsächlich vor, allerdings nur dort, wo das "schneller Arbeiten" als einziges Mittel gesehen wird, die Velocity zu erhöhen. Dass eine Steigerung auch durch Arbeit am System, an den Kommunikationswegen oder an der Technologie erreicht werden kann, wird zu häufig übersehen. Um so besser, dass Stay Saasy einiges davon zusammengefasst hat.
Man bekommt es aus fast allen Firmen mit - die Versuche, die Mitarbeiter zu regelmässiger Anwesenheit im Büro zu überreden, haben entweder nur geringe Erfolge oder erzielen diese mit dem Preis von Unzufriedenheit und Konflikten. Die Lösung, die Thomas Knüwer präsentiert, um die Motivation für die Präsenzarbeit zu erhöhen, scheint zuerst offensichtlich: man sollte die Büros so gestalten, dass die Menschen gerne in ihnen arbeiten. Der entscheidende Punkt ist seine These (die ich teile): dafür müssten die Grossraum-Büros wieder in kleinere Einheiten umgebaut werden, so wie sie früher waren.
Das was John Cutler hier ausspricht, dürfte für viele klassisch sozialisierte Manager hart zu schlucken sein: je mehr man Umsetzungsteams dazu drängt, prognostizierte Lieferzeitpunkte und -umfänge einzuhalten, desto geringer ist die Wahrscheinlichkeit, dass das dauerhaft gelingen wird. Denn gerade das, was vernachlässigt wird, wenn alle Energie in die pünktliche Fertigstellung des nächsten Features fliessen muss, ist das was auf Dauer für Lieferfähigkeit sorgt: Aufräum- und Reparatur-Arbeiten am Prozess, an der Technik und am Produkt.
Gerade bei den einfachsten Begriffen können mitunter die grössten Missverständnisse auftreten. Irgendwie erscheint alles offensichtlich und naheliegend, so dass man die Dinge einfach tun kann ohne darüber nachzudenken - und ohne es zu merken ist man plötzlich in der falschen Richtung unterwegs. Kent Beck ist aufgefallen, dass das auch beim von ihm entwickelten Test Driven Development (TDD) immer wieder der Fall ist. Aufgrunddessen hat er die Idee und das Vorgehen noch einmal kompakt zusammengefasst, so dass jeder sich mit dem Ansatz im Original vertraut machen kann.
Ein grosser Klassiker. Welche Bestandteile von Scrum sind optional und können weggelassen werden und ohne welche geht es nicht? Mike Cohn beantwortet diese Fragen nicht nur (zumindest anhand einiger der am häufigsten gefragten), sondern er tut es auch noch multimedial - man kann seine Antworten entweder lesen oder als Kurzvideo ansehen und anhören.