240 agile Zertifizierungen

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

¹Zertifizierungslehrgänge verschiedener Kammern
²Inclusive der fünf Zertifizierungen von Discipled Agile Delivery (wurde 2019 von PMI gekauft)
³Der LeSS-Friendly Scrum Trainer ist eine Erweiterung des Certified Scrum Trainer der Scrum Alliance

Lean Procurement Canvas

Es ist immer wieder erstaunlich wie viele verschiedene Canvasse (ist das der Plural von Canvas?) es mittlerweile gibt. Diesesmal ist es der Lean Procurement Canvas, der aber eine Besonderheit mit sich bringt: laut seinem Erfinder Mirko Kleiner kann er nicht nur zur Themenfindung benutzt werden sondern sogar den Vertrag zwischen Anbieter und Käufer ersetzen - zumindest in der Schweiz. Es wäre interessant zu sehen ob das in Deutschland auch so ist.



Dankenswerterweise ist er mit einer CC BY-SA 4.0-Lizenz für die Weiterverbreitung freigegeben.

Wir müssen uns den Scrum Master als glücklichen Menschen vorstellen

Bild: Pixabay / Mohamed Hassan - CC0 1.0

Wenn irgendwo Scrum neu eingeführt wird nimmt das Gespräch häufig eine unerwartete Wendung. Zu Beginn folgt fast immer die Frage ab wenn der Scrum Master denn nicht mehr benötigt wird - irgendwann hat das Team schliesslich Scrum gelernt und die Impediments sind weg. Die Antwort darauf: nie. Scrum erodiert mit der Zeit und muss immer wieder neu aufgfrischt werden, und Impediments erweisen sich als "nachwachsender Rohstoff". An dieser Stelle kann die Skepsis gegenüber dieser Rolle in Mitleid umschlagen. "Dann muss der ja immer wieder von vorne anfangen. Was für eine Sisyphos-Arbeit!"

Warum diese Beschreibung zwar richtig, Mitleid dennoch fehl am Platz ist erschliesst sich bei einer kurzen Recherche. Wer war dieser Sisyphos von dem hier die Rede ist? Es handelt sich um einen sagenhaften griechischen König, der von den Göttern für frevelhaftes Verhalten hart bestraft wurde. Für alle Ewigkeit muss er einen Fels einen Berg hinaufrollen, der ihm dann aber jedesmal kurz vor dem Gipfel entgleitet und zurückrollt. Immer rund immer wieder. Aber wie gesagt, Mitleid ist dennoch fehl am Platz.

Diese scheibar widersinnige Aussage lässt sich zurückführen auf Albert Camus, einen der wichtigsten Philosophen des 20. Jahrhunderts und sein Werk "Der Mythos des Sisyphos". Camus geht in ihm davon aus, dass die Vergänglichkeit aller Dinge das Leben sinnlos macht. Egal was die Menschen tun, egal was sie vollbringen, es gibt ihrem Dasein nur für eine kurze, beschränkte Zeit einen Sinn, der danach wieder in sich zusammenfällt. Der Einzige der dieser Absurdität entgeht ist eben Sisyphos, der als Einziger eine Aufgabe von Dauer hat in der er aufgehen und dauerhafte Erfüllung finden kann.

Jedes mineralische Aufblitzen in diesem in Nacht gehüllten Berg ist eine Welt für sich. Der Kampf gegen Gipfel vermag ein Menschenherz auszufüllen. Wir müssen uns Sisyphos als einen glücklichen Menschen vorstellen.

Albert Camus, Der Mythos des Sisyphos

An dieser Stelle kommen wir zurück zum Scrum Master. Auch er gehört zu den wenigen Menschen seiner Unternehmung deren Bestimmung eine dauerhafte ist. Er hat kein Produkt dessen Lebenszyklus irgendwann zu Ende ist, keine Karriere die früher oder später ihren Endpunkt erreicht, keine Tätigkeit die der technische oder der gesellschaftliche Fortschritt irgendwann obsolet machen werden. So lange sich Komplexität und Entropie gegenseitig bedingen wird er seine Berufung haben.

