Kommentierte Links (CI)
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.
Zusammen mit Johannes Schartau und Christiaan Verwijs hat Barry Overeem den Begriff "Zombie Scrum" geprägt, womit ein Vorgehen gemeint ist, dass oberflächliche Ähnlichkeiten mit dem echten Scrum hat, aufgrund einer nicht sinngemässen Umsetzung aber dysfunktional ist. Zu den stärksten Indikatoren für derartige Missstände gehören Meetings, die lediglich formelhaft durchgeführt werden, ohne ihren eigentlich Zweck zu erfüllen (und ihn ggf. sogar unterlaufen). Wie das aussieht erfährt man in diesem Artikel.
Die
Flusseffizienz zu messen ist eine Idee der ich bei verschiedenen Kunden immer wieder begegnet bin, und grundsätzlich ist sie auch gut. Was Bruno Baketarić hier anmerkt ist aber ebenfalls Teil der Wahrheit: eine Erhebung ist sehr, sehr schwierig. Das liegt unter anderem daran, dass es dafür nötig ist die Daten mindestens auf Tagesbasis aktuell zu halten, was spätestens im Fall mehrerer paralleler Tätigkeiten und verschiedener beteiligter Teams aufwändig und kleinteilig wird. Nicht, dass es gar nicht ginge, man sollte sich aber bewusst machen, worauf man sich einlässt.
Einige der besten Denkanstösse sind die, die auf den ersten Blick widersinnig wirken. Und da es sich bei Jim Highsmith um einen der Verfasser des legendären
Agilen Manifests handelt konnte man direkt davon ausgehen, dass seine Verteidigung des Micromanagements in diese Richtung geht. Die wichtige Zusatz-Information ist, dass er zwischen dem Mircomanagement der Mitarbeiter und dem Micromanagement des Produkts unterscheidet. Das zweite sinnvoll zu finden ist immer noch kontrovers, aber schon eher mit agilem Arbeiten kompatibel.
Kategorische Aussagen sind bekanntlich immer falsch, so auch die, dass Entwicklungsteams am Besten alles im
Pair Programming machen sollten. Wann das Sinn macht, was die Alternativen sind und wann diese Sinn machen arbeitet Fagner Brack in dieser Gegenüberstellung sehr schön heraus. Auch er liefert natürlich keine allgemeingültige Anleitung, nach dem Lesen seiner Ausführungen kann es aber einfacher sein sich auf ein Vorgehen zu einigen, dass dann eine Zeit lang ausprobiert werden kann.
Je nachdem in welchem Kontext man arbeitet gelten verschiedene Parameter als fix und variabel, meistens Kosten, Zeit und Umfang. Jeff Gothelf versucht sich daran das Ganze neu zu denken: da im Rahmen von Continuous Delivery die Teams relativ stabil sind fällt das Budget als potentiell variabler Parameter weg (in der Wissensarbeit sind Gehälter der wesentliche Kostenfaktor), genau wie Zeit (es gibt kein Ende) und Umfang (verändert sich permanent). Als alternativen Fix-Parameter schlägt er ein anzustrebendes Kundenverhalten oder Geschäftsziel vor, als Variablen Parameter das Produkt, bzw. dessen Entwicklung - in der die bisherigen Parameter enthalten sind. Spannend.
