Kommentierte Links (XXX)

Grafik: Pixabay / Geralt - Lizenz

• Joshua Kerievsky: Size teams for few to no handoffs

  Ein schönes Beispiel dafür wie sich Lean und Agile überschneiden. Übergaben zwischen Teams führen zu Wartezeiten, Wartezeiten führen zu langsamen Produktionsvorgängen und langsame Produktionsvorgänge sind nicht mehr agil. Joshua Kerievsky definiert die Freiheit von Übergaben (→ Crossfunktionalität und Autonomie) als so wichtig, dass dafür im Zweifel sogar relativ große Teams (größer als zehn Mitglieder) in Kauf genommen werden sollten. Ein interessanter Gedanke, selbst wenn ich glaube, dass in der täglichen Arbeit mit hoher Wahrscheinlichkeit ein Zerfall in Subteams stattfinden würde.

• Michael Küsters: How splitting work kills companies

Der gleiche Gedankengang aus einer anderen Perspektive. Dass selbst kleine und gut gemeinte Aufgabenteilungen zwischen mehreren Teams zu Bürokratie und Verlangsamung führen können ist auf einer abstrakten Ebene klar, das ganze Ausmaß erschließt sich aber erst an konkreten Beispielen. Das in diesem Fall genannte ist besonders anschaulich, da es sich nicht um Softwareproduktion handelt sondern um einen outgesourcten Kundenservice. Und auch ein weiterer Aha-Effekt ist enthalten: wenn Bürokratie selbst in einem so begrenzten Fall bereits entstehen kann - was passiert dann erst in komplexen Umgebungen?

• Claire Lew: The Culture Cliché

  An der Universität habe ich gelernt, dass Kultur die Summe der impliziten und expliziten Konventionen, Normen, Werte und gemeinsamen Erinnerungen ist, aus der eine soziale Gruppe ihre Identität konstruiert. Claire Lew formuliert es einfacher: “Culture is the way we do things around here.” Was beiden Definitionen gemeinsam ist - man kann Kultur nicht verordnen oder einführen. Sie ist einfach da und überlagert früher oder später alles andere. Wenn im Rahmen einer Unternehmenstransition nicht auch die Kultur geändert wird ändert sich im Zweifel gar nichts, zumindest nicht so wie gewünscht.
  

• Leon Tranter: Technical debt — or technical bankruptcy?

  Vermutlich muss man eine ausser Kontrolle geratene technische Schuld selbst erlebt haben um ihre Tragweite erfassen zu können. Wenn selbst kleinste Änderungen zu umfangreichen Arbeiten in allen Anwendungsteilen, systemweiten Ausfällen und langwierigem Bugfixing führen ist dieses Endstadium erreicht, das Leon Tranter sehr anschaulich als "technischen Bankrott" beschreibt. Sowohl die Ursachen als auch mögliche Lösungen sind gut zusammengefasst, jetzt müsste sie nur noch jemand lesen, der den Entwicklern seines technisch bankrotten Projekts/Unternehmens erlauben kann sie umzusetzen.

• Patrick Beuth: Feindbild Algorithmus

  Kurz nachdem die Digitalbranche zum größten Arbeitgeber in Deutschland geworden ist zeigt der Staat, dass er diesen Wandel leider noch immer nicht versteht. Wenn Bundesjustizministerium, wissenschaftlicher Dienst des Bundestages und weitere Politiker jetzt fordern, dass den Nutzern von Google, Facebook & Co offengelegt wird welche Algorithmen einem Suchergebnis oder Newsfeed zugrundeliegen, dann wird deren Volatilität verkannt. Alleine im letzten Jahr wurden in der Web-Suche von Google 9800 Modifikationen im Livebetrieb getestet, von denen dann 1600 dauerhaft eingeführt wurden (Bericht hier). Soll dann jeder Benutzer 27 Benachrichtigungen pro Tag erhalten? Vielleicht würden dem Bundestag und der Regierung eine Einführung in die Grundlagen agiler Softwareentwicklung gut tun.

Das Ende der Selbstorganisation

Bild: Wikimedia Commons / Famartin - CC BY-SA 4.0

