Freitag, 18. Juni 2021

Der agile Virus

Grafik: Pixabay / Alexandra Koch - CC0 1.0

Eine Metapher die im Umfeld agiler Arbeitsweisen immer wieder benutzt wird ist die des so genannten Virus (z.B. hier, hier und hier). Sicherlich eine nicht ganz unproblematische Begriffswahl, (alleine weil aus ihr nicht sofort hervorgeht, dass sie positiv gemeint ist) auf jeden Fall aber eine die bei näherer Betrachtung einige Eigenheiten agiler Transformationen aufzeigen kann. Welche das sind? Die Folgenden:


Zunächst das Offensichtliche: genau wie der Virus Körperzellen infizieren und umprogrammieren kann, können agile Enthusiasten ihre Teams erstaunlich weitgehend in Richtung neue Arbeitsweisen umwandeln. Zum Teil auf dem offiziellen Weg (z.B. durch die Einführung von Scrum), zum Teil aber auch inoffiziell und zunächst unbemerkt, etwa dadurch, dass zu Beginn nur die Arbeit visualisiert wird oder durch die Etablierung regelmässiger Lessons Learned-Termine. Beides kann Eigendynamiken auslösen.


Eine weitere Eigenschaft von Viren ist es, dass die Zellen in die sie sich begeben haben nicht nur intern anders funktionieren als vorher, sondern dass sie auch neue Viren produzieren, die dann wiederum andere Zellen verändern. Auch hier ist die Analogie offensichtlich. Wer schon einmal in einem agil arbeitenden Team gute Erfahrungen gemacht hat wird wenn er versetzt wird versuchen die hier gelernten Praktiken mitzunehmen und sie auch im neuen Team einzusetzen.


Auch die Reaktionen der jeweiligen Umgebung weisen Parallelen auf. Genau wie das Immunsystem des Körpers versucht erkannte Viren auszuschalten versuchen oft auch die "Immunsysteme von Organisationen" die durch die Agilität entstehenden Veränderungen einzudämmen, zum Beispiel durch Standardisierung, Regulierung oder das Entfernen von als riskant wahrgenommenen Elementen (wie den "zu grossen" Entscheidungsspielräumen der Teams).


Die Reaktion eines Virus auf ein erstarkendes Immunsystem ist schliesslich, dass es durch Mutation so genannte "Fluchtvarianen" ausbildet, die so neu sind, dass sie zunächst nicht erkannt werden. Die Entsprechung in der Welt der Agilität wäre eine Hinwendung agiler Teams zu neuen Frameworks wie Popcorn oder Fast, sobald die bestehenden (meistens Scrum und Kanban) so stark reguliert wurden, dass sie ihren ursprünglichen Zweck nicht mehr erfüllen können.


Wie zu Beginn gesagt, ganz unproblematisch ist die Metapher des agilen Virus nicht, sie hilft aber dabei, agile Transitionsvorhaben aus einem anderen Blickwinkel zu betrachten. Und um zuletzt eine Frage zu beantworten die mir ein Manager tatsächlich einmal gestellt hat: nein, eine wirksame Impfung dagegen gibt es nicht.

Montag, 14. Juni 2021

Ein Bild sagt mehr als 1000 Worte (XXXI)

 Vor mehr als fünf Jahren war das hier der erste Beitrag der Serie Ein Bild sagt mehr als 1000 Worte. Scheinbar ein nicht zu verbessernder Klassiker. Scheinbar. Bis jemand in Wales auf die Idee kam an einer ähnlichen Stelle ein Hinweis-Schild aufzustellen. Und diese neue Variante ... wie die Briten sagen: it keeps on giving. Alle Assoziationen zu bürokratischen Organisationen sind möglich.


Donnerstag, 10. Juni 2021

Warum die Menschen nicht zurück ins Büro wollen

Bild: Wikimedia Commons / Peter Bennet - CC BY 3.0

Wenn grosse Organisationen ihre Angestellten für eine längere Zeit ins Home Office geschickt haben (sei es wegen Pandemien, Bauarbeiten, Überbelegung der Büros oder aus anderen Gründen) kommt es gegen Ende dieser Phasen oft zu interessanten Meinungsbildern. Auf der einen Seite gibt es eine starke Unzufriedenheit mit der Ineffektivität und sozialen Isolation die Heimarbeit mit sich bringt, auf der anderen Seite einen starken Widerwillen gegen die Rückkehr zur durchgehenden Präsenzarbeit.


Warum das so ist dürfte sich zwar von Fall zu Fall unterscheiden, nachdem ich in den letzten 15 Jahren eine ganze Reihe derartiger Fälle erlebt habe, habe ich aber eine These entwickelt: dass viele Menschen mittlerweile eine grosse Skepsis gegenüber der Präsenzarbeit haben liegt stark daran, dass das was sie unter diesem Namen kennengelernt haben in Wirklichkeit etwas ganz anderes ist, nämlich schlecht umgesetzte Remote- oder Hybrid-Arbeit.


Um das zu erklären bedarf es zunächst einer Definition: in der Kreativ- und Wissensarbeit findet Wertschöpfung in der Regel nicht durch einzelne Personen statt sondern durch die Zusammenarbeit in Gruppen oder Teams. Präsenzarbeit muss in diesem Kontext also bedeuten, dass alle Beteiligten gemeinsam vor Ort sind. Sind auch nur Teile des Teams an einem anderen Ort wird die Arbeit aller Beteiligten automatisch zu Remote-Arbeit, da die Abwesenden ja einbezogen werden müssen.


Und auch das muss definiert werden: "an einem anderen Ort" bedeutet eben nicht nur in einem anderen Land, einem anderen Standort oder zu Hause in der Wohnung. Es schliesst alles ein was nicht in Sicht- oder Rufweite (oder zumindest mit wenigen Schritten erreichbar) ist. Als Faustregel in der Wissensarbeit kann gelten: sobald andere Teammitglieder nicht mehr direkt ansprechbar sind sondern angerufen, angemailt oder angechattet werden müssen kann von Präsenzarbeit nicht mehr die Rede sein.


An dieser Stelle wird das Problem vieler grosser Organisationen offensichtlich. In den einen werden Mitarbeiter zu Projektteams zusammengefasst, die weiterhin bei ihren entsendenden Einheiten sitzen. In anderen wurden feste Arbeitsplätze abgeschafft, so dass man sich täglich einen neuen suchen muss - mit der Folge dass es für Teams schwer wird genug nebeneinanderliegende freie Plätze zu finden. Beides hat eine Verteilung der Teams über verschiedene Räume, Stockwerke oder Gebäude-Flügel zur Folge.


Selbst innerhalb eines Gebäudekomplexes führt diese geografische Verteilung dazu, dass mit den Kollegen auf dem gleichen Weg kommuniziert wird wie mit denen in anderen Standorten oder Ländern, also über Calls, Chats oder Mails. Der Vorteil des gemeinsamen Standorts schrumpft darauf zusammen, dass man einfacher Präsenzmeetings organisieren kann - was aber gemeinsame Präsenzarbeit nur zum Teil ersetzt und ausserdem oft an zu wenigen verfügbaren Meetingräumen scheitert.


Soweit zum ersten Teil der These: was für Präsenzarbeit gehalten wird ist in vielen Fällen nichts anderes als Remote-(Zusammen-)Arbeit mit Kollegen die irgendwo verstreut im Gebäudekomplex sizen. Aber es kommt noch ein zweiter Teil dazu, einer dessen Auswirkungen weitgehend unterschätzt werden - es ist nicht nur Remote-Arbeit sondern Remote-Arbeit unter schlechten Bedingungen, was deutliche Auswirkungen auf Effektivität und Ergebnisqualität hat.


Anders als zu Hause, wo man zwar einsam aber ungestört ist, führt das in Grossraum- und Gruppen-Büros stattfindende Zusammensitzen mit den Mitgliedern anderer Teams dazu, dass deren Telefonate und Video Calls mit ihren ebenfalls verstreut sitzende Teammitgliedern einen ständigen Hintergrundlärm erzeugen, gegen den nur noch Schallschutz-Kopfhörer helfen. Da es dadurch unmöglich gemacht wird ansprechbar zu sein verschwindet die direkte Kommunikation fast völlig. Dazu kommt der Stress.


Letztendlich ist es eine Loose-Loose-Situation: um rechtzeitig im Büro sein zu können fallen mit früh Aufstehen und langen Fahrtzeiten die negativen Effekte der Präsenzarbeit an, gleichzeitig bleiben nicht nur deren mögliche Vorteile aus, sondern die zwangsweise auch vor Ort stattfindende de facto-Remote-Arbeit ist sogar stressiger und unkomfortabler als sie es von zu Hause aus wäre. Wer kann es den Menschen verdenken wenn sie nicht zurück ins Büro wollen?


Heisst das also, dass es bei dauerhaftem Arbeiten von zu Hause aus bleiben soll? Auch nicht wirklich, denn hier entstehen andere Probleme. Besser wäre es in der Präsenzarbeit für Bedingungen zu sorgen die dazu führen, dass sie ihren Namen wirklich verdient hat. Und dafür müsste man nicht einmal besonders innovativ sein, man müsste nur das beherzigen was schon vor einem Vierteljahrhundert als gut erkannt wurde. Es wäre höchste Zeit die Büros entsprechend umzubauen, dann kommen die Mitarbeiter auch wieder gerne dorthin.

Montag, 7. Juni 2021

