Hola, mein Name ist Carina und ich war der erste Scrum Master in unserem  Nice Code Valley. Aufmerksame Blogleser haben unseren Weg zu Scrum bereits mitverfolgt und unsere Erfolge mit uns mitgefeiert. Heute möchte ich ein wenig aus dem Nähkästchen plaudern:  Die Geschichte, wie alles begann. Welche Herausforderungen es zu meistern gab. Pläne, die wir wieder verworfen haben. Warum man es tatsächlich so machen sollte, wie man es “lernt” und wie ich an meine persönlichen Grenzen gestoßen bin. 

Warum ich euch das erzählen möchte? 

A) Weil ich mit euch die unheimlich coolen Erfahrungen teilen möchte. Ich muss gestehen, das letzte Jahr macht mich unglaublich dankbar. Dafür, Teil dieses unglaublich offenen, aufgeschlossenen Unternehmens zu sein und großes Vertrauen genießen zu dürfen. Ohne das uneingeschränkte Commitment  aller Nice People wäre so eine Veränderung in so kurzer Zeit nie von Erfolg gekrönt. Grund genug, stolz auf mein großartiges Team zu sein, das einfach mitzieht und die kühnsten Erwartungen übertrifft. 

B) Weil ich auch die weniger coolen Erfahrungen mit euch teilen möchte. Ja, wir haben mittlerweile alle Akzeptanzkriterien unseres Epics “Einführung von Scrum” abgehakt und die “Definition of Done” dafür erfüllt. Auf dem Weg dorthin sind wir allerdings über die eine oder andere Hürde gestolpert, wollten das Rad neu erfinden oder mit dem Kopf durch die Wand gehen. Das war mühsam, hin und wieder zermürbend, aber stets wertvoll auf dem Weg dorthin, wo wir jetzt stehen. Ja, aus Fehlern lernt man. Man muss sie aber nicht zwangsläufig selbst machen, wenn ma auch darüber im Nice Blog lesen kann. 😉 

Wie alles begann…

Niceshops ist in enorm kurzer Zeit enorm gewachsen und damit auch die Entwicklungsabteilung. Vom 1-Zimmer-Büro mit 2 Personen auf über 40 Personen, verteilt auf zwei Standorten, mit immer komplexeren Aufgabenstellungen und einem Tempo, das selbst der viel zitierten VUCA-Welt alle Ehre macht. Plötzlich wacht man auf und steht vor einer Fülle von Herausforderungen: Wie können wir schneller und agiler entwickeln? Wie können wir unsere Organisation skalierbarer machen? Wie können wir die Qualität erhöhen und unsere internen Kunden besser abholen? Wie ist transparent, was wir machen und warum wir es machen?  

Scrum als Framework war schon immer ein Thema. Eigentlich waren wir auch der festen Überzeugung, dass wir uns die “Scrum-Rosinen” schon erfolgreich rausgepickt hatten: Wir hatten Sprints und es gab Daily Stand-Ups (auch wenn meistens sitzend und nur dreimal pro Woche). Aber aus irgendeinem Grund wollte das Ding nicht funktionieren … Scrum hält wohl doch nicht alles, was es verspricht … Etwas anpassen und adaptieren? Nein, das kam zu der Zeit für uns nicht in Frage. Viel zu extravagant seien unseren “Tickets”. Viel zu unterschiedlich die Teammitglieder. Die Meetings könne man auch reduzieren. Und warum einen Product Owner suchen, wenn das ohnehin ein Entwickler übernehmen könne? 

Bis dato war ich mit Scrum theoretisch vertraut, hatte Fortbildungen gemacht und Bücher gelesen, praktisch wusste ich aber nur, dass das – was wir machten – mit Scrum nicht viel zu tun hatte. Doch plötzlich wurde Scrum zu “der Aufgabe 2020” (damals war Corona nur ein Ort in Niederösterreich), zu “meiner” Aufgabe und zu meiner Herzensangelegenheit. 

