. .

Führung selbstorganisierter Teams – alte Theorie vs. Scrum

Die Rolle des ScrumMasters wird gerne schnell auf die des Moderators und des Organisators reduziert. Das ist schön greifbar und man hat die Erfahrung, dass solche Aufgaben wichtig sind und somit ihre Daseinsbereichtigung haben. ScrumMaster zu sein ist allerdings mehr als das. Es ist eine moderne Art der Führung, ohne disziplinarisch vorgesetzt zu sein. Die Kombination mit der Führung eines selbstorganisierten Teams wirft daher schon lange Fragen auf wie:

  • „How does one lead others who are supposed to lead themselves?“ (vgl. Stewart/Manz, 1995, S. 750.) oder
  • „If self-managing teams are truly self-managing, then why should an external leader be required?“ (Manz /Sims , 1987, S. 106)

Solche Fragen tauchen nicht nur in Scrum auf, sondern begleiten die Forschung und Praxis selbstorganisierter Teams seit jeher. Schon 1986 versuchten sich Manz/Sims in ihrem Artikel “Leading Self-managed Groups: a Concept  Analysis of a Paradox” an einer integrativen Perspektive zur Führungsrolle in selbstorganisierten Teams. Dabei fassen sie auf Grundlage der sozio-technischen Systemtheorie und der sozial-kognitiven Lerntheorie das im Folgenden beschriebene Führungsverhalten zusammen. Da mir beim Lesen und Zusammenstellen vieles doch sehr bekannt vorkam, werde ich einfach die entsprechende Scrum-Sicht der Dinge ergänzen. In diesem Blog die gruppeninternen Aufgaben (direkt auf die Gruppe bezogen) und beim nächsten Mal die Aufgaben/Verhalten an der Grenze von der Gruppe zur Organisation.

Obwohl es in der Darstellung nicht explizit benannt wird, betrachten Manz/Sims (1986, S. 147) externes Führungsverhalten. Vielleicht hilft die Aufstellung dem einen oder anderen bei der Argumentation, warum wirklich ein ScrumMaster pro Team bzw. nur ein Team pro ScrumMaster drin ist!

Aufgaben Teamleitung eines selbstorganisierten Teams nach Manz/Sims Aufgaben des ScrumMasters
Mit dem allgemeinen Ziel, die Leistung des Teams zu steigern, sorgt der externe Teamleiter für die Förderung, Ver- und Bestärkung (und ggf. Unterstützung), nicht Durchführung oder Anleitung der Gruppe (vgl. Manz/Sims, 1986, S. 148f., 150f. ): 

