Agile Compliance

Bild: Wikimedia Commons / Creig Pat - CC BY-SA 4.0

Wenn die Vorteile von agilen Vorgehensweisen genannt werden liegt in der überwiegenden Mehrzahl der Fälle der Schwerpunkt auf der IT, die so zu bedarfsgerechteren Produkten und schnelleren Releases kommt. Auch Betrieb (Stichwort DevOps) und andere Organisationseinheiten entdecken diese Welt mittlerweile für sich und sehen in Agilität ein anzustrebendes Zielbild. Es gibt aber auch einen weiteren Berech in dem dieser Ansatz Sinn macht, selbst wenn man ihn dort zunächst nicht vermuten würde - Compliance.

Zum besseren Verständnis muss man sich vor Augen halten was dieser Begriff bedeutet. Compliance ist in der Theorie eine Umschreibung für die Einhaltung von Gesetzen und Richtlinien während der Berufsausübung. In der Realität haben sich Compliance-Tätigkeiten allerdings in Teilen von dieser Bedeutung gelöst und auf die damit verbundene Bürokratie ausgedehnt - in fast allen auch nur halbwegs grossen Organisationen bedeutet Compliance heute, dass die eigene Arbeit möglichst lückenlos dokumentiert wird, um bei Bedarf nachzuweisen zu können, dass man sich wirklich an alle Vorschriften gehalten hat¹.

Im klassischen wasserfall-artigen Vorgehen führt das am Ende eines Geschäftsjahres oder einer Projektphase zu hektischen Aktivitäten. Nicht nur muss rückwirkend dokumentiert werden, gegebenenfalls muss zuerst durch Reverse Engineering ermittelt werden was überhaupt der zu dokumentierende aktuelle Stand ist. Und im schlimmsten Fall weicht der Ist-Stand so stark von den Vorschriften ab, dass er überarbeitet werden muss. So kann klassische Compliance dazu beitragen, dass sich "fast fertige" Projekte noch erstaunlich lange ziehen.

Ein agiler Ansatz würde dieses Risiko minimieren indem die notwendigen Dokumentationen parallel zur Produktentwicklung fertiggestellt werden, idealerweise im Team selbst, möglicherweise aber auch durch unterstützende Spezialistenteams. Das bedeutet zwar, dass Juristen, Datenschutz-Beauftragte, Penetrationstester und Security-Spezialisten durchgehend verfügbar sein müssen, im Gegenzug ist der Zustand des "potentially shippable" damit durchgehend gewährleistet und nicht nur punktuell. Und die Nacharbeits-Aufwände am Ende fallen weg.

Ein in diesem Kontext sinnvolles Vorgehen wäre übrigens ein Aufbrechen von Wissensmonopolen, z.B. durch den Transfer von Security- oder Datenschutz-Know-How in die Umsetzungsteams. Auch das trägt bei zu schneller Reaktionszeit, da nicht mehr auf den Experten gewartet werden muss.


¹Das einfach wegzulassen ist zwar naheliegend, wegen der Überprüfung durch Regulierungs- und Aufsichtsbehörden aber oft nicht machbar.

Customer-Vendor Antipattern

Vielleicht hat Jeff Patton Pech mit seinen Bekanntschaften aus dem agilen Umfeld. Vielleicht ist seine Aussage, dass die ausschliesslich auf die Velocity fixiert wären, nur ein rhetorischer Trick um sich als Schwimmer gegen den Strom zu inszenieren. So oder so - sein Vortrag geht auf einige wichtige Punkte ein, und sein Illustrations-Stil ist etwas Besonderes.

Jeff Patton at MTP Engage Hamburg 2018 from Mind the Product on Vimeo.

Jenga-getriebene Retrospektiven

Bild: Flickr / RJP - CC BY 2.0

Wenn Teams sich entscheiden nach Kanban zu arbeiten statt nach Scrum fällt vieles weg, was von manchen Menschen als einengend empfunden werden kann, unter anderem die Fixierung auf Sprints von ein bis vier Wochen. Was damit allerdings auch verloren geht ist der automatisch stattfindende Feedback- und Verbesserungszyklus, der durch die am Ende jedes Sprints stattfindende Retrospektive angetrieben und am Laufen gehalten wird.

