Nadia Vinciguerra, Senior Scrum Master bei IBM iX (ehemals ecx.io)

− in Kooperation mit ecx.io – an IBM Company −

Nadia gibt uns einen Einblick in ihre Rollen bei ecx.io - an IBM Company: Als Scrum Master betreut sie ein E-Commerce-Projekt von Schlüter Systems. Als Scrum Domain Owner erklärt sie wie Scrum bei ecx.io implementiert wird, und als Team Lead erläutert sie, welche Leadership-Learnings sie bereits machen konnte.

Hallo Nadia, welchen Job machst du bei ecx.io?

Bei ecx.io übe ich verschiedene Rollen aus. Zum einen bin ich als Scrum Master in die operative Arbeit involviert. Ich habe ein verteiltes Team bestehend aus zehn Leuten: Entwickler, Tester, Product Owner, Client Manager und einen Solution Architect. Seit Januar bin ich außerdem Teamlead von drei Scrum-Teams mit insgesamt 26 Mitarbeitern. Da geht es eher um organisatorische Tätigkeiten wie Kapazitätsplanung, Mitarbeiter- und Bewerbungsgespräche, Urlaub und solche Sachen.

Außerdem bin ich noch “Domain Owner” für das Thema Scrum. Bei ecx.io haben wir für unterschiedliche Themen “Domain Owner”.

Welche Aufgaben hat der Domain Owner?

Der Owner einer Domain hat ein Auge auf das Thema und sorgt dafür, dass es umgesetzt wird. Das heißt nicht, dass er alles entscheidet. Aber er treibt das Thema für ecx.io voran und stellt Fragen wie: Wie ist Scrum bei den unterschiedlichen Standorten implementiert? Macht Scrum überhaupt für alle Projekte Sinn? Wie können wir Scrum weiterentwickeln?

Wie viel Prozent deiner Arbeitszeit entfällt auf die Rollen?

Wir haben im letzten halben Jahr getestet, ob es möglich ist, alle drei Rollen gleichzeitig auszuüben. Alle drei Rollen sehr gut zu machen, funktioniert nicht zu 100 Prozent. Ich habe allerdings das Glück, dass ich tolle Leute in meinem eigenen Scrum-Team habe, und die funktionieren auch ohne mich als Scrum Master. Darum überlege ich gerade mit meinem Vorgesetzten, ob ich von den operativen Aufgaben weniger übernehmen kann, um mich dafür mehr um andere Themen zu kümmern.

Welcher Teil der Arbeit macht dir am meisten Spaß?

Ich leite gerne Menschen und sehe mich daher in der Rolle des Teamleads. Dabei habe ich das Ideal eines Leaders in Abgrenzung zum Manager vor Augen. Ich würde mich gerne in den nächsten Jahren zu einem Leader weiterentwickeln, weil mir diese Art der Arbeit besonders viel Spaß macht.

Eine Frage an den Domain Owner: Wie setzt ihr Scrum bei ecx.io ein?

Wir implementieren Scrum nach seinen Prinzipien, Rollen und Events. Aber grundsätzlich muss ich sagen, dass wir bei ecx.io versuchen, die Teams zu “empowern”, selbst die beste Scrum-Lösung zu finden – eine Lösung die gut zum Team und zum Kunden passt und womit wir erfolgreich sein können. Das heißt, meine Arbeit als Scrum Master besteht auch darin, mich als Scrum Master ein Stück weit überflüssig zu machen.

Ich denke, Scrum sollte nie eine Religion sein.

Denn es geht darum ein Projekt abzuliefern. Das mache ich auch stets in Bewerbungsgesprächen deutlich. Wir wollen Leute haben, die sich nicht um der Methode willen an Scrum festklammern, sondern auch mal von Scrum Abstand nehmen können, wenn das Projekt es gerade erfordert. Zum Beispiel stehen manchmal selbst die Scrum-Events im Weg, weswegen wir uns auch die Frage stellen, ob es wirklich immer Scrum sein muss, oder ob wir nicht auch auf Scrumban zurückgreifen können, um etwas leaner zu arbeiten.

