Kommentierte Links (XXIX)

Grafik: Pixabay / Geralt - Lizenz

• John Cutler: One Day Sprints

  Ich habe bereits Teams begleiten dürfen deren Anforderungen so klein geschnitten waren (und so klein geschnitten werden konnten), dass sie innerhalb eines Tages zu erledigen waren. Für die hätte man einen solchen Versuch starten können. Der Grund warum ich den meisten aber davon abraten würde ist, dass es bei komplexen Anwendungen und Anwendungslandschaften sehr schwer fallen wird in nur einem Tag ein Increment zu erzeugen, also eine Funktionalität die einen benutzbaren und bestenfalls vermarktbaren Mehrwert erzeugt. Trotzdem - probieren kann man es, etwa indem man es als Experiment für die Dauer eines "normalen" Sprints laufen lässt. Selbst wenn es nicht beibehalten wird - die Überlegungen zum Kleinerschneiden von Requirements sind in jedem Fall eine wertvolle Übung.

• Roman Pichler: Choosing the Right Planning Horizon for Your Product

  Wenn ich als Berater oder Coach in ein Unternehmen komme in dem Scrum/Agile nicht optimal laufen ist die fehlende mittel- und langfristige Planung ein Problem dass fast immer vorliegt. Das was Roman Pichler hier vorstellt ist ein guter Weg damit umzugehen, vor allem weil er nicht nur verschiedene Horizonte/Zeiträume nennt sondern auch Ratschläge gibt in welchen Zeiträumen sie aktualisiert werden sollten. Mein Modell, das ich bei manchen Kunden eingebracht habe, ist in einigen Punkten noch weniger ausformuliert, gegebenenfalls werde ich das eine oder andere von Pichler übernehmen.
  

• Stephan Grabmeier: Heterogene Teams bilden und führen – Diversity Faultline

Mit Sollbruchstellen in Teams habe ich auch schon Erfahrungen machen dürfen, besonders mit einer die Stephan Grabmeier gar nicht beschreibt: der zwischen internen und externen Mitarbeitern. Selbst wenn es nach Klischee klingt - alleine durch die häufigen Wechsel von Unternehmenskulturen, angewandten Technologien und Produkten sind externe Entwickler häufig flexibler, offener umd umfassender qualifiziert als interne, die seit Jahren oder Jahrzehnten in der gleichen Abteilung an der gleichen Anwendung arbeiten. Hier einen Ausgleich zu finden und Team Spirit zu fördern kann eine Herausforderung sein.

• Robert Galen: Agile Leadership – Eating our own Dogfood

  Was diesem Artikel zugrundeliegt ist ein grundsätzliches Problem: (Change)Manager haben häufig bessere Arbeitsbedingungen als "normale" Mitarbeiter. Bessere Hardware, bessere Software, weniger Vorschriften, weniger Deadlines, etc. Die Implementierung neuer Arbeitsweisen wird daher von ihnen häufig als einfacher empfunden als von den Entwicklungsteams. Um die "Schmerzen des Übergangs" nachvollziehbar zu machen empfiehlt es sich daher, die neuen Regeln auch auf die Change-Manager selbst anzuwenden. Die besten Change-Teams die ich erleben durfte (die auch die höchste Akzeptanz durch die Entwicklungsteams hatten) waren die, die selbst nach Scrum oder Kanban gearbeitet haben.

• Adam Henshall: How to Build an MVP App Without Writing Code

  Es ist einer der zentralen Painpoints bei Teams oder Unternehmen die sich an Design Thinking oder Lean Startup versuchen. Entweder hat bei Prototypen und MVPs ein "Dumbing down" bis zu einem fast schon albernen Level stattgefunden (z.B. wird der Testgruppe ein mit Buntstiften auf Papier gemalter Website-Entwurf vorgelegt um Feedback zur Usability zu erhalten) oder es ist bereits soviel Arbeit und Geld in ihn geflossen, dass das Verwerfen zu einem schmerzhaften Schritt wird ("das darf nicht alles umsonst gewesen sein!"). Adam Henshall bietet einige gute Werkzeuge um dieser Situation auszuweichen und mit sehr geringem Aufwand vorzeigbare und benutzbare Ergebnisse zu erstellen, die man im Zweifel auch ohne Bauchschmerzen wieder verwerfen kann.