Der ScrumMaster beschützt das Team vor externen Unterbrechungen und Störungen. Er hilft Probleme zu beseitigen, verbessert die Produktivität des Teams, treibt „inspect and adapt“ Zyklen voran. Er ist Moderator und lateraler – d.h. nicht weisungsbefugter – Leiter des Teams. Er arbeitet mit dem Product Owner, um die Rentabilität von Investitionen ins Produkt zu maximieren. Er stellt sicher, dass agile Prinzipien und Ideale verstanden und organisationsweit respektiert werden. Aber: Er ist nicht verantwortlich für die Lieferung des Produkts.
  • gruppeninterne Kommunikation – Austausch und Diskussion von Ideen und Bedenken
  • Der ScrumMaster sollte beim Team sitzen, damit er den Austausch mit Fragen initiieren, oder ggf. das Weiterführen fördern kann
  • Training unerfahrener Mitarbeiter durch das Team – Erschließung der Potenziale der Gruppe
  • Der ScrumMaster sorgt dafür, dass z.B. durch Pairing, Reviews, gemeinsame Plannings etc. der Wissensaufbau und Austausch funktioniert und somit alle bestmöglich beisteuern können
  • Problemlösung im Team – Evaluation und Lösung der eigenen Probleme
  • Der ScrumMaster gibt keine Lösungen vor (selbst wenn ihm sofort eine einfällt) oder Anweisungen, sondern versucht z.B. durch Fragen das Team zur eigenständigen Lösungsfindung und ggf. Alternativenbetrachtung zu bringen
  • teaminterne Arbeitsverteilung – effektive Aufteilung der Aufgaben zwischen Mitgliedern
  • Nicht nur im Daily achtet der SM darauf, dass der nötige Fokus bleibt und die Teammitglieder gemeinsam an der Lösung arbeiten
  • Planung – Koordination und Festlegung der notwendigen Aktivitäten vor der Durchführung
  • Moderation im Sprint Planning 1 und 2 und bei aufkommenden Unklarheiten oder Verbesserungsvorschlägen sorgt für ein gemeinsames Bild und Verständis, bevor man anfängt umzusetzen
  • Selbstbeobachtung / Selbstüberwachung - Gewinnung von Informationen über die eigene Arbeit als Grundlage für Evaluierung, Anpassungen, Soll-Ist Vergleiche bzgl. Zielen und z.B. Bestärkung bei Zielerreichung
  • Einfordern der Transparenz über z.B. die Bearbeitungslänge der Tasks (Punkt drauf, falls es länger als einen Tag dauert), empirische Erhebung und Visualisierung der gelieferten Story oder Function Points pro Sprint, Abweichungen vom Commitment etc. helfen dem Team – der ScrumMaster sorgt “nur” dafür, dass es auch gemacht wird
  • Selbstzielsetzung - Spezifische, realistische, herausfordernde Ziele können die Leistung positiv beeinflussen. Das eigenständige Setzen dieser bietet den Teams Arbeitsziele, an denen sie sich ausrichten können sowie die Basis für Selbstverstärkung bei Zielerreichung.
  • Hauseigen im Commitment angelegt. Das Einfordern gerne mit Hilfe des SM. Auch die Selbstverstärkung bei Zielerreichung kommt oft etwas kurz – geht mal feiern, wenn ihr es geschafft habt … wem nicht nach Feiern zumute ist, sollte das nächste Mal ehrgeiziger committen …
  • Modifikation der Anreize - Selbstbestärkung und Selbstkritik / Selbstbestrafung:
    • Selbstbestärkung sind Belohnungen, über deren Inhalt und Anwendung die Gruppe selbst (und nur selbst), entscheiden kann. Gewünschtes Verhalten wird von der Gruppe anerkannt, gelobt oder anderweitig belohnt und führt somit zu kontinuierlicher Anstrengung.
    • Selbstkritik oder Selbstbestrafung zur Reduktion von unerwünschtem Verhalten sollte offen und konstruktiv unter den Teammitgliedern eingesetzt werden. Zu starker Gebrauch kann zu Nachteilen wie Demotivation, Unzufriedenheit und verminderter Leistung führen. Teams können diese Form der Selbstorganisation jedoch auch (bewusst) vermeiden.
  • Der ScrumMaster sorgt dafür, dass das Team die Möglichkeit zur Modifikation bekommt.
    • Hat das Team momentan nicht die Möglichkeit oder wünscht sich andere Mittel für die Selbstbestärkung, sollte der ScrumMaster sich dafür einsetzen, diese dem Team zur Verfügung zu stellen oder mit dem Team Alternativen erarbeiten.
    • Der ScrumMaster sorgt dafür, dass die Kritik konstruktiv bleibt, jedoch durchaus ausgesprochen wird. Bei Kritik, die immer gegen eine Person geht, geht der ScrumMaster den Gründen nach und versucht diese zu beheben.
  • Proben - Diskussion oder Ausprobieren möglicher Lösungen für Probleme im Team bevor die Umsetzung erfolgt
  • Mit dem SP 2 auch schon im Prozess angelegt, dennoch sollte der SM immer wieder ermutigen, etwas zu skizzieren und auszuprobieren – auch wenn das bei Scrum schon die Umsetzung bedeutet. Verbesserungen bzw. mögliche Problemlösungen werden natürlich spätestens (!!!) in der Retro diskutiert.
Um diese Verhaltensweisen (SLT, gruppenintern) in Teams zu fördern, raten Manz/Sims (13 – S. 152) dem externen Teamleiter zu

  1. Vorleben, Vormachen, „Vorbild sein“ in der spezifischen Strategie zur Selbstorganisation;
  2. Ermutigung und Beratung, Orientierung, Leitung bei der Nutzung sowie
  3. Verstärkung, wenn das Team diese Strategien nutzt.


Am Beispiel Zielsetzungen beschreiben Manz/Sims (13 – S. 152) konkret, dass der Teamleiter den Prozess der eigenen Zielsetzung vormachen oder abbilden (1), Anleitung und Tipps wie Nutzung spezifischer und herausfordernder Ziele und Hilfe bei der z.B. der Formulierung (2) sowie das Verhalten der Zielsetzung bei Beobachtung loben (3) könnten. Sicher auf für ScrumMaster gute Tipps!

Ich finde es immer wieder faszinierend, wie viel in der ScrumMaster Rolle untergebracht ist und wie oft die Organisationen dennoch an ihrer Berechtigung zweifeln. Ein guter ScrumMaster zu sein ist verdammt schwer und mit Sicherheit kann man all diese Punkte nicht von der ersten Stunde an abdecken. Aber wenn man gleich nach einer eventuellen ersten Schonfrist neben dem einen Team noch ein oder zwei weitere aufgebrummt bekommt, nimmt man sich (die Organisation sich selbst) die Möglichkeit zu lernen, zu wachsen und den Nährboden für richtig gute ScrumMaster !!!


Quellen

Manz, C. &  Sims, H.  (1986): Leading Self-managed Groups: a Conceptual Analysis of a Paradox, Economic and Industrial Democracy Vol. 7, S. 141-164.

Stewart, G. & Manz, C. (1995): Leadership for Self-Managing Work Teams: A Typology and Integrative Model, Human Relations, Vol. 48, Nr. 7, S. 750.


Manz, C. &  Sims, H.  (1987): Leading Workers to Lead Themselves: The External Leadership of Self- Managing Work Teams, Administrative Science Quarterly, Vol. 32, No. 1, S. 106-129.


Gloger, B. (2012): Scrum Checklist.

