Zertifizierungs-Overkill

Bild: Pixabay / Assy - CC0 1.0

Die Scrum Alliance hat in dieser Woche etwas missverständlich kommuniziert. Ihr neues Mitglied in ihrem "2020 Board of Directors" kündigte sie per Mail mit den folgenden Worten an: "Hello, Community. We’re very proud to officially announce our 2020 Board of Directors. The membership of Scrum Alliance elected Karim Harbott as the new Scrum Certified Member on the Board. Here is an excerpt from Karim’s candidacy page: ..."

Ob dieser "Scrum Certified Member on the Board" ein selbstironischer Bezug darauf war, dass die Scrum Alliance in der Öffentlichkeit im Wesentlichen als Zertifizierungs-Vergabestelle wahrgenommen wird, oder eine missverständliche Umschreibung für einen Verteter der Scrum-Zertifikats-Inhaber - man weiss es nicht. Der Effekt war aber der: an Kaffetheken, in Twitterfeeds und Diskussionsgruppen rund um die Welt fragten sich verunsicherte Alliance-Mitglieder ob sie möglicherweise die Einführung der neuesten Management-Zertifizierung verpasst hätten.

Dass das überhaupt als ernstzunehmende Option in Betracht gezogen wurde hat einen Grund: seit einigen Jahren unterliegen die "Agilen Zertifizierungen" einer erstaunlichen Vermehrung. Neben die Scrum Alliance, die u.A. mit dem Certified Scrum Master die älteste Zertifizierung vergibt, ist mit der vom "Scrum-Vater" Ken Schwaber ins Leben gerufenen Scrum.org und ihrem Professional Scrum Master (und anderen) ein erster Wettbewerber getreten, der zweite Scrum-Gründer Jeff Sutherland ist mit dem Licensed Scrum Master seiner Firma Scrum Inc nachgezogen. Und noch reden wir nur über Scrum.

Mit der Lean Kanban University und ihrem Kanban Management Professional hat auch das zweite grosse agile Framework eine Zertifizierung, dazu kommen noch weitere, spezifischere Ausprägungen. Das International Requirements Engineering Board hat das Re@Agile-Zertifikat im Angebot, das International Software Testing Qualifications Board bietet die Agile Tester Extension. Natürlich ist auch irgendwie ein DevOps Institute entstanden, bei dem man zum Certified Agile Service Manager werden kann. Und jede dieser Organisationen bietet noch weitere Zertifizierungen, die hier sind nur Beispiele.

Auch das ist noch nicht alles. Seit die klassische, Top Down-getriebene Management-Bewegung reduzierte agile Ansätze auf den unteren Hierarchie-Ebenen zulässt wird auch hier zertifiziert. Beim Project Management Institute wird man Agile Certified Practitioner, Prince2 hat die Agile Practitioner Certification und die International Project Management Association vergibt die Agile Leadership Certification. Auch das Scaled Agile Framework mit seinen SAFe-Zertifikaten gehört in diese Kategorie.

Noch immer nicht genug? Kein Problem, die Zertifizierungen gehen bei den verschiedenen Anbietern noch weiter in die Breite und in die Tiefe. In der Breite stehen neben dem zertifizierten Scrum Master auch zertifizierte Product Owner, Entwickler und UX-Spezialisten, in der Tiefe findet eine Staffelung statt: Professional Scrum Master II, Professional Scrum Master III, Certified Agile Leader, Enterprise Kanban Coach und DevOps Leader zieren zweifellos jeden Lebenslauf und künden von teuer erkauften Kursen und gekonnt bestandenen Prüfungen.

Insgesamt kommen allein die bis hierher genannten Zertifizierungsanbieter auf eine mittlere zweistellige Zahl an möglichen Zertifizierungen. Noch nicht enthalten sind die zahllosen halb- und unseriösen Vergabestellen und die klassischen Zertifizierungsdienstleister (wie z.B. der TÜV und die IHK) die ihr Portfolio ebenfalls in Richtung Agilität erweitert haben sobald zu erkennen war, dass hier eine Nachfrage entsteht die man bedienen kann.

Als Folge dieser Entwicklung treten mittlerweile Overkill-Erscheinungen auf. Zunehmend ratlos stehen Personaler und Einkäufer vor der Frage ob ein CSP-SM oder ein PSM III wirklich so viel mehr wert sind als ein A-CSM oder ein PSM II, für Einzelpersonen ist nicht mehr nachvollziehbar welches Zertifikat ihnen helfen könnte, AKC und SDP sind sogar in Fachkreisen weitgehend unbekannt und der IHK-zertifizierte Agile Mindsetter löst nur noch ein Mittelding aus Fassungslosigkeit und Belustigung aus.

