Donnerstag, 8. April 2021

Alternative Metriken für eine agile Transition

Bild: Wikimedia Commons / James Petts - CC BY-SA 2.0

Eigentlich sollte es gar nicht so schwer sein herauszufinden mit welchen Metriken sich der Erfolg einer agilen Transition validieren lässt. Einige davon hatte ich schon einmal aufgeschrieben, unter anderem kämen da Time to Market, Feedback Implementation Time, (Mean)Time to Recovery und Time to Process Adaption in Frage. Eine häufige Sorge ist dabei aber, dass sie alle dazu führen können, dass alle Erwartungen und Verantwortungen nur auf die unteren Hierarchieebenen abgewälzt werden.


Aufbauend darauf stellt sich die Frage, was für weitere Metriken es geben kann, an denen sich auch das Management messen lassen könnte. Ausgehend davon, dass es in der agilen Zielwelt unter anderem für die richtigen Rahmenbedingungen um möglichst autonome Teams zuständig sein wird wäre dieser Bereich ein naheliegender Ansatz. Und auch für diese Zielzustands-Rahmenbedingungen gibts bereits Definitionen: flache Hierarchien, wenige organisatorische Silos, möglichst wenige Abhängigkeiten.


Bevor das operationalisiert wird aber noch eine letzte Vorbemerkung. Da jeder Einzelfall immer einzigartig ist und da eine agile Zielorganisationen hohe Grenzwerte zulassen kann und muss sollte es sich bei allen folgenden Metriken um die Durchschnittszahlen der gesamten Organisation handeln. Dadurch bleiben Ausnahmen noch immer möglich, es kann aber nicht dazu kommen, dass sie zur Regel werden. Und jetzt in medias res, hier sind Ideen für die alternativen Transitions-Metriken:


I. Anzahl der Menschen die einem Product Owner eine Entscheidung untersagen können

Dass diese Zahl bei Null liegen könnte werden zwar nur Scrum-Fundamentalisten glauben, wie hoch sie im Ist-Zustand fast jeder grösseren Firma ist, ist aber selbst für deren Angehörige immer wieder erschreckend. Vorstände gehören dazu, verschiedene Bereichs-, Abteilungs-, Initiativen-, Programm- und Projektleiter, dazu meistens Fachabteilungs-, Produkt- und sonstige Manager sowie Angehörige der Vertriebs-, Anforderungsmanagement-, Rechts-, Datenschutz- und Compliance-Abteilungen. In Summe kommt so schnell eine mittlere zweistellige Personenzahl zusammen, die entweder Sitz in Lenkungs-Gremien oder Vetorecht hat. Ein gutes Transitionsziel kann sein, diese Zahl einstellig werden zu lassen.


II. Anzahl der Menschen die einem Team die Art der Umsetzung vorschreiben können

Auf den ersten Blick ein ähnlicher Fall, nur mit anderen Beteiligten, auf den zweiten mehr. Zu den disziplinarischen Vorgesetzten kommen hier die Architekten, Lead Developer, Test-, Release-, Integrations- und sonstigen IT-Manager, dazu aber auch andere Angehörige der unteren Hierarchie-Ebenen. Wenn andere Teams die selben Services und Komponeneten benutzen ist es schliesslich nur natürlich, dass sie Entscheidungen widersprechen dürfen von denen sie betroffen sind. Ein Transitionsziel auch diese Zahl einstellig werden zu lassen muss daher nicht nur zur Entflechtung von Mitspracherechten führen sondern auch zur Entflechtung von IT-Systemen.


III. Anzahl der organisatorischen Einheiten die beteiligt sein müssen um ein crossfunktionales Team zu bilden

Auch hier gilt: selbst für die Angehörigen grosser Firmen ist immer wieder erschreckend wie gross diese Zahl sein kann wenn End to End-Verantwortung erreicht werden soll. Der PO hängt im Produkt-, der Scrum Master im Projektmanagement, Entwickler in der Entwicklung, Tester in der QA, UXler, Release-Manager und Business Analysten können eigene Abteilungen haben und der Produktions-Betrieb wird oft sogar von eigenen Gesellschaften verantwortet. Alleine um das Customer-Vendor Antipattern zu vermeiden macht es Sinn hier die Zahl zu reduzieren. Das ideale Transitionsziel wäre eine Eins, aber auch eine niedrige einstellige Zahl wäre fast überall eine Verbesserung.


IV. Anzahl der Teams denen ein durchschnittlicher Mitarbeiter der Ausführungsebene gleichzeitig angehört

Ein Phänomen das häufig gemeinsam mit einem funktionalen Abteilungsschnitt auftritt ist die gleichzeitige Zugehörigkeit einzelner Personen zu mehreren Teams, z.B. wenn sich zwei UX-Designer auf mehr als zwei Projekte aufteilen müssen. Die dadurch entstehenden negativen Effekte (Terminkonflikte, Kontext-Wechsel, etc.) sind zwar bekannt, trotzdem sind in grossen Organisationen fünf bis zehn gleichzeitige Mitgliedschaften nicht ungewöhnlich. Da manche Hochspezialisierungen kaum vermeidbar sind (z.B. Juristen oder Penetrationstester) ist ein Transitionsziel von Eins zwar wenig realistisch, ein Durchschnittswert zwischen Eins und Zwei kann aber angestrebt werden.


V. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um mit einem Endkunden reden zu können

Auch hier kann mehr dahinterstecken als man zunächst ahnt. Das erste und offensichtlichste Hindernis sind natürlich andere Einheiten die bisher das Monopol auf den Endkundenkontakt hatten (häufig Vertrieb, Marketing und/oder Kundendienst), dazu kommt aber auch, dass in der Budgetierung von Entwicklungsteams meistens kein Posten für Kunden-Gespräche vorgesehen ist, bzw. dass dieser aufwändig beantragt und genehmigt werden muss. Ein gutes Transitionsziel in diesem Bereich wäre die Zahl Null, was in der Umsetzung nicht nur zum Abbau von Kommunikationsbarrieren führen würde sondern auch zum Ende von Micromanagement-Versuchen über das Budget.


VI. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um alle (!) Zahlen zum eigenen Produkt zu erhalten

Apropos Budget. Vor allem Finanz-Zahlen, aber auch Absatzmengen und Nutzungsdaten sind in vielen Firmen für die Entwicklungsteams gar nicht oder nur erschwert zugänglich. Wie aber soll ein Team Intrapreneurship (wirtschaftliches Denken und Handeln) eintwickeln wenn ihm weder bewusst ist welche Kosten es verursacht noch welche Umsätze und Gewinne es erwirtschaftet? Auch hier ist das ideale Transitionsziel die Zahl Null, aber selbst eine Reduzierung auf den niedrigen einstelligen Bereich würde fast überall ein deutliches Mehr an Transparenz und deutlich weniger Herrschaftswissen bedeuten.


Wie oben gesagt, das Erheben und gezielte Senken derartiger Zahlen kann ein wirkungsvoller Weg sein um zu verhindern, dass die Änderungs-Aufwände (bewusst oder unbewusst) ausschliesslich auf die Teamebene gewälzt werden. Wer so vorgeht kommt am Verändern der Rahmenbedingungen nicht vorbei - und das ist auch gut so, denn ohne das haben nur die wenigsten Transitionen eine wirkliche Aussicht auf Erfolg.

Montag, 5. April 2021

Agile Rhapsody

 Ich muss mich im voraus entschuldigen, an der einen oder anderen Stelle klingt dieses Lied ein kleines bisschen schief. Aber da müssen wir jetzt durch, denn was diese Damen und Herren aufgenommen haben ist eine Coverversion von Queens Bohemian Rhapsody, mit auf Scrum und Kanban umgedichteten Texten. Und diese Kombination kann nicht unbeachtet bleiben.



Ganz nebenbei: gefühlt gibt es auf dieser Seite mittlerweile schon so viele "Agile Lieder", dass ich fast über eine eigene Kategorie nachdenken könnte.

Mittwoch, 31. März 2021

Kommentierte Links (LXXIII)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Henning Kagermann, Wolfgang Wahlster: Zehn Jahre Industrie 4.0

Mit dem Begriff Industrie 4.0 geht es mir vermutlich so wie anderen Leuten mit dem Begriff Agil - ich ahne, dass eine grundsätzlich gute Idee dahintersteckt, nehme aber vor allem Buzzwords wahr. Um so dankbarer bin ich, dass die beiden Erfinder sich zum zehnjährigen Jubiläum des initialen Artikels Industrie 4.0: Mit dem Internet der Dinge auf dem Weg zur 4. industriellen Revolution die Zeit genommen haben noch einmal aufzuschreiben was genau ihre Intention war. Die zwei zentralen Aussagen sind dabei "Die Vernetzung von Menschen, intelligenten Objekten und Maschinen, die Nutzung serviceorientierter Architekturen, die Komposition von Diensten und Daten aus unterschiedlichen Quellen zu neuen Geschäftsprozessen" und "Eine besseren und sinnvolleren Mensch-Maschine-Kooperation ohne Angst vor Kontrollverlust". Noch immer leicht sperrige Sätze, aber solche die man voll unterschreiben kann.

Ross Clanton, Amy Walters: Culture and Leadership

Mit diesem Artikel haben Clanton und Walters ihre Serie The Seven Domains of Transformation zu einem würdigen Höhepunkt und Ende geführt. Das was sie hier über Incentivierung, Fehler- und Lernkultur, Lern- und Austauschformate und zu überwindende alte Gewohnheiten schreiben ist zwar nicht grundlegend neu, es fasst aber viele gute Ideen und bewährte Konzepte gut lesbar zusammen. Auch der häufige Gegensatz von "Bottom up-" und "Top Down"-Initiativen im Change Management wird angesprochen, mit der originellen aber in der Umsetzung anspruchsvollen Lösung, dass dabei das (überzeugende) Zielbild von oben vorzugeben ist, die Umsetzung aber von unten zu erfolgen hat. Insgesamt ein guter Impuls nicht nur zum selber Lesen sondern auch zum Weitergeben an alle Führungskräfte.

Rob Cross, Heidi K. Gardner, Alia Crocker: For an Agile Transformation, Choose the Right People

Die Frage mit welchen Mitarbeitern man ein agiles Pionier-, Transformations- oder Vorzeigeteam besetzen sollte ist einer der grossen Klassiker wenn Unternehmen ihre Strukturen und Prozesse beweglicher machen wollen. Rob Cross, Heidi K. Gardner und Alia Crocker haben dazu einige lesenswerte Gedanken zusammengefasst, darunter auch solche die der gängigen Mehrheitsmeinung widersprechen. Dass derartige Teams nicht ausschliesslich aus zu hundert Prozent verfügbaren Personen zusammengesetzt werden sollten erscheint zum Beispiel zuerst widersinnig, wenn man bedenkt, dass die besten Leute aber (zumindest zu Beginn) nicht ganz zu haben sein werden macht es durchaus Sinn. Ein kleiner Zusatz-Ratschlag: der Artikel erhält ausklappbare Textboxen - auch die sind durchaus einen näheren Blick wert.

Rajiv Prabhakar: Wie sich Softwareverrottung verhindern lässt

