Führungskräfte abschaffen! Selbst führen!
tarent Blog

Führungskräfte abschaffen! Selbst führen!

16.09.2021 Posted 1 Monat ago Adrian Salamon

Eine sehr geschätzte Kollegin von mir ist temporär für ein Projekt in die Rolle des Scrum Masters gewechselt. Sie war zwar noch nie zuvor Scrum Master in einem Team, hatte aber schon lange ein entsprechendes Zertifikat, unglaublich viel Erfahrung im Bereich Moderation und ein Händchen im Umgang mit Menschen. Ich, als praxiserfahrener Vollzeit-Scrum Master, habe mir keine Sorgen gemacht, dass sie bei den neuen Herausforderungen ernsthafte Probleme haben könnte. Wir haben uns anfangs einige Male ausgetauscht und ich habe ihr ein paar Tipps für den Start eines neuen Teams gegeben. Da ging es inhaltlich um Teambuilding, Finden einer Definition of Done, Aufsetzen eines gemeinsamen Scrum Boards und ähnliche Themen.

Nach kurzer Zeit habe ich wieder weniger von ihrem Projekteinsatz und neuen Erlebnissen gehört, weil ich selbst intensiv in einem anderen Kundenprojekt eingebunden war. Nach ca. vier Wochen habe ich mich bei ihr nach ihrem Befinden und dem Projekt erkundigt, aber die Antwort hat mich etwas überrascht:

»Danke, dass du nachfragst! Ich musste beim Lesen ein wenig schmunzeln, du übernimmst gerade den Job, den eigentlich meine Führungskraft erledigen sollte.«

Was mich daran überraschte ist folgendes: Ich bin keine Führungskraft. Und ich hatte auch nicht die Intention, irgendwelche Aufgaben einer solchen (was auch immer das genau sein mag) hier zu übernehmen. Die Kollegin empfand aber anscheinend mein fachlich und kollegial begründetes Interesse als Nachkommen einer Fürsorgepflicht, wie sie üblicherweise disziplinarisch Vorgesetzte tragen. Man kann diesen Aspekt auch als »menschliche Führung« betrachten. Dabei wollte ich nur wissen, ob der frisch gebackene Scrum Master mit passenden Methoden und Prozessen erfolgreich ihre Herausforderungen meistert und letztendlich Teams und Kunden damit glücklich macht. Für mich war in meiner Nachfrage also eher ein fachlicher Schwerpunkt – aber ist das schon »fachliche Führung«?

In diesem Blogbeitrag möchte ich gerne meine persönliche Perspektive auf die verschiedenen Aspekte von Führung in der Agilen Welt und der tarent im speziellen darlegen und diskutieren.

Führungsaspekte in der agilen Softwareentwicklung

In den letzten Jahren und Monaten haben wir uns in der tarent viel mit Führung beschäftigt. Manche mögen sagen, vielleicht zu viel. Als wachsendes Unternehmen bekommen wir immer mehr Kolleg*innen, die irgendwie organisiert werden müssen. Da uns Selbstorganisation auch ein großes Anliegen ist, haben wir verschiedene Aspekte von Führung auf unterschiedliche Rollen und Personenkreise aufgeteilt.

Fachliche und menschliche Führung

Zuerst betrachten wir die fachliche Führung. In unseren Softwareentwicklungsteams übernimmt diese Aufgabe der Product Owner. Er bestimmt in welche Richtung sich das Produkt entwickeln soll, indem er konkrete Wünsche in Form eines priorisierten Product Backlogs an die Entwickler*innen im Team weiter gibt. Auch wenn das Produkt hier im Vordergrund steht, gibt dieses Vorgehen doch Leitplanken und Führung an Menschen im Team. Diese behalten natürlich Freiheiten in der Ausgestaltung, wie sie diese Aufgaben bestmöglich umsetzen.

