Führung im Kontext agiler Methoden, Teil 1: Scrum
Durch Agile Transformationen und Selbstorganisation werden Macht und Führung nicht aus der Welt geschafft, sie müssen nur neu betrachtet und verhandelt werden. Für Organisationen und Führungskräfte bedeutet dies ein hohes Maß an Unsicherheit. In unserer Serie „Führung im Kontext agiler Methoden“ wollen wir auf die bekanntesten agilen Frameworks, Methoden und Ansätze eingehen und deren Implikationen auf Führung und Führungskräfte aufzeigen. In Teil 1 widmen wir uns Scrum.
Scrum – ein Überblick
Scrum ist in den 90er-Jahren entstanden und wird seit 2009 durch den Scrum Guide von Ken Schwaber und Jeff Sutherland definiert. Im aktuellen Annual State of Agile Report wird Scrum ein
weltweiter Marktanteil von 66 % attestiert, das heißt, dass zwei Drittel aller Organisationen unter Agilität auf Teamebene Scrum verstehen. Aus diesem Grund werden Scrum und Agilität gerne
synonym verwendet oder Agile Organisationen mit der Verwendung von Scrum gleichgesetzt.
In diesem Artikel soll Scrum nur in groben Zügen vorgestellt werden. Für einen genaueren Blick lohnt es sich, den Scrum Guide zu lesen, der auf 14 Seiten Scrum komplett beschreibt. Dass es nur so wenige Seiten sind, erklärt sich daraus, dass Scrum lediglich ein Framework ist und keine Methodik oder detailliertes Kochbuch. Scrum gibt Teams zwar einen fixen Rahmen vor, innerhalb dessen sich die Arbeitsweise und Praktiken allerdings stark unterscheiden können. Im Framework definiert werden Rollen, Events und Artefakte und die Art und Weise, wie diese zusammenspielen.
Das Scrum Framework
In Scrum wird in kurzen Iterationen, sogenannten Sprints, gearbeitet. Alle ausstehenden Arbeiten werden im Product Backlog nach Kundenwert priorisiert gewartet und am Anfang jedes Sprints im sogenannten Sprint Planning nimmt sich das Scrum Team ein Ziel vor, das Sprint Goal, und definiert dann, was aus dem Product Backlog es machen muss, um das zu erfüllen. Dies heißt dann Sprint Backlog. Während des Sprints tauschen sich die Umsetzer:innen (Developer) laufend aus und planen gegebenenfalls neu (Daily Scrum) und am Ende steht ein Increment. Vereinfacht lässt sich ein Increment als Mindset beschreiben, nämlich als Einstellung, dass am Ende eines Sprints tatsächlich etwas entstanden ist, das verwendbar und sinnvoll ist. Dann wird geschaut, was entstanden ist (Sprint Review) und wie es entstanden ist (Sprint Retrospective) und es werden Verbesserungen identifiziert. Danach geht es mit dem nächsten Sprint weiter. In diesem stetigen Ablauf sorgt die Rolle Product Owner dafür, dass der Product Backlog stets aktuell und transparent ist und der ursprünglichen Zielsetzung folgt (Product Goal) und die Rolle Scrum Master kümmert sich darum, dass der Prozess gut läuft und das Team gut zusammenarbeiten kann.
Braucht es bei Scrum noch Führungskräfte?
Die oben dargestellte, zugegebenermaßen stark verkürzte und vereinfachte Beschreibung von Scrum macht deutlich, warum sich viele Führungskräfte mit Scrum schwertun. Einfach gesagt, weil sie in dieser Beschreibung nicht vorkommen. Scrum beschreibt ein Team, das Scrum Team, aber nicht mehr als das. Des Weiteren tituliert der Scrum Guide, seit der letzten Version von November 2020, das Scrum Team als Self-Managed Team. Also keine Manager:innen mehr?
Natürlich nicht. Macht und Führung werden durch Agilität und Selbstorganisation (oder Selbst-Management) nicht obsolet, sondern nur anders definiert und verteilt. Auch Führungskräfte wird es in Agilen Organisationen der Zukunft, mit wenigen Ausnahmen wie etwa in holakratischen Organisationen, noch brauchen.
Doch was bedeutet es konkret eine Führungskraft im Umgang mit einem Scrum Team zu sein?
Scrum Führungskräfte gestalten das Umfeld
Scrum ist ein Framework das Scrum Teams erfolgreich machen möchte. Die Aufgabe von Führungskräften ist es, ein Umfeld zu schaffen, das es den Teams auch erlaubt, erfolgreich zu sein. Viele Organisationen interpretieren Scrum als Spielwiese für Teams, vergessen aber diese Spielwiese entsprechend zu gestalten und sind dann enttäuscht, dass die Teams beziehungsweise die Agile Transformation nicht erfolgreich sind. Auch die Teams sind enttäuscht, denn sie sehen keine der ihnen versprochenen Vorteile von Scrum.
Wir sehen allerdings noch eine zweite, fast noch gefährlichere Tendenz in Organisationen, nämlich die Gefahr einer Entfremdung. Viele Scrum Teams sind am Anfang schwer mit der Umsetzung von Scrum beziehungsweise mit sich selbst beschäftigt. Der dem Framework innewohnende kontinuierliche Verbesserungsprozess führt dazu, dass die Teams immer besser werden und mehr und mehr Erfolge feiern. In ihrem Wunsch immer besser zu werden, beginnen die Teams dann irgendwann auch nach außen zu blicken und dann … – nichts. Die Organisation möchte sich nicht kontinuierlich verbessern und die Teams erkennen, dass sie unter einer gläsernen Decke stecken. Zurück wollen sie aber auch nicht mehr, dazu haben sie das Agile Mindset schon zu sehr verinnerlicht und sie merken, dass sie mit der Organisation nicht mehr im Einklang sind.
Für beide Situationen benötigt es Führungskräfte, die dies verstehen und entsprechend ein Umfeld gestalten, welches es den Teams erlaubt, erfolgreich nach Scrum zu arbeiten. Dies können einfache Prozess- oder Regelanpassungen sein, unterschiedliche Berichtslinien oder angepasste Kommunikations- und Entscheidungsstrukturen. Und oftmals bedeutet das keine großen Organisationsanpassungen, sondern einfach nur ein offenes Ohr für die Bedürfnisse der Teams oder Übersetzung der Organisationsbedürfnisse in Scrum Sprache oder umgekehrt.
Ich möchte dazu ein Beispiel erzählen: Ich durfte vor ein paar Jahren ein Unternehmen begleiten, das eine stark ausgeprägte und formalisierte Projektkultur hatte. Es war schon bald absehbar, dass die Projektvorgaben und -strukturen das Scrum Team davon abhielten, agil zu arbeiten und relativ schnell wurde abwechselnd Agilität oder Projektcontrolling die Schuld gegeben. Gelöst wurde das Ganze durch einen einfachen zweistündigen Termin, in dem wir die Organisationsbedürfnisse wertgeschätzt und diese auf Agile Kennzahlen und Informationen gemapped haben. Was das mit Führungskräften zu tun hat? Wir hätten das Ganze nicht geschafft, wenn uns eine Führungskraft nicht erklärt hätte, wozu sie all die traditionellen Kennzahlen benötigte und welche Entscheidungen sie darauf basierte. Dadurch wurden uns Transparenz und Freiheit gegeben, die Bedürfnisse hinter den Kennzahlen zu erkennen, tradierte Vorgaben zu hinterfragen und neue Wege zu gehen, ohne der Organisation zu schaden.
Scrum Führungskräfte schaffen Freiräume und Kontext
Agilität bedeutet aus Sicht einer Führungskraft zu delegieren beziehungsweise loszulassen. Doch Selbstorganisation oder im Falle von Scrum Selbstmanagement sind kein Selbstzweck. Der Grund, warum Scrum die Entscheidungsmacht an das Team gibt, ist im Agile Manifesto zu finden: The best architectures, requirements, and designs emerge from self-organizing teams. Die Annahme ist, dass Teams bessere Entscheidungen treffen können als – unausgesprochen – Führungskräfte. Dies liegt daran, dass die Teams näher an der Information und deren Quellen sind und daher bessere Entscheidungsgrundlagen haben. Führungskräfte sollten daher getrost loslassen, sie geben damit die Autorität dorthin, wo die Information ist, also in gute Hände.
Selbstorganisation bedeutet jedoch nicht, dass die Teams im luftleeren Raum agieren und dort tun, und lassen können was sie wollen. Wie es im berühmten Spotify-Video so schön heißt: Autonomy needs Alignment. Und dafür sind Führungskräfte auch im Agilen Kontext zuständig.
Scrum unterscheidet sehr stark zwischen WAS und WIE. Wir geben vor, was entwickelt wird, jedoch nicht wie. Damit wird Kreativität im Team gefördert und das Commitment zu den gefundenen Lösungen erhöht. Um als Führungskraft das WAS mitzugestalten, ist die Teilnahme am Sprint Review unumgänglich. Hier wird der aktuelle Stand hergezeigt, Feedback eingeholt und die weitere inhaltliche Entwicklung diskutiert. Dabei werden alle relevanten Stakeholder eingeladen und die unterschiedlichen Sichtweisen harmonisiert. Dies sind der richtige Ort und die richtige Zeit für Führungskräfte, um formalisiert inhaltliches Feedback zu geben und die Richtung zu gestalten. Die Führungskräfte sollten dabei allerdings vermeiden, über das WIE zu sprechen (diese Autorität bleibt beim Team) oder außerhalb des Sprint Reviews in das Scrum Team zu intervenieren (dies sorgt nur für Unruhe).
Eine der wichtigsten Diskussionen im Sprint Review ist die Orientierung am Product Goal. Im Idealfall richtet sich sämtliche Arbeit eines Scrum Teams an einem gemeinsamen Ziel aus und in jeder Diskussion, vor allem auch während des Sprint Reviews, ist das Product Goal die handlungsleitende Entscheidungsprämisse. Dieses Product Goal wird am Anfang der Entwicklung von dem Product Owner gemeinsam mit Stakeholdern definiert und auch hier ist ein passender Schlüssel, um als Führungskraft die Richtung mitzugestalten.
Insgesamt ist der Product Owner Hauptansprechpartner:in für Führungskräfte, denn alle Vorgaben, Erwartungen und Abhängigkeiten werden vom Product Owner im Product Backlog abgebildet und in eine priorisierte Reihenfolge gebracht.
Scrum Führungskräfte bilden Brücken
Scrum beantwortet die Frage, wie ein Team zusammenarbeiten soll, es beantwortet jedoch – wie wir bereits oben anhand der fehlenden Führungskräfte gesehen haben – nichts, was außerhalb der Scrum Teams liegt. Scrum definiert zwar, dass Product Owner mit den inhaltlichen Stakeholdern zusammenarbeiten und Scrum Master die Organisation in der Zusammenarbeit mit und im Verständnis vom Scrum Team unterstützen sollen, aber das ist in den meisten Fällen zu wenig konkret, um hilfreich zu sein.
Sobald Themen außerhalb des Scrum Teams und in der Organisation liegen, sind Führungskräfte gefragt. Während das Scrum Team autonom in seinem System agiert, orchestrieren Führungskräfte die Brücken und Verbindungen zwischen den Systemen.
Doch auch hier soll es den self-managed Scrum Teams möglich sein, zu wachsen und immer mehr Verantwortung zu übernehmen. Führungskräfte von Scrum Teams orchestrieren also die Interaktionen des Scrum Teams mit der Außenwelt, machen sich dabei aber immer mehr obsolet. Im Idealfall bildet ein Scrum Team ein lebendiges und belastungsfähiges Netzwerk mit der Außenwelt, das losgelöst von Führungskräften funktionieren kann.
In vielen Situationen, vor allem wenn das Scrum Team wechselseitige Abhängigkeiten oder gemeinsam mit Anderen Probleme lösen wollen, so reicht es nicht mehr aus, die Interaktion zu orchestrieren, sondern es benötigt auch Koordinations- und Steuerungsschichten und -regeln. Hier gibt es bereits viele bekannte Ansätze, die gemeinhin unter dem Begriff Agile Skalierung zusammengefasst werden. Zu diesem Thema werden wir in dieser Beitragsserie noch einiges hören, hier sei jetzt nur so viel gesagt: Führungskräfte von Scrum Teams ermöglichen den Erfolg von Scrum Teams, indem sie deren Umfeld betrachten und gegebenenfalls auch Strukturen außerhalb von Scrum schaffen, ohne die erfolgreiche Umsetzung von Scrum zu gefährden.
8 Tipps für Führungskräfte von Scrum Teams
Scrum ist ein weitverbreitetes und erfolgreiches Framework für agiles Arbeiten, das für Führungskräfte eine große Herausforderung bereithält: Es gibt keine Antworten darauf, wie Führungskräfte mit Scrum Teams umzugehen haben. Deswegen haben wir für Führungskräfte folgende Empfehlungen:
- Das Scrum Team ist ein self-managed Team und braucht aus der Sicht der Arbeit im Team keinerlei Zutun von Führungskräften.
- Scrum Teams brauchen ein Umfeld, das es ihnen erlaubt, erfolgreich Scrum umzusetzen. Sorgen Sie für ausreichend Freiraum und Kontext.
- Nehmen Sie am Sprint Review teil, geben Sie Feedback und teilen Sie klar Ihre Erwartungshaltung mit. Dies gibt dem Scrum Team ausreichend Richtung vor, um eigene Entscheidungen treffen zu können.
- Kommunizieren Sie Ihr inhaltliches Feedback an die Rolle Product Owner und akzeptieren Sie deren Autorität.
- Vertrauen Sie darauf, dass im Team bessere Entscheidungen getroffen werden. Das Scrum Team ist näher an der Information.
- Unterstützen Sie das Scrum Team bei der Interaktion mit der Außenwelt und bilden Sie die Brücke in die Organisation und das Management.
- Bleiben Sie dabei transparent und ermöglichen Sie es dem Team sein eigenes Netzwerk aufzubauen.
- Wenn Sie mehrere Scrum Teams haben, die gemeinsam arbeiten, sorgen Sie für wertstiftende und nachhaltige Strukturen, um dies erfolgreich zu ermöglichen (Agile Skalierung).
Über den Autor
Gregor Habinger ist Neuwaldegger Berater und Agile-Experte. In dieser Blog-Serie wird er sich in den kommenden Monaten jedes Mal mit einem anderen kniffligen Thema rund um Agiles Arbeiten & Führung annehmen. Er nutzt dafür seine langjährige Erfahrung in der Begleitung agiler Transformationen, seine eigenen Erfahrungen im agilen Arbeiten und seine Expertise als Führungskraft im IT-Bereich.
Links, die Sie interessieren könnten
arrow_backFokusseite Agile Transformation
arrow_backAgile Organisation Beratung
arrow_backDiagnose-Workshop zur Agilen Transformation
arrow_backBlogbeiträge
arrow_backBuch Moving Organizations