Die Lösung die sich Rajiv Prabhakar überlegt hat könnte man auch mit einem Wort zusammenfassen: Refactoring. Sein Text geht allerdings auf verschiedene Details vertieft ein, so dass es trotzdem Sinn macht ihn zu lesen. Zum Einen gibt er anschauliche Beispiele dafür wie "Software Rot" entsteht (btw: gibt es dafür nicht eine bessere Übersetzung als "Softwareverrottung"?) und mit welchen Kosten und Risiken sie verbunden ist, zum Anderen hat er einen durchaus kontroversen Lösungsvorschlag: in bestehenden Systemen sollte permanent irgendetwas verändert werden, selbst wenn es dafür keine fachliche oder technische Notwendigkeit gibt. Der Grund dafür es trotzdem zu tun ist der, dass dadurch im kollektiven Gedächtnis der Organisation das für Erhaltung und Betrieb relevante Wissen ständig aufgefrischt wird. Das wirklich Verrückte daran ist aber nicht seine Idee selbst - es ist die Vermutung, dass das tatsächlich die insgesamt wirtschaftlichste Lösung sein könnte.

Barry O’Reilly: The Metrics Of Digital Transformation: Small Steps to Outcome-Based Innovation

Ein Beitrag der Vieles in sich vereint. Eine traurige Bestandsaufnahme grosser Transformationsforhaben, einen Seitenhieb gegen SAFe, einen Aufruf zur Subversivität, Plädoyers für Transparenz und Datengetriebenheit, ein Hoffnung machendes Praxisbeispiel und einen Ausblick in eine bessere Zukunft. Da sollte für jeden etwas dabei sein.

Montag, 29. März 2021

Biggest Bottleneck Ever Given

Bild: Wikimedia Commons / NASA - Public Domain
Es ist immer hilfreich wenn man komplexe Sachverhalte mit nachvollziehbaren Analogien erklären kann, selbst wenn diese auf eher unerfreulichen Ereignissen beruhen. Seit März 2021 sind wir um eine solche Analogie reicher, und zwar aufgrund eines der folgenschwersten Verkehrsunfälle der Menschheitsgeschichte. Sein Schaden dürfte in die Milliarden gehen, aber immerhin - durch ihn können wir die Risiken von Flaschenhälsen in Wertströmen so anschaulich erklären wie nie zuvor.


Gegenstand dieser Geschichte ist das Container-Frachtschiff Ever Given, das am 23.03. beim Passieren des Suez-Kanals so unglücklich von einem Sandsturm getroffen wurde, dass es sich quer stellte und an beiden Enden auf Grund lief, wodurch der Kanal, die bedeutenste Wasserstrasse der Welt, tagelang blockiert wurde. Zahllosen anderen Schiffen blieben dadurch nur zwei Möglichkeiten: bis zur Befreiung der Ever Given warten oder den zehn Tage längeren Umweg um Afrika nehmen.


Verschiedene Aspekte lassen sich für Vorträge oder Workshops verwerten. Zunächst ein häufig übersehener: ein Flaschenhals ist nicht zwingend die einzige Stelle durch die ein Wertstrom fliessen kann, es ist aber die schnellste oder wirtschaftlichste. Andere können zwar existieren (in diesem Fall die Route um Afrika) gleichwertige Alternativen sind sie allerdings wegen der mit ihnen verbundenen zusätzlichen Aufwände nicht.


Ein weiterer Punkt der sich anhand der Suez-Blockade gut vermitteln lässt ist das mit Flaschenhälsen verbundene Risiko: ein einziger feststeckender "Liefergegenstand" kann weitreichende Auswirkungen haben. Darüber hinaus lassen sich auch Schwarze Schwäne mit ihr veranschaulichen, also Risiken die praktisch nicht vorhersehbar waren. Dass ein so grosses Schiff hier auf Grund laufen könnte war aus gutem Grund nicht zu ahnen - bis 2018 gab es einfach noch keine in dieser Grössenordnung.


Ebenfalls gut mit diesem Beispiel zu erklären sind die beiden eigentlich abstrakten Konzepte von totem Kapital und Cost of Delay. Dass die Ladungen der über 350 an ihrer Weiterfahrt gehinderten Frachtschiffe dem Wirtschaftskreislauf entzogen (und damit "tot") sind dürfte auch für Nicht-Wirtschaftswissenschaftler offensichtlich sein, und für die Verspätungskosten gibt es sogar eine Zahl: mehr als zehn Milliarden dürfte der wirtschaftliche Gesamtschaden am Ende betragen.


Bild: ESA, Contains modified Copernicus Sentinel data 2021 - CC BY-SA 3.0 IGO


Es sindaber nicht nur die negativen Seiten von Flaschenhälsen die sich anhand des Unfalls der Ever Given erzählen lassen, auf der anderen Seite sind es auch die möglichen Arten mit diesem Risiko umzugehen. Die naheliegendste davon dürfte sein, den Engpass zu erweitern, etwa im Fall des Suez-Kanals durch eine zweite Fahrrinne. Das ist zwar in der Umsetzung teuer, im Vergleich zu möglichen Unfallkosten (siehe oben) aber ggf. zu rechtfertigen.


Auch die Sinnhaftigkeit kleinerer Lieferpakete lässt sich hier darstellen: zum einen würde bei vielen kleineren Schiffen nur ein Teil des zu liefernden Werts von einem blockierten Flaschenhals betroffen sein, zum Anderen kann davon ausgegangen werden, dass diese kleineren Fahrzeuge nur einen Teil der Engstelle blockieren würden - oder aufgrund ihrer geringeren Grösse äusseren Einflüssen (wie dem Sandsturm) eine viel kleinere Angriffsfläche bieten würden.


Wie alle Analogien hat natürlich auch die der Suez-Blockade ihre Grenzen, als plakativer und leicht nachvollziehbarer Einstieg in den Themenkomplex Flaschenhälse und Wertströme ist sie aber definitiv verwendbar. Ein vertiefteres Eingehen ist danach ja noch immer möglich. Und als eingängiges Schaubild dürfte die quer im Kanal steckende Ever Given geeignet sein wie wenige sonst.



Donnerstag, 25. März 2021

Krabbenkörbe

Bild: Wikimedia Commons / USEPA - CC0 1.0

Zu den einfachsten und stärksten Metaphern für die Schwierigkeiten die die Menschen sich gegenseitig bereiten gehört die des Krabbenkorbes. Die in einer solchen Falle gefangenen Krabben versuchen zwar zu entkommen, da jede sich an den jeweils anderen hochziehen und auf ihnen abstützen will behindern sie sich gegenseitig aber so sehr, dass alle gefangen bleiben. Die Übertragung auf die Gesellschaft liegt nahe: statt sich gegenseitig zu helfen ziehen die Menschen sich gegenseitig herunter.


Allerdings: so offensichtlich diese Deutung auf den ersten Blick auch erscheinen mag, bei einer näheren Betrachtung bietet sich ein ungleich komplizierteres Bild. Zum einen sind die Menschen zum Glück deutlich besser als ihr Ruf, zum anderen ist es aber leider doch so, dass sich in der Realität (und hier vor allem in der Arbeitswelt) immer wieder Krabbenkörbe beobachten lassen. Das wirkt zunächst widersprüchlich, lässt sich aber erklären.


Zunächst zur Natur des Menschen. Selbst wenn es unbestreitbar ist, dass es missgünstige und zur Sabotage neigende Charaktere gibt, sind in der Biologie, Psychologie und Soziologie immer wieder Belege dafür gefunden worden, dass es auch einen weitverbreiteten Drang zum selbstlosen Helfen gibt, der sich in vielfältiger Form manifestiert, von der religiös begründeten Nächstenliebe über staatliche Sozial- und Stipendiensysteme bis hin zu den unterstützenden Positionen in Mannschaftssportarten.


Die gleichzeitig beruhigende und beunruhigende Erkenntnis die sich hieraus ziehen lässt: dort wo es zu den Effekten des gegenseitigen Herunterziehens kommt handelt es sich um kein naturgegebenes Schicksal, die Ursache muss an anderer Stelle liegen. Und wenn die menschliche Natur wegfällt bleibt eigentlich nur ein anderer möglicher Entstehungsgrund übrig - das die Menschen umgebende soziale System, das durch seine Rahmenbedingungen das Verhalten seiner Angehörigen formt.


Hat man sich einmal auf diesen Gedanken eingelassen wird man vor allem in grossen Organisationen zahlreiche Beispiele finden, etwa dort wo Softwareentwicklungs-Organisationen in Programmier- und Test-Abteilungen getrennt sind. Während dort ein Entwickler in der Regel für einen möglichst frühen Code Freeze belohnt wird erhält der Tester seine Anerkennung oft dafür, dass er bis zum letztmöglichen Zeitpunkt nach Fehlern sucht. Und derartig gegenläufige Ziele sind kein Einzelfall.


Einkaufs-Mitarbeiter werden meistens angehalten externe Arbeitskräfte möglichst billig einzukaufen, während intern möglichst gute (und damit teure) externe Kollegen gebraucht werden. Von Vertriebs-Einheiten werden hohe Umsätze durch neue Features verlangt, während die Teams in der Anwendungs-Entwicklung mehr Ressourcen für Refactoring brauchen um ihre Stabilitätsziele zu erreichen. Etc. Die aus diesen und vergleichbaren Fällen entstehende gegenseitige Behinderung ist absehbar.


Auf den ersten Blick scheint diese Betrachtung tragisch zu sein, werden hier doch eigentlich altruistische Mitmenschen durch Systemzwänge in eine gegenseitige Sabotage getrieben, die sie von sich aus nie anstreben würden. Auf den zweiten Blick ist das Erkennen dieser Zusammenhänge aber Grund zum Optimismus: es ist möglich die Krabbenkorb-Mentalität verschwinden zu lassen - man muss dafür nur die Rahmenbedingungen verändern.

Montag, 22. März 2021

Hybrid

Bild: Pixabay / Krefe - CC0 1.0

Es ist fast schon ein Naturgesetz. Bei praktisch jeder Unternehmenstransformation in Richtung Agilität kommt früher oder später jemand auf die Idee, dass man doch auch ein "hybriden" Ansatz wählen könnte. Gemeint ist damit in der Regel eine Mischung aus klassischen und agilen Vorgehensweisen, gewissermassen "das Beste aus beiden Welten". Das mag auf den ersten Blick auch verlockend wirken, zeugt in Wirklichkeit aber nur von einem grossen Missverständnis.


Um zu verstehen warum das so ist, ist ein Schritt zurück nötig, zur Frage was Agilität eigentlich bedeutet. Kurz gesagt: es ist die Fähigkeit in kurzen Abständen Mehrwert zu liefern und auf Änderungen zu reagieren. Und da davon ausgegangen wird, dass die Rahmenbedingungen sich ständig ändern muss ständig aufs Neue daran gearbeitet werden agil zu werden oder zu bleiben. Mit anderen Worten - es ist ein Zielbild. Das kann sowohl mit den bestehenden Prozessen und Strukturen erreicht werden als auch mit neuen, Hauptsache es funktioniert.


Im Gegensatz dazu sind die meistens als "klassisch" bezeichneten Ansätze deutlich stärker deskriptiv ausgestaltet. In ihnen wird in zum Teil erstaunlichem Detaillierungsgrad vorgegeben wer wann was zu tun hat, wie und wo er das zu dokumentieren hat, wem er davon zu berichten hat und was dieser mit den erhaltenen Informationen zu tun hat. Die Einhaltung dieser Vorgaben wird in den meisten Organisationen regelmässig überprüft und eine Abweichung sanktioniert.