An der Seite jedes Product Owners steht ein Scrum Master. In den älteren Versionen des Scrum Guides wurde er Servant Leader (dienender Führer) genannt. Der 2020er Scrum Guide nennt ihn sogar True Leader (echte Führungskraft), konkretisiert aber die Art der Führung nicht. Der Scrum Master begleitet Prozesse, misst z.B. die Velocity und Liefertreue des Teams und hilft vor allem dem Team sich weiterzuentwickeln. Auch diese Form von Feedback, Begleitung und Coaching könnte man als fachliche Führung mit Schwerpunkt auf Zusammenarbeit und Methodik interpretieren. Bestimmt gibt es darüber hinaus auch Aspekte von menschlicher Führung, die ein Scrum Master innerhalb seines Teams übernimmt. Für mich ist das ein sich-kümmern, das auch über die Grenzen der für die Teamarbeit relevanten Themen hinausgeht. Als Scrum Master spreche ich mit meinen Kolleg*innen über Konflikte, individuelle Work-Life Balance, berufliche Veränderungen, aber auch die Einbindung der Kolleg*innen in die Gesamtorganisation, über ein gemeinsames Mindset und geteilte Werte.

Disziplinarische Führung

Dahingegen ist disziplinarische Führung etwas, das für mich relativ wenig mit agiler Arbeitsweise zu tun hat, jedoch zum Teil gesetzlich vorgegeben ist. Disziplinarische Führung beinhaltet Dinge wie Gehaltsverhandlungen, aber auch Maßregelungen, Abmahnungen und Kündigungen. Die letzten drei Aufgaben kommen zum Glück in unserem Arbeitsumfeld selten vor, müssen jedoch rechtlich geregelt sein. Begriffe wie »Weisungsbefugnis« lassen mich immer kurz zusammenzucken, weil sie für mich im Gegensatz zur Selbstorganisation stehen. Da disziplinarische Vorgesetzte nur in den allerseltensten Fällen im Team mit ihren Untergebenen arbeiten, fehlt mir oft der regelmäßige Bezug/Kontakt zwischen ihnen und ihren Mitarbeitenden. Ihre Distanz wird also nicht nur über organisatorische Hierarchie, sondern auch durch disjunkte Arbeitsfelder aufgebaut.

Bei tarent hat jede disziplinarische Führungskraft einen eigenen Stil und eine individuelle Herangehensweise, mit der sie ihre Mitarbeitenden dennoch gut betreuen kann. In der Regel liegt ihr Schwerpunkt auch eher bei Aspekten der menschlichen Führung, überschneidend mit den Aufgaben des Scrum Masters im Team. Es wäre ja auch kaum auszuhalten, wenn der eigene Arbeitsalltag maßgeblich geprägt wäre durch die Verteilung von Mahnungen, Maßregelungen und Weisungen…

Urlaubsanträge, Weiterbildungen & Co. sollten in der Verantwortung der Teams liegen

Die Verwaltung von Urlaubsanträgen ist für mich übrigens keine Führungsaufgabe, sondern liegt in der Selbstverwaltung der Teams. Das wird in der tarent auch schon sehr lange so gehandhabt. Etwas diffuser ist es bislang bei Weiterbildung von Mitarbeitenden: Offiziell ist sie noch Teil der disziplinarischen Führung. Wir haben jedoch auch schon seit einigen Jahren eine Arbeitsgruppe (»Service Board«) der Mitarbeiterentwicklung, die sich um unsere Entwicklung mit kümmert. Ich habe hier die Vorstellung, dass man diesen Teil der Führung sogar ebenfalls stärker ins Team geben könnte: Die Peers aus dem direkten Arbeitsumfeld können wertvollen Input geben, wenn es um Weiterbildungen und Entwicklungspfade geht. Man könnte auch aus dem Teamgedanken schauen, welche Skills aufgebaut werden müssen, um die täglichen Teamaufgaben besser bewältigen zu können. Ebenso würde ich stärker auf Peerfeedback setzen, wenn es um Beurteilungen, z.B. als Grundlage für Gehaltsentwicklung, gehen soll. Die Leute, die auf täglicher Basis eng zusammenarbeiten, könnten sich wahrscheinlich am besten gegenseitige Stärken und Schwächen aufzeigen. (Wobei Gehaltsentwicklung und Gehaltsfindung aus vielen Perspektiven schwierig ist. Das würde den Rahmen dieses Beitrages sprengen.)

Und was ist mit technischer Entwicklung?

Mit Blick auf ein Softwareentwicklungsteam könnte man auch über technische Führung nachdenken. Besonders im Konzernumfeld gibt es Softwarearchitekten oder Lead-Developer, die den Ton bei technischen Entscheidungen angeben können. Mit diesem Gedanken konnte ich mich jedoch bislang nicht wirklich anfreunden, weil er im Kontrast zur selbstverwalteten Entscheidungsfindung des Entwicklungsteams steht. Bei technischer Führung kommt es für mich darauf an, ob sie eine Art Guideline zur teamübergreifenden Konsensfindung darstellt oder ein Diktat durch (vermeintliche) Experten und ihre vordefinierte rollenspezifische Hierarchie ist. Hier steckt häufig Konfliktpotential, wenn das Entwicklungsteam zu wenig Mitspracherechte bei technischen Entscheidungen hat und seine Erfahrungen und Meinungen nicht entsprechend respektiert werden. Immerhin sind sie ja selbst Expert*innen auf ihrem Gebiet.

Meine Vision: gegenseitig Führen ohne Hierarchie

Es ist wahrscheinlich schon in den oberen Absätzen durchgeklungen: Ich glaube, in der Zukunft brauchen wir immer noch Führung, aber weniger explizite Führungskräfte. Wir führen uns einfach gegenseitig. Klar brauchen wir dafür konkrete Verantwortungsbereiche und Kompetenzen. Es ist auch gut, eine feste Person als Ansprechpartner*in außerhalb des eigenen Teams zu haben, die mich langfristig begleitet, kennt und mit der ich über schwierige berufliche oder persönliche Situationen sprechen kann. Aber vielleicht kann ich mir diese Vertrauensperson selbst aussuchen? Und warum sollte ich meine fachliche Weiterentwicklung mit meinen Vorgesetzten diskutieren und nicht mit den Expert*innen auf dem Gebiet – meinen Peers? Klar muss jemand Gehaltsentwicklungen fair gestalten, aber ist das genau eine Person? Kann ich Coaching nur von jemandem empfangen, der im Organigramm über mir steht? Ich denke, Scrum und andere agile Formen der Zusammenarbeit haben bewiesen, dass das nicht so sein muss.

Die tarent hat bereits in ihren Statuten definiert:
»Alle Mitarbeitenden können Führungsverantwortung (im Team, in einer übergreifenden Gruppe, für ihre Division, ihrem Bereich etc.) auf unterschiedliche Weise übernehmen.«

Das ist etwas, was wir an unseren Kolleg*innen wertschätzen und auch aktiv fördern wollen. Für mich steckt da drin: Wir wollen uns gegenseitig führen. Statt in Hierarchien organisieren wir uns in Netzen und (beg-)leiten die Kolleg*innen in Aspekten, in denen wir selbst firm sind. Ich glaube, dass diese Selbstorganisation fruchtbar ist – auch wenn Kritiker*innen das als Chaos bezeichnen könnten, weil es immer weniger zentrale Strippenzieher und Machtpositionen gibt. Letztendlich lassen sich die verschiedenen Führungsaspekte nicht rollengenau trennen, da z.B. Scrum Master und disziplinarische Führungskraft beide menschlich führen. Aber genauso können Entwickler*innen oder Product Owner für ihre Kolleg*innen da sein und Aspekte menschlicher Führung übernehmen.

Ob ich will oder nicht – ich führe Menschen

Ursprünglich war mir der Begriff der Führungskraft vorbelastet mit Hierarchien, fehlendem Expertentum und Befehlsketten. Die Arbeit in der tarent zeigt mir aber, dass es gar nicht so sein muss. Auch Führung ist dank des wachsenden agilen Mindsets im Wandel. Man muss Führungskräfte nicht radikal abschaffen, denn eigentlich füllt jede*r von uns im Arbeitsalltag Aspekte von Führung aus. Auch ich, als Scrum Master. Als Servant Leader. Als True Leader. Als Kollege. Immer dann, wenn ich an Regeln und Prozesse appelliere, nach meiner Meinung gefragt werde oder mit offenem Ohr zuhöre.

Zurück zu meiner Kollegin, die als Scrum Master unterwegs war: Mittlerweile ist sie wieder stärker in anderen Rollen und Kontexten unterwegs. Ihr Intermezzo hatte sie aber erfolgreich abgeschlossen. Natürlich sind wir immer noch im lockeren Austausch zu verschiedenen Themen. Als Kollege und Kollegin, die gegenseitig füreinander da sind, wenn unsere Expertise oder unser Einsatz gefragt ist.

Adrian Salamon

Adrian Salamon, Scrum Master und Experte für agile Methoden und Frameworks
a.salamon@tarent.de