Kommentierte Links (XVIII)

Grafik: Pixabay / Geralt - Lizenz

• Jason Little: Is Your Organization Ready for Agile Change? (Edit: Link ist mittlerweile tot)

Ich bin mittlerweile ein Fan von Jason Littles Blog, so ziemlich alles was er schreibt könnte ich unterschreiben. Wenn er darüber hinaus noch sinnvolle Werkzeuge vorstellt - umso besser. Die in diesem Beitrag vorgestellten Umfragen habe ich in ähnlicher Form bereits an anderer Stelle gesehen, was ich noch nicht eingesetzt habe sind die Perspective Maps, für die es dort zwei schöne Beispiele gibt. Die Idee dahinter ist, die Sichtweisen verschiedener Gruppen (Teams, Management, Stakeholder, etc) zu erheben und festzuhalten wo sie voneinander abweichen oder sogar gegenläufig sind. Das visualisierte Ergebnis kann dann an einer zentralen Stelle aufgehängt werden, an der es nicht mehr übersehen werden kann. Das ist Transparenz!

• Melissa Perri: Stop Blaming the User

  Was Melissa Perry da schreibt ist leider eine viel zu häufige Realität. Software (und Hardware) ist oft so benutzerunfreundlich, dass es ohne Vorwissen oder Hilfe nicht mehr möglich ist sie korrekt zu bedienen. Das hat fast nie mit Bosheit oder Unfähigkeit zu tun, sondern fast immer mit "Sachzwängen". Um Geld und Zeit zu sparen werden neue Funktionen nicht richtig entwickelt sondern notdürftig irgendwo an bestehende Prozesse und Oberflächen drangeklemmt, mit den entsprechenden negativen Folgen für Usability und User Experience. Richtig bedenklich wird das aber erst, wenn Unternehmen oder Entwicklungsteams die Schuld für die daraus entstehenden Akzeptanzprobleme auf den Benutzer schieben wollen. Mit Perris Worten: "If the user doesn’t understand something, they are just stupid. If the user won’t tell us what they want, they are difficult. If they are calling to complain, they are ungrateful." Bei der Entwicklung von Anwendungen für die eigenen Mitarbeiter kann dieses User Blaming dazu führen, dass die Betroffenen in die innere Kündigung abtauchen, bei externen Anwendungen können schlechte Presse und Verluste von Marktanteilen die Folge sein. Das Abstellen dieser (vermeintlichen) Sachzwänge sollte daher immer höchste Priorität haben. Apropos:

• Tom Bartel: Refactoring For Non-Coders

  Einfache Erklärungen wie diese hier von Tom Bartels sind extrem wichtig, und zwar aus einem banalen Grund: zu den technikfernen "Non-Coders" gehört in vielen Unternehmen auch das Management, das die Refactoring-Aufwände verstehen, genehmigen und einplanen muss. Für jemanden der von einer Anwendung nur die Benutzeroberfläche kennt können Refactorings leicht den Eindruck erwecken, hier würde nur "der Code hübscher gemacht". Wenn nur begrenzte Ressourcen verfügbar sind gehört das dann zum Ersten was gestrichen wird (das sind die "Sachzwänge" aus dem letzten Abschnitt). Die Folge: schlecht wartbare, bedienbare und erweiterbare Anwendungen. Mit plastischen Methaphern wie dieser hier können die Auswirkungen von fehlendem Refactoring vermittelt werden.
  

• Mike Perrow: 5 tough questions about scaled agile you'll need answers for

  SAFe ist vermutlich das umstrittenste unter den großen agilen Frameworks, für viele ist es sogar ein Antipattern, das durch die Hintertür Wasserfall-Elemente wiedereinführt. Sein Erfinder Dean Leffingwell hat allerdings einen Punkt wenn er festhält, dass Scrum oder Agile in großen Firmen Fragen aufwerfen, die man beantworten können sollte:
  

  1. Wie kann sichergestellt werden, dass alle Teams das gleiche Ziel im Blick haben und darauf hinarbeiten?
  2. Wie kann verhindert werden, dass die Teams unterschiedliche (schlimmstenfalls inkompatible) Wege in Architektur, Benutzerführung und Design gehen?
  3. Wie funktioniert langfristige (Budget)Planung in einem skalierten agilen Umfeld?
  4. Wie lässt sich berechnen, welchen Geschäftswert die getätigten Ausgaben einbringen werden?
  5. Warum ist eine permanente Anpassung von Anwendung und Anforderungen billiger als das schnelle Fertigstellen und Abliefern klarer Aufträge?

  Ob SAFe die richtigen Antworten auf diese Fragen liefert ist umstritten, zumindest sind sie aber für klassische Management verständlich. Und in einem Punkt hat Leffingwell definitiv recht: wer diese Fragen nicht beantworten kann wird schnell als unseriös gelten und nicht mehr ernstgenommen werden.

• Harald Schlüter: Eine Fallstudie zur Einführung von Kanban

Diese Fallstudie von Harald Schlüter ist gleich in zweifacher Weise interessant: zum einen aufgrund ihres Inhalts, zum anderen aber aufgrund der visuellen Aufbereitung. Auch wenn man bei der Veranstaltung nicht dabei war geben die Flipchart-Blätter einen sehr guten Einblick darüber wie die Einführung strukturiert und durchgeführt wurde..