Einer der zahlreichen heiligen Grale der Agilität ist die Selbstorganisation der Teams. Autonom, crossfunktional und empowered sollten sie sein, von niemandem gemicromanaged, lediglich von Servant Leadern umgeben und unterstützt. Nur wenn all das gegeben ist können sie zu schlagkräftigen und reaktionsschnellen High Performance-Units werden, ungebremst von Flaschenhälsen oder Handovers. Das stimmt in der Theorie und das stimmt auch in der Praxis, und doch - Selbstorganisation muss häufig Grenzen haben.

Man kann es am einfachsten an den Extremfällen sehen. Ein Team in einer Firma für Bürosoftware kann noch so selbstorganisiert sein, wenn es sich entscheiden würde statt eines Antivirus-Patch der Bürosoftware lieber Computerspiele zu programmieren würde das Management das zu Recht verhindern. Und ein Entwicklungsteam einer Bank kann noch so selbstorganisiert entscheiden, dass es seine Prozesse nicht mehr dokumentiert, die Bafin würde ungerührt untersagen, dass die so entstandene Software in Produktion geht.

Auch Grenzfälle sind bei genauerer Betrachtung offensichtlich: ein Team das die eigene Anwendung sowohl weiterentwickelt als auch wartet kann zwar selbstorganisiert entscheiden wann seine Mitglieder ihren Urlaub nehmen, es muss aber dafür sorgen, dass immer jemand da ist der die Live-Version am Laufen hält. Und ein Team das eine neue Software baut kann zwar wählen welche Programmiersprache es benutzt, das Unternehmen kann aber verlangen, dass es eine ist die auch ausserhalb des Teams verstanden wird.

Schwierig wird es schließlich wenn die Selbstorganisation mit Unternehmensgrundsätzen kollidiert. Darf ein Team für seine MVPs Quick & Dirty-Lösungen implementieren wenn das Unternehmen Clean Code will? Dürfen sich Entwickler selbstorganisiert zu Teams von über 20 Personen zusammenschliessen wenn das Unternehmen auf kleine Squads oder Scrum Teams setzt um agil zu bleiben? Spätestens hier heißt es oft: "Wenn Ihr das vorschreibt schafft Ihr die Selbstorganisation ab!" Aber ist das wirklich ein Argument?

In den meisten Fällen zeigt sich an solchen Situationen, dass nie daran gedacht wurde festzulegen bis wohin Selbstorganisation geht (dass es solche Grenzen gibt sieht man an den ersten Beispielen). Bei vielen agilen Transitionen heisst es einfach "Ab jetzt sind die Teams selbstorganisiert". Und wenn die im Rahmen ihrer Selbstorganisation auf eine Stelle stossen an der diese doch nicht gewünscht ist knallt es gelegentlich. Das muss nicht sein.

Es ist empfehlenswert, dass Management und Team gemeinsam (!) Grenzen festlegen bis zu denen die Autonomie reicht. Welche das sind kann von Fall zu Fall unterschiedlich sein, sie sollten aber begründet und nachvollziehbar sein. Und es sollte auch jedem klar sein, dass diese Grenzen nicht unverrückbar sind sondern sich verschieben können. So kann etwa zu Beginn noch ein Architekt vorhanden sein, der sich irgendwann später selbst abschafft und in das Team geht.

Zuletzt kann jedes einzelne Teammitglied anhand dieser Grenzen entscheiden ob es sich hier noch richtig aufgehoben fühlt. Und wenn das nicht der Fall ist kann es mit den Füssen abstimmen und gehen, in ein anderes Team oder ein anderes Unternehmen.

Kollektives Gedächtnis

Bild: Pxhere - CC0 1.0

Zu den häufigsten Beschwerden bei der Einführung agiler Methoden gehört die, dass man sich "das alles" unmöglich merken könnte. Das Grundgerüst von Scrum oder Kanban würde ja noch gehen, aber die zahllosen good und best Practices aus Extreme Programming, Lean Startup, Lean Management, TPS, Design Thinking, Clean Code, DevOps und sonstigen Ursprüngen wären einfach zu viel.

Bis zu einem gewissen Grad ist dieser Einwand sicher richtig, kein Mensch ist in der Lage sich alles zu merken. Dass in Summe trotzdem viel mehr an Wissen hängenbleibt als man denken sollte liegt an einem Phänomen das man als "kollektives Gedächtnis" bezeichnet, welches erstmals 1939 vom Soziologen Maurice Halbwachs beschrieben wurde. Vereinfacht gesagt bedeutet es, dass sich Gruppen von Menschen mehr Dinge merken können als einzelne Personen. Wie so oft: ein Ganzes ist mehr als die Summe seiner Teile.

