Permafrostböden #agil auftauen – ein Open-Space-Thema beim #ScrumDay2018

Dieses Problem kennen alle, die in einer historisch gewachsenen Hierarchie agile Methoden einführen. Das Top-Management weiß, dass man sich zu einem Kunden- und Mitarbeiter-zentrierten Unternehmen mit kurzen Feedback-Schleifen wandeln muss, um heute am Markt zu bestehen. Die Mitarbeiter lernen die Methoden, wenden sie an und fühlen sich meist bald besser, weil sie mehr positives Feedback bekommen und mehr Sinn in ihrer Arbeit sehen. Wenn – Ja wenn ihnen nicht der „Permafrostboden“ in die Quere kommt, die zwei bis viele Schichten des mittleren Managements dazwischen. Was tun?

Das war grob die Fragestellung, die ich im Open Space beim Scrum Day in Filderstadt klären wollte. Daraufhin kamen etwa 40 Kolleginnen und Kollegen aus kleinen bis ganz großen Unternehmen, von denen so einige bekannten, auch Elemente dieses Permafrostbodens zu sein. Allen war aber gemeinsam, dass sie das Thema ernsthaft und ohne Polemik diskutieren wollten, denn es ist zweifellos real.

Wer sind diese Führungskräfte und wie sind sie in ihre Positionen gekommen?

Oft in einer ganz anderen Zeit und mit einer anderen Motivation, als wir heute brauchen würden. Das existierende System hat sie für bestimmtes Verhalten belohnt oder bestraft, in diesem System waren sie erfolgreich. Deshalb kann der Change im Extremfall eine Generation lang dauern, war da zu hören.

Das ist natürlich für viele zu lang. Wo es oft funktioniert, ist wenn eine Firma so wirklich am Abgrund steht, Zehntausend Meter tief, für alle sichtbar, und man dann einen tiefgreifenden Umbau in die richtige Richtung vornimmt. Für die anderen Unternehmen, vor allem die, die richtig lang schon erfolgreich sind, heißt es, die Führungskräfte nach und nach abholen und auf ihre Ängste richtig reagieren.

Welche Ängste haben sie?

Für sich selbst fürchten sie den Verlust von Position und Gehalt, Macht, Status und Anzahl der Mitarbeiter. Sie haben Angst davor, dass Teams zwar Entscheidungen treffen, aber sie weiter dafür verantwortlich gemacht werden. Sie fühlen sich verantwortlich für ihr Mitarbeiter, dass diese den Change schaffen und nicht unter die Räder kommen. – Daher müssen wir diese Führungskräfte überzeugen, dass die Veränderung gut für sie und für die Mitarbeiter ist, und ihnen ermöglichen, sie aktiv mit voran zu treiben.

Was ist der Knackpunkt der Veränderung?

In der neuen Organisation gibt es selbstorganisierte cross-funktionale Teams, die sich miteinander koordinieren über priorisieren Backlogs, Product-Owner-Meetings, Scrum of Scrums und Communities of Practice. Jedenfalls nicht rauf und runter über Hierarchien. Es braucht also weniger Führungskräfte, und alle in neuen Rollen:

  • Peoplemanager kümmern sich als Sparringspartner und Coach um die Weiterentwicklung der Mitarbeiter
  • Wer fachlich firm ist, die Kunden gut versteht und priorisieren kann, wird Product Owner, und
  • Wer gerne den Teams Hindernisse aus dem Weg räumt und Prozesse vereinfacht, wird Scrum Master.

Wie kann man die Führungskräfte beim Change mitnehmen?

Am häufigsten wird genannt, dass man die Führungskräfte aktiv in die Veränderung einbeziehen muss. Zunächst einmal gibt es da zwei Hindernisse: die genannten Ängste, und das nötige Know-How.

Für beiden braucht man Geduld und Offenheit und spezielle Veranstaltungen, bei denen sich die Führungskräfte miteinander die neue Arbeitsweise quasi erarbeiten. Aus verschiedenen Firmen wurde berichtet, dass es Veranstaltungen gab, wo sie lernen, im Team miteinander an Lösungen von Problemen zu arbeiten, ähnlich wie wir das auch in der DATEV gemacht haben. Man erarbeitet mit den Führungskräften, welche der neuen Rollen wofür verantwortlich sein wird. Es wird auch ein auf die FK zugeschnittenes Fortbildungsangebot zusammengestellt.

Sehr gut ist es auch, von anderen in derselben Situation zu lernen: Führungskräfte aus ähnlichen Unternehmen oder anderen Teilorganisationen sprechen über ihre Erfahrungen mit dem Change, und sie nehmen die andren mit z.B. in öffentliche Reviews ihres Produktes, wo die Teams nach jedem Sprint ihre Fortschritte zeigen. Wer die Energie und den positiven Spirit in so einem Review erlebt hat, wird deutlich weniger Angst um seine Mitarbeiter haben.

Das Top-Management verspricht, dass jeder der die Veränderung mitmacht, im neuen Job mit der bisher erreichten Position und dem Gehaltsniveau einsteigen wird. Gleichzeitig verändern sie das System, d.h., wofür man in der neuen Organisation gelobt und befördert wird oder Gehaltserhöhung bekommt, orientiert sich am Bedarf einer agilen Organisation. Ebenso, ob man noch beurteilt wird und wie.

Für jede Teilorganisation, welche Agil wird, erarbeitet ein Agiler Coach mit dem Führungsteam die neue Ablauforganisation. Dabei wächst das Führungsteam mit der Zeit zu einem echten Team zusammen, und durch eigenes Erleben wird ihnen in 1 bis 2 Jahren klar, welche Rollen gebraucht werden, und auch was ihre eigene beste Rolle ist. Mit etwa Glück passt das dann auch schon von der Menge her, andere gehen dann weiter in die nächste Teilorganisation.

Für jedes Produkt in den ersten Monaten der Veränderung braucht man aber auch mindestens eine Führungskraft mit breitem Kreuz und guten Kommunikationsskills, die bei den Managern weiter oben Stakeholder-Management betreibt. Denn es passiert alles Mögliche, vor allem kommt erst mal die bekannte Abwärtsbewegung bevor es aufwärts geht, und das muss man miteinander aushalten, ohne in Panik zu verfallen.

Alle Ebenen von Führungskräften muss man gesondert abholen. Es gibt zwei Maßnahmen, mit der man die Ebenen weiter oben für die Veränderung aktiviert:

  • Statusberichte werden abgeschafft! Das fördert die Teilnahme auch des höheren Management an Reviews. Es ist natürlich manchmal aufgrund der Menge nötig, noch ein übergeordnetes Review auf gröberem Korn zu machen.
  • Impediments, also Hindernisse, die in den Teams nicht gelöst werden können, werden nach oben ans Management eskaliert. Dabei kann man festlegen, wie lange sie maximal in jeder Hierarchie-Ebene zur Lösung brauchen dürfen, bis sie weiter nach oben eskaliert werden.

Es gibt natürlich auch hoffnungslose und sogar toxische Fälle, da waren sich auch alle einig. Wenn bei jemandem Position, Geld und Macht die Hauptmotivation für die Karriere waren und auch Monate der Veränderung keine anderen Motive hervorgelockt haben, und die ganzen Trainings und Workshops umsonst waren, dann muss man halt schauen, ob es noch eine un-agile Ecke im Unternehmen gibt, sonst kann so jemand ganze Teams demotivieren und an der Selbstorganisation hindern.

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