Kommentierte Links (XLVIII)

Bild: Unsplash / Compare Fibre - Lizenz

• Christiaan Verwijs: Here’s what's wrong with maturity models

Die Frage ist erstmal naheliegend: Wie gut bin ich eigentlich in dem was ich mache? Auf diesen Kontext hier übertragen: Wie gut beherrsche ich Agile, Scrum, Lean, Kanban, etc.? Die scheinbar naheliegendste Lösung der Überprüfung und Auszeichnung durch Zertifizierungen läuft sich gerade tot, so dass eine andere gesucht wird. Maturity Modelle scheinen auf den ersten Blick eine naheliegende Alternative, allerdings eine die mit Vorsicht zu betrachten ist. Christiaan Verwijs zeigt die grundlegenden Probleme dieses Konzepts auf - zu generalistisch, zu wenig auf den jeweiligen Fall eingehend, zu linear. Mit anderen Worten: nicht agil.

• Joshua Kerievsky: Preconditions for Agility

  Mit der Bewegung von agilen Vorgehensweisen in Richtung Mainstream erhöht sich nicht nur die Zahl der Erfolgsgeschichten sondern auch die der Fehlschläge. Ein häufiger Grund dafür ist der Versuch "agile" Vorhaben in einem Kontext durchzuführen in dem sie nur eingeschränkt oder gar nicht funktionieren können. Joshua Kerievsky führt einige Vorbedingungen auf die gegeben sein müssen damit das Ganze Erfolgsaussichten hat: Crossfunktionalität, gemeinsames Verständnis der Ziele, Teamwork, Bereitschaft zu Work in Progress-Limits und Kenntnis der üblichen Praktiken bei allen Beteiligten. Dass das für Agilität elementar ist dürfte offensichtlich sein, umgekehrt stellt sich aber die Frage wie ohne zumindest einige dieser Vorbedingungen überhaupt produktiv gearbeitet werden kann.
  

• Jeff Sutherland: Why Less Communication is Better!

  Ein weiterer Beitrag zu den Ursprüngen von Scrum und Agilität im Militär. Nach den römischen, mongolischen und preussischen Armeen diesesmal mit einem Verweis auf die modernen amerikanischen und vor allem deutschen Streitkräfte. Vom Deutschland des 21. Jahrhunderts aus betrachtet nicht ganz unproblematisch. Einen der beiden Scrum-Gründer von Wehrmachts-Begriffen wie "Auftragstaktik" und "Führen mit Auftrag" schwärmen zu sehen ist (gelinde gesagt) befremdlich und führt spätestens dann zu Unwohlsein wenn der Frankreich-Feldzug von 1940 als positives Beispiel herangezogen wird. Selbst wenn man versuchen könnte das militärische Vorgehen von der dahinterliegenden Ideologie zu trennen ist es unwahrscheinlich, dass dieses Thema hier populär wird.

• Roman Pichler: 10 Scaling Tips for Product People

  Im Grunde auch benutzbar für jede andere Form von Skalierung im agilen Umfeld (und darüber hinaus). Pichlers 10 Skalierungstips sind:
  
  1. Beziehe die richtigen Leute ein
  2. Skaliere nicht zu früh
  3. Starte mit einem MVP (um noch nicht skalieren zu müssen)
  4. Mache die Entwicklungsteams verantwortlich und selbstständig
  5. Teile Teams und fülle sie auf um zu wachsen
  6. Mache Teams produktorientiert statt komponentenorientiert
  7. Starte mit allen Beteiligten an einem Ort und expandiere schrittweise (und nur wenn nötig)
  8. Erwäge die Abspaltung neuer Teilprodukte oder Varianten
  9. Nutze die Vorteile gemeinsamer Plattformen (z.B. von Frontend-Komponenten oder Security)
  10. Skaliere nie zu einem späten Zeitpunkt
  Interessant an dieser Liste: während das meiste die vorbehaltlose Zustimmung der meisten agilen Practitioner finden dürfte sind mit den Tips 5 und 9 zwei durchaus kontrovers zu betrachtende dabei. Nicht dass sie nicht funktionieren könnten, sie bergen aber Risiken in sich derer man sich bewusst sein sollte.

• Shaaron A. Alvares: Tuckman Was Wrong! Doc Norton on Reteaming Models

  Zum Abschluss noch ein Link der zusammen mit dem ersten eine thematische Klammer bildet. Auch das legendäre Tuckman-Modell der Teambildungsphasen (Forming, Storming, Norming, Performing, Adjourning) krankt daran, dass es zu generalistisch, zu wenig auf den jeweiligen Fall eingehend und zu linear ist. Interessant ist insbesondere der Link zu einer Studie mit über 300 Teams, derzufolge nur zwei Prozent von ihnen (!) sequentiell durch die fünf Phasen gingen. Ob die beschriebenen Alternativen der "fluiden Teams" oder des "dynamic Reteamings" besser sind könnte man aber auch diskutieren. Wie so oft: es kommt darauf an.