Für viele Menschen ist diese Vorstellung eine furchtbare. Ein Leben das man mit den Worten Karl Scheffler beschreiben könnte - immer werden niemals sein - das soll erstrebenswert sein? Ja, ist es, wenn man bereit ist sich darauf einzulassen. Zu akzeptieren, dass ständige Veränderungen unvermeidbar sind ermöglicht eine Neuausrichtung der eigenen Ziele. Statt Sicherheit und Stabilität anzustreben und immer wieder daran zu scheitern ermöglicht das ständige Willkommenheissen und und Bewältigen von Veränderungen ständige Erfolgserlebnisse. Das alte konfuzianische Motto, dass der Weg das Ziel ist, wird so mit Leben gefüllt. Oder, frei nach Camus:

Wir müssen uns den Scrum Master als einen glücklichen Menschen vorstellen.

Altsysteme

Der Spiegel hat es getan. Das grosse alte Flaggschiff der deutschen Medienlandschaft hat sich von seinen historischen Hinterlassenschaften befreit und seine digitalen Auftritte einem Relaunch unterzogen. In beispielhafter Tranzparenz wurde dabei nicht nur kommuniziert wie das methodisch vor sich gegangen ist sondern auch was die Probleme waren die man damit hinter sich lassen will. Und das waren einige (Informationen aus diesen Quellen: 1, 2, 3).

• Das bisherige Redaktionssystem Content Entry war zu einer Zeit selbst gebaut worden als es auf dem Markt kein gutes CMS zu kaufen gab (vermutlich um das Jahr 2000 herum, von den ursprünglichen Entwicklern dürfte damit kaum noch einer da sein)
• Moderne App-Development-Frameworks waren nicht einsetzbar (was es schwer gemacht haben dürfte neue Entwickler an Bord zu holen)
• Das alte System war nicht lauffähig auf aktuellen Browsern, weshalb mit einer alten Version des Internet-Explorers gearbeitet werden musste (für die es vermutlich keinen Hersteller-Support mehr gab)
• Die erstellten Websites waren nicht responsiv (im Zeitalter der mobilen Internetnutzung ein Problem)
• Die Mobile Apps hatten eine überproportionale Dateigrösse (was für Probleme bei Download und Speicherplatz sorgt)
• Änderungen, z.B. im strategisch wichtigen Bezahlbereich, waren nur noch schwer zu implementieren (dadurch behindert die IT die Geschäftsentwicklung)
• Selbst im Normalbetrieb waren die Systeme fehleranfällig (also ressourcenbindend und teuer)
• Andere Medien des Unternehmens (Manager Magazin, Bento) liefen auf eigenen CMS-Varianten, wodurch sich Instandhaltung- und Erneuerungsaufwände nochmal multiplizierten 

Man kann an dieser Übersicht sehen, dass der Zustand der alten Anwendungen ein starkes Hindernis für realistische Planung, strukturiertes Arbeiten, schnelle Reaktionsfähigkeit und geregelten Betrieb gewesen sein dürfte. Wer schon in derartig "historisch gewachsenen" Systemen gearbeitet hat kennt die Phänomene die dort gehäuft auftreten: erratisches Verhalten der Software, veraltete Dokumentation, viele Abhängigkeiten, fehlende Kompatibilität mit modernen Standards, fehlende Testabdeckung, Störung des Arbeitsflusses durch Bugfixes und Hotfixes, Stabilisierungsphasen nach jedem Release.

Derartige Zustände sind Nichts was den Fall des Spiegels zu etwas Besonderem gemacht haben, sie finden sich in nahezu jedem grösseren Unternehmen wieder. Bei vielen Konzernen sind sie sogar wesentlich stärker ausgeprägt, da hier zentrale Anwendungen (Warenwirtschaftssysteme, Kernbankensysteme,  ERP-Systeme, etc.) noch aus den 90er oder 80er Jahren kommen. In diesen Fällen sind die oben genannten Probleme oft so gravierend, dass selbst kleine Modifikationen die gesamte Arbeitskapazität der IT-Ressorts über Monate hinweg in Anspruch nehmen. Produktinnovationen werden so nahezu unmöglich, zumindest aber unwirtschaftlich.

Der Spiegel hat mit dem Relaunch also das einzig Richtige gemacht. Zu dieser Geschichte gehört aber auch, dass sie trotzdem langwierig und teuer gewesen sein dürfte. Das Ablösungsprojekt "NextGen" hat ganze drei Jahre gedauert, in denen die Neuentwicklung parallel zum Betrieb der "alten Welt" gelaufen ist. Die noch bessere Lösung wäre eine früh begonnene und kontinuierliche Modernisierung gewesen, die dafür gesorgt hätte, dass der Problem-Rückstau gar nicht erst entsteht (Stichwort organisatorische Schulden). Man kann dem Spiegel nur wünschen, dass das ab jetzt geschieht.

The agile Bookshelf: The Watchman's Rattle

Bild: Wikimedia Commons / Nxr-at - CC BY-SA 4.0

Alleine der Titel des Buches klingt bereits vielversprechend. "The Watchman's Rattle: A Radical New Theory of Collapse" hat Rebecca D. Costa ihr bisher einziges Buch genannt. Es ist zwar kein Werk das sich um Agilität im engeren Sinne dreht, es hat aber ein Hauptthema das ursächlich dafür ist, dass die agilen Ansätze überhaupt erst entstanden sind: Komplexität. Wie sie entsteht, welche Auswirkungen sie hat und welche Folgen.

Ausgangspunkt ist eine erstaunlich naheliegende Annahme: das menschliche Gehirn ist von der Natur nicht für die Bewältigung grosser Komplexität entwickelt worden. In den ca. sechs Millionen Jahren in denen der Mensch sich aus dem Affen entwickelt hat sind die Herausforderungen grösstenteils sehr schlicht gewesen. Essen finden, sich vor Tieren schützen, mit dem eigenen Stamm interagieren. Komplexität in Kultur und Gesellschaft entwickelte sich erst vor etwa 10.000 Jahren und hochkomplexe Systeme erst seit der industriellen Revolution vor etwa 200 Jahren. Die menschliche Evolution kann mit dieser Geschwindigkeit nicht mithalten.

Im Buch sind zahlreiche Beispiele für das Scheitern der Menschheit an zu hoher Komplexität aufgeführt, am prominentesten der Untergang der Römer, Maya und Khmer. Auch Erklärungen werden mitgeliefert, im Wesentlichen abgeleitet aus Biologie und Evolution. Fettleibigkeit mitsamt der damit verbundenen persönlichen und gesamtgesellschaftlichen Nachteile beruht auf Jagd- und Fresstrieben, fehlendes Denken über den Tellerrand hinaus entsteht aus der Revierverteidigung, das Überlagern langfristiger Planung durch kurzfristige Handlungen ist darauf zurückzuführen, dass der tägliche Überlebenskampf wichtiger war als alles andere, etc.

Abgeleitet aus diesen grundlegenden Überlegungen identifiziert Costa fünf verbreitete Handlungsmuster, die ursächlich für das Scheitern an komplexen Herausforderungen sind: destruktive Kritik statt Finden von Alternativen, Suche nach Schuldigen statt nach Lösungen, Überbewertung von Korrelationen (und deren Verwechselung mit Kausalitäten), Silo-Denken ohne Berücksichtigung systemischer Zusammenhänge und die Höherbewertung von wirtschaftlichem Erfolg über dem Wohlergehen von Natur und Mitmenschen.

Wie immer wenn Komplexität ernsthaft behandelt wird gibt es auch hier keine einfachen Lösungen. Was Costa bieten kann sind: langfristig wachsende Probleme identifizieren so lange sie noch nicht drängend sind, das Verzögern von Problemfolgen nicht mit dem Lösen von Problemen verwechseln, vielschichtige Probleme nicht mit einzelnen oder einfachen Lösungen bekämpfen, Lösungsmassnahmen regelmässig überprüfen und bei Bedarf an die mittlerweile gewonnenen Erkenntnisse anpassen.

Insgesamt enthält das Buch zwar nichts revolutionär Neues, es gelingt ihm aber viele Informationen so zusammenzutragen und zueinander in Bezug zu setzen, dass ein neuer, unkonventioneller Blick auf die anstehenden Herausforderungen entsteht. Gleichzeitig findet sich an seinem Ende ein beeindruckend grosses Literatur- und Quellenverzeichnis, das genug weiterführenden Stoff für das ganze Jahr bieten dürfte.

