Kommentierte Links (CXXXV)
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.
Eigentlich war ich mir ziemlich sicher,
das Video von James Shore's Keynote auf dem Regional Scrum Gathering Tokyo irgendwann mal in einen Post auf dieser Seite eingebunden zu haben. Da ich es nicht finde, ist hier das Transkript. Anscheinend ist
seine Firma, die er hier beschreibt, einer der mittlerweile seltenen Fälle, in denen Extreme Programming der offizielle Arbeitsmodus ist - und wenn man ihm glauben darf, mit durchschlagendem Erfolg.
Artikel über die Ursachen der zur Zeit abnehmenden Beliebtheit agiler Arbeitsweisen gibt es viele, die meisten davon allerdings nur mit geringem Tiefgang, bzw. mit der offensichtlichen Absicht, mit einer Alternative zu Geld oder (unternehmensintern) zu mehr Macht zu kommen. Charles Lambdins Text hat wesentlich mehr Tiefgang, da er auf einer systemischen Betrachtung der umgebenden Gesamt-Organisationen aufbaut, mit denen die agilen Teams und Methodiker oft eher unglücklich interagieren.
Itamar Gilad setzt mit seinen Überlegungen an einem häufigen Problempunkt an: wenn die Märkte und Technologien sich ständig ändern, wie kann man da planen? Und umgekehrt - wie soll man ohne Planungen in der Lage sein, ein Unternehmen zu führen? Seine Ausführungen fassen einige bewährte Praktiken zusammen, mit deren Hilfe man diesem Dilemma entkommen kann, verbunden mit einigen hilfreichen Tools und Visualisierungen.
Dass Reorganisationen grosser Unternehmen auf viele Mitarbeiter traumatisierend wirken können ist einer der dunklen Aspekte des Change Managements, über die eher selten gesprochen wird. Steve Denning sieht die Ursache dafür in dem typischen Organisationsdesign, in dem Identifikation und Expertenstatus sich aus der Zugehörigkeit zu Organisationseinheiten ableiten (und mit ihnen verloren gehen können). Seine naheliegende Lösung: die Entkoppelung dieser Aspekte von der Firmenstruktur.
Um zu verstehen, warum das eigentlich sehr einfache Scrum-Framework von vielen Menschen als kompliziert und unverständlich empfunden wird, muss man sich die offiziellen Scrum-Regeln wie eine Legacy-Software vorstellen, die seit mehr als einem Vierteljahrhundert ständig erweitert und angepasst wird. Das was Tobias Mayer gemacht hat, kann man im Rahmen dieser Metapher als Refactoring verstehen: die Funktionsweise ist die gleiche geblieben, aber der Aufbau ist wesentlich klarer.
Der Hintergrund dieses Artikels ist ein Mythos, und zwar der des so genannten "10x Engineer", also einer Softwareentwicklers, der zehnmal besser ist als der Durchschnitt, und der daher der ideale Angestellte einer IT-Firma ist. Charity Majors relativiert diese Wunschvorstellung und ordnet sie ein: in einem so grossen und sich so stark ändernden Berufsfeld wie der IT ist es praktisch unmöglich, dauerhaft 10x Engineer zu sein. Besser als trotzdem nach einem zu suchen ist es daher, ein Umfeld zu schaffen, in dem auch normale Entwickler das Beste aus sich herausholen können.
Um Missverständnisse zu vermeiden: wenn Benji Weber von "Genies" spricht, dann meint er nicht geniale Menschen, sondern die Softwareentwicklung unterstützende KI-Programme, die für ihn Geister (englisch: Genies) sind, die man nicht wieder in ihre Flasche zurückbekommt. Was er herausstreicht: der beste Arbeitsmodus für sie ist der, der auch bei menschlichen Programmierern der beste ist - kleine Releases, kleine Codebase, schnelle Tests, viel Automatisierung und verständlicher Code.
Von vielen Menschen wird (Unternehmens-)Kultur als etwas gesehen, das einfach da ist und sich nicht gezielt verändern oder gestalten lässt Die Organisationssoziologie und -psychologie würde widersprechen: es geht, allerdings mit dem Haken, dass es nicht einfach ist - vor allem in grossen Organisationen. Zum Glück hat Mike Fisher gerade für die einiges an Ratschlägen parat, mit deren Hilfe man sich dieser verdienstvollen Aufgabe annehmen kann.
Zum Product Operating Model, dem v.A. von Marty Cagan popularisierten Arbeitsmodus der kalifornischen Tech-Firmen, ist schon viel gesagt und geschrieben worden. Was diese Erklärung von Melissa Suzuno aus dieser Masse heraushebt ist die Mischung aus Struktur und Ausführlichkeit. Man muss sich etwas Zeit nehmen, aber dann weiss man nicht nur wie das Ganze gedacht ist, sondern auch wie man versuchen kann, es bei sich einzuführen und was man dabei beachten sollte..
Zu den grossen Mantras der Objectives und Key Results (in der Produktentwicklung) gehört es, dass sie auf eine Verhaltensänderung der Käufer oder Nutzer eines Produktes abzielen sollten, und zwar auf eine, die gemessen werden kann. Das macht erstmal Sinn, wirft aber die Frage auf, wie man dann im Fall von Refactorings oder nichtfunktionaler Anforderungen mit OKRs arbeiten kann, schliesslich soll dabei ja keine Änderung spürbar sein. Jeff Gothelfs eigentlich naheliegende Antwort: in solchen Fällen sollte darauf hingearbeitet werden, dass Käufer oder Nutzer ihr Verhalten
nicht ändern. Eigentlich einfach.