Zunächst klingt das banal. Person A lernt Wissensgebiet A, Person B lernt Wissensgebiet B und zusammen wissen beide mehr als jeder für sich genommen. In der Realität ist es aber komplexer als das. Da die verschiedenen Personen sich kontinuierlich miteinander austauschen wird das Wissen nicht nur untereinander und mit Dritten geteilt, es wird auch immer wieder zurück in Erinnerung gerufen, so dass es nicht in Vergessenheit geraten kann. Ohne diese Kommunikation würde das Wissen irgendwann wieder verfallen.

An dieser Stelle überschneidet sich die Idee des kollektiven Gedächtnis mit verschiedenen good Practices im agilen Vorgehen. Die überschaubare Größe von Organisationseinheiten und die verschiedenen Querschnittsgruppen sorgen dafür, dass die gemeinsamen Erinnerungen durch eine permanente Kommunikation immer wieder erneuert werden, während der Soft Power-Aspekt der Methode dafür sorgt, dass das auch gerne und von sich aus stattfindet. Die verschiedenen themenspezifischen Meetingformate bieten den geeigneten Rahmen.

Ein für große Organisationen unerfreulicher Aspekt ist übrigens, dass auch schlechte Erinnerungen im kollektiven Gedächtnis hängenbleiben. Besonders das Fehlverhalten herausgehobener Personen (→ Manager) kann jahrelang im gemeinsamen Bewusstsein erhalten bleiben und selbst in jüngere Generationen hereingetragen werden die es gar nicht selbst erlebt haben. Ein Grund mehr das eigene Tun regelmässig zu überdenken.

Scaled Agile: Gilden

Bild: Wikimedia Commons / Gerbrand van den Eeckhout - Public Domain

Wenn es um die Skalierung von agiler Softwareentwicklung geht sind die Gilden in den letzten Jahren zu einem Buzzword geworden an dem kaum jemand vorbeikommt. Fast jedes größere Unternehmen oder Projekt das mehr als fünf Entwicklungsteams umfasst hat mittlerweile mehrere von ihnen, in denen gleichartige Spezialisten zusammengefasst sind. Frontend-Gilden, QA-Gilden, Architektur-Gilden, etc.

Wann genau die Verwendung dieses Begriffs in diesem Kontext angefangen hat ist nicht mehr genau nachzuvollziehen, es dürfte aber innerhalb der letzten zehn Jahre gewesen sein. Zwar gab es auch vorher schon Gruppierungen die sich in Anlehnung an die mittelalterlichen Handwerksvereinigungen Gilden nannten, allerdings waren das noch Zusammenschlüsse von Softwareentwicklern im Allgemeinen, die Spezialisierung auf bestimmte Teilbereiche erfolgte irgendwann in der Zeit danach.

Popularisiert wurde das Konzept schließlich durch das Spotify Model und die Management 3.0-Bewegung, von der auch die heute am weitesten verbreitete Definition stammt. Ihr zufolge ist eine Software-Gilde eine freiwillige Vereinigung von Entwicklern, die sich (wie in einer klassischen Community of Practice) über ihr jeweiliges Spezialthema austauschen, gleichzeitig aber auch Standards und Werkzeuge weiterentwickeln. Das Ziel ist dabei, sowohl die Mitarbeiter als auch die Methoden selbst immer weiter in Richtung Exzellenz zu bewegen und so bessere Produkte zu schaffen.

Der zentrale Unterschied zu Scrum of Scrums und Chaptern ist in der Regel, dass die Gilden nicht das Ziel haben die Arbeitsfortschritte der einzelnen Teams zu koordinieren. Es geht eher um die Weiterentwicklung der "Handwerkskunst" im Allgemeinen, unabhängig vom jeweiligen Produkt- oder Projektkontext. Die Ergebnisse können in die tägliche Arbeit einfliessen, müssen es aber nicht. Und häufig werden sie der Welt als Open Source zur Verfügung gestellt.

Bedingt durch die schnelle Verbreitung und dadurch dass er nicht geschützt oder geregelt ist kann der Begriff der Gilden natürlich auch anders verwendet werden. Gerade in einem eher hierarchischen Umfeld ist er mittlerweile oft als Bezeichnung für klassische Koordinationsgremien anzutreffen, etwa als Testmanagement-Gilde. Derartige Verwendungen sind starke Indikatoren für Cargo Cult und sollten daher am besten intensiv hinterfragt werden.

