Meine Arbeit – wie sieht sie aus, wie fühlt es sich an?
Abstrakt gesagt: Ich will mit meinem Kegelverein ins Trainingslager nach Bulgarien an den Goldstrand fahren. Jeder hat seine Aufgabe: Heiko ist für die Musik zuständig, Jasmin verwaltet die Urlaubskasse und Martin sorgt dafür, dass alle genug zu trinken haben. Alle wissen grob, wo es hingehen soll (Vision), aber jeder hat ein etwas anderes Verständnis davon, wie wir dahin kommen und was für ein Auto wir dafür brauchen. Nun ist es meine Aufgabe ein Auto bereit zu stellen, in dem jeder am Fahrersitz sitzen kann und wir trotzdem heil am Strand ankommen.
In etwas so könnte man meine Rolle beschreiben. Aktuell bin ich Scrum Master für zwei von insgesamt fünf Teams und arbeite täglich mit anderen Scrum Mastern zusammen. Wir arbeiten nach dem Scaled Agile Framework (SAFe), wobei ein Release in vier reguläre Sprints und einen Innovation & Planning Sprint aufgeteilt ist. Im letzteren diskutieren wir innovative Themen außerhalb des normalen Sprintgeschehens und setzen sie selbstorganisiert um.
Hallo, ich bin Philipp – Scrum Master!
Ich komme aus einer Zeit, in der große Softwareprojekte mit Pflichten- und Lastenheften Jahre im Voraus geplant wurden. Riesige, ausgeplottete Gantt-Charts schmückten die Bürowände der Projektleiter – eine Zeit lang wurde es auch die Fototapete für Projektleiter genannt. Die Verantwortung von Umfang, Budget und Zeit spiegelte sich in einem hierarischen Projektorganigramm wieder, an dessen Kopfende sich die Stakeholder und der Projektleiter befanden.
Mittlerweile hat sich einiges geändert und in der agilen Software Entwicklung gibt es nicht mehr den „einen“ Projektleiter. Die Projektverantwortung ist jetzt auf das gesamte Team verteilt, die Planung wird in kurzen Sprints organisiert und anstelle von starren Budget- oder Zeitvorgaben steht der Mehrwert des aktuellen Software Inkrements im Vordergrund. Dadurch gibt es die Rolle des klassischen Projektleiters in der agilen Softwareentwicklung nicht mehr und die Hierarchien sind extrem aufgeweicht.
Aber macht in der agilen Softwareentwicklung nicht jeder was er will?
Ja und Nein. Das Scrum Team inkl. Frontend (Was macht eigentlich…. ein:e Frontend Developer:in bei Netfonds?), Backend, UX/UI, QA und Product Owner (Was macht eigentlich ein:e Product Owner:in bei Netfonds?) haben die Freiheit zu entscheiden WAS im Produkt umgesetzt wird. Der Scrum Master erarbeitet mit dem Team und anderen Scrum Mastern die Prozesse, Methoden und nötigen Weiterbildungen. Er unterstützt dabei das gesamte Team und bestimmt somit das WIE. Mit dieser Freiheit und Selbstorganisation des gesamten Scrum Teams geht auch eine große Verantwortung auf den Erfolg des Produkts einher. Dieser Erfolg und auch Mehrwert der aktuellen Software Version wird am Ende eines Sprints zusammen mit den Fachbereichen und Stakeholder bemessen. Somit kann man nicht sagen, dass jeder machen kann, was er will: Der Weg zum Ziel wird so flexibel wie möglich gestaltet, aber das Ziel ist klar vordefiniert.
Und was genau ist meine Rolle?
Ich arbeite jeden Tag daran, die Teams dabei zu unterstützen das WAS umsetzen zu können und das WIE weiterzuentwickeln. Dazu muss ich ein Umfeld schaffen, in dem sich hoch effiziente, selbstorganisierte Teams entwickeln können. Je eingespielter ein Team ist, desto höher ist die Chance ein großartiges Produkt zu entwickeln, das vom Kunden akzeptiert wird und im aktuellen Markt einen Unterschied macht. Durch eine positive Wahrnehmung wird Vertrauen in die Teams gestärkt.
Aber was bedeutet das genau?
Hoch effizient („Ich muss ein Umfeld schaffen, in dem sich hoch effiziente, selbstorganisierte Teams entwickeln können.“ – Philipp): In Scrum geht es auch immer darum, möglichst ohne Umwege und „Waste“ das Sprintziel umzusetzen. Dabei ist es meine Aufgabe potentielle Hindernisse für das Team aus dem Weg zu räumen und somit die Ablenkungen zu minimieren. Die richtigen Tools zu finden und Prozesse mit den Teams zu definieren um wertvollen Output für das Produkt zu generieren. Das heißt auch, ich darf nicht nur auf die Scrum Teams schauen, sondern muss auch mit gutem Beispiel voran gehen und Voraussetzungen für die Anwendung dieser Tools und Prozessen sowie der Weiterentwicklung eines agilen Mindsets im Unternehmen schaffen.
Selbst organisiert („If you want to achieve great things, you have to stop asking for permission!“ – Thomas Mangold): Ich unterstütze unsere Teams dabei, die passende Produktvision zu finden, zu schärfen, weiterzuentwickeln und jederzeit transparent zu gestalten. Wenn alle dasselbe Verständnis von der Vision haben, können Produktentscheidungen schneller aus den Teams heraus getroffen werden. Bottlenecks verschwinden. Anstelle von einer übergeordneten Hierarchie, treffen die Teams gemeinsam Entscheidungen und verantworten diese auch. Doch aus der Freiheit an Entscheidungen folgt große Verantwortung. Das setzt Mut, Engagement, Vertrauen, Offenheit und Transparenz auf allen Ebenen unserer Teams voraus.
Teams (“Great teams are grown, not hired“ – Pat Kua) : Für komplexe und komplizierte Probleme in der Softwareentwicklung müssen oft kreative Lösungen gefunden werden. Das lässt sich am besten umsetzen, wenn eine kleine Gruppe von Menschen aus unterschiedlichen Perspektiven und Disziplinen auf das Problem schauen. Ein ständiger Austausch innerhalb des eigenen und mit anderen Teams hilft dabei sich einer möglichen Lösung anzunähern. Sobald eine Idee umgesetzt wurde und funktioniert, schweißt das ein Stück weiter zusammen und schafft Vertrauen. Mein Ziel ist es genau dieses Vertrauen zu entwickeln und weiter auszubauen. Teamwork makes the dream work!
Entwickeln („To improve is to change; to be perfect is to change often.“ – Winston Churchill): Aktuelle Technologien, neue Kollegen, geänderte Marktfaktoren, usw. führen dazu, dass ich nie fertig bin, Agilität und Scrum in das Unternehmen zu tragen und mit den Teams auf die neuen Situationen anzupassen. Das ständige Hinterfragen von aktuellen Prozessen und zurückschauen auf den letzten Sprint in den Retros helfen dabei die kontinuierliche Verbesserung und Selbstoptimierung voran zu treiben. Ein „Das haben wir schon immer so gemacht!“ lasse ich nicht gelten.
Was machst du jeden Tag so bei Netfonds?
Die meiste Zeit verbringe ich damit zu erkennen, welche Rolle gerade am dringendsten gebraucht wird. Das setzt voraus, dass ich sehr viel kommuniziere und somit ganz dicht am Puls der Teams und des Unternehmens bin. Gerade in den Regelterminen wie Dailys, Retros, Plannings, I&P Sprints oder einfachen Coffee Talks habe ich die Möglichkeit dazu und übernehme dabei je nach Situation die Rolle des Coaches, Mentors, Faciliators, Advisores oder Role Models ein. Der ständige Austausch in den verschiedenen Rollen nimmt zwar viel Zeit in Anspruch und mein Kalender explodiert manchmal vor Meetings, aber es ist es allemal wert.
Wenn ein konkretes Problem vorliegt, coache ich einzelne Teammitglieder oder ganze Teams. Durch gezielte Fragestellungen, Aufzeigen von Entscheidungsmöglichkeiten oder vielleicht schon ein einfaches Strukturieren der Problemstellung, entstehen gemeinsam vielfältige Lösungen (Coaching).
Manchmal ist es notwendig einzelnen Kollegen direkte Entwicklungsmöglichkeiten auf professioneller und persönlicher Ebene aufzuzeigen (Mentoring). Dabei muss ich herausfinden, in welchem Interessengebiet jeder Einzelne sich wohl fühlt oder hin entwickeln will. Dafür bieten wir externe oder interne Trainings sowie Weiterbildungen an. Es gibt auch Beispiele von Teammitgliedern, die in einen anderen technischen Fachbereich gewechselt sind und sich zum Beispiel als Frontend Entwickler fest in der QA etabliert haben.
Oft kann aber auch eine Anekdote aus dem Berufsleben, anderen Unternehmen oder dem eigenen persönlichen Umfeld bereits für einen Denkanstoß sorgen (Advising). Probleme in Prozessen oder aktuellen Fragestellungen sind oft so oder so ähnlich bereits gelöst worden. Diese gilt es zu finden und gegebenenfalls an die Situation im Team anzupassen.
Damit die Entwicklerteams bei Netfonds zu konkreten Ergebnissen kommen, müssen Workshops oder Meetings organisiert, strukturiert und durchgeführt werden (Facilitating). Das klingt einfacher als es ist, denn jede Stimme sollte gehört werden, gleich viel zählen und die Termine nicht in endlosen Diskussionen enden. Mein Methodenkoffer aus anderen agilen Projekten, Liberating Structures (Link), Tools wie Google Meet und gesundem Menschenverstand helfen mir dabei das richtige Maß zu finden.
Zum Beispiel verwende ich gerne das Format einer Magic Estimation, wenn viele ungeschätzte User Stories im Backlog liegen. Dabei werden ein paar User Stories als Referenzen besprochen und je nach Größe auf der Fibonacci-Folge verteilt. Anschließend schnappt sich jeder im Team ein paar ungeschätzte User Stories und ordnet sie auf der Zahlenfolge in Relation zu den Referenzstories. Das schärft das Verständnis über die einzelnen Aufgaben und noch viel wichtiger, es werden Diskussionen zwischen den Kollegen initiiert. Die Struktur der Magic Estimation hilft mir als Scrum Master zu erkennen, wann eine Diskussion zielführend ist und wann man die Gruppendynamik ändern muss.
Und wie sooft agiere ich dabei nie alleine, sondern stimme mich mit den Teams ab, beratschlage mich mit anderen Scrum Mastern und achte auf die Befindlichkeiten der Stakeholder. Dabei geht es auch immer darum bestimmte Werte und Kulturvorstellungen von Netfonds zu vermitteln (Role Modelling).
Was sind die größten Herausforderungen?
Wie überall spielen die aktuellen Corona Regelungen eine große Rolle. Aktuell wird heiß diskutiert wie ein Arbeiten nach der Pandemie aussehen könnte und welche Voraussetzungen im Büro sowie im Home Office durch Netfonds geschaffen werden sollten. Auch hier wird wieder auf die Bedürfnisse der Teams geschaut, wer, wie und wann vor Ort sein kann. Wir beziehen alle aus den Teams mit ein, sodass alle Vorschläge einbringen können. So dauert die Entscheidungsfindung zwar länger, aber das Ergebnis wird durch alle mitgetragen.
Durch das Remote Arbeiten ziehen sich allerdings auch einige Abstimmungen in die Länge. Wo man früher einfach schnell am Platz mit den Teams gesprochen hat, muss jetzt ein remote Meeting aufgesetzt werden. Mit der Google Suite haben wir sehr effiziente Möglichkeiten zur schnellen Kollaboration. Allerdings kommt dabei natürlich auch der persönliche Umgang etwas zu kurz. Das versuchen wir mit regelmäßigen Spiele Abenden oder auch virtuellen Firmenevents auszugleichen.
Als Scrum Master…
… bin ich nie wirklich “fertig”und es gibt immer etwas zu tun um ein agiles Mindset auf allen Ebenen zu etablieren. Aber der Veränderungswillen ist spürbar vorhanden und es wird jedem Einzelnen die Möglichkeit gegeben diese Veränderung mit zu gestalten und sich einzubringen. Das öffnet den Raum für neue Ideen und kreative Lösungsansätze zu aktuellen Problemen.
Bildquellen:
Canva
https://www.agile42.com/en/wp-content/uploads/sites/2/2020/11/Screenshot-2020-05-04-at-10.23.32.png
