Kommentierte Links (XXVII)

Grafik: Pixabay / Geralt - Lizenz

• Paul Rosenzweig: Bad Code Is Already a Problem. Soon, Companies Will Be Liable.

  Ein noch zu wenig bedachter Aspekt der aktuellen technischen Entwicklungen. Das "Internet der Dinge" und künstliche Intelligenz machen fehlerhafte Software zu einem immer größer werdenden Risiko, z.B. in selbstfahrenden Autos, automatisierten Kraftwerken oder Flugzeug-Leitsystemen. Paul Rosenzweig geht in diesem Artikel davon aus, dass es nur noch eine Frage der Zeit ist bis IT-Firmen gesetzlich verpflichtet werden ihre Anwendungen einfach und verständlich zu strukturieren, sie updatefähig zu halten, regelmässig zu testen, über Schnittstellen zugänglich zu machen und Fehlfunktionen unverzüglich zu beheben. Sollte das so kommen wäre es de facto ein juristischer Zwang agil zu arbeiten.

• Melissa Perri: Product Manager vs. Product Owner

  Eigentlich behandelt Melissa Perri in diesem Text zwei Themen. Zum einen das Scaled Agile Framework (SAFe) und seine Dysfunktionalität in Bezug auf kunden- und benutzerorientiertes Produktmanagement, zum anderen die grundsätzliche Differenzierung zwischen Product Manager und Product Owner. Zum ersten Thema muss man nicht viel sagen, ausser, dass sie Recht hat. Das zweite lautet in einem Satz zusammengefasst: Product Owner ist eine Rolle in Scrum, Product Manager ist ein Beruf den man behält, auch wenn die Methode sich ändert. Und: ein Product Manager kann auch andere Rollen ausfüllen, die nichts mit Scrum zu tun haben. Das ist ein wichtiger Punkt - viele POs sind "One Trick Ponies" und ohne das umgebende Framework relativ hilflos. Daran zu arbeiten sollte Teil der Personalentwicklung jedes agilen Unternehmens sein.
  

• Stephen Frein: Donning the agile camouflage - 5 ways to tell if you're agile in name only

Ich habe es in mehr als einem Unternehmen selbst erleben dürfen - nicht überall wo Agil (bzw. Scrum) draufsteht ist auch Agil drin. Viel zu häufig handelt es sich doch nur um Cargo Cult. Damit Unternehmen selbst feststellen können ob sie in einer solchen Situation sind hat Stephen Frein fünf Anzeichen dafür gesammelt und aufgeschrieben:

• Es gibt innerhalb der Entwicklungsteams Sub-Teams (z.B. Design, Entwicklung, Test) die sich in Form von Mini-Wasserfällen organisieren.
• Es gibt eine weit in die Zukunft reichende Detailplanung der Sprints, die wenig Raum für Anpassungen lässt.
• Am Ende der Sprints gibt es zwar einen Fertigstellungs-Fortschritt, der aber keine benutzbare Funktionalität erzeugt hat.
• User Stories sind zu groß für einen Sprint und werden entweder gar nicht oder nach Phasen (z.B. Design, Entwicklung, Test) geteilt.
• Retrospektiven sind formalisierte Zeremonien die ohne Überzeugung abgehalten werden und zu keinen Veränderungen führen.
Sich selbst an diesen Kriterien zu messen würde im Fall vieler Teams und Unternehmen sehr erhellend sein, aber auch sehr deprimierend.

• Klaus Leopold: Zwischen den Zeilen – Swimlanes am Portfolioboard [Edit: Link ist mittlerweile tot]
  

  Ein kurzer aber wichtiger Text. Wenn Unternehmen ihre Change-Vorhaben visualisieren (was Bestandteil jeder agilen Transition sein sollte), dann können diese nach verschiedenen Kriterien angeordnet sein: entsprechend den Abteilungs- oder Bereichsgrenzen, nach Wichtigkeit oder Dringlichkeit oder nach Impact auf die Positionierung am Markt. Während Variante 1 zu einer Abart von Conway's Law führen kann und Variante 2 schnell in abstrakte Diskussionen abgleitet führt Variante 3 den Focus zurück auf den Grund warum eigentlich etwas geändert werden soll. Nach meiner Erfahrung ist diese Variante leider auch die seltenste. Im Grunde nachvollziehbar, schließlich fordert sie den Beteiligten die größte Änderung im Denken ab.

• Jeff Sutherland: How to Optimize Your Kanban

  Als Beitrag zu einer Diskussion um optimale und dysfunktionale Kanban-Systeme gibt Jeff Sutherland einige Ideen zum Besten. Wie man es vom Begründer von Scrum erwarten kann bestehen die aus der Einführung von Scrum-Elementen. Letztendlich geht das in die selbe Richtung wie die Bemühungen von David Anderson seinen Essential Kanban Condensed Guide zu etablieren. Es scheint einen Bedarf dafür zu geben Kanban zu formalisieren.