Nun ist es nicht so, dass es in Kanban keine Retrospektiven gäbe. Sie heissen zum Teil anders (z.B. Kaizen Session, Schulterblick oder KVP-Meeting), aber sie sind da, ohne sie wäre das "manage the flow" nicht möglich. Anders als in Scrum bleibt aber die Frage wann sie stattfinden sollen. "Immer wenn es nötig ist" ist zwar grundsätzlich ein guter Ansatz, bei ihm drohen sie aber vom Alltagsbetrieb verdrängt zu werden. Und feste Intervalle gehen wieder in Richtung Scrum, was oft nicht (mehr) gewünscht ist.

Ein interessanter Ansatz kommt von einem kölner Gamification-Guru und basiert auf einem Jenga-Spiel. Die Grundidee: wie beim normalen Jenga werden nach und nach die Steine aus dem Turm herausgezogen, und sobald er umfällt ist eine Retrospektive fällig. Das Team muss jetzt nur noch vereinbaren wann jeweils ein Stein gezogen wird. Mögliche Anlässe sind:

• Ein Stein für jeden Tag seit der letzten Retrospektive
• Ein Stein für jede Aufgabe die in die Expedite-Lane geschoben wird
• Ein Stein für jede Überschreitung der WIP-Limits
• Ein Stein sobald ein vereinbartes WIP-Age überschritten wird
• etc.

Bei diesem Vorgehen würde es spätestens ca alle sechs Wochen zu einer Retro kommen, alleine wegen der Regel, dass ein Stein pro Tag gezogen wird. Je nach vereinbarten weiteren Regeln kann es aber auch deutlich schneller so weit sein, das Vorgehen ist also stark anlassgetrieben. Und zuletzt können Retrospektiven auch spontan angesetzt werden - man muss dafür nur den Turm umwerfen.

Nicht-Newtonsche Organisationsformen

Bild: Pixabay / Moho01 - CC0 1.0

Wie würde eine ideale Organisationsform eines agilen Unternehmens aussehen? Eine Frage die noch schwieriger zu beantworten ist als es zunächst den Anschein hat. Selbst wenn es klar ist, dass das Erscheinungsbild anders sein muss als in den starren, bürokratischen Strukturen der Gegenwart - fast alle Scrum Master, Agile Coaches und Unternehmensberater bleiben die Antwort auf die sich darauf anschliessende Frage schuldig: Wie dann?

Die naheliegendste Erwiederung ist die klassische, unbefriedigende Beraterantwort: es kommt immer darauf an. Grundsätzlich ist das auch richtig, nur durch die Orientierung an den im Einzelfall gegebenen Herausforderungen kann eine Organisation reaktionsfähig und somit agil bleiben. Das Problem ist die damit einhergehende Gefahr der Beliebigkeit und Planlosigkeit, die dazu führen kann, dass dauerhaft oder zeitweise in die falsche Richtung gelaufen wird. Ähnlich wie im Fall der Produktentwicklung gilt auch in der Organisationsentwicklung, dass es ein Zielbild oder eine Vision geben sollte der man folgen kann. Die wird durch ein "Kommt darauf an" nicht geliefert.

Auch die nächsthäufige Idee ist nicht ganz befriedigend: die "fluide Organisation". Dabei ist auch dieser Ansatz gut. Genau wie eine Flüssigkeit bewegt sich eine solche fluide Organisation nicht auf dem direktesten Weg Richtung Ziel (→ Zielbild/Vision) sondern auf dem Weg des geringsten Wiederstandes. Hindernisse werden nicht bekämpft sondern umflossen, und bei einer Verlagerung des Widerstandes verlagert sich auch der Fluss. Das Problem an dieser Stelle: manchmal muss man auch im agilen Kontext standhaft sein, etwa um zu Überregulierung oder Überspezifikation Nein zu sagen. Dafür sind fluide Organisation nicht gemacht.