Zudem werden unsere Projekte und Teams immer größer und somit auch internationaler. Wir haben sie Zahl der Mitarbeiter in den letzten Jahren weiter erhöht. Vorher waren alle Teams onsite. Jetzt haben wir oft verteilte Teams in Düsseldorf, in Wels in Österreich und in Varaždin und Zagreb in Kroatien. Das heißt, mein Team besteht zum Beispiel aus einem Product Owner, dem Scrum Master, Entwicklern und Testern hier in Düsseldorf und weiteren Entwicklern und Softwarearchitekten in Österreich und Kroatien.

Wie unterscheidet sich Scrum für kleine, lokale Teams zu Scrum für ein 25-Mann Team, das offsite arbeitet?

Ab einer bestimmten Teamgröße funktioniert das klassische Scrum nicht mehr, ohne dass man es skaliert. Mit Scrum of Scrums haben wir eine Möglichkeit eines “Scaled Agile Framework” ausprobiert, bei dem ein großes Team in Sub-Teams unterteilt ist. Jedes Team hat einige Stand-ups – zum Beispiel morgens und nachmittags schicken die Teams jeweils eine Person repräsentativ in das Scrum of Scrum-Meeting, um sich remote mit dem Chief Scrum Master zu besprechen. Kommunikation und Interaktion ist dabei das Wichtigste: Denn gerade bei großen Projekten sind die Abhängigkeiten besonders kompliziert.

Als Scrum-Master bin ich erfolgreich, wenn ich es schaffe ein selbstorganisiertes Team zu führen.

An welchem Projekt arbeitest du als Scrum Master?

An einer E-Commerce-Plattform für Schlüter Systems. Sie produzieren Bauelemente wie die Schlüter-Schiene, die als Abschlussschiene für Parkett oder Kacheln dient. Wir haben mehrere Projekte für diesen Kunden und begleiten ihn schon seit mehreren Jahren durch die digitale Transformation.

Wie sieht eine Produktentwicklung bei ecx.io für gewöhnlich aus?

Mein Team kommt dann ins Spiel, wenn die Customer-Engagement-Abteilung und die Usability-Engineering-Group ihre Arbeit gemacht haben. Sie haben dann bereits herausgefunden, welches Produkt unser Kunde und die Kunden des Kunden haben wollen. In diesem Prozess sind wir als Scrum Team schon mit eingebunden, um Kommentare zur Machbarkeit von bestimmten Punkten abzugeben. Dann gibt es eine Anforderungsanalyse, bei der wir versuchen, herauszufinden, ob das überhaupt machbar ist. Meine Aufgabe ist es, sicherzustellen, dass agil gearbeitet wird. Das bedeutet: Nicht alle Anforderungen sind komplett definiert, sondern einige werden erst während der Produktentwicklung finalisiert.

Zu meinen Aufgaben gehört es auch den Solution Architect, das Dev-Team und den UX-Designer einzubeziehen, um die Requirements zu definieren. Die Quality Engineers challengen das Konzept aus der User-Perspektive und anhand der High-Level-Requirements brechen wir die Aufgaben dann in User Stories herunter und planen die Releases zusammen mit den Kunden. Und dann geht es auch schon los.

Welche Aufgabe hat bei euch der Solution Architect?

Aktuell arbeiten wir mit drei Technologien: Sitecore, SAP Hybris und Adob. Beim Schlüter-Projekt handelt es sich zum Beispiel um ein SAP-Hybris-Projekt. Für jede Technologie haben wir ein oder mehrere Solution Architects, die Experten sind und den Kunden beraten, um die richtige Lösung für ihn zu finden. Der Solution Architect spielt für die Dev-Teams bei der Entwicklung eines Projektes eine wichtige Rolle, weil er Experte für die Lösung ist und beurteilen kann, ob die Technologie überhaupt geeignet ist, und welche Stolpersteine es bei dem Projekt geben könnte.

Welche Tools verwendet ihr während des Entwicklungsprozesses? Welche Tools sind für dich als Scrum Master wichtig?

