Kommentierte Links (CIX)
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.
Pavel Samsonov zeigt hier einen interessanten Blickwinkel auf die Ergebnisse früher Design Thinking-, Design Sprint und Lean Startup-Phasen auf. Das was in ihnen erzeugt wird, ist fast immer ein falsches Ergebnis, und zwar falsch in dem Sinn, dass es auf Hypothesen basierende Prototypen oder
MVPs sind, die per Definition noch gar nicht richtig sein können, da der Product-Discovery-Prozess mit ihnen erst beginnt. Um das nicht nur zu akzeptieren sondern sogar wertzuschätzen sind besondere Unternehmen und besondere Unternehmenskulturen notwendig.
Mit der Produktvision verhält es sich wie mit vielen nicht abschliessend beschriebenen Fachthemen: je mehr Experten man befragt, desto mehr unterschiedliche Antworten bekommt man. Jeff Patton hat zwar nicht die eine Version auf die sich alle einigen werden, dafür aber eine gute: Seine Produktvision beschreibt eine zukünftige Welt, einschliesslich des zukünftigen Produkts und der Zwecke die es dort erfüllt. Ebenfalls wertvoll ist die Abgrenzung die er vornimmt, u.a. zu Business Goal, Wchstumsziel und Mission Statement. Nicht dass diese Dinge schlecht wären, aber es sind eben keine Produktvisionen.
Agile Software-Entwicklung hat (Überraschung) mit Software zu tun, und zwar nicht nur damit wie sie entwickelt wird, sondern auch damit, wie die fertig entwickelten neuen Funktionen zum Anwender kommen. Der klassische Weg ist der über den sich Charity Majors hier aufregt: durch Deployments, also dadurch, dass sie auf der Produktionsumgebung ausgerollt werden und ab diesem Moment sichtbar und benutzbar sind. Da das bei zusammenhängenden Funktionalitäten doch wieder zu
Big Bang-Releases führt, zeigt sie einen besseren Weg auf - Continuous Delivery mit
Feature Flags.
In diesem Artikel eines ganzen Autoren-Kollektivs geht es um psychologische Sicherheit, genauer gesagt darum, wie man sie auch erzeugen kann, wenn die Gesamtsituation gerade kritisch ist. Gerade dann ist es nämlich wichtig, dass alle Beteiligten sich trauen, Missstände anzusprechen und Verbesserungsvorschläge zu machen; wenn das nicht der Fall ist, kann ein Runaway Projekt eintreten, der die Probleme ausser Kontrolle geraten lässt. Spannend ist, dass hier nicht nur erklärt wird wie psychologische Sicherheit gefördert werden kann, sondern auch weshalb sie häufig nicht gegeben ist.
Das hier ist ein wirklich innovativer und bemerkenswerter Ansatz. Phil Normans Firma Google hat erkannt, dass eines der grössten Hindernisse für agile Produktentwicklung die Aufblähung des Quellcodes ist, die zu Unübersichtlichkeit, Unberechenbarkeit und Aufwändigkeit von Änderungen führt. Die Lösung ist radikal: ein Programm namens Sensenmann [sic] identifiziert redundanten oder überflüssigen Code und löscht ihn automatisch. Das kann natürlich nur bei hoher Test- und Monitoring-Abdeckung funktionieren, ist dann aber hocheffektiv.
Irgendwann habe ich mal über das Problem von
Branching und Merging geschrieben, mit der Kernaussage, dass Branches keine gute Idee sind. Trisha Gee führt das mit deutlich mehr Detail und Sachverstand aus und hat auch eine Lösung parat wie es besser geht: durch Trunk-based Development (das kontrollierte Einchecken von neuem Code direkt in den Master Branch) wird höhere Geschwindigkeit und Reaktionsfähigkeit erreicht, höhere Stabilität, bessere Zusammenarbeit, bessere Entwicklungspraktiken und geringere
technische Schuld. Es lohnt sich also, darauf hinzuarbeiten.
Noch einmal ein Bericht von Google. Laut Richard Seroter wird die Idee der
Fullstack- und T-Shape-Skills, durch die Personen an möglichst vielen Themengebieten mitarbeiten können, dort eher kritisch gesehen, da sie das Risiko eines zwar breiten, dafür aber nicht besonders tiefgehenden Wissens mit sich bringt. Seine Alternative nennt er Shift Down, und sie besteht daraus, dass den Entwicklern in seiner Firma möglichst viel Arbeit abgenommen wird indem sie in einfach bedienbare Plattform-Services ausgelagert wird. So kann die kognitive Last gering bleiben und die Expertise hoch.
Einer der interessanteren Trends des letzten Jahres sind die grossflächigen Entlassungen von Agile Coaches und Scrum Mastern, die in mehreren deutschen und amerikanischen Konzernen stattgefunden haben. Viele der Reaktionen darauf beschränken sich auf ein
marktschreierisches füt tot erklären der Agilität, es gibt aber auch differenzierte Analysen. Diese hier von Anthony Mersino gehört in die zweite Gruppe. Verkürzt gesagt zeigt er Gründe auf, wegen denen diese Rollen als nicht mehrwertstiftend wahrgenommen und daher in Krisenzeiten abgebaut werden.
Und noch einmal ein Praxis-Bericht, diesesmal nicht von Google sondern von der amerikanischen Marine, bzw. deren Programm zur Verbesserung der Einsatzfähigkeit ihrer Flugzeuge. Vieles davon kennt man aus agilen Teams, z.B. das Delegieren von Verantwortung, das datengetriebene Vorgehen und das Suchen nach Lösungen statt nach Schuldigen. Darüber hinaus gibt es in Bill Leschers Artikel aber auch interessante neue Aspekte, wie z.B. den, dass dort bei den Beurteilungen der verantwortlichen Personen das Systemverständnis und die Prognose-Genauigkeit ähnlich wichtig sind wie die Erfolgsquote.
Ein Hoch auf die Wissenschaft! Dass zu vieles von dem, was Agile Coaches und Scrum Master für richtig halten, eher auf
anekdotischer Evidenz als auf überprüfbaren Daten beruht wird oft beklagt - Barry Overeem und Christiaan Verwijs tun etwas dagegen. Zusammen mit der Universität Aalborg haben sie einige der gefühlten Wahrheiten einer wissenschaftlichen Überprüfung unterzogen, mit zum Teil überraschenden Ergebnissen. Von derartigen Untersuchungen bräuchte es deutlich mehr.