Avatar of Kristina Klessmann
Über Tatsachen reden statt Floskeln zu schwingen ist die Art und Weise, wie Kristina Klessmann an ihre Arbeit herangeht und dabei verlangt sie nicht nur von anderen, sondern vor allem von sich selbst Flexibilität im Denken. Direkte Fragen, die von ehrlichem Interesse getragen und manchmal mit ein wenig Ironie garniert sind, sind für sie der Schlüssel zum Gegenüber. Pragmatismus im Handeln, anpacken und auch den ersten Schritt für andere in die Veränderung zu gehen, ist ihre zweite große Stärke.
  • Hans-Peter Korn

    Gratulation! Das ist eine sehr schöne Illustration dafür, weshalb “Scrum” und “agil” von vielen Leuten mit langjähriger Führungs- / Projekttmanagement- und Entwicklungserfahrung als “allter Wein in neue Schläuche” und bei seiner “evangelisierenden” Verkündung als ziemlich “religiös” (O-Ton eines Feedbacks zu einer kürzlich in Zürich durchgeführten SM-Schulung). Eine klare Bezugnahme auf derartige Wurzeln (inkl. Tom Gilb und Barry Böhm) würden hier “entspannend” wirken….
    Diesen Satz allerdings: ” Es ist eine moderne Art der Führung, ohne disziplinarisch vorgesetzt zu sein.” möchte ich anzweifeln. Das disziplinarische Führung ein Gegensatz zur modernen Art der Führung möchte ich anzweifeln. Für mich ist er eher Ausdruck der aktuell schwindenden Bereitschaft, Führungsverantwortung zu übernehmen bzw. Führung zu akzeptieren.
    Und dass ein Teamleiter mit disziplinarischer Führungsverantwortung die Selbstorganisation des Teams verhindert ist Ausdruck einer spezifischen auf „hire and fire“ und einer von detailliertem „command and control“ geprägten Führungskultur. Sie ist sicher nicht für alle Unternehmen generalisierbar.

    Das Dilemma des ScrumMasters als „dienende“, jedoch nicht disziplinarische, Führungskraft ist gut beschrieben beschrieben im Kapitel 4 von [Gloger, Boris; Häusling, André: Erfolgreich mit Scrum – Einflussfaktor Personalmanagement. München: Carl Hanser, 2011] :
    „Der ScrumMaster muss die Leistung der einzelnen Teammitglieder zwar erkennen und erfassen, er sollte der disziplinarischen Führungskraft aber nicht auf direktem Wege eine Rückmeldung darüber geben, weil er eine neutrale Instanz ist. … Der ScrumMaster [soll] dem Einzelnen kein direktes Leistungsfeedback geben. Der einzig gangbare Weg für den ScrumMaster, auf die Bedürfnisse des Einzelnen im täglichen Arbeitsprozess einzugehen, führt daher über die Teamkultur … Er muss das Team dahin entwickeln (z. B. in den Reviews), dass sich die Mitglieder gegenseitig Anerkennung zollen.“
    Da wäre es ja besser und insbesondere transparenter, wenn es in jedem dieser Teams einen eng mit dem Team zusammenarbeitenden Teamleiter gäbe, der auch die Rolle des ScrumMasters erfüllt!
    Unter „Führungskraft“ verstehe ich hier nicht den die Details der Arbeiten planenden, zuweisenden und kontrollierenden „Hierarchen“, sondern einen den Rahmen der Teamarbeit setzenden und schützenden und die Teammitglieder individuell fördernden „Servant Leader“ [The Robert K. Greenleaf Center, Inc.: What Is Servant Leadership?. Online verfügbar unter: http://www.greenleaf.org/whatissl/ oder „Gastgeber“[Wheatley, Margaret; Frieze, Debbie: Leadership in the Age of Complexity – From Hero to Host. Resurgence Magazine, Winter 2011, online verfügbar unter: http://www.margaretwheatley.com/articles/Leadership-in-Age-of-Complexity.pdf, der seine Verantwortung mit der auf den Unternehmenskontext übertragenen „Soft/Smart Power“ [Nye jr, Joseph S.: Soft Power. Online verfügbar in: http://de.wikipedia.org/wiki/Soft_Power und http://de.wikipedia.org/wiki/Joseph_Nye wahrnimmt.

  • Holger Schauer

    Toller Artikel. Die Frage, inwieweit man als Scrum Master in die Abläufe des selbst-organisierenden Entwicklungsteams eingreift, finde ich vor allem immer wieder an den Rändern des Scrum-Prozesses sehr herausfordernd. Ist es bspw. Aufgabe des Scrum Masters Schwächen und Risiken des Entwicklungsprozesses abzustellen, auch wenn das Team sich gut mit diesen Schwächen eingerichtet / abgefunden hat?

    Mir fehlen da griffige Kriterien, anhand dessen man als Scrum Master gut abwägen kann, wann man Probleme und mögliche Lösungen ansprechen sollte bzw. wann man das Realisieren des Problems und die Erarbeitung der Lösung dem Team überlässt. Der Verweis auf den jeweiligen Kontext und auch auf die erforderliche Erfahrung (z.B. durch Zuzug eines Coaches) ist da im Alltag oft ein schwacher Trost.