In meiner Rolle als Team Lead der Nice IT durfte ich mir mögliche Ansätze überlegen. In vielen Stunden soweit entwickelt, dass es (vorerst) meiner Vorstellung entsprochen hat. Danach wurden die Vorschläge intern in kleiner Runde vorgestellt, diskutiert, adaptiert und verworfen. Rückwirkend betrachtet: wir machten die Einführung von Scrum zu unserem ersten echten agilen Projekt. In kleinen Iterationen und inkrementellen Schritten. Im Sommer 2020 hatten wir vieles geklärt: Welche neuen Rollen müssen besetzt werden? Was bedeutet es für uns intern? Was bedeutet es für die Organisation? Wie schaffen wir eine transparente Priorisierung? Was müssen wir sonst noch beachten, damit Scrum klappt? 

Und was war nun meine Rolle? Tja, unser wohl erster Verstoß gegen die Lehre des Agilen Manifests: Meine Rolle war nicht eindeutig. 

Als Team Lead war es meine Aufgabe, das Commitment für Scrum zu bekommen. Im ersten Schritt war unsere Geschäftsführung ins Boot zu holen. Dank unserer Unternehmenskultur eine reine Formsache, lagen doch die Vorteile auf der Hand und unser Plan am Tisch. Damit hatten wir hier die Rückendeckung und auch das notwendige Budget, ging damit doch auch einher, dass wir Scrum Master, Product Owner & Co. benötigen. Im nächsten Schritt wurde die Idee im Management-Team vorgestellt. Auch hier galt es, alle notwendigen Informationen zu sammeln, unseren Plan zu präsentieren, für die einzelnen Stakeholder zu adaptieren und ein einheitliches Verständnis von Scrum zu schaffen. Nach unzähligen Schleifen nahm unser Plan immer mehr Form an. Neue Fragestellungen taten sich auf, Lösungen dafür wurden gemeinsam gefunden. Dadurch und durch unsere schon erwähnte Unternehmenskultur war bald das gesamte Management-Team Feuer und Flamme für Scrum und standen auch hinter unserem Plan. Transparenz war uns hier wichtig. Unsere Stakeholder wussten, dass es auch für sie harte Arbeit bedeuten würde: Feature-Requests müssen klar formuliert sein und einen eindeutigen Business Value haben, Wissen muss an die Product Owner weitergegeben werden, für Reviews und Abstimmungen muss Zeit und Geduld investiert werden und gerade zu Beginn würde die Durchlaufzeit nicht unbedingt steigen, sondern eher (noch) schlechter werden.

Teamintern galt es ebenso Stimmung für unser Vorhaben zu machen. Die Schwierigkeit bestand darin, das Team am Laufenden zu halten, wo wir mit unseren Plänen stehen, aber nichts zu kommunizieren, wo wir uns selbst  noch nicht 100 % sicher waren. Ein gemeinsamer Workshop, wo Entwickler, UX-Experten, zukünftige Product Owner, aber auch ausgewählte Stakeholder dabei waren, gab den offiziellen Auftakt, ab dem es Schlag auf Schlag ging. Die Motivation und Vorfreude waren am Höhepunkt, ebenso die Auseinandersetzungen mit dem Thema im Team. Damit erreichten auch die herausfordernden Fragen im Team ein neues Niveau: Wie werden wir unsere Releases planen? Wie wird unsere Sprintlänge sein? Wie stellen wir die Teams zusammen? Soviel vorab: Keine dieser Fragen haben wir aus dem Stehgreif beantwortet, sondern die vermeintlich richtige Antwort gefühlte hundertmal wieder verworfen. 

