• Verän­de­rung
  • Führung
  • Purpose und Stra­tegie
  • Agile Orga­ni­sa­tion
  • Weiter­bil­dung
  • DE
  • EN
search close

Vereinbaren Sie jetzt ein unverbindliches Beratungsgespräch

Lassen Sie uns bei einem gemeinsamen Telefonat auf Ihre aktuelle Situation schauen! Wir rufen Sie gern zurück!

[contact-form-7 404 "Nicht gefunden"]
  • Start­seite
  • Über uns
    • Purpose
    • Team
    • Kunden
    • Geschichte
  • Bera­tung
    • Verän­de­rung
    • Führung
    • Purpose & Stra­tegie
      • Case HR-Stra­­tegie neu Verkehrs­be­trieb
    • Agile Orga­ni­sa­tion
  • Weiter­bil­dung
    • Neuwald­egger Curri­culum
    • Neuwald­egger Change Campus
    • Neuwald­egger Coaching Campus
    • Gender Equa­lity Lab
    • Agile Leader­ship Campus
    • Purpose Driven Orga­niza­tions Work­shop
    • Agiler Frei­raum
    • Rema­king Orga­niza­tions
    • Virtual Archi­tects
    • Events
  • Publi­ka­tionen
    • Bücher & Artikel
    • Blog
    • News­letter
    • Podcast
  • Kontakt
    • Ando­cken
    • Abon­nieren
    • Anreisen
  • Fokus
    • Agile Trans­for­ma­tion
    • Purpose Driven Orga­niza­tion
Foto: REDPIXEL​.PL

Führung im Kontext agiler Methoden, Teil 1: Scrum

Durch Agile Trans­for­ma­tionen und Selbst­or­ga­ni­sa­tion werden Macht und Führung nicht aus der Welt geschafft, sie müssen nur neu betrachtet und verhan­delt werden. Für Orga­ni­sa­tionen und Führungs­kräfte bedeutet dies ein hohes Maß an Unsi­cher­heit. In unserer Serie „Führung im Kontext agiler Methoden“ wollen wir auf die bekann­testen agilen Frame­works, Methoden und Ansätze eingehen und deren Impli­ka­tionen auf Führung und Führungs­kräfte aufzeigen. In Teil 1 widmen wir uns Scrum.

Scrum – ein Über­blick

Scrum ist in den 90er-Jahren entstanden und wird seit 2009 durch den Scrum Guide von Ken Schwaber und Jeff Suther­land defi­niert. Im aktu­ellen Annual State of Agile Report wird Scrum ein
welt­weiter Markt­an­teil von 66 % attes­tiert, das heißt, dass zwei Drittel aller Orga­ni­sa­tionen unter Agilität auf Team­ebene Scrum verstehen. Aus diesem Grund werden Scrum und Agilität gerne
synonym verwendet oder Agile Orga­ni­sa­tionen mit der Verwen­dung von Scrum gleich­ge­setzt.

In diesem Artikel soll Scrum nur in groben Zügen vorge­stellt 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 ledig­lich ein Frame­work ist und keine Methodik oder detail­liertes Koch­buch. Scrum gibt Teams zwar einen fixen Rahmen vor, inner­halb dessen sich die Arbeits­weise und Prak­tiken aller­dings stark unter­scheiden können. Im Frame­work defi­niert werden Rollen, Events und Arte­fakte und die Art und Weise, wie diese zusam­men­spielen.

Das Scrum Frame­work

In Scrum wird in kurzen Itera­tionen, soge­nannten Sprints, gear­beitet. Alle ausste­henden Arbeiten werden im Product Backlog nach Kunden­wert prio­ri­siert gewartet und am Anfang jedes Sprints im soge­nannten Sprint Plan­ning nimmt sich das Scrum Team ein Ziel vor, das Sprint Goal, und defi­niert 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 (Deve­loper) laufend aus und planen gege­be­nen­falls neu (Daily Scrum) und am Ende steht ein Incre­ment. Verein­facht lässt sich ein Incre­ment als Mindset beschreiben, nämlich als Einstel­lung, dass am Ende eines Sprints tatsäch­lich etwas entstanden ist, das verwendbar und sinn­voll ist. Dann wird geschaut, was entstanden ist (Sprint Review) und wie es entstanden ist (Sprint Retro­s­pec­tive) und es werden Verbes­se­rungen iden­ti­fi­ziert. 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 trans­pa­rent ist und der ursprüng­li­chen Ziel­set­zung folgt (Product Goal) und die Rolle Scrum Master kümmert sich darum, dass der Prozess gut läuft und das Team gut zusam­men­ar­beiten kann.

Braucht es bei Scrum noch Führungs­kräfte?

