Wenn der Agile Coach überall Cargo Cult sieht

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.

Irgendwann wird #agile als Begriff ausgehöhlt und beliebig werden wenn es so weitergeht. pic.twitter.com/2HpF47Dxos

— FCS (@fcstein) 13. September 2017

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.

Relationale Schätzungen

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.

Erfolgs-User Stories

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.

Why agile: Gesetzesänderungen

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.

Ein Bild sagt mehr als 1000 Worte (XIX)

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?

I'm blown away by this photo pic.twitter.com/Fiv0y7lWnj

— ClassicPics (@History_Pics) 25. August 2017

Kommentierte Links (XXVIII)

• Tendayi Viki: Lessons From Kodak’s Bankruptcy - How Can Large Companies Sustain Innovation?

  Direkt zu Beginn dieses Textes wird die Tragik des Untergangs von Kodak auf den Punkt gebracht: die Firma ging nicht nur unter weil ihre Erzeugnisse durch den technischen Wandel obsolet wurden, sie hatte diesen Wandel selbst begonnen, wollte dann aber doch nicht auf ihre traditionellen Erfolgsprodukte verzichten. Tendayi Viki geht davon aus, dass ein solches Management-Verhalten seinen Ursprung in einer falschen Ausbildung der Manager an den Universitäten und in den Firmen hat, wo vermittelt wird, dass eine Fokussierung auf ein einziges Geschäftsfeld sinnvoll ist. Sein Gegenvorschlag besteht darin bis zu 30 % der Ressourcen auf neue und disruptive Geschäftsmodelle mit noch unklaren Erfolgschancen zu verwenden und diese möglichst früh validierbar zu machen. Klingt gut, es bleibt aber die Frage wie das mit kurzfristigen Shareholder-Interessen in Einklang zu bringen sein wird.

• Ron Jeffries: Business Agile - Built Upon Sand

  Ob Business Agility und agiles Projektmanagement wirklich neue Trends sind und ob sie grundsätzlich das Risiko in sich tragen die eigentliche Agilität mit zu viel Prozessen einzuengen würde ich hinterfragen. Ron Jeffries hat aber Recht damit, dass es eine spürbare Tendenz gibt agile Transformationen als rein organisatorische Vorhaben zu sehen und die technischen Implikationen auszublenden. Bei vielen Managern gibt es den Irrglauben, dass eine zweitägige Zertifizierung oder eine zweiwöchige Begleitung durch einen Coach ausreichen um ein Team "agil zu machen". In meiner Erfahrung sind eher mehrere Monate nötig, aber das muss erstmal jemand bezahlen wollen. Wobei klar ist - wer eine billige Transition will zahlt meistens drauf.
  

• Jurgen Appelo: Frameworks are like Radio Stations

Da Jurgen Appelo zur Zeit an einem Framework-unabhängigen Methodenbaukasten arbeitet sind seine in letzter Zeit zunehmenden Äusserungen über die Starrheit und Unflexibilität dieser Frameworks mit Vorsicht zu betrachten. Einen zutreffenden Kern haben sie aber, hier werden Freiheiten und Optionen bewusst durch Leitplanken eingegrenzt. Ich bin auch bereit zu hinterfragen ob agile Teams diese Leitplanken wirklich brauchen, erfahrungsgemäß ist das oft nicht der Fall. Wenn aber auf der anderen Seite unerfahrene Teams versuchen die Methoden anzupassen endet das sehr oft in Verschlimmbesserungen. Harikiri, wie ich es nenne. Frameworks haben ihren Sinn, man muss ihn sich nur bewusst machen statt ihnen kritiklos zu folgen.

• Urs Enzler: Problem-Centric User Stories

  Einer der klassischen Fehler die man bei User Stories machen kann ist, dass bereits Lösungen beschrieben werden statt der Bedürfnisse des Benutzers oder des Kunden. Übertroffen wird das gelegentlich noch durch die Beschreibung von Bearbeitungsschritten ("Als Sachbearbeiter möchte ich auf einen Knopf drücken ..."). Der Lösungsansatz von Urs Enzler ist der Richtige, da er das Erarbeiten der Lösung beim Team lässt. Die Voraussetzung dafür ist allerdings, dass in dem auch wirkliche Software-Entwickler sitzen und nicht nur Coding Monkeys. (siehe auch: "As a User" needs to stop).

