Donnerstag, 31. Oktober 2019

Kommentierte Links (LIV)

Bild: Unsplash / Compare Fibre - Lizenz
  • Christopher Laine: Advice to Product Owners from a Developer

  • Eigentlich sollte es nicht der Idealfall sondern der Normalfall sein, dass auch die Mitglieder der (Scrum-)Entwicklungsteams den Arbeitsprozess als etwas sehen das für sie wichtig ist, dessen Sinn sie verstehen und an dessen Verbesserung sie arbeiten. Viel zu häufig wird darin aber nur "das was der Scrum Master macht" gesehen. Christopher Laine scheint die positive Abweichung davon zu sein, seine Ausführungen zeigen, dass er sich gründlich mit der Frage beschäftigt hat was er von seinen Product Ownern erwartet und was nicht. Besonders hervorzuheben: er sieht es ausdrücklich als Aufgabe des Teams an, dem PO ehrliches Feedback und Hilfe zu geben falls dessen Berufsausübung zu wünschen übrig lässt. Das kann man gar nicht genug unterstreichen.

  • Piet Hadermann: The Cost of Waiting for Feedback in Software Development

    Apropos Entwickler die sich Gedanken um die Verbesserung von Arbeitsprozessen machen. Piet Hadermann gehört ebenfalls dazu, und er hat sich eines wahren Klassikers angenommen - den negativen Effekten von zu viel Multitasking, bzw. den Möglichkeiten dem entgegenzuwirken. Seine naheliegenden Erkenntnisse: Work in Progress-Limits und Sofortbehebung auftretender Fehler können wirkungsvolle Massnahmen sein um die Entwicklungsgeschwindigkeit zu beschleunigen. Aber auch weniger naheliegende Erkenntnisse sind dabei. Dass auch kurze Sprints mit unveränderbarem Inhalt eine Form der Work in Progress-Limitierung sind ist eine Einsicht die viele Teams noch nicht haben. Und neben all diesen ernsten Themen enthält der Artikel auch noch zwei kleine Comics, von denen einer lustig und einer sogar wirklich witzig ist.

  • Carolin Wahnbaeck: Wo Zara und H&M zu langsam sind

    Man könnte lange darüber diskutieren ob das was Carolin Wahnbaeck in diesem Artikel beschreibt Lean Management, Business Agility, beides oder etwas ganz anderes ist. Viel wesentlicher ist: die "Ultrafast Fashion Companies" haben es offensichtlich geschafft eine Time to Market zu erreichen die deutlich unter einem Monat liegt - und das nicht etwa in der IT sondern in der Textilproduktion. Die dafür angewandten Erfolgsrezepte scheinen zunächst schlicht und bekannt - Optimierung der Lieferketten, Aufgreifen von Trends und Reagieren auf Änderungen der Nachfrage. Wer jemals versucht hat daran zu arbeiten weiss aber, dass dafür ein erheblicher Aufwand nötig ist. Bemerkenswert auch ein Nebenaspekt: da weniger unverkaufte Kleidung weggeworfen wird kann Ultrafast Fashion sogar umweltschonend sein.

  • Dave Snowden: Separated by a common language?

    Zu den (agilen) Frameworks die mich seit Jahren faszinieren gehört die Cynefin. Dass rund um etwas scheinbar so Schlichtes eine solche Menge an Ideen, Praktiken, Erläuterungen und Anwendungen entstehen kann ist bemerkenswert. Das ist besonders dann gegeben wenn dabei auch noch eine "Sekundärerkenntnis" entsteht, so wie in diesem Fall. Dave Snowdens Abgrenzung von Cynefin zur äusserlich ähnlichen aber inhaltlich völlig anderen Stacey-Matrix ist an sich schon interessant, der zusätzliche Aha-Effekt kommt aber dadurch zu Stande, dass er en passant erklärt, dass besagte Stacey-Matrix in Wirklichkeit gar nicht so aussieht wie allgemein angenommen. Das was meistens so bezeichnet wird ist eine vereinfachte Version, die Zimmermann-Matrix. Wieder etwas gelernt.

  • John Clopton: The Scrum is for Projects, Kanban is for Maintenance Myth

    In der Tat ein verbreiteter Mythos, und ein irreführender dazu. Dass Scrum eher zur Anwendungsentwicklung passt und Kanban eher zum Anwendungsbetrieb ist eine Aussage an der man erkennen kann, dass diese Konzepte nur oberflächlich verstanden wurden. John Clopton übernimmt die ehrenvolle Aufgabe die Dinge wieder geradezurücken..