Air Sandwich

Bild: Wikimedia Commons / Matthias Süßen - CC BY-SA 4.0

Zu den Tätigkeiten die ein Agile Coach ausüben kann gehört eine die man als "Auditierung" agil arbeitender Projekte oder Unternehmen bezeichnen könnte. In den meisten derartigen Fällen ist die dahinterstehende Motivation die, dass die Umstellung des Arbeitsmodus nicht zu den Verbesserungen geführt hat die erhofft waren, und dass das Unternehmen herausfinden möchte ob es bei der Umstellung etwas falsch gemacht hat. Und zu den häufigsten Fehlern die dabei gefunden werden gehört das so genannte "Air Sandwich".


Erstmals geprägt von der amerikanischen Strategieberaterin Nilofer Merchant in ihrem 2009 erschienenen Buch The New How: Creating Business Solutions Through Collaborative Strategy beschreibt dieser Begriff einen der klassischen Gründe dafür, dass grosse Veränderungsvorhaben wirkungslos bleiben - das fehlende Herunterbrechen des grossen Plans auf ein Detail- und Abstraktions-Niveau das auf der Ausführungsebene umsetzbar ist. Mit ihren Worten:


An Air Sandwich is a strategy that has clear vision and future direction on the top layer, day-to-day action on the bottom, and virtually nothing in the middle.


Am Beispiel einer nicht gut verlaufenden Umstellung auf agiles Arbeiten würde das so aussehen: in der obersten Unternehmensebene ist grundsätzlich verstanden, dass schnelle Liefer- und Reaktions-Zyklen wichtig sind, und deren Implementierung wird angeordnet. Im Idealfall würde jetzt in der Mitte die Operationalisierung beginnen, zum Beispiel in Form eines Rückbaus von Silos und Hierarchien, so dass auf der unteren Ebene selbstorganisierte, crossfunktionale Produktteams entstehen können.


In der Realität ist es dagegen häufig so, dass die Anordnung schneller und flexibler zu werden in der Mitte auf die dort vorhandene Luftschicht (das Air Sandwich) trifft, ungebremst durch diese hindurchfällt und weiter unten auf der Umsetzungsebene einschlägt. Da in diesem Szenario die Hierarchien und starken Aufgabenteilungen aber nicht verändert worden sind (das hätte in der Mitte passieren müssen) kommt es dort nur zu symbolischen Veränderungen, wie z.B. Scrum in Komponententeams.


Eine populäre Deutung für das Air Sandwich ist, dass die in der Mitte liegenden Management-Schichten kein Interesse haben sich selbst ändern zu müssen, weshalb sie derartige Anweisungen einfach nach unten durchreichen. Sie sagt aber meistens mehr über das Menschenbild des so Urteilenden aus als über die Realität. Eine wahrscheinlichere Erklärung ist aber, dass das Gesamtsystem so konstruiert wurde, dass es durch die Umsetzung organisatorischer Veränderungen an seine Grenzen gebracht wird.


Zur Erklärung: in den meisten klassischen Organisationen ist es eben nicht die Aufgabe der mittleren Schichten Organisationsveränderungen durchzuführen, stattdessen haben sie vor allem eine Kommunikationsfunktion: auf dem Weg von oben nach unten werden Ziele und Anweisungen immer weiter ausdetailliert und auf die verschiedenen Empfänger aufgeteilt, auf dem Weg nach oben werden Rückmeldungen und Ergebnis-Berichte immer weiter zusammengefasst und vereinheitlicht.


Um zu verhindern dass eine Umstellung auf agiles Arbeiten durch ein Air Sandwich wirkungslos wird sind demnach zwei Dinge elementar: zum einen muss allen Beteiligten klar werden, dass in der Mittelschicht nicht nur die Veränderungs-Vision nach unten durchkommuniziert werden muss, sondern dass in diesem Rahmen auch organisatorische Veränderungen geplant und durchgeführt werden müssen. Zum anderen muss klar sein, dass viele klassische Mittelschichten darin weder Expertise noch Erfahrung haben1.


Natürlich sind derartige Überlegungen und Erkenntnisse zunächst einmal frustrierend, da durch sie klar wird, dass Veränderungsbemühungen schwieriger sind als gedacht und meistens eine Unterstützung durch externe Experten benötigen. Auf der anderen Seite bewahren sie aber auch davor, dass als einziges Ergebnis das entsteht was in Air Sandwiches in beliebiger Menge erzeugt werden kann: heisse Luft.


1Es gibt zwar Change Management-Einheiten, aber das ist nochmal ein eigenes Thema.

Freitag, 4. Juni 2021

Lots of systems all over the place

Wer häufiger in der agilen Filterblase unterwegs ist kennt Woody Zuill vor allem als Pionier des Mob Programming und der NoEstimates-Bewegung, in diesem Talk redet er aber über das Management. Genauer gesagt darüber, welche Fehlannahmen, Fehlwahrnehmungen und unhinterfragten Handlungsmuster dazu führen, dass viele Management-Entscheidungen trotz guter Intention keine Verbesserungen zur Folge haben, sondern eher das Gegenteil.



Angesichts des Themas ist es übrigen um so bemerkenswerter welche Art von Präsentation er benutzt, die ist nämlich weit, weit weg von dem was Manager üblich zu sehen bekommen. Aber wer weiss, vielleicht ist gerade das gar nicht so schlecht.

Montag, 31. Mai 2021

Kommentierte Links (LXXV)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Kai Pukall: Kann man Businesswert messen?

Das Thema Business Value, bzw. dessen Bestimmung und Messung ist einer der grossen Klassiker für agile (und nicht-agile) Teams, Produktmanager und Unternehmen. Was Kai Pukall hier zurecht anmerkt ist, dass es sich dabei grösstenteils um Business-Theater handelt. Die Zukunft vorauszusagen (und mit ihr die Gewinne oder Einsparungen die sich mit einem Produkt oder Feature erzielen lassen) ist nicht möglich, aber ganz umsonst ist die Beschäftigung mit dem Thema nicht - es lassen sich so Indikatoren, Wahrscheinlichkeiten und Risiken identifizieren. Aus meiner persönlichen Erfahrung würde ich noch einen weiteren oft unterschätzten Mehrwert von Business Value-Diskussionen einwerfen: sie helfen dabei Anforderungen aus den Backlogs und Roadmaps herauszunehmen die fast keinen Wert haben, aber trotzdem irgendwann eingeplant wurden. Das ist oft schmerzhaft, bringt aber sehr viel.

Neil Rahilly, Casey Winters, Fareed Mosavat, Keya Patel: The art of removing features and products

Apropos herausnehmen. Was hier ein "Autorenkollektiv" aus den Firmen Reforge und Mixpanel zusammengetragen hat ist die umfangreichste Auseinandersetzung mit dem Thema des Ausbauens von Produkt-Features die ich bisher gelesen habe. Angefangen bei den Gründen dafür (Spoiler: es gibt auch gute Gründe für das Entfernen von Features deren Einführung Sinn gemacht hat), über die technischen, menschlichen und wirtschaftlichen Probleme die dabei auftreten können bis hin zu den Erfolgsfaktoren und notwendigen oder hilfreichen organisatorischen Rahmenbedingungen. Ein Text der jedem Product Owner und Produktmanager wärmstens zu empfehlen ist.

Steve Denning: How To Lead Change From Anywhere

Vor allem in grossen Organisationen ist eines der grössten Hindernisse für positive Veränderungen die weit verbreitete Meinung, selbst nicht der Lage zu sein dazu beitragen zu können (→ Untertanenkultur). Dass das nicht so ist wird zwar von Change Managern und Agile Coaches immer wieder betont, wie es vor sich gehen kann wird aber häufig nicht gesagt. Steve Denning stösst in diese Lücke und gibt eine gute Anleitung zum Verändern einer Organisation "von unten". Wie immer muss zwar auch hier klar sein, dass es sich um eine Inspiration handelt und nicht um eine Blaupause, es ist aber auf jeden Fall vieles dabei was sich in fast jedem Kontext anwenden lässt.

Jason Yip: Making the rules explicit becomes more critical shifting from co-located to remote

Das Explizit machen von Regeln ist einer der grossen Klassiker im Rahmen agiler Transitionen und führt immer wieder zu wertvollen Erkenntnissen. Das gilt bereits dann wenn Teams in Co-Location zusammensitzen, es gilt aber nochmal verstärkt im Fall von Remote-Arbeit. Was Jason Yip völlig zu Recht anmerkt ist, dass in diesem Fall die implizite Kommunikation wegfällt, sowohl in Bezug auf das weniger sichtbar werdende Verhalten der anderen Teammitglieder als auch in Bezug auf die abnehmbare Sichtbarkeit der Aktionen von Experten und erfahrenen Kollegen, an denen andere (bewusst oder unbewusst) ihre Handlungen ausgerichtet haben. Yip geht soweit, dass er nicht nur das Explizit Machen von Arbeits- und Entscheidungsprozessen sondern auch von Informationsströmen empfiehlt, um so in Summe alles abzubilden was für die Produktentwicklung relevant ist.

Gojko Adzic: Nijute - how to solve impossible problems

Ich gebe zu, auch ich neige vermutlich manchmal dazu, im Kanban-Umfeld (zu) viele japanische Lehnwörter zu benutzen. Aus diesem Grund fühlte ich mich leicht ertappt als Gojko Adzic mit seinem japanisch klingenden (?) Begriff "Nijute" ein bisschen die Agile-Community trollte, bei dem es sich in Wirklichkeit um die Abkürzung für "Not Impossible, Just Too Expensive" handelt. Unanhängig von diesem Hintergrund kann man ihm nur zustimmen, dass "möglich, aber zu teuer" bei Machbarkeitsdiskussionen ein besseres Argument ist als das häufig benutzte "das geht nicht". Weshalb das so ist und warum hinter dieser Aussage mehr steckt als im ersten Moment zu vermuten kann man schön herausgearbeitet bei ihm nachlesen.

Freitag, 28. Mai 2021

2001 Agile vs 2021 Agile

Grafik: Pixabay / Bytrangle - CC0 1.0

Während der letzten Monate ist Jeff Patton, einer der bekannten Vordenker der agilen Bewegung, in zwei Podcasts zu Gast gewesen die ich zufällig kurz nacheinander gehört habe (nachzuhören hier und hier). Unter seinen vielen anregenden Denkanstössen stach in beiden Auftritten einer heraus: in Pattons Wahrnehmung haben wir heute ein anderes Verständnis von Agilität als die Verfasser des Manifests für agile Softwareentwicklung vor 20 Jahren, denen wir den Begriff immerhin verdanken.


Das ist insofern bemerkenswert, da das agile Manifest eigentlich als zeitlos gültiges Dokument konzipiert wurde und von seinen Verfassern und dem überwiegenden Teil der "agilen Bewegung" auch bis heute noch so gesehen wird. Patton vertritt hier also eine Minderheits-Meinung, wenn auch eine die er gut begründen kann. Und angesichts seiner anerkannten Verdienste und Expertise ist diese Meinung eine nähere Betrachtung wert.


Ein zentraler Unterschied zwischen den Verständnissen von 2001 und von 2021 den er sieht ist die unterschiedliche Bedeutung von Product Discovery, Outcome-Orientierung und Erfolgsmessung. Seiner Auffassung nach spielten diese schon im New New Product Development Game vorhandenen Konzepte auf der legendären "Leightweight Methods Conference" in Snowbird/Utah keine Rolle, während sie heute aus agiler Produktentwicklung nicht mehr wegzudenken sind.


Was er dagegen im agilen Manifest noch sehr stark wahrnimmt ist eine Betonung des Delivery-Aspekts, die er an den Formulierungen "deliver working software frequently" und "working software is the primary measure of progress" festmacht. Die Ursache dafür sieht er in den Berufen der Verfasser des agilen Manifests, bei denen es sich grossteils um externe Berater und Entwickler handelte, deren Beruf weniger aus Produktinnovation und mehr aus der Umsetzung von Kundenaufträgen bestand.


Ein dritter Unterschied liegt für ihn im technischen Fortschritt begründet - 2001 wurde Software noch auf CDs und DVDs verschickt und war nach dem Absenden für die Entwickler nicht mehr erreichbar, diese mussten also möglichst perfektionistisch arbeiten. Abweichend davon machen die heute durchführbaren Updates über das Internet es möglich auch frühe und noch unperfekte Versionen auszuliefern und sie im laufenden Betrieb kontinuierlich zu optimieren und zu erweitern.


Soviel zu Pattons zentralen Punkten, jetzt zur eigentlich interessanten Frage - hat er recht? Die nicht ganz befriedigende Antwort: in gewisser Weise schon, je nach Sichtweise aber auch nicht. Er hat recht damit, dass Product Discovery, Outcome-Orientierung, Erfolgsmessung und Continuous Delivery im Manifest für agile Softwareentwicklung nicht explizit genannt werden. Aber - wenn man es möchte lassen sie sich implizit aus den anderen Punkten ableiten, z.B. Continuous Delivery aus dem "Constant Pace".


Vielleicht ist aber auch gerade das eine Besonderheit dieses Dokuments: obwohl sich die Nutzergewohnheiten, Produktlebenszyklen und technischen Rahmenbedingungen über die letzten 20 Jahre deutlich verändert haben lässt es sich für jeden Zeitpunkt dieser Spanne so interpretieren, dass eine für diesen Moment passende Interpretation von Agilität entsteht. Damit wäre es also doch zeitlos (was Pattons Denkanstösse übrigens nicht weniger wertvoll macht).


Nachtrag:

Zum Thema Agile 2001 vs Agile 2021 passt auch diese Äusserung von Ron Jeffries, einem der Unterzeichner des Manifests:

Dienstag, 25. Mai 2021

Begriffs-Entfrachtung

Bild: Wikimedia Commons / Rohit Choudhary Raj - CC BY-SA 3.0

Zu den grossen Problemen nahezu aller agilen Transformationsvorhaben (und auch vieler Firmen die ihre Arbeitsweisen bereits umgestellt haben) gehört die Unklarheit des Begriffs "Agil". An keiner Stelle (auch nicht im Manifest für agile Software-Entwicklung) wird definiert was genau darunter zu verstehen ist, man kann lediglich versuchen es sich aus dem Kontext herzuleiten - in irgendeiner Form läuft es auf beweglich, schnell und reaktionsfähig heraus, völlig klar wird es aber nicht.


Diese Unklarheit hat mit der Zeit dazu geführt, dass der Begriff mitunter sehr weit ausgelegt und manchmal sogar erweitert wird. Immer wieder werden verschiedene ähnliche, verwandte oder nicht im Widerspruch stehende Konzepte zu (halb)offiziellen Elementen der Agilität erklärt. Das ist in verschiedener Hinsicht problematisch: zum einen wird die Umsetzung unnötig eingeengt, zum anderen liefert es all jenen Munition die nach Gründen suchen um das Konzept ablehnen zu können.


Um die Diskussion und die Umsetzung wieder zurück zu Klarheit, Offenheit und Realismus zu führen kann es nötig sein den Begriff zu "entfrachten" ihn also von allem zu befreien was ihm nachträglich aufgeladen wurde. Das macht sowohl zu Beginn agiler Transitionen Sinn als auch bei Firmen und Teams die schon länger so arbeiten, bei denen sich aber (ggf. unbemerkt) derartige Überfrachtungen eingeschlichen haben.


Vermutlich das häufigste Überfrachtungselement ist die Überzeugung, dass agiles Arbeiten erfordert, "dass jeder alles kann". Abgeleitet von dem Wunsch Crossfunktionalität zu haben und Flaschenhälse zu vermeiden ist die Grundidee Wissen zu verteilen zwar richtig, in diesem Extrem führt sie aber entweder dazu, dass die Betroffenen sich überfordert fühlen oder dazu, dass sie unverhältnismässig viel Zeit für Lernen und Ausprobieren einfordern.


Ein weiteres Element mit dem agile Arbeitsweisen überfrachtet werden ist Basisdemokratie. Vermutlich ausgehend von den hohen Mitbestimmungsrechten der agilen Teams stösst man in vielen Organisationen auf Menschen die der Meinung sind, dass in einem "wirklich agilen" Unternehmen auch über Entscheidungen zu Produktstrategie oder Stellenbesetzungen abgestimmt werden müsste. Aber bei aller Liebe zur Demokratie - um schnell liefer- und reaktionsfähig zu sein braucht man sie nur bedingt.


Oft mit der Forderung nach Demokratie einhergehend kommt als drittes Überfrachtungselement der Konsens-Zwang. Ohne dass klar ist wie diese Idee entstanden ist herrscht in vielen Teams die Überzeugung vor alle Entscheidungen einstimmig treffen zu müssen, mitunter wird auch gefordert das auf grössere Organisationseinheiten zu übertragen. Hier droht sogar das Gegenteil von Agilität - lähmende Dauer-Debatten bis endlich alle zustimmen.


Ebenfalls immer wieder anzutreffen ist die Überzeugung, dass konsequent agil arbeitende Firmen ihren Kunden jeden denkbaren Wunsch erfüllen müssten. So naheliegend das angesichts des hohen Wertes der Kundenorientierung auch klingt, stimmen tut es nicht. Spätestens bei dem (menschlich verständlichen) Kundenwunsch immer die höchste Qualität zum niedrigsten Preis haben zu wollen muss sich die Frage nach der Wirtschaftlichkeit stellen.


Und auch das kann in Extremfällen auftreten: die Überzeugung, dass agile Unternehmen eher gemeinwohl- als gewinnorientiert arbeiten müssten. Man kann die Ursache dafür vermutlich bei den amerikanischen XP- und Scrum-Teams der 90er Jahre finden, die sich ihre Handlungsfreiheit noch gegen das Shareholder Value-getriebene Management erkämpfen mussten, eine daraus abgeleitete grundlegende Ablehnung von Gewinnorientierung ist aber eher anarchistisch als agil.


Die Liste liesse sich noch weiterführen, die Grundproblematik ist aber klar: sobald sich die Überfrachtung des Begriffs "Agil" mit einem oder mehreren der hier genannten Aspekte in den Köpfen festgesetzt hat wird der Versuch so zu arbeiten eher zu Frustration und Unwillen führen als zu Erfolgen. Da dieses Antipattern in vielen Fällen aber unbewusst herbeigeführt wird oder schleichend und unbemerkt entsteht kann man es kaum verhindern. Also was tun?


Ein Lösungsansatz ist es, möglichst früh eine intern geltende "offizielle Definition" des Begriffs zu verfassen, idealerweise eine die sich auf die Kernaspekte der Liefer- und Reaktionsfähigkeit beschränkt und breit kommuniziert wird. Die kann dann regelmässig genutzt werden um sich zu fragen ob sich mittlerweile alte oder neue Überfrachtungselemente eingeschlichen haben, die dann wieder entfernt werden sollten.


Und bevor es zu Missverständnissen kommt: das heisst nicht, dass man diese Ideen nicht nutzen könnte. Wenn eine Organisation z.B. alles im Konsens entscheiden will, nur zu. Sie sollte das nur nicht deshalb tun weil es angeblich zur Agilität gehört.

Samstag, 22. Mai 2021

Customer-Vendor Antipattern (II)

Bild: Pixabay / Suju-Foto - CC0 1.0

Würde man die populärsten Missverständnisse über Scrum sammeln gäbe es eines das ganz sicher weit oben in der "Beliebtheitsskala" auftauchen würde: das, dass sich der Inhalt eines Sprints nicht mehr ändern darf sobald er gestartet wurde. Gerade weil es so verbreitet ist lohnt sich ein näherer Blick. Worum geht es in diesem Missverständnis, wie konnte es zu ihm kommen und überhaupt - was ist eigentlich falsch daran?


Zunächst zur Erläuterung. Im Rahmen eines Sprints, also eines Zeitraumes von ein bis vier Wochen, liefert ein Scrum Team eine bestimmte Menge an Mehrwert ab, z.B. in Form neu programmierter Software-Features. Diese zu liefernden Features werden vor dem Sprint in Anforderungen beschrieben (häufig in Form von User Stories) und in das so genannte Sprint Backlog übernommen, das im Sprint abgearbeitet wird. An dieser Stelle steht dann häufig das Missverständnis: viele Menschen glauben, dass während des Abarbeitens keine Änderungen an diesen Anforderungen mehr stattfinden dürfen.


Wann dieser populäre Irrtum entstanden ist lässt sich zwar nicht mehr genau rekonstruieren, die mit ihm regelmässig mitgelieferten Begründungen lassen aber erahnen wie das geschehen sein dürfte. Von Product Owner-Seite heisst es meistens, dass die Entwickler sich durch Änderungen am Sprint-Inhalt aus den gemachten Zusagen herauswinden könnten, von Entwickler-Seite, das ihnen der Product Owner auf diese Weise zusätzliche Arbeit unterschieben könnte. Beides lässt tief blicken.


Was aus diesen Aussagen erkennbar wird ist, dass sich hier alle Beteiligten im Customer-Vendor Antipattern verfangen haben. Beide betrachten den Sprintumfang als das Ergebnis einer Verhandlung in der sie versucht haben der jeweils anderen das Maximum an Zugeständnissen abzuringen. Der Product Owner hat möglichst viele Anforderungen in den Sprint drücken wollen, die Entwickler dagegen haben deren Menge möglichst gering halten wollen um ohne Zeitdruck arbeiten zu können.


Auch eine ähnliche Variante kommt häufig vor: in ihr ist es nicht der Product Owner der den Entwicklern möglichst hohe Zusagen abringen will sondern es sind ausserhalb des Teams stehende Stakeholder. Der Product Owner befindet sich in dieser Konstellation entweder gemeinsam mit den Entwicklern in einer Abwehrhaltung oder eher befindet sich in einer Zwischenposition in der er es keiner der beiden Seiten recht machen kann.


Die Auswirkungen des Customer-Vendor Antipatterns können weit über das Team hinaus verheerend sein. Latentes Misstrauen im Refinement, erbittertes Feilschen im Planning, ein Gefühl des übervorteilt worden Seins im Review und gegenseitige Vorwürfe in der Retrospektive sind häufig auftretende Folgen dieser gegeneinander gerichteten Positionierung der Teammitglieder, die den Ruf der Beteiligten, der angewandten Methodik aber auch der diese Konflikte zulassenden Firma schwer beschädigen können.


Um es dazu nicht kommen zu lassen ist es dringend anzuraten bereits auf erste Zeichen dieses Antipatterns zu achten und ihnen von Anfang an entgegenzutreten. Das kann innerhalb des Teams durch Retrospektiven geschehen oder ausserhalb dadurch, dass übergriffige Stakeholder in ihre Schranken gewiesen und die Autorität des Product Owners ihnen gegenüber gestärkt wird, es kann aber auch durch Arbeit an den Rahmenbedingungen geschehen.


Die einfachste Art das zu tun führt dabei wieder zurück zum Beginn dieses Textes, denn sie besteht aus der Beseitigung des Missverständnisses, dass der Inhalt eines Sprints sich nicht mehr ändern darf sobald er gestartet wurde. Richtig ist in Scrum nämlich, dass der Sprintinhalt sehr wohl geändert werden kann (siehe hier), lediglich das Sprint-Ziel nicht. Mehr noch: der Sprint-Inhalt muss sogar geändert werden sobald das Sprint-Ziel gefährdet ist, um es zumindest in einer abgespeckten Version erreichen zu können. Und umgekehrt: wenn es früher als gedacht erreicht wird kann Arbeit nachgezogen werden.


Hat ein Scrum Team diese Vorgaben einmal verinnerlicht wird das Customer-Vendor Antipattern von sich aus nach und nach verschwinden, alleine deshalb weil alle mühsam erfeilschten zu grossen oder zu geringen Zusagen wieder ausgeglichen werden sobald klar wird, dass sie an der Realität vorbeigehen. Die Möglichkeit und damit auch der Anreiz den anderen zu übervorteilen entfallen einfach, und als Folge dessen gehen auch die schädlichen Verhaltensweisen zurück.

Montag, 17. Mai 2021

Sprintfähigkeit (wieder)herstellen

Bild: Pexels / Jonathan Borba - CC0 1.0

Auf den ersten Blick sieht Scrum wie eine Arbeitsweise aus auf die man sich einfach umstellen kann, der Scrum Guide scheint schliesslich lediglich den Sprint, die drei Rollen, die vier Meetings und die drei Artefakte vorzugeben. Das scheint sich schnell einführen zu lassen. Auf den zweiten Blick wird es allerdings deutlich schwieriger, denn das dritte der drei Artefakte hat es in sich: das Increment ist eine neue, benutzbare Produktversion, und davon muss es mindestens eine pro Sprint geben.


Wer schon einmal in einem komplexen Produktentwicklungs-Umfeld gearbeitet hat wird erkennen welche Herausforderung das bedeuten kann: die initialen Anforderungen müssen so geklärt sein, dass die Arbeit an ihnen sofort beginnen kann, das Team muss crossfunktional genug sein um nicht auf Zulieferungen warten zu müssen und Tests und Deployments müssen automatisiert sein um möglichst schnell stattfinden zu können.


Die wenigsten Teams die bisher in einem eher klassischen Umfeld mit bürokratischem Anforderungs-Management, starker Arbeitsteilung und vielen manuellen Arbeitsschritten gearbeitet haben werden aus dem Stand dazu in der Lage sein, mit dem Effekt, dass aus einem sofort gestarteten Sprint kein auslieferbares Increment entstehen kann (und aus den nächsten vermutlich auch nicht). Frustration und Enttäuschung wären die Folge.


Um es dazu nicht kommen zu lassen ist es wichtig, dass vor dem ersten Sprint die Grundlagen dafür geschaffen werden ihn überhaupt durchführen zu können. Es wird häufig versucht das in einen so genannten Sprint 0 zu packen, was aber nicht immer funktioniert. Gerade in grösseren Organisationen können Wochen und Monate dafür nötig sein, was den Begriff des Sprints völlig konterkarieren und unbrauchbar machen würde.


Zielführender ist es in solchen Fällen überhaupt erstmal die Sprintfähigkeit herzustellen bevor man mit Scrum beginnt. Das kann ein letztes mal in Form eines klassischen Projekts entstehen, es kann aber auch nach einem anderen mehr oder weniger agilen Vorgehen durchgeführt werden. Wichtig ist in jedem Szenario aber ein klares Zielbild: nur wenn nachvollziehbar definiert ist welche Kriterien für eine Sprintfähigkeit zu erfüllen sind ist klar wann diese Vor-Phase vorbei ist.


Ein Sonderfall dieser Situation tritt ein wenn ein bereits nach Scrum arbeitendes Team seine Sprintfähigkeit verliert, zum Beispiel durch Personalabgänge oder ausfallende Infrastruktur. Der Scrum-Begründer Ken Schwaber empfiehlt in diesem Fall (zumindest bei grösseren Vorhaben) so genannte Scrumble-Phasen, in denen die Sprints ausgesetzt werden und stattdessen an der Wiederherstellung der Sprintfähigkeit gearbeitet wird.


Elementar in beiden Varianten ist, dass in ihnen ein möglichst ausschliesslicher Focus darauf liegt an den Voraussetzungen für Scrum zu arbeiten. Wird parallel dazu bereits mit der Arbeit am Produkt begonnen, werden diese fehlenden Voraussetzungen dazu führen, dass sich nicht integrierte Arbeit anstaut oder Vorarbeiten durchgeführt werden die sich später ggf. nicht abschliessen lassen. Beides würde wieder zu den Problemen führen für deren Beseitigung Scrum eigentlich erfunden wurde, es wäre also nicht im Sinne der Idee.

Freitag, 14. Mai 2021

Scrum goes Pop Music (II)

Als ich vor ein paar Monaten entdeckt habe, dass Chad Beier angefangen hat auf Scrum umgetextete Lieder neu aufzunehmen hatte ich direkt gehofft, dass noch weitere nachkommen. Tatsächlich wurde ich nicht enttäuscht, mittlerweile gibt es drei weitere. Mein persönliches Highlight ist die neue Version von Nirvanas Smells like teen spirit, aber auch die beiden anderen kann man sich gut anhören. Ich bin gespannt wieviele noch kommen werden.




Dienstag, 11. Mai 2021

Der Werkvertrag über agile Produktentwicklung

Bild: Pixabay / Aymenjed - CC0 1.0

Dass ich immer wieder an Phillipp Kühn vorbeikomme wenn es um das Thema Agilität und Verträge geht sagt viel Gutes über ihn aus und zeigt auf, dass er einer der (noch) zu wenigen Experten in diesem Bereich ist. In seinem aktuellen Auftritt im Scrum meistern Podcast greift er einiges von dem auf was er schon letztes Jahr in einem Vortrag in meiner Firma gesagt hat, er geht aber auch auf neue Aspekte ein. Einen davon möchte ich herausgreifen, da er auch mir schon wiederholt begegnet ist - die (falsche) Gleichsetzung von Werkvertrag und Festpreis.


Zur Einordnung: viele grosse Unternehmen versuchen ihre von externen Dienstleistern umgesetzten IT-Projekte über Werkverträge einzukaufen, was grundsätzlich auch Sinn macht. Egal ob es eine Server-Migration ist, ein Website-Relaunch oder die Ablösung eines Legacy-Systems - irgendwo sollte schliesslich geregelt sein was eigentlich die zu erbringende Leistung ist (in welchem Detailgrad das zu erfolgen hat wäre dabei nochmal ein Thema für sich).


Zu einem Problem wird diese Art des Einkaufs dadurch, dass im Verständnis vieler Einkaufsabteilungen ein Werkvertrag automatisch einem Festpreis-Vertrag entsprechen muss, also einer Abmachung bei der für die Werk-Erfüllung nur ein bestimmter Betrag zu bezahlen ist, und zwar unabhängig vom nötigen Umsetzungsaufwand und auch dann wenn dieser Aufwand durch sich ändernde Rahmenbedingungen von der ursprünglichen Schätzung abweicht.


Für den Einkäufer ist diese Art der Abmachung scheinbar vorteilhaft, da sie ihn vor Kostensteigerungen schützt, für den Dienstleister scheinbar mit Nachteilen behaftet, da er im Fall unvorhersehbarer Aufwände (im komplexen IT-Umfeld ein häufiges Phänomen) die höheren Kosten alleine zu tragen hat. In der Realität verlieren häufig beide Seiten, da der Dienstleister höhere Kosten dadurch eindämmt, dass er spart wo der Käufer es nicht sofort sieht: bei Lastfähigkeit, Wartbarkeit, Erweiterbarkeit, etc.


Ein Ausweg aus dieser Loose-Loose-Situation ist die Erkenntnis, dass Werkverträge keineswegs zwangsläufig einen fixen Preis haben müssen. Das einfache Beispiel aus dem oben genannten Podcast: auch eine Badezimmer-Renovierung lässt sich per Werkvertrag beauftragen, der Preis wird aber trotzdem schwanken, abhängig davon welche Schäden während der Bauarbeiten entdeckt und behoben werden. Eine Übertragung dieses Beispiels auf die IT ist problemlos möglich.


Sich auf ein derartiges Vertragsmodell einzulassen fordert allerdings verschiedene Voraussetzungen: die Einsicht des Auftraggebers, dass sich in der IT Aufwände nicht genau vorhersagen lassen, die Bereitschaft beider Vertragspartner vertrauensvoll und ehrlich miteinander umzugehen und primäre Nutzung des Vertrages als Kooperationsvereinbarung und nicht als Sanktionierungs-Werkzeug. Andererseits - ohne all das wird jedes Projekt noch ganz andere Probleme bekommen. Das kommt oft genug vor, aber dann ist die Vertrags-Art bei weitem nicht mehr das grösste Problem.

Donnerstag, 6. Mai 2021

Praxisbeispiel: Lean Management im Impfzentrum

Bild: Unsplash / Mufid Manjun - CC0 1.0

Dass Lean Management keineswegs nur für die Optimierung von Fabriken geeignet ist dürfte sich schon länger herumgesprochen haben, nach einfach nachvollziehbaren Beispielen dafür musste man aber etwas suchen - bis jetzt. Mitten in der Corona-Pandemie ist es gelungen mit diesem Vorgehen eine der Einrichtungen zu optimieren die im Augenblick im absoluten Mittelpunkt des öffentlichen Interesses stehen: ein Impfzentrum.


Eine kurze Rückblende. Bis Mitte April waren alle Berichte über das Impfzentrum des Rhein-Kreises Neuss eher negativ. Lange Warteschlangen und bürokratische Prozesse sorgten für Unwillen unter den Bürgern die sich für ihre Impfung im kalten Wetter anstehen mussten und angesichts der dort aufgestauten Menschenmengen einem erhöhten Ansteckungsrisiko ausgesetzt waren. Das einzig Gute an diesen Missständen: die Notwendigkeit von Verbesserungen wurde durch sie offensichtlich.


An dieser Stelle kam das sprichwörtliche Glück im Unglück ins Spiel. Unter den freiwilligen Helfern befand sich auch der Lean-Experte Andreas Syska, der ab März mit der Optimierung der Abläufe betraut war. Aus seinem ersten Bericht kann man entnehmen welche Praktiken nach und nach eingeführt wurden: Wertstrommapping, Line Balancing, Verschwendungsanalyse, Kreidekreis, Standardisierte Arbeitsprozesse und bessere Visualisierung.


Die Ergebnisse dieser Massnahmen werden jedem bekannt vorkommen der schon einmal mit der Optimierung von Produktions- und Geschäftsprozessen befasst war. Flaschenhälse wurden erweitert, Rückstaus aufgelöst, Laufwege selbsterklärend gestaltet und unnötige oder redundante Abläufe abgeschafft. Bereits Ende April gehörte das Impfzentrum dadurch zu den effektivsten in Deutschland. Einen kleinen Einblick gibt dieses Video:



Überhaupt scheint das Impfzentrum des Rhein-Kreises für Innovationen grundsätzlich sehr aufgeschlossen zu sein. So gehörte es zu den ersten die es impfwilligen Personen ermöglichten per SMS über Impfstoff-Restposten informiert zu werden um sich selbst als Nachrücker anzubieten. Letztendlich nichts anderes als eine Kombination aus Digitalisierung und Pull-Prinzip. Und für noch mehr Beschleunigung sind mobile Impfteams unterwegs.


Das Beispiel aus Neuss zeigt sehr gut zu welchen Effektivitätssprüngen selbst öffentliche Einrichtungen in der Lage sind wenn sie sich auf moderne Management-Methoden einlassen. Und neben den geimpften Bürgern profitieren auch die deutschen Agile- und Lean-Coaches, die jetzt über ein weiteres plakatives Beispiel verfügen um die Vorteile ihrer Ansätze für jeden nachvollziehbar zu erklären.


Nachtrag 10.06.:

Auch in Japan gibt es vergleichbare Initiativen. Wenig überraschend.

Montag, 3. Mai 2021

Das Remote-Produktivitäts-Paradox

Startup Stock Photos/Eric Bailey - CC0 1.0

Was die Auswirkungen von vermehrter oder sogar vollständiger Heimarbeit auf die Produktivität eines Unternehmens sind ist ein umstrittenes Thema. Bedingt durch die Vielzahl der verschiedenen einwirkenden Faktoren ist es schwer möglich zu sagen welche Effekte auf den Arbeitsort zurückgehen und welche auf begleitende Umstände wie z.B. die Corona-Pandemie 2020/2021. Praktisch alle Studien sind daher mit Vorsicht zu lesen.


Was wissenschaftliche Untersuchungen auch in diesem Umfeld können ist aber das Aufzeigen von Auffälligkeiten und scheinbaren Inkonsistenzen in den gesammelten Daten, die die Ausgangslage für weitere Nachforschungen bilden können. Ein aktueller derartiger Fall ist eine Metastudie der Deutschen Bank, deren Verfasser auf etwas gestossen sind das sie das "Produktivitäts-Paradox" nennen - obwohl sich die Angestellten im Home Office produktiv fühlen geht aus der Sicht ihrer Firmen die Produktivität im Vergleich zur Präsenzarbeit zurück.


Die Ursache für diese Diskrepanz dürfte erst mit weiteren Studien zu erklären sein, bis diese verfügbar sind lassen sich aber zumindest anhand anekdotischer Evidenz erklärende Hypothesen formulieren. Eine die ich aufgrund der Erfahrungen in mehreren Firmen für vielversprechend halte ist dabei diese: die unterschiedliche Wahrnehmung der Heimarbeits-Produktivität durch Angestelle und Firmen geht stark darauf zurück, dass die beiden Gruppen ein unterschiedliches Verständnis davon haben was Produktivität überhaupt ist.


Aus Angestellten-Perspektive wird Produktivität häufig gleichgesetzt mit der Menge an Zeit die für die Arbeit zur Verfügung steht. Da das Wegfallen der Abeitswege zum und im Büro (und umgekehrt die kurzen Wege in der eigenen Wohnung) dazu führen, dass mehr Zeit am Schreibtisch verbracht wird, kann sich das produktiver anfühlen. Verstärkt wird dieses dadurch, dass keine Kollegen im Raum sitzen von denen man von Aufgaben abgelenkt wird. Man hat nicht nur mehr Zeit, man erledigt auch mehr.