Was durch diese Gegenüberstellung klar wird ist, dass "Agil" und "Klassisch" nicht nur unterschiedliche Methoden sind sondern grundsätzlich verschiedene Konzepte. Agilität definiert sich durch einen Zielzustand, der mit sich ständig ändernden Mitteln verfolgt und wiederhergestellt werden muss, klassische Vorgehensmodelle legen dagegen sehr klar die Abläufe und Strukturen fest, die bereits im hier und jetzt dem finalen Zielbild entsprechen und sich nur noch möglichst wenig ändern sollen.


Bedingt durch diese Unterschiede führt der Versuch hybride Ansätze zu etablieren in praktisch allen Fällen in nicht lösbare Konflikte. Einen Umsetzungsweg zur selben Zeit zu standardisieren und ihn möglichst offen und flexibel zu lassen ist einfach nicht möglich. Im Ergebnis wird entweder eine der beiden Seiten sich durchsetzen oder es wird zu einem ständigen Hin und Her kommen, auf Kosten von Nerven und Ressourcen.


Diese Zusammenhänge zu erkennen und zu vermitteln kann übrigens nicht nur vorbeugend sinnvoll sein. Die meisten festgefahrenen oder scheiternden Transitionsvorhaben befinden sich ebenfalls wegen dem (sicher gut gemeinten) Versuch hybrid vorzugehen in diesem Zustand. Sich davon zu lösen kann der entscheidende Schritt sein um wieder Fahrt aufzunehmen.

Donnerstag, 18. März 2021

Agile Manufacturing

Bild: Wikimedia Commons / Ron Clausen - CC BY-SA 4.0

Man kann sich das Erstaunen vorstellen mit dem am Anfang auf dieses "agile Arbeiten" reagiert wurde. Kleine, selbstorganisierte Teams, flache Hierarchien, direkte Kommunikation und reaktive, datengetriebene Verbesserungsprozesse passten auf den ersten Blick so gar nicht zu den bewährten Strukturen. Aber sobald die Effektivitätsgewinne sichtbar waren gab es kein Halten mehr - sogar grosse Traditionskonzerne wollten plötzlich agil sein, an Hochschulen wurde zu dem Thema gelehrt und publiziert und selbst die staatliche Wirtschaftsförderung sah in Agilität die Zukunft der Wirtschaft.


Jetzt zur Preisfrage: wann haben sich die hier beschriebenen Ereignisse zugetragen? Ab 2001, nach dem Verfassen des Agilen Manifests? Ab 2011, nachdem mit SAFe und LeSS die ersten Skalierungsframeworks entstanden sind? Oder zu einer ganz anderen Zeit? Die überraschende Antwort ist die dritte - der Trend setzte deutlich früher ein, nämlich ca. 1990. Und noch überraschender: der Anwendungsschwerpunkt war (noch) nicht die IT sondern die Fertigungsindustrie, in der "Agile Manufacturing" betrieben wurde. Kaum jemand weiss von dieser erste Blütezeit der Agilität, und doch hat sie existiert und es selbst in namhafte Medien wie die New York Times, den Chicago Tribune und das MIT Sloan Review geschafft.


Was aus diesen Artikeln hervorgeht ist eine erstaunlich grosse Verbreitung. Unter anderem haben Ford, Motorola, Boeing, Apple, Siemens, IBM, General Motors, General Electric, Goodyear und Chrysler in ihren Fabriken agil gearbeitet, das amerikanische Verteidigungsministerium hat diese Arbeitsweise zum Bestandteil von Ausschreibungen gemacht und an Universitäten sind ganze Forschungsinstitute entstanden die sich wissenschaftlich mit diesem Thema auseinandergesetzt haben. Sogar die staatlichen Wirtschaftsförderungen in Amerika, der europäischen Union und Japan scheinen das Konzept gekannt und gefördert zu haben.


Auch inhaltlich entsprach der Begriff der Agilität schon weitgehend dem was wir heute darunter verstehen. Die Berichte beschreiben zwar auch einiges was man heute eher in die Konzepte der Lieferketten-Optimierung, des Lean Management und der Digitalisierung einordnen würde, die übergreifende Idee ist aber die, die bis heute aktuell ist: Agilität als die Fähigkeit schnell und mit wenigen Reibungsverlusten auf sich ändernde Rahmenbedingungen zu reagieren. Und Umsetzungs-Elemente wie Teams von maximal 10 Mitgliedern und die Nutzung von Monitoring-Ergebnissen zur Prognostizierung von Wartungsbedarf könnten so auch aus Scrum und DevOps kommen.


Angesichts dieser scheinbaren Kontinuität ist es um so erstaunlicher, dass die Verwendung des Namens Agile Manufacturing Ende der 90er Jahre scheinbar aufgegeben wurde. Ab ca dem Jahr 2000 sind kaum noch Veröffentlichungen und Medienberichte zu finden, in der jüngeren Vergangenheit gar keine mehr. Über die Gründe kann nur spekuliert werden. Vielleicht wurde Agilität durch das agile Manifest nur noch als IT-Idee wahrgenommen, vielleicht wurde sie in der Fertigungsindustrie nach einer zu starken Hype-Phase als Mode-Phänomen verworfen, vielleicht wurden die Prinzipien und Praktiken aber auch so sehr zur Normalität, dass sie keinen Namen mehr brauchten. Man weiss es nicht.


Was heute aufgrund dieses damals stattgefundenen "kollektiven Anmesie-Vorfalls" zu beobachten ist, ist jedenfalls vor dem Hintergrund der Geschichte hoch paradox - jedesmal wenn eine der alle paar Jahre wiederkehrenden Initiativen durch die Unternehmen läuft, dass doch auch die Hardware-Fertigung agile Vorgehensweisen übernehmen könnte, wird dem an vielen Stellen mit Skepsis begegnet. Es wäre doch gar nicht klar ob ein "so neumodischer" und "aus der IT kommender" Ansatz sich hier umsetzen liesse. Dass in Fabriken bereits agil gearbeitet wurde als in der IT noch niemand diesen Begriff benutzte überrascht dann fast jeden der davon hört.


Zwar braucht es die "historische Untermauerung" nicht um in diesen Diskussionen die Vorteile der agilen Frameworks herauszustreichen, die sprechen bereits ausreichend für sich. Das was man aber machen könnte ist, die Ereignisse der 90er Jahre für die begleitende Kommunikation zu nutzen. "Take agile back to the roots", "Agile is coming home" oder "Don't follow the hypes, stick to Agile Manufacturing" wären doch grossartige Kampagnen-Slogans, oder?.

Montag, 15. März 2021

Das Problem mit SAFe (III)

Bild: Pexels / Andrea Piacquadio - CC0 1.0

Über die Herausforderungen und Fallstricke die sich ergeben wenn man versucht das Scaled Agile Framework (SAFe) in einem Grossunternehmen einzuführen1 ist mittlerweile so viel gesagt worden, dass man darüber ganze Bücher schreiben könnte. Die meisten davon würden sich aber sehr einseitig um die Debatte drehen ob ein Konstrukt mit so viel Regulierung und so vielen Rollen überhaupt agil sein kann2 und einen weiteren, vermutlich sogar tiefgreifenderen Aspekt dabei erstaunlich vernachlässigen.


Es handelt sich um die Frage ob die oft negative Wahrnehmung von SAFe nicht mittlerweile Züge einer selbsterfüllenden Prophezeihung hat. Von der überwältigenden Mehrheit der vom Konzept der Agilität überzeugten Angehörigen der unteren Hierarchie-Ebenen schlägt SAFe heute eine hohe Skepsis entgegen, zum Teil sogar eine vehemente Ablehnung.3 Wie berechtigt das ist, ist dabei gar nicht relevant, wichtig ist die Wahrnehmung selbst.


Deren mittlerweile weite Verbreitung resultiert darin, dass auf Team- oder Abteilungsebene selbstorganisierte Optimierungsbemühungen praktisch nie dazu führen, dass dort SAFe als Lösungs- oder Verbesserungs-Option für Koordinations- oder Alignment-Probleme genannt wird. Wenn es diskutiert wird dann fast ausschliesslich auf Betreiben von Beratern oder Managern. Aus Sicht der umsetzenden Einheiten kommt es damit "von Aussen".


Wer bereits Change Management in grossen Organisationen betrieben hat wird das an derartigen Stellen entstehende Risiko kennen: das Gefühl von Aussen eine ungewollte Änderung aufgedrückt zu bekommen kann zu Abstossungsreaktionen führen, manchmal in Form von aktivem Widerspruch und Widerstrand, oft durch passive und ausweichende Handlungsmuster wie dem ständigen Melden von Verständnis-Poblemen, Dienst nach Vorschrift und brauchbarer Illegalität.


Alle Varianten sind bereits für sich genommen problematisch, im Kontext des agilen Arbeitens, das stark auf freiwillige Kooperation und Eigeninitiative aller Beteiligten angewiesen ist, sind sie es nochmal in besonderer Form. Die in vielen SAFe-Umsetzungen zu findenden hohen Ausmasse am Konfliktlastigkeit, Ineffektivität und Ineffizienz lassen sich in weiten Teilen damit erklären, ggf. noch verschärft durch Versuche die Einführung zu erzwingen oder den Mitarbeitern ihre Bedenken auszureden.


Heisst das, dass eine Einführung von SAFe dort wo es diese Skepsis gibt unmöglich ist? Nein, natürlich nicht, das wäre auch zu deterministisch. Um die selbsterfüllende Prophezeihung zu vermeiden kann es aber sehr sinnvoll sein vor (!) einer Entscheidung für dieses Framework mit allen Beteiligten die Gründe für und gegen agile Skalierung zu besprechen und gemeinsam nach einem passenden Ansatz zu suchen. Der kann dann SAFe sein, aber ggf. auch ein anderer, dem deutlich weniger Skepsis entgegenschlägt und mit dem man dadurch einfacher und schneller seine Probleme lösen kann.


1Für kleinere Einheiten ist es nicht gedacht 
2Was weniger einfach zu beantworten ist als viele denken
3Eine Entwicklung die durch skeptische Äusserungen vieler "Thought Leader" befeuert wird

Donnerstag, 11. März 2021

Agile Prozesse

Grafik: Pixabay / Geralt - CC0 1.0

"Wir haben keinen Prozess, wir arbeiten agil", ist einer der grossen Klassiker, den man von vielen Teams hört wenn man sie fragt wie sie ihre Arbeitsabläufe organisieren. Häufig wird diese Aussage ergänzt durch eine zweite: "Wir arbeiten stattdessen nach Scrum." (oder Kanban oder XP). Eine schwierige Selbstwahrnehmung. Selbst wenn sie für einen Agilisten auf den ersten Blick naheliegend wirkt - tatsächlich zeugt sie von einigen Missverständnissen.