10 Dos und Don'ts einer Scrum Master-Stellenausschreibung

Bild: Flickr / Mr. Blue MauMau - CC BY 2.0

Über die Jahre bin ich bei mehreren Kunden daran beteiligt gewesen Stellenausschreibungen für Scrum Master zu erstellen, die ich dann auch auf lokalen Community-Meetups vorgestellt habe. Basierend auf dem Feedback (und eigener Expertise) sind hier einige Ratschläge:

1. Scrum nicht komplett in Grossbuchstaben schreiben (und schon gar nicht mit Punkten dazwischen)

Es ist einer der grossen Klassiker: "Gesucht wird ein SCRUM Master für ein SCRUM-Team". Das Problem - dem Bewerber wird dadurch sofort klar, dass man sich hier nur sehr oberflächlich mit der Methodik beschäftigt hat. Scrum ist ein Eigenname und keine Abkürzung, weshalb auch erst recht die Variante S.C.R.U.M. nicht benutzt werden sollte.

2. Seriöse Sprache benutzen

Für die meisten Firmen ist Scrum etwas Neues und damit auch gefühlt mit Jugendlichkeit verbunden. Wird das versucht auf die Sprache zu übertragen wirkt das schnell anbiedernd und peinlich. (Pseudo-)Jugendsprache, schlimmstenfalls gemischt mit deutsch-englischem Kauderwelsch zieht niemanden an. Also bitte kein "Booste die Performance Deiner Crew" und kein "Du hast Bock auf Agile?"

3. Methodische "Anpassungen" kommunizieren

 Wer die Scrum Master-Rolle so verändert oder mit Zusatzaufgaben versehen hat, dass sie sich vom Standard stark unterscheidet, sollte das schon in der Ausschreibung klar machen. Wenn das nicht passiert setzt schnell das grosse Staunen ein warum denn alle Neueinstellungen schon in der Probezeit kündigen. Wir reden schliesslich von gesuchten Fachkräften, die schnell etwas anderes finden.

4. Keine Selbstverständlichkeiten aufzählen

"Zu Deinen Aufgaben gehören das Vermitteln von Scrum und die Beseitigung von Impediments". Das ist richtig, es braucht aber nicht erwähnt zu werden. Der Scrum Guide liefert eine klare Stellenbeschreibung, die jeder der in diesem Job arbeitet kennen muss. Dass nochmal zu wiederholen kostet entweder knappen Platz oder bläht den Text unnötig auf. Zur Not reicht: "Deine Tätigkeiten sind die aus dem Scrum Guide".

5. Klar sagen welche agilen Praktiken schon eingesetzt werden und welche noch nicht

"Du stehst auf DevOps, CI/CD und TDD? Dann bist Du hier richtig." Wer so eine Ansage macht muss dann auch liefern, sonst setzt schnell das grosse Staunen ein (siehe oben). Wenn es aber tatsächlich so ist, dass das schon gelebt wird, dann ist das ein Differenzierungsmerkmal das auf jeden Fall genannt werden sollte. Damit zieht man die richtigen Leute an.

6. Keine technischen Skills verlangen (auch nicht für Jobs in IT-Teams)

"Erforderlich ist Expertise in Java, C# und Oracle PL/ SQL". Kann man so schreiben, allerdings trifft dann das Gleiche zu wie bei der Schreibweise SCRUM: dem Bewerber wird dadurch sofort klar, dass man sich hier nur sehr oberflächlich mit der Methodik beschäftigt hat. Der Scrum Master entwickelt selbst keine Software, er braucht diese Skills nicht.

7. Herausforderungen ehrlich benennen

Veränderungsprozesse können anstrengend sein, und wenn das der Fall ist, dann ist auch der Job des Scrum Masters anstrengend. Das muss nicht abschreckend sein, manche suchen nach einer derartigen Herausforderung. Manche aber auch nicht, die entwickeln dann auch keine Wirkung. Um den Richtigen zu bekommen hilft es, klar zu sagen womit man zu rechnen hat wenn man unterschreibt.