Die oben darge­stellte, zuge­ge­be­ner­maßen stark verkürzte und verein­fachte Beschrei­bung von Scrum macht deut­lich, warum sich viele Führungs­kräfte mit Scrum schwertun. Einfach gesagt, weil sie in dieser Beschrei­bung nicht vorkommen. Scrum beschreibt ein Team, das Scrum Team, aber nicht mehr als das. Des Weiteren titu­liert der Scrum Guide, seit der letzten Version von November 2020, das Scrum Team als Self-Managed Team. Also keine Manager:innen mehr?

Natür­lich nicht. Macht und Führung werden durch Agilität und Selbst­or­ga­ni­sa­tion (oder Selbst-Manage­ment) nicht obsolet, sondern nur anders defi­niert und verteilt. Auch Führungs­kräfte wird es in Agilen Orga­ni­sa­tionen der Zukunft, mit wenigen Ausnahmen wie etwa in hola­kra­ti­schen Orga­ni­sa­tionen, noch brau­chen.

Doch was bedeutet es konkret eine Führungs­kraft im Umgang mit einem Scrum Team zu sein?

Scrum Führungs­kräfte gestalten das Umfeld

Scrum ist ein Frame­work das Scrum Teams erfolg­reich machen möchte. Die Aufgabe von Führungs­kräften ist es, ein Umfeld zu schaffen, das es den Teams auch erlaubt, erfolg­reich zu sein. Viele Orga­ni­sa­tionen inter­pre­tieren Scrum als Spiel­wiese für Teams, vergessen aber diese Spiel­wiese entspre­chend zu gestalten und sind dann enttäuscht, dass die Teams bezie­hungs­weise die Agile Trans­for­ma­tion nicht erfolg­reich sind. Auch die Teams sind enttäuscht, denn sie sehen keine der ihnen verspro­chenen Vorteile von Scrum.

Wir sehen aller­dings noch eine zweite, fast noch gefähr­li­chere Tendenz in Orga­ni­sa­tionen, nämlich die Gefahr einer Entfrem­dung. Viele Scrum Teams sind am Anfang schwer mit der Umset­zung von Scrum bezie­hungs­weise mit sich selbst beschäf­tigt. Der dem Frame­work inne­woh­nende konti­nu­ier­liche Verbes­se­rungs­pro­zess 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 irgend­wann auch nach außen zu blicken und dann … – nichts. Die Orga­ni­sa­tion möchte sich nicht konti­nu­ier­lich verbes­sern 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 verin­ner­licht und sie merken, dass sie mit der Orga­ni­sa­tion nicht mehr im Einklang sind.

Für beide Situa­tionen benö­tigt es Führungs­kräfte, die dies verstehen und entspre­chend ein Umfeld gestalten, welches es den Teams erlaubt, erfolg­reich nach Scrum zu arbeiten. Dies können einfache Prozess- oder Regel­an­pas­sungen sein, unter­schied­liche Berichts­li­nien oder ange­passte Kommu­ni­ka­tions- und Entschei­dungs­struk­turen. Und oftmals bedeutet das keine großen Orga­ni­sa­ti­ons­an­pas­sungen, sondern einfach nur ein offenes Ohr für die Bedürf­nisse der Teams oder Über­set­zung der Orga­ni­sa­ti­ons­be­dürf­nisse in Scrum Sprache oder umge­kehrt.

Ich möchte dazu ein Beispiel erzählen: Ich durfte vor ein paar Jahren ein Unter­nehmen begleiten, das eine stark ausge­prägte und forma­li­sierte Projekt­kultur hatte. Es war schon bald absehbar, dass die Projekt­vor­gaben und -struk­turen das Scrum Team davon abhielten, agil zu arbeiten und relativ schnell wurde abwech­selnd Agilität oder Projekt­con­trol­ling die Schuld gegeben. Gelöst wurde das Ganze durch einen einfa­chen zwei­stün­digen Termin, in dem wir die Orga­ni­sa­ti­ons­be­dürf­nisse wert­ge­schätzt und diese auf Agile Kenn­zahlen und Infor­ma­tionen gemapped haben. Was das mit Führungs­kräften zu tun hat? Wir hätten das Ganze nicht geschafft, wenn uns eine Führungs­kraft nicht erklärt hätte, wozu sie all die tradi­tio­nellen Kenn­zahlen benö­tigte und welche Entschei­dungen sie darauf basierte. Dadurch wurden uns Trans­pa­renz und Frei­heit gegeben, die Bedürf­nisse hinter den Kenn­zahlen zu erkennen, tradierte Vorgaben zu hinter­fragen und neue Wege zu gehen, ohne der Orga­ni­sa­tion zu schaden.

Scrum Führungs­kräfte schaffen Frei­räume und Kontext

