Netzgeflüster: Erfahrungsbericht Scrum-Zertifizierung „Professional Scrum Developer I (PSD)“

Immer ein bisschen Fortschritt. Ein bisschen ist okay, nur stehen bleiben ist schlecht. Ich finde, dass das ein guter Vorsatz ist in allen Belangen. Was die berufliche Weiterentwicklung betrifft oder das Lernen generell. Nachdem ich 2016 die Oracle-Zertifizierung als Java-Entwickler für Java 8 abgelegt habe, habe ich dieses Jahr die Fühler mehr nach einem anderen Thema ausgestreckt: mich mit Scrum auseinanderzusetzen und wie man es „richtig“ macht. Naja und was „richtig“ überhaupt bedeutet.

Was ist Scrum? Warum Scrum? Warum Scrum-Zertifizierung?

Scrum ist ein Vorgehensmodell für Projekt- und Prozessmanagement und erfreut sich großer Beliebtheit in agilen Softwareentwicklungs-Projekten. Agile Softwareentwicklung bedeutet, dass man iterativ und inkrementell arbeitet und den bürokratischen Aufwand gering hält und damit möglichst beweglich bleibt. Im Gegensatz zu starrem Projektmanagement wo man über Monate entwickelt und nicht auf akute Probleme reagieren kann ohne den ganzen Plan durcheinander zu werfen. Salopp gesagt. Scrum ist also eine Methodik, eine Theorie wie man agil arbeitet, die auf Erfahrungen beruht und von Scrum.org als Organisation rund um Ken Schwaber zusammengeschrieben wird. Von ihnen wurde auch ein Workshop zum Professional Scrum Developer von der Firma gebucht in der ich arbeite und da ich gern nach Scrum arbeite, habe ich mich dafür angemeldet und einen Platz in dem Workshop bekommen. Ich habe bereits in meinem letzten Projekt nach Scrum gearbeitet und empfand das als sehr angenehm. Allerdings gab es auch immer wieder Diskussionen darüber ob wir „Scrum richtig machen“ oder was man verändern müsste und da erschien es mir als wichtig und richtig sich mit Scrum mal tiefergehend auseinanderzusetzen. Dafür als „Auskenner“ zertifiziert zu werden empfand ich als sehr sehr schönen Bonus um mal vorweisen zu können „hey, ich kenne die empirischen Regeln“ und nicht zu sagen „hey, ich habe davon schon mal gehört, [aber ich weiß auch nicht so genau, ob wir das damals gut gemacht haben]“.

Photo by Giu Vicente on Unsplash

Für alle, die das alles noch zu nebulös finden und jetzt eigentlich immer noch nicht wissen, was Scrum ist – hier eine kurze Einleitung. Scrum besagt, dass man einen Entwicklungszyklus, sogenannten Sprint, festlegt. Die sind relativ kurz und erfüllen die agile Anforderung iterativ zu sein. Am Ende jedes Sprints gibt es ein sichtbares und funktionierendes Produkt, das man releasen könnte. Scrum gibt einige Kontrollmetriken vor die dabei helfen sollen. Beispielsweise tägliche, kurze Meetings (Daily bzw. Daily Scrum) und solche, die helfen die Sprints zu planen (Sprint Planning) und auch ein Fazit des jeweils letzten Sprints zu ziehen (Retrospektive) für künftige Verbesserungen, etc. Weiterhin legt es sehr genau fest, was im Aufgabenbereich des Entwicklers liegt und was nicht. Eine solche Metrik zu haben ist sehr hilfreich und es beruht auf Erfahrungen. Es ist ein empirisches Modell und das merkt man. Die Professional Zertifizierung geht außerdem sehr nah an die Technik ran und behandelt Themen wie Continuous Integration, Automatisierte Tests (Unit, Integrationstests, …), Versionskontrolle und noch vieles mehr. Heißt die Zertifizierung und der Workshop sind sehr nah an der Realität und den Tools eines Softwareentwicklers und nicht so trocken wie es klingen mag.

