Selbstführung wird oft als ideologisches Bekenntnis präsentiert: Scrum schätzt Autonomie, deshalb sollten sich Teams selbst führen. Diese Rahmung macht es leicht, das Konzept als nett klingendes Prinzip ohne konkreten Nutzen abzutun. Das eigentliche Argument für Selbstführung ist praktischer und konkreter als eine Werteerklärung.
Das Informationsnähe-Argument
Die Menschen, die die Arbeit leisten, haben Information, die eine Führungskraft, die diese Arbeit zuweist, typischerweise nicht hat: die konkreten technischen Abwägungen eines Ansatzes gegenüber einem anderen, welches Teammitglied aktuell tatsächlich Raum für eine neue Aufgabe hat, welches Arbeitspaket dringlicher ist angesichts von etwas, das gestern gelernt, aber noch nicht nach oben berichtet wurde. Eine Führungskraft, die Zuweisungsentscheidungen von außerhalb dieser Information trifft, muss sie entweder erst einholen (was Verzögerung und Kommunikationsaufwand hinzufügt) oder ohne sie entscheiden (was schlechtere Entscheidungen bedeutet). Selbstführung verlagert die Entscheidung dorthin, wo die Information bereits ist, was schneller und im Durchschnitt besser informiert ist.
Das Geschwindigkeitsargument
Jede über eine Führungskraft zur Genehmigung geleitete Entscheidung fügt Verzögerung hinzu, selbst wenn die Führungskraft am Ende genau das genehmigen würde, was das Team vorgeschlagen hat. Ein Team, das ermächtigt ist, eigene Entscheidungen darüber zu treffen, wie es seine Arbeit organisiert, wartet nicht auf diesen Genehmigungszyklus, was sich über die Dutzenden kleinen organisatorischen Entscheidungen, die ein Team in einem typischen Sprint trifft, bedeutsam summiert.
Das Eigentümerschafts-Argument
Menschen, die selbst wählen, wie sie ein Problem angehen, investieren generell mehr darin, diesen Ansatz zum Erfolg zu führen, als Menschen, denen einfach gesagt wird, wie sie vorgehen sollen. Das ist keine abstrakte Motivationsbehauptung: Es ist ein konkreter, gut dokumentierter Effekt, bei dem wahrgenommene Autonomie darüber, wie Arbeit erledigt wird, das Engagement für das Ergebnis dieser Arbeit erhöht, unabhängig von der tatsächlichen Qualität des gewählten Ansatzes.
Wo Selbstführung echte Grenzen hat
Selbstführung gilt dafür, wie das Team seine Arbeit erledigt (Aufgabenverteilung, technischer Ansatz, interner Prozess), nicht dafür, woran das Team arbeitet, was weiterhin Accountability der Product-Owner-Person bleibt, und nicht für organisatorische Einschränkungen, die das Team nicht kontrolliert, wie Budget oder Personalstärke. Ein Team, das Selbstführung als Freibrief interpretiert, geschäftliche Prioritäten zu ignorieren, hat den Umfang der Autonomie missverstanden, die Scrum tatsächlich gewährt. Die Autonomie ist real, aber begrenzt, und "Selbstführung beim Wie" mit "Selbstbestimmung beim Was" zu verwechseln, ist ein häufiges und folgenreiches Missverständnis.
Was das für den Aufbau von Selbstführungsfähigkeit bedeutet
Selbstführung ist kein Schalter, den ein Team per Erklärung umlegt. Es braucht eine Erfolgsbilanz, die das Vertrauen rechtfertigt (ein Team, das bei kleineren Entscheidungen gutes Urteilsvermögen zeigt, bevor ihm Spielraum bei größeren gegeben wird), und es braucht Management, das genuin bereit ist, Team-Entscheidungen zu akzeptieren, die es selbst vielleicht nicht getroffen hätte, sofern sie vernünftig sind, statt Selbstführung nur zu tolerieren, wenn sie das Ergebnis liefert, das eine Führungskraft ohnehin gewählt hätte. Beide Bedingungen brauchen Zeit zum Aufbau, weshalb sich Selbstführung in einem neu gebildeten Team tendenziell allmählich entwickelt statt von Tag eins an vollständig zu bestehen.