8. Kommunizieren ob es verteilte Teams und Heimarbeit gibt

Scrum läuft vor allem dann gut wenn das gesamte Team fünf Tage die Woche in einem Raum zusammensitzt. Sonst wird die Kommunikation ineffektiv und Information Radiators funktionieren nicht mehr. Wenn das nicht gegeben ist (warum auch immer) sollte das vorher klar sein, für viele Scrum Master wäre das ein Kündigungsgrund.

9. Klar machen ob es ein Scaled Agile-Kontext ist

Egal ob LeSS, Nexus, SAFe oder Flight Level-Kanban - sobald ein Scrum Team Teil von einem Projekt oder einer Abteilung ist in der Skalierungsframeworks eingesetzt werden verändern sich die Aufgaben eines Scrum Masters. Das ist nicht gut oder schlecht, es ist aber etwas das manche machen wollen und andere nicht. Darum sollte das von Anfang an transparent sein.

10. Keine Zertifizierungen verlangen

Ein Zertifikat kann den Eindruck erwecken, dass man einen Fachmann vor sich hat. Diese Annahme ist falsch. Obwohl es gute Zertifizierungskurse gibt hat die damit verbundene Industrie einen zwielichtigen Ruf und wird von vielen Scrum Mastern abgelehnt. Wer auf Zertifizierungen beharrt schneidet sich von vielen guten Kandidaten ab.

---

Ich habe diese Punkte schon oft auf der Tonspur weitergegeben und dabei manchmal irritierte Rückmeldungen bekommen: diese Dos und Don'ts wären zu spezifisch. Ob z.B. das Vorgehen angepasst wurde, welche Praktiken eingesetzt werden und welche Herausforderungen bestehen liesse sich doch aus HR-Sicht gar nicht beurteilen. In solchen Fällen gebe ich einen elften Ratschlag - bei derartigen Ausschreibungen kann man sich auch helfen lassen.

Kommentierte Links (LVII)

Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.

• Mary Poppendieck: Grown-Up Lean

  Den längsten Essay gleich zu Beginn, und gleichzeitig auch den optimistischsten. Belegt mit vielen Beispielen (Toyota, Linux, Google, Amazon, SpaceX, ING, Spark NZ) schlägt Mary Poppendieck den grossen Bogen von den 80ern bis heute und zeigt auf, dass das was wir heute als Agile oder DevOps bezeichnen seine Ursprünge im Lean Management der japanischen Fabriken des 20. Jahrhunderts hat. Gleichzeitig wirkt sie auch einem verbreiteten Missverständnis entgegen, nämlich dem, dass es in Lean in erster Linie um Effizienzsteigerung, bzw. um die Vermeidung nicht zielführender Tätigkeiten ginge. Als zentrales Element stellt sie die Humanzentrierung heraus, also das in den Mittelpunkt Stellen des Mitarbeiters. Durch Product Ownership, durch dienendes Management, durch die Demokratisierung der Produktionsprozesse. Und als wäre all das nicht schon lesenswert genug beginnt sie ihre Ausführungen mit einer Anekdote aus Deutschland.

• Gunter Dueck: How to innovate if you must

  Trotz des englischen Titels ein deutscher Text, und mal wieder ein echter Dueck. Mit im Verlauf des Artikels zunehmendem Sarkasmus seziert er die Fehler, die die Konzerne seit 30 Jahren bei der Digitalisierung und Agilisierung ihres Geschäfts machen. Zusammengefasst: viel Fassade, viel Hochmut, wenig Mut, wenig Bereitschaft sich auf Neues einzulassen. Das ist nicht falsch (und wird auch hier mit vielen bekannten und neuen Beispielen unterfüttert), lässt aber unerwähnt, dass selbst Konzernvorstände weniger frei in ihren Entscheidungen sind als man denken sollte. Von den Aktionären bis zum Betriebsrat will so ziemlich jeder mitreden. Grundsätzlich hat Dueck aber Recht - ein bisschen mehr ginge immer. Und die Anekdote, dass IBM Google Maps hätte vorwegnehmen können, es aber nicht gemacht hat, hat Potential zum Klassiker.
  

• Steve Denning: Why Budgeting Kills Agile And Innovation

