Donnerstag, 26. März 2020

Backlogs

FS
Bild: Pixabay / Pandapotter - CC0 1.0
Sprachen sind komplizierte Konstrukte. Selbst die mit der wir aufgewachsen sind hält Unklarheiten und Doppeldeutigkeiten bereit, bei Fremdsprachen ist es noch einmal schwieriger. Wenn dann auch noch spezifische Fachbegriffe dazukommen besteht die grosse Gefahr von Fehldeutungen. Ein Fall in dem das leider immer wieder vorkommt ist einer der zentralen Begriffe der Agilität: das Backlog.

Würde man eine beliebige Anzahl von Product Ownern um eine Erklärung bitten was das denn überhaupt ist, dieses Backlog, käme in fast allen Fällen eine ähnliche Antwort zu Stande. Die meisten würden sich darauf einigen, dass es sich um einen Vorrat an Arbeit, Herausforderungen oder Aufgaben handelt, aus dem sich das Team bedient um durch die Umsetzung Mehrwert zu schaffen. Viele würden noch Ergänzungen anbringen wie User Stories, Sprint-Ziele oder priorisiert, aber der Grundtenor wäre gleich.

Das Problem dabei: das ist nicht das was der Begriff eigentlich bedeutet und es wird der Intention auch nicht gerecht mit der er in Scrum übernommen wurde. Diese "überraschende" Bedeutung (die jeder problemlos in jedem beliebigen Wörterbuch nachschlagen könnte) ist nämlich eine andere: Backlog bedeutet ins Deutsche übersetzt Rückstau. Und dieses Wort ist etwas komplett anderes als ein Arbeitsvorrat.

Ähnlich wie im Strassenverkehr ist ein Rückstau etwas was man eigentlich nicht haben möchte. Er bildet sich hinter Engpässen, Blockaden oder in überlasteten Systemen, er steht sinnbildlich für verlorene Zeit und ungenutzte Ressourcen und - am schlimmsten - er ist selbst Ursache für noch mehr Verzögerungen. Um das zu verstehen reicht es aus sich neben eine Bahnschranke zu stellen. Geht sie hoch fahren die aufgestauten Autos nicht sofort alle los sondern erst nach und nach, je weiter entfernt desto später. Ähnliche Phänomene zusätzlicher Verspätungen gibt es auch bei der Arbeitsplanung.

Aus diesem Grund1 ist es ein zentraler Aspekt eines Backlogs, dass es so kurz wie möglich sein sollte. Je besser das gelingt desto geringer sind die negativen Auswirkungen. Natürlich bedeutet das nicht, dass ohne Plan einfach losgearbeitet wird. Es muss eine langfristige Produktvision geben und um die zu erreichen muss im Just in Time-Verfahren immer so viel Arbeit abgeleitet und heruntergebrochen werden, dass in der nächsten Zeit genug zu tun ist.

Aber: das sollte nur in einem Ausmass passieren, das klein genug ist um einen grösseren Rückstau zu vermeiden. Und sollte der doch einmal entstehen muss man das nicht hinnehmen sondern kann ausmisten.


1Und ausserdem zu zu verhindern, dass ggf. für eine Zukunft geplant wird die so gar nicht eintritt.

Montag, 23. März 2020

Sense of Urgency

FS
Bild: Kirill M / Slonpics - CC0 1.0
Falls zukünftige Generationen die Geschehnisse im Frühling 2020 rückblickend betrachten sollten werden sie vermutlich einen Sachverhalt besonders bemerkenswert finden: die unglaubliche Geschwindigkeit mit der hier in Deutschland Grundrechte ausser Kraft gesetzt wurden. Nur wenige Wochen nach dem ersten Coronavirus-Fall wurde von der Regierung beschlossen die Versammlungsfreiheit auszusetzen, die Bewegungsfreiheit einzuschränken und bestimmten Gruppen zeitweise die Berufsfreiheit zu nehmen (dazu kommen noch beispiellose finanzielle Massnahmen). Noch vor drei Monaten wäre das unvorstellbar gewesen.

Dass sich das in so kurzer Zeit derartig radikal geändert hat, hat mit einem Phänomen zu tun, das im Change Management Sense of Urgency (übersetzt Gefühl der Dringlichkeit) genannt wird. Dabei handelt es sich um nicht weniger als um den heiligen Gral aller Veränderungsvorhaben - wenn der Sense of Urgency gegeben ist werden auch weitreichende Veränderungen von den Beteiligten und Betroffenen nicht nur hingenommen sondern sogar unterstützt, was im Change Management der anzustrebende Idealzustand ist.

Damit dieses Gefühl entsteht müssen in der Regel zwei Voraussetzungen gegeben sein: zum einen muss wirklich eine Dringlichkeit vorliegen, zum anderen müssen bei Nichtstun ernsthafte Konsequenzen drohen. Das scheint naheliegend, ist es in der Realität meistens aber nicht. In grossen Organisationen wird oft schon von einem Sense of Urgency gesprochen wenn in zwei Jahren eine Verrentungswelle ansteht, nach der Stellen extern (und damit teurer) besetzt werden müssen. Wie unsinnig eine solche Begriffsverwendung ist zeigt sich beim Vergleich mit echter Dringlichkeit: Börsencrashs, Produktionsausfällen, Security Breaches oder (wie im aktuellen Fall) Seuchenausbrüchen.

Der Vorteil eines bei Beteiligten und Betroffenen gegebenen Sense of Urgency ist, dass Reaktionsgeschwindigkeit und Handlungsspielraum schnell und massiv erweitert werden können. Das kann wie im aktuellen Fall bedeuten, dass mit Notstandsverordnungen regiert werden kann, auf die Wirtschaft übertragen aber z.B auch, dass die betriebliche Mitbestimmung oder regulierende Vorschriften tatsächlich oder de facto ausgesetzt werden. Es entsteht dadurch der sprichwörtliche "grosse Hebel", mit dem schnell reagiert und "durchregiert" werden kann.

Auf der anderen Seite stehen aber auch grosse Risiken die beachtet werden müssen. Im schlimmsten Fall kann sich der Sense of Urgency zu einer Massenpanik auswachsen, in deren Rahmen auch unverhältnismässige oder populistische aber wirkungslose Massnahmen durchgepeitscht werden. Zudem ist er zwar ein guter Ausgangspunkt für Hau Ruck-Veränderungen, flacht aber auch schnell wieder ab, weshalb er selten langfristige und nachhaltige Verbesserungsprozesse auslösen kann (einmal mehr sei an dieser Stelle Alan Deutschmanns Buch Change or Die empfohlen).

Zusammengefasst: der Sense of Urgency kann eine mächtige Veränderungskraft sein, der man sich aber mit Vorsicht anvertrauen sollte. Man kann mit ihm in kurzer Zeit viel erreichen aber auch viel beschädigen. Und wenn das Risiko besteht, dass diese Schäden an so fundamental wichtigen Stellen wie den Grundrechten oder der betrieblichen Mitbestimmung auftreten, dann sollte man sich sehr sicher sein, dass man sich nicht gerade von seiner Dynamik zu weit treiben lässt.

Donnerstag, 19. März 2020

Warum Meetings von verteilten Teams länger dauern

FS
Bild: Pexels / Andrea Piacquadio - CC0 1.0
Für Teams die aus einem gemeinsamen Büro ins Home- oder Remote-Office wechseln ist es eine genauso überraschende Erfahrung wie für Scrum Master die zum ersten mal ein verteiltes Team übernehmen - die Meetings (und vor allem die Dailies) dauern einfach länger. Und der Versuch das durch konsequentere Moderation zu lösen endet meistens in Widerständen und Frustration. Der erste Reflex: alle Meetings verlängern. Der (hoffentlich) zweite Reflex: herausfinden warum das so ist.

Um dieses Verständnis zu bekommen bietet es sich an das Ganze von der anderen Seite aus zu betrachten - warum sprengen zusammensitzende Teams1 deutlich seltener die Timebox ihrer Meetings? Die vereinfachte Antwort: weil ihre Kommunikation grösstenteils ausserhalb dieser Termine stattfindet, so dass in ihnen ein ganz anderer Focus möglich ist. Und auch die Art dieses Informationsaustausches ausserhalb der Meetings kann man differenzieren, in beiläufige Kommunikation und implizite Kommunikation.

Das einfacher zu verstehende der beiden Konzepte ist die beiläufige Kommunikation. Darunter fällt jeder Austausch zu beruflichen Themen der ohne formellen Anlass stattfindet, meistens dann wenn die Beteiligten sich mehr oder weniger zufällig begegnen. In der Mittagspause, an der Kaffeemaschine, auf dem Weg vom Parkhaus zum Büro, etc. Gegebenenfalls kann sie auch spontan im Büro entstehen, z.B. mit der über den Tisch gerufenen Aufforderung "So, ich bin fertig. Willst Du es Dir ansehen?"

Implizite Kommunikation ist dagegen ein eher unsichtbarer und oft sogar unbeabsichtigter Austausch von Informationen. Dazu gehören Gestik und Mimik, durch die z.B. Begeisterung, Ablehnung oder Ratlosigkeit sehr effektiv übermittelt werden können, es gehören aber auch Informationsübermittlungen dazu für die man nicht einmal gleichzeitig in einem Raum anwesend sein muss. Der aus dem Besprechungszimmer herausschallende emotionale Ausbruch wäre ein Beispiel, oder die Spuren eines nicht zu Hause sondern spät im Büro eingenommenen Abendessens.

Diese beiden Kommunikationsformen fallen weg wenn die Teammitglieder nicht mehr zusammensitzen. Da die auf diese Art vermittelten Informationen (oder der sich aus ihrem Fehlen ergebende Klärungsbedarf) aber wichtig sind wird meistens versucht sie in dem einzigen gemeinsamen Forum auszutauschen das verblieben ist - den Meetings. Diese werden dadurch mit einer viel grösseren Anzahl von Themen überladen als vorher und dauern dementsprechend auch deutlich länger.

Sich über diese Mechanismen bewusst zu sein ist auch der erste Schritt auf dem Weg zur Lösung des Problems. Wenn sie den Beteiligten bewusst sind kann darauf aufbauend versucht werden sie zu kompensieren. Eine Möglichkeit ist z.B. eine gemeinsame "virtuelle Kaffeepause" am Nachmittag, also eine kurze Videokonferenz mit keinem anderen Zweck als einem schnellen Austausch ohne vorgegebene Agenda (z.B. als Lean Coffee), eine andere wäre eine digitale Instant Implementation Hour, in der kleinere Anliegen gebündelt werden können. Je nach Kontext gibt es aber noch viele weitere.

Mit ein bisschen Übung kann ein derartiges Vorgehen das Phänomen der ausufernden Remote-Meetings nicht nur abschwächen sondern sogar weitgehend kompensieren. An einer Stelle muss die Erwartungshaltung aber realistisch bleiben: so effektiv wie bei zusammensitzenden Teams wird die Kommunikation von Remote-Teams nie werden. Man kann aber versuchen dem so nahe zu kommen wie möglich.


1Die Rede ist hier von Teams die schon eine gewisse Erfahrung in agilem Arbeiten haben. Bei Teams in Umbruchphasen ist die Lage nochmal anders.

Montag, 16. März 2020

Von schwarzen und grauen Schwänen

FS
Bild: Wikimedia Commons / Squacco - CC BY-SA 2.0
Zu den Begriffen die im Rahmen der Berichterstattung über den Coronavirus-Ausbruch immer wieder genannt werden gehört der "Schwarze Schwan" (z.B. hier, hier, hier, hier, hier, hier, hier und hier), mit dem ausgedrückt werden soll, dass es sich um einen schweren Ausnahmefall handelt. Erklärt wird er allerdings nicht immer. Anlass genug für ein bisschen Nachforschung - was hat es mit dieser Metapher auf sich? Und wird sie überhaupt korrekt verwendet?

Definiert durch John Stuart Mill und Nassim Taleb basiert sie auf der bis ins 18. Jahrhundert üblichen Redensart "so wahrscheinlich wie ein schwarzer Schwan", mit der ausgedrückt werden sollte, dass etwas völlig unmöglich ist. Der Hintergrund war, dass alle damals bekannten Schwanen-Arten weiss waren. Dieses Sprichwort wurde gegen 1700 widerlegt, als in Australien schwarze Schwäne entdeckt wurden. Das scheinbar Unmögliche war Realität geworden.

In Anlehnung an diese historische Kuriosität verwandten Mill und Taleb den Begriff des schwarzen Schwans als Beschreibung für ein extrem unwahrscheinliches Ereignis, das dann plötzlich doch eintritt. Und während Mill es dabei beliess definierte Taleb (auf dessen gleich benanntes Buch die heutige Verwendung zurückgeht) den Begriff weiter aus. Für ihn gehören (neben anderen, die eher für die rückblickende Betrachtung relevant sind) folgende Charakteristika dazu:
  • völlige Unvorhersehbarkeit und Unvorstellbarkeit
  • plötzliches Auftreten ohne Vorwarnung
  • schwere Konsequenzen1
In gewisser Weise also eine etwas ausführlichere Erläuterung von Donald Rumsfelds Unknown Unknowns.

Angewandt auf die gegenwärtige Situation fällt auf, dass diese Kritierien hier nicht alle gegeben sind. Selbst wenn es in der jüngeren Vergangenheit keine derartigen Pandemien in der westlichen Welt gegeben hat, in anderen Weltgegenden und etwas weiter in der Vergangenheit auch in Europa gab es sie durchaus. Russische Grippe, Spanische Grippe, Asiatische Grippe, Ebola-Fieber, SARS, Schweinegrippe und MERS sind bekannte Fälle der letzten 150 Jahre, SARS und MERS sind dabei sogar mit den aktuell umgehenden Coronaviren verwandt.

Der Begriff des Schwarzen Schwans dürfte damit sowohl nach der Definition von Mill als auch nach der von Taleb eher unpassend sein, denn selbst wenn das Ausmass ohne historischen Vergleich sein mag, das Auftreten einer globalen Krankheit ist es nicht. Passender für die Beschreibung dürfte die ebenfalls von Taleb geprägte abgeschwächte Variante sein, der "Graue Schwan". Dieser ist definiert als ein zwar sehr seltenes aber bekanntes Phänomen, das in ungeahnter Stärke und Plötzlichkeit auftritt. Auf die Coronavirus-Pandemie trifft das zu.

Soweit die Begriffsabgrenzung, jetzt zur finalen Frage: hat diese Differenzierung noch einen Mehrwert über geisteswissenschaftliche Wortklauberei hinaus? Ja, hat sie, denn die Erwägung der vorbeugenden Massnahmen die in den beiden Fällen ergriffen werden können sind jeweils andere. Im Fall des Grauen Schwans kann kontrafaktisches Denken helfen, also die Überlegung wie eine bereits bewältigte Krise noch schlimmer hätte enden können.2 Im Fall des Schwarzen Schwans hilft es nur alle Abläufe und Strukturen so zu optimieren, dass schnelle Entscheidungen möglich sind sobald eine solche Situation eintritt.


1Letzteres natürlich nicht von den australischen Schwänen abgeleitet sondern dazudefiniert
2Dieses Vorgehen führte z.B. zu den erstaunlichen Erfolgen bei der Corona-Bekämpfung in Taiwan

Donnerstag, 12. März 2020

The unexpected benefit of celebrating failure

FS
Zugegeben, alleine der Name von Astro Teller ist irgendwie cool, das was er zu sagen hat aber auch: es geht darum wie in Firmen wie Google das Scheitern von Projekten als etwas Positives gesehen und genutzt wird. Und ein gutes Zitat ist auch dabei: "Skeptizismus und Optimismus sind keine Gegensätze."

Montag, 9. März 2020

(Kein) Powerpoint

FS

Eine Beobachtung die man bei vielen Scrum Mastern und Agile Coaches machen kann ist die, dass sie selten bis nie Powerpoint oder vergleichbare Programme benutzen. Stattdessen wird auf Flipcharts, Whiteboards und Tafeln gemalt und geschrieben, Post Its werden an die Wand geklebt und Karten hochgehalten. Das ist eine derartig zentrale Abweichung von den üblichen Gepflogenheiten des Büroalltags, dass sich ein näherer Blick auf die Ursachen lohnt.

Als wichtige historische Rahmenbedingung ist zunächst die Herkunft der heutigen agilen Frameworks aus der IT zu nennen. Viele Scrum Master haben früher in ihrer Karriere Code geschrieben und sind daher daran gewöhnt, dass Arbeitsergebnisse auch nüchtern, schlicht und schmucklos sein können. Vor allem das für Präsentationen typische "Aufhübschen" ist in diesem Berufsverständnis irrelevant. Entweder etwas macht Sinn oder eben nicht, Ästhetik ist da eher sekundär.

Die zweite "historische Wurzel" ist die starke Abgrenzung der aus den Umsetzungs-Einheiten entstandenen agilen Bewegung zu den sich eher an das Management richtenden klassischen Unternehmensberatungen. Selbst bei den mittlerweile existierenden agilen Beratern wird dieser Unterschied weiterhin kultiviert und äussert sich neben der Ablehnung von beratertypischem Kleidungsstil und Fachjargon auch in der Meidung von Powerpoint als dem klassischen Beraterwerkzeug.

Neben diesen historisch-ideologischen Gründen gibt es aber auch ganz praktische wegen denen digitale Folienschlachten abgelehnt werden. Der offensichtlichste: das meistens groteske Missverhältnis zwischen Erstellungsaufwand und Nutzungsdauer. In grossen Organisationen fliessen oft Stunden oder sogar Tage in übertrieben perfektionistische Präsentationen, die dann nur für Minuten an die Wand geworfen werden. Wer die Steigerung von Effektivität und Effizienz zu seinem Beruf gemacht hat wird das instinktiv verabscheuen.

Ebenfalls ein Ärgernis ist das Verhalten von Meeting-Teilnehmern, das durch Powerpoint getriggert wird. Präsentationen mit vielen Informationen, mit gutem Design oder mit Animationen und eingebetteten Medien (und irgendetwas davon ist fast immer vorhanden) ziehen automatisch die Aufmerksamkeit weg vom Vortragenden und hin zum Bildschirm oder Beamer. Die Folge ist ein Fehlen von Focus und Verständnis, wodurch Termine nachhaltig entwertet werden.

Zuletzt zwingt ein vorbereiteter Foliensatz einem Meeting, bzw. einem Referenten eine starre Agenda auf. Wenn im Rahmen der Durchführung Gesprächsbedarf zu neuen Themen entsteht wird der häufig nicht bedient, da ja keine Folien dafür vorliegen. Und selbst wenn Themenblöcke nur untereinander vertauscht werden wird das Vor- und Zurückspringen (samt des kurzen Auftauchens der dazwischenliegenden Folien) den Ablauf für den Vortragenden hektisch und für die Zuhörer verwirrend machen.

Mit während des Meetings beschriefteten Flipcharts und Whiteboards treten all diese Probleme nicht mehr auf, weshalb sie mit der Zeit zu den bevorzugten Präsentationsmitteln von Scrum Mastern und Agile Coaches geworden sind. Es erfordert zwar gewisse Fertigkeiten in den Bereichen Tafelschrift und Visualisierung, die sind aber erlernbar. Und als unbeabsichtigter Nebeneffekt wirkt das gleichzeitige Miteinander von Vortrag und Visualisierung häufig so beeindruckend, dass es zur Soft Power of Scrum beiträgt.

Freitag, 6. März 2020

Das Scrum-Schisma

FS
Bild: Pixabay / Schach 100 - CC0 1.0
Es gibt Entwicklungen die so langsam vor sich gehen, dass man sie erst bemerkt wenn sie bereits eine Zeit lang existieren und sich schon verfestigt haben. Eine davon dürfte die Aufspaltung der Scrum-Bewegung in zwei Ausrichtungen sein. Nicht etwa in Scrum Alliance und Scrum.org sondern viel grundsätzlicher: die eine Ausrichtung geht davon aus, dass Scrum von ganzheitlicher, organisationsweiter Bedeutung ist, die andere reduziert es auf die Team-Ebene.

Um zu verstehen wie diese Trennung entstanden ist hilft ein Blick in die Vergangenheit. In seiner ersten schriftlichen Form ist das heutige Scrum noch als teambasiert zu erkennen. Das OOPSLA-Paper von 1995 spricht eindeutig vom "Scrum Project Team" mit Subteams für Produktmanagement und Entwicklung. Es wird zwar betont, dass zum Entwicklungsteam auch Vertreter von Marketing, Vertrieb und anderen Funktionen gehören müssen, die Zusammenarbeit mit der umgebenden Organisation ist aber noch kein Thema.

Der seitdem entwickelte "offizielle Weg", vertreten von den Gründern Schwaber und Sutherland und den Verbänden Scrum Alliance und Scrum.org, ist (zugespitzt) der, dass sich das restliche Unternehmen nach dem Scrum Team zu richten hat. Laut Scrum Guide muss die gesamte Organisation die Entscheidungen des Product Owners respektieren, das Entwicklungsteam ermächtigen seine Arbeit selbst zu managen und wird in ihrer Umstellung auf Scrum von den Scrum Mastern geführt.