Wie habe ich mich vorbereitet?

Zuerst habe ich den Workshop besucht, der von einem Scrum.org-Trainer in unserer Firma abgehalten wurde. Dafür gibt es offizielles Lernmaterial von Scrum.org. Einmal einen Foliensatz und ein Handbuch, das den Foliensatz nochmal sehr detailliert erläutert (250-Seiten-detailliert um genauer zu sein). Der Workshop war auf Java ausgelegt und hat drei Tage gedauert. Innerhalb des Workshops geht man effektiv das Handbuch und die Folien durch. Man bildet außerdem Teams und spielt echte kleine Sprints durch in denen auch auf einer zur Verfügung gestellten Code-Base entwickelt wird, es werden Retros gemacht, Plannings – das ganze Ding wird in vier Sprints immer wieder durchgespielt. Nach dem Workshop haben wir Zugang zu einem Zertifizierungstest erhalten. Im Prinzip brauch man den Workshop nicht (rein formal). Allein das Bestehen des Tests wird für die Zertifizierung benötigt.

Nach dem Workshop habe ich die auf Scrum.org angebotenen Assessments (Beispiel-Tests) abgelegt, genauer gesagt Scrum Open und Developer Open. Scrum Open beinhaltet Theorie-Fragen zu Scrum, während Developer Open sehr auf testing, entwickeln und Integration eingeht. Aber nicht auf konkrete Tools wie SonarQube, jUnit oder Cucumber. Man muss 85% der Fragen richtig beantworten, was mir nicht gelungen ist allein nach der Teilnahme am Workshop. Daher war klar, dass ich mir den Stoff nochmal zu Gemüte führen würde. Es ist zu empfehlen, dass man das Lernen und die Zertifizierung nicht auf die lange Bank schiebt, sondern erledigt, solange die Erinnerung noch recht frisch ist. In meinem Fall war das aus privaten Gründen erstmal schwer, mir hat die Zeit gefehlt. So habe ich stückweise für ca. eineinhalb Wochen jeden Tag ein bisschen was gemacht. D.h. genauer: jeden Tag ca eine Stunde Schulungsmaterial von scrum.org lesen + Recherche im Internet + anschließend open assessments wiederholen. Bis ich alles gelesen hatte und die Fragen aus den open assessments mehrmals und zuverlässig mit 100% bestanden hatte.

Was war problematisch bei der Vorbereitung?

Das Problem bei der Vorbereitung war zum Einen, dass ich andere Fakten im Kopf hatte. Dadurch dass ich Scrum während eines Projektes kennengelernt habe und dort nicht strikt nach „Lehrbuch“ (=“Scrum-Guide“) gearbeitet wurde, bin ich initial mit anderen Vorstellungen an Scrum rangegangen. So waren bei uns Dailys stets 30 Minuten lang und der Product Owner und Scrum Master stets anwesend (um mal nur ein Beispiel zu nennen). Nach dem Scrum-Guide sind Dailys aber 15 Minuten lang (strikt) und es muss eigentlich nur das Development Team anwesend sein. Solche Fragen habe ich typischerweise erstmal falsch beantwortet, da ich es eben anders kannte. Ich halte es übrigens immer noch für valide Scrum an die Gegebenheiten des Projekts anzupassen (sofern man die Lehrbuch-Variante schon mal erprobt hat, sonst hat man ja kein Maß). Aber der Test ist eben strikt nach Lehrbuch. Durch den Workshop wurde meine Vorstellung zwar zu großen Teilen erstmal ‚gerade gezogen‘ aber wir haben im Workshop einige Themen ganz übersprungen, weswegen Nachbereitung keine Option sondern eine Erforderlichkeit wurde. Es wäre außerdem sinnvoll gewesen den Kurs an das Publikum anzupassen.