Um mit dem naheliegendsten anzufangen: natürlich gibt es einen Prozess. Sobald man eine Tätigkeit ausübt die auch nur in Ansätzen widerholbare oder vergleichbare Ergebnisse erzeugt wird es fast zwangsläufig sein bestimmte Schritte regelmässig zu wiederholen. In einem berechenbaren Umfeld kann das z.B. standardisierte Akkord-Arbeit sein, in einem unberechenbaren Umfeld ein schneller Wechsel von kleinteiliger Mehrwerterzeugung und schnellen Überprüfungs- und Anpassungsschritten.


Was beidem gemeinsam ist (und allen dazwischen liegenden Abstufungen auch) - es handelt sich dabei um einen Prozess im wahrsten Sinne des Wortes, also eine Aneinanderreihung definierter Ver- oder Bearbeitungsschritte mit dem Ziel ein Produkt oder eine Dienstkeistung zu erzeugen. Selbst die häufig postuliertes Alternative "ich überlege einfach bei jeder neuen Aufgabe was das sinnvollste Vorgehen sein könnte" ist bei näherer Betrachtung nichts anderes.


Was lediglich die Besonderheit im zuletzt genannten Beispiel (und bei Scrum, Kanban, XP, etc.) ausmacht ist, dass diese Prozesse relativ minimalistisch sind. Es gibt nur wenige harte Regeln wie die Lieferung in Sprints oder die  WIP-Limits, und es bleibt den Anwendern selbst überlassen wie deren Einhaltung sichergestellt wird. Das wirkt wie laissez-faire, ist aber im Grunde besonders rigoros - der Hintergrund dieser Freiheit ist, dass jedes Mittel zulässig sein soll um die harten Regeln einhalten zu können.


Dass darin kein Prozess gesehen wird liegt an einem zweiten Missverständnis: dem, dass Prozesse immer umfassend und detailliert sein müssen. Das gibt es zwar auch, dieser Typ, der starre Prozess, ist aber nur einer von mehreren. Er macht nur innerhalb von bestimmten Rahmenbedingungen Sinn, vor allem innerhalb des oben genannten hochgradig berechenbaren und in seinem Verhalten vorhersagbaren Umfelds.


Dort wo die Rahmenbedingungen unberechenbarer sind macht ein anderer Typ Sinn, der agile Prozess, der dann nochmal in zwei Untertypen zerfällt: der erste ist ebenfalls bereits weiter oben genannt, in ihm sind wenige Parameter hart vorgegeben, der Weg zu ihrer Erreichung aber nicht. Im anderen ist auch der Prozess selbst Gegenstand seines eigenen Verbesserungs- und Anpassungsfortschritts.1 Beides wird durch einen möglichst geringen Detaillierungsgrad einfacher.


Um noch mit einem letzten grossen Missverständnis aufzuräumen: häufig wird zwar die Notwendigkeit schlanker Prozesse anerkannt, die Benennung als Agiler Prozess aber nicht, mit der Begründung, dass die Verfasser des Agilen Manifests sich doch gerade von Prozessen hätten freimachen wollen. In solchen Diskussionen empfiehlt sich immer ein Verweis auf die zweite Seite des Manifests. Auf ihr werden agile Prozesse mehrfach erwähnt.


1Häufige Anwendungs-Varianten dieser zwei Typen sind Scrum und Kanban

Montag, 8. März 2021

Inselgigantismus

Bild: Wikimedia Commons / Padanus - CC0 1.0

Zu den vielen Besonderheiten der Natur die sich als Analogie auf Organisationen übertragen lassen gehört auch die, dass seit langem auf Inseln lebende Tierpopulationen mit der Zeit eine Körpergrösse entwickeln die deutlich über der von vergleichbaren Tieren auf dem Festland liegt. Bekannte Beispiele dafür sind die Galapagos-Schildkröte, der Elefantenvogel und der Dodo, es gibt aber auch zahllose weniger bekannte wie die Riesenratte, den Schreckens-Igel und den Riesengecko.


Die Forschung geht davon aus, dass praktisch alle dieser riesenhaften Arten eine vergleichbare Entstehungsgeschichte haben: zu dem Zeitpunkt an dem ihre Inseln besiedelt wurden oder sich vom Festland trennten gab es dort weder Raubtiere vor denen sie fliehen mussten noch knappe Nahrungsvorräte die sie als erstes erreichen mussten. Klein, schnell und wendig zu sein war damit kein evolutionärer Vorteil mehr.


Die Übertragung auf die Wirtschaft ist naheliegend - überall dort wo Unternehmen über längere Zeiträume keinem Wettbewerb oder keiner Bedrohung ausgesetzt sind (weil sie ein Monopol haben, der Markt schwer zugänglich ist, etc.) gibt es die Tendenz zu starkem Wachstum, sowohl in Bezug auf die Personalstärke als auch in Bezug auf Regeln und Prozesse.


Dieser "organisatorische Inselgigantismus" ist dabei abzugrenzen von dem Phänomen, dass vorher nötige und wertschöpfende Einheiten durch Digitalisierung und Automatisierung unnötig werden. Das gibt es auch, es hat aber einen anderen Hintergrund. Es geht hier explizit um ein imposantes aber unnötiges Wachstum, mit Schwerfälligkeit und hohem Ressourcenverbrauch als Folge.


Dass eine solcher Entwicklung problematisch ist dürfte intuitiv nachvollziehbar sein, ein Blick auf die tierischen Inselgiganten zeigt aber die potentiell verheerenden Folgen auf: überall dort wo die Ökosysteme der von ihnen bewohnten Inseln mit anderen verbunden wurden waren sie den plötzlich entstehenden Wettbewerben und Bedrohungen nicht gewachsen. Fast alle Inselgiganten-Spezies stehen heute vor dem Aussterben.


Vor einer noch nicht so dramatischen, aber bereits bedrohlichen Situation stehen heute viele Unternehmen. Ähnlich wie die frühen Handlungsreisenden und Siedler die bis dahin getrennten Ökosysteme miteinander verbanden öffnen heute Handelsabkommen und verbesserte Transport- und Kommunikationstechnologien die Märkte und machen sie für innovative und bewegliche Wettbewerber zugänglich. Organisatorischer Inselgigantismus ist jetzt ein Problem.


Zum Glück endet an dieser Stelle die Analogie. Galapagos-Schildkröte, Elefantenvogel und Dodo waren in ihrer biologischen Form gefangen, sie waren den neuen Bedingungen hilflos ausgeliefert. Organisationen können sich dagegen auch in kurzen Abständen verändern, gesundschrumpfen und beweglich machen - wenn sie es denn wollen.

Freitag, 5. März 2021

The agile Bookshelf: The Culture Map

Bild: Pixabay / Geralt - CC0 1.0

Indirekt ist The Culture Map von Erin Meyer bereits hier auf dieser Seite thematisiert worden, und zwar bei der Besprechung ihres zweiten Buches, No Rules Rules, das sie gemeinsam mit Reed Hastings veröffentlicht hat. Dessen zehntes Kapitel greift die verschiedenen Dimensionen von Kultur auf, die das Hauptthema von The Culture Map sind und dient als Beispiel für ihre Anwendung.


Allen die von diesem Kapitel neugierig geworden sind (und natürlich allen anderen auch) kann das Lesen von Meyers Hauptwerk nur nahegelegt werden. Angereichert mit zahllosen Beispielen aus ihrer Forschung und ihrem persönlichen Erleben werden zentrale Unterschiede zwischen verschiedenen Landeskulturen herausgearbeitet und nachvollziehbar gemacht, so dass viele Begegnungen mit Menschen aus anderen Ländern dadurch in neuem Licht erscheinen.


Natürlich sind unter den aufgeführten Beispielen einige der grossen Klassiker, darunter die unterschiedliche Wertigkeit von Pünktlichkeit in Mitteleuropa und Südasien oder die unterschiedliche Direktheit von Feedback in französisch-sprachigen und englisch-sprachigen Ländern, aber auch solche die man nicht erwartet hätte: etwa dass deutsche und amerikanische Manager sich (aus jeweils unterschiedlichen Gründen) gegenseitig als hierarchisch und unflexibel empfinden.


Diese und weitere Unterschiede werden von Meyer acht verschiedenen Dimensionen zugeordnet, in denen sie die verschiedenen Kulturen jeweils irgendwo auf einer Skala zwischen zwei Glaubens-, bzw. Handlungsmustern einordnet:

  • Kommunikation - wenig kontextspezifisch oder hoch kontextspezifisch?
  • Feedback - direkt oder indirekt?
  • Führungsstil - egalitär oder hierarchisch?
  • Entscheidungsprozesse - im Konsens oder direktiv?
  • Argumentieren - beispielhaft/spezifisch oder ganzheitlich/systemisch?
  • Vertrauen - basierend auf persönlichem Bekanntheitsgrad oder auf Qualität der Zusammenarbeits-Ergebnisse?
  • Konfliktaustragung - konfrontativ oder ausweichend/umschreibend?
  • Zeitempfinden - linear/präzise oder flexibel?

Diese Einordnung (die wie alle derartigen Modelle im Einzelfall problematisch, in der Gesamtbetrachtung aber hilfreich sein kann) kann nicht nur von ihr übernommen sondern auch für die eigene Gruppe/das eigene Unternehmen individuell erstellt werden um Hinweise darauf zu erhalten wo in der Kommunikation mit anderen Gruppen Probleme auftreten könnten.


Um ganz zum Schluss noch die Kurve zum Hauptthema dieser Seite zu bekommen: Ein interessanter Aspekt taucht eher versteckt in diesem Buch auf, es ist der der "kulturellen Agilität" (culturally agile). Unter ihm versteht Meyer die Fähigkeit sich schnell und ohne grosse Missverständnisse und Reibungsverluste an die kulturellen Besonderheiten der Gesprächs- oder Geschäftspartner anpassen zu können. Sicherlich eine erstrebenswerte Fähigkeit.

Dienstag, 2. März 2021

Scrum goes Pop Music

Ein weiterer Beleg für die Soft Power of Scrum: Chad Beider, ein amerikanischer Agile Coach, hat begonnen bekannte Musikstücke mit einem neuen, auf Scrum bezogenen Text zu versehen und neu aufzunehmen. Im Moment sind das drei (neben den beiden die hier eingebunden werden noch ein drittes, dessen Weihnachts-Thema aber nicht mehr zur Jahreszeit passt). Hoffen wir dass bald noch weitere dazukommen.



Sonntag, 28. Februar 2021

Kommentierte Links (LXXII)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Willem-Jan Ageling: Does Scrum’s Product Owner Really Exist?

Auf den ersten Blick eine unverständliche Frage. Product Owner findet man mittlerweile in gefühlt jeder zweiten IT-Abteilung, ihre Existenz dürfte also gesichert sein. Auf den zweiten Blick ist sie aber gar gar nicht so abwegig, denn bei einer radikalen Auslegung des Scrum Guide könnte man tatsächlich Zweifel haben. Besonders der im Scrum Guide stehende Satz "For Product Owners to succeed, the entire organization must respect their decisions" wird in diesem Zusammenhang immer wieder aufgeführt, häufig verbunden mit der (in den meisten Firmen völlig unrealistischen) Forderung, dass das so weit gehen müsste, dass der Product Owner sich gegebenenfalls ohne Rücksprachen entscheiden könnte das Produkt einzustellen. Willem-Jan Ageling nimmt eine solche Aussage Anlass um etwas Kontext und Realismus in die Debatte einzubringen. Das vorweggenommene Fazit: Product Owner gibt es, und Maximalforderungen sind nicht hilfreich.