Story Points

Bild: Publicdomainpictures - CC0 1.0

Es gibt eine Grundsatzdebatte die bei fast jeder Scrum-Einführung aufkommt, und zwar die um die Story Points. Muss das sein? Warum braucht man die? Warum schätzen wir nicht in Personentagen, wie jeder andere auch? Alle diese Fragen sind berechtigt und müssen beantwortet werden wenn diese Methode vom Team akzeptiert und angewandt werden soll. Story Points sind nämlich keineswegs Teil von Scrum, sie sind lediglich eine ursprünglich aus dem Extreme Programming kommende good Practice und können von jedem Team auch weggelassen werden.

Um zu verstehen warum man es zwar kann aber nicht sollte bietet sich ein Gedankenspiel an. Ein Team schätzt eine Anforderung während eines Backlog Refinements und benutzt dabei Personentage als Metrik. Die Schätzung ist aus der Sicht aller Beteiligten auch einigermassen realistisch. In einem der folgenden Sprints beginnt die Umsetzung, jetzt stellt sich aber heraus, dass die geschätzte Zeit nicht stimmt und die Umsetzung deutlich länger oder kürzer dauert. Fast jedes Team wird an dieser Stelle bestätigen, dass es diese Situation aus eigener Erfahrung kennt. Woran kann das liegen?

Ein häufiger Grund ist, dass die einzelnen Teammitglieder unterschiedliche Kenntnisse und Erfahrungswerte in verschiedenen Themengebieten haben, was dazu führt, dass unterschiedliche Personen unterschiedlich lang mit der Umsetzung der selben Aufgabe beschäftigt wären. Jacob bräuchte z.B. sechs Tage für das Implementieren einer Upload-Funktion, Jennifer dagegen nur drei. Da die Aufwandsschätzung aber lediglich den Konsens oder Mittelwert eines Teams darstellt kann sie im Einzelfall nur danebenliegen, bestenfalls um Stunden, schlimmstenfalls um Tage.

Aber kann man dann nicht einfach im voraus festlegen wer welche Aufgabe übernimmt? Im Prinzip ja, allerdings zu einem Preis. Wenn Arbeitspakete von Beginn an einer Person zugeordnet sind nimmt man sich Fexibilität und riskiert, dass diese Person zu einem Flaschenhals werden kann der ggf. alle anderen verzögert. Der Busfaktor (das Risiko, dass der Ausfall einer einzigen Person Auswirkungen auf alle anderen hat) steigt und zuletzt wird es deutlich schwerer die Teammitglieder durch Hands On-Erfahrungen mit neuen Themem in Richtung T-Shape zu entwickeln.

Durch die Nutzung von Story Points kann ein Grossteil dieser negativen Effekte kompensiert werden, und zwar einfach dadurch, dass sie eine neutrale Schätzgrösse bilden. Das Team kann sie weiterhin gemeinsam schätzen, aber der Schätzwert von z.B. fünf Story Points bedeutet dann eben für Jacob sechs Tage und für Jennifer drei. Entgegen einem häufigen Vorurteil muss man dafür auch nicht die Prognosefähigkeit für die nächste Zeit aufgeben, denn in der grossen Zahl mitteln sich die Unterschiede und man kann mit einem Durchschnittswert von Story Points pro Sprint planen, der Velocity.

Es gibt darüber hinaus noch weitere Argumente für Story Points, etwa die Veranlagung des menschlichen Gehirns zum relationalen Schätzen oder die dadurch möglichen Moderationstechniken, wie z.B. Planning Poker. Wenn all das einem Team erklärt wird entscheidet es sich in vielen Fällen von sich aus dafür dauerhaft mit dieser Metrik zu arbeiten, selbst wenn es zu Beginn die oben genannten Fragen gestellt hat.

Bad technology choices can influence your culture

Die agile Coaches dieser Welt werden nicht müde es zu betonen: praktisch alles in der agilen Softwareentwicklung basiert auf der (Unternehmens)Kultur, bzw. auf ihren einzelnen Ausprägungen. Auf Werten, Verhaltensweisen, Überzeugungen und Mindsets. Das ist zwar richtig, verkennt aber einen zentralen Aspekt - die eingesetzten Technologien können auch die Kultur beeinflussen. Tim Gross erklärt in diesem Video Zusammenhänge und Auswirkungen.



