Freitag, 29. September 2017

Kommentierte Links (XXIX)

FS
  • 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 Ansatz

  • 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.

Dienstag, 26. September 2017

How to convince your boss to be agile

FS


Ein Vortrag der nicht nur inhaltlich gut ist sondern auch hohen Unterhaltungswert hat. Kann man sich ansehen.

Donnerstag, 21. September 2017

Scaled Agile: Release Trains

FS
Bild: Wikimedia Commons / David Gubler - CC BY-SA 3.0
Die Idealwelt ist die von der man hört wenn von Netflix, Zalando und Spotify die Rede ist. Statt einer großen, monolithischen Anwendung gibt es viele kleine Module (Microservices), die unabhängig voneinander deploybar sind und ihren Teams dadurch hohe Autonomie sichern. Die Realität ist häufig eine andere - Microservices existieren nicht (oder sind ungünstig geschnitten), so dass es doch dazu kommt, dass verschiedene Teams ihre Features gemeinsam auf Produktion bringen müssen. Wie passt das zu agiler Softwareentwicklung?

Der typische Management-Reflex ist "Koordination", womit in den meisten Fällen gemeint ist, dass ein koordinierender Manager eingesetzt wird, der den Teams vorgibt wann sie was fertigzustellen haben. In der Theorie sorgt das dafür, dass zusammengehörende Features gleichzeitig fertigwerden, in der Realität ist das leider seltener der Fall. Eher kommt es hier zu den aus dem Wasserfall bekannten Effekten: es passieren ungeplante Entwicklungen, die Geschwindigkeiten der Teams laufen auseinander, es kommt zu Leerlauf, Merge-Konflikten, etc.

Es könnte auch anders laufen, und um zu wissen wie braucht man nur auf einen ähnlichen Fall zu schauen - auf zu erreichende Deadlines. Auch damit können agile Teams zurechtkommen indem sie auf Komfortfunktionen verzichten, einfache Lösungen bevorzugen oder auf andere Art den Scope reduzieren. Ein langsameres Team kann auf diese Weise seinen zeitlichen Rückstand wieder aufholen. Umgekenrt kann gegebenenfalls das schnellere Team einen Gang zurückschalten und mehr Zeit in Refactoring, Bugfixing oder Wissenstransfer stecken, auch dadurch erreichen alle gleichzeitig den gemeinsamen Release-Zeitpunkt.

Als Analogie bietet sich der Bahnverkehr an: wenn in Hamm die Züge aus Duisburg und Köln zusammengekoppelt werden sollen, dann kann der langsamere (in diesem Fall aus Duisburg) schlimmstenfalls einen der vielen Stops im Ruhrgebiet ausfallen lassen, etwa den in Bochum. Umgekehrt könnte der schnellere (in diesem Fall der aus Köln) auch einen Zusatzhalt in Dortmund einlegen. In beiden Fällen würden beide gleichzeitig ankommen und gemeinsam ihre Fahrt nach Berlin fortsetzen.

Bleibt nur die Frage: könnte das nicht auch von einem koordinierenden Manager orchestriert werden? Nur bedingt. Da es erfahrungsgemäß nicht nur zu einer ungeplanten Entwicklung kommt sondern zu mehreren müssen im Zweifel alle beteiligten Teams permanent (in Scrum jeden Sprint, d.h. alle 1 bis 4 Wochen) Korrekturen vornehmen, das mit den Stakeholdern und anderen Teams abstimmen und die Planungen entsprechend aktualisieren. Schon bei zwei Teams wäre das für einen Koordinator eine Herausforderung, bei noch mehr Teams kaum zu schaffen.

Direkt miteinander kommunizierende autonome Teams können sich dagegen ohne Entscheidungs-Engpässe oder Stille Post-Effekte abstimmen und jedes für sich Kurs und Geschwindigkeit so anpassen, dass Vorsprünge und Verspätungen sich ausgleichen. Das Zusammenkoppeln kann dann reibungsloser stattfinden und der gemeinsame "Release-Zug" Fahrt aufnehmen.

Montag, 18. September 2017

Wenn der Agile Coach überall Cargo Cult sieht

FS
Bild: Wikimedia Commons / Thorsten Bachner - CC BY 3.0
Das Leben als Agile Coach kann großartig sein. Dann nämlich wenn man sieht wie die eigenen Ratschläge zu höherer Produktivität, höherer Kundenzufriedenheit oder höherer Mitarbeiterzufriedenheit führen. Andererseits kann es manchmal auch frustrierend sein, dann nämlich wenn man damit konfrontiert ist, dass unwillige Teams oder Manager eigentlich alles beim Alten lassen wollen und überall nur "Agile" als Buzzword-Label draufkleben.

Das Risiko das sich daraus ergibt ist, dass irgendwann reflexhaft jede (scheinbar) falsche Verwendung der Begriffe Agile und Agilität als Cargo Cult abqualifiziert wird. Ich sehe das manchmal an mir selbst, vor allem dann wenn ich gerade nicht bei einem Kunden unterwegs bin und mich daher (unbewusst) nicht an die selbst auferlegte Sorgfaltspflicht gebunden fühle. In solchen Situationen rutscht mir mitunter ein schnelles Urteil durch, eines für das ich mich im Nachhinein ein bisschen schäme.

Um dem entgegenzuwirken versuche ich regelmässig meine eigenen Ansichten zu reflektieren, mich selber zu hinterfragen und mich auf andere Standpunkte einzulassen. Gerade bei Menschen die nicht so tief und dauerhaft in der Thematik stecken wie ich kann eine falsche Benennung von Begriffen ja leicht vorkommen. Auf der anderen Seite ist aber auch deren missbräuchliche Verwendung eine immer wiederkehrende Realität. Und manchmal verschwimmen auch die Grenzen. Einen Schritt zurückzutreten und alles nochmal in Ruhe zu betrachten macht fast immer Sinn.

Was sich immer wieder als hilfreich herausgestellt hat sind "Selbsthilfegruppen" mit anderen Agile Coaches, sei es im Rahmen einer (Un)Konferenz, eines Coaching Retreat oder einer Kollegialen Fallberatung. Und sei es nur um festzustellen, dass andere genau die gleichen Probleme haben wie ich.

Donnerstag, 14. September 2017

Relationale Schätzungen

FS
Bild: Wikimedia Commons / mossi889 - CC BY 3.0
Ob das relationale Schätzen wirklich eine agile Methode im eigentlichen Sinn ist wird immer wieder diskutiert. Tatsache ist, dass die meisten agilen Teams (und fast alle Scrum Teams) derartige Ansätze nutzen um die Größemschätzung ihrer Arbeitspakete durchzuführen. Aber was ist das eigentlich, dieses relationale Schätzen?

Die grundlegende Einsicht dahinter ist, dass das menschliche Gehirn bei Schätzungen bestimmte Schwächen und bestimmte Stärken aufweist. Zu den Schwächen gehört dabei leider eine Schätzung in Zeitaufwänden. Ob eine Arbeit drei oder vier Stunden in Anspruch nehmen wird oder vier oder fünf Tage ist kaum zu sagen, schon gar nicht bei so komplexen und unberechenbaren Aufgaben wie der Neuentwicklung von Software. Zu den Stärken gehört dagegen die Einschätzung von Relationen. Jeder Mensch wird ohne Nachzudenken sagen können, dass eine Walnuss schwerer ist als eine Haselnuss, oder dass das Bauen einer Bank länger dauert als das Bauen eines Stuhls.

Um sich diese Stärke zu mutze zu machen kommt das relationale Schätzen zum Einsatz: neue Aufgaben werden in Bezug gesetzt zu älteren, bereits erledigten. "Wenn das Verarbeiten von Emails mit Word-Anhängen Größe X hatte, ist dann das Verarbeiten von Emails mit Excel-Anhängen ähnlich, größer oder kleiner?" Beruhend darauf ist eine Einschätzung nicht nur einfacher sondern auch wesentlich verlässlicher.

Erfahrungsgemäß hilft es den Beteiligten noch mehr, wenn auch bei diesen Relationsvergleichen keine Zeiteinheiten verwendet werden. Die Frage "Wenn das Erstellen einer Word-Verarbeitung 5 Tage gedauert hat, wie lange dauert dann die Excel-Verarbeitung?" ist zwar einfacher zu beantworten als "Wie lange dauert das Erstellen einer Excel-Verarbeitung?", trotzdem werden sich viele Menschen schwer tun. Leichter fällt es den meisten bei neutralen Einheiten, die nicht sofort mit Zeiteinheiten zu verbinden sind.

Die üblichste dieser neutralen Einheiten sind so genannte Story Points (meistens eine abgewandelte Fibonacci-Reihe), aber es gibt auch T-Shirt-Größen, Tierarten (wie im Symbolbild oben) oder andere selbstentwickelte Einheiten. Das kann jedes Team für sich optimieren.

Montag, 11. September 2017

Erfolgs-User Stories

FS
Bild: Wikimedia Commons / Abdulrahman Raofi - CC BY 4.0
Wieder etwas dazugelernt: in einem zur Zeit von mir gecoachten Team wird eine Art von Anforderungsbeschreibung verwendet die ich noch nicht kannte - die Erfolgsgeschichte, bzw. Erfolgs-User Story. Sie beschreibt einen (noch nicht eingetretenen) Fortschritt der Produktentwicklung aus der Sicht desjenigen, der ihr Ergebnis bereits benutzen kann. Ein Beispiel:

"Zum Glück sind ist die Performance unseres Systems besser geworden, gerade noch rechtzeitig vor der Einspeisung der Partnerdaten. Jetzt können wir sie nutzen ohne durch lange Ladezeiten aufgehalten zu werden."

