Kirandeep Kaur, Scrum Master bei HRS

Kirandeep gibt uns einen Einblick in ihre Rolle als Scrum Master bei HRS. Sie erklärt, wie sie mit dem Shuhari Prinzip ihre Teams führt und warum die Retrospektive eine Schlüsselrolle dabei spielt.

Hallo Kirandeep, was ist deine Aufgabe bei HRS?

Bei HRS arbeite ich seit circa zwei Jahren als Scrum Master für unsere mobile Teams. Anfangs habe ich noch als Mobile Developer gearbeitet. Ich war schon in meinen vorherigen Firmen an den agilen Prozessen interessiert. Als man mich dann fragte, ob ich mir vorstellen könnte, die Rolle des Scrum Master zu übernehmen, habe ich ja gesagt. 

Wie war der aktuelle Stand der mobile Teams, als du zu HRS kamst?

Als ich zu HRS kam, hatte sich das alte Team aufgelöst. Viele Mitarbeiter hatten die Firma verlassen, und wir haben angefangen ein neues Team aufzubauen. Das war dann schon im neuen Headquarter. Im neuen Team waren zwei Mitarbeiter aus dem alten Team, die weitermachen wollten. Heute sind wir 17, die eine Hälfte hier in Köln und die andere in  Cluj-Napoca, Rumänien. Kulturell sind wir sehr divers aufgestellt und für Tech-Teams haben wir mit sechs Frauen eine ziemlich gute Quote. 

Wie bist du an deine neue Rolle herangegangen?

Am Anfang war ich zu einer Hälfte Entwickler und zur anderen Scrum Master. Ich habe dann viel über Scrum und die agile Methodologie gelesen. Was ist eigentlich “Agile”, und wie bettet man die Methode in die Arbeit ein? Dabei habe ich festgestellt, dass “agil” mehr als nur eine Methode ist. Es ist ein Mindset und man kann es viel weiter fassen, als nur als eine Methode für Projektmanagement. Ein Buch hat mich dabei besonders begeistert: “Scrum: The Art of Doing Twice the Work in Half the Time.” von Jeff Sutherland, dem Mit-Erfinder von Scrum. Er kommt ursprünglich aus dem Militär. Und zusammen mit seiner Lebenserfahrung hat er ein paar einfache Regeln entwickelt, um produktiver zu sein. 

Für mich war am Anfang die größte Herausforderung das Team zu professionalisieren, ihr Selbstbewusstsein zu stärken und das Mindset für Ownership zu vermitteln. Die Teammitglieder hatten alle unterschiedliche Backgrounds. Manche kamen aus dem Agenturumfeld und waren es gewohnt, dass man ihnen sagt, was zu tun ist. 

Wie bist du damit umgegangen?

Wir haben am Anfang die Übung gemacht “Baue deinen eigenen Scrum Master.” Frage das Team: Was siehst du in einem Scrum Master? Warum willst du einen Scrum Master und warum brauchst du ihn? Anhand dieser Fragen konnten wir dann Qualitäten und Charakteristiken für das spezifische Team entwickeln, die ich dann versucht habe zu implementieren. Mir war außerdem wichtig zu verdeutlichen, dass ich das Team nicht managen oder führen werde. Das ist nicht die Aufgabe des Scrum Masters.

It’s not a position of authority, it’s a position of responsibility.

Am Anfang war das sehr anspruchsvoll. Was ich darum gemacht habe, war, die Regeln vorzuleben und immer versuchen zu erklären, warum wir das so machen und warum das notwendig ist. Etwas zu erklären ist wirklich wichtig, um den Grund dahinter zu verstehen. Nur so kann man das Mindset ändern und damit auch die Zusammenarbeit verbessern. Und das sollte man mit viel Empathie dafür tun, wie die Kollegen etwas wahrnehmen und wie sie denken.

In diesem Interview haben wir neben dem Einblick in deine Arbeit auch die Möglichkeit, die Arbeit eines Entwicklers zu beleuchten, der schon auf zwei Kontinenten gearbeitet hat. Welche kulturellen Unterschiede sind dir zwischen Indien und Deutschland aufgefallen?

Indien ist vor allem ein Outsourcing-Land, das sehr von der Globalisierung profitiert. Und der Unterschied im Bezug auf die Arbeit besteht darin, dass du hauptsächlich für Firmen außerhalb Indiens arbeitest, hauptsächlich für Firmen aus den USA. Europa hat gerade erst angefangen Indien zu entdecken. Und für uns ist das kein Problem. In Indien gibt es das Mindset des “Atithi Devo Bhava”, was so viel bedeutet wie “Der Gast ist wie ein Gott”. Wir betrachten jeden, der in unser Land kommt und uns einen Job und Geld geben möchte, als Gott. So sind wir kulturell geprägt und aufgewachsen. Für unsere Arbeitswelt bedeutet das, dass du einen Boss hast, dass alles gut strukturiert ist und dass es Manager gibt, die für dich mitdenken. 

Ist da agiles Arbeiten überhaupt möglich?

In Indien werden Produkte schon auch agil entwickelt, auch wenn es immer in die eine oder andere Richtung gedreht ist. Da man mit Kunden aus der ganzen Welt arbeitet, muss man sich auch immer an den Kunden anpassen. Wenn der Kunde agil ist, dann sind wir es auch. Meine erste Erfahrung mit agilen Methoden habe ich in einem verteiltem Arbeitsumfeld für eine deutsche Firma gewonnen. Weil viel Remote war, waren wir gezwungen, viel zu kommunizieren und zusammenzuarbeiten. Das hat viel gebracht. Wichtig war es auch sich gegenseitig zu besuchen, um die kulturellen Unterschiede zu verstehen und selbst zu erleben.

Lass uns wieder zurück zu deiner aktuellen Arbeit bei HRS gehen. Welche Anpassungen habt ihr mit Scrum gemacht? Oder nutzt ihr das Framework nach dem Lehrbuch?

Das Einzige, was wir gemacht haben, war die “Definition of Done” anzupassen. Wir haben im Grunde das Invest Kriterium durch gesunden Menschenverstand ersetzt. Und wir machen Retrospektiven. 

Ist das etwas Besonderes, dass man Retrospektiven macht?

In meiner vorherigen Firma haben wir zwar nach Scrum gearbeitet. Eine Retrospektive gab es aber nicht.

Was waren die Gründe dafür keine Retrospektive zu machen?

Damals hieß es zum Beispiel, dass der Kunde uns diese zwei Stunden nicht bezahlt. Oder sowas wie “Wir sind eine Gruppe erwachsener Menschen. Wieso sollten wir uns zusammensetzen und über Probleme unterhalten? Sowas machen wir nicht.” Oder es gab die Befürchtung, dass einem vorgeworfen wird, dass man seine Arbeit nicht richtig macht. Man hatte also Angst vor der Situation. Ich glaube, in meinem alten Team wurde einmal eine Retro gemacht, die aber nicht so produktiv war. Statt also herauszufinden, wie man eine Retro richtig macht, haben wir es einfach sein gelassen.

Um was geht es denn bei einer Retrospektive?

In der Retrospektive geht es um drei Aspekte: Prozesse, Kommunikation und Tools. Es geht also nicht um die Features oder darum, wer was geschafft hat oder ob man das technisch eher so oder so umsetzt. Es geht darum, ob die Prozesse im Team wirklich funktionieren. Hast du das Gefühl, das passt, oder muss das Team etwas anpassen? Wie war die Kommunikation des Teams während des Sprints? Gerade Kommunikation ist ein sehr wichtiger Faktor, der, wenn er nicht transparent ist und darüber gesprochen wird, dazu führen kann, dass sich Gruppen bilden und das Team sich nicht weiterentwickelt. 

Die Tools sind auch ein wichtiges Thema, denn die müssen funktionieren. Wir nutzen zum Beispiel Jira und Confluence und am Anfang haben wir auch noch HipChat genutzt. Wir haben aber gesagt, wir würden viel lieber Slack verwenden. Also haben wir das geändert. Wie läuft die Continuous Integration? Über sowas sprechen wir in der Retro. Das Team tauscht Erfahrungen aus, die es während des Sprints gemacht hat, manche teilen Learnings, die sie gemacht haben, manchmal stelle ich jemanden heraus, um sein Selbstbewusstsein ein bisschen zu boosten. Vor einer Retro sollte man weniger Angst haben, sondern sie als eine Chance für den persönlichen Growth sehen. Ich erkläre das gerne mit dem Shuhari-Prinzip. 

Was hat es mit dem Prinzip auf sich?

Kennst du Kung-Fu Panda? Es gibt da den Meister Shifu und den Schüler Po. Der Meister beginnt dem Schüler beizubringen sich an Regeln zu halten. Das ist das Shu. Bei Kung-Fu Panda muss Po zum Beispiel Treppen steigen, und er versteht natürlich nicht, warum er das tun muss. Also braucht er eine Retrospektive, um zu verstehen: Wenn du deine Fähigkeiten verbessern willst, wenn du deine Kampfkunst verbessern willst, musst du die Treppen steigen und ständig an dir arbeiten. Erst, wenn er das verstanden hat, ist er bereit für Ha, was so viel bedeutet wie variieren. Wenn ich begriffen habe, wozu die Regeln da sind, kann ich sie auch anpassen. Bei Ri geht es dann darum, etwas eigenes zu entwerfen. Agiles Arbeiten basiert auf diesem Prinzip: Plan, Inspect, Adapt. Das ShuHaRi-prinzip habe ich auch aus Jeff Sutherlands Buch. 

Für meine Generation würde man das vermutlich mit dem Film Karate Kid erklären. Wie setzt ihr die Retrospektive bei HRS im Alltag um?

Wir haben alle zwei Wochen nach dem Ende unseres Sprints eine Retro, die auf circa zwei Stunden angesetzt ist. Dazu nutzen wir das Tool Padlet. Für das Team in Köln buchen wir dafür einen Besprechungsraum und wir öffnen dazu das Tool. Und die Kollegen in Rumänien sitzen an ihren Rechnern an ihren Plätzen. Der erste Schritt ist der “Feeling-Circle”. Der dauert circa 10 Minuten. Danach schauen wir uns die Punkte an, die schon vorher in Padlet eingetragen worden sind. Steht da nichts, dann nutze ich eine gemeinsame Aktivität, die hilft etwas zu finden, über das wir sprechen können. Ich sortiere dann die Punkte in zwei Spalten: Anchors und Engines. Bei Anchors geht es darum, was dich aufgehalten hat, etwas zu tun. Bei Engines, was richtig gut gelaufen ist, und was man noch besser machen kann. 

Die nächsten 10 bis 15 Minuten geht es dann darum, dass jeder über die Punkte spricht, die aufgeschrieben wurden. Danach wird abgestimmt, über welches Thema wir sprechen sollten. Denn in zwei Stunden kann man nicht über alles sprechen. Wenn ein Thema ausgewählt wurde, aber da ist noch ein anderes Thema, das eigentlich wichtig ist, aber keiner gelikt hat, dann spreche ich das an, damit darüber reflektiert werden kann. Danach geht es in die Diskussionsrunde. Je nachdem wie groß das Problem ist, schafft man auch mal mehrere Punkte zu besprechen.

Kannst du ein Beispiel für ein Thema machen, dass ihr mal besprochen habt?

Da wir ja jetzt Slack haben, nutzen wir das Tool natürlich auch viel. Aber das hatte manchmal zur Folge, dass Informationen verloren gegangen sind. Darum haben wir darüber gesprochen und Policies entwickelt. Jetzt kennzeichnen wir unsere Kommunikation in Slack, ob es darum geht etwas zu lesen, zu machen oder um eine reine Information geht. 

Kannst du uns drei Tipps geben, was man als Fazilitator eines Retros beachten sollte? 

Als erstes ist es wichtig einen geschützten Raum zu schaffen. Niemand urteilt über jemand anderen, und jeder beteiligt sich neutral und offen an der Diskussion. Der zweite Tipp ist Zuhören. Und der dritte Tipp ist, nicht mehrere Hüte auf einmal auf zu haben. Das ist manchmal sehr hart. Manchmal hast du eine Idee, wie du dem Team helfen könntest, darfst es aber eigentlich nicht. Das war Anfangs echt eine große Herausforderung. Das Feedback, dass ich dann bekam, war: Du bist der Fazilitator, du kannst dich inhaltlich nicht einbringen. Denn sonst wird das als das aufgefasst, was das Team tun muss. Hier muss der Scrum Master einen Schritt zurück machen und dem Zweck des Retros dienen.

Wenn du heute auf deine persönliche Entwicklung als Scrum Master zurückblickst, wo siehst du dich da?

Für mich ist diese Frage auch bezogen auf meine Religion. Ich bin eine Sikh, und Sikh ist Panjabi und bedeutet Lernender. Als Sikh bin ich eine Lernende, mein ganzes Leben lang. Das ist mein Mindset. Wenn ich meine Teams anschaue, dann haben wir es geschafft, dass das Team sich selbst organisieren kann. Der nächste Schritt wäre es, dass die Teams ihre Prozesse selbst designen können. Im Grunde geht es darum mich als Scrum Master überflüssig zu machen. Ich sollte keine Rolle mehr für die Teams spielen, weil sie in der Lage sind, alles selbst zu designen. Hier sehe ich meine persönliche Weiterentwicklung. Wenn wir das erreicht haben würde ich gerne die Erfahrungen auch an andere Teams bei HRS weitergeben. 

Dafür drücke ich dir, Kirandeep, die Daumen! Vielen Dank für das Interview!

Dieses Interview wurde am 19. Juli 2019 im Headquarter von HRS in Köln in englischer Sprache geführt. 

Du möchtest mehr über HRS erfahren? Auf dem Digitale Leute Summit 2019 legt Jochen Jaser, CIO von HRS dar, wie der Blick auf die Produktentwicklung aus der Rolle des CIO aussieht.