Montag, 28. Oktober 2019

Erosion

Bild: Wikimedia Commons / Thomas Wilken - CC BY-SA 3.0
Vermutlich war es eine der interessantesten Diskussionen mit denen ich in letzter Zeit beteiligt war: was ist die häufigste Art der Abschaffung von agilen Transitionen oder Arbeitsweisen? Eine spontane Management-Entscheidung alles bisher Erreichte rückgängig zu machen? Eine bewusste Verfälschung oder Überladung der Methodik? Versehentlicher Murks? Widerstand der Mitarbeiter? Über-Optimierung? All das kommt vor, und doch glaube ich, dass ein anderes Phänomen häufiger ist - Erosion.

Unter Erosion (von lateinisch erodere, "abnagen") versteht man in der Geologie das langsame Abtragen von Erde oder Gestein durch Regen und Wind. Dieser Prozess verläuft aufgrund seiner Kleinteiligkeit und Langsamkeit nahezu unsichtbar - nach und nach verschwinden so kleine Mengen von der Oberfläche, dass der Effekt nur über Langzeitbeobachtungen feststellbar ist. Im Vergleich weit auseinanderliegender Zeiträume ist der Unterschied aber offensichtlich: von einstmals massiven Bergen und Felsen ist nicht mehr viel übrig.

Im übertragenen Sinn lässt sich Erosion auch in Organisationsformen betrachten. Am Anfang beginnt es meistens harmlos, fast unscheinbar. Die Timeboxes dauern ein bisschen länger als geplant, die Punkte auf den Zetteln werden manchmal vergessen, bei "offensichlichen" User Stories wird auf den Zwecksatz verzichtet, etc., etc., etc. Die Gemeinsamkeit mit der geologischen Erosion: auch hier erscheint jede einzelne Abtragung so klein, dass es sich kaum lohnt über sie zu reden. Und tatsächlich - ist es wirklich von Bedeutung wenn das Daily Standup 19 Minuten dauert statt 15?

Die zunächst un-intuitive Antwort: ja, es ist von Bedeutung, und zwar von grosser. Die vielen kleinen, scheinbar unbedeutenden Regelverletzungen haben Folgen. Wenn begonnen wird Vereinbarung zu verletzen schwindet mit jedem mal die Hemmung es erneut zu tun (Broken Window-Effect), wenn sich diese Regelverstösse als "pragmatisches Vorgehen" etablieren erfolgt dadurch eine Erziehung zur Normverletzung und wenn sich auch diese ohne Widerspruch ausbreitet droht als Endzustand der Konzern-Anarchismus. Und selbst wenn es kleinlich klingt - all das entsteht durch für sich genommen kaum erwähnenswerte Abweichungen.

Um nicht am Ende dieses Erosionsprozesses mit einem abgenagten Rest des ursprünglich agilen Prozesses dazustehen empfiehlt es sich regelmässig in Retrospektiven darüber zu refektieren ob das Erodieren schon irgendwo begonnen hat. Und sollte das der Fall sein ist es hochgradig sinnvoll sich gemeinsam Gegenmassnahmen zu überlegen, durch die verhindert wird, dass die gemeinsame Arbeitsgrundlage langsam weiter wegbröckelt.

Donnerstag, 24. Oktober 2019

Logistische Intelligenz

Mal wieder Gunther Dueck. Gewohnt eloquent werden die möglichen Dysfunktionen agiler Konzern-Transitionen aufgezählt und analysiert. Für meinen Geschmack etwas zu sehr focussiert auf die negativen Aspekte, aber trotzdem sehr unterhaltsam.

Montag, 21. Oktober 2019

Delivering twice the value at half the cost

Bild: Flickr / Peter Linke - CC0 1.0
Einmal mehr hat sich der bekannteste Sales-Pitch von Scrum beinahe unbemerkt geändert. Bereits 2018 schwenkte Jeff Sutherland, der Verfasser von Doing twice the work in half the time um auf Delivering twice the value in half the time, aber auch das ist mittlerweile nicht mehr der neueste Stand. Der ist seit gestern Delivering twice the value at half the cost. Man kann das begrüssen, ähnlich wie die letzte hat auch diese Neuformulierung das Potential weniger missverständlich zu sein.

Da die bisherigen Formulierung nur in ihrem hinteren Teil verändert wurde soll es hier nur um den gehen (zum ersten Teil siehe hier), und zwar zunächst um die alte Version. Liefert Scrum tatsächlich in der Hälfte der Zeit? Die Antwort: nicht zwingend, genau das ist es was missverständlich ist. Ein Vergleich der unterschiedlichen Ansätze zeigt warum.

Zuerst zu Scrum: sein Anspruch ist, durch bessere Strukturen und Prozesse in kurzer Zeit lieferfähig sein. Zum einen bedeuten crossfunktionale Teams weniger Übergaben und weniger Koordinationsaufwand, zum anderen kann die Integration der Abnahme-, Integrations- und Regressionstests in jeden einzelnen Sprint die vor dem Projektende stattfindende Integrations- und Bugfixing-Phase entfallen lassen. Zusätzlich verhindert das schnelle Beheben der Fehler, dass diese sich gegenseitig verstärken und dadurch aufwändiger zu beheben sind. So verkürzt sich die Gesamtlaufzeit, wodurch das ursprüngliche Versprechen in half the time zustande kam.

Auf der anderen Seite stimmt aber auch: klassisches Projektmanagement kann "ambitionierte Lieferfristen" ebenfalls immer wieder erreichen, und zwar mit einer einfachen Massnahme. Diese besteht darin, dass zur Erreichung der gesetzten Ziele mehr Personal in das Projekt gepumpt wird1. Mit mehr Leuten kann dann versucht werden mehr zu schaffen, entweder durch parallele Arbeit gleichartiger Teams oder durch ein überlappendes Vorgehen der Teams die den unterschiedlichen Phasen zugeordnet sind. Es bleibt daher die Frage - wenn beide Ansätze schnell liefern können, macht der Umstieg auf Scrum überhaupt einen Unterschied?

Dass die Antwort darauf Ja ist liegt in den entstehenden Kosten begründet. Die Faktoren die in Scrum zu schnellem Arbeitsfortschritt beitragen sind im Gegensatz zum klassischen Projektmanagement nicht mit zusätzlichem Personalaufwand verbunden. Da dieser aber gleichbedeutend mit zusätzlichen Ausgaben ist bedeutet das, dass die Entwicklung im Vergleich billiger ist. Für praktisch jedes Vorhaben dürfte das ein wesentliches Argument sein, das Budget ist schliesslich in jedem Vorgehen ein entscheidender Faktor. Und damit erklärt sich auch die Sinnhaftigkeit der neuen Formulierung Delivering twice the value at half the cost.


1Dass dieses Vogehen zu anderen Problemen führen kann ist nochmal ein Thema für sich

Donnerstag, 17. Oktober 2019

The (Toyota) Flow System

Grafik: Toyota Connected / Thurlow, Turner, Rivera - CC BY 4.0 (Link mittlerweile tot, siehe unten)
[Edit: der Name hat sich geändert, siehe ganz unten]
Manchmal kommen grosse Neuigkeiten überraschend an. In einem zunächst eher unspektakulären Artikel erwähnt der Forbes-Journalist Steve Denning etwas Bemerkenswertes: nach 70 Jahren hat die Firma Toyota ihr legendäres Toyota Production System (den Ursprung des Lean Management) weiterentwickelt zu etwas Neuem, dem Toyota Flow System. Der Name ist fast gleich geblieben, der Inhalt dagegen hat sich spürbar verändert - es finden sich jetzt deutliche Spuren agiler Frameworks in ihm.

Vor allem in der linken Säule taucht einiges auf was aus der agilen Welt bekannt ist. Scrum, the Toyota Way hat bereits 2018 für Aufsehen gesorgt, und auch andere bekannte Konzepte finden sich hier, etwa Cynefin und OODA-Loops. Die mittlere Säule greift eher Ideen aus dem Coaching-Umfeld auf, wie z.B. psychologische Sicherheit, aktives Zuhören und Mentoring, während die rechte Säule sich auf die sozialpsychologischen und organisatorischen Aspekte der Teamarbeit konzentriert. Zusammen mit den beiden Grundlagen Toyota Way und Toyota Production System kommt ein Gesamtbild zu Stande, dessen Einzelbestandteile es ermöglichen genug Lesestoff für Wochen zusammenzugoogeln. Auf jeden Fall spannend.

Nachtrag 07.11.2019
Passend zum Thema ein Video. Nigel Thurlow, Chief of Agile bei Toyota Connected, gibt einen Einblick in die agilen Arbeitsweisen seiner Firma:



Nachtrag 06.07.2021
Anscheinend hat sich das Framework mittlerweile von Toyota gelöst, es ist jetzt nur noch "The Flow System™". Dementsprechend ist auch die Überschrift der Visualisierung angepasst worden:
Grafik: Flowguides.org - CC BY 4.0 (zum Vergrößern klicken)

Montag, 14. Oktober 2019

Frameworks und Werte

Bild: Wikimedia Commons / ChinaFlag - CC0 1.0
Wer schon einmal in einem Workshop war, in dem es darum ging agile Vorgehensmodelle zu erklären oder ihre Einführung vorzubereiten, wird dort mit grosser Wahrscheinlichkeit auch über Werte gesprochen haben. Egal ob Extreme Programming (Communication, Simplicity, Feedback, Courage,  Respect), Scrum (Courage, Commitment, Focus, Openness, Respect) oder Kanban (Transparency, Balance, Collaboration, Customer Focus, Flow, Leadership, Understanding, Agreement, Respect) - jedes bekannte Framework betont, dass es wertebasiert ist. Aber warum ist das so?

Die Antwort hat mit genau dieser Selbstbezeichnung zu tun. XP, Scrum & Co legen Wert darauf, keine Methoden zu sein, sondern Frameworks, wohinter sich ein völlig anderes Konzept verbirgt. Während durch Methoden relativ genaue Vorgaben erfolgen, wer wann was mit welchem Ziel zu tun hat, wollen die agilen Frameworks genau das vermeiden. Die darunterliegende Annahme: je strikter die Vorgaben, desto unwahrscheinlicher, dass sie der komplexen Realität gerecht werden. Im Zweifel schaden sie sogar mehr als sie nutzen, da plötzlich der Plan nicht mehr zur Realität passt.

Um derartige Konstellationen zu vermeiden lassen die Frameworks bewusst grosse Lücken, die jeder so füllen kann, wie er es für sinnvoll hält. Beispiele dafür sind Anforderungsformate und die Abnahmen fertiger Arbeit: XP, Scrum und Kanban gehen nicht darauf ein wie sie ausgestaltet sein sollen, jedes Team kann das für sich selbst festlegen. Das daraus entstehende Problem - diese Offenheit bringt das Risiko mit sich, dass versehentlich unflexible und bürokratische Strukturen (wieder)eingeführt werden, etwa indem besonders detaillierte Spezifikationen möglichst früh im voraus verfasst werden, die dann zu erfüllen sind.

Die Lösung für dieses Dilemma sind die zu Beginn genannten Werte. Sich im Zweifel an ihnen zu orientieren lässt den Beteiligten genug Freiraum, um den Arbeitsprozess nach ihren Bedürfnissen auszugestalten, zeigt ihnen aber auch, wo sie sich von der angestrebten Agilität entfernen. Um beim Beispiel der Abnahmen anhand von lange im voraus verfassten Detailspezifikationen zu bleiben - wer ernsthaft Simplicity, Openness und Balance als Werte verfolgt wird sich von diesem Vorgehen schnell verabschieden.

Um zuletzt einen häufigen Einwand aufzugreifen: natürlich bedeutet das auch, dass der Arbeitsprozess weniger stabil ist und häufiger geändert werden muss, nämlich immer dann, wenn er sich aufgrund geänderter Realität plötzlich im Widerspruch zu den Werten befindet. Aber das ist etwas Gutes - es verhindert, dass die Menschen durch unnötige Vorgaben eingeengt werden.

Donnerstag, 10. Oktober 2019

Die agile Filterblase

Bild: Flickr / Serge Melki - CC BY 2.0
Eine Frage die beim letzten bonner Scrumtisch intensiv diskutiert wurde war die: "Befindet sich die agile Community in einer Filterblase?" Natürlich lautet die Antwort im Zweifel immer "Kommt darauf an", aber ganz von der Hand zu weisen ist es nicht - eine Abkapselungstendenz ist da. In dem Punkt waren sich die Teilnehmer einig.

Zunächst zur Begrifflichkeit. Filterblasen sind ein Konzept aus der Kommunikationswissenschaft in dem davon ausgegangen wird, dass durch technische Mechanismen (personalisierte Suchmaschinen) bewussten Medienkonsum (Echokammer) oder unbewusste psychologische Vorgänge (Confirmation Bias) vor allem die Informationen wahrgenommen werden die die eigene Meinung bestätigen. Abweichende Ansichten werden ausgeblendet.

Auf die agile Community übertragen erkennt man deutliche Züge von Filterblasenhaftigkeit. Die bekannteren Agilisten gehen auf die gleichen Konferenzen, lesen die gleichen Autoren, hören die gleichen Podcasts, abonnieren die gleichen Youtube-Kanäle, folgen sich gegenseitig auf Twitter und Facebook und kennen sich untereinander schon seit Jahren. Das lässt sich sowohl auf der internationalen als auch auf der nationalen und lokalen Ebene beobachten und zeigt sich daran, dass viele der eigentlich fachlichen Zusammenkünfte mittlerweise einen Klassentreffen-Charakter haben.

Die damit verbundenen Effekte sind bedenklich: bestimmte Glaubenssätze werden kaum noch hinterfragt (z.B. "mittleres Management ist überflüssig"), bestimmte Vorzeigeunternehmen wie Spotify werden gehypt während andere wie Mercadona trotz hochinnovativer Ansätze nahezu unbekannt sind, die Berührungspunkte zu verwandten Disziplinen wie dem klassischen Projektmanagement nehmen ab, wichtige Themenfelder wie Finance oder Legal werden weitgehend ignoriert.

Das zu ändern liegt bei jedem Einzelnen selbst. Warum nicht mal auf eine Projektmanagement-Konferenz gehen, ein BWL-Buch lesen oder sich mit Lean Manufacturing beschäftigen? Und wenn das zu weit ausserhalb der eigenen Komfortzone ist - warum nicht auf dem nächsten Agile Meetup ein ungewohntes Thema einbringen wie Compliance, Budgeting oder Procurement? Das würde nicht nur zur Weitung des eigenen Horizonts führen sondern auch neue Teilnehmer anlocken. Auch so liesse sich die agile Filterblase öffnen.

Montag, 7. Oktober 2019

ScrumBut und ScrumAnd

Bild: Flickr / David Molloy - CC BY 2.0
So schlicht Scrum auch ist, so viel kann man bei seiner Umsetzung falsch machen. Das meiste davon dürfte unbewusst passieren und den Handelnden gar nicht bewusst sein, also in die Kategorie fallen für die sich der schöne Name Cargo Cult eingebürgert hat. Es gibt aber auch Fälle in denen absichtlich am Vorgehen herumgedoktort wurde. Auch für die beiden hierbei möglichen Varianten gibt es mittlerweile Bezeichnungen: ScrumBut und ScrumAnd.

ScrumBut ist abgeleitet von der Aussage "We do Scrum, but ...", also "Wir machen zwar Scrum, aber ...". Hinter diesem "aber" verbergen sich dann die Einschränkungen denen das Vorgehen unterworfen wurde. "Wir machen zwar Scrum, aber nur auf Teamebene.", "Wir machen zwar Scrum, aber ohne Scrum Master." oder "Wir machen zwar Scrum, aber nur für die IT." sind klassische ScrumBut-Aussagen, wie man sie überall dort wiederfinden kann wo vor einer wirklichen Einführung zurückgeschreckt wurde.

Das irritierende an dieser Variante - selbst bei offensichtlich eingeschränktem Umfang bleiben die an Scrum gerichteten Ansprüche meistens unverändert hoch. Dass auch diese proportional zum Rückbau der Methode sinken müssten wird selten eingesehen, und selbst wenn es erkannt wird kann eine überzogene Erwartungshaltung dazu führen, dass eine ernsthafte Organisationsveränderung blockiert wird. "Das soll erstmal auf Teamebene für Verbesserung sorgen bevor wir es woanders einführen" entspricht etwa der Aussage "Die Glühbirne soll erstmal zeigen, dass sie Licht machen kann, bevor sie Strom bekommt." Kann man so sehen, bringt einen aber nicht weiter.

ScrumAnd geht dagegen ist die genau andere Richtung: Scrum wird zwar wie vorgesehen eingeführt (zumindest weitgehend), gleichzeitig aber mit zusätzlichen Inhalten überfrachtet. Ein Beispiel dafür wäre ein Geschäftsführer, der zusätzlich die Rolle eines Product Owners übernimmt (und aus Zeitmangel fast alle damit verbundenen Tätigkeiten ins Team delegiert). Ein anderes Beispiel wäre die Integration so vieler Randaspekte in die Produktentwicklung (Werbekampagnen, First Level Support, etc.), dass das Team kaum noch focussiert arbeiten kann.

Rein formal lässt sich gegen diese Auslegung in vielen Fällen nichts sagen, der Scrum Guide erwähnt zwar nichts Derartiges, untersagt es aber auch nicht. In der Realität führt eine solche Überladung erfahrungsgemäss aber fast immer zu Reibungsverlusten, Zielkonflikten und Motivationsrückgang. Gleichzeitig kann es auch im Fall von ScrumAnd zu unrealistischen Erwartungshaltungen kommen. "Aber in den Regeln steht doch, dass der PO delegieren darf und dass dass Team crossfunktional sein muss." wäre eine klassische Begründung dafür, auch in solchen Konstellationen reibungslose Performance zu erwarten.

Sowohl bei ScrumAnd als auch im Fall von ScrumBut sind die Erwartungshaltungen auch der Punkt an dem angesetzt werden sollte um an Verbesserungen zu arbeiten. Dass stark beschnittene oder überfrachtete Vorgehensweisen ihre positiven Effekte nicht voll entfalten können wird fast jeder nachvollziehen können, wer an diesen Effekten interessiert ist wird daher erkennen, dass er ein Zurückfahren der Missstände zumindest erwägen muss. Und wer von den alten Strukturen und breiten Aufgabenspektren nicht ablassen kann (wofür es gute Gründe geben kann) dem kann man vermitteln, dass Scrum seinen Ansprüchen nicht genügen wird und er einen anderen Ansatz ausprobieren sollte.

Dass auch ein anderer Ansatz mit hoher Wahrscheinlichkeit an diesen Ansprüchen scheitern dürfte steht dann auf einem anderen Blatt, hat aber mit den beiden hier beschriebenen Scrum-Antipattern nichts mehr zu tun.

Freitag, 4. Oktober 2019

Die fünf Zeitdiebe

Die Ähnlichkeit zwischen den fünf Zeitdieben und den Mudas des Toyota Production System dürfte kein Zufall sein, beiden ist die Herkunft aus dem Lean Thinking deutlich anzumerken. Dementsprechend präsentiert Dominica DeGrandis hier nichts völlig Neues, betrachtet einige Aspekte aber aus einem neuen Blickwinkel.