Wie werden unsere Führungskräfte agil? – #AgileHRConference 2015

Diesen Blogpost schreibe ich inspiriert durch die Vorträge bei der 4. Agilen HR-Konferenz in Köln, und einen Open Space zum Thema „Training für agile Führungskräfte“, den ich dort moderiert habe.

Open Spaces bei der #agilehrconference

Während viele der anwesenden HR-Expertinnen die Meinung vertraten, dass sich die Anforderungen an die Führungskräfte agiler Teams gar nicht sehr von denen unterscheiden, die heute allgemein an solche Personen gestellt werden, waren wir uns alle einig, dass diese Trainings in der Praxis sehr nötig sind. Das gilt vor allem in IT- oder R&D – Organisationen, wo sich Führungskräfte häufig aus den Fachexperten rekrutieren, die nun mal wenig Hintergrund in Führung haben.

Inhalte solcher FührungskräfteTrainings können sein:

  •  mich führen, Mitarbeiter führen, das Unternehmen führen
  • Aufgaben und Verantwortung delegieren
  • Entscheidungsbefugnis geben (Delegation Board aus Management 3.0)
  • Mikromanagement abgewöhnen und durch Vertrauen ersetzen
  • Vertrauen als Mechanismus zur Reduktion der Komplexität (Luhmann. ..)
  • X-Modell versus Y-Modell vom Mitarbeiter
  • Die Stärken der Mitarbeiter stärken, nicht so sehr an Schwächen herumdoktern
  • Fehlerkultur trainieren. Fehler machen dürfen und daraus lernen
  • Feedback geben und annehmen
  • kollegiale Fallberatung – nicht Einzelkämpfer sein als Führungskraft
  • Wahrnehmung
  • Gewaltfreie Kommunikation
  • Agile Werte und Prinzipien
  • Lean – Themen wie Respekt vor Menschen, kontinuierliche Verbesserung, one piece Flow

 

Als Strategie zur Implementierung versorgen wir zuerst die Führungskräfte mit Trainings die das wollen, um gute Erfahrungen zu sammeln und einen Sog in die Richtung agiler Führung zu erzeugen. Ihnen richten wir Communities ein, in deinen sie sich im geschützten Raum face-to-face über Fallbeispiele austauschen können. Es macht auch Sinn eine komplette Einheit zu trainieren, wenn darüber ein Grundkonsens da ist, so dass sich alle gegenseitig helfen können.

Als nächstes ist wichtig, dass gute Beispiele agiler Führung im gesamten Unternehmen wie Leuchttürme wirken. Wenn der Präsident oder CEO durch Storytelling Agiles Führungsverständnis positiv heraushebt und nicht so agiles Verhalten als nicht nachahmenswert darstellt, kann sich insgesamt etwas bewegen, da man so auch die späte Mehrheit erreicht.

Es gab noch eine längere Diskussion über 360-Grad-Feedback. Dies ist auch ein bewährtes Instrument zur Entwicklung der Führungskräfte, nicht speziell agil. Ein gutes 360-Grad-Feedback besteht nicht nur aus einer Online-Beurteilung durch Führungskraft und Team, sondern auch aus einem face-to-face Workshop. Dieser wird durch HR oder extern moderiert und gibt den Mitarbeitern Gelegenheit, nach Vergleich der Ergebnisse zu verschiedenen Themen Beispiele zu erzählen und Maßnahmen zu formulieren. Die Ergebnisse werden auch mit dem Vorgesetzten darüber geteilt, der auch eine eigene Einschätzung abgibt.

Unterschiedliche Meinungen gibt es zum Thema der Freiwilligkeit – einige Firmen fordern ein 360-Grad-Feedback alle zwei Jahre und HR überprüft das auch. Andere setzen auf die freiwillige Anmeldung – altmodische Comand&Control-Führungskräfte können so allerdings, bei freiwilligen Trainings UND freiwilliger Diagnose, ihren ungeeigneten Führungsstil beibehalten. Bei Führungskräften höherer Stufen ist auch immens wichtig, alle Mitarbeiter zu fragen, nicht nur die direkt darunter.

Insgesamt gab es bei der Konferenz eine gute Mischung aus Führungskräften, HR-Professionals und agilen Praktikern. Dadurch waren gerade die Open Spaces sehr inspirierend, und auch die Diskussion nach dem Film „Augenhöhe“, den ich schon in meinem vorherigen Blogpost erwähnt hatte, und der auch dort gezeigt wurde.

Begeistert haben mich auch eine ganze Reihe Vorträge, z.B. der Vortrag von Seibertmedia über extreme agile Leadership.

Wozu brauchen wir Frameworks für Scrum im Großen wie #LeSS und #SAFe ?

Es gibt mittlerweile zwei Frameworks für Scrum im Großen:

Dean Leffingwell und seine Firma haben 2011 das recht ausführliche SAFe oder Scaled Agile Framework online gestellt und schieben nummerierte Updates nach. Es illustriert eine sehr elaborierte große agile Organisation.

Bas Vodde und Craig Larmann folgten 2014 mit LeSS oder Large Scale Scrum, welches auf ihren sehr hilfreichen Büchern von 2009 „ Scaling Lean und Agile Developement: Thinking and Organizational Tools for Large-Scale Scrum“ und 2010 „Practices for Scaling…“ basiert. Das ist ein sehr schlankes Framework, das die Bücher nicht ersetzt, sondern eher einen guten Einstieg in alle Themen bietet.

In den letzten Monaten werde ich immer häufiger gefragt, ob man ein solches Framework bei der Einführung von Scrum in großen Organisationen verwenden soll. Dahinter stehen Fragen wie ob es einfacher wird, kostengünstiger, man weniger lesen muss, oder gar ob man es fertig kaufen kann und nur noch ausrollen lassen muss.

Gerade der Ansatz von SAFe suggeriert dies: es ist bewährt, oft erfolgreich angewendet worden. Und das Ausrollen in einer beliebig großen oder komplexen Organisation erfolgt durch eine Serie von zertifizierten Trainings durch zertifizierte Trainer, die es praktischerweise in vielen Ländern gibt.
Drei Schritte: Training für die internen Coaches, Training für das Management, dann für die Teams – als komplette Release-Trains innerhalb von 5 Tagen. Und fertig? – Na ja, da braucht man für viele Situationen dann doch noch erfahrene externe Coaches, denn gelernt ist ja nicht wirklich gekonnt, und was man noch nicht selbst angewendet hat, kann man auch schlecht coachen.

Ich weiß noch, wie viel und wie lange wir diskutiert haben bei der Einführung von Scrum in unserer großen und verteilten Organisation. Dabei hatten wir viele Voraussetzungen schon im Laufe der Vorbereitungen geschaffen, z.B. Testautomatisierung für den bestehenden Code erhöht, häufigere Builds, und Informationen über vorhandene technische Schulden gesammelt und ins Backlog integriert. Aber schon allein die Tatsache, dass die Verteilung der Organisation über die verschiedenen Standorte ganz anderen Kriterien folgen musste als vorher, da wir ja gemischte Teams wollten, die ganze Features entwickeln und testen können, hat schon viel Kopfzerbrechen verursacht. Es sollten viele Leute in anderen Rollen arbeiten als zuvor. Einige Rollen hatten wir an bestimmten Orten zum ersten Mal. Wie viele Feature Areas sollten wir bilden, und wer war für welche Feature Area als Area Product Owner geeignet? Alle diese Dinge kann man entscheiden, wenn man sich schon eine Weile damit auseinander gesetzt hat und erfahrene Sparringspartner hat.

So ein Framework kann einem dabei helfen, alle Gebiete zu finden, über die man nachdenken muss. Es kann einem ein paar Lösungen zeigen, die sich schon bewährt haben – was natürlich wieder in bestimmten Organisationen mit bestimmten Kontexten und Randbedingungen war. Die Bücher von Vodde und Larman haben uns damals sehr geholfen, weil sie nicht als Bibel daher kamen, sondern mit Mustern, die man unter bestimmten Umständen sinnvoll anwenden kann, die aber unter anderen Umständen heftig scheitern können. Manchmal haben sie sogar empfohlen, Muster die sie zuvor als falsch und un-agil dargestellt hatten, in bestimmten vertrackten Situationen dennoch als Workaround einzusetzen.

Auch im Scaled Agile Framework haben wir einige interessante Lösungen gefunden, z.B. das Verhältnis zwischen Kundenfeatures und technischen Features und wer dafür sorgt, dass beide hoch genug priorisiert werden – siehe Program Backlog. Man muss eben nur auch hier alles als Anregung sehen, was in bestimmtne Kontexten funktionieren kann.

Meinen Erfahrungen entspricht, was im LeSS Framework zum Ausrollen gesagt wird: Eine agile Transition funktioniert weder nur top-down noch nur bottom-up, sondern es muss immer in beide Richtungen gehen. Lieber anfangs eine kleine Abteilung oder ein kleines Produktteam umstellen, und das richtig tief, dabei wirklich gut experimentieren und lernen – und dann in der größeren Organisation ausbreiten und mehr lernen. Viel mit Freiwilligen machen, so dass Selbstorganisation auch zum Ausrollen der Selbstorganisation verwendet wird!

Mit einem solchen Ansatz ist die Verwendung eines Frameworks für Scrum im Großen sinnvoll. Die eigentliche agile Transition bleibt dabei immer in den Händen der Organisation, die sie tun will, und die ja auch die Verantwortung für ihre wirtschaftlichen Ergebnisse, ihre Experimente und ihr Lernen hat. Die externen Coaches können nur unterstützen.

LeSS works

– Vor einigen Tagen haben sich übrigens ein paar Freiwillige aus verschiedenen Firmen zusammen gefunden, um das Large Scale Scrum Framework ins Deutsche zu übersetzen. Wer Interesse hat, dabei mit zu machen, kann gerne der Xing-Gruppe beitreten und mich kontaktieren! https://www.xing.com/communities/groups/large-scale-scrum-8e98-1052168

%d Bloggern gefällt das: