Kommentierte Links (LXVI)
Ein guter Opener ist bekanntlich alles, und der hier verlinkte Text hat einen besonders schönen. In nur 70 Worten erklärt Kent Beck einen psychologischen Fachbegriff (Ataxophobie), lässt beiläufig fallen, dass er Extreme Programming erfunden hat, macht klar welche Hoffnungen er damit verbunden hatte und verteidigt seinen Status als grimmiger alter Mann der Agilität
einmal mehr durch das schöne Bonmont, dass Software nur drei Zustände kennt: desaströs, desaströs und unbenutzt. Es gibt dann noch die Erklärung was die drei klassischen Phasen des Extreme Programming sind, warum in ihnen zwangsläufig Unordnung entehen muss und warum das natürlich und behebbar ist. Und wer danach noch immer nicht genug hat kann bei Ron Jeffries weiterlesen, der das Ganze
auf seinem Blog nochmal weiterführt.
Das hier ist streckenweise etwas technisch, aber der Löwenanteil der agilen Produktentwicklung findet nun mal in der IT statt. Die Botschaft die Fagner Brack hier vermitteln möchte dürfte aber auch in jedem anderen komplexen Umfeld zutreffen: dort wo eine zu starke Spezialisierung von Arbeit stattfindet sind böse Überraschungen im wahrsten Sinn des Wortes vorprogrammiert und tauchen mit unschöner Zuverlässigkeit immer dann auf wenn die Spezialisten-Teilprodukte zusammengefügt werden
. Um dem entgegenzuwirken sind Generalisten gefragt, und zwar laut Brack nicht solche die alles können (was unmöglich ist) sondern solche die in der Lage sind herauszufinden welches Wissen sie sich wann zu welchem Zweck aneignen müssen. Ein interessanter (und im Gegensatz zum üblichen Klischee auch umsetzbarer) Blick auf den mythischen "Fullstack-Developer".
"Dual Track Agile" (zwei parallel laufende und jeweils in sich agil organisierte Stränge für Product Discovery und Product Delivery) gilt für den einen oder anderen als die geheime Zutat für erfolgreiche Produktentwicklung. Das ist auch nicht grundlegend falsch, je nach Kontext kann dieses Vorgehen durchaus Sinn machen. Was Alex Ballarín hier zurecht anmerkt ist aber, dass sich dieses Vorgehen in der Praxis fast immer zu kleinen Wasserfallstrukturen entwickelt, mit allen Nachteilen die damit verbunden sind: langen Lieferzyklen, schlechten Sprintzielen, demotivierten Entwicklern und reduzierten Lerneffekten. Was ihm im Folgenden hoch anzurechnen ist - er stellt nicht einfach ein Idealbild als Gegenentwurf auf sondern er erklärt auch warum das so schwer umzusetzen ist - und wie es vielleicht doch geht.
Für viele Product Owner eine bekannte Situation: der Auftraggeber will aus einem riesigen Wunschkorb alles haben und für ihn ist auch alles gleich wichtig, so dass es zunächst unmöglich erscheint ein priorisiertes Backlog zu erstellen. Roman Pichlers (verkürzte) Anleitung zur Auflösung dieses Dilemmas: die (Nutzer-)Zielgruppe identifizieren, deren Bedürfnisse feststellen, davon die Dringendsten auswählen und damit anfangen. Das klingt erstmal einfach, dürfte in meiner Erfahrung zuerst zu einer weiteren Erkenntnis führen - hinter einem (zu) grossen Anforderungsumfang steckt sehr häufig eine unklare Vorstellung vom eigenen Kunden. Wenn das der Fall ist macht es Sinn damit anzufangen die zu schärfen und erst danach über die Backlog-Priorisierung nachzudenken.
Dilbert: Applying Math To Guesses [Edit: Link ist mittlerweile tot]
Dass Scott Adams es auch nach über 30 Jahren und tausenden von Comic Strips noch schafft den gelegentlichen Wahnsinn von Konzern-Jobs auf den Punkt darzustellen ist bewundernswert. Diesesmal geht es um die Angewohnheit, Prognosen zu unprognostizierbaren Sachverhalten zu verlangen. Und genau so wie hier beschrieben kommt es jeden Tag irgendwo vor.