• Mind the Product: Scaling Autonomous Teams

  Mit ihrer Aussage "It's all about Business Agility" gibt Debbie Wren scheinbar eine Gegenthese zu Ron Jeffries (weiter oben) ab. Wo sie wieder mit ihm zusammenkommt: um das zu erreichen ist (unter anderem) "technische Agilität" notwendig. Erst das, in Kombination mit Autonomie und Empowerment, macht Business Agility möglich.

Die verlorene agile Disziplin - Domain Driven Design (DDD)

Vor einiger Zeit gehörte Christoph Baudson zu einem Entwicklungsteam das ich coachen durfte. Deshalb freut es mich um so mehr, dass ich heute auf ihn, bzw. seinen Vortrag auf der Froscon 2017 verlinken kann.



Auch jenseits persönlicher Sympathie ist das Video sehenswert, da DDD in der Tat relativ selten diskutiert wird. Und wie Christoph richtig sagt: man muss es nicht als Konkurrenz zu Frameworks wie Scrum sehen sondern als mögliche Ergänzung.

Warum Konzerne nicht versuchen sollten agil zu werden

Bild: Max Pixel / Freegreatpicture - CC0 1.0

Es passiert jeden Tag. Überall auf der Welt. Immer wieder. In gepolsterten Sesseln um einen langen Konferenztisch sitzend schauen sich die Manager großer Konzerne tief in die Augen und versichern sich gegenseitig "Wir werden Agil". Sie treten vor ihre Belegschaft, schreiben Rundmails, geben Interviews und sprechen auf Kickoff-Veranstaltungen um die Botschaft hinauszutragen in das eigene Unternehmen. Die Mitarbeiter verstehen, sie haben den Auftrag Agil zu werden. Die Umsetzung beginnt. Und dann passiert das genaue Gegenteil.

Das Problem in vielen Organisationen ist, dass sie ein falsches Verständnis von Agilität haben. Agilität wird gleichgesetzt mit den Rollen und Meetings von Scrum, SAFe und Spotify. Gibt es in den IT-Teams statt Teamleitern Scrum Master? Check. In den Fachabteilungen statt Business Analysten Product Owner? Check. Der Statusbericht heisst jetzt Daily Standup? Check. Die Architektur- und QA-Teams heissen jetzt Gilden? Check. Das Problem: es sind die gleichen Rollen, Personen und Strukturen wie früher. Das bloße Umbenennen ändert gar nichts.

Was hier passiert ist nichts anderes als eine Umkehrung von Mittel und Zweck. Eigentlich sind agile Methoden nur ein Mittel um den eigentlichen Zweck zu erreichen: kurze Time to Market, hohe Reaktionsgeschwindigkeit, Vermeidung sinnloser Arbeit. Nur dafür wurden die Frameworks, Rollen und Events erfunden und nur wenn sie darauf ausgerichtet sind machen sie Sinn. Wenn sie stattdessen als Selbstzweck eingeführt werden ist dieser nicht mehr gegeben. Einen Product Owner zu benennen nur damit er da ist bringt niemandem etwas.

Um diese Zustände zurück auf die Füße zu bringen kann es sinnvoll sein die Begrifflichkeiten der Agilität fallenzulassen und den eigentlichen Zweck wieder in den Mittelpunkt zu stellen. Wenn kurze Time to Market, hohe Reaktionsgeschwindigkeit und Vermeidung sinnloser Arbeit erreicht werden sollen, dann kann man das auch so benennen. Und die dahinführenden Maßnahmen werden automatisch die sein müssen die man aus Scrum & Co kennt: Nähe zum Kunden, flache Hierarchien, schlanke Prozesse und Automatisierung sich wiederholender Tätigkeiten.

Am Ende ist es fast ein Paradoxon. Sich das Ziel zu setzen Agil zu werden führt viele Konzerne in eine Sackgasse. Auf diese Bezeichnung zu verzichten kann Agilität dagegen fördern.