TL;DR

In der „Kennenlernphase“ mit einem neuen Team als Scrum Master wichtig: Zeit mit dem Team verbringen, viele Fragen stellen, Gespräche suchen, gut zuhören, das Netzwerk des Teams verstehen und Infos notieren.

Manche Dinge merkt man sehr schnell, wenn man in einem neuen Team startet. Gerade als Außenstehender fallen einige Dinge besonders auf und springen einen geradezu an, die langjährige Teammitglieder als Normalität wahrnehmen. Andere Themen haben eine gewisse Historie und bestehen aus vielerlei Perspektiven, die man zusammen setzen muss. Bis man das Team kennengelernt und einen gewissen Überblick gewonnen hat, dauert es also ein bisschen.

So viele Fragen

Das, was ich am Anfang am meisten mache, ist fragen. Und natürlich zuhören! Ich will verstehen wie das Team tickt, was für Charaktere im Team sind, wie die Dynamik im Team ist und was für eine Historie die Teammitglieder verbindet. Dann natürlich, welche Themen das Team beschäftigen, was sie Zeit & Nerven kostet und was sie motiviert. Wenn Andeutungen gemacht werden („da gab es schon mal ein paar kritische Situationen“, „das wirst du auch noch merken“, „das Thema hat so eine gewisse Historie bei uns“) frage ich nach. Entweder direkt oder nachgelagert in einem passenderen Moment (hier braucht es manchmal etwas Fingerspitzengefühl). Außerdem stelle ich viele Fragen („wie geht ihr eigentlich damit um, dass?“, „wie ist euer standardmäßiges Vorgehen bei …?“, „wie organisiert ihr euch zum Thema XY?“). Ein Glücksfall sind kommunikative Teammitglieder, die schon lange im Team sind und auch schon eine ganz gute Vorstellung von agilen Arbeitsweisen haben. Sie haben schon viel mitbekommen und ordnen die Dinge mit einem ähnlichen Mindset ein wie ich. Ich habe Glück und habe so jemanden im Team. praktischerweise sitze ich ihm die ersten beiden Wochen gegenüber und kann schnell mal unkompliziert etwas fragen. Aber Achtung, du solltest im Auge behalten, wie viel Zeit deine Fragen das Team kosten! Gerade mit Teammitgliedern, die gerne und viel reden, entwickelt sich eine „kurze Frage“ schnell zu einer mehrstündigen Q&A Session.

A apropos Sitzplatz…

Zeit beim Team

Meiner Meinung nach ist es als Scrum Master essentiell, dass der eigene Arbeitsplatz im Teambüro ist. Natürlich kommt es darauf an: sitzt das Team überhaupt zusammen (hint: sie sollten!) Eine besondere Herausforderung ist es natürlich, wenn man ein verteiltes Team hat oder Scrum Master für mehrere Teams ist.

Mein Team hat ein erweitertes Büro, also zwei Räume, die durch eine Tür getrennt sind. Die steht eigentlich immer offen, außer es telefoniert mal jemand länger oder es gibt Stress. Dadurch bin ich direkt aufmerksam, falls ich ins Büro komme und die Zwischentür geschlossen ist – dann liegt meistens etwas in der Luft. In dem Unternehmen herrscht glaube ich die Wahrnehmung, dass Einzel- oder Zweierbüros vorteilhaft sind. Ein Büro mit vier Personen zählt quasi schon als Großraumbüro. An meinem ersten Tag werde ich also zu einem kleinen, leeren Büro ein paar Türen weiter geführt. „So, und das ist dein Arbeitsplatz“. Puh, schwierig! Auch wenn es nur ein paar Meter weiter ist – hier bekomme ich überhaupt nichts vom Team mit. Da könnte ich auch Home Office machen. Zum Glück ist im Teambüro noch Platz, zumindest nachdem ein paar als Ablage genutzte Tische umgestellt werden. Wir finden sogar einen Monat später einen Arbeitsplatz für den neuen Entwickler und werden somit offiziell zum „Großraumbüro“.

Mein Team macht zunächst große Augen, als ich die Absicht bekunde, täglich bei ihnen zu sitzen. Die erste Reaktion, halb ernst, halb im Spaß: „Dann müssen wir ja aufpassen, was wir sagen!“ Ich bin überrascht und auch etwas irritiert. In bisherigen Projekten war es immer selbstverständlich, dass ich beim Team sitze und wenn das mal nicht möglich war, hat sich das Team regelmäßig darüber beschwert.

An meinem Arbeitsplatz im Teambüro bekomme ich jede Menge wichtige Infos:

  • Darüber, wie zusammengearbeitet und gepairt wird
  • Darüber, wer sich versteht und nicht so gut versteht
  • Darüber, wie die Kommunikation, zwischen den beiden Teil-Büros funktioniert
  • Darüber, wenn plötzlich überlegt wird, ob das untere Ticket nicht eigentlich doch eine viel höhere Prio hat
  • Darüber, wie das Onbording neuer Teammitglieder läuft

Und auch über sonstige Gewohnheiten im Team weiß ich nach einer Woche ziemlich genau Bescheid (ein Teammitglied macht in seiner verlängerten Mittagspause Sport, ein anderer fastet drei Tage die Woche, der dritte isst regelmäßig Fried Chicken im Büro). Alles wichtige Infos, die ich nicht (oder erst deutlich später) gehabt hätte, wenn ich nicht im Teambüro sitzen würde. Ok, bis auf das mit dem Fried Chicken, das riecht man auch noch zwei Räume weiter! 😀

Kennenlerngespräche

In den ersten Tagen und Wochen schnappe ich mir jedes Teammitglied für ein Kennenlerngespräch unter vier Augen. Ich plane ca. 45-60 min ein und frage, ob wir zusammen einen Kaffee trinken gehen wollen, um uns ein bisschen besser kennen zu lernen. Im Prinzip bringe ich die Leute zum reden. Meistens braucht es dafür nicht viel. Ich frage sie, wie ihr bisheriger Weg war – sowohl örtlich, ausbildungstechnisch, als auch beruflich und im Unternehmen (Wichtigkeit zunehmend). Dann frage ich, was sie an der Arbeit in diesem Unternehmen und Team mögen, was ihnen an der Arbeit Spaß macht, was sie motiviert und antreibt. Auf der anderen Seite auch, was sie nervt und was sie anstrengend finden. Dann klopfe ich ab, welche Erfahrungen sie mit agilen Arbeitsweisen und Scrum haben und wie ihre Einschätzung dazu ist. Außerdem frage ich sie explizit, was sie von mir als Scrum Master erwarten. Was sollte ich auf jeden Fall tun? Was sollte ich auf gar keinen Fall tun? Welches Thema sollte ich als erstes angehen? Seitdem ich bei der Frage nach Erwartungen an meine Rolle schon mehrmals wie ein Auto angeschaut wurde, kündige ich diese Frage meistens schon vor den Gespräch an, sodass sich die Leute darauf vorbereiten können.

Das Netzwerk ums Team

Ein Team kann man eigentlich nie losgelöst von seiner Umgebung betrachten. Es gibt andere Personen, Teams, Abteilungen zu denen Kontaktpunkte, Schnittstellen und Abhängigkeiten bestehen. Um zu verstehen, wie ein Team funktioniert, muss man auch sein Umfeld kennenlernen. Mein Team hat keine Abhängigkeiten zu anderen Softwareentwicklungsteams, aber enge Kontaktpunkten zu mehreren Personen mit verschiedenen Rollen außerhalb des Teams:

  • technische Fachexperten, die Anforderungen von Kunden ans Team „übersetzen“
  • technische Fachexperten, die Ansprechpartner für die Kunden bei Problemen sind
  • Projektmanager
  • Quality Manager
  • Safety Manager
  • verschiedene Führungskräfte

Diese Rollen und ihre Aufgaben zu verstehen ist gar nicht so einfach, weil es auch innerhalb des Teams und der Abteilung nicht so ganz klar ist, was die anderen Rollen eigentlich machen. Zumindest gibt es keine einheitliche Sichtweise, oft genug bekomme ich auf meine Fragen diesbezüglich die Antwort „gute Frage, das weiß ich ehrlich gesagt auch nicht so genau“.

Schreib es auf

Gerade am Anfang lerne man so viele Leute und Themen kennen, dass man schnell den Überblick verliert. Deshalb kann ich Notizen definitiv empfehlen. An sich denke ich von mir, dass ich ein ganz gutes Gedächtnis habe. Aber gerade zum Start von einem neuen Projekt prasseln so viele neue Informationen auf einen ein, da ist es ganz natürlich, Dinge zu vergessen. Außerdem hilft mir das Aufschreiben dabei, nochmal zu reflektieren und mich selbst zu sortieren. Deswegen nehme ich mir gerade am Anfang bewusst Zeit, um durch meine Notizen zu gehen und Dinge zu ergänzen. Entweder wenn ich im Laufe des Tages Zeit dafür finde, ansonsten am Ende des Tages. Ich notiere zum Beispiel wie Meetings ablaufen, Dinge, die mir auffallen, wichtige Infos aus Gesprächen, wie die Teamdynamik ist, wie die Abteilung / das Unternehmen funktioniert sind und – meine wichtigste Notiz – das Improvement Backlog. Aktuell nutze ich die Notizen App auf Laptop und Handy. Ich hatte aber auch schon Phasen, wo ich ein physisches Notizbuch genutzt habe. Das Format ist eigentlich egal, Hauptsache es funktioniert für dich!