Nachdem ich 2022 eine Schreibwerkstatt für Autoren besuchte, stellte ich mir eine Frage:
Wieso gibt es eigentlich keine „Schreibwerkstatt“ für die PSM-III-Zertifizierung?
Im Gegensatz zu allen anderen Zertifizierungen für Scrum Master ist doch für die PSM-III-Prüfung die Kernfähigkeit „Schreiben“ essenziell. Seither träume ich von dem Gedanken, eine solche Werkstatt anzubieten.
Nur ist in meinem „Ein-Mann-Unternehmen“ – wie in wahrscheinlich jedem anderen Unternehmen auch – für Träume wenig Zeit und noch weniger Budget. Denn das Problem mit Neuentwicklung oder Innovation ist doch überall gleich. Ich könnte die Zeit oder das Geld auch in Aktivitäten investieren, die bereits funktionieren. Anfang dieses Jahres stand ich konkret vor der Entscheidung: den Traum einer „Schreibwerkstatt“ für die PSM-3-Prüfung träumen oder die Zeit lieber in die Vermarktung anderer Trainings oder in Aufträge bei Kunden investieren?
Als ehemaliger Product-Owner, langjähriger Coach für agile Produktentwicklung und mittlerweile auch für Unternehmen ist mir eines ziemlich bewusst:
Entwicklung neuer Produkte ist ein Risiko.
Wir alle kennen die Schauergeschichten:
- Nokia: Vom Marktführer zum Nachzügler – das Mobilfunkgeschäft wurde 2013/2014 an Microsoft verkauft.
- Kodak: Die Digitalkamera mitentwickelt, am Filmmodell festgehalten – 2012 folgte der Insolvenzantrag.
- Amazon Fire Phone: Teurer Flop – 2014 verlor Amazon rund 170 Mio. Dollar; 2015 war Schluss.
- Google Glass: Visionär, aber ohne tragfähigen Nutzen im Massenmarkt – Support-Ende 2023 besiegelte das Aus.
Die amtliche Statistikbehörde des US-Arbeitsministeriums hat diesen makabren Trend, der die meisten Unternehmen und Produkte ereilt, als Statistik veröffentlicht.
Die Zahlen sind bedrückend:
21,5 % der Unternehmen scheitern im ersten Jahr, 48,4 % innerhalb von fünf Jahren, 65,1 % innerhalb von zehn Jahren. Natürlich stammen die Zahlen nur aus dem Land der Gründer und Pioniere. Allerdings fürchte ich, dass sich im Land der Ingenieure und Zweifler ein ähnliches Bild zeigt.
Nochmal zurück zu Nokia, Fire Phone und Google Glass. Was haben sie alle gemeinsam?
Sie sind gefloppt, nachdem sie ausgeliefert wurden.
Aus Unternehmenssicht das Schlimmste, was passieren kann – da bereits viel Geld und Zeit in die Entwicklung geflossen sind. Deshalb suchen Produktmanager und Coaches rund um den Globus nach Wegen, so ein Desaster zu vermeiden. Am hilfreichsten finde ich hierzu die Klassifizierung von Produktrisiken von Marty Cagan.
Er unterscheidet diese Arten:
Die 4 Arten von Risiken in der Entwicklung
- Wertrisiko: Wird der Kunde oder Nutzer den Mehrwert erkennen, wollen oder gar dafür bezahlen? Hierzu gehören die Fragen, ob Nutzerinnen und Nutzer das Produkt verwenden oder kaufen werden, ob der Nutzen groß genug ist, ob das Problem relevant ist.
- Verwendbarkeitsrisiko: Können die Nutzer das Produkt tatsächlich bedienen? Wird es intuitiv genug sein? Können sie ihre Ziele erreichen? Hierbei geht es um das User-Interface, die Bedienbarkeit, das Onboarding, ob die Nutzerführung verständlich ist, ob sich eine Lernkurve oder Frustration einstellt.
- Umsetzbarkeitsrisiko: Haben wir die technischen Mittel, das Wissen und die Ressourcen, um das Produkt wie geplant zu bauen – mit akzeptablem Aufwand, in kurzer Zeit und mit hoher Qualität? Es stellt sich die Frage nach Technologie, Architektur, Infrastruktur, Fähigkeiten im Entwicklungsteam, vorhandenen Werkzeugen, nach technischen Schulden und der Komplexität der Lösung.
- Unternehmensrisiko: Ist das Produkt wirtschaftlich tragfähig? Passt es zum Geschäftsmodell, Markt, regulatorischen Rahmenbedingungen und Vertriebskanälen? Hierzu gehört die Frage nach Monetarisierung, Kosten, Rentabilität, Skalierbarkeit, gesetzlichen, rechtlichen oder Compliance-Fragen, Markteintrittsbarrieren, Markenkompatibilität, Vertriebsorganisation ...
Natürlich bin ich mir all dieser Risiken bewusst.
Ich gebe sie auch an andere Product-Owner in meinen „Professional Scrum Product Owner – Advanced“-Schulungen weiter. Leider bin ich mir ihrer so bewusst, dass sie mich förmlich lähmen. Wenn ich mir vorstelle, dass ich Zeit vergeudet habe, weil ich den falschen Ansatz gewählt habe, die Schreibwerkstatt zu entwickeln. Oder schlimmer: Dass ich Geld damit verloren habe, weil ich stattdessen keine anderen Aufträge erledigen konnte. Oder am schlimmsten: Dass sich mein Aufwand nicht langfristig auszahlt und ich deshalb zum Jahresende in finanzielle Schieflage gerate.
Dann schnürt es mir sofort den Hals zu.
Ich stand also vor einem Dilemma.
Auf der einen Seite stellte ich mir die Frage: Wie lassen sich diese Risiken adressieren, damit die Entwicklung auch erfolgreich sein kann? Und auf der anderen: Wie verrenne ich mich nicht total auf der Suche nach dem „richtigen“ Vorgehen?
Ein pragmatischer Ansatz war also gefragt.
Mir fiel eine Erkenntnis aus dem Buch „The Mom Test“ von Fitzpatrick ein:
„Mit Kunden reden.“
Klingt banal. Hat mir aber geholfen. Mehr noch: Es hat mich neben meinen Zweifeln, ob ich Zeit oder Geld verschwende, ob ich das richtige Vorgehen nutze, auch davon geheilt, noch weitere Luftschlösser zu bauen, wie die Schreibwerkstatt aussehen sollte.
Deshalb habe ich angefangen, mit anderen Scrum Mastern darüber zu sprechen. Wenn ich auf die PSM-3-Prüfung angesprochen wurde – sei es nach dem Training oder auf Meet-ups oder Konferenzen – habe ich nachgefragt:
- Warum möchtest du dich an die Prüfung machen? Was erhoffst du dir davon?
- Was würde dich bei der Vorbereitung unterstützen?
- Wie sollte die Vorbereitung auf die Prüfung konkret ablaufen?
Auf den ersten Blick waren die Gespräche hilfreich. Allerdings säten sie auch Zweifel an meiner „Schreibwerkstatt“-Idee. Einige Scrum Master schilderten mir, dass ihnen ein zweites Training ähnlich zum „Professional Scrum Master – Advanced“ helfen würde. Sie würden gerne kompakt in ein bis zwei Tagen alle Theorie lernen, die nötig wäre, um die Prüfung zu bestehen.
Bisher war ich überzeugt, dass mehr Theorie nicht entscheidend ist, um die Prüfung zu bestehen, sondern die Fähigkeit, auf den Punkt schwierige Fragen mit Beispielen und Erfahrungen aus dem wirklichen Leben von Scrum Mastern zu beantworten. Aus meiner Sicht geht es weniger um schieres Wissen, sondern mehr um konkrete Anwendung. Betrachten wir die Kriterien von Marty Cagan, dann hatte ich wohl mit diesen Gesprächen ein Wert-Risiko aufgedeckt:
Können andere Scrum Master den Wert für sich in einer „Schreibwerkstatt“ erkennen?
Was nun? Blicken wir nochmal zurück und fassen zusammen:
Ich hatte die Idee, dass eine Schreibwerkstatt anderen Scrum Mastern helfen könnte, die PSM-3-Prüfung zu bestehen. Diese Intuition war darauf gestützt, dass ich so auch die Prüfung bestanden habe. Ich habe über Jahre mit Stift und Zettel geübt, schwierige Scrum-Master-Fragen zu beantworten. Allerdings haben mir die Gespräche mit Scrum Mastern gezeigt, dass sich viele bei einer Unterstützung etwas anderes vorstellen und wünschen. Zu guter Letzt stand für mich viel auf dem Spiel. Ich wollte weder meine Zeit noch mein Geld in eine fixe Idee verschwenden.
Und jetzt?
Ich entschied mich, erstmal nicht aufzugeben und mehr Daten zu sammeln.
Deshalb stellten Marc und ich Anfang des Jahres eine Website für das PSM-3-Bootcamp online. Dort beschrieben wir, wie das Camp ablaufen sollte. Vom Namen „Schreibwerkstatt“ war ich mittlerweile abgekommen, da ich etwas suchte, das treffender den Kohorten-Ansatz beschrieb. „Bootcamp“ war da passender. Zudem konnte ich auch Marc für meine Idee gewinnen.
Im April waren 28 Scrum Master auf der Warteliste für das Bootcamp.
Was soll ich sagen? Bei über 5000 Followern alleine auf LinkedIn klingt das nach nichts. Ich muss dir nicht sagen, dass ich da eine andere Zahl erwartet hatte.
Ich deute es auf zweierlei Weise:
- Intuition ist gefährlich. Ich hatte mich zu sehr in meine Idee verliebt und die Realität aus den Augen verloren – die Nachfrage war viel geringer, als ich angenommen hatte.
- Das Format könnte funktionieren. Die Seite beschrieb keine zweitägige Schulung, sondern eine Online-Kohorte von einem Monat. Und 28 Personen waren der Ansicht, dass es ihnen helfen könnte.
Neben diesen beiden Erkenntnissen ärgerte ich mich am meisten über mich:
Ich bin dem Bestätigungsfehler auf den Leim gegangen.
Was ist der Bestätigungsfehler?
Er beschreibt die Tendenz, nur Informationen wahrzunehmen oder zu suchen, die unsere bestehenden Überzeugungen bestätigen, und widersprechende Hinweise zu ignorieren oder abzuwerten. Genau das hatte ich gemacht. Ich hatte Daten gesammelt, um Annahmen zu bestätigen.
Peinlich.
Mit anderen Worten: Ich hatte mir keine Gedanken – und zwar vorher – gemacht, was eine wünschenswerte Anzahl von Personen auf der Warteliste wäre. Wären 30 akzeptabel gewesen, um die Idee weiterzuverfolgen? Oder hätte es 100 gebraucht? Durch „einfach mal machen“ hatte ich mich um das fundierte Lernen gebracht, das durch ein evidenzbasiertes Vorgehen entstanden wäre. Was so ausgesehen hätte:
- Erst eine Hypothese formulieren,
- dann das Experiment gestalten und durchführen und
- erst zum Schluss messen, auswerten und interpretieren.
Dieser Ansatz ist das, was im Kern der Lean-Start-up-Ansatz zur Produktentwicklung oder Unternehmensgründung beschreibt. Er fußt auf der Idee, nur Evidenz und Daten – nicht Bauchgefühl oder Intuition – zu nutzen, um die Ungewissheit in der Entwicklung zu managen.
Hier ein kurzer Exkurs zum sogenannten Lean-Start-up-Zyklus im Detail:
- Hypothese formulieren: Starte immer mit einer Annahme darüber, was funktionieren könnte (z. B. „Nutzer wollen ein Tool, das X kann.“). Diese Annahme wird zur testbaren Hypothese gemacht („Wenn wir eine Landing Page für X schalten, werden mindestens 10 % der Besucher ihre E-Mail-Adresse hinterlassen.“).
- Experiment gestalten: Erstelle ein Minimalprodukt (z. B. Mock-up, Landing-Page, Concierge-MVP), das nur dazu dient, die Hypothese zu testen. Es geht nicht darum, ein fertiges Produkt zu bauen, sondern nur gerade genug, um Daten zu sammeln.
- Messen und auswerten: Sammle jetzt für einen festen Zeitraum Daten. Am Ende dieses Zeitraums entscheidest du, ob deine Hypothese bestätigt oder widerlegt wurde. Dieses Ergebnis entscheidet, ob du weitermachst, etwas änderst oder ganz abbrichst.
Nach dem Exkurs wieder zurück zu meiner Idee, ein PSM-3-Bootcamp zu erstellen.
Mittlerweile war Mai.
Ich wusste, dass 28 Personen der Online-Kohorten-Ansatz nicht abschreckte, und ich wusste auch, dass 28 Interesse am Camp hatten. Was ich nicht wusste: Wie hoch ihr Interesse (wirklich) war. Sich mit seiner E-Mail-Adresse auf eine Warteliste einzutragen, war bestimmt eine größere Absichtserklärung zur Teilnahme als nur ein Lippenbekenntnis auf einem Meet-up. Aber genügt das als „Beweis“, dass sich jemand am Ende auch wirklich zum Camp anmeldet und bereit ist, zu zahlen?
Was ich brauchte, um weiterzumachen oder die Idee endgültig zu verwerfen, war ein belastbarer Beweis.
Deshalb formulierte ich eine weitere Hypothese und ein Experiment, diese zu testen. Hier der Original-Wortlaut aus der E-Mail an Marc:
„Wir schreiben die 28 Interessenten direkt an, teilen mit, dass wir das Bootcamp am 22.09. starten wollen, aber 12 Teilnehmende benötigen. Wir fragen, ob sie dabei sind, und laden sie zu einem Vorab-Call ein. Damit müssen sie wirkliches Commitment und nicht nur ein Lippenbekenntnis abgeben. Wenn mindestens 12 Personen am Call teilnehmen, setzen wir es um.“
Bei weniger als 12 Zusagen hätte ich die Entwicklung abgebrochen. Diesmal war ich mir sicher, dass ich den Daten trauen konnte. Denn im Unterschied zu Gesprächen und der Landingpage mussten die Interessenten wirklich zeigen, dass sie dabei sein wollten. Sie mussten auf meine E-Mail antworten, sie mussten sich Zeit für den Call nehmen und daran teilnehmen.
Am Ende waren sogar 19 Personen im Call. Marc und ich machten uns an die Arbeit – und entwarfen dabei noch ein weiteres Experiment:
Wir glauben, dass sich von 19 Interessenten im Call mindestens 12 bis zum 15.07.2025 verbindlich zum Camp anmelden, indem sie die Teilnahmegebühr entrichten.
Wenn ich mir den Verlauf der Experimente und die Erkenntnisse ansehe, dann kann ich darin schön die Suche nach der Wahrheit anhand der Wahrheitskurve von Giff Constable erkennen.
Dieses Modell beantwortet die Frage:
„Wie sehr kann ich dem glauben, was ich gerade lerne?“
In unserer Situation:
- Interviews
- Landingpage-Experiment
- Preis-Test
- Pre-Commitment-Test
- Kaufentscheidung
Mit jedem Experiment steigt die Belastbarkeit der Daten, gleichzeitig steigen die Kosten der Experimente. Das teuerste Experiment ist, das Produkt fertigzustellen und auszuliefern. Und auch das bleibt ein Experiment – wie Nokia, das Fire Phone und Google Glass schmerzhaft vor Augen geführt haben.
Als nächsten Test wollen Marc und ich herausfinden, ob sich das Angebot skalieren lässt. Könnte das Bootcamp auch für deine Karriere als Scrum Master hilfreich sein? Dann trage dich hier auf die Warteliste ein und du erfährst als erster wann die nächste Kohorte startet.