"Die Budgetierung stellt häufig einen der letzten - und grössten - Stolpersteine auf dem Weg zu einer wirklich agilen Organisation dar", lautet gleich der erste Satz von Steve Dennings Streitschrift. Trotz dieses Auftaktes geht es dann aber strukturiert durch verschiedene Argumentationsphasen. Die historischen Hintergründe, die theoretisch möglichen Vorteile klassischer Budgetprozesse, die in der Realität auftretenden Nachteile und zuletzt die grosse Alternative: Beyond Budgeting. Geschrieben ist das aus einer US-amerikanischen Perspektive, aus einer deutschen/europäischen dürfte es sogar noch schlimmer sein. Die Kombination aus übertriebenem Taylorismus (die Mitarbeiter sind so spezialisiert, dass sie nur noch an einer spezifischen Stelle einsetzbar sind) und einem de facto Kündigungsschutz führt dazu, dass häufig nur noch der Schein von Handlungsfähigkeit entsteht. in Wirklichkeit wird das Geld jedes Jahr auf die selbe Art ausgegeben - das Gegenteil von Business Agility..

• Alistair Cockburn: Agile is not dead, quite the opposite

  In der Produkt-, Projekt- und Prozessmanagement-Filterblase kann man leicht den Eindruck gewinnen, dass die agile Bewegung die Gegenwart dominiert, vielleicht sogar so sehr, dass es zu Sellout und Overkill kommt. Die Zahlen die Alistair Cockburn anführt legen etwas anderes nahe: angesichts von hunderten Millionen von Menschen in der Wissensarbeit (davon viele aber keineswegs alle in der IT) fallen die wenigen Millionen die bereits mit dem Thema Agile in Berührung gekommen sind kaum ins Gewicht. Der Bewegung steht ihre eigentliche Wachstumsphase also noch bevor. Dass das in der Öffentlichkeit oft anders dargestellt wird macht Cockburn daran fest, dass diese Mengenverteilung nicht allen bewusst ist. Als die Untergangspropheten der Agilität sieht er jene, die schon vor 10 und mehr Jahren begonnen haben so zu arbeiten. Für die scheint sich der Lebenszyklus dieser Idee dem Ende entgegenzuneigen. Dass sie aber keineswegs repräsentativ sind sollte man im Hinterkopf behalten. Ein wertvoller Beitrag, den man sich in Erinnerung rufen sollte wenn mal wieder jemand "Agile is dead" propagiert.

• Yuri Malishenko: Agile transformation is a bad story and here is why

  Ein lesenswerter Text, hinter dem sich mehr verbirgt als man anhand der Clickbait-Überschrift ahnen könnte. Basierend auf dem Actantial Model von Algirdas Julien Greimas versucht Yuri Malishenko darzustellen mit welchen Betrachtungsweisen und Erwartungshaltungen sich verschiedene Gruppen (Management, Agile Coaches, Mitarbeiter) einer agilen Transition nähern. Die wenig überraschende Erkenntnis: sie sind nicht identisch sondern weichen z.T. stark voneinander ab. Das Interessante daran: mit Hilfe des Actantial Model ist es möglich diese Interessenkonflikte aufzuzeigen und zu visualisieren. Im Fall strauchelnder Veränderungsvorhaben könnte das ein wertvolles Werkzeug sein um aufzuzeigen wo die Beteiligten aneinandervorbeireden.

• Stefan Kühl: Zur Entstehung, Durchsetzung und Regulierung von Regelabweichungen

  Ich muss mich wohl korrigieren. Vermutlich hat nicht Mary Poppendieck den längsten Beitrag in dieser Liste sondern Stefan Kühl. Dass das nicht ganz klar zu sagen ist liegt daran, dass ein nicht unwesentlicher Teil des Textes aus dem Quellenverzeichnis besteht, was ein deutlicher Hinweis darauf ist, dass hier wissenschaftlich gearbeitet wurde. Die in diesem Zusammenhang behandelte zentrale These ist die, dass Gesetzesbrüche und Regelverstösse in Organisationen meistens nicht auf Schlampigkeit oder Indifferenz zurückgehen sondern das Ergebnis von rationalem Abwägen sind. Die Verstösse werden nur in dem Rahmen betrieben, der eine Erkennung oder Sanktionierung unwahrscheinlich macht - und dieser Rahmen wird durch ständiges Ausprobieren erkundet und ausgereizt. Im Grunde ein Inspect & Adapt mit dem Ziel einer möglichst effektiven brauchbaren Illegalität. Bedingt durch diese Brauchbarkeit ergibt sich implizit eine weitere Dimension der Erziehung zur Normverletzung: die Etablierung der Abweichung von Regeln als organisationskulturelle Erwartung. Führt man sich die in aller Konsequenz vor Augen kann einem schwindelig werden.