In einem so verteilten Team-Setup brauchst du dringend Slack. Für Videokonferenzen nutzen wir Google Hangouts und für mich als Scrum Master ist auch das Telefon sehr wichtig. Das sind meine Haupt-Tools. Denn als Scrum Master muss ich sofort wissen, wenn es ein Hindernis zu überwältigen gibt.

Als Scrum Master brenne ich Roadblocker wegzuräumen.

Natürlich nutzen wir Jira, ein Ticketsystem, um zu sehen, wo wir in einem Sprint stehen. Jedes Scrum-Team hat einen eigenen JIRA Workflow, eine eigene “Definition of Done” und eine starke “Definition of ready”. Damit vermeiden wir unklare User-Stories in einem Sprint und können damit sicherstellen, wann eine Story fertig ist. Confluence nutzen wir für die Dokumentation in der Vorbereitungsphase unserer User Stories. Unter anderem sind da unsere Wireframes und Click-Dummys abgelegt.

Unsere Entwickler arbeiten dann noch mit Stash, das auch mit Jira verknüpft ist, und mit dem die automatische JIRA Status Transition implementiert ist. Grundsätzlich gilt bei uns, dass jedes Scrum-Team die Lösungen nutzen kann, die für sie am besten funktionieren.

Welche Tools nutzt du noch?

Ich bin sehr chaotisch und nutze recht viele Post-its. Sowohl die in Windows 10 integrierten Sticky Notes als auch Papier-Post-its. Die kleben bei mir überall. Ich mag das Papiergefühl. Manchmal nutzen wir in der Retrospektive Mindmap. Zusätzlich zu den klassischen Scrum-Retros, am Ende jedes Projekt machen wir ein Lessons learnt, eine Art Projekt-Retro, um das agile Prinzip von “Inspect and Adapt” auch auf der Projektebene und nicht nur auf der Sprint-Ebene zu implementieren.

Wie muss man sich deinen Tagesablauf bei ecx.io vorstellen?

Wenn das Wetter es erlaubt, komme ich mit dem Fahrrad. Zuerst bringe ich um 8.00 Uhr meinen Sohn in die Kita und dann fahre ich hier in den Medienhafen. Das ist ein schöner Umweg und genau die richtige Portion Fitness am Morgen, um in Schwung zu kommen.

Als Erstes mache ich dann Slack auf und schaue, ob mein Team etwas braucht. Dann gehe ich in die Küche und hole mir einen Latte macchiato. Um 10.00 Uhr geht es dann ins Stand-up und dort haben wir immer ein bisschen Spaß, bevor wir loslegen. Im Stand-up besprechen wir die To-dos des Tages und versuchen, Probleme aus dem Weg zu räumen. Morgens bin ich viel bei meinem Team, am Nachmittag habe ich viele Meetings als Team Lead und Bewerbungsgespräche als Domain Owner für Scrum.

Nimmst du die Arbeit nach dem Feierabend noch mit nach Hause?

Ich mag meinen Job und ich mag es, die Leute zu führen. Aber für mich ist es wichtig, Arbeit und Freizeit klar zu trennen. Nach dem Feierabend lese ich also keine Mails mehr und reagiere nicht auf Slack.

Bitte gib uns einen Einblick in deinen Werdegang.

In Neapel habe ich Mathematik mit Nebenfach Informatik an der Universität in Neapel studiert, wo ich auch meinen ersten Job bei einem Mikrochip-Produzenten hatte. Wir haben da in C programmiert und das machte mir nicht wirklich Spaß. Was mir aber Spaß machte, war es, Fehler zu finden. So bin ich zur Quality Assurance gekommen. Mit meinem damaligen Freund bin ich dann nach Finnland gezogen, wo er einen Job als System-Tester bei Nokia hatte. Das war zu der Zeit, als das iPhone herauskam und Nokia nochmal alles gegeben hat. Ich habe in der Systemintegration von Nokia gearbeitet. Aber auch das war wenig herausfordernd. Bei F-Secure habe ich dann für vier Jahre als Agile Quality Engineer gearbeitet und das war auch mein erster Kontakt mit agilem Arbeiten und Scrum. Dort habe ich zum Beispiel Python als Scripting-Methode genutzt, um automatisierte Tests für den Antivirus zu schreiben.

Finnland war aufgrund des Wetter ziemlich hart, besonders im Vergleich zu Italien. Es gibt schon einen Grund, warum Linus Torvalds Zeit hatte, ein Betriebssystem zu schreiben. Wir sind dann nach Deutschland gezogen, nach Düsseldorf, und dort war ich Test-Manager und Scrum Master bei Qiagen. Das war spannend, da es da um Software für die Analyse von Bluttests ging. Ein Fehler hätte zum Beispiel ein positives statt ein negatives HIV-Ergebnis ausgegeben. Die nächste Station ist jetzt ecx.io, und hier ist es spannend zu erleben, wie der Transformationsprozess von klassischem Projektmanagement zu Agile und Scrum über die Bühne geht.

Welche Themen und Trends sind aktuell für dich von Bedeutung?

Im Moment geht es bei uns schon darum, wie wir Scrum bei ecx.io nutzen. Gerade probieren wir Scrum of Scrums für größere Projekte aus und überlegen, ob wir lieber Kanban oder Scrumban bei Service-Projekten implementieren sollen, weil eine Scrum-Planung aufwändiger sein kann als es das Projekt selbst.

Außerdem merken wir, dass es nicht immer optimal ist, wenn die Leute, die ein Projekt vorbereitet haben, aus dem Projekt während der Umsetzung zur nächsten Projektvorbereitung wechseln. Wir sind gerade dabei, eine Lösung zu finden.

Gibt es etwas, das dich bei der Arbeit total nervt?

So richtig nervt nichts. Aber es gibt Teamkollegen, die manchmal nicht lösungsorientiert arbeiten. Das kann dann schon mal anstrengend sein. Ich sehe das als Herausforderung für mich, dem Team-Mitglied ein Feedback zu geben und ihm beizubringen, wie er sich zu einem lösungsorientierten Mindset entwickeln kann. Leadership bedeutet, eine Feedback-Kultur zu etablieren, ein offenes Ohr für Mitarbeiter zu haben und dem Mitarbeiter sein Weiterentwicklungspotenzial zu zeigen.

Gibt es Learnings, die du mit unseren Lesern diesbezüglich teilen kannst?

Zu meiner Zeit als Testmanager war ich gut darin, positives Feedback zu geben, wenn jemand gut war, aber schlecht darin, negatives Feedback zu geben. Das musste ich erst lernen, und das hat mich auch einiges an Überwindung gekostet. Ich habe ein paar Trainings und Workshops dazu bekommen und es einfach ausprobiert. Letztendlich ist es viel einfacher, als man denkt, wenn man offen und freundlich an das Thema herangeht.

Welche Bücher kannst du zum Thema Scrum empfehlen?

Google!

Das größte aller Bücher.

Ich lese lieber Blogs und habe mir eine Reihe an Blogartikeln gebookmarkt, die ich immer wieder hervorhole. Dazu zählt dann zum Beispiel “Finding Marbles”, der Blog von Mountain Goat Software, Scrum.org oder Agile 42. In letzter Zeit habe ich viel zum Thema Distributed Teams gelesen. Außerdem schaue ich noch, was ich auf Social Media finde, und gehe sehr gerne auf Konferenzen. Im letzten Jahr war ich zum Beispiel auf der Scrum Gathering Conference. Außerdem fördert ecx.io seine Mitarbeiter sehr und ermutigt uns Workshops und Trainings wahrzunehmen. Jeder Team Lead hat ein Budget, das er dafür ausgeben kann.

Gibt es etwas, das dich inspiriert?

Ich finde es spannend, neue Menschen kennenzulernen und herauszufinden, wie sie ticken. Das ist Teil meines Jobs, und es ist jedesmal spannend, sich auf jemanden neu einzulassen und reinzuhören.

Liebe Nadia, vielen Dank für das Interview!

Webseite: ecx.io – an IBM Company

Dieses Interview wurde am 18. September in Düsseldorf gehalten und entstand in Kooperation mit der ecx international GmbH.