Obwohl jeder von uns schon mal nach Scrum gearbeitet hat, haben wir die vollen vier Sprints durchgezogen. Ich persönlich empfand das ein wenig als Zeitverschwendung für erfahrene Entwickler. Wir wussten alle wie ein Planning aussieht oder eine Retro. Zwei Sprints hätten ausgereicht um unsere Vorstellung von Scrum geradezuziehen und ein gleiches Verständnis zu gewinnen. Stattdessen waren die vier Sprints in denen wir ja auch entwickelt haben ziemliche Zeitfresser, v.A. auch das Aufbauen einer Entwicklungsumgebung. Das könnte man auch automatisieren, damit man in dem Workshop nicht 3 Stunden an das Herunterladen von IDEs und Packages verschwendet. Stattdessen hätte man mehr Erfahrungen austauschen oder Was-tut-ihr-wenn-Fallbeispiele durchspielen können. Ansonsten war der Trainer sympathisch, konnte unsere Fragen beantworten und hat uns einen guten Überblick gegeben. Allerdings empfinde ich es immer als sehr schade, wenn man aus einem Workshop rausgeht und nicht in der Lage ist einen Test sofort durchzuführen. Das ist zwar sowieso individuell unterschiedlich – jeder lernt anders. Aber ich denke die Mehrheit sollte dazu ‚geschult‘ werden und das sollte Ziel eines Workshops sein – vielleicht ist das aber auch nur meine Meinung? Das klingt jetzt sehr negativ, aber ich bin froh teilgenommen zu haben, v.A. um meine Vorstellung von Scrum mal mit dem Lehrbuch vergleichen zu können, zu wissen wie es nach dem empirischen Maß gemacht werden sollte und darüber nachdenken zu können, was meinem ehemaligen (und zukünftigen) Projekten gut tun würde.

Wie lief der Test ab?

Nachdem ich mich also gut vorbereitet gefühlt habe und die Open Assessments mehrmals mit 100% bestanden hatte, habe ich den Zertifizierungstest gemacht. Generell ist bei sowas aber Vorsicht angebracht – man kann auch leicht in Muster verfallen und die Fragen und Antworten auswendig lernen. Den eigentlichen Test macht man dann über einen bereitgestellten Link, wo und wann auch immer man möchte. Handy aus, Ruhe, Test an. Man muss in 60 Minuten 80 Fragen beantworten und zum Bestehen müssen 85% der Fragen richtig beantwortet werden. Das heißt man hat effektiv weniger als eine Minute pro Frage Zeit und 68 Fragen müssen richtig beantwortet werden. Die Fragen sind Multiple-Choice und man hat die Möglichkeit Fragen zu bookmarken und später zu beantworten. Eine große Erleichterung ist, dass einem der Counter angezeigt wird, außerdem wieviele Fragen man bisher beantwortet hat und angezeigt wird wieviele Auswahlmöglichkeiten man ankreuzen muss („Choose 2 answers“ anstatt „Choose all that apply“).

Einige der Fragen wird man 1:1 aus Scrum Open und Developer Open wiedererkennen. Manche haben auch leicht umformulierte Fragen oder Antworten oder sind eine Inversion der Fragen. D.h. während in Developer Open gefragt wurde, was bad practices sind, wird im echten Test stattdessen gefragt was good practices sind. Kann vorkommen. Gerade deswegen ist es auch wichtig die Fragen der Assessment Tests nicht nur auswendig zu lernen. Mal abgesehen davon ist das auch insgesamt nicht hilfreich, stattdessen also lieber: verstehen, hinterfragen, ggf nachlesen und diskutieren. Insgesamt sind diese 1:1 übernommenen Fragen und Fragen, die etwas umformuliert wurden zu schätzungsweise 50% im Zertifizierungstest enthalten. Der Rest geht tiefer in die Materie rund um Tests und Automatisierung beispielsweise, weswegen es sich wahrscheinlich lohnen würde über das Schulungsmaterial hinaus die angegebenen Bücher und Links zu lesen. Ich habe das übrigens nicht getan, einige Fragen vorgefunden die das Schulungsmaterial nicht covert und stattdessen aus Instinkt oder Vorwissen beantwortet. Eventuell auch noch wissenswert: Der Test ist in Englisch.