Wie wir auf unsere Lösung mit dem Team-Setup gekommen sind? Mit der so simplen Frage an unsere Seniors: “Stell dir vor, du müsstest deine Völkerballmannschaft in der Schule wählen. Wen hättest du gerne in deinem Team, wenn deine Gegner die Epics des letzten Jahres wären?” Das Ergebnis war ebenso verblüffend, wie trivial: Cross Functional Teams mit unterschiedlichem Wissen und Erfahrung, aber als Team harmonisch. Tja, klingt so einfach, doch trotzdem hatten wir da 100 Varianten, die wir zuvor durchdacht haben. Hier haben wir uns etwa mit einem Kardinalfehler verzettelt: Wir haben in unseren bestehenden Strukturen/Themen gedacht. Hier ist eben die perfekte Lösung aus dem Team selbst gekommen. Wie von Geisterhand (oder schlicht und einfach durch “Selbstorganisation”) wurde der Plan geschaffen, dass jedes Team Themenblöcke bekommt, in unserem Fall “Logistik/Finance”, “Shopmanagement” und “Customer Care”. Der Plan ist, dass das Know-How für diese isolierte Themenbereiche im ersten Schritt innerhalb des Teams geshared wird. In weiterer Folge ist es dann denkbar, die Teams langfristig nach dem “Split and Seed”-Ansatz durchzumischen und mit neuen Teammitgliedern zu ergänzen, sodass jedes Scrum-Team einen jeden unserer Feature-Requests umsetzen könnte. 

Mit dem Team-Setup stand auch fest, welche Rollen es noch zu besetzen gab. Das bedeutete, dass für meinen Kollegen Christian, der mich beim Recruiting nicht nur unterstützte, sondern vielmehr coachte, und mich ein wahrer Staffing-Marathon begann. Da wir schon ein genaues Bild im Kopf hatten, wie unser Roll-Out stattfinden soll, mussten wir nur noch die richtigen Köpfe für die offenen Rollen finden. Auch hier führten die Recruiting-Gespräche dazu, dass wir unsere Ideen nochmal mit erfahrenen Product Ownern und Scrum Mastern challengen und verfeinern konnten. Für den gemeinsamen Scrum-Werdegang hatte das zur Folge, dass die Spielwiese klar abgetrennt war: Was ist der Rahmen, in dem wir uns bewegen? Was ist noch offen und kann bzw. soll noch mitgestaltet werden. Auch hier war uns das Commitment des Teams wichtig und so wurden die Kandidaten auch auf das Team losgelassen, um weder Inhaltliches noch Zwischenmenschliches dem Zufall zu überlassen. 

Währenddessen übernahm ich auch die Rolle des Scrum Masters in unseren interimistischen Scrum-Setups. Diese “Experimente”, wie wir sie nannten, entstanden aus einer Not heraus, da sowohl die angehenden Product Owner ungeduldig wurden als auch das Entwicklerteam in den Startlöchern scharte. Im Rahmen der sogenannten “Übungs-Refinements” hatten die Product Owner die Möglichkeit, ihre ersten User Stories den Entwicklern zu präsentieren. Im Nachhinein erwies sich diese Übung als unbezahlbar: Die Product Owner konnten sich damit schon vorab auf die Bedürfnisse des Entwicklerteams einstellen, den Backlog mit bereits geschätzten User Stories befüllen und das Team durfte sich im Planning Poker versuchen. Weiters war es teamintern möglich, sich aufeinander einzustimmen, Gesprächsregeln zu definieren und mit Scrum in der Praxis vertraut zu machen, jedoch in einem geschützten Rahmen, welcher ausreichend Platz für Fehler und daraus resultierenden Learnings ließ. 

Nach einer kurzen “Experimentierphase” durfte ich dann das “Saazer Power”-Team in seinem Scrum-Start begleiten. Die Spielregeln waren klar, das Team aufeinander eingespielt und topmotiviert. Wie alte Hasen nahmen wir den Kampf gegen die User Stories auf und stellten uns mutig unseren Stakeholdern im Review. Es klappte wie am Schnürchen, obwohl unser Angstgegner “Home Office und Remote Scrum” zu unserem täglichen Begleiter wurde. Auch hier übte sich das Team in Selbstorganisation und vereinbarte Abstimmungs-Meetings und Pair Programmings in ihrem Chat. Als Scrum Master sah ich es als meine Aufgabe an, erreichte Sprintziele mit kleinen Überraschungen zu feiern und siehe da: Die Velocity stieg und stieg und stieg, das Team übertraf sich in jedem Sprint. 

War es ein Grund zu feiern? Nein, nicht ganz. Als Scrum Master hatte ich das Gefühl, dass das Team die Forming-Phase quasi überspringt und direkt in die Storming-Phase sprintet. Was war passiert? Ein Teil des Entwicklerteam drückte so dermaßen aufs Gas, vergaß allerdings auf die Tester und Product Owner, welche dadurch unter Druck gerieten. Es war gefühlt wichtiger, “seine eigene Entwicklung zu übertreffen” als sich als ganzes Team auf ein nachhaltiges Tempo einzupendeln. Damit kamen erste Zweifel an Scrum auf: Passt es tatsächlich zu unseren Herausforderungen? Ist es wirklich immer anwendbar? Können wir nicht ein paar Meetings ausfallen lassen und mehr entwickeln? Hier und da passierte es, dass alte Muster wieder in den Vordergrund traten, zB der Versuch, den Product Owner bei der Priorisierung zu overrulen, auf den Kunden wurde hin und wieder vergessen. Überraschend war für mich, dass die Transparenz von Scrum teilweise als “Kontrolle” (durch den Kunden, Tester, Product Owner, Scrum Master) empfunden wurde und die eigentlich gewünschte “Selbstorganisation” und das Empowerment des Teams gerade von den Seniors eher als Verlust der Selbstbestimmtheit wahrgenommen wurde. Diese Zeichen zu bemerken und zu interpretieren war ein wichtiger Schritt für mich persönlich. Es machte deutlich, wo wir noch blinde Flecken hatten, wo wir nachschärfen müssen, wo ich so schnell und voreilig war. Das war auch meine größte Herausforderung: Die Zeit zu geben, die ich mir selbst seit einem Jahr genommen habe. Zeit, zu verstehen, es persönlich wirken zu lassen, sich daran zu gewöhnen, an einem selbst zu arbeiten. Geduld zählt leider nicht zu meinen Stärken und die Luft war bei mir langsam draußen. Umso glücklicher war ich, dass ich im März meine Scrum Master-Rolle abgeben konnte und dem Team damit die Aufmerksamkeit zuteil wurde, die es verdient. 

Step by step folgten so eben unsere neuen Teammitglieder: die beiden Scrum Master, die beiden zusätzlichen Product Owner, die Tester. Hier war es wichtig, sie gut in die Teams zu integrieren, unsere Scrum-Vorstellung mit ihnen zu teilen und auch team- bzw. abteilungsübergreifend unser nice Onboarding zu betreiben. 

Meine persönlichen 5 Learnings: 

• Scrum nach Lehrbuch: Scrum macht man ganz oder gar nicht! Halbherzig damit zu starten ist zum Scheitern verurteilt, denn es funktioniert nur, wenn die (wenigen) Prinzipien eingehalten werden. 
• Nachhaltiges Tempo in der Entwicklung: Auch dieses Prinzip hat sich für uns als elementar erwiesen. Ein nachhaltiges Tempo im Team ist nicht nur wichtig, um die Tester als letztes Glied in der Entwicklungskette nicht untergehen zu lassen, sondern auch um den Product Ownern bzw. Stakeholdern ein Gefühl zu geben, wann ein Release realistisch ist. Von einer ausgewogenen Work-Life-Balance ganz zu schweigen. 
• Man kann nicht über-kommunizieren: Egal, ob es die “Definition of Done”, die Rollen und Artefakte von Scrum oder die Qualitätssicherung betrifft, man kann es als Scrum Master nicht oft genug wiederholen. Gerade wenn man selbst vieles erarbeitet hat oder bei der Entstehung involviert war, verliert man leicht den Blick von außen. Hier ist es wichtig, immer wieder inne zu halten und zu hinterfragen, ob alles klar ist oder ob nachgeschärft werden muss. 
• Rollenklarheit schaffen: Es gehört zu Scrum nach Lehrbuch, hat sich auch bei uns nicht ganz vermeiden lassen und ist uns – natürlich – auch zum Verhängnis geworden. Der Product Owner entwickelt selbst mit und gibt die Lösung vor, der Product Owner ist auch der Tester, der Scrum Master hat eigentlich die Führungs- und damit Abteilungsverantwortung. Ausreden wie “das ist bei uns ganz sicher kein Problem” oder “das ist nur eine Ausnahme” sollte man nicht gelten lassen, früher oder später kommt man in Teufels Küche. 
• Individuen und Interaktionen vollste Beachtung schenken: Gut vorbereitete Retrospektiven gehören zur Pflicht eines Scrum Masters. Die Kür allerdings ist, zwischen den Zeilen zu lesen. Was für den einen Fluch ist, ist Segen für den anderen. So bedeutet die plötzliche enge Zusammenarbeit im Team vielleicht Last für den einen, Entlastung für den anderen. Auf die Bedürfnisse des Einzelnen einzugehen, ist die wahre Challenge. Die letzten Monate haben gezeigt, dass hier Sorgen und Fragen auftauchen, auf die man in der Literatur keine Antwort finden wird. Die Quintessenz für mich ist, sich einfach die Zeit zu nehmen, in das Team “reinzuhorchen” und dem Team auch Zeit zu geben, sich mit den neuen Anforderungen und Prozessen vertraut zu machen. 

Scrum ist etabliert – bin ich jetzt arbeitslos? All unsere Scrum-Teams sind schon mittendrin, statt nur dabei, die Product Owner entwickeln sich immer mehr zur wahren Experten in ihrem Metier und die Scrum Master motivieren die Teams mit viel Fingerspitzengefühl zu Höchstleistungen. Damit ist es an der Zeit, mich aus den operativen Scrum-Geschäften wieder zurück zu ziehen. Wie es mir dabei geht? Ich sehe das mit einem lachenden und einem weinenden Auge: Mir bereitet es große Freude zu sehen, mit welcher Selbstverständlichkeit Scrum bereits nach so kurzer Zeit gelebt wird. Die Scrum-Teams funktionieren intern so fantastisch und ergänzen sich untereinander optimal. Vor diesem Hintergrund fällt es mir überhaupt nicht schwer, loszulassen und voller Vertrauen kann ich sagen: Es läuft! Was mir aber ehrlicherweise schwer fällt ist, nun wieder etwas an Flughöhe zuzulegen. Wenn ich dazu tendiere, mich in Scrum Master-Agenden oder Product Owner-Diskussionen einzumischen, dann nicht, weil ich nicht davon überzeugt bin, dass sie das alleine hinkriegen. Sondern eher, da es mir im vergangenen Jahr einfach so dermaßen viel Freude bereitet hat und mich die letzten Monate absolut “verscrumt” haben. Nun versuche ich, mich bewusst aus dem Daily Business herauszuhalten. Die gewonnene Zeit kann ich jetzt in die Unterstützung der “Communities of Practice” investieren. Dort stehe ich für Fragen, Wünsche, Anregung oder einfach nur als Sparring Partner zur Verfügung. Dabei eint uns alle das gemeinsame  Ziel: Unsere Prozesse und unsere Zusammenarbeit stetig weiter zu verbessern, damit wir noch effizienter werden und wir selbst, aber auch unsere Stakeholder noch zufriedener werden. 

Darf man der Scrum-Literatur glauben, werden wir jetzt noch ein- bis eineinhalb Jahre brauchen, bis Scrum uns allen in Mark und Bein übergegangen ist. Und wie es in der agilen Welt so ist: Ein Ende ist ohnehin nicht in Sicht! Wir werden noch ein paar Mal stolpern und ratlos am Boden liegen, um gleich wieder unser Krönchen zu richten und weiterzulaufen. In all diesen Momenten werde ich mit Rat und Tat zur Seite stehen und alles daran setzen, weiter kräftig die Werbetrommel für Scrum zu rühren. Denn glaubt man Mike Cohen mit seinem “ADAPTing zu Scrum”-Prinzip ist der nächste Schritt auf unserer Roadmap, Scrum-Promotion zu betreiben, dh. unsere Erfahrungen und Erfolge in der Organisation bekannt zu machen. Hier werden wir unsere Success Stories teilen und eine Scrum-Safari machen. Die Krönung wäre dann, Scrum auf andere Bereiche in der Organisation auszuweiten. Wie wir dahin kommen, wissen wir noch nicht. Jedenfalls haben wir das Ziel vor Augen und wir werden die Challenge definitiv aufnehmen. Und damit kann ich auch die Frage beantworten: Nein, arbeitslos bin ich definitiv nicht, denn unsere Reise geht weiter! 😀