Christiaan Verwijs: Don’t Scale Up. Scale Your Product Down!

Dass eine immer stärkere Aufblähung eines Produktes dazu führen kann, dass ein Team alleine nicht mehr die ausreichende Kapazität hat um es weiterzuentwickeln ist ein oft anzutreffendes Phänomen. Die häufigste Reaktion darauf ist das Hinzufügen weiterer Teams, deren gemeinsame Arbeit dann durch ein Skalierungsframework koordiniert wird (mit Bürokratie und Ineffektivität als häufiger Folge). Christiaan Verwijs hat einen anderen Vorschlag: warum nicht stattdessen das zu gross gewordene Produkt in mehrere kleine aufspalten, die dann wieder von jeweils einem Team verantwortet werden können? Passend dazu ein ähnlicher Vorschlag von Sara Estes: man kann Produkte auch gesundschrumpfen indem man Features wieder entfernt.

Jeff Gothelf: Hiring and retention is not HR’s responsibility. It’s yours.

Letzten Endes betont Jeff Gothelf hier einmal mehr, dass organisatorische Silo-Strukturen problematisch sind. Er geht aber auch darüber hinaus und zeigt eine weitreichende Konsequenz auf: wenn man nicht mehr von wenigen zentralen Einheiten abhängig sein will dann führt kein Weg daran vorbei deren Aufgaben zumindest in Teilen selbst zu übernehmen. Sein Beispiel dafür ist HR, es liesse sich aber auch auf viele andere übertragen. Wer wirklich crossfunktionale Einheiten anstrebt wird an derartigen Überlegungen nicht vorbeikommen.

Serafin Eilmes: Das Paradox der Holakratie – Wie durch Regeln Regellosigkeit entsteht

Selbst wenn es in diesem Artikel in erster Linie um Holokratie geht - das grundlegende Phänomen das Serafin Eilmes hier beschreibt lässt sich auch in nahezu jeder grösseren Organisation wiederfinden. Sobald der Umfang der Regeln die die Mitarbeiter zu befolgen haben eine bestimmte Schwelle überschreitet ist es für sie nicht mehr möglich den Überblick über alle Vorgaben zu behalten von denen sie betroffen sind. Im schlimmsten Fall ist die Menge der Vorschriften sogar so gross (und ggf. so verstreut gespeichert), dass es nicht mehr mit vertretbarem Aufwand möglich ist sie auf Relevantes zu durchsuchen. Die Folge: obwohl umfangreiche Regelwerke bestehen kommt es immer wieder vor, dass die regulierten Personen sich über deren Inhalt oder sogar Existenz im Unklaren sind. In Folge dessen wird einfach ein irgendwie sinnvoll scheinender Weg gewählt, der aber im Zweifel ein unbewusster Regelverstoss ist.

Marcus Raitner: Wissensarbeiter in der Autonomiefalle

Bereits letzten Oktober habe ich in einem Artikel von Cal Newport einen Denkanstoss bekommen. Newport geht davon aus, dass das von Peter Drucker eingeführte Führen mit Zielen (Management by Objectives) oft zu positiv gesehen wird, weil es in der Realität immer wieder dazu führt, dass Angestellte mit Zielen überhäuft aber mit der Umsetzung alleingelassen werden. Nachdem ich zwar die Absicht hatte darüber zu schreiben, es aber monatelang vor mir hergeschoben habe, ist mir Marcus Raitner jetzt zuvorgekommen. Besonders zwei der von ihm erörterten Aspekte finde ich wichtig: zum einen ist das was heute unter dem Namen Management by Objectives stattfindet nicht mehr das was Drucker erreichen wollte, aber zum anderen kann die Nutzung von iterativen Ansätzen wie Scrum dafür sorgen, dass es wieder dazu wird.

Donnerstag, 25. Februar 2021

Kanban University veröffentlicht 'Official Kanban Guide'

Bild: Pixabay / 5138153 - CC0 1.0

Etwas überraschend rauschte gestern eine Meldung durch die agilen Filterblasen: die Kanban University hat einen neuen Leitfaden veröffentlicht, genannt "The Official Guide to The Kanban Method". Auf der einen Seite ist das begrüssenswert, inhaltlich scheint es sich um eine kompakte und hilfreiche Zusammenfassung für Einsteiger zu handeln. Auf der anderen Seite gibt es aber einige Anmerkungen und Fragen.



Um mit der wichtigsen Anmerkung anzufangen: das Dokument mag zwar vom Namen her wie ein offizielles Grundlagenwerk der Methodik erscheinen, es ist aber alles andere als das. Anders als im Fall von Scrum oder SAFe gibt es bei Kanban weder einen eindeutigen Urheber noch einen "governing Body" der sich von allen anerkannt um die Weiterentwicklung kümmert. Die Kanban University ist (polemisch gesagt) eine Gruppe von Leuten mit einer Meinung. Das macht die Inhalte des Kanban Guide nicht falsch, sie sind aber nicht vergleichbar gültig wie die des Scrum Guide.


Sachlich und fachlich ist dagegen wenig auszusetzen. Nach einer leicht haarspalterischer Überlegung ob Kanban Methode oder Framework ist folgen die Praktiken Visualize, Limit Work in Progress (WIP), Manage Flow, Make Policies Explicit, Implement Feedback Loops und Improve Collaboratively, Evolve Experimentally, es wird anhand einer Autobahn-Metapher die grundlegende Vorgehensweise erklärt und am Ende gibt es noch Ratschläge für Einführung, Board-Designs, WIP Limit-Umsetzungen, Metriken und Produktionszyklen.


Vom Umfang her ist der Kanban-Guide angenehm überschaubar geworden, er hat lediglich 14 Seiten (einmal mehr dürfte der Scrum Guide hier die Benchmark gewesen sein). Bedenkt man, dass dazu auch Deckblatt und Inhaltsverzeichnis gehören und dass Überschriften, Footer und Grafiken grossen Platz einnehmen sind es sogar noch weniger. Apropos: die grafische Gestaltung ist wie immer Geschmackssache, mit vielen Farben und Comic-artigen Grafiken ist sie aber zumindest gewöhnungsbedürftig.


Etwas verwirrend ist, dass die Kanban University jetzt zwei "Guide" genannte Dokumente hat, neben dem hier besprochenen "offiziellen" Guide auch den älteren Essential Kanban Condensed Guide, der dazu trotz seines Namens deutlich umfangreicher ist als der neue Leitfaden. Genau wie der neue lässt sich auch der alte Guide noch von der Website der herunterladen und es gibt noch keine Aussage dazu ob er weiterhin gilt oder durch seinen Nachfolger obsolet geworden ist.


Alles in allem kann man sagen, dass der "Official Guide to The Kanban Method" ein handliches und für Einsteiger sicher nützliches Dokument geworden ist, bei der die Einführung begleitenden Kommunikation währe aber etwas mehr Klarheit wünschenswert gewesen. Andererseits dürfte sich das in der näheren Zukunft problemlos nachholen lassen.

Dienstag, 23. Februar 2021

Kein Richtiges im Falschen

Bild: Wikimedia Commons / Vysotsky - CC BY-SA 4.0

Es gibt einige hochproblematische Denk- und Handlungsmuster die mir in mittlerweile mehr als zehn Jahren Unternehmensberatung und Agile Coaching immer wieder aufgefallen sind, sowohl bei Kunden als auch bei anderen Beratern. Eines davon durfte ich mir vor kurzem auf einer Rede auf einer Branchenveranstaltung wieder anhören. Da es schwerwiegende Auswirkungen haben kann lohnt sich ein näherer Blick.


Die zentrale These lautete, dass Hochleistungsteams in grossen Unternehmen nur bestehen können wenn sie permanent gegen Regeln verstossen. Alles - Machtstrukturen, Kommunikationswege, Organisationsaufbau und Arbeitsabläufe - wäre dort so leistungsfeindlich, dass Leistung nur im unbeachteten Hintergrund stattfinden könnte. Die Aufgabe von Managern müsste es daher sein, diese "verborgenen Inseln der Höchstleistung" zuzulassen und sie gegen Entdeckung und Anpassung an die geltenden Regeln zu verteidigen.


Puh. There is a lot to unpack here, wie die Amerikaner sagen würden. Zunächst die Ausgangslage: offensichtlich kannte der Redner1 aus seiner Arbeit vor allem hochgradig dysfunktionale Organisationen. Dass es die gibt ist unbestritten, und dass er überwiegend dort gelandet ist, ist Pech für ihn. Sein erster Denkfehler ist allerdings, dass er aus seiner lediglich anekdotischen Evidenz eine generelle Regel ableitete (von der ich nicht glaube, dass sie stimmt). Aber gut, gehen wir den Gedankengang mit und tun wir so als wären alle Firmen leistungsfeindlich.


Der zweite Denkfehler baut auf dem ersten auf: nicht nur ist in ihm die Ausgangslage überall gleich schlimm, sie ist auch nirgendwo zum Besseren veränderbar, weil die Regeln (und das sie durchsetzende Management) diese Verbesserung verhindern würden. An dieser Stelle ist vieles problematisch - etwa das Menschenbild, der Determinismus, die durchscheinende Untertanenkultur. Auch hier glaube ich nicht, dass die Annahme stimmt, aber nochmal, gehen wir den Gedankengang mit.


Der dritte (auf den beiden vorigen aufbauende) Denkfehler ist der bei dem es wirklich gefährlich wird: da in dieser Weltsicht die Situation überall gleich dysfunktional ist und da niemand das ändern will (oder kann) bleibt nur noch der bewusste Regelverstoss als einzige Handlungsoption übrig. Warum das gefährlich ist dürfte offensichtlich sein - sobald einmal eine Erziehung zur Normverletzung stattgefunden hat werden mit hoher Wahrscheinlichkeit auch sinnvolle Regeln umgangen werden, und vielleicht sogar Gesetze. Das Ergebnis ist Nihilismus.


Was in der Gesamtsicht dieser Denkfehler erkennbar wird ist das Risiko in das man sich begibt wenn man toxische Rahmenbedingungen nicht ändern will (oder sie für unveränderbar hält) und stattdessen versucht innerhalb dieses Rahmens nur das zu optimieren was von ihm nicht vorgegeben wird. Da bei diesem Vorgehen der Root Cause, also der Ursprung des Problems, nicht angegangen wird, bleiben dessen Auswirkungen bestehen und kontaminieren letztendlich auch die gut gemeinten lokalen Optimierungen.


Auf den Punkt gebracht wurde diese Erkenntnis bereits in den 40er Jahren vom Philosophen Theodor W. Adorno mit seinem mittlerweile geflügelten Wort "Es gibt kein richtiges Leben im falschen",  mit dem er (vereinfacht gesagt) aussagte, dass man sich auch noch so gut gemeinte lokale Verbesserungen eigentlich sparen kann wenn sie in einem dysfunktionalen Gesamtsystem stattfinden. Auf das oben genannte Beispiel übertragen: wer die "verborgenen Inseln der Höchstleistung" vor der toxischen Umwelt versteckt statt diese Umwelt zu reparieren verbessert damit nichts.