Fazit

Ich habe bestanden, muss aber sagen, dass ich den Test nicht einfach finde, auch wenn viele Fragen aus den Assessments vorkommen. Aber er ist machbar, nur eben nicht einfach. Da man nur einen Versuch hat und die Zertifizierung nicht gerade billig ist: lieber auf Nummer sicher gehen und mindestens die Assessment Tests gut absolvieren und das bereitgestellte Material lesen (mindestens!) Von nichts kommt nichts 😉

Zu anderen Erfahrungsberichten:

Erfahrungsbericht Java-Zertifizierung „Oracle Certified Associate, Java SE 8 Programmer I“

Featured image source: Giu Vicente

Habt ihr die Zertifizierung auch absolviert? Oder habt das noch vor? Oder habt ihr ggf schon mal eine andere Zertifizierung für Scrum absolviert oder eine der weiterführenden von scrum.org? Wie sind da eure Erfahrungen? Wie seht ihr das mit den Workshops – sollte man eurer Meinung nach auch geschult dort rausgehen oder ist das Wunschdenken Vielleicht seid ihr da anderer Meinung oder habt andere Erfahrungen gemacht?

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen rund um IT, Forschung, Netzwelt, Internet und eben auch Gerüchten widme. 🙂

5 Antworten

  1. Super spannend. Bei uns in der Company ist Scrum bzw. agile Arbeitsweise auch großes Thema und alle technischen Abteilungen arbeiten damit. Auch im Marketing haben wir uns an Kanban versucht und Teile daraus übernommen. Von einer Zertifizierung bin ich aber weit entfernt… 😉

    Gratuliere und nun viel Erfolg damit!

  2. Danke für den sehr interessanten Artikel und Gratulation zur bestandenen Zertifizierung. 🙂 Ich habe einige Jahre in Projekten gearbeitet, deren Prozesse an Scrum angelehnt waren. Die Frage, ob die Prozesse so richtig sind, habe ich mir damals auch gestellt und ein Buch zu Scrum steht noch auf der Leseliste. Meine Meinung zu Scrum ist allerdings geteilt. Ich mochte, dass Anforderungen durch den Prozess besser formuliert werden mussten, so dass ich mich als Entwickler darauf konzentrieren konnte Software zu schreiben anstatt Anforderungen und Vorstellungen abzugleichen und aufzuarbeiten. Auf der anderen Seite wird man durch seine Rolle auch stärker beschnitten und Unternehmen neigen meiner Erfahrung nach dazu Entwickler stärker zu instrumentalisieren, wenn sie einen durch Prozesse im Griff haben. Scrum hat eben auch einen Fließbandcharakter und verleitet meiner Erfahrung nach zur Verfolgung kurzfristiger Ziele. Nach meiner Erfahrung führt Scrum auch zu einem hohen Management-Overhead. Ich denke Scrum (wie jeder Prozess) ist nie optimal, kann einen aber zuverlässig gegen den worst-case schützen.
    Am Ende entscheiden eben Markt und Mitarbeiter darüber ob ein Unternehmen erfolgreich ist. Prozesse eigenen sich denke ich besser dazu Probleme sichtbar zu machen als sie effizient zu lösen.

  3. puh so viele Gedanken dazu, wir müssen mal wieder ein Bier oder 3 trinken 😉
    Nur soviel ich mag das Agile Manifesto und für mich ist es nicht so sehr eine Frage ob man agil arbeiten will oder nicht, in einer sich immer schneller drehenden Welt wüßte ich gar nicht, wie man nicht agil arbeiten sollte.
    Waterfall hat meines Erachtens nie wirklich funktioniert.
    Herzlichen Glückwunsch zur Zertifizierung auf jeden Fall 🙂

  4. […] Erfahrungsbericht Scrum-Zertifizierung „Professional Scrum Developer I (PSD)“ […]

Schreibe einen Kommentar zu bullion Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert