TL;DR

Scrum: Simple to Understand, Difficult to Master“.
Aller Anfang ist also schwer. Warum also nicht einfach mal einen Anfang dokumentieren und das Vorgehen beschreiben, damit es für andere etwas leichter wird?
Demnächst halte ich euch über meine ersten Schritte als Scrum Master in einem neuen Team auf dem Laufenden. Stay tuned!

Es ist wieder soweit: In kurzer Zeit werde ich wieder als Scrum Master in einem neuen Team starten. Ich bin gespannt, weiß noch nicht genau, was auf mich zukommt, freue mich aber auf die neue Herausforderung. Ich habe mir überlegt, euch im Rahmen einer Artikel-Serie an meinem Start im neuen Team teilhaben zu lassen. Das heißt die ersten Wochen und Monate werde ich darüber berichten, was ich meine ersten Schritte sind, welche Themen ich als Erstes angehe, welche Methoden und Tools ich nutze, und vor welchen Herausforderungen und Problemen ich stehe.

Bisherige Infos

Viel weiß ich noch nicht über das Team. Es besteht aktuell aus drei Entwicklern, von denen ich zwei ganz kurz kennengelernt habe. Sie haben weder einen dedizierten Product Owner, noch einen dedizierten Scrum Master. Die Rollen sind über mehrere Personen innerhalb und außerhalb des Teams verteilt. Das Team arbeitet bereits seit ca.  2 Jahren mehr oder weniger nach dem Scrum Framework. Ein ehemaliges Teammitglied war Befürworter des Frameworks und hatte angefangen, es “bottom-up” im Team zu etablieren. Nach seinem Weggang ist das ganze allerdings etwas degeneriert: es fehlte an theoretischem und praktischen Know-How, die Produkt Owner und Scrum Master Rollen wurden nicht besetzt und das Team stand im vergangenen Jahr ziemlich unter Zeitdruck. Wichtig zu wissen ist außerdem, dass das Team Software für einen sicherheitskritischen Bereich entwickelt. Das heißt, es müssen gewisse Standards eingehalten werden und im Unternehmen ist noch nicht klar, wie man diese formalen Vorgaben mit agilen Arbeitsweisen „verheiraten“ kann.

Mein Auftrag

Situationsbedingt übernimmt zur Zeit auch die Führungskraft der Entwickler Teile der Scrum Master und Product Owner Rollen. Diese sollen aber so bald wie möglich anderweitig besetzt werden. Ich werde die Scrum Master Rolle zunächst übernehmen, bis die Rolle unternehmensintern besetzt werden kann. Dadurch werde ich hoffentlich die Führungskraft entlasten und im Team die Grundlagen zu Scrum und agilen Arbeitsweisen legen bzw. die vorhandenen Grundlagen stabilisieren und ausbauen. Zunächst muss ich mir einen Überblick verschaffen, wie der Stand ist und mit welchen Themen das Team zu kämpfen hat.

Positiv überrascht bin ich von der Aussage der Führungskraft, dass er es als seine Aufgabe ansieht Impediments zu lösen, die vom Team bzw. von mir als Scrum Master nicht gelöst werden können. Gerade als externer Berater ist ein guter Draht zum Management wichtig, denn wenn man etwas verändern will braucht man jemanden an Board, der auf höherer Ebenen etwas verändern kann und Veränderung mit vorantreibt.

Scheinbar gibt es noch einiges zu tun, sowohl im Team, als auch im Unternehmen. Es gibt Befürworter agiler Arbeitsweisen, aber auch Skeptiker. Teilweise wissen die Mitarbeiter gar nicht genau, was agiles Arbeiten überhaupt genau bedeutet. Das wird sich hoffentlich bald ändern 😀

Na dann, auf gehts! Viel Spaß beim Verfolgen meiner Erlebnisse als Scrum Master in meinem neuen Team. Vielleicht könnt ihr ja etwas mitnehmen.