Auf der anderen Seite ist aus Firmensicht wichtiger, dass in der zur Verfügung stehenden Arbeitszeit nicht nur Aufgaben erledigt werden sondern auch ein Ergebnis erzielt wird. Dass die Angestellten ausreichend Zeit zum Arbeiten haben und viele Aufträge erledigen ist zwar wichtig, wenn dabei aber keine (oder zu wenige) Produkte erzeugt oder Geschäftsprozesse erledigt werden geht das am Ziel vorbei. Produktivität entspricht in dieser Perspektive dem effektiven Einsatz von Zeit und Mitteln.


Wie diese abweichenden Verständnisse in der Realität entstehen können zeigt eine weitere Studie aus dem Jahr 2020: in 50 untersuchten IT-Teams führte die in der Corona-Pandemie eingeführte Heimarbeit dazu, dass zwar mehr Code geschrieben wurde (die Entwickler schafften es also viele Aufgaben zu erledigen), gleichzeitig war dieser aber in gesteigertem Ausmass fehlerhaft oder am Bedarf vorbei entwickelt (aus Firmensicht wurden also Zeit und Mittel ineffektiv genutzt).


Was die Verfasser als Ursache ausmachten würde auch ich aus meiner Erfahrung bestätigen: gerade das was aus individueller Perspektive als produktiver empfunden werden kann (vereinfacht gesagt: mehr Zeit alleine vor dem Computer) führt aus systemischer Perspektive dazu, dass die Produktivität zurückgeht, da informeller oder impliziter Informationsaustausch, spontane Reviews, Pair Programming und ähnliche effektivitätsfördernde Praktiken zurückgehen und nur schwer wieder zu etablieren sind.


Wie oben gesagt, verlässliche Daten gibt es noch nicht, sowohl die Studien als auch meine Erfahrungen sind eher Indikatoren als fertige Erkenntnisse. Zumindest sind sie aber ein erster Erklär-Ansatz für das Remote-Produktivitäts-Paradox, also dafür dass sich manche Menschen im Homeoffice produktiver fühlen als sie sind.

Freitag, 30. April 2021

Kommentierte Links (LXXIV)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Shawn Carolan: A Path to the Minimum Viable Product

Steve Blank ist nicht irgendwer. Zusammen mit Eric Ries ist er einer der beiden Vordenker der Lean Startup-Bewegung, in der unter anderem das Konzept des Minimum Viable Product (MVP) entwickelt wurde. Wenn er es also einem anderen erlaubt auf seiner Website einen Artikel zu diesem Thema zu veröffentlichen kann man davon ausgehen, dass er lesenswert ist. Dieser Andere ist in diesem Fall Shawn Carolan, und sein Thema ist der so genannte "MVP-Tree", ein Entscheidungsbaum mit dessen Hilfe man bestimmen kann welches das richtige MVP ist das man bauen sollte. Wie alle "Standard-Rezepte" ist auch dieses mit Vorsicht zu geniessen, eine wertvolle Inspiration ist es aber auf jeden Fall.

Ron Ashkenas, Larry Hirschhorn, Thomas Giernalczyk: A Fair Way to Lead a Team of Contractors and Full-Time Employees

So schön die Theorie auch sein mag - manchmal kommt man nicht darum herum die Realität zur Kenntnis zu nehmen. Ein Aspekt bei dem das immer wieder vorkommt ist die in agilen Teams eigentlich vorgesehene Gleichbehandlung aller Teammitglieder, ungeachtet ihres Hintergrunds. Ron Ashkenas, Larry Hirschhorn und Thomas Giernalczyk merken völlig zu Recht an, dass das nur eingeschränkt funktionieren kann wenn ein Team sowohl aus internen als auch aus externen Mitarbeitern zusammengesetzt ist und arbeiten heraus welche unterschiedlichen Rahmenbedingungen und Motivationsfaktoren für diese Gruppen gelten.

Karin Bauer: Warum agile Coaches auf Widerstand stoßen

Man muss dich die Journalisten als gequälte Menschen vorstellen. Drei Jahrzehnte voller digitaler Disruption, sich wandelndem Medienkonsum, Redaktionszusammenlegungen und Entlassungswellen haben dazu geführt, dass die meisten von ihnen nach und nach zu Akkord-Textern degradiert worden sind. Dass das zu einem gesellschaftlichen Problem werden kann zeigt dieser Artikel, dem man ansieht, dass bei ihm weder für gründliche Recherche noch für Faktencheck und Redigieren Zeit und Geld vorhanden waren. Dass der relativ neue Beruf des Agile Coaches mitunter so dubios wahrgenommen (und ausgeübt) wird liegt auch an diesen Hintergründen: es gibt in den ausgezehrten Redaktionen kaum noch Kapazitäten um ihn angemessen zu erforschen und darzustellen.

GeePawHill: On Agile Methods

Die zentrale These dieses Artikels von GeePaw Hill lautet: "Keine der gängigen 'Agilen' Methoden kann hoch-performante Entwicklungsteams hervorbringen." Selbst wenn man dem nicht in dieser Absolutheit folgt, die Gründe die er dafür anführt verdienen es sorgfältig durchdacht zu werden.
  1. Teamübergreifende Standardisierungen sorgen dafür, dass individuelle Bedürfnisse einzelner Teams nicht mehr erfüllt werden können.
  2. Die Fixierung auf Prozesse sorgt dafür, dass das Arbeiten an den eigentlich wichtigeren Arbeitsbeziehungen in den Hintergrund tritt.
  3. Die unterschiedlichen Interessen von Kunden, Firmen und Mitarbeitern werden im Zweifel zugunsten des methodisch vorgegebenen Ziels vernachlässigt.
  4. Alle Methoden beschreiben einen Idealzustand der in der Realität nur schwer erreichbar ist.
  5. Für die Erfinder und Vertreter der Methoden ist es wichtiger mit ihnen Geld zu verdienen als anderen zu helfen.
Wie gesagt, man muss dem nicht in allem zustimmen, aber wer bereits Umsetzungen irgendwelcher agiler Frameworks erlebt hat wird einiges wiedererkennen. Und dass der Autor durchaus mit ein paar steilen Thesen provozieren will merkt man daran, dass unter den von ihm genannten Methoden auch eine ist als deren Fan er sich normalerweise bekennt: Extreme Programming.

J. Meadows: Epistemic Failure in Software Engineering

Wie häufiger bei den kommentierten Links steckt hinter dem letzten der längste Text, angeteasert von der kürzesten Beschreibung. Ein kurzer Spoiler: hier wird der Bezug zwischen Softwareentwicklung und Erkenntnisstheorie hergestellt. Und die Schlüssel zum Erfolg sind bayesscher Wahrscheinlichkeits-Begriff, Agilität und Demut.

Dienstag, 27. April 2021

Ein neues agiles Framework: FAST Guide veröffentlicht

Bild: Pixabay / Mahmur Marganti - CC0 1.0

Es ist schon eine Zeit lang her, dass zum letzten mal ein erwähnenswertes agiles Framework erfunden wurde. Es gab zwar Versuche, die waren aber entweder nur rudimentär entwickelt (z.B. POPCORN-Flow oder FLEAT) oder lediglich Variationen bereits bestehender Frameworks (z.B. Scrum 3.0 von Scrum oder TameFlow von Kanban). Dieses hier scheint in dieser Hinsicht besser zu sein: FAST (Fluid Agile Scaling Technology), erstmals veröffentlicht im März 2021 in Form des FAST Guide. Ob es erfolgreich sein wird muss sich noch zeigen, es ist aber ausdifferenziert genug um besprochen zu werden.


Wichtig ist zunächst, dass FAST sich selbst als Zusammenfassung und Weiterentwicklung bestehender Ansätze versteht, mit dem expliziten Anspruch Scrum abzulösen. Ron Quartel, der Schöpfer des Frameworks, nennt in dessen "Origin Story" die Hauptquellen Open Space Technology und Open Allocation/Dynamic Reteaming, im FAST-Guide kommen dazu noch Dunbar-Zahl/Tribe,  Ken Schwabers Überlegungen zu Post-Scrum und Verweise auf Conway, McGregor, Lewin, Pink und andere Vordenker. Aus all diesem Input entstehen die folgenden Elemente:


Tribes und (dynamische) Teams

Die  nach FAST arbeitenden Menschen bilden einen so genannten Tribe, der zunächst bis zu 14 Mitglieder haben kann (zu grösseren Einheiten siehe unten). Der Tribe ist in beliebig viele Teams unterteilt, die sich mit jeder Iteration (siehe nächster Absatz) selbstorganisiert in der für den Moment jeweils sinnvollsten Konstellation zusammenfinden. Das kann bedeuten, dass auf diese Art Feature-Teams zustande kommen, aber auch Komponenten-Teams oder Mischtypen sind möglich. Auch ein selbstorganisierter Neu-Zuschnitt der Teams während der Iteration geht, wenn es Bedarf dafür gibt.


Iterationen und FAST Meetings