Dass das eher unbekannt ist liegt wesentlich an der Abneigung von Schwaber und Sutherland gegen zu spzifische Prozessbeschreibungen, die dann im Einzelfall nicht mehr passen würden. Die Art der Umsetzung ist daher bewusst offengelassen, die quasi-offiziellen Skalierungsframeworks LeSS und Nexus stimmen aber darin überein, dass die Verantwortung des Product Owners für alle an diesem Produkt arbeitenden Teams ein wesentliches Element ist.

Wesentlich häufiger als der "offizielle Weg" ist in Unternehmen die Situation vorzufinden, dass Scrum (und ähnliche Ansätze) auf die Teamebene beschränkt werden, und auch dort häufig nur auf die Umsetzung, während Planung, Architekturentscheidungen und Kunden-/Auftraggeberkontakt an andere Gruppen ausgelagert werden. Bekannt ist in diesem Zusammenhang SAFe mit seinen zahlreichen Rollen, aber auch PMI und Prince2 haben (eingeschränktes) Scrum bei sich integriert.

Diese Formalisierung ist aber letztendlich nichts anderes als das offiziell Machen der bereits in vielen Unternehmen schon länger gelebten Praxis. Ohne Kenntnis des übergreifenden Anspruchs (oder ohne Bereitschaft ihn zu akzeptieren) ist Scrum an vielen Stellen schon seit längerem ein reiner Team-Ansatz, der damit zwar die reine Lehre nicht erfüllt, meistens aber besser funktioniert als das vorher genutzte Mikromanagement.

Zu einem Zusammenprall der beiden unterschiedlichen Scrum-Auslegungen kommt es vor allem dann wenn Angestellte oder Berater mit einem Hintergrund der einen Scrum-Variante in ein Unternehmen kommen in dem die andere gelebt wird. Ein Konflikt ist dann unvermeidbar, der aber je nach Kenntnisstand unterschiedlich ausgetragen werden kann. Da wo den Beteiligten das "Scrum-Schisma" bewusst ist kann versucht werden zu einer Lösung zu kommen, da wo davon ausgegangen wird, dass das jeweils "eigene" Scrum auch das einzige ist reden sie aneinander vorbei.

Dienstag, 3. März 2020

The agile Bookshelf: Change or die

FS
Bild: Pixabay / sbtlneet - CC0 1.0
In der Theorie ist das Managen von Veränderungsprozessen eine einfache Sache. Sobald die Notwendigkeit erkannt ist wird diese an alle Betroffenen kommuniziert, es wird ein Umsetzungsplan erstellt, auch der wird breit kommuniziert, es folgt die Umsetzung und man ist fertig. Dass dieses Vorgehen in der Realität meistens scheitert liegt an der Konzentration auf den hinteren Teil, die Umsetzung. Wenn aber schon vorher bei den Betroffenen das Verständnis und die Bereitschaft zur Beteiligung fehlen kann davon ausgegangen werden, dass die Umsetzung nicht erfolgreich sein wird.

In seinem Buch Change or die, das auf einem Artikel mit dem gleichen Namen basiert, versucht der Journalist Alan Deutschmann die Ursache für die häufig fehlende Veränderungsbereitschaft zu ergründen, und das gleich zu Beginn an einem drastischen Beispiel: obwohl sie sich bewusst sind, dass sie damit den eigenen Tod in Kauf nehmen, ändern viele Menschen mit Herzerkrankungen ihren Lebenswandel nicht. Auch an anderen Beispielen aus Wirtschaft und Gesellschaft zeigt Deutschmann auf, dass selbst harte drohende Konsequenzen oft kein ausreichender Grund für Änderungen sind.

Die Ursache dafür sieht er in der klassischen Art wie Veränderungsbedarfe kommuniziert werden. Er selber benutzt dafür die Begriffe Facts, Fear und Force (Fakten, Furcht und Zwang), und zeigt auf, dass diese auf Schockmomenten basierenden Konzepte gar nicht langfristig erfolgreich sein können. Kein Mensch kann sich dauerhaft im Zustand der Alarmiertheit, Erregung und Verängstigung befinden, früher oder später setzen Gewöhnung und Abstumpfung ein. Die Veränderungsbereitschaft verschwindet dann so schnell wieder wie sie aufgetreten ist.

Als bessere Konzepte führt Deutschmann Relate, Repeat und Reframe ein (den Bezug zu sich selbst erkennen, Neuerungen nach und nach Verinnerlichen, eine neue Welt- bz. Systemsicht entwickeln). Im genauen Gegensatz zu den Schockeffekten von Facts, Fear und Force handelt es sich dabei um langwierige, dafür aber auch nachhaltige Prozesse, mit denen auch umfangreiche und drastische Veränderungen möglich sind. Auch hierfür führt er zahlreiche Beispiele aus Wirtschaft und Gesellschaft an.

Obwohl Artikel und Buch nicht neu sind (verfasst 2005, bzw. 2007) sind sie noch nicht im Mainstream angekommen, noch immer wird die Sinnhaftigkeit von Veränderungsvorhaben auf die klassische Weise kommuniziert (statt Facts, Fear und Force spricht man heute aber eher vom Sense of Urgency). Sie sind daher weiterhin als Leseempfehlung nutzbar und haben nichts von ihrer Aktualität eingebüsst.

Samstag, 29. Februar 2020

Kommentierte Links (LIX)

FS
  • Zu den IT-Problemen des Iowa-Caucus: Sascha Lobo, Mark Graban, Steve Denning

  • Man soll sich ja mit sehr starken Aussagen zurückhalten, aber die IT-Panne bei den ersten Vorwahlen der US-Demokraten dürfte nicht nur dieser Partei geschadet haben sondern auch dem Ansehen der Demokratie in Amerika und weltweit. Bedingt durch die Prominenz des Falls haben sich verschiedene Experten mit den Hintergründen beschäftigt, von denen an dieser Stelle drei erwähnenswert sind, da sie verschiedene Aspekte beleuchten. Sascha Lobos Analyse lässt sich mit dem Satz zusammenfassen, dass hier technisch ahnungsarme Menschen aus (im wahrsten Sinn des Wortes) politischen Gründen den Go Live eines noch nicht fertig entwickelten Produktes erzwungen haben - ein auch aus der Wirtschaft bekanntes Phänomen. Mark Graban zeigt auf, dass die gesamte Produktidee der Caucus-App nicht gut durchdacht war. Alleine seine Anmerkung, dass das ganze Konzept einer mobile App wenig Sinn macht wenn bekannt ist, dass die meisten Abstimmungen an Orten mit schlechter Netzabdeckung stattfinden, lässt das Ausmass der Fehlplanung erahnen. Steve Denning erinnert schliesslich daran, dass der Abstimmungsprozess bereits vorher so intransparent und erratisch organisiert war, dass jeder andere Versuch ihn zu digitalisieren auch zu Problemen geführt hätte. Alles in allem ein Katastrophengemälde, dass das Potential hat zu einem neuen Wasa-Mythos zu werden.

  • Sjoerd Kranendonk: The Increment in Police work

    Die Vielfalt von möglichen Anwendungsfällen für Scrum scheint ohne absehbares Ende zu wachsen. In diesem Beispiel von Sjoerd Kranendonkwird es von einen (Non IT-)Team der Polizei benutzt um die Verfolgung und Prävention von Verbrechen zu organisieren. Allein das wäre bereits einen Link wert, aber der Artikel enthält noch mehr interessanten Inhalt: sehr schön wird herausgearbeitet, dass selbst für diesen abseitigen Zweck keine Veränderung des Regelwerks nötig ist. Ein weiterer Beleg dafür, dass es sich bei der häufigen Aussage, dass Scrum ohne "pragmatische Anpassungen" nicht funktionieren würde, nur um Ausflüchte handelt, mit denen ihre Urheber sich um nötige aber unangenehme Anstrengungen drücken wollen.

  •  Marty Cagan: Team Objectives

    Passend dazu, dass man nicht versuchen sollte, sich um nötige aber unangenehme Anstrengungen zu drücken: obwohl dieser Text von Marty Cagan damit beginnt, dass er aufgehört hat Objectives and Key Results (OKRs) zu empfehlen kann man ihn auch Appell lesen sie trotz allem doch einzuführen - aber eben nur so wie diese Technik eigentlich gedacht ist. Als besonders wichtig erachtet er dabei, dass man OKRs nicht einfach in einer bestehenden Organisation einführen kann ohne diese zu verändern. Erst wenn bestimmte Rahmenbedingungen wie Produktteams, Teamziele und verändertes Management-Selbstverständnis gegeben sind macht eine Einführung Sinn. Dieser Analyse kann man nur voll und ganz zustimmen.

  • Andy Cleff: How to Effectively Measure Your Transformation Journey

    In meinem Artikel Wann ist eine agile Transformation abgeschlossen? Hatte ich bereits einige Überlegungen zu dem Thema der Messbarkeit von "Agilisierungserfolgen" gemacht. Andy Cleff tut das ebenenfalls, wenn auch mit wesentlich grösserer inhaltlicher Tiefe. Wärmstens zu empfehlen ist es, nicht nur bis zur Aufzählung der von ihm als sinnvoll empfundenen Metriken zu lesen (Employee Engagement, Continuous Improvement, Innovation, Customer Satisfaction, Market Responsiveness, Productivity, Speed, Quality, Predictability) sondern auch noch weiter. Für jede Einzelne führt er verschiedene Beispiele auf, darunter auch einige bei denen auf interessante Art und Weise um die Ecke gedacht wird. So ist z.B. Slack Time ein Indikator für Innovativität und die Menge ungeplanter Arbeit ein Indikator für Prognosefähigkeit. Alleine diese Gedankenanstösse sind lohnend.

  • Mike Freislich: Manage flow, not people!

    Mitunter sind es nicht die Vielschreiber denen es gelingt Bemerkenswertes zu veröffentlichen sondern die, die eher selten zur Tastatur greifen. Dieser Blogpost von Mike Freislich steht sinnbildlich dafür, denn obwohl er der einzige ist den er auf Medium veröffentlich hat ist er sowohl lang als auch gut geschrieben und inhaltlich wertvoll. Nachvollziehbar strukturiert führt er durch das was man als den "State of the Art of Kanban" bezeichnen könnte und führt ganz nebenbei einen neuen Begriff ein: DOF (Death of Flow).

Donnerstag, 27. Februar 2020

Feedback Wraps

FS
Bild: Wikimedia Commons / Takeaway - CC BY-SA 3.0
Als Agile Coach und/oder Scrum Master werde ich regelmässig um Feedback zu allen möglichen Themen gebeten, von neuen Meetingformaten über Methodenverständnis bis zu der persönlichen Weiterentwicklung von Teammitgliedern und Coachees. Als Folge meiner "agilen Neujahrsvorsätze" gebe ich dieses Feedback seit einigen Wochen verstärkt in einer besonderen Form: ich rede in seinem Rahmen relativ viel über mich selbst.

