Disziplinarische Führung in Scrum

Immer mehr Unternehmen entscheiden sich dafür, Scrum oder andere agile Verfahren nicht nur für einzelne Projekte einzusetzen, sondern als Standard-Ansatz für die Entwicklung. Damit wird die Frage nach der Mitarbeiter-Führung in solchen Umgebungen immer drängender. Bisher ist dazu die eine heilsbringende Lösung (Silver Bullet) nicht gefunden worden. Tut mir leid. Aber es gibt auch eine gute Nachricht: Wir sind auch nicht vollkommen ahnungslos.

Führung muss sich der Arbeitsorganisation unterordnen

Werfen wir zunächst einen Blick auf das klassische Modell von Führung: Das Unternehmen ist in funktionsorientierte Abteilungen (z.B. Marketing, Vertrieb, Entwicklung, Qualitätssicherung) zergliedert. Wenn die Abteilungen ausreichend groß sind, sind sie nochmal in Gruppen oder „Teams“ organisiert. Entlang dieser Zergliederung findet die disziplinarische und  fachliche Führung statt. Die Abteilungsleiter führen die Gruppenleiter, die Gruppenleiter führen ihre Mitarbeiter. Diese Form der disziplinarischen Führung passt zu dem klassischen Paradigma, Arbeit zu organisieren (Teile und Herrsche kombiniert mit funktionaler Zergliederung).

Die agile Welt folgt einem anderen Paradigma, Arbeit zu organisieren: Interdisziplinäre Teams vereinigen die Skills, die notwendig sind, um Wert aus Kundensicht zu schaffen. Es ist kaum zu erwarten, dass für diese andere Art der Arbeitsorganisation der klassische Ansatz disziplinarischer Führung funktionieren kann. Die Organisation disziplinarischer Führung muss sich der Arbeitsorganisation unterordnen. Dauerhaft kommt man bei flächendeckender agiler Entwicklung nicht um eine Reorganisation der disziplinarischen Führung herum kommen.

Funktionen von Führung können verteilt werden

Für eine Reorganisation disziplinarischer Führung müssen wir uns gedanklich von einem weiteren klassischen Dogma lösen, nämlich dass alle Funktionen disziplinarischer Führung bei einer Person liegen müssen. Dazu lohnt es sich, eine Liste mit den Funktionen zu machen, die heute im Unternehmen unter Führung verstanden werden. Dabei kommen typischerweise Dinge wie die folgenden heraus:

• Sicherstellen, dass die Mitarbeiter das Richtige tun.
• Sicherstellen, dass die Mitarbeiter effizient arbeiten.
• Arbeitsmittel bereitstellen.
• Für die Weiterentwicklung der Mitarbeiter sorgen.
• Urlaubsanträge unterzeichnen.
• Mitarbeiter einstellen.
• Mitarbeiter entlassen.
• Leistung von Mitarbeitern beurteilen.
• Gehälter festlegen.
• Für Mitarbeiterzufriedenheit sorgen.
• Unter- und Überlastung von Mitarbeitern verhindern.
• Fürsorge (z.B. Burnouts verhindern)
• Eskalationsinstanz
• etc.

Warum sollte so eine lange Liste von Funktionen unbedingt in einer Person gebündelt werden? Mitunter wird eingeworfen, dass es „so schön einfach“ wäre. Das ist definitiv der Fall, aber es ist das falsche Kriterium. Es geht nicht darum, ob etwas einfach im Organigramm aussieht, sondern darum, ob es wirksam ist. In einer agilen Welt ist die Bündelung der o.g. Funktionen in einer Vorgesetzten-Position nicht besonders wirksam.

Führungsfunktionen in Scrum

Mit dieser Idee der Funktionsverteilung kann man jetzt flexibel entscheiden, wo welche Funktionen von Führung liegen. Ein paar Dinge klärt Scrum bereits:

• Der Product Owner sorgt dafür, dass die Entwickler das Richtige tun (durch Priorisierung des Product Backlogs).
• Das Entwicklungsteam entscheidet darüber, wie die Arbeit konkret organisiert wird.
• Der Scrum Master sorgt dafür, dass das Team effizient arbeiten kann (z.B. durch Hindernisbeseitigung).
• Das Entwicklungsteam sorgt zusammen mit dem Scrum Master dafür, dass bei der Arbeit weder Unter- noch Überlast entstehen.

Und der Rest?

Damit bleiben eine Reihe von Führungsfunktionen zunächst ungeklärt, z.B. die langfristige Weiterentwicklung von Mitarbeitern, Einstellungen, Entlassungen und Gehaltsfestlegungen. Hier findet sich häufig die Auffassung, dass die Weiterentwicklung von Mitarbeitern und die Gehaltsfestlegung an derselben Stelle liegen sollte. Das ist aber gar nicht notwendig und häufig sogar problematisch. Es ist problematisch, weil für die persönliche Weiterentwicklung des Mitarbeiters offen über seine Schwächen und Fehler gesprochen werden muss. Wenn gleichzeitig über eine Gehaltserhöhung entschieden wird, wird der Mitarbeiter nicht besonders offen bzgl. vermeintlicher Schwächen sein. Und es ist nicht notwendig, weil eine erfolgreiche Weiterentwicklung Auswirkungen auf die Wirksamkeit des Mitarbeiters haben sollte und die Wirksamkeit sollte schließlich entscheidend sein, wenn es um Gehaltserhöhungen geht.

Dinge, die ich in der Praxis gesehen habe für die Führungsfunktionen, die per Scrum nicht fest verortet sind:

• Über den Urlaub entscheidet das Team selbst. (Und achtet dabei darauf, bestimmte Constraints einzuhalten, z.B. Verfügbarkeit von Support für die produktive Software).
• Über Einstellungen entscheidet das Team.
• Bei Einstellungen redet das Team auf Augenhöhe mit.
• Teams entscheiden darüber, ob Teammitglieder das Team verlassen müssen. Diese setzen sich dann auf die Ersatzbank und sind für andere Teams verfügbar.
• Die langfristige Weiterentwicklung der Teammitglieder liegt beim Scrum Master.
• Die langfristige Weiterentwicklung der Teammitglieder liegt im Team.
• Die langfristige Weiterentwicklung der Teammitglieder liegt in selbstselektierten Peer-Groups.
• Der Scrum Master verantwortet die Mitarbeiterzufriedenheit.
• Ein Feelgood-Manager verantwortet die Mitarbeiterzufriedenheit.
• Das Team verantwortet die Mitarbeiterzufriedenheit.
• etc.

Es gibt also nicht die eine richtige Art und Weise, Führung zu organisieren. Man wird mit verschiedenen Ansätzen experimentieren müssen, um die Form zu finden, die für das eigene Unternehmen passt. Und man wird sich darauf einstellen müssen, dass auch Mitarbeiterführung einem kontinuierlichen Verbesserungsprozess unterliegt.

Mit diesem Ansatz, Führungsfunktionen zu verteilen, wird übrigens jedes klassische hierarchische Organigramm vollkommen nutzlos.