Um zum Abschluss zu kommen: warum die hier erläuterten Denk- und Handlungsmuster hochproblematisch sind dürfte jetzt klar sein, dass sie weit verbreitet sind dürfte aber leider auch zutreffen2. Sich dieses Thema bewusst zu machen kann ein zentraler Faktor für Erfolg oder Misserfolg von Verbesserungsvorhaben sein - nicht zuletzt deshalb weil man dann alle Berater und Agile Coaches die nur am Richtigen im Falschen arbeiten wollen sanft auf die Unsinnigkeit ihres Tuns hinweisen kann.



1Keine Nahmensnennung, weil ich ihn weder an den Pranger stellen noch beruflich schädigen will.
2Ja, auch nur anekdotische Evidenz, aber immerhin basierend auf einem Jahrzehnt Beratungserfahrung.

Donnerstag, 18. Februar 2021

The Secrets of High Performing Technology Organizations

Mit Aussagen wie "das Erfolgsgeheimnis von ..." sollte man zwar immer vorsichtig sein, aber das was Jez Humble hier erzählt hat nicht nur Hand und Fuss sondern auch eine solide Datenbasis. Mehr als 31.000 Teilnehmer haben dem DevOps Research & Assessment-Program ihre Daten zur Verfügung gestellt, man kann also davon ausgehen, dass das Ergebnis Relevanz hat.



Ebenfalls zu empfehlen sind neben dem Video auch die Inhalte der weiter oben verlinkten Website. Zum einen ist das eine dort zu findende interaktive Visualisierung verschiedener Erfolgsfaktoren, zum anderen aber auch verschiedene Studien und Paper. Zu empfehlen ist besonders dieses hier. Wer mag kann hier eine Erkenntnis gewinnen die von vielen Unternehmen und Agile Coaches ignoriert wird: Schlanke Prozesse, Vertrauenskultur, Psychologische Sicherheit, Sinnfindung und Lernbereitschaft sind immens wichtig, in einem IT-Kontext ist aber nichts davon möglich wenn technische Exzellenz und moderne Infrastruktur fehlen.

Montag, 15. Februar 2021

Warum Agilität keine Management-Mode ist

Bild: Pexels / The Lazy Artist - CC0 1.0

Zu den Kuriositäten die einem Agile Coach immer wieder begegnen gehört die erstaunlich weit verbreitete Ansicht, dass die agilen Vorgehensmodelle nur eine Management-Mode wären. Und ähnlich wie vorher bei [hier beliebige andere Methodik einsetzen] wäre es nur eine Frage der Zeit bis sie durch die nächsten Moden abgelöst würden. Nun ja. Kann man so sehen, muss man aber nicht.


Um das Offensichtlichste zu nennen: mit einer mehr als zwanzigjährigen Geschichte seit dem Manifest für agile Softwareentwicklung (und einer nochmal dazukommenden Vorgeschichte) reden wir mittlerweile von mehr als dreissig Jahren ununterbrochen zunehmender Verbreitung und Popularität. Was sich über so lange Zeit hält kann man kaum noch als Mode bezeichnen, eher wäre es angemessen von etablierten und gefestigten Arbeitsweisen zu sprechen.


Und selbst wenn es so sein sollte, dass eine dreissigjährige Phase eine (dann sehr langlebige) Mode darstellt, zu einer Management-Mode würde es dadurch noch lange nicht. Denn selbst wenn Manager aus vielen verschiedenen Bereichen heute gut damit beraten sind sich mit diesem Thema zu beschäftigen - in ihrem Ursprung und in weiten Teilen ihrer Umsetzung haben die agilen Vorgehensmodelle wenig mit den Management-Ebenen zu tun.


Ein Grund dafür ist, dass die agilen Arbeitsweisen initial nicht konzipiert worden sind um Unternehmen zu lenken sondern von Praktikern der unteren Hierarchiestufen entwickelt wurden um die tägliche Arbeit von Umsetzungsteams einfacher zu machen. Als sich daraus dann trotzdem hierarchie- und organisations-übergreifende Ansätze entwickelten war der erste Reflex vieler oberen Ebenen diese "da unten" entstandenen Ideen als unqualifiziert abzulehnen.

 

Zur Verdeutlichung ein Ausschnitt aus dem höchst lesenswerten Artikel For Agile, It's The Best And The Worst Of Times des Wirtschafts-Journalisten Steve Denning (Forbes Magazine):

For instance, in 2014, when I attended the Drucker Forum for the first time, I was met with deep skepticism. Agile might be fine, I was told by the world’s leading management experts, for those unkempt, disrespectful software developers dwelling in the basement, or for tiny startups. But if we had learned one thing about the management through the millennia, from the great armies of Julius Caesar onwards, it was that big organizations - organizations with tens of thousands of people - could only be managed by top-down discipline. Otherwise: chaos.

Laut Dennings Analyse hat es bis ca 2016 gedauert bis sich diese Aussagen geändert haben. Für ihn hat die Agile Bewegung bis zu diesem Zeitpunkt "ein Leben in den Schatten" geführt, das obere Hierarchie-Ebenen trotz bereits erkennbarer Erfolge nur mit einer Mischung aus Amüsiertheit und Abscheu betrachteten.


In dieser Haltung kann man eine narzisstische Kränkung erkennen: dass ein nicht-Manager eine besser funktionierende Methode der Unternehmensführung entwickeln könnte als ein Angehöriger des Managements hätte in den Augen vieler Betroffener deren Position und Selbstverständnis so unterminiert, dass allein schon die Möglichkeit verdrängt und negiert wurde (btw: ironischerweise gibt es ähnliche Vorbehalte gegen agiles Arbeiten mittlerweile auch bei Software-Entwicklern). Und es geht noch weiter.


Ein weiterer sich aus seiner Entstehung herleitender Grund dafür, dass Agile kein von oben vorgegebener Hype sein kann ist dessen tiefe Verwurzelung in flachen Hierarchien und "handwerklichen Prinzipien". Ob es die über Arbeitsprozesse entscheidenden Retrospektiven der Umsetzungsteams sind (an denen Aussenstehende in der Regel nicht teilnehmen dürfen) oder Praktiken wie Pair Programming, Code Reviews oder automatisierte Deployments - Manager sind an vielen Aspekten gar nicht beteiligt.


Aufgrund dieser starken Verankerung "ausserhalb der Management-Reichweite" wird auch die typische Umsetzungsform unmöglich, mit der sonst das jeweils aktuelle Trend-Vorgehen implementiert wird. Massenveranstaltungen mit Tschakka!-Vorträgen und in Wellen durchgeführte Schulungen aller Mitarbeiter kann man zwar auch in agilen Transitionen versuchen, die angestrebten Änderungen an Verhaltensmustern und Umsetzungsdetails erreicht man so aber nur selten.


Um keine Missverständnisse aufkommen zu lassen: das alles heisst nicht, dass das Thema der Agilität für obere Hierarchiestufen unzugänglich wäre. Im Gegenteil, auch dort gewinnt es mehr und mehr Anhänger. Klar ist aber auch - durch ihre "Entstehung im Schatten" und ihre starke Verwurzelung in der Umsetzungsebene ist die Agile Bewegung zu grossen Teilen unterhalb der Management-Ebene angesiedelt, wodurch es per Definition unmöglich ist, dass es sich bei ihr um eine Management-Mode handelt.



Nachtrag:

Um auf mehrfaches Feedback einzugehen: Ich weiss nicht ob ich unklar formuliere, anscheinend ja. Nur weil ich sage, dass Agilität keine Management-Mode ist bedeutet das nicht, dass dieser Ansatz meiner Meinung nach für immer die Welt regieren wird. Das eine hat mit dem anderen wenig zu tun. Siehe auch hier.

Donnerstag, 11. Februar 2021

Agile Manifest Destiny

Bild: Wikimedia Commons / Kallahar - CC BY 3.0

Auf den Tag genau heute vor 20 Jahren machten sich siebzehn Software-Entwickler, Projektmanager und IT-Consultants aus verschiedenen Gegenden Nordamerikas auf den Weg. Ihr gemeinsames Ziel: das Hotel "The Lodge" im Snowbird Ski-Resort in Utah, wo sie eine "Leightweight Methods Conference" durchführen wollten, also eine kleine Konferenz zum Thema leichtgewichtiger (→ möglichst unbürokratischer) Vorgehensmodelle in der Software-Entwicklung.

 

In den nächsten Tagen entstand dort ein Dokument das heute als Grundstein der "agilen Bewegung" gilt, das Manifest für agile Softwareentwicklung, das in vier einfachen Gegensatzpaaren die bis heute anerkannten Grundüberzeugungen dieser Denkrichtung zusammenfasst: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. Die Veranstaltung war damit nicht weniger als der Entstehungsort einer der wichtigsten Urkunden der IT- und Management-Geschichte.


Was die Veranstaltung hingegen nicht war (und hier existiert eine weitverbreitete Falschwahrnehmung) ist der Geburtsort der agilen Bewegung, oder gar des Konzeptes der Agilität selbst. Die existierte schon deutlich früher in vielen verschiedenen Formen. Zum Teil waren diese entwickelt worden durch die Verfasser des Agilen Manifests selbst, die ja nicht aus Zufall nach Snowbird eingeladen worden sind, zum Teil lag ihre Entstehung noch weiter in der Vergangenheit.


Verkürzt zusammengefasst: Wenn man von den Frühformen bei den Römern, Mongolen und Preussen absieht begann die Entwicklung der modernen Agilität in den 80er Jahren, als Pioniere wie Hirotaka Takeuchi, Ikujiro Nonaka und Mary Poppendieck erkannten, dass konsequentes Lean Management nicht nur zu hoher Qualität bei niedrigen Preisen führte, sondern dass damit auch eine bemerkenswerte Flexibilisierung und Beschleunigung der Produktionsprozesse verbunden war. Spätestens ab 1990 wurde versucht das in die IT zu übertragen.


Aufbauend darauf entstanden in den 90er Jahren verschiedene Vorgehensmodelle in der IT, darunter die bis heute bekannten Frameworks Scrum und Extreme Programming, aber auch Lean Software Development, Feature Driven Development, Adaptive Software Development, Crystal und viele mehr. Sie verhalten sich zur Agilität wie frühe impressionistische Bilder zum Impressionismus - sie existierten schon deutlich vorher und wurden nachträglich unter diesem Begriff zusammengefasst, unter dessen Dach dann die Weiterentwicklung stattfand.


Sogar die Auswahl des Tagungsortes Snowbird hatte eine Vorgeschichte - wie man u.a. bei Martin Fowler und Rebecca Wirfs-Brock nachlesen kann fanden hier seit Mitte der 90er Jahre die "Workshops on Object-Oriented Design" statt, an denen bereits mehrere der späteren Verfasser des Agilen Manifests teilnahmen und in denen bereits Themen behandelt wurden die man heute der agilen Anwendungsentwicklung zuordnen würde.


Um nicht falsch verstanden zu werden: all das soll die Leistung der Leightweight Methods Conference von 2001 nicht herabsetzen, erst durch sie hat die Agilität ihren Namen bekommen und ist beschreibbar und popularisiert worden. Es muss aber auch klar sein, dass hier nichts grundlegend Neues erfunden wurde, sondern dass eine Bewegung die lange vorher begann hier ihren vorläufigen Höhepunkt und Durchbruch erreichte. Was danach kam waren im Wesentlichen Konsolidierung und Kommerzialisierung.