Dieses auf den ersten Blick überraschende Verhalten beruht (hoffentlich) nicht auf Egozentrik sondern auf einer Technik aus dem Umfeld von Management 3.0, dem so genannten Feedback-Wrap. Der Anspruch dahinter: diese Art Feedback zu geben soll klar als solche erkennbar sein, nicht bewertend wirken, Empathie vermitteln und als gut gemeint wahrgenommen werden. Damit soll sie sich bewusst von der Sandwich-Methode (eine zwischen zwei Komplimenten versteckte Kritik) unterscheiden, von der auch die Benennung nach einem bekannten Lebensmittel inspiriert ist.

Um zu verstehen wie (und ob) das funktionieren kann ein kurzer Überblick. Ein Feedback-Wrap besteht aus insgesamt fünf verschiedenen Teilen:
  1. Kontext - in welcher Situation, bzw. welcher Stimmung befindet sich der Feedbackgeber gerade (entspannt, gestresst, etc.)?
  2. Beobachtungen - die möglichst neutral formulierten Wahrnehmungen des Feedbackgebers zum jeweiligen Sachverhalt (z.B. "Die ersten sieben Seiten sind schon ausformuliert, auf den nächsten vier stehen noch Blindtexte")
  3. Emotionen - wichtig dabei: auch potitive Emtionen wie Neugier und Anerkennung gehören dazu. Und: bei negativen Emotionen immer die persönliche Betroffenheit nennen (z.B. "ich bin etwas besorgt, da Freitag die Abgabefrist endet")
  4. Wichtigkeit - geht es bei jeweiligen Sachverhalt um Kleinigkeiten ("wenn wir nicht pünktlich sind verliere ich eine Wette um einen Kasten Bier") oder ist er kritisch ("ohne diese Zulieferung ist der Auftrag in Gefahr")?
  5. Anregungen - hierzu können Hilfsangebote gehören ("Soll ich beim Kunden um etwas mehr Zeit bitten?"), aber auch Kontext-Informationen ("Das geht im Schwarz-Weiss-Druck raus, das Farbschema ist also nicht so wichtig")

Im Zusammenhang mit dem oben genannten "über sich selbst reden" sind vor allem die Punkte Eins, Drei und Vier wichtig. Die Kontext-Information kann dafür sorgen, dass der Empfänger eine sehr knappe oder übermässig euphorische Rückmeldung besser einordnen kann, die Offenlegung der eigenen Emotionen macht für den Feedbackempfänger die Motivation und das Verhalten des Feedbackgebers besser nachvollziehbar, die Vermittlung der Wichtigkeit zeigt auf welches Feedback für den Geber von Bedeutung ist und welches eher als unverbindliche Kommentierung gedacht war. Dem Feedbackempfänger diese Informationen mitzugeben kann Offenheit, Wertschätzung und Augenhöhe in deutlich differenzierterer Weise vermitteln als ein einfaches Loben und Kritisieren.

Natürlich passt ein Feedback-Wrap nicht in jede Situation, und bei übermässiger Verwendung besteht das Risiko in Formelhaftigkeit zu erstarren, grundsätzlich ist es aber ein guter Ansatz um Feedback anders zu gestalten. Um zu erfahren wie es angekommen ist gibt es auch einen einfachen Weg: Feedback für das Feedback erbitten. Gerne auch in Wrap-Form.

Montag, 24. Februar 2020

Wann ist eine agile Transformation abgeschlossen?

FS
Bild: Wikimedia Commons / Erwin Sooputa - CC BY 2.0
 Eine Firma aus meiner Region hat es in den letzten Tagen zu einer gewissen Bekanntheit in der deutschen Agile Community gebracht. "Geutebrück hat agile Transition nahezu abgeschlossen" verkündete sie per Pressemitteilung, nur um Verwunderung und Amüsement zu ernten. In den sozialen Medien und auf Meetups wurde anlässlich dieses Beispiels immer wieder betont, dass agile Transformationen/Transitionen nie abgeschlossen sein können, derartige Erfolgsmeldungen also von Unkenntnis zeugen. Aber ist das wirklich so? Sind agile Transitionen nicht abschliessbar?

Das Argument für diese These ist, dass sich Märkte, Kunden und Technologien ununterbrochen ändern, und das auf unabsehbare Zeit.1 Um damit mithalten zu können müssen sich auch Unternehmen permanent ändern um nicht den Anschluss zu verlieren. Was implizit in dieser Argumentation mitschwingt ist die Gleichsetzung der agilen Transition mit der ständigen Anpassung an sich ändernde Rahmenbedingungen. Akzeptiert man diese Gleichsetzung ist es richtig, ein Ende der Transition gibt es nicht, bzw. nur mit dem Preis der Aufgabe der Agilität.

Es ist aber auch eine andere Sichtweite möglich. In ihr umfasst die Transition nur die Phase in der noch die alte, starre, von Langfristplanung und Jahresbudgets getriebene Organisation existiert, in der sie aber bereits Anstrengungen unternimmt um sich selbst umzubauen (ein häufiger Indikator für derartige Phasen ist die Existenz eines Transformations- oder Transitionsteams). Wenn dieser Umbau mit dem richtigen Ziel erfolgt ist er abschliessbar, und mit ihm auch die Transition. Bleibt nur die Frage: was ist dieses "richtige Ziel"?

Um mit der negativen Definition zu beginnen: die Einführung neuer Rollen und Meetings sollte nicht das Ziel sein, dadurch ändern sich Formalismen und sonst nichts. Auch das "Nachbauen" von erfolgreichen Veränderungen anderer Unternehmen ist keine gute Idee, alleine deshalb weil diese Erfolgsgeschichten meistens nur Momentaufnahmen aus längeren Verbesserungsprozessen sind. Das aus der "agilen Perspektive" richtige Vorhaben ist es dagegen, aus der eigenen Firma eine "lernende Organisation" zu machen, die in der Lage ist sich schnell an veränderte Rahmenbedingungen anzupassen. Und dieses Transformationsziel ist nicht nur erreichbar, es ist sogar messbar.

Klassische Metriken die erreicht werden können um eine agile Transition dieser Definition abzuschliessen wären verschiedene Ausprägungen von Lead Time und Cycle Time (die im Sinn der agilen Prinzipien so kurz wie möglich sein sollten):
  • Time to Market (Zeit zwischen Produktidee und Produkteinführung)
  • Processing Time (Gesamtdauer aller Be- und Verarbeitungsschritte)
  • Feedback Loop Time (Zeit zwischen Produktidee und Benutzer-Feedback)
  • Feedback Implementation Time (Zeit bis zur Umsetzung von Anwender-Wünschen)
  • Time to Recovery (Zeit zwischen Systemausfall und Wiederherstellung)
  • Time to Process Adaption (Zeit zwischen erkannter Notwendigkeit und Umsetzung von Prozessverbesserungen → betrifft Massnahmen die die anderen Werte niedrig halten)
  • Je nach Situation noch weitere

Wenn eine agile Transformation mit dem erklärten Ziel begonnen wurde derartige Werte unter eine definierte Schwelle zu drücken ist sie in dem Moment erfolgreich in dem das gelungen ist. Idealerweise folgt darauf ein permanentes Monitoring, in dem sichergestellt wird, dass die Zahlen auf einem niedrigen Niveau stabil bleiben und Abweichungen im Normalbetrieb erkannt und behoben werden können. Das Transitionsteam kann aufgelöst werden wenn das für einen gewissen Zeitraum gelungen ist, da sich das Unternehmen dann mit nachvollziehbarer Begründung agil nennen kann. Und sollten die Werte irgendwann in der Zukunft nicht mehr im Normalbetrieb niedrig zu halten sein startet man eben eine neue Transformation.

Es bleibt nur die letzte Frage: entspricht die "nahezu abgeschlossene" Umwandlung der zu Beginn genannten Firma Geutebrück diesen Kriterien? Anhand der Pressemitteilung ist es nicht zu erkennen, dafür liegt ihr Schwerpunkt zu sehr auf Management-Personalien. Zu wünschen wäre es ihr.


1Natürlich gibt es auch stabile Märkte, in denen machen agile Transitionen aber kaum Sinn und finden kaum statt

Donnerstag, 20. Februar 2020

The Golden Age of Agile Coaching

FS
Alleine der Titel ist grossartig, aber auch unabhängig davon ein sehenswerter Vortrag, der viele Aspekte dessen berührt was man heute unter dem Begriff "Agile Coach" versteht.

The Golden Age of Agile Coaching - Shane Hastie from Agile Alliance on Vimeo.

Montag, 17. Februar 2020

Das Urteil des Dodo

FS
Grafik: Flickr / Biodiversity Heritage Library - Public Domain
Welcher agile Ansatz ist denn jetzt der Richtige? Ist es Scrum oder Kanban? LeSS oder SAFe? Lean Startup oder Extreme Programming? Derartige Fragestellungen findet man häufig, vor allem in Unternehmen die gerade ihre ersten Schritte in diese Richtung machen. Die Frage scheint auch nachvollziehbar zu sein, schliesslich soll die Lösung ja zum Problem passen. Und doch - beantwortet wurde sie bis heute nicht, welches Framework in welcher Situation am besten hilft bleibt offen1.

Wie kann man am besten mit dieser unbefriedigenden Unklarheit umgehen? Hier hilft einmal mehr der Blick über den Tellerrand. Auch in anderen Wissensgebieten kann nicht klar gesagt werden welcher Ansatz der beste oder hilfreichste ist, und eines das einen näheren Blick lohnt ist die Psychotherapie. Wie im Fall der agilen Frameworks bestehen auch hier verschiedene miteinander konkurrierende Ansätze. Die Frage nach dem Besten konnte auch hier lange nicht beantwortet werden. Bis 1936.

Die vom amerikanischen Psychologen Saul Rosenzweig vorgestellte Lösung lautete: alle Ansätze sind richtig. Für eine bessere Kommunizierbarkeit gab er dieser Erkenntnis einen Namen - The Dodo Bird Verdict (Das Urteil des Dodo), benannt nach einer Figur aus Alice im Wunderland, deren Schiedsspruch nach einem Wettrennen lautete "Everybody has won and all must have prizes."

Um von der Fachwelt akzeptiert zu werden brauchte Rosenzweig natürlich mehr als einen salomonischen Spruch, weshalb er das Urteil des Dodo mit der wissenschaftlichen Veröffentlichung Some implicit common factors in diverse methods of psychotherapy im American Journal of Orthopsychiatry untermauerte. Wie schon am Titel zu erkennen lautete dessen These, dass die verschiedenen Methoden deshalb gleich wirksam wären, weil sie alle auf den gleichen Grundlagen aufbauen.