Dass es Iterationen gibt ist auf den ersten Blick eine Gemeinsamkeit mit Scrum, ungewöhnlich ist aber die kurze Dauer und die sich oft ändernde Länge: empfohlen werden zu Beginn zwei Tage, anzustreben ist der kürzeste mögliche Zeitraum. Auch die Meeting-Struktur ist minimalistisch - es gibt lediglich ein Meeting, das zwischen zwei Iterationen stattfindet und ohne vorbereitete Agenda als Open Space durchgeführt wird. Alle Planungs-, Verbesserungs- und Teambuilding-Aktivitäten sollen selbstorganisiert in diesem Termin zur Diskussion gestellt, beschlossen und eingeleitet werden.


Vier Rollen

Angesichts des bisher zu erkennenden Minimalismus ist erstaunlich, dass es bei den Rollen sogar eine mehr gibt als in Scrum. Ein Product Director stellt im FAST-Meeting seine Vision für die nächste Iteration vor, aus der der Tribe selbstorganisiert seine Arbeit ableitet, ein pro Iteration gewählter Team- oder Feature Steward übernimmt in dieser Zeit die Koordination eines Themas, ein Tribe Coach hilft dabei zu verstehen wie die Methodik gemeint ist. Alle anderen Personen gelten einfach als Tribe Member, von denen jeder an mehreren Themengebieten arbeiten können sollte.


Vier Artefakte

Drei der vier Artefakte bilden mit möglichst geringem Detailgrad den Work Breakdown ab. Release Map (gross), Feature Tree (mittel), Iteration Board (klein, als einziges Artefakt optional). Das vierte bilden die so genannten Tribe Agreements, die aber nicht etwa bestimmte Beschlüsse und Regeln enthalten, sondern lediglich beschreiben wie diese möglichst unbürokratisch zu Stande kommen. Alle vier Artefakte können und sollen regelmässig selbstorganisiert geändert werden, ohne dass im Detail festgelegt ist wann das stattzufinden hat. Hauptsache Verbesserungen finden statt, egal wie.


Skalierung

Der Anspruch von FAST ist, dass es ohne zusätzliches Skalierungsframework funktioniert, bzw. sein eigenes Skalierungsframework ist. Tribes können dazu bis zur Dunbar-Zahl von 150 Mitgliedern anwachsen ohne dass zusätzliche Rollen und Meetings benötigt werden, lediglich das FAST-Meeting wird umfangreicher. Erst oberhalb der Dunbar-Zahl muss der Tribe in mehrere geteilt werden. Alternativ können FAST-Tribes in Skalierungsframeworks wie SAFe oder Flight Level-Kanban eingebettet werden, solange diese die internen Abläufe nicht verändern.


Aber: Ist das wirklich umsetzbar?

Ja, aber. Wie oben gesagt muss man sich FAST als ein Framework vorstellen das für Teams geeignet ist die Scrum gemeistert haben und jetzt einen Schritt auf die nächste Stufe machen wollen. Das bedeutet, dass sie Produkte haben die sich durch kleine, in wenigen Tagen umsetzbare Incremente erweitern lassen. Das bedeutet, dass sie die technische Exzellenz haben die für tägliche Produktionsdeployments nötig ist. Das bedeutet, das ihre Firma ihnen alle nötigen Freiheiten gibt. Und das bedeutet, dass ihre Mitglieder nah am Ideal des Fullstack-Developers sind, der nahezu jede nötige Arbeit erledigen kann.


Um ehrlich zu sein - nur wenige Teams dürften jemals den Entwicklungsgrad erreichen der für FAST nötig ist, nicht zuletzt weil nicht alle notwendigen Rahmenbedingungen selbst beeinflussbar sind. Aber vielleicht ist das auch gar nicht immer nötig - alleine der Versuch sich in diese Richtung zu entwickeln dürfte derartig viele positive Veränderungen bewirken, dass es den Aufwand bereits wert ist. FAST wäre damit weniger ein organisatorischer Rahmen und mehr ein guter Grund um ständig an Verbesserungen zu arbeiten. Aus "agiler Sicht" bereits mehr als ausreichend.

Donnerstag, 22. April 2021

Cost of Change, Coupling and Cohesion

Woran man erkennen kann, dass Kent Beck ein guter Konferenz-Speaker ist? Zum Beispiel daran, dass er die ersten vierzehn Minuten dieses Auftritts hier nur dafür verwendet einleitende Worte zu finden, Spannung aufzubauen und Scherze zu machen, ohne dass das langweilig wird. Man kann direkt zum Zeitpunkt 14:00 springen und in den eigentlichen Inhalt einsteigen, man kann sich aber auch den gesammten ersten Teil ansehen und sich gut unterhalten lassen.



Und bevor der falsche Eindruck aufkommt - nicht nur wegen der Art der Präsentation sondern auch wegen des Themas lohnt sich das Video. Es geht darum warum Betrieb und Erweiterung von Software häufig so teuer sind und was man tun kann um dem entgegenzuwirken.

Montag, 19. April 2021

Die Autonomie-Falle

Bild: Flickr / Royalty Free - CC BY 2.0

In der Theorie ist es ganz einfach: das Management erkennt, dass es für Flaschenhälse und Stille Post-Effekte sorgt wenn es alles zentral entscheiden will, also delegiert es Kompetenzen auf die niedrigeren Hierarchieebenen. Dort können die Mitarbeiter jetzt selbst Entscheidungen treffen ohne für alles nach Erlaubnis zu fragen und auf die Genehmigung warten zu müssen. Beschwingt wird in die neue Arbeitswelt gestartet - und zu oft ist eine Bruchlandung die Folge.


Dass es häufig zu diesen Bruchlandungen kommt hat Gründe. Wer in seiner Karriere noch keine wichtigeren Projekt- oder Produktmanagement-Entscheidungen treffen musste wird häufig nicht das Wissen über alle dazugehörigen Aspekte haben und darum wichtige vergessen und unwichtigen zu viel Aufmerksamkeit geben. Der amerikanische Wirtschaftswissenschaftler Claus W Langfred hat das schon 2008 unter dem Namen der "Autonomie-Falle" in einer Studie beschrieben, später ist dieser Begriff vom ebenfalls amerikanischen Informatik-Professor Cal Newport weitergedacht worden.


Langfred und Newport beschreiben vor allem zwei Aspekte. Zum einen durch welche System-Defizite es überhaupt dazu kommt, dass niemand die Delegation von Verantwortung mit einer Weiterqualifizierung der Mitarbeiter verbindet (überspitzt zusammengefasste Antwort: weil zuwenig mitgedacht wird), zum anderen was die Folgen davon sind (nochmal überspitzt: es entsteht ein hyperaktives Schwarm-Bewusstsein, das ständig irrelevante Arbeit erzeugt). Mindestens genauso interessant ist aber eine andere Frage - welches Wissen hätte eigentlich zusammen mit der Delegation vermittelt werden müssen?


Als erstes dürfte hier das Kontextwissen zu nennen sein. In welchem Umfeld sind die Entscheidungen zu treffen für die man auf einmal zuständig ist? Zu welchen anderen Organisationseinheiten bestehen Abhängigkeiten und wer ist dort jeweils der Ansprechpartner an den man sich zuerst wenden sollte? Bereits bei Personen auf der gleichen Hierarchie-Ebene ist in dieser Hinsicht schon viel zu beachten, noch komplizierter wird es wenn andere Hierarchiestufen beteiligt sind. Die Frage wo Selbstorganisation aufhört und wo man weiter eine Genehmigung braucht ist hier von elementarer Bedeutung.


Ein weiterer Punkt ist das technische Wissen. Ist das was zur Entscheidung ansteht überhaupt mit den vorhandenen Systemen umsetzbar oder müssten die umkonfiguriert oder sogar umgebaut werden? Und wenn das zweite der Fall ist - wer könnte (und darf) das machen? Wer benutzt diese Systeme sonst noch und sollte daher in die Entscheidung einbezogen werden, welche Architekturparadigmen sind zu beachten, gibt es bereits Pläne für eine Ablösung oder Weiterentwicklung und was sind erfahrungsgemäss die Teile die besonders kompliziert oder instabil sind?


Auch Wissen um die Prozesse gehört dazu. In welchem Kommunikations-Kanal, mit welchen Informationen und mit welchen Fristen müssen Informationen verschickt und Änderungen angekündigt werden, welche Gesetze und Vorschriften sind relevant und was muss wie dokumentiert werden? Auch die inoffiziellen Prozesse sind wichtig. Wer hat beim jeweiligen Thema Interesse und Einfluss, wer könnte ein Unterstützer sein und wer gilt eher als Quertreiber? Wer das nicht weiss wird sich mitunter an unerwarteten Stellen schwertun.


Genug der Problembeschreibung, wie kann die Befreiung aus der Autonomiefalle gelingen? Schulungen sind verbreitet aber meistens ineffektiv, Peer Groups sind hilfreich, stehen aber oft vor dem selben Problem. Coaching durch die bisherigen Entscheidungsträger könnte die beste Lösung sein, oft sind diese aber mit dem Konzept nicht vertraut (nochmal eine spezielle Ausprägung der Autonomiefalle: viele Manager haben wenig Erfahrung damit Anderen zu helfen ohne die Entscheidung an sich zu ziehen).


Eine mögliche Lösung kommt aus David Marquets Buch Turn the Ship Around. In einem (z.B. wöchentlichen) Regeltermin kann man dem bisherigen Entscheidungsträger erzählen was man vorhat (ich möchte Folgendes erreichen) und wie man es angehen will (dazu plane ich Folgendes zu tun). Der kann dann auf mögliche Probleme hinweisen und Erfahrungswerte weitergeben, ohne dass er die Entscheidung übernimmt oder genehmigt. Mit der Zeit kann dieser Termin dann immer seltener werden, so dass man dadurch nach und nach aus der Autonomiefalle herausgeführt wird.