• Greg Satell: True Transformation Isn’t Top-Down Or Bottom-Up, But Side-To-Side

  Das hier ist ein ähnlicher Beitrag wie der von Marcus Raitner, den ich vorgestern verlinkt habe, wenn auch mit unterschiedlichen Nuancen. Greg Satell sieht das Modell der "viralen Verbreitung" von Organisationsveränderungen nicht nur als Gegenmodell zu den Management-geführten Change-Programmen sondern auch zu den reinen Grasswurzel-Bewegungen. Darüber hinaus sieht er bei den (von ihm "Apostel" genannten) Vorreitern nicht nur die Aufgabe andere durch das Vorleben der neuen Werte und Prinzipien zu "infizieren" sondern auch sich aktiv an ihrer Verbreitung zu beteiligen, also aktiv auf andere zuzugehen. Dass das im Vergleich zu den Top-Down- und Bottom-Up-Ansätzen besser funktioniert kann er nachvollziehbar begründen: anders als jemand der die Veränderungen aus der Ferne oder aus einer anderen Hierarchieebene vorantreiben will kennt der Apostel seine unmittelbare Umgebung, wodurch er am besten abschätzen kann wer ablehnend und wer offen reagieren wird.

• Tim Themann: Von Methoden, METHODEN und MeTooden

  Eine schöne Differenzierung. Angelehnt an Tom DeMarco und Timothy Lister unterscheidet Tim Themann zwischen Methoden (Vorgehensmodellen), METHODEN (dogmatischen Regelwerken) und MeTooden (dem Versuch ein an anderer Stelle erfolgreiches Vorgehen zu kopieren). Letzteres kann leicht in Cargo Cult abgleiten, was von Theman nochmal ausdifferenziert wird: Mismatch von Lösung und Problem, versehentlich falsche Übertragung, Unterschätzung des Einführungsaufwandes, ggf. Toolfixierung und Kontaminierung der ursprünglichen, eigentlich guten Idee. Ich würde noch den Survivor Bias hinzufügen, aber das ist nur ein Detail. Was den Charme der MeToode ausmacht ist vor allem der Begriff, der jedem der ein bisschen Englisch kann sofort intuitiv verständlich sein wird.

Kommentierte Links (LVI)

Leicht verfrüht: die Kommentierten Links des Dezember. Übermorgen mit einer weiteren Ausgabe, mit den Links die es zu Unrecht nicht in die Kommentierten Links der vergangenen Monate geschafft haben.

• Jason Little: Boundaries, Interventions, and Baby Ducks

Zum Ende des Jahrzehnts reflektiert Jason Little über die Unternehmenstransformationen die er in dieser Zeit begleiten durfte. Dabei identifiziert er drei Konzepte die man sich bei derartigen Vorhaben vor Augen führen sollte:

• Interventions-Punkte - Es gibt gute und schlechte Momente um Veränderungen anzustossen. Gut ist z.B. vor oder während der Planung des nächsten Jahres, schlecht unmittelbar danach.
• Einfluss-Sphären - Wo sind Prozesse und Strukturen selbst verantwortet und gestaltbar und wo sind sie es nicht? Und dort wo sie es nicht sind: würde sich der dort verantwortliche an Veränderungen beteiligen?
• Entenküken-Syndrom - Genau wie Entenküken zu den ersten von ihnen wahrgenommenen Wesen eine starke emotionale Bindung entwickeln können Menschen vergleichbare Bindungen zu Programmiersprachen, Management-Ansätzen, etc. entwickeln.
Während die ersten beiden Konzepte weitgehender Common Sense sein dürfte ist das das dritte eines das selten bedacht wird. Eine Gesetzmässigkeit kann man sicher nicht ableiten, einige Überlegungen ist es aber definitiv wert, sowohl in der Organisationsentwicklung als auch in der Selbstreflektion.