Die Parallele zu den agilen Frameworks ist offensichtlich. Auch hier gibt es bei aller Unterschiedlichkeit geimnsame Grundlagen, durch die alle verbunden werden: Akzeptanz der Nichtvorhersehbarkeit der Zukunft, incrementelle Auslieferung, Pull-Prinzip, Delegation von Entscheidungskompetenz, Bereitschaft zur ständigen Anpassung. Und auch hier ist es so, dass jedes Vorgehen das sich an diesen Grundlagen orientiert in vergleichbarer Form erfolgreich sein wird.

Die Frage bei der Auswahl des Vorgehens sollte demnach nicht sein welches Framework das passende ist sondern ob es so umgesetzt wird, dass es den darunterliegenden Ideen gerecht wird. Wenn das der Fall ist kann das Urteil des Dodo auch bei der Methodenwahl angewandt werden.


1Natürlich gibt es Menschen die behaupten die Antwort zu wissen, aber die verdienen entweder mit einem bestimmten Framework Geld oder ihre Expertise beruht lediglich auf anekdotischer Evidenz

Donnerstag, 13. Februar 2020

Vom Risiko, sich einem Guru anzuvertrauen

FS
Bild: Wikimedia Commons / André Zehetbauer - CC BY-SA 2.0
Es ist eine lang bekannte Tatsache, dass man fast alles mit einem Fussball-Vergleich erklären kann. Die Geschehnisse um Bundesliga und Nationalmannschaft sind in der deutschen Gegenwartskultur so präsent, dass alles was man aus diesem Bereich als Beispiel nehmen kann sofort anschlussfähig ist. Spätestens seit dieser Woche ist diese Liste von Narrativen um einen Punkt länger geworden. Man kann jetzt auch die Risiken verdeutlichen die entstehen wenn eine Organisation zu bereitwillig einen vermeintlichen Guru damit betraut grosse Veränderungen voranzutreiben.

Der Name mit dem sich das von jetzt an verdeutlichen lässt ist Jürgen Klinsmann. Seitdem er in den Jahren 2004 bis 2006 die deutsche Nationalmannschaft trainierte gilt er als jemand der alte Strukturen aufbrechen und mit neuen Ansätzen zum Erfolg kommen kann. Gleichzeitig gilt er seit seinen Engagements bei Bayern München (2008/2009) und Hertha BSC (2019/2020) aber auch als jemand der mit seinen Methoden seine Umgebung massiv überfordern und letztendlich sogar lähmen kann. Die verschiedenen Medienberichte nach seinen Amtszeiten lassen ein Bild erkennen in dem man Parallelen zu vielen anderen anfangs gefeierten und dann gescheiterten Change-Gurus wiederfindet.

Zu Beginn seiner beiden Amtszeiten stand jeweils etwas das eigentlich positiv ist, eine grosse Vision. Alles sollte moderner, besser und ganzheitlicher werden, und das nicht in irgendeiner Zukunft sondern möglichst schnell und radikal. Das Problem dabei war auch nicht diese Vision sondern das mit ihr kommunizierte Urteil über die jüngere Vergangenheit, der das genaue Gegenteil attestiert wurde. Nicht mehr zeitgemäss sei hier gearbeitet worden, unprofessionell und kleingeistig. Die Reaktion darauf war vorhersehbar: aus der Gruppe derer die ihre bisherige Leistung herabgewürdigt sahen gab es Widerstand.

Die Reaktion auf derartige Widerstände war dann nicht etwa, dass darauf eingegangen wurde, stattdessen wurden alle die die grosse Vision nicht vorbehaltlos zu ihrer machen wollten als störend und behindernd empfunden und von Klinsmann auf das Abstellgleis geschoben. Bei beiden Vereinen gab es gleich reihenweise Spieler und Angestellte die plötzlich ihren Stammplatz oder ihre Anstellung verloren. Auch das erzeugte vorhersehbare Reaktionen: Verunsicherung, passiven Widerstand und Rückzug auf weniger angreifbare Positionen. Ein stetiges Absinken von Stimmung und Leistungsfähigkeit war die Folge.

Statt diese Entwicklung als Anlass zu nehmen sich selbst zu hinterfragen wird aus beiden Vereinen über eine gegenteilige Reaktion Klinsmanns berichtet. Noch mehr Veränderungen, noch mehr Entscheidungsfreiheit und noch weniger Rücksprachen soll er eingefordert haben. Und als diese ihm (nachvollziehbarerweise) nicht gegeben wurden war das für ihn der Grund dafür, dass es nicht weiterging. Ein Projizieren aller Problemursachen nach aussen also, fast immer ein Indikator dafür, dass ein Veränderungs-Vorantreiber die Bodenhaftung verliert. In beiden Fällen folgte dann schnell das Ende.

So weit, so gut - die Moral von der Geschichte ist also, dass zu radikal und zu egozentrisch vorangetriebene Veränderungen scheitern müssen? Nun, ganz so einfach ist es auch nicht. Zum Gesamtbild gehören nämlich auch die beiden anderen Trainerstationen Klinsmanns, die bei den Nationalteams Deutschlands und der USA. Die Methoden waren hier ähnlich, die Resultate aber deutlich besser. In Deutschland gilt er als heimlicher Vater des späteren Weltmeistertitels, in Amerika konnte er die Kontinentalmeisterschaft gewinnen, in beiden Verbänden wird er als grosser Modernisierer anerkannt.

Die eigentliche Lehre die man aus dieser Fussball-Geschichte ziehen kann ist die: was an einem Ort geklappt hat muss keineswegs an einem anderen Ort genauso gut funktionieren, im Gegenteil. Es kann sogar sein, dass die Erfolgsmethode und der grosse Anführer die andernorts spektakuläre Erfolge hatten beim Versuch das zu wiederholen ein Trümmerfeld erzeugen. Statt sich einem vermeintlichen Guru anzuvertrauen ist es im Zweifel also besser nach einem eigenen Weg zu suchen. Das ist zwar weniger glamourös, dafür aber auch mit deutlich weniger Risiko behaftet.

Montag, 10. Februar 2020

Wie junior darf ein Scrum Master sein?

FS
Bild: Pexels / Kyla Daw - CC0 1.0
Ein erkennbarer Trend der letzten Jahre ist der, dass der Scrum Master (bzw. dessen Entsprechungen) zu einem Ausbildungsberuf wird. Wie bei allen anderen IT-nahen Jobs ist es auch hier so, dass der Fachkräftemangel es schwierig bis unmöglich macht genug geeignete Kandidaten für alle offenen Stellen zu finden. Um den zu begegnen finden in vielen Firmen Umschulungen und Ausbildungen statt,1 was die Frage nach den Auswahl- und Zulassungskriterien mit sich bringt. Einer der wichtigsten Aspekte dabei ist das Alter, bzw. die Berufserfahrung. Sollten die angehenden Scrum Master Berufs- und/oder Lebenserfahrung mitbringen oder kommen auch Berufseinsteiger und Mitarbeiter mit erst wenigen Jahren im Job in Frage?

In vielen Fällen wird diese Frage so beantwortet, dass eher jüngere Mitarbeiter in die Ausbildungen geschickt werden. Gründe dafür gibt es mehrere. Zum einen gilt Agilität noch immer als etwas Neues und damit auch irgendwie Jugendliches (was man oft an den Ausschreibungen erkennt), des Weiteren gibt es die noch immer verbreitete Ansicht, dass das Lernen und ausgebildet Werden nur an den Anfang der Karriere gehört. Auch wird häufig davon ausgegangen, dass langgediente Kollegen schon so sehr in festen Denkspuren unterwegs sind, dass sie sich mit Neuerungen schwer tun. Zuletzt sind Nachwuchskräfte einfach billiger (solange man nur das Gehalt betrachtet) und passen so besser ins Budget. Aber - so nachvollziehbar diese Begründungen auch sein mögen, die Entscheidung für die Jugend sollte kritisch hinterfragt werden.

Um die Rolle des Scrum Masters ausüben zu können ist in nicht unwesentlichem Ausmass Vorwissen nötig. Der Scrum Guide erwähnt unter den Standard-Tätigkeiten einige, deren Bewältigung ohne Erfahrungen kaum möglich ist. "Ensuring that goals, scope, and product domain are understood [...] as well as possible", "Understanding product planning in an empirical environment" und "Helping the Development Team to create high-value products" sind drei Beispiele dafür, gleichzeitig zeigen sie auch gut auf, dass das Vorwissen nicht zwingend aus bisherigen Scrum Team-Mitgliedschaften kommen muss. Man kann es auch auf andere Weise erworben haben, erworben haben sollte man es aber.

Noch wichtiger wird die Erfahrung in einem zweiten Bereich. Gleich drei mal wird im gerade erwähnten Abschnitt des Scrum Guides definiert, dass der Scrum Master als Coach tätig sein muss, und zwar sowohl für die einzelnen Mitglieder des Entwicklungsteams als auch für die gesamte Organisation. Und obwohl es keine allgemein gültige Definition von Coaching gibt ist in praktisch jeder Beschreibung explizit oder implizit enthalten, das der Coach sein Charisma zu einem grossen Teil aus seiner Berufs- und Lebenserfahrung bezieht. Er muss nicht zwangsläufig ein alter Mann mit langem weissen Bart sein, er sollte aber glaubhaft vermitteln können in seinem Feld über breites Wissen zu verfügen, wenn er von seinen Coachees akzeptiert werden soll.

Ein dritter Grund dafür, dass Scrum Master eine gewisse Seniorität haben sollten ist der, dass von ihnen erwartet wird ihre Firmen zu führen und zu verändern. Auch hier ist der Scrum Guide eindeutig: "Leading [...] the organization in its Scrum adoption", "Planning Scrum implementations within the organization" und "Working [...] to increase the effectiveness of the application of Scrum in the organization" sind klare Beschreibungen von (Change-)Management-Tätigkeiten. Die können zwar in der Theorie von jedem verantwortet werden, die Übertragung von derartiger Verantwortung an unerfahrene Kollegen ist aber sehr unwahrscheinlich (siehe auch Ist der Scrum Master ein Manager?).

All das spricht also dafür, dass es eher erfahrenere Kräfte sein sollten, die die neue Rolle übernehmen. Selbst wenn es beim Nachwuchs natürlich auch Ausnahme-Erscheinungen geben mag - die meisten eher junioren Kollegen dürften aus den genannten Gründen Schwierigkeiten haben ihre Rolle auszuüben. Es bleibt die letzte Frage - kann man diese Tätigkeiten dann nicht aus ihr herausnehmen? Die Antwort darauf findet sich ebenfalls im Scrum Guide: "Although implementing only parts of Scrum is possible, the result is not Scrum". Mit anderen Worten: man kann das zwar machen, sollte dann aber seine Erwartungshaltung an das Ergebnis herunterschrauben.


1Es gibt auch Firmen die glauben, dass man für den Job nur den zweitägigen Zertifizierungskurs braucht. Die haben andere Probleme.

Donnerstag, 6. Februar 2020

Agile Bauprojekte (III)

FS
Bild: Wikimedia Commons / China News Service - CC BY 3.0
So tragisch der Ausbruch des Corona-Virus in China auch gewesen ist, aus Projektmanagement-Perspektive hat er zu einem interessanten Fallbeispiel geführt. In weniger als zwei Wochen sind in Wuhan, dem Ort an dem die Seuche ausgebrochen ist, zwei Krankenhäuser komplett neu errichtet worden. Auch die Gründe dafür, dass das in derartiger Rekordzeit gelungen ist sind nachvollziehbar, denn bedingt durch die weltweite Aufmerksamkeit die ein solcher Virus auf sich zieht fand eine intensive Berichterstattung in den Medien statt, unter anderem in der New York Times, der BBC, auf QZ.com, in der South China Morning Post und bei Xinhua. Folgende Faktoren scheinen die schnelle Baugeschwindigkeit möglich gemacht zu haben:

Zweckbau statt Show-Architektur

Einige der verheerendsten Bauprojekte sind vor allem deshalb aus dem Ruder gelaufen weil der Architekt besonders schön bauen wollte, was dann in der Umsetzung besonders aufwändig wurde. Die schornsteinfreie Entrauchungsanlage am Berliner Flughafen, die Kelchstützen im Stuttgarter Bahnhof, der Verzicht auf rechte Winkel in der Elbphilharmonie - keine derartige Idee dürfte in Wuhan auch nur erwogen worden sein, was die Errichtung ungemein vereinfacht haben dürfte.

Einfache Bauweise

Die Krankenhäuser sind nicht nur Zweckbauten, es sind einfache Zweckbauten. Die Gebäude sind kastenförmige, zweigeschossige Flachbauten ohne Keller. Damit waren keine Ausschachtungsarbeiten nötig, die tragenden Wände müssen kein grosses Gewicht aushalten, es gibt keine breiten oder hohen Hallen mit komplizierter Statik. Das ist simpel und schnell zu planen und zu bauen. Auch weitere Aufwände wie die Entsorgung der ausgebaggerten Erde und der Transport und Aufbau hoher und stabiler Gerüste sind entfallen.

Focussierung

Ähnlich wie das im Jahr 2003 während der SARS-Epidemie gebaute Xiaotangshan Hospital in Peking dienen die neuen Krankenhäuser nur der Bekämpfung einer einzigen Krankheit. Bedingt dadurch kann vieles entfallen was in normalen Krankenhäusern vorhanden sein muss: OP-Räume, Radiologie-Anlagen, medizinische Labore und Entbindungsstationen mussten nicht gebaut werden, wodurch die Komplexität des Bauvorhabens noch einmal reduziert wurde.

Modularisierung

Durch die einfache und focussierte Architektur wurde ein weiterer Beschleunigungsfaktor möglich: der Grossteil der beiden Gebäude wurde aus vorgefertigten Bauteilen errichtet, die parallel an anderen Orten angefertigt wurden und vor Ort nur noch zusammengebaut werden mussten. Eine Bauweise die auch in Deutschland bekannt ist, die im Osten verbreiteten Plattenbauten wurden so errichtet (daher auch der Name → aus Platten zusammengebaut).

Standardisierung

Das gerade erwähnte Xiaotangshan Hospital ist aus einem weiteren Grund von Bedeutung: durch seine seinerzeit ähnlich schnelle Errichtung gab es Erfahrungswerte die als Blaupause für die Neubauten verwedet werden konnten. Die Voraussetzung dafür war allerdings, dass die Behandlung und Pflege von SARS- und Corona-Virus-Patienten mit den gleichen Anlagen und Geräten möglich ist. Das scheint in diesem Fall auch so gegeben gewesen zu sein.

Entbürokratisierung (Priorisierung)

Die beschleunigten Genehmigungs- und Finanzierungsverfahren haben sicher auch damit zu tun gehabt, dass durch die zuvor genannten Faktoren das Ausmass der Komplexität und der nötigen Qualitätssicherung deutlich reduziert werden konnte. Gleichzeitig muss es aber auch so gewesen sein, dass der Teil auf den nicht verzichtet werden konnte Vorrang vor allen anderen Vorhaben hatte. Ganz wesentlich dürfte diese klare Priorisierung mit der ausgerufenen Notlage zu tun haben.

Skalierung

Auf vielen Bildern kann man erkennen, dass Arbeiten so weit wie möglich parallelisiert wurden. Alleine auf dem oben zu sehenden Bild befinden sich über 30 Baufahrzeuge, auf anderen Bildern sind zahllose Arbeiter zu sehen die gleichzeitig Beton giessen, Dachplanen ausrollen oder sonstige parallel ausführbare Tätigkeiten durchführen. Man kann davon ausgehen, dass zwei Voraussetzungen dafür nötig waren: ein immenses Budget und eine boomende Bauindustrie, mit vielen ausgebildeten Arbeitern und geeigneten Maschinen. Beides war in diesem Fall vorhanden.

Verzicht auf Nachhaltigkeit

Positiver formuliert: hier wurde mit einem MVP-Gedanken im Kopf gebaut. Noch einmal zum Referenz-Beispiel des Xiaotangshan Hospitals. Nach dem Abklingen der SARS-Epidemie wurde es anscheinend weitgehend aufgegeben und stand leer, was auch nachvollziehbar ist. Viele der funktionalen und ästhetischen Beschränkungen die eine schnelle Errichtung möglich machen grenzen auch die Nachnutzung ein. Andererseits stand hier eben die schnelle Seuchenbekämpfung im Mittelpunkt und nicht nachhaltiges Bauen.

---

Natürlich ist der Bau der Kankenhäuser in Wuhan ein Extrembeispiel, dass nur im Rahmen extremer Rahmenbedingungen möglich war und daher nur begrenzt in andere Kontexte übertragbar ist. Es zeigt aber auch, dass in kürzester Zeit erstaunliches möglich ist wenn Willen und Dringlichkeit da sind. In die "agile Terminologie" übertragen - der Bau eines ganzen funktionierenden Kankenhauses hat gerade mal einen Sprint gedauert. Das ist mehr als beachtlich.

Montag, 3. Februar 2020

Anekdotische Evidenz

FS
Bild: Pexels / Fauxels - CC0 1.0
Wann immer eine Gruppe Agile Coaches, Unternehmensberater und Scrum Master zusammensitzt um darüber zu diskutieren wie man agile Transformationen ganzer Unternehmen durchführen kann, wird man eines mit Sicherheit erwarten können: lebhafte Erfahrungsberichte. Anders wird es dagegen aussehen wenn um deren Repräsentativität geht und um die empirische Fundierung. Nur in extrem seltenen Fällen hat jemand mehr als zehn Transformationen über einen längeren Zeitraum in einer Position mit Gesamtüberblick begleitet, die meisten werden sogar auf weniger als fünf kommen.1

Den an dieser Stelle naheliegenden Exkurs zu den Hauptgütekriterien statistischer Werte kann man sich angesichts dieser Zahlen gleich ersparen, zu offensichtlich ist es, dass die Menge zu gering ist um allgemeingültige Erkenntnisse abzuleiten. Die daraus folgende spannende Frage: wer könnte denn über die notwendige Menge an Erfahrungen verfügen? Ein altgedienter Berater mit jahrzehntelanger Projekterfahrung? Auch das eher nicht, alleine wegen der üblichen Karrieren. Den einfachen Juniors und Consultants fehlt noch der Überblick, die Partner und Associates sind schon wieder zu weit weg vom Geschehen. Im Mittelbau gibt es zwar relevante Erfahrung, aber dort verbleibt kaum jemand lang genug.

Es bleibt eine andere Möglichkeit: wenn schon kein Einzelner über repräsentative Erfahrungswerte verfügt - vielleicht kommen im kollektiven Gedächtnis von Unternehmen genug zusammen? Schön wärs, aber vermutlich ist auch das nicht der Fall. Vor dem Hintergrund, dass in nahezu jedem Einzelfall einzigartige Konstellationen bedeutender Einflussfaktoren vorliegen (Demografie der Belegschaft, Regulierungsintensität, Unternehmenskultur, Unternehmensaufbau, Zustand der Systemlandschaft, Branchen-Besonderheiten, aktuelle Management-Moden, etc.) kann bezweifelt werden, dass irgendwo auf dieser Welt eine Datenbasis vorliegt aus der man brauchbare Erkenntnisse ableiten kann.

Sollte das aber der Fall sein, dann würde es sich bei allen Erfahrungsberichten und bei aller daraus abgeleiteten Expertise um nicht mehr halten als um das was man in den Sozialwissenschaften Anekdotische Evidenz nennt. Und hinter diesem Begriff steckt etwas wovon eigentlich strikt abzuraten ist: das Ableiten allgemeingültiger Aussagen aus eigenen Erlebnissen oder (noch schlimmer) aus Berichten von Einzelfällen bei denen man selbst nicht zugegen war und deren Dokumentation lediglich aus oberflächlichen Wiedergaben besteht. Eigentlich sollte all das auch eine Selbstverständlichkeit sein, da manche Anekdoten aber zu gut klingen gibt es mittlerweile ganze agile Pseudo-Frameworks, die nur auf anekdotischer Evidenz beruhen (Spotify, anyone?).

Es bleibt die Frage: wenn es keine verlässlichen Erfahrungswerte für agile Transitionsforhaben gibt, wie sollen sie dann organisiert werden? Die naheliegende Antwort - agil. Wie immer wenn die Zukunft ungewiss ist wird es das beste Vorgehen sein sich auch über längere Zeiträume per Inspect & Adapt voranzutasten. Und um das zu können ist es erforderlich die Transformation in kleine, auch allein Mehrwert stiftende Pakete zu unterteilen und zu diesen dann regelmässig das Feedback der betroffenen einzuholen und dieses ins weitere Vorgehen einfliessen zu lassen. Dieses Vorgehen mag zwar nicht den Charme der eloquent vorgetragenen Erfolgs-Anekdote haben, dafür aber eine wesentlich grössere Erfolgswahrscheinlichkeit.


1Unternehmensweite Transformationen dauern mehrere Jahre, so dass man alleine bei zwei oder drei von ihnen problemlos ein Jahrzehnt verbringen kann.

Freitag, 31. Januar 2020

Kommentierte Links (LVIII)

