Wer sich heute über Scrum-Zertifizierungen informiert, landet schnell bei der Frage: CSM (Scrum Alliance) oder PSM (Scrum.org)? Die üblichen Vergleiche zählen dann Preise, Testformate und Erneuerungsgebühren auf. Diese Informationen sind korrekt, aber sie gehen an der wichtigsten Frage vorbei.
Die wichtigste Frage lautet: Was soll am Ende anders sein? Ein Zertifikat im Lebenslauf, oder die verbesserte Fähigkeit, in einer echten Organisation mit echten Menschen agil zu arbeiten?
Ich (Anton hier) gebe seit über 10 Jahren Scrum-Trainings und sage vorweg offen, wo ich stehe: Ich bin heute ein Certified Scrum Trainer der Scrum Alliance und meine Trainings führen zur CSM- und CSPO-Zertifizierung. Ich habe also ein Interesse. Genau deshalb will ich hier fair sein, auch gegenüber dem anderen Modell.
Der berechtigte Einwand: „CSM ist doch nur Anwesenheit“
Wer recherchiert, findet diese Kritik schnell, und sie verdient eine ehrliche Antwort: Der CSM-Test ist deutlich einfacher als der PSM-I-Test. Das stimmt. Der PSM-I-Test ist anspruchsvoll, zeitlich eng und prüft Begriffe und Regeln des Scrum Guide präzise. Wer ihn selbstständig und ohne AI besteht, hat den Scrum Guide durchdrungen. Das ist eine Leistung, und ich kenne hervorragende Scrum Master mit PSM-Zertifikat.
Aber der Umkehrschluss, ein schwererer Test bedeute eine bessere Ausbildung, ist ein Denkfehler. Die beiden Zertifizierungen prüfen unterschiedliche Dinge, weil sie unterschiedlich aufgebaut sind:
Bei PSM ist der Test das zentrale Element. Ein Training ist optional, viele bereiten sich im Selbststudium vor. Die Qualitätssicherung liegt im Test, also muss der Test schwer sein.
Bei CSM ist das Training das zentrale Element. Es ist verpflichtend, dauert mindestens zwei volle Tage und darf nur von Trainern gegeben werden, die ein mehrjähriges Auswahlverfahren durchlaufen und davor eine langjährige Scrum-Erfahrung nachgewiesen haben. Die Qualitätssicherung liegt im Training, der Test danach bestätigt im Wesentlichen, dass die Grundlagen angekommen sind.
Man vergleicht also nicht zwei Tests miteinander, sondern zwei Modelle: geprüftes Wissen gegen erlebtes Lernen. Welches Modell besser ist, hängt davon ab, was man erreichen will.
Warum Erleben bei Scrum keine Floskel ist
Es gibt einen Moment, den ich in fast jedem Training beobachte, und den ich vor vielen Jahren in meinem eigenen ersten Training selbst hatte. Die meisten Menschen kommen mit der stillen Überzeugung an: „Scrum, Agilität, das sind Buzzwords für Dinge, die ich längst kenne. Wir machen ja schon Meetings und arbeiten im Team.“
Diese Überzeugung lässt sich nicht durch Definitionen ausräumen. Man kann den Scrum Guide auswendig lernen und sie trotzdem behalten. Sie löst sich erst auf, wenn man die Arbeitsweise selbst erlebt: in einer Simulation, in der das eigene Team an denselben Stellen scheitert wie im echten Projekt, und dann erfährt, wie anders es läuft, wenn die Prinzipien wirklich angewendet werden. In diesem Moment passiert etwas, das kein Multiple-Choice-Test prüfen kann: Die Teilnehmer verbinden die Prinzipien mit eigenen Erfolgen und Misserfolgen aus ihrer Arbeitsrealität. Sie haben danach eine Referenzerfahrung.
Ein konkretes Beispiel dafür sind die Feedback-Schleifen in den Simulationen. Wenn Menschen erleben, wie ein kurzes, aber echtes Feedback zur Wirksamkeit ihrer Arbeit zu einem herausfordernden Gespräch und dann in der nächsten Schleife zu tatsächlich besseren Ergebnissen führt, verstehen sie schlagartig, was an ihrem Sprint Review oder ihrem Demo-Meeting im Unternehmen schiefläuft. Die Lösung dafür ist oft nicht leicht. Aber sie haben jetzt ein Bauchgefühl dafür, wie es sich anfühlen sollte, und dieses Gefühl ist durch eine echte Erfahrung informiert, nicht durch eine Definition.
Eine zweite Erfahrung verstärkt das, und sie lässt sich allein durch einen Trainer kaum erzeugen: Im Raum sitzen Menschen aus unterschiedlichen Organisationen. Wenn jemand hört, dass ein Element von Scrum, das in der eigenen Firma angeblich „bei uns nicht funktioniert“, in einer anderen Organisation völlig selbstverständlich ist, beginnt er die eigenen Prozesse ernsthaft infrage zu stellen. Diese vielen unabhängigen Erfahrungen anderer helfen, von der eigenen Organisation zu abstrahieren, und genau diese Abstraktion ist eine notwendige Voraussetzung dafür, dass jemand die eigenen Abläufe überhaupt verändert. Eine bloße Trainermeinung erreicht das oft nicht.
Diese Referenzerfahrung ist der Unterschied zwischen „ich kann erklären, was ein Sprint ist“ und „ich erkenne in meinem Unternehmen, warum unser sogenannter Sprint keiner ist, und weiß, wo ich ansetze“. Das erste bringt einen durch einen Test. Das zweite macht einen wirksam.
Begriffe lernen oder Prinzipien verstehen
Ein Training, das auf einen schweren Multiple-Choice-Test vorbereitet, optimiert zwangsläufig auf das, was der Test messen kann: Begriffe, Regeln, Abgrenzungen. Das ist nicht wertlos, präzises Begriffswissen hat seinen Platz. Aber Scrum ist kein Regelwerk, das man befolgt, sondern ein Rahmen, der auf empirischen Prinzipien beruht: Transparenz, Überprüfung, Anpassung. Wer nur die Regeln kennt, wendet sie mechanisch an und wundert sich, warum es nicht funktioniert. Wer die Prinzipien verstanden hat, kann auch in Situationen entscheiden, die in keinem Guide stehen, und davon besteht der Alltag eines Scrum Masters oder Product Owners zu neunzig Prozent.
Wie groß dieser Unterschied ist, zeigt eines der häufigsten Missverständnisse überhaupt: die Verwechslung von Akzeptanzkriterien, also der Beschreibung einzelner Product-Backlog-Einträge, mit der Definition of Done. Auswendig lässt sich die Abgrenzung kaum behalten. Erlebt man aber einmal über zwei Tage hinweg, wie beide durchgehend nebeneinander verwendet werden, hat man den Unterschied sofort verstanden und entwickelt auch hier ein Bauchgefühl, das im Selbststudium nur schwer entsteht.
Genauso ist es mit Retrospektiven. In meinen Trainings halten wir Retrospektiven über das Training selbst. Dort erleben die Teilnehmer den Unterschied zwischen einem vagen Ziel („Wir wollen morgen konzentrierter bei den Themen bleiben“) und einer konkreten, überprüfbaren Maßnahme („Wenn wir den Fokus verlieren, halten wir diese Karte hoch“). Das klingt unscheinbar, ist aber ein zentraler Lernmoment: Wer später als Scrum Master ein Team bei wirksamer Selbstverbesserung begleiten soll, muss diesen Unterschied nicht nur kennen, sondern gespürt haben.
Woran Sie ein gutes Training erkennen, unabhängig vom Zertifikat
Fairerweise: Es gibt erfahrungsorientierte PSM-Trainings und es gibt CSM-Trainings, die unter ihren Möglichkeiten bleiben. Das Zertifikatslogo allein garantiert nichts. Stellen Sie dem Anbieter deshalb diese Fragen:
- Wie viel Zeit verbringen die Teilnehmer in Simulationen und Übungen, wie viel mit Folien? Ein gutes Training liegt deutlich über der Hälfte aktiver Zeit. Arbeitet ein Trainer ohne Beamer und Powerpoint, steigert das die Konzentration auf die Inhalte zusätzlich.
- Wie viel Praxiserfahrung hat der Trainer selbst in agilen Teams, jenseits des Trainierens? Ein guter Trainer hat in verschiedenen Rollen und vielen verschiedenen Kontexten gearbeitet und teilt Erfahrungen daraus.
- Wird im Training Raum für Widerspruch und Diskussion geschaffen, oder wird Stoff durchgezogen?
- Welche Elemente von Scrum werden direkt für die Durchführung des Trainings angewandt? Nur durchs Erleben entwickelt man eine Intuition für die richtige Anwendung.
Für wen welcher Weg passt
Wenn Sie bereits jahrelang in einem gut funktionierenden Scrum-Team arbeiten und ein formales Zertifikat brauchen, ist der PSM-Weg mit Selbststudium eine legitime, kostengünstige Option. Sie haben Ihre Referenzerfahrung schon, der Test bestätigt Ihr Wissen.
Wenn Sie aber neu in der Rolle sind, in eine Rolle hineinwachsen, oder wenn Sie, wie die meisten, in einer Organisation arbeiten, in der „Scrum“ bisher eher ein Etikett ist: Dann ist die Erfahrung das, was Sie brauchen, nicht der Test. Dann sollten Sie ein Training wählen, in dem Sie die Arbeitsweise erleben, hinterfragen und mit Ihrer Realität verbinden können, und das Zertifikat ist der Nebeneffekt, nicht das Ziel.