Agilität bedeutet aus Sicht einer Führungs­kraft zu dele­gieren bezie­hungs­weise loszu­lassen. Doch Selbst­or­ga­ni­sa­tion oder im Falle von Scrum Selbst­ma­nage­ment sind kein Selbst­zweck. Der Grund, warum Scrum die Entschei­dungs­macht an das Team gibt, ist im Agile Mani­festo zu finden: The best archi­tec­tures, requi­re­ments, and designs emerge from self-orga­ni­zing teams. Die Annahme ist, dass Teams bessere Entschei­dungen treffen können als – unaus­ge­spro­chen – Führungs­kräfte. Dies liegt daran, dass die Teams näher an der Infor­ma­tion und deren Quellen sind und daher bessere Entschei­dungs­grund­lagen haben. Führungs­kräfte sollten daher getrost loslassen, sie geben damit die Auto­rität dorthin, wo die Infor­ma­tion ist, also in gute Hände.

Selbst­or­ga­ni­sa­tion bedeutet jedoch nicht, dass die Teams im luft­leeren Raum agieren und dort tun, und lassen können was sie wollen. Wie es im berühmten Spotify-Video so schön heißt: Auto­nomy needs Alignment. Und dafür sind Führungs­kräfte auch im Agilen Kontext zuständig.

Scrum unter­scheidet sehr stark zwischen WAS und WIE. Wir geben vor, was entwi­ckelt wird, jedoch nicht wie. Damit wird Krea­ti­vität im Team geför­dert und das Commit­ment zu den gefun­denen Lösungen erhöht. Um als Führungs­kraft das WAS mitzu­ge­stalten, ist die Teil­nahme am Sprint Review unum­gäng­lich. Hier wird der aktu­elle Stand herge­zeigt, Feed­back einge­holt und die weitere inhalt­liche Entwick­lung disku­tiert. Dabei werden alle rele­vanten Stake­holder einge­laden und die unter­schied­li­chen Sicht­weisen harmo­ni­siert. Dies sind der rich­tige Ort und die rich­tige Zeit für Führungs­kräfte, um forma­li­siert inhalt­li­ches Feed­back zu geben und die Rich­tung zu gestalten. Die Führungs­kräfte sollten dabei aller­dings vermeiden, über das WIE zu spre­chen (diese Auto­rität bleibt beim Team) oder außer­halb des Sprint Reviews in das Scrum Team zu inter­ve­nieren (dies sorgt nur für Unruhe).

Eine der wich­tigsten Diskus­sionen im Sprint Review ist die Orien­tie­rung am Product Goal. Im Ideal­fall richtet sich sämt­liche Arbeit eines Scrum Teams an einem gemein­samen Ziel aus und in jeder Diskus­sion, vor allem auch während des Sprint Reviews, ist das Product Goal die hand­lungs­lei­tende Entschei­dungs­prä­misse. Dieses Product Goal wird am Anfang der Entwick­lung von dem Product Owner gemeinsam mit Stake­hol­dern defi­niert und auch hier ist ein passender Schlüssel, um als Führungs­kraft die Rich­tung mitzu­ge­stalten.
Insge­samt ist der Product Owner Hauptansprechpartner:in für Führungs­kräfte, denn alle Vorgaben, Erwar­tungen und Abhän­gig­keiten werden vom Product Owner im Product Backlog abge­bildet und in eine prio­ri­sierte Reihen­folge gebracht.

Scrum Führungs­kräfte bilden Brücken

Scrum beant­wortet die Frage, wie ein Team zusam­men­ar­beiten soll, es beant­wortet jedoch – wie wir bereits oben anhand der fehlenden Führungs­kräfte gesehen haben – nichts, was außer­halb der Scrum Teams liegt. Scrum defi­niert zwar, dass Product Owner mit den inhalt­li­chen Stake­hol­dern zusam­men­ar­beiten und Scrum Master die Orga­ni­sa­tion in der Zusam­men­ar­beit mit und im Verständnis vom Scrum Team unter­stützen sollen, aber das ist in den meisten Fällen zu wenig konkret, um hilf­reich zu sein.

Sobald Themen außer­halb des Scrum Teams und in der Orga­ni­sa­tion liegen, sind Führungs­kräfte gefragt. Während das Scrum Team autonom in seinem System agiert, orches­trieren Führungs­kräfte die Brücken und Verbin­dungen zwischen den Systemen.

Doch auch hier soll es den self-managed Scrum Teams möglich sein, zu wachsen und immer mehr Verant­wor­tung zu über­nehmen. Führungs­kräfte von Scrum Teams orches­trieren also die Inter­ak­tionen des Scrum Teams mit der Außen­welt, machen sich dabei aber immer mehr obsolet. Im Ideal­fall bildet ein Scrum Team ein leben­diges und belas­tungs­fä­higes Netz­werk mit der Außen­welt, das losge­löst von Führungs­kräften funk­tio­nieren kann.