Letztendlich bräuchte es eine Kombination der drei Typen: fluide wenn es möglich ist, mit stabileren, wiederstandsfähigeren Strukturen wenn es nötig ist und das Ganze ständig wechselnd, je nachdem was gerade Sinn macht. Eine Inspiration dafür wie das aussehen könnte liefert ein physikalisches Phänomen: die nicht-newtonschen Flüssigkeiten. Grundsätzlich verhalten diese sich wie jede andere Flüssigkeit auch und fliessen entlang des geringsten Widerstandes. Aber: wenn sie unter Druck gesetzt werden verfestigen sie sich, und zwar um so stärker je heftiger der Druck ist. Erst wenn der nachlässt verflüssigen sie sich wieder. Ein konkretes und verblüffend bekanntes Beispiel dafür kann man sich hier ansehen.

In die Realität umsetzbar ist eine derartige nicht-newtonsche Organisationsform allerdings nur wenn ihre Mitglieder erhebliches Commitment und einen hohen Reflektionsgrad haben. Sobald angefangen wird auf die Organisation Druck auszuüben müssen sie das erkennen und sich zum Widerstand zusammenschliessen, sobald der Druck nachlässt müssen sie die dafür erschaffenen Regeln und Strukturen zurückbauen und auflösen. Das immer wieder zu tun ohne irgendwann zu sehr in eine Richtung zu kippen ist eine Herausforderung.

Der Punkt ist aber auch, dass man eine nicht-newtonsche Organisation eher als ein anzustrebendes Fernziel sehen muss und nicht als den nächsten umzusetzenden Schritt. Wie oben gesagt: als Zielbild oder Vision. Selbst wenn diese vermutlich nie zu hundert Prozent erreichbar ist - sie gibt der Organisationsentwicklung die Möglichkeit zu überprüfen ob der eingeschlagene Weg noch der richtige ist oder ob er korrigiert werden sollte. Allein das ist schon viel wert.

Agile is not a mindset

Bild: Pexels / Rawpixel - CC0 1.0

Eigentlich ist es nach dieser Überschrift bereits vorbei. Wie kann er es wagen? Häresie, Frevel, Proselytismus. Er hat Jehova gesagt! In der agilen Community ist es mittlerweile ein Allgemeinplatz, dass Agilität ein Mindset ist, eine Geisteshaltung und eben kein Regelwerk und keine Methode. Basta! Naja. Dem zweiten Teil dieser Aussage würde ich sogar zustimmen, Agilität ist tatsächlich keine durch Regeln definierte Methodik. Dem ersten Teil widerspreche ich aber, ein Mindset ist es auch nicht. Eine bestimmte Geisteshaltung ist zwar eine Voraussetzung, alleine für sich genommen bewirkt diese aber noch gar nichts.

Schauen wir uns das Ganze näher an. Das Wort "agil" hat eine Bedeutung: beweglich oder reaktionsschnell. Ohne Kontext ist das noch sehr unspezifisch. Bin ich bereits agil wenn ich in der Lage bin bei Bedarf meine Meinung schnell zu ändern? Wohl kaum. Es braucht also Zusatzparameter. Für den Kontext von XP, Scrum & Co wurden diese im legendären Manifesto for Agile Software Development geliefert, und zwar anders als man bei erstmaligem Lesen denken könnte nicht nur mit Schwerpunkt auf geistiger Haltung sondern auch mit einem klaren Fokus auf zu erzielenden Ergebnissen.

Vor den berühmten vier Gegensatzpaaren steht auf seiner ersten Seite der Satz: "We are uncovering better ways of developing software by doing it and helping others do it." und genau das ist der Punkt - im Sinn seiner Urheber definiert sich Agilität durch das Liefern von Ergebnissen (Software) und durch das ständige Verbessern dieses Lieferungsprozesses. Auf der zweiten Seite wird das sogar noch genauer ausgeführt: ... early and continuous delivery ..., ... changing requirements, even late in development ..., ... working software is the primary measure of progress ..., und so weiter. Wer mag kann es dort nachlesen.

Warum diese Betonung des Delivery-Aspekts wichtig ist erkennt man an einem in vielen Organisationen zu hörenden Spruch: "Wir sind ja agil, sind offen für geänderte Anforderungen, machen Retros, hinterfragen Regeln, etc - aber wegen der gesetzlichen Vorschriften / wegen unserer Vorgesetzten / wegen unserer veralteten Anwendungen releasen wir nur zweimal pro Jahr." Das Mindset wird an dieser Stelle zu einem Teil einer Selbsttäuschung, die man so formulieren könnte: "Dass wir nur alle paar Monate neue Funktionen zum Anwender bringen ist zwar schade, es hindert uns aber nicht daran Agil zu sein, denn wir haben ja die richtige Geisteshaltung."

Um dieser Selbsttäuschung vorzubeugen rate ich mittlerweile dazu, den Satz Agile is a mindset nicht mehr zu verwenden. In meiner Sicht der Dinge ist Agilität die Fähigkeit sich schnell und unbürokratisch an sich ändernde Rahmenbedingungen anzupassen um kontinuierlich Mehrwert liefern zu können. Wie oben gesagt, ein bestimmtes Mindset ist dafür eine von mehreren Voraussetzungen. Nicht weniger, aber auch nicht mehr. Und wenn die genannte Anpassungs- und Lieferfähigkeit nicht da ist, dann ist man nicht agil, egal wie offen und flexibel die Geisteshaltung ist.

Darum: Agile is not a mindset.

Kommentierte Links (XXXVIII)

• Steve Denning: Ten Agile Axioms That Make Managers Anxious

  Ein Artikel der anscheinend in der Eile des inspirierten Moments geschrieben wurde. Da die Nummer 7 zweimal vorkommt sind es 11 Axiome und nicht 10, Henrik Kniberg wird zu Henrik Nyberg und auch noch weitere Kleinigkeiten ziehen sich durch den Text. Trotz dieser kleinen Fehler ist er bemerkenswert in seinen Aussagen;
  
  First Law Of Agile: The Law Of The Customer
  1. Firms Make More Money By Not Focusing On Making Money
  2. There Are No Internal Customers
  3. There Are No B2B Organizations
  4. Making Better Products May Not Make More Money
  The Second Law Of Agile: The Law Of The Small Teams
  5. Forget Economies of Scale: Your Market Is One Person
  6. Don’t Scale Up: Descale Complexity Down
  7. Control Is Enhanced By Letting Go Of Control
  7. Agile Is A Mindset, Not A Process
  8. Talent Drives Strategy, Not Vice Versa
  The Third Law Of Agile: The Law Of The Network
  9. The Top-Down Organizational Pyramid Is Finished
  10. Lead Like A Gardener, Not A Commander
  
  Kontrovers und Kontra-Intuitiv. Das alles nachzuerzählen würde zu weit führen, daher der Ratschlag: oben auf den Link klicken und selber lesen.
  

• Zeit: Deadlines halten uns von wichtigeren Aufgaben ab

Eine Weiterführung der Debatte um Push-Prinzip und Pull-Prinzip. Das Setzen von Deadlines ist eine der klarsten Formen von Push und wird im agilen Kontext daher nach Möglichkeit abgelehnt. Meng Zhu unterfüttert das mit wissenschaftlichen Erkenntnissen. Zeitdruck erzeugt falsche Prioritäten, senkt Produktivität, führt zu Defocussierung und zum Aufschieben wichtiger aber nicht zeitkritischer Aufgaben. Das Ganze nicht etwa im anekdotischen Einzelfall sondern im Durchschnitt einer statistisch validen Testgruppe. Das sollte eigentlich eine gute Grundlage sein um gegen "aktivierende" und "fordernde" Fristen zu argumentieren.

• FAZ: In Kalifornien kommt der Burger vom Roboter

  Über die kalifornischen Burger-Roboter hatte ich schonmal etwas geschrieben. Mittlerweile scheint man die Probleme dort in den Griff zu bekommen, mit bemerkenswerten Folgen: das Personal wird entlastet und bekommt geldwerte Leistungen und Zeit für persönliche Entwicklung und Weiterbildung. An dieser Stelle wiederholt sich die Geschichte: bereits vor über hundert Jahren führte die Einführung des Fliessbandes zu ähnlichen Effekten. Es kommt also gerade zu einer weiteren Verschiebungswelle, weg von körperlicher Akkordarbeit, hin zu besser angesehenen und weniger aufreibenden Tätigkeiten. Mit allen Folgen die das für die gesellschaftliche Entwicklung hat
  