Wie im Fall normaler User Stories gibt es auch hier präzisierende Akzeptanzkriterien, allerdings in einer neuen Form: "Das war nur möglich weil der Datenbankindex angepasst wurde." "Das war nur möglich weil Duplikate bereinigt wurden.", etc.

Bei genauerer Betrachtung steckt etwas Ähnliches dahinter wie im Fall einer normalen User Story, nämlich der grundlegende Use Case mit angehängtem Business Value, bei Bedarf ergänzt um eine Rolle. Auch die Akkzeptanzkriterien sind trotz der neuen Formulierung inhaltlich mit den alten vergleichbar. Der Mehrwert dieses neuen Ansatzes ergibt sich aus seinem Einsatz in der Zusammenarbeit mit Kunden, Anwendern und Auftraggebern.

Im Rahmen von Anforderungs-Workshops kann man jetzt Fragen stellen wie "Welche Erfolgsmeldung würden sie als nächstes hören wollen?" oder "Welche Erfolgsmeldung möchten Sie als nächstes verkünden können?". Anders bei der klassischen Frage "Was brauchen Sie alles?" ist in einer Antwort darauf bereits eine Priorisierung eingeflossen. Darüber hinaus wird auch die (implizite) Erwartungshaltung aufgelöst, eine Anforderung umfassend beschreiben zu müssen.

Auch hier bedarf es natürlich einer gewissen Übung, damit ein Stakeholder nicht auf die Idee kommt ein "Zum Glück ist alles fertig"zu verfassen. Sobald das geschafft ist kann eine Erfolgs-User Story aber eine gute Ergänzung zu der klassischen Form sein.

Donnerstag, 7. September 2017

Why agile: Gesetzesänderungen

FS
Bild: Pixabay / Jörg Elman - CC0 1.0
"Warum sollen wir jetzt agil werden? Uns betrifft das doch nicht. unser Tagesgeschäft läuft stabil, keine großen Neuerungen, kein intensiver Wettbewerb." Äusserungen wie diese gibt es immer wieder aus Firmen, Behörden und sonstigen großen Organisationen. Tatsächlich ist es auch in vielen wirklich so, dass die Rahmenbedingungen sehr stabil und unveränderbar scheinen. Dass es aber auch in einem scheinbar ruhigen Umfeld zu unerwarteten Änderungen kommen kann zeigt ein aktuelles Beispiel.

Vor gerade erst zwei Monaten hat der Bundestag die Ehe für alle beschlossen, so dass bald auch gleichgeschlechtliche Paare heiraten dürfen. Ab dem ersten Oktober können sie zum Standesamt gehen und sich dort trauen lassen, werden danach aber auf ein technisches Problem stossen: in der dort verwendeten Software befinden sich weiterhin Felder für Ehemann und Ehefrau. Für eine Eintragung von zwei Ehefrauen oder zwei Ehemänndern muss diese Software angepasst werden, und das dauert voraussichtlich (festhalten) bis Herbst 2018. Vierzehn bis sechzehn Monate nach der Gesetzesänderung.

Dieses Beispiel erscheint extrem, es ist aber gewöhnlicher als man denken sollte. Gerade bei älterer Software können die Planungs-, Umsetzungs oder Rolloutprozesse so langwierig sein, dass es selbst bei kleineren Änderungen länger als ein Jahr dauern kann bis neue Versionen in Betrieb genommen sind. Gründe dafür sind umständliche Genehmigungsvorschriften, schlechte Dokumentation der bestehenden Anwendungen, schlechte Absicherung durch Tests und vieles mehr.

Da in diesem Fall der Staat selbst von seiner Gesetzgebung betroffen ist werden sich die Konsequenzen im überschaubaren Rahmen halten, es braucht aber nicht viel Phantasie um sich Konstellationen vorzustellen in denen er strikt auf der zügigen Umsetzung bestehen würde. Mögliche Beispiele finden sich vor allem in stark regulierten Branchen wie im Finanzwesen und der Stromerzeugung, und spätestens beim Thema Verbraucher- oder Umweltschutz ist so ziemlich die ganze Wirtschaft betroffen.

Würde in solchen Fällen mehr als ein Jahr vergehen bis gesetzliche Vorgaben umgesetzt werden, es könnte für die jeweiligen Unternehmen unangenehm werden. Von daher ist die Fähigkeit zur schnellen Anpassung der eigenen Systeme (→ Agilität) etwas das man auch in einem scheinbar stabilen Umfeld haben sollte.

Montag, 4. September 2017

Ein Bild sagt mehr als 1000 Worte (XIX)

FS
Auf dieses Bild gibt es zwei Reaktionen. Menschen die nicht in der Softwareentwicklung arbeiten: Wow, so viel? Menschen die in der Softwareentwicklung arbeiten: Wow, so wenig?

Powered by Blogger.