Letzten Endes kann man aber auch etwas Positives aus der Gesamtsituation ziehen. Je undurchsichtiger und unvergleichbarer die sich inflationär vermehrenden agilen Zertifizierungen werden, desto mehr werden Einzelpersonen, Personaler, Recruiter und Einkäufer darauf zurückgreifen müssen die Sinnhaftigkeit und das Vorhandensein der angestrebten oder verlangten Wissensgebiete, Qualifikationen und Erfahrungen selbst zu überprüfen. Und das - nicht die noch verbreitete Zertifikatsgläubigkeit - sollte ohnehin der Normalzustand sein.

Why agile: Gesetzliche Regulierung

Bild: Unsplash / Patrick Tomasso - CC0 1.0

Zu den verbreiteten Mythen um agile Produktentwicklung gehört auch die Aussage, dass sie in bestimmten Zusammenhängen nicht einsetzbar wäre. Der vermutlich zweithäufigste Fall (nach das funktioniert in bestimmten Ländern/Kulturen nicht) ist die mit grosser Überzeugung vorgetragene Behauptung, dass Agilität in stark gesetzlich regulierten Bereichen nicht funktionieren kann. "Da muss man sich schliesslich an Vorschriften halten." heisst es oft. In der Realität ist allerdings das Gegenteil der Fall, gerade hier ist Agilität dringend nötig.

Der Grund dafür ist genau der gerade genannte: man muss sich an die Vorschriften halten. Das bedeutet aber auch, dass man die eigenen Produkte und Prozesse anpassen muss wenn die Vorschriften sich ändern - und zwar rechtzeitig zum Inkrafttreten. Wie schnell das nötig sein kann zeigt ein Bericht der Berliner Zeitung. Ihm zufolge dauert es im Durchschnitt 231 Tage bis ein Gesetz gültig wird. Klassische Change-Projekte dauern meistens deutlich länger, oft ein oder mehrere Jahre.

Selbst diese 231 Tage sind aber noch immer trügerisch lang. Zum einen ist es ein Durchschnittswert (es gibt also Abweichungen nach unten), zum anderen können während der Entstehung noch bis zur letzten Lesung signifikante Änderungen des bisherigen Standes eingebracht werden (eine Erklärung des deutschen Gesetzgebungsprozesses gibt es hier). Ein ähnlicher Fall von kurzfristigen Änderungen kann bei der Umsetzung von EU-Richtlinien entstehen, die durch ein so genanntes "Corrigendum" ergänzt werden können (wie im Fall der DSGVO geschehen).

Zuletzt bleibt immer noch das Risiko, dass die Auslegung einer bereits in Kraft getretenen Vorschrift sich durch ein Gerichtsurteil ändert, wie etwa im Fall des Urteils des Europäischen Gerichts zur Arbeitszeiterfassung. Ein gutes Beispiel für die weitreichenden Folgen, da zu seiner Umsetzung schlimmstenfalls komplette IT-Systeme neu zu konfigurieren oder sogar neu zu entwickeln und zu integrieren sind. Auch eine solche Situation erfordert schnelle Reaktionen um Rechtsunsicherheit und versehentliche Gesetzesverstösse zu vermeiden.

Der langen Rede kurzer Sinn: gerade in stark gesetzlich regulierten Bereichen ist agile Produktentwicklung nicht nur möglich sondern dringend nötig.

Three Ways to break Hierarchy

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



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

Relativ erfolgreich

Bild: Pixabay / Engin Akyurt - CC0 1.0

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

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

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

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

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

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

Freiheit und Sinnhaftigkeit

Bild: National Guard / University of Minnesota IAS - Public Domain

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

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

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

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

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

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

Welches Scrum darfs denn sein?

Bilder: Flickr / Charlie / Royskeane - CC BY 2.0

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

Ur-Scrum

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

"Historisches" Scrum

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

Scrum by the Book

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

ScrumBut / ScrumAnd

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

Verschlimmbessertes Scrum

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

Kastriertes Scrum

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

Scrum@Scale / Scrum the Toyota Way

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

Und noch mehr ...

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

Kommentierte Links (LIV)

• Christopher Laine: Advice to Product Owners from a Developer

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

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

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

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

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

• Dave Snowden: Separated by a common language?

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

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

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

Erosion

Bild: Wikimedia Commons / Thomas Wilken - CC BY-SA 3.0

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

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

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

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

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