• Jean-Pierre Lambert: Scrum Master vs. Agile Coach - same in theory, what about practice?

  Es gibt in agilen Kreisen einen sarkastischen Witz: "Was ist der Unterschied zwischen einem Scrum Master und einem Agile Coach?" "Ein um 500 € höherer Tagessatz." Jean-Pierre Lambert geht dem näher auf den Grund. Wie er richtig schreibt sollte es zwischen den beiden Rollen eigentlich keinen Unterschied geben, weder in den Tätigkeiten noch in der Entlohnung. Und doch ist er da. Woran sich in der Berufswelt Scrum Master und Agile Coach unterscheiden zeigt er an vielen Aspekten auf. Und das nicht mit ideologischem Blick sondern einfach die Realität beschreibend.

• Mike Cohn: Six Guidelines for Saying No to a Stakeholder

  Zu den Allgemeinplätzen in Ausbildung und Coaching von Product Ownern gehört, dass sie in der Lage sein müssen Nein zu sagen. Wie das in der Realität aussehen soll und wie dabei Verärgerung und Konflikte vermieden werden können wird dagegen zu selten erklärt. Mike Cohn macht sich die Mühe und holt das nach.

Deine Muda: Transportation

Bild: Pixabay / Skitterphoto - CC0 1.0

Vor wenigen Tagen hatte ich die Ehre auf der Inhouse-Konferenz eines Kunden einen Vortrag halten zu dürfen. Das Thema waren die Mudas (無駄), also die nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System. Bei der Vorbereitung bin ich vor allem an einer Muda hängengeblieben, der Transportation, bzw. dem Transport.

Kurz zum Hintergrund: solange Güter von A nach B transportiert werden, können sie nicht weitergegeben oder weiterverarbeitet werden, sie bilden also totes Kapital. Zusätzlich dazu verbraucht der Transportvorgang weitere Ressourcen, von der Arbeitszeit des Fahrers über das verbrannte Benzin bis hin zum Verschleiss des Fahrzeugs. Aus diesen Gründen gilt Transport als Muda.

Der irritierende Punkt - in vielen Firmen in denen ich gearbeitet habe sind Transporte noch ein Alltagsphänomen, und das obwohl es sich fast ausschliesslich um Branchen der IT- und Wissensarbeit handelt, in denen die Digitalisierung eigentlich dafür gesorgt haben müsste, dass alles zentral abgelegt oder per Mausklick um den Globus geschickt werden kann. Allein - oft ist dem nicht so. Überall wird noch Papier befördert.

Zwar seltener werdend aber noch immer zu finden sind die Laufmappen in denen die Hauspost Briefe und Formulare durch die Gegend fährt, häufig anzutreffen sind Lieferungen gedruckter (und schnell veraltender) Anleitungen, Anforderungen und Dokumentationen sowie Prospekte, Kataloge und Mitarbeiterzeitschriften. Einige besonders skurrile Sonderfälle bilden die Transporte digitaler Datenträger, etwa von Disketten und CDs.

Das all das auch gegenwärtig noch stattfindet lässt sich in der Regel mit zwei Ursachen erklären. Zum einen hängen gerade ältere Mitarbeiter noch an der haptischen Erfahrung von Papier und fordern diese immer wieder ein, zum anderen wird die Digitalisierung von Prozessen oft nicht mehr vorangetrieben, sei es weil man sie für abgeschlossen hält oder sei es weil gerade andere Vorhaben wichtiger sind.

Selbst wenn man es kaum glauben mag - auch heute sind in der IT- und Wissensarbeit die fehlende Digitalisierung und der damit verbundene Transportaufwand grosse Probleme. Diese anzugehen bietet noch immer ein grosses Potential für mehr Effektivität und weniger Transportation-Muda.

Das Ergebnis von 60 Jahren kontinuierlicher Optimierung

... kann man hier sehen. Von mehr als einer Minute verkürzt sich der Vorgang des Reifenwechselns in der Formel 1 auf nur noch wenige Sekunden:



Hinter dieser Verbesserung stecken verschiedene Faktoren: geänderte Teamzusammensetzung, geänderte Abläufe und neue Technologie, angetrieben von einem hochgradig kompetitiven Umfeld. Die Parallelen zur IT sind offensichtlich.