Ich werde häufig von Kunden gefragt, ob Scrum Zertifizierungen Sinn machen. Im Wesentlichen gibt es ja die Certified Scrum Master (CSM) und Certified Scrum Product Owner (CSPO) Zertifizierungen, die Unternehmen in der Auswahl haben. Ich habe selbst eine CSM und CSPO Zertifizierung. In diesem Blogbeitrag möchte ich mich über den Sinn und vor allem den Unsinn dieser Zertifizierungen beschäftigen. Seit 2005 sind wir nun Agile unterwegs. Häufig kokettiere ich mit „Und wir lernen immer noch“. Diesen Blogbeitrag und eine mögliche Kommunikation mit Ihnen, liebe Leser, sind für mich ebenfalls eine Form von Lernen. Mein Eindruck ist, dass Scrum Zertifizierungen unnötig sind.
Was ist Scrum?
Scrum ist ein einfaches Rahmenwerk, das schwierig zu implementieren ist. Es ist ein empirisches Verfahren, bei dem in iterativer Arbeitsweise (Software-)Inkremente eines Produkts entstehen. Die große Einmalplanung aus dem Wasserfall weicht einer kontinuierlichen, kleinteiligen Planung. Wir erkennen erst in der Rückschau, was passiert ist, denn häufig sind Ursache und Wirkung nicht zusammen hängend. Das macht es für alle Beteiligten etwas anstrengender, denn es braucht unter anderem eine kontinuierliche Kommunikation und Zusammenarbeit zwischen dem Delivery Team und dem Kunden (repräsentiert durch den Product Owner und ggf. weiteren Personen wie interne Stakeholder oder Endkunden).
Scrum baut auf dem Agilen Manifest auf, das Werte und Prinzipien vermittelt. Im Rahmen der iterativen Arbeitsweise verbessern sich die beteiligten Personen kontinuierlich, ermöglicht durch die Arbeit in Retrospektiven. Durch kontinuierliche Beobachtung und Reflektion sowohl von Innen wie von Außen verbessern sich die am Prozess beteiligten Personen, um somit mehr Wert im Endprodukt zu schaffen.
Im Scrum Rahmenwerk gibt es nur wenige Regeln, wenige Aktivitäten und wenige Artefakte, die definiert werden. Das macht es in der guten Anwendung so schwierig für manche Teams. Beim Begriff „Team“ schließe ich auch den Product Owner mit ein.
Irrglaube: Silver Bullet
Ein Teil der Unternehmen, die mich nach den Zertifizierungen fragen, möchten gerne eine Silver Bullet kaufen. Es gibt den Irrglauben, dass man doch nur die Grundlagen wissen müsste (denn Scrum ist ja ein sehr einfaches Rahmenwerk mit nur wenigen Regeln, Aktivitäten und Artefakten!), und schon könnte man loslegen. Es sind also alle sehr schnell aufgeschlaut und können sofort loslegen.
Die moderne Personalabteilung weiß natürlich, dass solch eine Zertifizierung nur Grundlagen schaffen kann. „Die müssen nur ein bißchen üben, und schon sind sie die Scrum Experten und unser Unternehmen wird profitabler!“, sagt man sich dann.
Doch die Probleme fangen erst in der Praxis an.
Irrglaube: Dinge weglassen oder So Wie Beim Letzten Mal
„Die Retrospektive brauchen wir nicht, die liefert ja gar keinen Mehrwert“, „Warum schätzt Ihr 8 Punkte, das muss doch auch in 3 gehen!“, „Heute habe ich keine Stories dabei, ich stell die Euch morgen im Planning spontan vor“, „Ich habe keine Zeit, ich habe noch Tagesgeschäft“, „Die Entwickler im Team sind auf fünf Projekte verteilt“: all das sind Situationen, die bei zertifizierten Beteiligten vorzufinden sind. Man wird also regelrecht wieder in die Kultur, in der man vorher schon nach anderen Methoden gearbeitet hat, hineingezogen. Mit anderen Worten: der Erfolg stellt sich nur sehr mühsam, wenn überhaupt, ein.
Worauf es ankommt
Wir benötigen Freiräume, um zu reflektieren und Verbesserungen anzustreben (Retrospektive). Wir benötigen Lern-Umgebungen, um zum Beispiel neue Technologien oder Konzepte zu erarbeiten, die auch Bestandteil des Backlogs sind. Wir müssen im konstanten Dialog innen – innerhalb des Teams inklusive Product Owner – und außen – mit Stakeholdern und Endanwendern – stehen. Es fordert von allen Beteiligten eine Menge ab, denn durch den gewonnenen Freiheitsgrad steigt auch die eigene Verantwortung für das Gesamte. Durch die Transparenz kann sich niemand mehr verstecken.
Die Zertifizierungen vermitteln in der Regel die entsprechenden Methoden. Geben Tipps zum Schneiden von User Stories. Erläutern das Schätzen anhand von Punkten. Vermitteln also Wissen und Techniken, um sie in der täglichen Praxis anzuwenden.
Doch zum Erfolg einer guten Produktentwicklung gehört noch mehr, und das lässt sich leider nur bedingt über Wissen und Techniken vermitteln. Sonst gäbe es ja die Retrospektive nicht (die meiner Meinung nach das Wichtigste im gesamten Rahmenwerk ist). Und wir erinnern uns: wir arbeiten empirisch, das heißt durch Beobachtung der vorangegangenen Periode, zum Beispiel den letzten Sprint, versuchen wir Zusammenhänge zu erkennen und daraus Verbesserungsmaßnahmen zu entwickeln.
Weil das ein kontinuierlicher Prozess ist, bei dem Neues Wissen auf dem Weg des Tuns entsteht, kann die ganze Kraft des Rahmenwerks erst dann entfaltet werden, wenn wir im operativen Doing sind. Dafür braucht es die passende Umgebung für das Team. Diese ist von Situation zu Situation höchst unterschiedlich. Im Laufe der Zusammenarbeit verändern die Teams auch ihre Umgebungen. Sie sind sozusagen Laborant und Versuchskaninchen zugleich.
Eine Scrum Zertifizierung kann dies nicht vermitteln. Die Verbesserung der Arbeit entsteht erst durch Beobachtung und Veränderung (Inspect & Adapt) und vielen Experimenten. Ein paar Beispiele für Laborumgebungen möchte ich hier auflisten.
Laborumgebung: die schützende Hand
Gerade wenn in einem Unternehmen noch nicht so viel Berührung mit agiler Arbeitsweise existiert, wird eine schützende Hand benötigt. Das kann eine Führungskraft oder eine der obersten Management-Ebenen sein, die ein Team außerhalb der im Unternehmen sonst etablierten Prozesse arbeiten lassen. Ganz wichtig ist hier allerdings, dass der- oder diejenigen, die die schützende Hand bilden, ein Grundverständnis agiler Werte und Praktiken haben und sich mit dem Team gegenseitig auf die Spielregeln verständigen.
Laborumgebung: Stabiles Team
Ein Team hat hohe Chancen auf kontinuierliche Verbesserung, wenn es möglichst kontinuierlich zusammenarbeitet und einzelne Teammitglieder nicht permanent in anderen Projekten mitmischen. Gängige Modelle auf Seite eines Dienstleisters (unternehmensintern wie auch extern) sehen zum Beispiel vor, die Personen rund um Projekte zu organisieren und nach Beendigung eines Projekts anders zusammenzustellen. Dies gilt es nach Möglichkeit zu vermeiden, sondern lieber die Projekte durch ein Team „hindurchfließen“ zu lassen. Ein Austausch in größeren Abständen kann wiederum sinnvoll sein, um neue Impulse in ein Team zu bringen, denn auch hier ergibt sich möglicherweise über lange Zeit eine gewisse „Betriebsblindheit“.
Laborumgebung: Retrospektive
Ich erwähnte es schon: ich halte die Retrospektive für das wichtigste Element im Scrum Rahmenwerk. Entfernen Sie die Retrospektive, so berauben Sie sich und dem Team der steten Verbesserungsmöglichkeiten. Eine gute Retrospektive schafft Vertrauen und ist auch in kurzer Zeit durchgeführt. An ihr nimmt idealerweise auch der Product Owner teil, da er als Teil des Teams zu betrachten ist. Nehmen Sie sich nur ein oder zwei ganz konkrete, kleine Maßnahmen vor, die Sie in der Zukunft anders machen werden. Denn die nächste Retrospektive kommt ja schon bald …
Laborumgebung: Spikes im Product Backlog
Häufig kommt es vor, dass wir für eine in den kommenden Sprints anstehende Aufgabe nicht genau wissen, wie wir sie realisieren werden. Um das Unwissen zu beseitigen, ist es also notwendig, Wissen zu schaffen. Zum Beispiel wenn in einer komplexen, über die Jahre gewachsenen Anwendung das jQuery 1.0 Framework durch die neueste Version ersetzt werden soll. Oftmals weiss man nicht genau, welche Implikationen dies einschließt, wie umfangreich oder einfach diese Aufgabe ist und wo die Risiken liegen. Hierzu gibt es also sogenannte Spikes. Diese sind vom Zeit-Invest limitiert (Beispiel: 2 Personen aus dem Team arbeiten maximal 2 Stunden an diesem Spike, und präsentieren dann die Ergebnisse innerhalb des Teams) und bieten somit die Chance, notwendiges Wissen für die anstehende Aufgabe zu erarbeiten und damit eine Story, die erst im übernächsten Sprint dran kommt, besser abschätzen zu können.
Wann immer also Unbekannte existieren, können Sie mit zeitlich limitierten Spikes in einem Sprint Wissen für die kommenden Sprints schaffen und somit eine gute Gesamt-Geschwindigkeit des Teams ermöglichen.
Laborumgebung: (Miß)Erfolge feiern
In meinen Slides „20 Tips for Product Owner“ habe ich erläutert, warum es sinnvoll ist, Release Parties zu feiern und dafür auch Budget einzuplanen. Wichtig ist jedoch auch, Mißerfolge zu „feiern“, denn ein Mißerfolg bietet eine gute Chance zum Lernen. Das kann innerhalb einer Retrospektive thematisiert werden, alternativ kann das auch über ein anderes Ritual „gefeiert“ werden. Wichtig dabei ist, zu ergründen, warum es schief lief und vielleicht sogar ein oder zwei kleine Maßnahmen zu besprechen, wie wir zukünftig die gleichen Fehler vermeiden wollen.
Laborumgebung: Coaching von Außen
Wer doch noch Unterstützung von Außen hinzu ziehen möchte, sollte lieber einen Agile Coach engagieren oder intern selbst ausbilden. Der Coach unterstützt agil arbeitende Produktentwicklungsteams dabei, ihre Fähigkeiten stetig zu verbessern, und ist der Supervisor für ein oder mehrere agil arbeitende Teams.
Mein Fazit
Was habe ich also bis jetzt gelernt?
Erstens: eine Scrum Zertifizierung kann Wissen im Bereich von Methode und Technik vermitteln. Sie schafft einige Grundlagen, um Starten zu können. Sie verhindert nicht, dass ein Team „sich verfährt“ oder die Beteiligten auf komische Ideen kommen wie oben geschildert.
Zweitens: es kommt auf so viel mehr an als nur zu wissen, worum es bei den Rollen, Artefakten und Aktivitäten geht.
Drittens: wenn es schon ein Training sein muss, dann suchen Sie sich ein Training, dessen Inhalte sich nicht explizit auf die Zertifizierung ausrichten und/oder am besten gar keine Zertifizierung enthält. Denn die beste Zertifizierung ist ein Team, das kontinuierlich selbst reflektiert und Feedback von außen (Kunden, Stakeholdern, Coaches) bekommt und einen guten Weg findet.
So, und jetzt seid Ihr dran. Was spricht für diese Zertifizierungen, was spricht dagegen? Lasst es mich in den Kommentaren wissen.
Schreibe einen Kommentar