Disziplinarische Führung in Scrum

July 19, 2015 at 9:18 pm 9 comments


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.

Entry filed under: it-agile-blog-planet. Tags: .

Salaries at it-agile Otto InnoDays 2016: Start einer Blogpost-Serie

9 Comments Add your own

  • […] hat sich das Stefan Roock in seinem Artikel über disziplinarische Führung in Scrum auch schon. Er kennt es so, das diese […]

  • 2. Sven Röpstorff  |  July 21, 2015 at 9:45 am

    Stefan, ich bin vollkommen bei dir. In der Praxis stellt sich dann allerdings die Frage, was aus den bisherigen Führungskräften wird. Ich stelle immer wieder fest, dass diese aus Angst um ihren Job *gegen* die aus Unternehmenssicht sinnvolle Transition hin zu selbstverantwortlichen Teams arbeiten. Die neue Rolle als Mentor und Coach ist vielen zu wenig. Das macht den Job des Coaches unnötig schwer. Hast du da Erfahrungen, die du teilen kannst?

  • 3. stefanroock  |  July 21, 2015 at 10:46 am

    Wenn man so einen Wandel angeht, muss man sich darüber im klaren sein, dass es keine Sicherheit für Positionen gibt. Es kann aber Sicherheit für die Jobs geben. Das Unternehmen könnte garantieren, dass niemand entlassen wird auch niemandes Gehalt gekürzt wird. Das lässt die Angst nicht vollkommen verschwinden. Aber sie wird reduzieren.

    Was das jetzt konkret bedeutet hängt natürlich vom gewählten Modell ab. Wenn man stark auf Mentoring setzt, hat man Ende vielleicht dieselbe Menge an Managern wie heute – sie verhalten sich nur anders (man müsste das Organigramm dann auf den Kopf stellen). Dann ist die Job-Angst kein Thema mehr. Die notwendige Verhaltensänderung bei den Managern bleibt aber eine große Herausforderung.

    Eine zweite Variante wäre das Herauslösen von Geschäftsanteilen und diese komplett neu aufzubauen, ohne Legacy. Das wird häufig gemacht, wenn sich das Unternehmen insgesamt in autonome Geschäftseinheiten organisieren will. Das haben die Manager in der Alt-Orga vielleicht immer noch Angst, aber sie können die neu aufgebauten Geschäftsbereiche nicht behindern.

    Und wenn tatsächliche Management-Positionen zur Disposition stehen, sollte man das IMHO sofort radikal transparent machen, das Thema offen diskutieren und nach gemeinsamen Lösungen suchen. Großzügige Abfindungen führen häufig zu Win-Win-Situationen, wenn sich herausstellt, dass das neugestaltete Unternehmen nicht mehr die passende Heimat für einzelne Manager ist.

  • 4. Felix  |  July 21, 2015 at 2:54 pm

    Meine Erfahrung ist die, dass es mitunter schlimmer ist:
    Durch die Übertragung von Aufgaben auf die Teams wird offensichtlich, dass bestimmte Stellen bei realistischer Betrachtung schon lange keine sinnvolle Funktion mehr gehabt haben. Stattdessen wurden dort nur Mails weitergeleitet die man auch direkt an den Empfänger hätte verschicken können, Dokumentationen erstellt die nie gelesen wurden, Genehmigungen erteilt auf die keiner angewiesen war, Personalentwicklungspläne entworfen an die sich niemand gehalten hat, etc., etc., etc.

    Die Umwandlung in eine agile Organisation bedeutete für diese Leute die Gefahr von “Enttarnung” und Gesichtsverlust, was letztendlich als noch schlimmer empfunden wurde als eine mögliche Versetzung. Die Folge war ein erbitterter Widerstand, der die Grenze zur Sabotage mehr als einmal deutlich überschritten hat.

  • 5. stefanroock  |  July 21, 2015 at 3:23 pm

    Das kenne ich auch. Das ist meiner Meinung nach auch der Grund, warum das Thema disziplinarische Führung zu Beginn einer Scrum-Einführung häufig gar nicht thematisiert werden muss. Das hat vorher nicht richtig stattgefunden und wird durch Scrum auch erstmal nicht schlimmer🙂

  • 6. Sven Röpstorff  |  July 23, 2015 at 10:37 am

    Ich habe leider erst einmal erlebt, dass eine Führungskraft den Weg bedingungslos mitgegangen ist. Er hatte 25 Entwickler unter sich und war Hans Dampf in allen Gassen. Er wusste von jedem einzelnen, woran er arbeitet, wann es fertig werden würde und wo die Probleme lagen. Er hat selbst mit angelegt und war Eskalationsstufe für jedes Problem, sei es in Entwicklung oder im Livesystem. Er ist aber völlig abgesoffen. Mit Scrum kam für ihn die Erlösung, er hat seinen Teams vertraut und konnte sich auf Wesentliches konzentrieren. Heute ist er CTO der Firma. Chapeau!

  • 7. schmadl  |  July 28, 2015 at 2:21 pm

    Der oben genannte Weg funktioniert bei Companys wie Spotify oder ähnlich. Firmen die ein Produkt entwickeln. Wie sieht es für Organisationen aus, die Dienstleistungen liefern. Projekte an einem Produkt sind dort Standard. Selten können ganze Teams des Dienstleisters platziert werden. Deshalb zerstückeln sich die Kollegen eines DL-Teams auf unterschiedliche Projekte. Wie sieht es in diesem Kontext mit Führung aus bzw. mit Firmenorganisation? Ich selbst bin Teamleiter eines solchen Dienstleisters und Scrum Coach für Projektteams. Ich wäre dankbar für einen Vorschlag.

  • 8. stefanroock  |  August 17, 2015 at 12:50 pm

    @Sven: Immerhin. Meiner Wahrnehmung nach stehen wir bzgl. neuer Ansätze zur disziplinarischen Führung noch sehr am Anfang. Da ist jeder einzelne Fall schon ein guter Fortschritt.

  • 9. stefanroock  |  August 17, 2015 at 12:59 pm

    Bei it-agile machen wir das und wir sind ein Dienstleister, bei dem die meisten Kollegen alleine bei Kunden arbeiten. Konkret machen wir es so:
    1. Persönliche Weiterentwicklung erfolgt mit Hilfe von Peergroups, die die Kollegen sich selbst zusammenstellen aus mind. 3 anderen Kollegen. Die Treffen sich 1-4 mal pro Jahr. In letzter Zeit verbreiten sich Rudel-Peergroups stärker: 4-5 Kollegen finden sich zusammen und “be-peeren” sich gegenseitig. Dadurch sinken die Transaktionskosten zur Terminkoordination, weil dann alle Kollegen der Rudel-Peergroup am selben Termin “bearbeitet” werden.
    2. Die Gehaltsfestlegung erfolgt durch die Gehalts-Checkee – ein Gremium aus 4 Kollegen, dass jährlich durch die Mitarbeiter neu gewählt wird. (Notwendige Voraussatzung dafür: Gehalts-Transparenz). Konkret setzen die Gehalts-Checket auf Konsultation – wer mehr Geld haben möchte, spricht mit Kollegen, um deren Perspektive auf diesen Wunsch zu erfahren.
    3. Der Rest liegt bei Business-Teams, die sich regelmäßig treffen und auch Online-Hilfsmittel (z.B. Yammer, Google-Hangout-Chat etc.) verwenden.
    4. Die Geschäftsführer dienen als Eskalationsinstanz, wenn sich etwas partout nicht durch die genannten Mechanismen klären lässt. Davon wird sehr selten Gebrauch gemacht.
    5. Es gibt darüber hinaus keine speziellen Führungskräfte (Manager, Team-Leads etc.).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: