Donnerstag, 14. November 2019

Three Ways to break Hierarchy

FS
Es ist eines der grossen Mantras nahezu jedes Agile Coaches: versucht nicht Spotify zu kopieren, das wird nicht funktionieren und nicht gut ausgehen, der Ansatz ist zu spezifisch und zu volatil. Inspirieren lassen kann man sich aber durchaus, zum Beispiel durch diesen Vortrag zum Thema der teamübergreifenden Koordination.



Und um es noch einmal ganz klar zu sagen: jeder der nach dem Ansehen dieses Videos reflexartig auch bei sich "Technical Steering Groups" und "Technology Architecture Groups" einführen will hat nichts, aber auch wirklich nichts verstanden.

Dienstag, 12. November 2019

Relativ erfolgreich

FS
Bild: Pixabay / Engin Akyurt - CC0 1.0
Es war einer der seltenen Fälle in denen ich einen Transitionsbegleitungs-Auftrag abgebrochen habe. Trotz Schulungen, Lessons Learned-Prozessen und monatelanger Begleitung stürmte der IT-Chef noch immer die Plannings, liessen die Teams noch immer die Retrospektiven ausfallen und benutzten die POs noch immer die Backlogs als to do-Listen. Besserung war nicht in Sicht. Als "letzte Amtshandlung" machte ich eine Feedback-Runde mit allen Projektmitgliedern und bekam von einigen eine erstaunliche Rückmeldung: sie wären noch nie in einem so gut laufenden Projekt gewesen.

Da ich meine Aufgaben bereits übergeben hatte und nur noch auf letzte Bürokratieschritte warten musste nutzte ich die verbleibende Zeit um mit allen die sich so geäussert hatten vertiefende Gespräche zu führen. Am Anfang war ich verunsichert - waren mir Fortschritte entgangen? Hatte ich zu hohe Ansprüche angelegt? Wie konnte es zu einer derartig unterschiedlichen Wahrnehmung kommen? Die Antworten die ich bekam hätten auch von Albert Einstein kommen können. Natürlich wäre die agile Transition kein voller Erfolg gewesen, aber relativ erfolgreich, das schon.

Allen war zwar bewusst, dass sie in ihrem Arbeitsumfeld von erheblichen Dysfunktionen umgeben waren und dass Teile des Managements diese bewusst nicht abschaffen wollten (mehr zu den  dahinter legenden Beweggründen steht hier), im Vergleich zu dem was in der Vergangenheit in anderen Projekten passiert wäre wären die Verbesserungen aber unübersehbar: mehr Transparenz über den Arbeitsumfang, kürzere Planungszeiträume mit regelmässigen Anpassungen der bisherigen Pläne, engere Zusammenarbeit zwischen Entwicklung und Test.

Die Gegenüberstellung zeigt die unterschiedlichen Sichtweisen. In Relation zu meinem Agile Coach-Anspruch an eine Transition wurden wesentliche Elemente bewusst weggelassen: Pull-Prinzip, Inspect & Adapt, regelmässige Auslieferung von Kundenmehrwert. In Relation zu vergangenen Erfahrungen der Projektmitglieder waren aber einige der schlimmsten Zustände verschwunden oder zumindest erkennbar zurückgegangen: kryptische Anforderungen, lang andauernde Wasserfall-Phasen, starke Abkapselung der verschiedenen organisatorischen Silos.

Dementsprechend wurde auch der Erfolg unterschiedlich bewertet. Aus meiner Sicht war die agile Transition relativ erfolglos, da nach wenigen initialen Fortschritten der Verbesserungsprozess angehalten wurde und nicht wieder ans Laufen kam, aus der Sicht der anderen war er relativ erfolgreich, da diese Fortschritte zum besten Arbeitsmodus geführt hatten an den sich alle Beteiligten erinnern konnten. Wir konnten gegenseitiges Verständnis herstellen - die Anderen verstanden warum ich gehen wollte, ich verstand warum sie gerne blieben.

Rückblickend gehören die letzten Tage auf diesem Projekt zu den erkenntnisreichsten meiner Karriere. Erfolg und Misserfolg betrachte ich seitdem deutlich differenzierter, und wenn ich Einsätze beende fällt mir nicht mehr nur ins Auge wo noch Fortschritte fehlen sondern auch wo bereits welche gemacht wurden.

Samstag, 9. November 2019

Freiheit und Sinnhaftigkeit

FS
Bild: National Guard / University of Minnesota IAS - Public Domain
Zeit für einen Blick über den Tellerrand. Am heutigen 9. November können wir den 30. Jahrestag des Mauerfalls feiern. Nach so langer Zeit dürften die damaligen Ereignisse für viele Menschen nicht mehr als eine Kindheitserinnerung sein - wenn sie damals überhaupt schon gelebt haben. Vielleicht macht es gerade deshalb Sinn ein bisschen über das zu reflektieren was damals passiert ist.

Zuerst eine kurze Anmerkung zur persönlichen Betroffenheit. Ich gehöre zwar zu den erwähnten Menschen die damals noch im Kindesalter waren (und wohnte damals nicht im Osten), mir waren aber später tiefere Einblicke in diese Zeit vergönnt. Während meines Studiums durfte ich eine Zeit lang in der Behörde der Bundesbeauftragten für die Unterlagen des Staatssicherheitsdienstes der ehemaligen Deutschen Demokratischen Republik, der BSTU, arbeiten, mit Zeitzeugen sprechen, Akten lesen und dabei helfen die Geschichte aufzuarbeiten.

Was mir aus diesen Akten, aber auch aus Gesprächen mit den Bürgerrechtlern der ehemaligen DDR in Erinnerung geblieben ist waren die Gründe für die Rebellion gegen das sozialistische Regime, die den Mauerfall auslöste. Neben sekundären Aspekten (Verwandte im Westen, Fehlen von hochwertigen Konsumgütern) waren es vor allem zwei die immer wieder genannt wurden: der Wunsch nach Freiheit und der Wunsch nach Sinnhaftigkeit, oder von der anderen Seite betrachtet die Ablehnung von Diktatur und Planwirtschaft.

Der Wunsch nach Freiheit erschliesst sich sofort. Die Bürger der DDR waren durch Mauer und Stacheldraht im eigenen Land eingesperrt und wurden regiert von einem diktatorischen Regime, das nicht durch Wahlen legitimiert war und abweichende Meinungen durch Zensur, Diskriminierung und Gefängnisstrafen unterdrücken wollte. Dass sich dagegen aufgelehnt wurde lässt sich problemlos nachvollziehen, ähnliche Reflexe dürfte jeder verspüren, der sich in derartigen Umständen wiederfindet.

Erst auf den zweiten Blick nachvollziehbar ist der zweite Grund für die Auflehnung, der Wunsch nach Sinnhaftigkeit. Bedingt durch die planwirtschaftliche Volkswirtschaft war jeder Bürger der DDR permanent von der dadurch verursachten Ineffizienz betroffen. Diese wirkte sich spürbar im Fehlen bestimmer Güter (z.B. Autos) aus, noch verheerender war allerdings die offensichtliche Unsinnigkeit der eigenen Arbeit. Dem Verrotten der Ernten, der Erstellung schlechter Produkte und der Bürokratisierung einfachster Abläufe waren die Menschen nicht nur ausgeliefert, sie mussten sich wider besseres Wissen an ihrer Herbeiführung beteiligen. Auch die Rebellion dagegen ist verständlich.

Dass die Bürger der DDR bereit waren im Kampf für Freiheit und Sinnhaftigkeit selbst Gefängnis, berufliche Diskriminierung und körperliche Gewalterfahrung in Kauf zu nehmen zeigt wie stark die Sehnsucht nach ihnen ist. Auch heute, 30 Jahre später, ist es sehr zu empfehlen sie nicht einzuschränken sondern gemeinsam mit den Menschen nach ihnen zu streben. Nicht nur in der Politik sondern auch in Wirtschaft und Gesellschaft.

Dienstag, 5. November 2019

Welches Scrum darfs denn sein?

FS
Bilder: Flickr / Charlie / Royskeane - CC BY 2.0
"Wir machen Scrum" ist eine Aussage die man mittlerweile von sehr vielen Teams hören kann. Schaut man sich einzelne davon näher an lassen sich allerdings grosse Unterschiede erkennen, zum Teil sogar so grosse, dass praktisch keine Vergleichbarkeit mehr gegeben ist. Das hat natürlich in vielen Fällen mit der freien Wahl der optionalen Bestandteile, mit Missverständnissen und mit Cargo Cult zu tun, selbst wenn man das weglässt bleibt aber noch eine erstaunliche Vielfalt übrig. Der Grund dafür - es gibt mehrere Varianten von Scrum, die sich z.T. deutlich unterscheiden:

Ur-Scrum

Die fast vergessene initiale Variante von Takeuchi und Nonaka, bzw. von DeGrace und Stahl. Nahezu alles was heute als Erkennungszeichen von Scrum Teams gilt fehlt hier noch. Keine Scrum Master, keine Product Owner, keine Sprints, keine Backlogs, keine Dailies, keine Sprint Reviews, keine Retrospektiven. Stattdessen findet sich vieles was heute eher zu den Grundlagen von Agilität gehört: crossfunktionale, stabile Teams, enger Kundenkontakt, Experimentier- und Fehlerkultur. In der Arbeitswelt kaum noch anzutreffen, mit Ausnahme von Teams die aus historisch interessierten Methoden-Nerds bestehen.

"Historisches" Scrum

Schon näher am "aktuellen" Scrum, aber noch nicht ganz da. Da Scrum regelmässig weiterentwickelt wird (seit 2010 im Rahmen des Scrum Guide) kommt es regemässig dazu, dass Teams auf einem älteren Entwicklungsstand stehen bleiben. Bei jüngeren Entwicklungen macht das kaum einen Unterschied, bei älteren kann der Unterschied deutlich sichtbar sein. Was z.B. noch immer verbreitet ist sind die "Pig" und "Chicken"-Rollen und verpflichtende Burndown Charts, aber auch andere "Relikte" kommen immer wieder vor. Vor allem in Teams oder Firmen anzutreffen die schon seit mehreren Jahren nach Scrum arbeiten.

Scrum by the Book

Der "Idealfall". Ist zu finden bei Teams die sich an der aktuellsten Form des Scrum Guide ausrichten und ihr Vorgehen nach jeder Aktualisierung anpassen. Ein Indikator dafür ist z.B. die (aktuell noch) neue Regel, dass das Sprint Backlog auch Massnahmen zur Prozessverbesserung enthalten sollte. Voraussetzung ist, dass es mindestens ein Teammitglied gibt, dass sich über aktuelle Entwicklungen auf dem Laufenden hält und diese im Team einbringt (im Normalfall ist das der Scrum Master). Im weiteren Sinn gehören auch die Skalierungsframeworks LeSS (Large Scale Scrum) und Nexus zu dieser Kategorie, da beide Wert darauf legen kaum zusätzliche Prozesse und Strukturen einzuführen und stattdessen "Scrum auf sich selbst anzuwenden".

ScrumBut / ScrumAnd

Leider der Normalfall. Berechtigt oder unberechtigt gibt es in vielen Firmen die Überzeugung, dass Scrum by the Book dort nicht funktionieren würde. Die Folgen: Weglassungen (ScrumBut) und/oder Überfrachtungen (ScrumAnd). Zu bemängeln sind in derartigen Zusammenhängen vor allem zwei Dinge - zum Einen, dass der Begriff Scrum auch dann noch benutzt wird wenn wesentliche Voraussetzungen und Kernelemente entfernt wurden, zum Anderen, dass häufig die (irrationale) Erwartungshaltung vorherrscht trotz erheblicher Eingriffe noch immer den maximalen Umfang möglicher Verbesserungen erwarten zu können.

Verschlimmbessertes Scrum

Zum Glück ein zurückgehender Trend. Getrieben von falschem Verständnis oder von kommerziellen Interessen wurden ab ca. 2010 immer wieder scheinbare (und falsche) Widersprüche konstruiert. Scrum wäre ja toll, würde sich aber bestimmte Aspekte (z.B. Security) nicht berücksichtigen, wäre nicht geeignet für grosse Unternehmen, etc. Als Lösung wurden scheinbare Weiterentwicklungen wie Secure Scrum, Reliable Scrum, Utra Scrum [sic], Scrum 2.0 oder Scrum 3.0 angeboten, die aber fast immer nur bürokratisierte oder verwässerte Abweichungen ohne erkennbaren Mehrwert sind. In gewisser Weise eine weitere Form von ScrumAnd. Ausschliesslich bei einzelnen Beratungsunternehmen zu finden.

Kastriertes Scrum

Der grosse zunehmende Trend der letzten Jahre. Seit etwa 2013 gibt es immer wieder Versuche Scrum in stark deskriptive oder Top Down-getriebene Projektmanagement-Methoden einzubinden. Die grosse Gemeinsamkeit - Scrum wird in diesem Zusammenhang nur als Arbeitsmodus einzelner Umsetzungsteams gesehen, die gleichzeitig nur ein untergeordneter Teil von grösseren Planungs- und Kontrollstrukturen sind (bekanntestes Beispiel ist SAFe). Bedingt dadurch sind zwei der wichtigsten Eigenschaften nicht mehr gegeben: Product Ownership und Process Ownership. In gewisser Weise eine weitere Form von ScrumBut, aber mit Literatur, Zertifizierungen, Konferenzen, etc.

Scrum@Scale / Scrum the Toyota Way

Zwei relativ neue und in ihrer Entstehung eng verknüpfte Scrum-Varianten (Scrum@Scale ist ein Skalierungsframework von Scrum-Pionier Jeff Sutherland, Toyota Connected eine der ersten Firmen die es eingesetzt hat). Das Besondere an ihnen: anders als in den weiter oben genannten Skalierungsframeworks LeSS und Nexus wird das untere und mittlere Management nicht obsolet sondern organisiert sich selbst in "Meta-Scrum-Teams" (Produktmanagement) und "Scrum of Scrums-Teams" (Prozessmanagement). Für die Toyota-Kultur mit ihrem stark auf die Team-Unterstützung ausgerichteten Management-Stil sicher passend, spannend wäre ob es auch woanders funktioniert.

Und noch mehr ...

Bei weiterem Suchen würde man mit Sicherheit noch weitere Varianten von Scrum finden, gute, schlechte und viele die irgendwo in der Mitte sind. Wichtig ist es sich über die Unterschiede im Klaren zu sein, denn eines ist angesichts dieser Vielfalt sicher: "Wir machen Scrum" ist zu wenig Information um zu erkennen was genau da gemacht wird.

Donnerstag, 31. Oktober 2019

Kommentierte Links (LIV)

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

FS
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

FS
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

FS
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

Toyota Flow System

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

Grafik: Toyota Connected / Thurlow, Turner, Rivera - CC BY 4.0 (zum Vergrößern klicken)
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:

Montag, 14. Oktober 2019

Frameworks und Werte

FS
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

FS
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

FS
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

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

Montag, 30. September 2019

Kommentierte Links (LIII)

FS
  • Troy Magennis: Story Point Velocity or Throughput Forecasting: Does it matter?

  • In Bezug auf das in der (IT-)Kanban-Bewegung beliebte statistikbasierte Forecasting bin ich gleichermassen Fan und Skeptiker. Natürlich hat eine auf der Story Point-Velocity beruhende Planung grosse Schwächen, von denen Troy Magennis hier einige aufzählt. Zu beachten ist dabei aber: er geht von nicht-idealen agilen Teams aus, die aufgrund nicht gegebener Crossfunktionalität und fehlender Focussierung starke Abhängigkeiten nach aussen haben. Das ist zwar durchaus realistisch, völlig unabhängige Teams sind selten. Umgekehrt wird aber bei dem als Alternative vorgeschlagenen Durchsatz-Modell nicht erwähnt, dass auch das ideale Rahmenbedingungen braucht, z.B. ein stabiles System, in dem Arbeiten nicht abgebrochen werden und in dem das Leistungsvermögen der Teams nicht schwankt. Auch das ist in der Realität aber selten. Ein bisschen wird hier also mit ungleichem Mass gemessen. Letzten Endes gilt für beide Ansätze, dass sie Unplanbares nicht planbar machen können, weshalb man sich von Anfang an auf Planänderungen einstellen sollte.

  • François Knuchel: Why aren’t Lean and Agile Collaborating?

    Mal wieder ein Artikel über die absoluten Basics. Die Unterschiede zwischen Agile und Lean dürften zwar schon oft erörtert worden sein, vermutlich aber selten so ausführlich wie hier von François Knuchel. Neben den offensichtlichen Besonderheiten arbeitet er auch einige heraus die in den meisten Betrachtungen untergehen, z.B. das Agile-Kanban ein eher linearer Prozess einzigartiger Einzelaufgaben ist, während Lean-Kanban aus wiederkehrenden Schleifen gleichartiger Arbeit besteht. Auch die Beobachtung, dass Agile aufgrund der Affinität zu IT und Open Source eine offenere Community hat als Lean ist ein interessanter Gedanke, vor allem in Verbindung mit der Hypothese, dass das eine Ursache der im Vergleich stärkeren Sichtbarkeit und Verbreitung ist. Wirklich zum Nachdenken anregend ist aber die Vermutung, dass die beiden Bewegungen sich kaum austauschen, weil sie sich zu parallelen Silo-Strukturen entwickelt haben. Damit wären sie genau da gelandet wo sie nicht hinwollen.

  • Mark Lambertz: Matrjoschkas und das Prinzip der losen Kopplung

    Noch mehr zum Nachdenken. Wie oben in anderem Zusammenhang hervorgehoben wurde geht auch Mark Lamberts davon aus, dass Teams mit zu grossen Abhängigkeiten letztendlich nicht agil sein können. Sein Betrachtungsschwerpunkt liegt dabei allerdings nicht auf den "horizontalen Abhängigkeiten" von anderen Teams sondern auf den "vertikalen Abhängigkeiten" von höheren Hierarchiestufen. Konkret geht es um die von dort vorgegebenen globalen Aufgabenschnitte, aus denen die unteren Ebenen ihre lokalen Aufgabenschnitte ableiten müssen. Dass das Selbstorganisation hemmt ist offensichtlich, dass es irgendwie zu einem Zusammenwirken aller beteiligten Einheiten kommen muss aber auch. Mark Lamberts' Idee von "lebensfähigen Systemen, welche in ein übergeordnetes lebensfähiges System eingebettet sind" ist ein interessanter Ansatz um diesen Widerspruch aufzulösen, dürfte aber in der Umsetzung sehr anspruchsvoll sein.


  • Oliver Staley: Whatever happened to Six Sigma?

    Eine Vorstellung von dem was manche Kritiker der agilen Bewegung voraussagen bietet das Schicksal von Six Sigma. Einst ähnlich gehypt ist mittlerweile nicht mehr viel davon übriggebliebben. Die von Oliver Staley genannten Ursachen sind auch tatsächlich die, die gerade bei Scrum, SAFe & Co zunehmend zu betrachten sind: Kommerzialisierung, Hype-getriebene Anwendung auf unpassende Bereiche, Wahrnehmung als Mode-Erscheinung. Dass Agile den selben Weg gehen wird ist nicht zwangsläufig, ein warnendes Beispiel für das was schlimmstenfalls passieren könnte ist Six Sigma aber auf jeden Fall.

Donnerstag, 26. September 2019

Deine Muda: Langfristige Detailplanung

FS
Grafik: Pxhere / Mohamed Hassan - CC0 1.0

Neunter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: die langfristige Detailplanung.

Warum langfristige Detailplanung eine Muda ist, ist einfach zu erklären: überall dort wo Arbeit in einer komplexen Umgebung stattfindet (→ dort wo sich Menschen uns Systeme unvorhersehbar verhalten und auf unvorhersehbare Art und Weise mit einander interagieren1) wird die Realität früher oder später zwangsläufig von der Planung abweichen. Sobald das geschieht müssen die Pläne an die geänderte Realität angepasst werden, wodurch die bisherige Planung automatisch obsolet wird.2 Die bereits in sie investierten Aufwände waren umsonst.

Die Alternative zu diesem Vorgehen kommt ebenfalls aus dem Toyota Production System: Just in Time Delivery, oder für diesen Verwendungszweck abgewandelt: Just in Time Planning. Detailplanung sollte nur in überschaubarem zeitlichen Abstand zur Umsetzung stattfinden, da proportional zum diesem kürzer werdendem Abstand die Wahrscheinlichkeit sich ändernder Rahmenbedingungen abnimmt. Das Risiko für die Tonne zu arbeiten lässt sich so minimeren (um Missverständnissen vorzubeugen: das bedeutet keine Planlosigkeit, aber an die Stelle der Detailplanung tritt eine Vision).

Das Problem bei der Abschaffung der langfristigen Detailplanung: viele grosse Organisationen haben ihre gesamte Planungs- und Reportingstruktur auf sie ausgerichtet. Noch immer herrscht in ihnen der Glaube vor, dass man nur gut genug vorausdenken müsste um alle Eventualitäten zu berücksichtigen, und ein Abweichen von diesen Glaubenssätzen wird ignoriert oder sanktioniert (siehe auch die Antipattern der scheinbaren Imitation und der scheinbar umfassenden Planung). Für eine Verhaltensänderung ist also viel Überzeugungsarbeit nötig.

Einen Ausweg aus dieser Situation bietet - Ironie der Geschichte - ausgerechnet das meistens mit langfristiger Detailplanung einhergehende langfristige Detailreporting. Überall dort wo jeder einzelne Konzeptions-, Umsetzungs- und Testaufwand erfasst, festgehalten und mit einer Buchungsnummer versehen ist kann man problemlos aufzeigen wie viel Arbeitszeit (und damit Geld) sinnlos ausgegeben wurde, weil die Realität nicht mehr zum Plan passt. Die Muda wird damit sichtbar und messbar - und so zu einem gewichtigen Argument um an Veränderungen zu arbeiten.


1Es gibt natürlich auch nicht-komplexe Umgebungen, aber um die soll es hier nicht gehen.
2In manchen Organisationen wird stattdessen versucht die Realität an die Planung anzupassen. Ein Thema für sich.

Montag, 23. September 2019

Jack of all trades, Scrum Master of none

FS
Bild: Pixabay / Moise Theodor - CC0 1.0
Liest man im Scrum Guide nach welche Aufgaben ein Scrum Master alles übernehmen soll kann einem schnell schwindelig werden. Er soll das Team in Richtung Selbstorganisation coachen, soll Hindernisse beseitigen, Meetings moderieren, den Product Owner methodisch unterstützen und Change Management in der umgebenden Organisation betreiben. Je nach Umfeld sind noch weitere Themenfelder nötig: XP-Techniken, Liberating Structures, Design Thinking, Konflikt-Mediation, Skalierung, etc. etc. etc.

Es ist zwar nicht ausgeschlossen, dass es Menschen gibt die all das aus dem Stand beherrschen, viele sind es aber nicht. Da es den Beruf noch nicht lange gibt kommen meisten Scrum Master ursprünglich aus einem anderen Betätigungsfeld, Klassiker sind dabei Softwareentwicklungs-Spezialisierungen (Entwickler, Konzepter, Tester), Projektmanager oder IT-ferne Coaching-Berufe. Aus einem solchen Hintergrund heraus zu einem "universal gebildeten Spezialisten für alles" zu werden ist schwer, und vor allem dauert es Zeit.

Wenn man nicht den Luxus hat in einer Gruppe von Scrum Mastern zu arbeiten, in der einzelne Mitglieder sich unterschiedliche Schwerpunkte suchen können, bleibt die Wahl zwischen zwei Ausrichtungen: Spezialisierung und Generalisierung. Entweder man geht in einem (oder wenigen) Wissensgebieten in die Tiefe oder man erwirbt ein Grundwissen in möglichst vielen. In der überwiegenden Zahl der zu beobachtenden Fälle1 fällt die Entscheidung auf Variante Eins.

Dass das problematisch ist, ist intuitiv ersichtlich, schliesslich werden wichtige Felder bewusst nicht beackert. Die wahre Dimension erschliesst sich aber wenn man bedenkt, dass in den meisten Fällen die Spezialisierung in den "teamnahen" Themenfeldern stattfindet. Um nicht falsch verstanden zu werden - gekonnte Meeting-Moderation und gute Coaching-Techniken sind wichtig, wenn für sie aber (agil) strukturiertes Produktmanagement und das Alignment mit der umgebenden Organisation wegfallen ist nichts gewonnen. Die Scrum-Implementierung wird dann schwere Dysfunktionen haben.

Die Alternative ist vielversprechender: ein Grundverständnis aller relevanten Bereiche sogt zum einen dafür, dass sich nicht irgendwo unbemerkt Antipattern ausbreiten können, zum anderen ist es die Ausgangslage dafür, zielgerichtet andere Teammitglieder zur eigenen Entlastung einbinden zu können. Zum Beispiel kann die Meeting-Moderation in den meisten Fällen von Teammitgliedern selbst übernommen werden, so dass dort nur noch eingesprungen werden muss wenn ein neutraler Vermittler nötig ist.2

Zuletzt ist ein breites Grundverständnis die Voraussetzung dafür, dass in späteren Phasen der Selbstentwicklung entschieden werden kann wo eine Vertiefung der Kenntnisse den grössten Mehrwert stiften kann. Wichtig ist dabei aber die Reihenfolge: erst das breite Verständnis, dann die Vertiefung in einzelne Themen. Nicht umgekehrt.


1Basierend auf der eigenen Beratungserfahrung und dem Austausch in der agilen Community im Rheinland
2Ironie der Geschichte: diese Tätigkei zu delegieren fällt vielen Scrum Mastern besonders schwer

Donnerstag, 19. September 2019

Das beste agile Skalierungs-Framework der Welt: Reden

FS
Bild: Pexels / Christina Morillo - CC0 1.0
In den nächsten Tagen werde ich an einer Podiumsdiskussion teilnehmen dürfen, die den etwas reisserischen Titel "Battle of the Frameworks" trägt. Das Ziel: verschiedene agile Skalierungs-Frameworks nebeneinander zu halten, Vorteile und Nachteile zu vergleichen und wenn möglich herauszufinden welcher Ansatz in welcher Situation hilfreich sein könnte und welcher eher nicht.

In der Vorbereitung habe ich mir durch den Kopf gehen lassen welche der bekannten Skalierungs-Frameworks ich schon im Einsatz gesehen habe und bin auf einige gekommen: Scrum@Scale, LeSS, Nexus, SAFe, (Pseudo)Spotify, Flightlevel-Kanban und einige Hybrid-Modelle aus Agile und Wasserfall waren dabei, alle mit Aspekten die gut funktioniert haben und solchen bei denen das nicht der Fall war. Mir ist aber auch klar geworden, dass ich einen absoluten Favoriten habe - einfach miteinander reden.

Bis zu einer Größe von mindestens fünf Teams kommt man damit erstaunlich weit (und ich kenne nicht viele Fälle in denen mehr als fünf Teams Sinn gemacht haben). Wenn die Produktmanager und Product Owner den gemeinsamen Release zusammengehörender Features planen wollen können sie das tun indem sie miteinander reden. Wenn die Entwickler Coding-Standards und Schnittstellen definieren wollen können sie miteinander reden. Wenn die UX-Designer ein übergreifendes Look and Feel herbeiführen wollen können sie miteinander reden, etc.

Das passiert grundsätzlich zwar auch in allen anderen Frameworks, der Unterschied ist, dass Zeit, Ort und Gruppe dabei reglementiert sind. Planung findet im PI-Planning statt, die Klärung von Abhängigkeiten im Scrum of Scrums, die Erarbeitung von Konventionen in der Community of Practice - für nahezu jedes Anliegen lässt sich ein passendes Format finden, dass dann aber auch Risiken in sich birgt: wenn für ein Anliegen kein Format da ist oder wenn dieses erst zu einem anderen Zeitpunkt stattfindet, dann findet eine Klärung oft nicht statt.

Die Alternative: sobald der Bedarf nach Abstimmung aufkommt kann man einfach zu den Betroffenen hingehen, kann sie fragen ob sie einen Beitrag zum Thema liefern können, wann sie Zeit dafür haben und wen sie sonst noch dazuholen würden. Wenn es soweit ist spricht man miteinander, einigt sich und klärt welche nächsten Schritte zu welchem Zeitpunkt gemeinsam angegangen werden sollen. Und das ist es, mehr als das ist in den meisten Fällen nicht nötig.

Dass dieses verblüffend einfache Modell in der Realität kaum vorkommt hat natürlich Gründe: räumliche Trennung, Überplanung durch zu viele Termine, fehlende Entscheidungskompetenzen, fehlende Einsicht in grössere Zusammenhänge und zu viele Abhängigkeiten. Aber an dieser Stelle gibt es auch gute Neuigkeiten - all das kann man ändern, man muss es nur wollen. Und wenn das geschafft ist kann man alle komplizierten Zusammenarbeitmodelle den Grossprojekten überlassen und sich auf das gemeinsame Reden beschränken.

Montag, 16. September 2019

Making things better for everyone

FS
Es ist ein Thema über das man lange diskutieren kann: gehören "weiche Themen" wie Augenhöhe, Diversität, etc. zur agilen Organisationsentwicklung dazu? Wenn sie dazugehören droht das Begriffsverständnis sehr in die Breite zu gehen, wenn sie nicht dazugehören kann das Folgen für die geistige Beweglichkeit der Belegschaft haben. Einen weiteren Aspekt kann man aus diesem Vortrag von Jill Wetzler mitnehmen: durch ihre diversitätsfördernden Massnahmen zeigen Unternehmen wie offen, datengetrieben oder feedbackorientiert sie sind - oder nicht sind.


Donnerstag, 12. September 2019

Agile Bauprojekte (II)

FS
Bild: Wikimedia Commons / Koma Modular Construction - CC BY-SA 3.0
Manchmal ist es erstaunlich durch welche Artikel besonders heftige Reaktionen ausgelöst werden. Der über agile Bauprojekte gehört definitiv dazu. Das würde doch alles gar nicht stimmen, hiess es mehrfach, das wäre am Thema vorbei und irreführend. Denn: dort ginge es gar nicht um Bauvorhaben im eigentlichen Sinn sondern nur um Renovierungen. Dort wo wirklich neu gebaut würde, da wären agile Ansätze nicht anwendbar. Nun ja. Vermutlich nicht überall, aber das hatte auch niemand behauptet. Grundsätzlich geht es aber sehr wohl, wenn man es denn will und sich auf bestimmte Voraussetzungen einlässt.

Beginnen wir mit der Problem-, bzw. Aufgabenstellung. Unter welchen Umständen könnte es dazu kommen, dass Gebäude in kurzer Zeit aufgebaut, umgebaut, abgebaut und an anderer Stelle neu errichtet werden müssen? Etwa dann wenn ihr Eigentümer häufig umzieht und seine Heimat mitnehmen möchte. Oder dann wenn sich der Bedarf nach Wohn- und Arbeitsraum häufiger ändert. Oder dann wenn es Schwankungen bei der Nutzungsintensität gibt oder unterschiedlich schnellen Verschleiss unterschiedlicher Gebäudeteile.

Sich an diese sich ändernden Gegebenheiten anzupassen wäre zwar mit den klassischen, sprichwörtlich fest gemauerten Baustilen nur schwer möglich, es gibt aber einen anderen mit dem sich diese Herausforderung bewältigen lässt: mit der Modulbauweise. Das Gebäude besteht in diesem Fall aus mehreren vorgefertigten Modulen, die sich je nach Bedarf kombinieren, neu arrangieren, anbauen oder entfernen lassen. Die Bauarbeiten bestehen dann nur noch aus dem Ebnen des Bodens, dem Aufstellen und Verbinden der Module und dem Anschliessen von Rohren und Leitungen.

Agilität wird so in verschiedenen Weisen ermöglicht: bis relativ spät im Baufortschritt können die Pläne angepasst werden. Grösser, kleiner oder anders angeordnet, verschiedene Modifikationen sind möglich. Auch ein schnelles Vergrössern oder Verkleinern fertiger Gebäude ist möglich, etwa wenn die Kinder ausziehen oder wenn in einem gewerblich genutzten Gebäude mehr Arbeitsplätze entstehen oder in einem Wohnheim mehr Zimmer gebraucht werden. Einzelne Module lassen sich austauschen, z.B. wegen Brandschutz, und da jedes Modul auf einen Laster passt kann sogar das ganze Haus versetzt werden.

Soweit die Theorie, aber gibt es das auch in der Realität? Ja, gibt es. Nicht zu oft aber vorhanden und erprobt. Eher selten sind modular aufgebauter Wohnhäuser, die sich bei Bedarf erweitern und verkleinern lassen. Häufiger sind temporäre Häuser, mit denen etwa München oder Brüggen am Niederrhein Wohnraum für zugezogene Studenten schaffen, die am Anfang keine Wohnung finden. Auch während der Flüchtlingswelle 2016 wurden Modulbauten genutzt, etwa in Hannover, Gelsenkirchen, Augsburg und Marburg. Und ein besonderer Fall sind schnell auf- und umbaubare Krankenhäuser in Krisengebieten.

Natürlich lässt sich nicht alles in Modulbauweise bauen. Keller zum Beispiel nicht, und auch andere Begrenzungen bestehen. Was aber klar ist: diese Bauweise ermöglicht grundsätzlich das Übertragen agiler Prinzipien auf den Neubau von Gebäuden. Ob das die jeweils beste Lösung ist muss dann im Einzelfall entschieden werden.

Montag, 9. September 2019

Den Maschinenpark in Ordnung halten

FS
Bild: Wikimedia Commons / Mixabest - CC BY-SA 3.0
Stellen wir uns die folgende Situation vor: eine Firma besitzt zur Herstellung ihrer Produkte eine grosse Produktionshalle voller Maschinen. Diese sehen auf den ersten Blick gut aus, bei näherer Betrachtung finden sich aber zahlreiche Beschädigungen. Keilriemen sind rissig, Schrauben haben gebrochene Gewinde und Verstrebungen sind stark verrostet. Solche Dinge. Die Schäden sind offensichtlich und allgemein bekannt, repariert wird aber nichts. "Dafür ist keine Zeit" heisst es als Begründung, "wir sind voll damit beschäftigt Güter zu produzieren." Was wäre von dieser Firma zu halten?

Nicht viel, wäre die Antwort. Denn selbst wenn die Auftragslage für eine Vollauslastung aller Maschinen sorgt ist eine unterlassene Instandhaltung fahrlässig. Mit zunehmendem Verschleiss wird es schwerer die Schäden zu reparieren, ab einem bestimmten Punkt weiten sie sich aus auf bisher nicht betroffene Teile, irgendwann bricht der Betrieb zusammen und muss in einer langen und aufwändigen Reparaturphase wieder aufgebaut werden - mit Kosten die wesentlich höher sind als es die kleinen Reparaturen zu Beginn gewesen wären.

Und doch ist es so, dass dieses widersinnige Verhalten permanent stattfindet, und zwar in zahlreichen Unternehmen, quer durch alle Branchen. Allerdings gibt es dabei eine Besonderheit: was hier nach und nach verfällt sind keine Maschinen sondern Software. Bugs werden nicht gefixt, schlechte Architektur wird nicht geradegezogen, fehlende Lastfähigkeit wird ignoriert. Die Folgen sind dagegen die selben wie bei der Maschine: die Probleme häufen sich und verstärken sich gegenseitig, bis irgendwann Nichts mehr geht und alles generalüberholt werden muss.1 Umsatz gibt es in dieser Zeit keinen mehr.

Bereits bei einem sich nicht verändernden System wäre das alles ein Grossproblem, dort wo regelmässig Um- und Ausbauten stattfinden müssen wird es zu einem riesigen. Dort wo intensiver Wettbewerb oder gesetzliche Regulierungen häufige Änderungen erfordern wird die Arbeit an einem nicht gewarteten System das Auftreten von Problemen wahrscheinlicher machen. Es ist wie bei einem Jenga-Turm - es ist nicht mehr die Frage ob eine Modifikation zum Zusammenbruch führt sondern nur noch wann das passiert. Und wenn dadurch Zieldaten verfehlt werden werden die Wettbewerber erfreut reagieren - und die Aufsichtsbehörden verärgert.

Schon in einem stabilen Umfeld macht es also grossen Sinn "den Maschinenpark in Ordnung zu halten", in einem dynamischen ist das erst recht der Fall. Und doch - häufig passiert es nicht. Das kann vielfältige Gründe haben: eine übermässige Focussierung auf kurzfristige Ziele, fehlendes technisches Verständnis der entscheidenden Personen und falsch verstandene Sparsamkeit dürften die häufigsten sein. Das in den grossen Kontext zu setzen und in vernünftigere Bahnen zu lenken muss in solchen Fällen ein vorrangiges Ziel sein. Sonst wird schon bald auch von diesen Firmen nicht mehr viel zu halten sein.


1Was schlimmstenfalls Monate dauern kann.

Donnerstag, 5. September 2019

Demographie

FS
Bild: Pixabay / Geralt - CC0 1.0
Irgendein Algorithmus ist Schuld. Ohne danach gesucht zu haben hatte ich plötzlich das Video vom Vortrag The Scribe's Oath von Bob Martin auf dem Bildschirm. Es ist mittlerweile über zwei Jahre alt, und nach dem Ansehen möchte ich die englischen Bewertung, "it aged well" vergeben. Was dieses mal bei mir hängen geblieben ist, ist aber nicht der eigentliche Inhalt (eine Art Hippokratischer Eid für Software-Entwickler) sondern eine Nebenbemerkung: ab Minute 17 versucht er nachzuvollziehen wie sich die Gesamtzahl der Software-Entwickler auf der Erde entwickelt und kommt auf einen atemberaubenden Schluss: die Zahl verdoppelt sich alle zwei bis fünf Jahre.

Seine daraus folgende Erkenntnis: solange das so bleibt (und nichts spricht dagegen, dass es sich ändert) wird die Mehrheit der Entwickler immer eine Berufserfahrung von nur wenigen Jahren haben. Man kann das kritisch sehen, so wie Bob Martin es tut, und ethische Richtlinien fordern. Man kann aber auch die Chance darin sehen. Wer erst wenige Jahre im Beruf ist wird in der Regel noch offen sein für Neues, nicht auf Gewohntem beharren, nicht alles so machen wollen "wie immer" und Veränderung nicht als Störung empfinden. Vermutlich ist das einer der grossen, unterschätzten Faktoren dafür, dass agile Ansätze vor allem in der IT entstanden sind und hier auch bestehen bleiben.1

Weitergedacht bedeuten diese Faktoren aber nicht, dass die "jugendliche Wechselbegeisterung" ein Charakteristikum aller IT-Unternehmen und Abteilungen sind - in kaum einer Firma steigt die Anzahl der Beschäftigten bremskurvenartig an. Ab einer bestimmten Grösse wird kaum noch neu eingestellt, so dass es zu einer demographischen Polarisierung kommt: auf der einen Seite die relativ junge Belegschaft in Startups und Neugründungen, auf der anderen Seite die älteren Mitarbeiter der Firmen die schon in den 80ern und 90ern auf Digitalisierungslösungen gesetzt haben. Selbst in der scheinbar immer modernen IT findet man hier Strukturkonservativismus, Sicherheitsfixierung, Groupthink und ähnliche Phänomene, die häufig zu verkrusteten, bürokratischen Strukturen führen.

Noch einmal weitergedacht ergibt sich für die nächsten Jahre aber ein gegenläufiger Trend. Dort wo IT-Abteilungen in den 80ern und 90ern aufgebaut worden sind steht in absehbarer Zeit ein Generationenwechsel an. Bei manchen Mittelständlern und in vielen IT-Abteilungen von Grossunternehmen sind die Entwickler im Schnitt Mitte bis Ende 50, die nächste Verrentungswelle ist also absehbar.2 Da die nächste, bereits in den Startlöchern stehende Generation deutlich jünger sein wird bedeutet das aber, dass die Offenheit für Neues bald wieder deutlich grösser sein wird. Und da die Unternehmen für die gefragten Fachkräfte attraktiv sein wollen werden auch sie nicht umhinkommen das zuzulassen und zu fördern. Die immer zahlreicher werdenden "New Work"-Programme sind Teil dieser Entwicklung.3

Natürlich besteht bei solchen Betrachtungen immer die Gefahr unzulässiger Verallgemeinerungen, trotzdem deuten die Faktoren aber darauf hin: die demographische Entwicklung sorgt dafür, dass die Agile Bewegung sich ständig erneuert, und dass zur Zeit der nächste "Agilisierungs-Schub" auf die IT-Branche zurollt.


1Ja, es gibt auch junge unflexible Entwickler und alte die hochagil sind. Es geht aber um Mittelwerte.
2Genaugenommen ist es in der IT fast überall die erste.
3Wobei der Unterschied zwischen Agilität und New Work nochmal ein eigenes Thema wäre.

Montag, 2. September 2019

Chaos doesn't cause problems, it reveals them

FS
Alleine das Wort schreckt viele ab - Chaos Engineering, das klingt nach Unordnung, nach Unvorhersehbarkeit und nach Kontrollverlust. Das kann keiner wollen! Das Problem: diese Zustände existieren trotzdem, und zwar überall (solange wir von IT und anderen komplexen Produkten reden). Nora Jones gibt einige Einblicke wie dem begegnet werden kann, wertvoll ist aber vor allem die andere Seite ihres Vortrags: wie sich eine Kultur des Chaos Engineering in einem Unternehmen etablieren lässt.

Freitag, 30. August 2019

Kommentierte Links (LII)

FS
  • Mark Lambertz - Warum der Begriff VUCA nicht taugt

  • Für jeden der sich im Umfeld der agilen Frameworks und Vorgehensmodelle bewegt ist das Konzept der Komplexität dauerpräsent. Komplexität wird regelmässig als Ursache, Gegenspieler oder Rahmenbedingung von Agilität genannt, bleibt aber angesichts dieser zentralen Bedeutung erstaunlich unkonkret in der Beschreibung. Mark Lambertz macht sich die Mühe und beleuchtet den Begriff ausführlich von verschiedenen Seiten - und wer mich kennt wird wissen, dass es die Exkurse in die Geisteswissenschaften sind die mir gefallen. Was ich an der Stelle ausserdem interessant finde ist seine Einordnung der über-trivialisierenden Begriffsverwendung in die Kategorie "Beratersprech". Ich selber habe das eher bei autodidaktischen und voreilig selbstsicher gewordenen Kunden erlebt, deren gestrandete agile Pilotprojekte ich aus dem Jammertal herausbegleiten durfte. Letzten Endes ist wohl beides subjektiv.

  • Marcus Raitner: Der Hofnarr an der Seitenlinie

    Der Begriff des Hofnarrs reizt mich zwar immer noch zum diskutieren, abgesehen davon hat Marcus Raitner aber recht. Wenn der Scrum Master seine Rolle als Servant Leader so missversteht, dass er im Team und/oder im Unternehmen die unangenehmen Aufgaben übernimmt, ist irgendetwas ordentlich schiefgelaufen. Egal ob als Mini-PMO, als "Teamsekretärin" oder als Dev-Support, das alles sind Varianten einer schlechten Rollen-Interpretation die es so nicht geben sollte. Dass es doch immer wieder dazu kommt hat so viele Gründe wie Varianten, gültig ist aber hier der unsterbliche Satz von Franz-Josef Strauss: Everybody's darling is everybody's Depp.

  • John Cutler: So You Want to Fix Something?

    Service-Durchsage: John Cutler hat einen neuen Blog mit der skurrilen URL https://cutle.fish. In einem seiner ersten Einträge geht er gleich wieder in die Tiefe und reflektiert was er besser schon früher gewusst hätte um erfolgreiches Change- und Innovationsmanagement zu betreiben. Im Grossen und Ganzen ist es das was der gesunde Menschenverstand nahelegt (zumindest der in agilen Projekten sozialisierte gesunde Menschenverstand). Überschaubare Experimente, Begrenzung paralleler Arbeit, iteratives Vorgehen, nicht alles auf eine Karte setzen. Was aus Sicht eines Agile Coaches ungewöhnlich ist, ist der Ratschlag nicht mit einem speziellen Ansatz identifizierbar zu sein. Der Gegenentwurf zur Fokussierung auf SAFe, Kanban, Scrum, etc.

  • Willem-Jan Ageling: How Managers slowly got removed from Scrum

    Das ist interessant - der Anti-Management-Touch den Scrum heute hat war nicht von Anfang an gegeben. Dass es in der Anfangszeit noch eine Übergangsphase mit deutlich erkennbaren Management-Rollen gegeben haben muss ist zwar naheliegend, in welchem Ausmass das der Fall war ist aber im Rückblick bemerkenswert. Ein Satz wie "[The] Management deals with backlog, risk, and release content” würde heute als schweres Antipattern gelten. Auch dass die letzten Spuren der Management-Rollen erst 2011 aus dem Scrum Guide entfernt wurden überrascht, gefühlt hätte das früher der Fall sein müssen. Vor allem sticht aber die Gegenläufigkeit zweier Tendenzen ins Auge: je mehr das Management aus seinen Regeln verschwunden ist, desto erfolgreicher ist Scrum geworden.
    (siehe auch: Ist der Scrum Master ein Manager?)

  • Katharin Tai: So geht Widerstand

    Mal wieder ein Blick über den Tellerrand. Wie geht man damit um in einem technologisch hochgerüsteten Überwachungsstaat von der Regierung verfolgt zu werden? Mit einer bis ins extrem getriebenen dezentralen Organisationsform. Dieser Artikel aus der Zeit bietet einen faszinierenden Einblick in die Strukturen der demokratischen Proteste in Hong Kong, die so un-hierarchisch sind, dass es nicht mehr gelingt sie durch die Verhaftung von Führungsfiguren zu schwächen.