FS
  • Holger Schmidt: „Noch ist das Gerede von Industrie 4.0 Unsinn“

  • Hier wird Einiges an Content geboten. Sowohl der verlinkte Artikel als auch das dort eingebettete Video sind sehenswert für jeden der davon ausgeht, dass Deutschland (oder sonst irgend ein Land auf der Welt) seine produzierende Wirtschaft schon auf die so genannte "Industrie 4.0" umgestellt hat. Der Grund dafür ist, dass die dafür notwenige Datenerhebung und Datenzusammenführung noch immer in fast keinem Unternehmen stattfindet. Nicht etwa weil das nicht gewollt ist sondern weil die (meistens Jahrzehnte alten) Anlagen einfach nicht so gebaut sind, dass das möglich wäre. Passend dazu auch dieser Artikel von Frank Thelen in dem er davon ausgeht, dass Tesla von den deutschen Autobauern kaum noch einzuholen ist - weil es anders als diese grossen Wert auf Datenerhebung und -auswertung legt.

  • Willem-Jan Ageling: Scrum didn’t work for us, so we went back to PRINCE2 / PRINCE2 didn’t work for us, so we went back to Scrum

    Hier wird der Finger in eine Wunde gelegt, die in mehr als einer Hinsicht schmerzt. In diesen zwei fast identischen Artikeln zeigt Willem-Jan Ageling auf, dass die Einführung von Agilität in grossen Organisationen an der selben Unwilligkeit sich an Prozesse zu halten scheitert wie zuvor die Einführung von eher klassischen Management-Vorgehen (Stichwort Konzern-Anarchismus). Und mehr als das - auch dass diesen ihre scheinbare Erfolglosigkeit genauso wenig vorgehalten werden kann wie den agilen Frameworks ihre oft scheiternde Umsetzung. Es ist in den meisten Fällen nie ernsthaft versucht worden. Ein ernsthafter Vergleich dieser Ansätze dürfte daher in den meisten Fällen unmöglich sein - in ihrer eigentlich angedachten Form kennt man beide oft nur vom Hörensagen.

  • Nadja Kupsa / Gerald Hüther: "Kinder machen sich aus Liebe zu Eltern selbst unglücklich"

    Zunächst ein scheinbar abseitiges Thema - was hat kindliche Entwicklung mit Agile, Scrum, Kanban, Change Management und dem ganzen Rest zu tun? Erstaunlich viel. Gerald Hüther gibt hier einen hochinteressanten Einblick in die Entstehung und die Folgen von Konformitätsdruck. Kurz zusammengefasst: er ist nicht grundsätzlich schlecht, hat aber häufig die negative Auswirkung, dass das eigene (Kreativ)Potential nicht mehr abgerufen werden kann. Was das für Folgen auf Wirtschaft und Gesellschaft haben kann wird an Beispielen erläutert, und auch einen Lichtblick gibt es: dank der Neuronalen Plastizität kann man Deformationen noch bis zum Lebensende ausgleichen.

  •  Naomi Stanford: Decaf, pragmatic and real resistance

    Dass es keinen Widerstand gegen Veränderungen gibt sollte Allgemeinwissen jedes Menschen sein, der sich mit Organisationsentwicklung beschäftigt. Widerstand gegen vom Betroffenen als negativ wahrgenommene Veränderungen gibt es aber, und Naomi Stanford versucht sich an einer Kategorisierung.
    • "Entkoffeinierter Widerstand" ist abgeleitet von entkoffeiniertem Kaffe - er fühlt sich ähnlich an, entfaltet aber keine nachhaltige Wirkung. Im Wesentlichen besteht er aus mehr oder weniger lautem und sarkastischen Anzweifeln der Wirksamkeit.
    • Pragmatischer Widerstand ist der Versuch irrationale oder untereinander widersprüchliche Arbeitsanweisungen so zu umgehen, dass produktives Arbeiten wieder möglich ist. Erinnert stark an Luhmanns brauchbare Illegalität.
    • Echter Widerstand ist das, was der umgangssprachlichen Definition von Widerstand am ehesten entspricht, von der Auflehnung und Verweigerung bis hin zum Whistleblowing. In der Wirklichkeit sehr selten anzutreffen, da es mit der Gefahr von Statusverlust und Karrierenachteilen verbunden ist.
    Erwähnenswert ist an Stanfords kurzer Liste die wissenschaftliche Fundierung. Sowohl das Konzept des "entkoffeinierten" als auch das des pragmatischen Widerstands beruhen auf Publikationen in denen das Thema weiter vertieft wird.

  • Ray Arell: Viable Organizations with Beer

    Zugegeben, dieser Artikel ist vor allem wegen seines Namens verlinkt. Lesenswert ist er aber trotzdem. Ein weniger Clickbait-artiger Titel hätte darauf verwiesen, dass es hier um das Viable Systems Model geht, das 1972 von Stafford Beer entwickelt wurde. Um noch mehr Klickbait einzubringen - es geht in ihm um Management-Kybernetik.

Dienstag, 28. Januar 2020

Kaizen Folder

FS
Bild: Pixabay / Vargazs - CC0 1.0
Ein von mir gecoachtes Team probiert gerade eine neue Idee aus um seine Prozessverbesserungen besser zu strukturieren und nachvollziehbarer zu machen: es legt einen Kaizen-Ordner/Kaizen Folder an. Der Hintergrund ist der, dass dort seit einigen Monaten nach Kanban gearbeitet wird und nach und nach immer weitere Verbesserungsideen erprobt werden sollen. Der Ordner soll dabei zwei Zwecke erfüllen - zum einen soll er als Archiv und Erinnerungsstütze dienen um zu verhindern, dass Erfahrungen und Erkenntnisse irgendwann in Vergessenheit geraten, zum anderen soll er es anderen Teams ermöglichen sich inspirieren zu lassen und von den bereits gemachten Erfahrungen zu profitieren.

Wie immer kann und soll das Format in Zukunft angepasst werden können wenn es nötig und sinnvoll ist, der erste Entwurf sieht aber so aus, dass das folgende Template für die im Ordner gesammelten Ideen verwendet werden wird:

Sprechender Titel
Kategorie
Problembeschreibung
Lösungshypothese
Erfolgskriterien
Umsetzung seit / von-bis
Wenn beendet: warum

Dieses Format ist zu Beginn bewusst schlicht gehalten und kann zukünftig noch ergänzt werden, beispielsweise um Metriken, Umsetzungsaufwände, betroffene Stakeholder, etc. Die Idee ist aber, dass die Struktur organisch wachsen kann, so dass sie zu Beginn nicht zu komplex oder überladen wirkt, was für die Anwender abschreckend sein könnte.

Ein Beispiel für die Anwendung wäre dieses hier:

Titel
"Ready to pull" sichtbar machen

Kategorien
Bessere Visualisierung, Besserer Arbeitsfluss

Problembeschreibung
Es ist nicht erkennbar ob die Arbeit in einer Spalte, bzw. Phase abgeschlossen ist

Lösungshypothese
Eine Drehung des Tickets um 90° ist als Kennzeichnung ausreichend

Erfolgskriterien
Keine Unsicherheiten/Diskussionen im Standup Meeting mehr

Umsetzung seit
Januar 2020

Solange es sich um Verbesserungen des physischen Kanban-Boards handelt bietet es sich an auch Fotos mit abzulegen, durch die neben der Idee auch die Art der Umsetzung besser nachvollziehbar wird. Andere Elemente die man einfügen kann wären Formatvorlagen, Erfahrungsberichte, Feedbacks oder Verweise auf zusammenhängende oder ähnliche Prozessverbesserungen. Begrenzungen gibt es hier nicht, es ist allerdings ratsam zu Beginn immer eine reduzierte Übersicht wie die oben genannte zu haben, um die relevanten Informationen schnell überblicken zu können.

Der Kaizen Folder wird in diesem Fall digital sein, was die Vorteile hat, dass parallele Zugriffe möglich sind, dass von anderen Standorten aus zugegriffen werden kann und dass eine Suchfunktion existiert. Bei Vorlieben für haptisches Arbeiten spricht aber auch nichts gegen einen physischen Ordner, der in einem Regal im Teamraum stehen kann.

Donnerstag, 23. Januar 2020

Soziale Rolle

FS
Bild: Pixabay / Sasin Tipchai - CC0 1.0
Wenn es ein zentrales Muster geben sollte das praktisch jede auf Selbstorganisation zielende Unternehmenstransition in Schwierigkeiten bringt (und viele an den Rand des Scheiterns), dann besteht es darin, dass die Verantwortlichen sich die nötigen Verhaltensänderungen der Mitarbeiter als zu einfach machbar vorstellen. Das zu realisieren ist nicht immer leicht, denn oft wird die Überzeugung, dass die Betroffenen sich ab sofort anders verhalten können, mit einer scheinbar rationalen Begründung unterlegt. Schauen wir sie uns an.

"In ihrer Freizeit kommen die doch mit komplexen Herausforderungen auch problemlos klar. Die leiten Vereine, organisieren ihre Familien, renovieren ihre Häuser und erziehen ihre Kinder. Verglichen damit ist es doch gar nicht schwer auf der Arbeit ein bisschen mitzudenken und Verantwortung zu übernehmen." Derartige Aussagen klingen im ersten Moment zwar total logisch, umsetzen lassen sie sich aber nicht so einfach. Der Grund dafür liegt in der Psychologie.

In der Sozialpsychologie geht man davon aus, dass es ein Phänomen gibt, dass sich "Soziale Rolle" nennt. Ihm zufolge hat das Verhalten das wir anderen Menschen gegenüber an den Tag legen Züge eines Schauspiels. Je nachdem wer das aktuelle "Publikum" ist werden in ihm unterschiedliche Rollen eingenommen. Das kann jeder an sich selbst überprüfen: den Eltern gegenüber tritt man anders auf als dem Ehepartner, dem gegenüber wieder anders als den Arbeitskollegen, etc.

Die Ausgestaltung dieser Rollen erfolgt dabei nur in seltenen Fällen bewusst. In der Regel erfolgt sie durch "Sozialisation", also durch das unbewusste Erlernen der von aussen herangetragenen Erwartungshaltungen, Normen und Reaktionsmuster und das ebenso unbewusste Entwickeln der eigenen Bereitschaft sich diesen externen Faktoren anzupassen oder ihnen aktiv oder passiv zuwiderzuhandeln. Den meisten Menschen ist all das nicht bewusst. Gefragt nach den Gründen für ihr Verhalten antworten sie mit "Ich bin halt so". Es erscheint ihnen normal.

Vor diesem Hintergrund wird auch klar warum die Aufforderung sich im Beruf genauso selbstständig zu verhalten wie im Privatleben nicht so einfach umsetzbar ist. Um eine jahre- oder jahrzehntelange Prägung abzulegen muss man sich ihrer zunächst bewusst sein, muss dann bereit sein an ihr zu arbeiten (was sich zunächst komisch oder unangenehm anfühlen kann) und muss sich zuletzt regelmässig reflektierend hinterfragen um eine unbewusste Erosion der Veränderungen zu verhindern.