Auch deren Abwesenheit macht übrigens einen Teil des Mythos des agilen Manifests aus. Wer sich die Bilder von damals ansieht bekommt schnell den Eindruck, dass der agil-industrielle Komplex 2001 noch in einer unvorstellbar weit entfernten Zukunft lag. Keiner der auf ihnen abgebildeten Männer wirkt als wäre er auf der Jagd nach dem grossen Geld, es sind erkennbar Enthusiasten aus der Umsetzungsebene, die echte Lösungen für echte Probleme suchen. Und vielleicht ist genau dieser Geist eine zentrale Inspiration, die die "Agile Bewegung" zwanzig Jahre später in Erinnerung behalten und selbst beherzigen sollte.


hey guys, found some pics and PDFs of the Agile Manifesto meeting. Pics below. Can't upload the PDFs, so took screen snaps of them to post here. I'll upload to my site later

Gepostet von Alistair Cockburn am Montag, 26. März 2018

Montag, 8. Februar 2021

The Hammer and the Dance

Bilder: Pixabay / Valentin Tixonov / Alpcem - CC0 1.0

Wenn sich Organisationen auf die Reise in Richtung Agilität begeben ist es fast zwangsläufig, dass sie früher oder später mit der Fragestellung konfrontiert werden wie disruptiv dieser Wandel sein soll. Sollen wenige, tiefgreifende Änderungen in kurzer Zeit durchgeführt werden oder machen viele kleine. über längere Zeit gestreckte Anpassungen mehr Sinn?

 

Die auf den ersten Blick unbefriedigende Antwort lautet, dass beides richtig ist, je nach Kontext. Das ist zwar zutreffend, hilft aber nicht wirklich weiter und muss daher konkretisiert werden. Ein Ansatz mit dem man dabei arbeiten kann (einer von vielen, es gibt hier keine absolute Wahrheit) trägt den poetischen Namen "The Hammer and the Dance". Er kann tatsächlich helfen, allerdings bedarf es zuvor einiger kurzer Erläuterungen.


Ein stark disruptiver (revolutionärer) Ansatz besteht aus starken Umwälzungen. Organisatorische und personelle Umstrukturierungen gehören dazu, auch Intensiv-Trainings aller Mitarbeiter oder Verkauf/Abschaffung und Neukauf/Neubau von Anlagen, Systemen und Gebäuden. Der Vorteil an diesem Vorgehen ist, dass in kurzer Zeit viel bewegt werden kann, der Nachteil, dass bei den davon Betroffenen Ängste und Widerstände ausgelöst werden können.


Ein wenig disruptiver (evolutionärer) Ansatz besteht dagegen aus einem behutsamen, schrittweisen, einladungs-basierten Veränderungsprozess, der sich auf kleine und überschaubare (Teil-)Schritte konzentriert und von denen auch nicht zu viele gleichzeitig stattfinden lässt. Die Ergebnisse können die selben sein wie beim stark disruptiven Ansatz, die Ängste und Widerstände sind aber erfahrungsgemäss deutlich geringer. Der Nachteil ist, dass dafür viel Zeit nötig sein kann, was in dringlichen Situationen ein Problem ist.


Der Hammer and Dance-Ansatz versucht Beides zu verbinden. Entwickelt im Jahr 2020 zur Bekämpfung der Covid19-Pandemie geht er davon aus, dass es sinnvoll ist abwechselnde Phasen starker und behutsamer Eingriffe zu haben, die er als "Hammer" und "Tanz" bezeichnet. Welche dieser Vorgehensweisen als nächstes angewandt wird muss dabei von der aktuellen Situation abhängen (mehr zu Hammer and Dance in der Covid19-Bekämpfung hier und hier).


Aus Sicht eines "Agilisten" ist dieses Vorgehensmodell vor allem deshalb naheliegend weil es evidenzbasiert ist. Im ursprünglichen Kontext der Pandemiebekämpfung bedeutet das (vereinfacht gesagt), dass das Überschreiten bestimmter Infektions-Grenzwerte zu starken Eingriffen führt, die dann wieder zu behutsamen Eingriffen zurückgefahren werden wenn die Grenzwerte wieder unterschritten werden und über einen definierten Zeitraum niedrig bleiben.


Um eine Übertragung auf den Kontext einer agilen Transition vorzunehmen müsste damnach in einem ersten Schritt definiert werden welches die relevanten Werte sind die gemessen werden sollen. Das können die klassischen Zahlen aus datengetriebenen Retrospektiven sein, wie Lead Time, Cycle Time, Durchsatz, WIP-Menge oder Bug-Rate, aber auch Devops-Metriken wie Deployment Frequency, Recovery Time, Automation Rate oder System Availability.


In einem zweiten Schritt sollten die jeweiligen Grenzwerte definiert werden. Wichtig ist dabei, dass diese keinen Idealzustand darstellen dürfen. Auch unterhalb der Grenzwerte kann (und und darf) es zu suboptimalen Metriken kommen, allerdings sollte das mit kleinen, dezentralen Massnahmen behebbar sein, etwa mit Training on the Job oder durch allmähliches Refactoring nur der Systemkomponenten an denen gerade ohnehin gearbeitet wird.


In dieser Vorgehenslogik werden am Anfang der meisten agilen Transitionen einige grosse Massnahmen stehen. Wenn sich zwischen den organisatorischen Silos die Arbeit staut müssen diese neu zugeschnitten oder zusammengelegt werden, wenn Systeme ständig ausfallen muss Zeit in ihre Stabilisierung investiert werden, zu viele parallele Arbeit kann durch die Begrenzung gleichzeitig begonnener Projekte und Initiativen zurückgefahren werden, etc.


Sobald durch diese Massnahmen ein Unterschreiten der Grenzwerte stattgefunden hat kann die Verantwortung für das weitere Vorgehen dezentralisiert und auf die unteren Organisationsebenen verlagert werden. Welche der im vorletzten Absatz genannten (oder anderen) Massnahmen dort ergriffen werden sollte in der Verantwortung des jeweiligen Einheit bleiben - bis die Grenzwerte nicht wieder nach oben überschritten werden, dann müssen erneut stärkere Massnahmen erwogen werden.


Neben der Evidenzbasierung hat das Hammer and Dance-Modell noch weitere Aspekte die zu einem agilen Zielbild passen, als wichtigste seien hier die Subsidiarität und das kontinuierliche Inspect & Adapt genannt. Zu den Risiken gehört, dass in den Hammer-Phasen Selbstorganisations-Strukturen beschädigt werden und die Grenzwerte zum Setzen unrealistischer "ambitionierter Ziele" genutzt werden können. Solange die Ziele der Transformation klar formuliert sind kann man daran aber arbeiten


Zuletzt noch eine Frage die vielleicht dem einen oder anderen Leser im Kopf herumschwirrt: ist "The Hammer and the Dance" denn wirklich in irgendeinem Transformationsvorhaben im Einsatz? Die Antwort: ja, ist es. Zwar nicht unter diesem Namen, nicht immer mit der nötigen Klarheit und nicht mit explizitem Bezug auf das 2020 entwickelte Pandemiebekämpfungs-Modell, aber die Art des Vorgehens findet man immer wieder. Vielleicht wäre es Zeit ihm zur besseren Kommunizierbarkeit einen Namen zu geben. Warum nicht diesen?

Freitag, 5. Februar 2021

Die Grundlagen-Dokumente von Scrum (Update 2021)

Bild: Pexels / Suzy Hazelwood - CC0 1.0

Manchmal gibt es diese Momente: kurz nachdem ich im Sommer 2020 die Übersicht über die Grundlagen-Dokumente von Scrum erstellt hatte wurde eine neue Version des Scrum Guide angekündigt und nachdem dieser im November veröffentlich wurde folgten im Januar die neuen Versionen von Nexus und Scrum@Scale. Zeit für ein Update dieser Zusammenstellung. Dabei bin ich auch auf einige Feedbacks eingegangen, auf andere nicht. Mehr dazu ganz unten. Aber jetzt erstmal - auf in die Geschichte. Durch die folgenden Dokumente hat sich Scrum in seine heutige Form entwickelt:


Dieser von von den Wissenschaftlern Takeuchi und Nonaka verfasste Artikel über die Arbeit japanischer Fabrikteams ist das einzige Grundlagenwerk an dem die "Scrum-Väter" Jeff Sutherland und Ken Schwaber nicht beteiligt waren (statt Scrum wird auch noch vom "Rugby Approach" gesprochen). Aus heutiger Sicht beschreibt es noch nicht Scrum selbst sondern einige Prinzipien auf denen es beruht, u.a. crossfunktionale Teams und iterativ-incrementelles Arbeiten. Die 1990 erfolgte Übertragung des New New Product Development Game auf die IT durch DeGrace und Stahl war die Inspiration für die Entwicklung von Scrum in seinem heutigen Sinn, was Sutherland und Schwaber auch selbst betont haben.


Nachdem Sutherland und Schwaber Scrum in den ersten Jahren nur im Rahmen ihrer eigenen Software-Projekte einsetzten führte der Wunsch es bekannter zu machen zur Vorstellung durch die beiden auf der OOPSLA-Konferenz im Jahr 1995. Das Konferenz-Paper gilt als Initialzündung der weltweiten Verbreitung von Scrum, enthält aber vieles noch nicht was heute zentral ist. Umgekehrt sind noch Elemente vom Wasserfall-Vorgehen enthalten, etwa die Phasen "Pregame", "Game" und "Postgame". Anderes, wie der Sprint, das Sprint-Ziel, das Sprint Planning, das Sprint Review oder der Product Owner (noch als Leiter eines Product Management-Teams), existieren bereits. Scrum ist in dieser (und den nächsten) Versionen explizit ein Ansatz der Software-Entwicklung.


Dieses leicht despektierlich "Scrum-Plop" abgekürzte Gemeinschaftswerk einer ganzen Reihe verschiedener Autoren erwähnt zum ersten mal die Rolle des Scrum Masters, wenn auch noch als eine spezifische Form des Teamleiters, dem auch leitende und kontrollierende Funktionen zugeschrieben werden. Besonders interessant: zusätzlich zum Scrum Master wird auch ein (nicht genauer beschriebener) Coach erwähnt, der anscheinend zu dieser Zeit noch eine eigene Rolle war. Auch das 15-minütige Daily Scrum-Meeting taucht hier erstmals auf, genau wie das Commitment des Teams das Sprint-Ziel zu erreichen.


Das erste Buch über Scrum, gleichzeitig aber auch ein Werk das im Rückblick leicht wunderlich wirkt. Statt Scrum als eigenständigen Ansatz vorzustellen stellten Schwaber und Beedle in den Vordergrund, dass ein anderer methodischer Ansatz, Extreme Programming (XP), sich mit Hilfe von Scrum besonders gut umsetzen liesse. Hintergrund ist, dass XP um das Jahr 2000 herum populärer war als Scrum und die Verbindung dieser beiden Ansätze Scrum schneller bekannt machen konnte. Zusätzlich kannten und respektierten sich die Urheber von Scrum und XP (u.a. waren sie 2001 gemeinsam an der Entstehung des agilen Manifests beteiligt). Der halboffizielle Status einiger XP-Elemente in Scrum (User Stories, Story Points, Pair Programming) erklärt sich aus dieser Zeit.