Man kann es natürlich auch umgekehrt sehen: wenn die richtige Kultur vorhanden ist wird das automatisch zur Folge haben, dass bestimmte technologische Entscheidungen nicht getroffen oder verworfen werden. Grundsätzlich stimmt das zwar, stellt aber alle Unternehmen vor große Herausforderungen in denen der Kulturwandel gerade stattfindet und ggf. gerade erst begonnen hat. Wenn in einer solchen Situation die falschen technologischen Entscheidungen getroffen (oder nicht korrigiert) werden, dann kann das den Wandel stoppen oder sogar zum Scheitern bringen.

Ein Bild sagt mehr als 1000 Worte (XX)

Diese Grafik liefert die Antwort auf eine immer wieder gestellte Frage: warum soll ein Scrum Team nicht mehr als neun Mitglieder haben? Die Antwort ist die: für schnellen Wissensaustausch und schnelle Entscheidungen muss in selbstorganisierten Teams jeder mit jedem kommunizieren. Ab einer bestimmten Größe würde das zu einer unbeherrschbaren Menge an Kommunikationskanälen führen. Zu sehen hier im Bild.

The challenge with adding more engineers to a project. Just moving from 3 developers to 4 doubles the number of lines of communication. pic.twitter.com/sltsBUVq8w

— Rich Rogers (@RichRogersIoT) 1. Oktober 2017

Es gibt keine Kanban-Rollen - oder doch?

Bild: Pixabay - The Digital Artist - Lizenz

Zu den Fragen die im Rahmen von Kanban-Trainings immer wieder gestellt werden gehört die nach den Rollen die dieses Framework mit sich bringt. Vor allem die nach einem Äquivalent des Scrum Masters taucht immer wieder auf. Die Antwort kann allerdings immer nur sein, dass derartige Rollen in Kanban nicht vorgesehen sind. Das ergibt sich sogar zwangläufig aus seiner Natur, die eine andere ist als die von Scrum.

Scrum ist designt als ein Framework mit dem Zweck der Produktherstellung. Es definiert daher verschiedene Rollen, einen bestimmten Ergebnistyp und klar definierte zeitliche Abläufe, während derer bestimmte Tätigkeiten auszuüben sind um die gewünschten Ergebnisse zu erzielen. Kanban ist im Gegensatz dazu ein Framework mit dem Zweck der Prozessverbesserung, das auf jeden beliebigen bestehenden Prozess aufgesetzt werden kann um ihn nach und nach zu optimieren. Da zu diesen bestehenden Prozessen auch bestehende Rollen gehören können ist es nicht möglich neue Rollen verbindlich zu definieren. Der bestehende Prozess würde dadurch nicht mehr nach und nach optimiert sondern aprubt verändert, was so nicht vorgesehen ist.

Ungeachtet dieser grundsätzlichen Funktionsweisen besteht aber trotzdem eine Konstellation in der die Schaffung von Rollen nötig sein kann. Dann nämlich wenn eine neue Organisationseinheit von Beginn an mit den Kanban-Werzeugen arbeiten soll (Boards, Wertströme, WIP-Limits), und zwar bewusst ohne sich initial an die bisher bestehenden (suboptimalen) Prozesse anzulehnen. Zwar könnte man auch komplett ohne Vorgaben starten und warten bis sich aus dem Chaos Strukturen bilden, der damit verbundene Effektivitäts- oder Effizienzverlust führt aber dazu, dass dieses Vorgehen praktisch nie angewandt wird.

Der zur Zeit populärste Ansatz wurde 2016/2017 unabhängig voneinander von David Anderson und Jeff Sutherland entwickelt und lehnt sich stark an Scrum an. Als Äquivalent zum Scrum Master gibt es auch hier einen Prozessverantwortlichen (Flow Master, Flow Manager oder Delivery Manager), als Äquivalent zum Product Owner ist auch ein Produktverantwortlicher vorgesehen (Service Manager, Product Owner oder Product Manager). Anders als bei Scrum handelt es sich hier um Rollen im eigentlichen Sinn, das heisst sie können ggf. auch von Personen übernommen werden deren eigentliche Jobs ganz andere sind. Auch ein Umsetzungsteam existiert, das aber stärker arbeitsteilig sein kann als in Scrum.