Das heisst natürlich nicht, dass Verhaltensänderungen nicht möglich wären. Sie sind es, und sie können bemerkenswerte Energien freisetzen. Sie kommen aber nicht von jetzt auf gleich.

Montag, 20. Januar 2020

240 agile Zertifizierungen

FS
Bild: Flickr / Dennis Wong - CC BY 2.0
Ohne Wertung und ohne Anspruch auf Vollständigkeit.

Organisation Zertifizierungen Auflistung
International Consortium for Agile 28
  • Agile Fundamentals
  • Agile Team Facilitation
  • Agile Coaching
  • Expert in Agile Coaching
  • Agile Programming
  • Agile Software Design
  • Expert in Agile Engineering
  • Agile Testing
  • Agile Test Automation
  • Expert in Agile Testing
  • Business Agility Foundations
  • Agile Talent
  • Agile Finance
  • Agile Leadership
  • Agile Marketing
  • Expert in Business Agility
  • Foundation of DevOps
  • Implementing DevOps
  • Expert in DevOps
  • Agile Project and Delivery Management
  • Delivery at Scale
  • Expert in Delivery Management
  • Agile in the Enterprise
  • Coaching Agile Transitions
  • Expert in Enterprise Coaching
  • Agile Product Ownership
  • Enterprise Product Ownership
  • Expert in Product Ownership
International Council for Certification and Accreditation 16
  • Certified Agile Foundation
  • Certified Agile Practitioner
  • Certified Agile Expert
  • Certified Agile Auditor
  • Certified Agile Coach
  • Scrum Foundation Certified
  • Certified Scrum Master Practitioner
  • Certified Scrum Product Owner Practitioner
  • Certified Scrum Developer Practitioner
  • Certified Scrum Expert
  • Certified Scrum Auditor
  • Certified Scrum Coach
  • Certified DevOps Foundation
  • Certified DevOps Manager
  • Certified DevOps Expert
  • Certified DevOps Tester
Scaled Agile Framework 13
  • SAFe Agilist
  • SAFe Practitioner
  • SAFe Program Consultant
  • SAFe Scrum Master
  • SAFe Advanced Scrum Master
  • SAFe Release Train Engineer
  • SAFe Product Owner/Product Manager
  • SAFe DevOps Practitioner
  • SAFe for Government
  • SAFe Agile Software Engineering
  • SAFe for Architects
  • Lean Portfolio Management
  • Agile Product and Solution Management
Scrum Alliance 12
  • Certified Scrum Master
  • Advanced Certified Scrum Master
  • Certified Scrum Professional-Scrum Master
  • Certified Scrum Product Owner
  • Advanced Certified Scrum Product Owner
  • Certified Scrum Professional-Product Owner
  • Certified Scrum Developer
  • Certified Scrum Professional for Developers
  • Certified Team Coach
  • Certified Enterprise Coach
  • Certified Scrum Trainer
  • Certified Agile Leadership I
  • Certified Agile Leadership II
International DevOps Certification Academy 12
  • Certified DevOps Generalist
  • Certified DevOps Executive
  • Certified DevOps Project Manager
  • Certified DevOps Product Owner
  • Certified DevOps Architect
  • Certified DevOps Developer
  • Certified DevOps Operations Engineer
  • Certified DevOps Quality Assurance Engineer
  • Certified DevOps Information Security Engineer
  • Certified DevOps Release Manager
  • Certified DevOps Trainer
  • Certified DevOps Coach
Scrum.org 11
  • Professional Scrum Master I
  • Professional Scrum Master II
  • Professional Scrum Master III
  • Professional Scrum Product Owner I
  • Professional Scrum Product Owner II
  • Professional Scrum Product Owner III
  • Professional Scrum Developer
  • Scaled Professional Scrum
  • Professional Scrum with Kanban
  • Professional Scrum with User Experience
  • Professional Agile Leadership
Scrum Institute 10
  • Scrum Master Accredited Certification
  • Scrum Product Owner Accredited Certification
  • Scaled Scrum Expert Accredited Certification
  • Agile Scrum Leadership (Executive) Accredited Certification
  • Scrum Trainer Accredited Certification
  • Scrum Coach Accredited Certification
  • Scrum Team Member Accredited Certification
  • Scrum Certification for Java Developer
  • Scrum Certification for Web Developer
  • Scrum Certification for Mobile App Developer
Scrumstudy 10
  • Scrum Fundamentals Certified
  • Scrum Developer Certified
  • Scrum Master Certified
  • Scaled Scrum Master Certified
  • ScrumStudy Agile Master Certified
  • Scrum Product Owner Certified
  • Scaled Scrum Product Owner Certified
  • Expert Scrum Master Certified
  • Scrumstudy Certified Trainer
  • Scrumstudy Certified Agile Coach
DevOps Institute 8
  • DevOps Foundation
  • Site Reliability Engineering Foundation
  • DevOps Leader
  • DevSecOps Engineering
  • Continuous Delivery Architecture
  • DevOps Test Engineering
  • Certified Agile Service Manager
  • Certified Agile Product Owner
EXIN 8
  • EXIN Agile Scrum Foundation
  • EXIN Agile Scrum Master
  • EXIN Agile Scrum Product Owner
  • EXIN Agile Scrum Product Owner Bridge
  • EXIN Agile Coach
  • EXIN DevOps Foundation
  • EXIN DevOps Professional
  • EXIN DevOps Master
APM Group International 7
  • Agile Digital Services Foundation
  • Agile Digital Services Practitioner
  • Agile Programme Management
  • Agile Project Management
  • Agile Business Analyst Foundation
  • Agile Business Analyst Practitioner
  • Agile Change Agent
DevOps Agile Skills Association 7
  • DASA DevOps Fundamentals
  • DASA DevOps Professional Enable and Scale
  • DASA DevOps Professional Specify and Verify
  • DASA DevOps Professional Create and Deliver
  • DASA DevOps Product Owner
  • DASA DevOps Leader
  • DASA DevOps Coach
Scrum Agile Institute 7
  • Scrum Master Certified
  • Scrum Product Owner Certified
  • Scrum Developer Certified
  • Scrum Master Instructor
  • Product Owner Instructor
  • Scrum Developer Instructor
  • Scrum Mentor
Industrie- und Handelskammern1 7
  • Agiler Projektmanager IHK
  • Agiler Personalentwickler IHK
  • Agiler Business Coach IHK
  • Trained Facilitator "Agile Methoden" IHK
  • Agiler Teamcoach IHK
  • Agile Führungskraft IHK
  • Agiler Mindsetter IHK
Project Management Institute2 6
  • PMI Agile Certified Practitioner
  • Certified Disciplined Agilist
  • Certified Disciplined Agile Practitioner,
  • Disciplined Agile Lean Scrum Master
  • Certified Disciplined Agile Coach
  • Certified Disciplined Agile Instructor
EuropeanScrum.org 6
  • Expert Scrum Foundations
  • Expert Scrum Master
  • Expert Product Owner
  • Expert Agile Methodologies
  • Expert Agile Coach
  • Expert Scrum Trainer
Lean Kanban University 6
  • Team Kanban Practitioner
  • Kanban Management Professional
  • Kanban Coaching Professional
  • Accredited Kanban Consultant
  • Accredited Kanban Trainer
  • Enterprise Kanban Coach
OpenSpace Agility Framework 6
  • Open Space Practitioner Level 1
  • Open Space Practitioner Level 2
  • OpenSpace Agility Professional Level 1
  • OpenSpace Agility Professional Level 2
  • OpenSpace Agility Certified Instructor
  • OpenSpace Agility Certified Trainer
IT Service Management Academy 6
  • Certified Agile Service Manager
  • Certified Agile Process Owner
  • Certified Process Design Engineer
  • DevOps Foundation Accredited
  • DevOps Continuous Delivery Architecture
  • DevOps Test Engineering
Large Scale Scrum3 5
  • Certified LeSS Basics
  • Certified LeSS Practitioner
  • Certified LeSS for Executives
  • Certified LeSS Trainer
  • LeSS-Friendly Scrum Trainer
Scrum Inc 5
  • Licensed Scrum Master
  • Licensed Scrum Product Owner
  • Licensed Scrum Team Member
  • Licensed Scrum Trainer
  • Licensed Agile Coach
Lean IT Association 4
  • LITA Foundation
  • LITA Kaizen
  • LITA Leadership
  • LITA Lean IT Coach
British Computer Society - The Chartered Institute for IT 4
  • BCS Foundation Certificate in Agile
  • BCS Practitioner Certificate in Agile
  • BCS Professional Certificate in Agile Business Analysis
  • BCS DevOps Certification
Agile Marketing Academy 4
  • Certified Agile Marketing Specialist
  • Certified Agile Marketing Practitioner
  • Certified Agile Marketing Coach
  • Certified Agile Marketing Trainer
Axelos 3
  • Prince2 Agile Foundation
  • Prince2 Agile Practitioner
  • AgileShift Certification
Flight Level Kanban Academy 3
  • Flight Levels Systems Architecture
  • Flight Levels Interaction Designs
  • Flight Levels Coach
AgilityHealth 3
  • Certified AgilityHealth Facilitator
  • Enterprise Business Agility Strategist
  • Certified Agile HR & Talent Strategist
International Software Quality Institute 3
  • iSQI Certified Agile Essential
  • iSQI Scrum Master Pro
  • iSQI Certified Agile Business Analysis
International Association of Project Managers 3
  • Certified Junior Agile Project Manager IAPM
  • Certified Agile Project Manager IAPM
  • Certified Senior Agile Project Manager IAPM
TÜV 3
  • Scrum Foundation Zertifikat
  • Scrum Master Zertifikat
  • Product Owner Zertifikat
Universität Köln 2
  • Basic Agile Master
  • Systemic Agile Master & Coach
Simplilearn 2
  • Agile Scrum Foundation
  • Agile Scrum Master
International Software Testing Qualifications Board 2
  • Foundation Level Agile Tester
  • Advanced Level Agile Technical Tester
International Requirements Engineering Board 2
  • Re@Agile
  • Re@Agile Advanced Level
International Project Management Association 2
  • Certified Agile Project Management
  • Agile Leadership Certification
EduScrum 1
  • EduScrum-Zertifikat
International Business and Quality Management Institute 1
  • Certified Kanban Coach
Agile Business Consortium 1
  • Agile Business Consortium Scrum Master
Scrum@Scale 1
  • Scrum@Scale Practitioner
1Zertifizierungslehrgänge verschiedener Kammern
2Inclusive der fünf Zertifizierungen von Discipled Agile Delivery (wurde 2019 von PMI gekauft)
3Der LeSS-Friendly Scrum Trainer ist eine Erweiterung des Certified Scrum Trainer der Scrum Alliance
Powered by Blogger.