In dieser Übersicht über die Scrum-Einführung in verschiedenen Unternehmen tauchen erstmals Skalierungs-Elemente auf. Zum Einen findet sich hier die Idee, dass auch die Management-Teams nach Scrum arbeiten können, zum Anderen wird hier zum ersten mal das Scrum of Scrums vorgestellt, ein wöchentliches Scrum-Meeting in dem sich Vertreter verschiedener Teams treffen um sich untereinander abzustimmen und die Arbeit an übergreifenden Themen zu koordinieren. Aus diesen Ansätzen entstand später das Skalierungsframework Scrum@Scale (siehe unten).


Im Vergleich zu den anderen Texten ein eher wenig wichtiger, es wird nicht wirklich etwas Neues hinzugefügt. Interessant ist aber, dass Ken Schwaber in ihm einen weiteren Aspekt aus dem Extreme Programming aufgreift: den Team-Raum (angelehnt an den Extreme Space, in dem alle Teammitglieder zusammensitzen). Mittlerweile aus dem offiziellen Teil von Scrum verschwunden ist er noch immer ein wichtiger Teil in vielen Umsetzungen.


Ein weiterer Artikel von Ken Schwaber, der diesesmal aber grössere Änderungen beschreibt. Das Sprint Planning wird unterteilt in Planning I (was machen wir?) und Planning II (wie machen wir es?). Im Daily werden die drei Fragen gestellt was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind. Erstmals findet am Ende des Sprints eine Retrospektive statt, die mittlerweile der zentrale Antrieb für den kontinuierlichen Verbesserungsprozess geworden ist und als das Scrum Meeting schlechthin gilt. Auch die später zum zentralen Abnahme-Kriterium gewordene Definition of Done wird hier erstmals erwähnt, allerdings noch eher beiläufig an verschiedenen Stellen im Fliesstext. Diese zentralen Änderungen tauchen dann auch 2004 in Schwabers Buch Agile Project Management with Scrum auf.


Selbst in der langfristigen Betrachtung ein kurioses Konferenz-Paper, gleichzeitig aber auch ein wichtiges. Der Bericht von Jeff Sutherland und seiner Frau Arline über den Einsatz von Scrum bei der Organisation von verschiedenen Kirchengemeinden ist die erste Primärquelle in der ein Einsatz des Frameworks in einem komplett IT-freien Kontext beschrieben wird. Damit nimmt es die offizielle Herauslösung von Scrum aus der Software-Erstellung um einige Jahre vorweg und bereitet den Weg für Varianten wie Hardware-Scrum, EduScrum, etc.


Ein Dokument das erst rückwirkend zum ersten Scrum Guide erklärt wurde, Sutherland und Schwaber veröffentlichten es zuerst unter dem schlichten Namen "Scrum". Es ist die letzte Version von Scrum in der sich Wasserfall-Elemente finden: zusätzlich zu den Sprint Plannings können langfristige "Release Plannings" durchgeführt werden und es gibt noch die Möglichkeit Integration und Testing in separate Sprints auszulagern. Auch die kontrovers benannten Rollen "Pig" (Teammitglied) und "Chicken" (Stakeholder) tauchen ein letztes mal auf. Der Scrum Master wird als helfender und coachender "Servant Leader" beschrieben, was erst 10 Jahre später zu "True Leader" geändert wurde. Mit der Festlegung, dass mehrere Teams ein gemeinsames Backlog haben können taucht ein weiterer Skalierungs-Aspekt auf.


Die letzten Wasserfall-Elemente verschwinden aus dem Scrum Guide, ausserdem alle spezifischen Bezüge zur Softwareentwicklung, womit Scrum auch offiziell auf andere Bereiche anwendbar wird. Auch die Pig- und Chicken-Rollen verschwinden. Das Grooming wird dagegen zu einem festen Bestandteil und die Rollen werden ausführlicher beschrieben als vorher. Im Wesentlichen entspricht diese Version von Scrum der die bis heute gültig ist, die späteren Änderungen sind kleiner.


Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.


Es werden Neuerungen und Ergänzungen in verschiedenen Bereichen eingeführt: die Teammitglieder sollen sich in den Daily Scrums nicht mehr nur fragen was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind, sondern auch welchen Einfluss das auf das Erreichen des Sprint-Ziels haben wird. Das (in manchen Ländern anstössige) Wort Grooming wird durch Refinement ersetzt. In diesem Zusammenhang wird es auch möglich Backlog-Einträgen den Status Ready zu geben, woraus die inoffizielle Definition of Ready abgeleitet werden kann. Die Teilung des Sprint Plannings in Planning I und Planning II wird aufgehoben, das Was und das Wie können jetzt beliebig erarbeitet werden. Eine kleinere Ergänzung kommt bei den Skalierungs-Aspekten dazu: mehrere Teams können eine gemeinsame Definition of Done haben.


Das erste offizielle Skalierungsframework von Scrum. Grundlage sind die beiden Skalierungs-Aspekte des Scrum Guide, die gemeinsame Definition of Done und das gemeinsame Backlog für Teams die an einem gemeinsamen Produkt arbeiten. Da gleichzeitig vorgegeben ist dass es nur einen Product Owner für ein Backlog geben darf wird daraus abgeleitet, dass der auch für alle derartigen Teams zuständig ist. Weitere Elemente sind die Aufteilung der Scrum-Meetings in jeweils einen übergreifenden und einen teamspezifischen Teil und die zusätzliche Mitgliedschaft von Experten und ausgewählten Teammitgliedern in einem übergreifenden Integration-Scrum Team, dass den anderen Teams dabei hilft sich selbst zu koordinieren. Ein sehr ähnliches, halboffizielles Framework ist Large Scale Scrum (LeSS).


Die "Scrum-Werte" Respekt, Commitment, Fokus, Offenheit und Mut werden in den Scrum Guide aufgenommen. Das ist keine vollständige Neuerung, da sie bereits 2001 im Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle enthalten waren. Ihre Wiedereinführung ist der bisher prominenteste Fall einer Scrum-Regeländerung die auf Wünsche aus der Anwender-Community zurückgeht.


Neben verschiedenen redaktionellen Änderungen gibt es drei grössere: die berühmten drei Fragen im Daily Scrum sind jetzt optional, der Scrum Master bewegt sich mehr Richtung Coach, da er nicht mehr für die Einhaltung der Scrum-Regeln sorgt sondern deren Verständnis fördert, und zuletzt muss in jeden Sprint mindestens eine Massnahme zur Verbesserung der eigenen Arbeitsweisen aufgenommen werden.


Das übergreifende Integration Team ist selbst kein Scrum Team mehr, um konkurrierende Mitgliedschaften zu vermeiden, es funktioniert jetzt eher wie ein um externe Experten erweitertes Scrum of Scrums. Darüber hinaus gibt es redaktionelle Änderungen, unter anderem um klarer herauszustellen, dass der Nexus Guide an den Scrum Guide angelehnt ist und nicht zu ihm in Widerspruch stehen kann.


Eine vergleichsweise kontroverse Neuerung. Anders als der oben erwähnte Nexus-Ansatz geht Scrum@Scale davon aus, dass das eigentliche Scrum Framework nur für einzelne Teams gedacht ist und nicht für grössere Organisationen. Skalierung funktioniert daher in diesem Modell nicht durch die Gruppierung von Teams um Backlogs und Product Owner sondern dadurch, dass es zwar übergeordnete Hierarchie-Ebenen gibt, diese aber aus Delegierten der jeweils nächstunteren Ebene bestehen, die sich auch als Scrum Teams organisieren. Dabei gibt es zwei parallele Hierarchien: die Scrum of Scrums, Scrum of Scrum of Scrums, etc. für die Scrum Master und die gleichartig gestaffelten Meta-Scrums für die Product Owner. Auf diesen höheren Ebenen entstehen auch die neuen Rollen des "Scrum of Scrums Master" und des "Chief Product Owner" (samt deren Steigerungen).


Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.


Je nach Betrachtung eine der umfangreichsten Änderungen überhaupt oder lediglich eine grundlegende redaktionelle Überarbeitung. Die offensichtlichste Neuerung ist die Einführung des Produktziels, an dem sich das Product Backlog ähnlich ausrichtet wie das Sprint Backlog am Sprint Ziel. Das Planning besteht jetzt aus drei Teilen, die den Fragen Warum, Was und Wie entsprechen. Die drei Fragen im Daily Scrum sind völlig verschwunden, ebenfalls die erst in der letzten Version eingeführte Aufnahme von Prozessverbesserungen in das Sprint Backlog. Dass Teams mit gemeinsamem Product Backlog auch einen gemeinsamen Product Owner haben müssen ist jetzt auch explizit beschrieben. Um den Eindruck konkurrierender Mitgliedschaften zu vermeiden gibt es innerhalb des Scrum Teams kein Entwicklungsteam mehr sondern nur noch Entwickler. Durch klarere Formulierung und Strukturierung ist diese Version mehrere Seiten kürzer als die letzte, dazu kommen angepasste Begrifflichkeiten, etwa True Leader statt Servant Leader.


Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt.


Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt. Darüber hinaus gibt es redaktionelle Änderungen und angepasste Begrifflichkeiten, beides mit dem Ziel, dass es genau wie bei der letzten Version des Scrum Guide zu einem geringeren Umfang und klareren Formulierungen kommen soll.


---


Honorable Mentions

Natürlich gibt es noch weitere Quellen die wertvoll für das Verständnis von Scrum sind, vor allem in Buchform. Von Schwaber und Sutherland sind das vor allem die ikonisch benannten Titel Software in 30 Days und The Art of Doing Twice The Work In Half the Time, es gibt Scrum and XP from the Trenches von Henrik Kniberg, Agile Product Management with Scrum von Roman Pichler, die Bücher von Mike Cohn, die Bücher von Craig Larman und Bas Vodde, den EduScrum Guide von Willy Wijnands und viele mehr. Sie alle haben Scrum aber nicht verändert sondern beschreiben lediglich seine Anwendungsmöglichkeiten und vermitteln bewährte Techniken und Praktiken, weshalb sie keine Grundlagen-Dokumente im eigentlichen Sinn sind (lesenswert sind sie natürlich trotzdem).


Zum Feedback zu dieser Seite

Einige Worte zu dem Feedback das ich angenommen oder nicht angenommen habe: neu in der Liste ist Scrum in Church, ausserdem auch die Übersicht über die einzelnen Versionen von Nexus und Scrum@Scale, statt wie bisher nur auf die jeweils neueste Version zu verlinken. Da die jeweiligen Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide inhaltlich zusammenhängen macht das Sinn.

Nicht aufgenommen habe ich dagegen Large Scale Scrum (LeSS), Scrum 3.0 und die Scrum-Varianten aus SAFe und Disciplined Agile (DA). Bei LeSS und Scrum 3.0 weil sie nichts Wesentliches hinzufügen was es nicht bereits von Schwaber und Sutherland gibt, bei SAFe und DA weil sie Scrum so stark beschneiden, dass das Ergebnis mit dem Original nur noch eingeschränkt zu tun hat.

Weiteres Feedback ist jederzeit willkommen, spätestens zusammen mit den nächsten Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide gibt es dann auch von dieser Seite eine neue Version in die es gegebenenfalls eingearbeitet wird.