Von elementarer Bedeutung ist, dass auch diese Rollen sich im Rahmen der kontinuierlichen Optimierung verändern, verschwinden oder vermehren  können. Wäre das nicht mehr der Fall gäbe es Teile der Organisation die per Definition nicht optimiert werden dürften. Das aber wäre mit Kanban nicht mehr vereinbar.

Die Zertifizierungs-Tretmühle

Bild: Freegreatpicture / Maxpixel - CC0 1.0

Angekündigt hatte es sich schon im letzten Jahr, seit einigen Tagen steht es auf der Website der Scrum Alliance: die angebotenen Zertifizierungen ändern sich, es werden weitere dazukommen. Die drei Basis-Zertifizierungen für Scrum Master, Product Owner und Developer werden ergänzt um ein Advanced-Level, der bisher rollenübergreifende Scrum Professional wird ebenfalls auf die drei Rollen aufgespalten. Aus bisher vier Zertifizierungen werden so neun¹. Und obwohl ich verstehe warum das so kommt glaube ich nicht, dass das eine gute Entwicklung ist.

Von der geplanten Erweiterung des Zertifizierungsspektrums habe ich zum ersten mal letztes Jahr auf dem Global Scrum Gathering Munich gehört. In den dort stattgefundenen Diskussionen war der Konsens der, dass die bisherigen Zertifizierungen über die Jahre weitgehend entwertet worden sind. In manchen Unternehmen wurde das gesamte mittlere Management geschlossen in die Zertifizierungslehrgänge geschickt, zahllose Freelancer kleben sich das Siegel auf den Lebenslauf um ihre Kunden zu beeindrucken und Schulungsanbieter haben in den dazugehörigen Kursen eine Goldgrube entdeckt.

Bedingt durch diese Inflation beweisen die Zertifikate heute eigentlich nur noch zwei Dinge: a) ihr Inhaber hatte genug Geld für die Prüfungsgebühr und b) er ist in der Lage eine überschaubare Menge an Lernstoff auswendig zu lernen. Das zu ändern und die Zertifikate durch mehr Stoff und mehr Praxiserfahrung aufzuwerten ist zunächst ein nachvollziehbares Anliegen, aber selbst wenn es von der Zielgruppe angenommen werden sollte ist für mich fraglich ob das gesteckte Ziel damit erreicht werden wird.

In den Gesellschaftswissenschaften gibt es den Begriff der Euphemismus-Tretmühle, der besagt, dass jedes neutrale oder positive Wort mit dem man die Benutzung eines negativ geprägten Begriffs umgehen will irgendwann die negative Konnotation seines Vorgängerausdrucks annehmen wird, solange sich die tatsächlichen Verhältnisse nicht verändern. Analog dazu glaube ich, dass wir uns gerade im Prozess einer "Zertifizierungs-Tretmühle" befinden.

Demnach findet im Moment Folgendes statt: eine Zertifizierung hat durch massenhafte Verteilung ihre Aussagekraft verloren und wird darum um eine "höhere Stufe" ergänzt. Auch die erleidet absehbar das selbe Schicksal, weshalb zur "Aufwertung" noch eine Stufe dazukommt, etc. Bereits nach kurzer Zeit wird die verästelte Hierarchie der entstehenden Zertifikate so groß, dass die meisten Menschen den Überblick verlieren². Abgesehen von wenigen Experten weiss keiner mehr was sich im Einzelfall dahinter verbirgt.

Der Effekt ist, dass die Menschen sich am Ende nur noch genervt abwenden wenn das Gespräch auf dieses Thema kommt. Noch einmal eine Parallele zur Euphemismus-Tretmühle: ausserhalb winziger Milieus gilt heute jeder der von "LSBTTIQ-Menschen", "Professorx" oder "Person mit Migrationshintergrund ohne eigene Migrationserfahrung" spricht als weltfremder Wunderling mit dem Unterhaltung eher anstrengend werden. Wer zukünftig den Scrum Master in CSM, A-CSM und CSP-SM unterteilen will dürfte schnell in der selben Schublade landen, und das nicht einmal völlig zu Unrecht.

Nun ja. Wie man hier im Rheinland sagt: Et es wie et es. Mal sehen wie die Sache ausgeht.

¹Dazu kommen die vor kurzem eingeführten Trainer-, Coach- und Leader-Zertifikate, die nochmal ein Thema für sich sind.
²Ich glaube, dass das gerade stattfindet.