• Marcus Raitner: Vorleben und infizieren statt abholen und mitnehmen

  Mehr zum Thema Unternehmenstransformation. Um beim gerade genannten Konzept der Einfluss-Sphären zu bleiben - Change Management kann die offiziellen Prozesse und Vorschriften beeinflussen, die inneren Motivationen und Verhaltensmuster dagegen nicht. Dort wo es versucht wird zeugt schon die Wortwahl von Paternalismus und Entmündigung, etwa dann wenn die Mitarbeiter "mitgenommen" werden sollen. Der von Marcus Raitner bevorzugte Weg sieht anders aus, es ist der "virale Wandel". Um ihn zu starten müssen einzelne kommunikationsstarke und vom Sinn der Veränderungsvorhaben überzeugte Personen gefunden werden, die diese so vorleben, dass andere von sich aus folgen wollen. Die (schwierige) Management-Aufgabe in diesem Modell ist es diese Personen zu finden und in die entsprechenden Positionen zu bringen.

• Sonja Blignaut: Reconceptualising organisations - from complicated machines to flowing streams

  Noch mehr zum Thema Unternehmenstransformation. Sonja Blignaut geht davon aus, dass (produkterzeugende) Organisationen aus nichts anderem Bestehen als aus Wert- oder Handlungsströmen (Flows), die zwar bis zu einem gewissen Grad in bestimmte Richtungen gelenkt werden können, sich aber letztendlich immer den geradesten Weg Richtung Ziel suchen - im Zweifel auch an den offiziellen Prozessen vorbei. Ein interessanter Ansatz, der aber konsequent zu Ende gedacht neue Fragen aufwirft: was passiert mit Einheiten zu denen der Zufluss so verstopft ist, dass der Strom an ihnen vorbeifliesst (→ Thromben und Embolien) und wie kann dafür gesorgt werden, dass an kritischen Stellen Druck nicht zu Ausweichreaktionen sondern zu Gegendruck führt (→ Nicht-Newtonscher Flow)? Auf jeden Fall eine Anregung zum Nachdenken.

• Christiaan Verwijs: Actual stakeholders? Or just your audience?

  Ein Grundlagen-Thema über das zu selten nachgedacht wird: wer sind eigentlich diese Stakeholder mit denen ein agiles Team regelmässig interagieren soll? Ausgehend von dem leider weit verbreiteten Antipattern, dass nur Firmen-interne Kollegen in diese Kategorie fallen versucht sich Christiaan Verwijs an einer besseren Definition. Die von ihm gefundene lautet: "Jeder der etwas zu gewinnen hat wenn das Team gute Arbeit leistet oder etwas zu verlieren hat wenn das nicht der Fall ist". Im Vergleich zur internen Lösung ein deutlich besserer Ansatz, wenn auch einer der immer noch Interpretationsspielraum lässt. Würde beispielsweise eine Audit- oder Revisionsabteilung nach dieser Definition ein Stakeholder sein? Vermutlich läuft es wieder auf die klassische Antwort hinaus - es kommt drauf an.

• Gojko Adzic: Deliberate Side-Products

  Wenn es um die Ursachen der Komplexität von Anwendungen und Produkten geht werden immer die gleichen Gründe genannt. Technischer Wandel, sich ändernde Nutzervorlieben, wachsende Funktionsumfänge, hohe Abhängigkeiten, etc. Was selten genannt wird ist der Wunsch der beteiligten Entwickler innovative oder anspruchsvolle Technologien auszuprobieren. Gojko Adzic beleuchtet von verschiedenen Seiten wie es dazu kommen kann und hat mit seinen "Deliberate Side-Products auch eine Lösung parat. Auch der eine oder andere Agile Coach könnte sich ertappt fühlen, denn auch hier gibt es immer wieder überkandidelte methodische Lösungen, die besser nicht in kritischen Bereichen ausprobiert worden wären.