Donnerstag, 15. April 2021

Selbstwirksamkeitserwartung und Kontrollüberzeugung

Bild: Pexels / Fauxels - CC0 1.0

"Die Gelegenheit beim Schopfe packen", Hilf Dir selbst, dann hilft Dir Gott", "Jeder ist seines eigenen Glückes Schmied" - die deutsche Sprache ist voll von derartigen Sprichwörtern, die alle einen ähnlichen Inhalt haben: wer bei einem Problem oder einer Aufgabe anpackt statt zu zaudern wird fast immer die besseren Ergebnisse erzielen. Dass darin viel Wahrheit steckt dürfte auch ohne wissenschaftlichen Beweis offensichtlich sein, wer etwas tut bewirkt im Zweifel mehr als jemand der nichts tut. Es bleibt dann aber die Frage - wie kommt es dann, dass oft nichts getan wird?


Eine Wissenschaft die sich mit dieser Frage schon lange beschäftigt ist die Psychologie. Vor allem in den 60er und 70er Jahren sind hier verschiedene Erklärungsansätze entstanden, die versuchen die Gründe für die Aktivität oder Inaktivität von Menschen nachzuvollzieren. Um zwei davon soll es heute gehen, es sind Selbstwirksamkeitserwartung und Kontrollüberzeugung. Sie überschneiden sich in weiten Teilen, so dass es Sinn macht sie gemeinsam zu betrachten.


Die Selbstwirksamkeitserwartung (im englischen Original Self-Efficacy) wurde in den 70er Jahren vom kanadischen Psychologen Albert Bandura entwickelt. Vereinfacht gesagt handelt es sich bei ihr um das Ausmass der Zuversicht mit dem man einer anstehenden Aufgabe oder einem auftretenden Problem entgegenblickt. Bei hoher Zuversicht ist man überzeugt, dass Aufgabe oder Problem erfolgreich bewältigt werden können, bei niedriger Zuversicht geht man eher davon aus, dass man scheitern wird.


Je nachdem wie hoch die Selbstwirksamkeitserwartung ist können die folgenden Aktionen sich stark unterscheiden. Ist die Erwartung hoch wird ohne grosses Zögern die Tat ergriffen, ist sie moderat erfolgt ein Abwarten und Abwägen, ist sie niedrig macht man entweder gar nichts (Resignation) oder sucht nach Wegen um Aufgabe, bzw. Problem zu umgehen, in die Zukunft zu verschieben oder delegieren zu können (Ausweichverhalten).


Die Kontrollüberzeugung (im englischen Original Locus of Control) geht auf den amerikanischen Psychologen Julian B. Rotter zurück, der den Begriff in den 60er Jahren einführte. Sie beschreibt in wiefern Probleme und Aufgaben überhaupt als selbst bewältigbar angesehen werden. Glaubt man daran selbst dazu in der Lage zu sein spricht man von einer internen Kontrollüberzeugung, glaubt man, dass nur jemand anders (oder mehrere andere) das können von einer externen Kontrollüberzeugung.


Von der Selbstwirksamkeit unterscheidet sich dieses Konzept folgendermassen: bei der Kontrollüberzeugung geht es darum ob man es überhaupt für möglich hält ohne externe Hilfe eine Veränderung herbeizuführen, bei der Selbstwirksamkeit steht im Mittelpunkt ob man es sich selbst zutraut eine theoretisch mögliche Veränderung auch tatsächlich umzusetzen. Beides sind subjektive Annahmen, die erste wird aber oft für objektiv gehalten.


Um diese Theorie mit der Praxis in Verbindung zu bringen: wenn eine Organisation es sich um Ziel gesetzt hat mit möglichst selbstorganisierten, sich selbst weiterentwickelnden und Intrapreneur-artig handelnden Teams Produkte zu entwickeln, dann kann das letztendlich nur dann gehen wenn Selbstwirksamkeitserwartung und interne Kontrollüberzeugung der Teammitglieder möglichst hoch sind. Sind sie das nicht werden sie zu oft auf externe Unterstützung warten statt selbst initiativ zu werden.


Aus dieser Erkenntnis können verschiedene Massnahmen abgeleitet werden um für die passende Zusammenstellung von Teams zu sorgen. Häufig aber meistens nicht zielführend sind Assessment Center, in denen die Teammitglieder auf die "richtige" Geisteshaltung überprüft werden. Durch kognitive Verzerrungen wie Observer-Expectancy Effects, Selection Biases oder Attribute Substitutions sind deren Ergebnisse kaum aussagekräftig und im Zweifel falsch.


Zielführender ist es sich die zugrundeliegenden psychologischen Mechanismen zu Nutze zu machen. Während niedrige Selbstwirksamkeitserwartung und externe Kontrollüberzeugung häufig durch Machtlosigkeits- oder Misserfolgs-Erfahrungen entstehen können häufige Erfolgserlebnisse das (positive) Gegenteil bewirken und zu hoher Selbstwirksamkeitserwartung und interner Kontrollüberzeugung führen.


An dieser Stelle kommen schliesslich Ansätze aus dem Lean-Agile-Bereich ins Spiel. Da diese durch Praktiken wie Pull Prinzip, regelmässige Refinements und kurze Planungszyklen vergleichsweise realistische und machbare Planungen hervorbringen können sie durch zahlreiche Erfolgserlebnisse eine Eigendynamik entwickeln die dafür sorgt, dass die für diese Art des Arbeitens notwendigen Selbst- und Systemwahrnehmungen von sich aus entstehen und verstärkt werden.

Montag, 12. April 2021

The agile Bookshelf: Mutual Aid - A Factor of Evolution

Bild: Wikimedia Commons / Nadar - Public Domain

Er dürfte eine der ungewöhnlichsten Biografien der letzten Jahrhunderte haben. Geboren wurde Pjotr Kropotkin in eine russische Adelsfamilie, er wurde Page des Zaren, Offizier an der chinesischen Grenze, Natur- und Geografieforscher in Sibirien, Anarchist, politischer Gefangener, Gefängnisausbrecher, Journalist in der Schweiz, Schriftsteller in England, Menschen- und Bürgerrechtsaktivist. Und aus diesem ungewöhnlichen Leben entstand ein ungewöhnliches Buch.


Gegenseitige Hilfe in der Tier- und Menschenwelt wurde von ihm 1902 in England veröffentlicht und später in verschiedene Sprachen übersetzt. Es stellt nicht weniger dar als den Versuch nachzuweisen, dass nicht etwa Konkurrenz und Wettbewerb sondern Kooperation und gegenseitige Unterstützung die Grundprinzipien sind an denen sich sowohl die Natur als auch die meisten menschlichen Gesellschaften ausrichten. Sowohl das Über- als auch das Zusammenleben von Menschen und Tieren basiert in dieser Sicht auf gegenseitiger Hilfe.


Man kann Kropotkins Buch vor allem als Gegenschrift zu den Werken zweier berühmter Engländer sehen, Charles Darwin und Thomas Hobbes. Anders als Darwin, der als erster die Evolution beschrieben hatte, ging Kropotkin davon aus, dass nicht in erster Linie die stärksten oder am besten angepassten Tierarten die erfolgreichsten sind (→ Survival of the Fittest) sondern vor allem die deren Angehörige sich am effektivsten bei Nahrungssuche, Selbstverteidigung und Aufzucht des Nachwuchses unterstützen.


Auf die menschlichen Gesellschaften bezogen vertrat Kropotkin eine Gegenposition zu Hobbes. Dieser war davon ausgegangen, dass die Menschen im Naturzustand ständig miteinander um Ressourcen und Macht kämpfen würden (→ der Krieg aller gegen alle), was Kropotkin mit zahlreichen Beispielen aus verschiedenen Gesellschaften widerlegte, darunter Eingeborenenstämmen in Asien und Afrika, antiken Reichen und Völkern, mittelalterlichen Städten und modernen Kommunen und Genossenschaften.


Für die Gegenwart anwendbar wird sein Werk dadurch, dass sich die ihm widersprechenden Gegenthesen bis heute gehalten haben. Auch ohne die Urheberschaft durch Darwin und Hobbes zu kennen oder zu nennen wird immer wieder mit ihren Standpunkten argumentiert wenn begründet werden soll warum ein selbstorganisiertes oder weitgehend hierarchiefreies Arbeiten in Konkurrenzkämpfe oder Chaos führen würde wenn man es zuliesse.


Das mit einem Verweis auf einen vor langer Zeit verstorbenen russischen Fürsten bestreiten zu wollen dürfte zwar nur wenig zielführend sein, was man aber machen kann ist seine zahlreichen Beispiele aufgreifen um zu zeigen, dass Selbstorganisation und Gruppenentscheidungen schon seit Menschengedenken gut funktionieren, gewissermassen also Good Practices sind.


---


Und übrigens: wer jetzt neugierig geworden ist kann sich das Buch hier im englischen Original herunterladen. Mehr als 100 Jahre nach Kropotkins Tod ist die Schutzfrist vorbei und sein Werk frei verfügbar. Einfach auf die nächste Zeile klicken.

Mutual Aid: A Factor of Evolution, by Knjaz Pjotr Alexejewitsch Kropotkin

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.