In vielen Situa­tionen, vor allem wenn das Scrum Team wech­sel­sei­tige Abhän­gig­keiten oder gemeinsam mit Anderen Probleme lösen wollen, so reicht es nicht mehr aus, die Inter­ak­tion zu orches­trieren, sondern es benö­tigt auch Koor­di­na­tions- und Steue­rungs­schichten und -regeln. Hier gibt es bereits viele bekannte Ansätze, die gemeinhin unter dem Begriff Agile Skalie­rung zusam­men­ge­fasst werden. Zu diesem Thema werden wir in dieser Beitrags­serie noch einiges hören, hier sei jetzt nur so viel gesagt: Führungs­kräfte von Scrum Teams ermög­li­chen den Erfolg von Scrum Teams, indem sie deren Umfeld betrachten und gege­be­nen­falls auch Struk­turen außer­halb von Scrum schaffen, ohne die erfolg­reiche Umset­zung von Scrum zu gefährden.

8 Tipps für Führungs­kräfte von Scrum Teams

Scrum ist ein weit­ver­brei­tetes und erfolg­rei­ches Frame­work für agiles Arbeiten, das für Führungs­kräfte eine große Heraus­for­de­rung bereit­hält: Es gibt keine Antworten darauf, wie Führungs­kräfte mit Scrum Teams umzu­gehen haben. Deswegen haben wir für Führungs­kräfte folgende Empfeh­lungen:

  • Das Scrum Team ist ein self-managed Team und braucht aus der Sicht der Arbeit im Team keinerlei Zutun von Führungs­kräften.
  • Scrum Teams brau­chen ein Umfeld, das es ihnen erlaubt, erfolg­reich Scrum umzu­setzen. Sorgen Sie für ausrei­chend Frei­raum und Kontext.
  • Nehmen Sie am Sprint Review teil, geben Sie Feed­back und teilen Sie klar Ihre Erwar­tungs­hal­tung mit. Dies gibt dem Scrum Team ausrei­chend Rich­tung vor, um eigene Entschei­dungen treffen zu können.
  • Kommu­ni­zieren Sie Ihr inhalt­li­ches Feed­back an die Rolle Product Owner und akzep­tieren Sie deren Auto­rität.
  • Vertrauen Sie darauf, dass im Team bessere Entschei­dungen getroffen werden. Das Scrum Team ist näher an der Infor­ma­tion.
  • Unter­stützen Sie das Scrum Team bei der Inter­ak­tion mit der Außen­welt und bilden Sie die Brücke in die Orga­ni­sa­tion und das Manage­ment.
  • Bleiben Sie dabei trans­pa­rent und ermög­li­chen Sie es dem Team sein eigenes Netz­werk aufzu­bauen.
  • Wenn Sie mehrere Scrum Teams haben, die gemeinsam arbeiten, sorgen Sie für wert­stif­tende und nach­hal­tige Struk­turen, um dies erfolg­reich zu ermög­li­chen (Agile Skalie­rung).

Über den Autor

Gregor Habinger ist Neuwald­egger Berater und Agile-Experte. In dieser Blog-Serie wird er sich in den kommenden Monaten jedes Mal mit einem anderen kniff­ligen Thema rund um Agiles Arbeiten & Führung annehmen. Er nutzt dafür seine lang­jäh­rige Erfah­rung in der Beglei­tung agiler Trans­for­ma­tionen, seine eigenen Erfah­rungen im agilen Arbeiten und seine Exper­tise als Führungs­kraft im IT-Bereich.

Links, die Sie inter­es­sieren könnten

arrow_backFokus­seite Agile Trans­for­ma­tion
arrow_backAgile Orga­ni­sa­tion Bera­tung
arrow_backDiagnose-Work­shop zur Agilen Trans­for­ma­tion
arrow_backBlog­bei­träge
arrow_backBuch Moving Orga­niza­tions

Versäumen Sie keine span­nenden Blog-Beiträge mehr! Abon­nieren Sie unseren News­letter!

Jetzt Bestellen

Bera­ter­gruppe Neuwaldegg
Gesell­schaft für Unter­neh­mens­be­ra­tung und Orga­ni­sa­ti­ons­ent­wick­lung GmbH

Gregor-Mendel-Straße 35, 1190 Wien
T +43 1 368 80 70, office@​neuwaldegg.​at, www​.neuwaldegg​.at
Firmen­buch-Nr. 69063 p, Handels­ge­richt Wien

News­letter
Impressum
AGB
Daten­schutz

Spre­chen Sie uns an!