„Wer führt eigentlich wen? – Scrum in der Aufbauorganisation“

In der klassischen Welt wird in der Aufbauorganisation gedacht und gelebt. Es gibt eine klare transparente Hierarchie und im Normalfall weiß jeder Mitarbeiter, an wen er berichtet und wo er „hängt“. Es gibt somit eine klare Zuordnung, die dem Mitarbeiter Sicherheit vermittelt und der Führungskraft Macht und Status gibt.

 

Wird Scrum eingeführt, wächst in der agilen Softwareentwicklung die Unklarheit bezüglich der Unternehmensstruktur. Auf der einen Seite gibt es immer noch die klassische Aufbauorganisation und auf der anderen Seite besteht das Scrum-Framework: Product Owner, Scrum Master und das Team.

Somit stellt sich die Frage: Wie stehen diese Rollen zueinander?

Bei unseren Kunden begegnen uns ganz unterschiedliche Modelle, zum Beispiel:

1. Modell: Alles bleibt wie es ist.

In diesem Modell bleibt die Aufbauorganisation im Mittelpunkt. Es gibt einen Abteilungsleiter, einen Teamleiter und zusätzlich einen Scrum Master in den Teams. Die Rolle des Scrum Masters wird dabei meistens von einem bestimmten Entwickler „nebenher“ übernommen oder die Rolle „rolliert“ auch im Team. Darüber hinaus gibt es einen PO, der aus dem Product Management das Backlog füllt und priorisiert.

Die Konsequenzen des Modells in Bezug auf die Führung der Mitarbeiter liegen darin, dass:

  • die Mitarbeiter weiterhin vom Teamleiter geführt werden,
  • die Scrum Master Rolle in dieser Konstellation nicht effizient ausgeführt werden kann, so dass der Grad der Selbstverantwortung und der Selbstorganisation der Teams in der Regel übersichtlich ist.

Bezeichnenderweise fragen sich die Führungskräfte in solchen Unternehmen häufig, warum die Mitarbeiter nicht mehr Verantwortung übernehmen. Die Antwort liegt ganz klar darin begründet, dass die Struktur die Umsetzung des agilen Mindsets behindert.

2. Modell: Die Matrix

Auch in diesem Modell gibt es Teamleiter, allerdings obligt diesen eine andere Verantwortung.

Die Entwicklungsteams sind in der Konstellation meistens auf Produkte ausgerichtet und nicht auf die Hierarchie des Unternehmens. Häufig gibt es sehr lehrbuchnahe Konstellationen: ein Scrum Master, ein PO, ein Team. Zudem sind die Mitarbeiter in „Communities of practice“ organisiert, die ein weiteres Team bilden, worüber die Matrix entsteht.

Die Konsequenz des Modells in Bezug auf die Führung der Mitarbeiter liegt darin, dass immer wieder Unklarheiten darin bestehen, an wen sich die Mitarbeiter bei welchen Fragen wenden sollen bzw. müssen. Die Unterscheidung, welche Verantwortung der Teamleiter und welche der Scrum Master hat, ist hier der Knackpunkt, der häufig zu Irritationen führt.

Hinzu kommt, dass die Teamleiter in kleinen Unternehmen auch noch Teammitglieder in den Entwicklungsteams sind, was eine zusätzliche Herausforderung darstellt.

3. Modell: Ohne Teamleiter

Häufig werden bei der Einführung von Scrum die Teamleiter abgeschafft. Das Ergebnis in einigen Fällen ist, dass für einen Verantwortlichen der Softwareentwicklung Führungsspannen von zum Teil über 30 Mitarbeitern entstehen.

Die Konsequenz des Modells in Bezug auf die Führung der Mitarbeiter liegt darin, dass die große Führungsspanne in der täglichen Führungspraxis mit vielen Herausforderungen einhergeht. Mitarbeiter fühlen sich häufig zu wenig geführt (im individuellen Sinne), zudem kann eine Führungskraft diese Führungsspanne meistens nur mit erheblichen Qualitätseinbussen in der Führungspraxis bewältigen.

Anhand dieser kurzen Ausführungen wird deutlich, dass die unterschiedlichen Konstellationen verschiedene Vor- und Nachteile für die tägliche Führungspraxis mit sich bringen. Wichtig ist, dass die Entscheidung für ein Modell bewusst getroffen wird, Alternativen geprüft und für die Konsequenzen aus der Struktur wirkungsvolle Lösungen für den Führungsalltag gefunden werden.

1 Kommentar

  1. Gute Darstellung – die sehr gut mit meinen Beobachtungen zusammenpasst!

    Ich persönlich habe dabei überwiegend das „3. Modell“ und die dabei entstehende „Führungslücke“ hautnah erlebt.

    Die Lösung aus meiner Sicht:

    Nicht so etwas:
    „Es gibt einen Abteilungsleiter, einen Teamleiter und zusätzlich einen Scrum Master in den Teams. Die Rolle des Scrum Masters wird dabei meistens von einem bestimmten Entwickler “nebenher” übernommen oder die Rolle “rolliert” auch im Team.“
    sondern einen „sachorientiert-kooperativ“ führenden Teamleiter der die Rolle des Scrum Master übernimmt.

    Ich habe den Eindruck, dass die unbewiesene (und nirgends im Scrum Guide zu lesende) Behauptung, dass ein SM keinTeamleiter sein darf darauf beruht, dass nur die heute veralteten „direktiven“ Führungsstile (sie sind – neben den aktuellen – hier genannt: http://de.wikipedia.org/wiki/F%C3%BChrungsstil) gesehen werden.
    Kann es sein, dass hier etwas zu einem Problem hochstilisiert wird, das in der Praxis keines ist?

    Sachorientiert kooperativ zu führen ist heute der allgemeine Trend: Kaum jemand wird noch mit voller Überzeugung einen ausschließlich autoritären Stil vertreten; ein ausschließlich mitarbeiterorientierter Stil hat in der harten Realität des Geschäftslebens keine Chance; und der Laissez-faire-Stil war noch nie ein Vorbild – obwohl er heute häufiger vorkommt, als man denkt.
    Mehr dazu siehe in http://www.vorgesetzter.de/mitarbeiterfuehrung/fuehrungsstil/fuehrungsstile/

Schreibe einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit * markiert.

Formular zurücksetzenBeitragskommentare