Montag, 26. August 2019

Epics

FS
Bild: Wikimedia Commons / Sarah Welch - CC BY-SA 4.0
Zu den Begriffen aus dem agilen Umfeld die immer wieder kontrovers diskutiert werden gehört das Epic. Es gibt zwar in den meisten Fällen die Übereinstimmung, dass es sich dabei um eine grössere Anforderungs- oder Planungseinheit handelt, alles was darüber hinausgeht wird aber sehr unterschiedlich verstanden. Zeit um Klarheit zu schaffen.

Ein Epic ist zunächst nichts anderes als eine User Story die zu gross ist um umgesetzt zu werden ohne vorher aufgeteilt worden zu sein. Wann, wo und in welchem Kontext diese Verwendung entstanden ist lässt sich vermutlich nicht mehr genau klären, bereits 2004 wird diese Verwendung vom Scrum-Pionier Mike Cohn in seinem Buch User Stories Applied aber schon mit grosser Selbstverständlichkeit vorgetragen1. Aber was ergibt sich aus dieser Bedeutung?

Zunächst, dass Epics genau wie normale User Stories verschiedene Voraussetzungen erfüllen müssen. Sie sollten einen End-to-End-Ansatz verfolgen2, in einfacher, verständlicher Sprache geschrieben sein, einen Anwender nennen3, den gewünschten Use Case, bzw. das zu lösende Problem beschreiben und auch nachvollziehbar darstellen welcher Mehrwert neu geschaffen werden soll. Die Gleichartigkeit von User Story und Epic lässt sich bereits daran erkennen, dass die Begriffe sich alleine durch eine Neuschätzung des Aufwandes vertauschen können.

Genau wie im Fall von User Stories ist es auch bei Epics möglich sie durch Zusatzinformationen anzureichern. Das können Akzeptanzkriterien sein, Personas oder Kundenfeedbacks, es gibt aber auch eine Form der Zusatzinformation die Epic-spezifisch ist: die Benennung der an der Umsetzung beteiligten Teams. Wenn das mehrere sind (wofür es verschiedene Gründe geben kann) erleichtert das die Nachverfolgung und Koordination des Arbeitsfortschritts.

Zuletzt ist es noch wichtig, dass Epics in überschaubarer Zeit abschliessbar sein müssen. Ohne die Begrenzung des Scrum-Sprints oder der XP-Iteration ist es ein verlockender Fehler den Rahmen so weit zu ziehen, dass am Ende eher ein Anforderungs-Kategorie als eine Anforderung steht (z.B. "Benutzerverwaltung" oder "Shop". Das ist nicht im Sinn der Idee und sollte vermieden werden.


1Danke für die Hinweise auf Mike Cohns Buch, allerdings wurde der Begriff dort nicht erfunden oder eingeführt. Auf Seite 6 heisst es "When a story is too large it is sometimes referred to as an epic." Die Verwendung gab es also auch schon früher.
2D.h. es sollte keine ausgelagerten Konzeptions-, Umsetzungs-, (Regressions)Test-, Dokumentations- oder Release-Epics geben
3Anwender ≠ Auftraggeber

Donnerstag, 22. August 2019

Andon

FS
Bild: Pxhere - CC0 1.0
Zu den grossen Inspirationsquellen für jeden der seinen agilen Prozess verbessern will gehört zweifellos das Toyota Production System (TPS). Selbst wenn es ursprünglich für die Industrieproduktion von Autos vorgesehen war enthält es zahlreiche Elemente, die auch in der Software-Programmierung oder Wissensarbeit von Nutzen sein können. Eines dieser Elemente ist das so genannte Andon (行灯, übersetzt rote Laterne, bzw. Papierlaterne).

Unter diesem Begriff versteht man Systeme oder Prozesse mit denen ganze Produktionsketten (in der Regel Fliessbänder, aber auch alles andere) schlagartig zum Stillstand gebracht werden können sobald ein Fehler auftritt. In den meisten Fällen erfolgt das durch Zugschnüre oder grosse Druckknöpfe (auch bekannt als Toyota-Buttons) die überall entlang der Fertigungsstrassen zu finden sind. Im weiteren Sinn gehören auch Signaltöne und Datenerfassungssysteme zu den Andon-Installationen dazu.

Bemerkenswert sind an diesem Konzept vor allem zwei Aspekte. Zum einen wird das Wesen eines Fehlers hier anders verstanden als üblich. Der Fehler ist nicht mehr die Beschädigung oder Minderwertigkeit des "fehlerhaften" Produkts sondern die Dysfunktion des vorhergegangenen Herstellungsprozesses. Dementsprechend folgt auf das Anhalten der Produktionskette auch eine Neukonfiguration des Prozesses und nicht eine Reparatur des Produkts (die soll überflüssig werden).

Zum anderen sind die Zugschnüre oder Druckknöpfe nicht nur überall angebracht sondern auch für jeden zugänglich - und es hat auch jeder die Berechtigung sie zu benutzen. Darüber hinaus ist ihre Benutzung auch prinzipiell nicht mit negativen Folgen verbunden, auch dann nicht wenn der Produktionsausfall auch Gewinnrückgänge nach sich zieht. Es soll alles vermieden werden was von ihrer Benutzung abhält, damit nichts der Idee einer möglichst fehlerfreien Auslieferung im Weg steht. Die Idee dahinter: der langfristige Nutzen ist weit grösser als ein kurzfristiger Verlust.

Übertragen auf die Softwareentwicklung wären vor allem die Tolerierung "unkritischer Bugs" oder die dauerhafte Durchführung zu vieler (potentiell fehlerhafter) manueller Prozesse Gründe für das Auslösen eines Andon-Systems. Da derartige Verhaltensmuster fast immer die Durchführung von langen, nachgelagerten Regressionstest- und Bugfixing-Phasen zur Folge haben verhindern sie die kontinuierliche Auslieferung von Geschäftswert und sind damit kritisch genug für einen Produktionsstop.

Das Gegenargument ist an dieser Stelle das selbe wie in der Fabrik: "Aber damit verhindert man doch das Einhalten der Produktionsquote, bzw. der Deadline!" Allerdings ist das nur bedingt richtig. Wenn zwar die Menge und das Zieldatum stimmen, die Arbeitsergebnisse aber defekt sind, dann ist der Erfolg nur ein scheinbarer. In Wirklichkeit sind Kosten und dauer sogar höher, sie werden nur in späteren Phasen versteckt.

Um das nicht geschehen zu lassen macht ein roter Knopf an jedem Arbeitsplatz absolut Sinn.

Montag, 19. August 2019

Rebound-Effekt

FS
Grafik: Public Domain Pictures / Witali Smoligin - CC0 1.0
In Change-Vorhaben (egal ob agil oder klassisch) gibt es Phänomen das gleichermassen häufig wie ärgerlich ist: ineffektive Prozesse haben in der Vergangenheit dazu geführt, dass sich vor den umsetzenden Einheiten (Fertigung, IT, etc) ein Rückstau gebildet hat, dessen Sichtung und Verwaltung Ressourccen bindet und zu Bürokratie führt. Prozessverbesserungen sollen helfen diesen Stau durch schnellere Bearbeitung abzubauen, und tatsächlich wird der Durchsatz erheblich gesteigert. Und trotzdem: die Menge an wartender, unerledigter Arbeit bleibt gleich.

Die dahinter stehende Ursache ist der so genannte Rebound-Effekt. Ursprünglich aus der Energiewirtschaft kommend lässt er sich folgendermassen beschreiben: ein Verbraucher konsumiert eine bestimmte Ressource. Eine Effizienzsteigerung des Ressourcenverbrauchs sorgt dann dafür, dass der Verbraucher weniger konsumieren muss als bisher. Da sein Budget aber unverändert bleibt benutzt er die frei gewordenen Mittel um zusätzliche Ressourcen zu konsumieren, wodurch der Gesamtverbrauch gleich bleibt.

Dieses Phänomen lässt sich auf Fertigungsprozesse übertragen. In der alten, ineffizienten Prozesswelt hatten der Produktion vorgelagerte Einheiten (Vertrieb, Innovation, etc.) einen doppelten Aufwand: sie mussten zum einen neue Anforderungen erstellen und zum anderen den sich anstauenden Berg der fertigen, aber auf die Umsetzung wartenden Anforderungen dokumentieren, aktuell halten und umpriorisieren. Wenn dieser Berg jetzt durch effizientere Produktionsprozesse verschwindet haben die vorgelagerten Einheiten plötzlich mehr Zeit, die sie nutzen können um noch mehr Anforderungen ins System zu geben, durch die sich trotz der schnelleren Abarbeitung ein neuer Stau bildet, der neue Bürokratie generiert.

Da eine solche Entwicklung sämtliche effizienz- und effektivitätssteigernden Massnahmen wirkungslos machen kann ist ein Gegensteuern dringend nötig. Die zunächst einfach klingende Massnahme: die Menge der neuen Anforderungen darf nur so stark steigen, dass kein neuer Rückstau entsteht. Der Fachbegriff dafür ist das Work in Progress Limit. Das umzusetzen kann aber zu einer Herausforderung werden, da die freigewordenen Kapazitäten ja auch nicht ungenutzt bleiben sollen. Die Konsequenzen (Versetzungen, Umschulungen, Personalabbau in den vorgelagerten Einheiten  oder Personalaufbau in den nachgelagerten Einheiten) sind schwerwiegend, zur Vermeidung des Rebound-Effekts aber nötig.

Donnerstag, 15. August 2019

Denn sie wissen nicht, wen sie rekrutieren (IV)

FS
Bild: Flickr / Amtec - CC BY-SA 2.0
Angeregt vom neuesten Artikel des geschätzten Marcus Raitner wird es Zeit die etwas eingeschlafene Reihe "Denn sie wissen nicht, wen sie rekrutieren" wieder fortzuführen. Im Artikel geht es um die (autobiografische?) Geschichte eines Menschen der sich zum ersten mal im Leben bei einem Konzern bewirbt, und von seinem Befremden angesichts der ihm dort begegnenden Formalismen und Bürokratien. Obwohl er natürlich nur einen Einzelfall beschreibt ist er symptomatisch für ein grundlegendes Phänomen.

Seit auch die grossen Organisationen die Agilität für sich entdeckt haben (und umgekehrt) prallen bei den Ausschreibungs- und Einstellungsprozessen zwei Welten aufeinander. Auf der einen Seite die Personalabteilungen, die mit grösster Selbstverständlichkeit davon ausgehen, dass das "seit langem bewährte" Vorgehen auch weiterhin das Richtige ist, auf der anderen Seite die in der agilen Bewegung sozialisierten Fachkräfte, die diesen von ihnen als anachronistisch empfundenen Routinen mit Fassungslosigkeit gegenüberstehen.

Beide Sichtweisen lassen sich nachvollziehen. Die Personalstellen sind jahrzehntelang durch Taylorismus und (Pseudo-)Lean Management so optimiert worden, dass sie die eingehenden Bewerbungen in möglichst einheitlichem Format erwarten. Das ist schliesslich die Voraussetzung dafür, dass sie alle möglichst schnell den selben Bearbeitungsvorgang durchlaufen können. Branchenerfahrung? Check. Führungserfahrung? Check. Budgetverantwortung? Check. Ab in die zweite Auswahlstufe. Um sich jeden Kandidaten genau anzusehen fehlt einfach die Zeit.

Darüber hinaus sind sie (oft unbewusst) in einen beruflichen Standesdünkel hineinsozialisiert worden. Bei einem Automobilbauer zu schaffen, Banker zu werden oder bei einem Verlag zu arbeiten ist Errungenschaft und Ehre, dafür soll sich der Bewerber ruhig anstrengen, und zwar so, dass man es sieht. Mit makellosem Lebenslauf und überzeugenden Argumenten warum man denn gerade ihn nehmen sollte. Flüssig formuliert, ansprechend formatiert und auf hochwertigem Papier eingereicht bitteschön.

Auf der anderen Seite die vom Fachkräftemangel selbstbewusst gemachten Bewerber. Im eigenen Projektportfolio steht doch übersichtlich und nachvollziehbar drin was man gemacht hat, welchen Wert soll es haben das chronologisch anzuordnen? Und dann die Kategorien. Budget- und Führungsverantwortung sind doch für Lead Developer und Scrum Master irrelevant. Und warum gibt es trotz so vieler geforderter Pflichtangaben keine in die die Mob Programming Skills und der Link zum eigenen Open Source-Projekt passen würden?

Auch der Standesdünkel ist da, allerdings umgekehrt. Konzern? Allein der Begriff klingt schon nach Cobol. Da kann man gespannt sein ob die auch nur annähernd den gleichen Techstack bieten können wie das Fintech in der Innenstadt. Und hoffentlich halten die nicht an solchen Relikten des 19. Jahrhunderts fest wie Krawatten und festen Arbeitsplätzen. Zumindest kann man ja wohl erwarten, dass für Bewerbungen auch eine 40 Jahre alte Technologie wie die Email akzeptiert wird.

Sollte es dann trotz all dieser Hindernisse doch zu einem Job-Interview kommen, werden die Differenzen häufig erst richtig sichtbar. Während die Konzern-Seite davon ausgeht, dass der Bewerber hier nach seiner Lebensstellung sucht will dieser nur "ein paar spannende Jahre" erleben, und während die Personalerin stolz von der Betriebsrente und der Betriebssportgemeinschaft erzählt will ihr Gegenüber über Homeoffice und Slacktime reden. Das alles gerinnt in Wortwechseln wie diesem hier: "Wo sehen sie sich in drei Jahren?" "Keine Ahnung, so lange will ich hier nicht bleiben."1

Bis vor nicht allzulanger Zeit hätten diese Differenzen dazu geführt, dass diese "unpassenden" Bewerber einfach aussortiert wurden. Aber das ist vorbei, die zunehmende Agilisierung, Digitalisierung, Automatisierung und Cloudifizierung sorgt dafür, dass grosse Firmen froh sein können wenn sie ihren Bedarf überhaupt gedeckt bekommen. Und jetzt stehen die Personalabteilungen vor einem Problem: nicht nur können sie die Ansprüche der begehrten Fachkräfte kaum befriedigen ohne die eigenen, "seit langem bewährten" Vorgehensweisen in Frage zu stellen, oft wissen sie gar nicht welche Ansprüche das sind. Und dann das Schlimmste: sobald diese ermittelt wurden ändern sie sich.

Um die in der agilen Bewegung sozialisierten Arbeitnehmer verstehen zu können und um auf ihre Ansprüche eingehen zu können bleibt den Personalern letztendlich nur ein Weg übrig: selbst agil werden. Das ist nicht immer einfach und nicht immer angenehm, wenn es nicht stattfindet drohen aber immer mehr Geschichten wie die von Marcus Raitner. Und dann mit der Pointe dort nicht angeheuert zu haben.


1Der Verfasser dieser Zeilen war amüsierter Zeuge.
Powered by Blogger.