More with LeSS, Descaling the Organization, Owning Methodologies

Heute hab ich die Links zu den Videorecordings von Craig Larmans Vortrag "More with LeSS: A Decade of Descaling with LeSS" bekommen:

https://www.youtube.com/watch?v=xoho0CbboTU
https://www.youtube.com/watch?v=Rk5qdG_qgNo&t=364s

Der beste und bedeutendste Vortrag, den ich von Craig je gehört habe. Warum? Hier nur einige wenige Punkte:

- LeSS hat nichts mit Scaling von Scrum zu tun, sondern mit Descaling von Organisationen und der Reduktion von Transaktionskosten und Änderungskosten in der Produktentwicklung als Ganzes.

- Skalierung, verteilte und Offshore Entwicklung sind organisatorisch gesehen der größte Kostentreiber - nicht Management Mindset oder Kultur. Und so ist Larman's Empfehlung: Don't, Don't, Don't.

- Das größte Hindernis für die De-Skalierung der Organisation ist laut Larman's Law, dass Menschen in großen, funktional aufgebauten Organisationen implizit (oder auch explizit) dafür belohnt werden, Spezialistentum, Micro-Management und andere Formen der lokalen Optimierung zu betreiben und dafür 'Wiederstand zu leisten' gegen Veränderungen Richtung Deskalierung im größeren Umfang.
http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organ...

- Daher gilt: keine Deskalierung ohne strukturelle Veränderung, "Culture follows structure"

Or, Culture/behavior/mindset follows system & organizational design. i.e., If you want to really change culture, you have to start with changing structure, because culture does not really change otherwise.

- Agilität hat primär mit Agilität zu tun "To turn on a dime, for a dime" wie Craig sagt. mit der Fähigkeit einer Produktentwicklungs-Organisation die Richtung zu ändern, ohne dass dadurch massiv die Entwicklungskosten ansteigen

- Die Fähigkeit zur Agilität zu entwickeln erfordert Lernen und Umlernen, nicht nur für Einzelpersonen, sondern auch für Entwicklungsteam und die Organisation als Ganzes: "Learning Organizations" wie sie u.a. Senge in "The 5th Discipline" beschrieben hat:
https://de.wikipedia.org/wiki/Lernende_Organisation

Neu ist auch die Art in der Craig über LeSS Adoption redet:
- "Job security, but no role security" statt feuert alle Team- und Projektleiter,

- "Start with why" statt seht doch endlich ein wie dysfunktional Eure Arbeitsweise ist und

- "Owning vs. renting" eines Skalierungs-Frameworks statt, LeSS ist das einzige Framework das wirklich funktioniert und alles andere ist "fake Scrum, fake Lean und fake Agile"

- Trotzdem gibt es natürlich in LeSS verbindliche Regeln. Darüber hinaus Prinzipien, Guidelines und Experiment (try ..., avoid ...), wodurch einem bei der LeSS Einführung mehr Spielraum zugebilligt wird. Eben dieser minimale Satz an Regeln und die Freiheitgrade bei Richtlinien und Experimenten im Rahmen der Prinzipien soll zu mehr Ownership führen!

Das alles sind für mich tolle Neuigkeiten und ein Grund mehr mich für LeSS zu begeistern und SAFe 4 und Essential SAFe kritischer zu sehen - auch wenn ich da eine Annäherung über die Zeit feststellen kann:
Das neue Value Stream Level entspricht LeSS Huge, aber wie üblich mit mehr Rollen und neuen Artefakten;
Essential SAFe reduziert wiederum die Levels, Rollen, Artefakte und Meetings auf das in SAFe Notwendige, dem, was in LeSS den Rules und Principles entspricht (ohne Guidelines und Experimete)

Meines Erachtens könnte man aber auch noch weiter gehen bei LeSS, Richtung der Crystal Familien von Agilen Methoden, Richtung "barely sufficient methodology" um Ownership der Methode weiter zu erhöhen, speziell da, wo die Organisation das Shu Level des Lernens verlassen hat und sich Richtung Ri Level bewegt.

Auch gibt es andere Gründe für Agilität als Agilität, Flexibiltät, Adaptivität oder Geringe Änderungskosten, z.B. Verbesserung von Mitarbeiterzufriedenheit, technischer Exzellenz, Code Qualität, Time to Market, Kundenzufriedenheit, etc. Der Mehrwert der Agilität liegt für mich eigentlich in dem Zusammenspiel dieser Faktoren:
Wie wir wissen sind Kunden unzufrieden, wenn sie lange warten müssen oder die Qualität nicht stimmt,
und das motivierte und fähige Mitarbeiter der Nährboden ist, auf dem all dieses wachsen kann.
Das wichtigste dabei ist, das Wachstum und Lernen von Mitarbeitern und Teams nicht zu begrenzen, z.B. durch vage, z.T. konkurrierende Ziele oder unnütze Regeln und Beschränkungen - womit wir wieder bei der Lernenden Organisation wären.

Es ist diese einmalige Kombination von Lernender Organisation, Theory Y, Systems Thinking (Teil der LE), Lean Thinking und Scrum, die LeSS für mich so attraktiv macht. Das gleich gilt für SAFe, dass viele dieser Dinge in ihre Werte und Prinzipien übernommen hat, oberflächlich betrachtet aber dem Thema Leadership eine größere Bedeutung beimisst. Das macht marketingtechnisch Sinn, denn das Top Management fühlt sich dadurch eher angesprochen und ist daher auch eher bereit Geld dafür in die Hand zu nehmen - übersieht dabei aber oft die Bedeutung von Einfach und Ownership, worin wiederum LeSS eine neue Stärke entwickelt hat, die es aber noch nicht richtig ausspielen konnte. Essential SAFe ist die Antwort auf diesen Trend, und man kann gespannt sein, wie diese beiden bedeutenden agilen Skalierungsansätze sich gegenseitig befruchten - und hoffentlich nicht bekämpfen - werden. Einfachheit von Regeln und Prinzipien ist wichtig in einem komplexen Umfeld, Diversität aber auch - keine Varianten keine Evolution!

Zugleich ist das Thema Leadership ja nicht unwichtig in LeSS, aber wie bei der Lernenden Organisation nicht beschränkt auf das Management, sondern verteilt in der Organisation. Community und Netzwerken wird mehr geschätzt als eine heroische, quasi allwissende Führung. Zugleich ist das, was LeSS zum Thema Management zu sagen hat eine Zumutung für viele Führungskräfte: Servant Leadership, Leader als Mentor und Coach seiner Mitarbeiter, was Problemlösen anbetrifft, Gemba walks aka Go See, Selbst-Organisation, Impediment Service, ... das passt alles nicht zum Bild des Managers als Held und Macher, Scientific Management, Management by Objectives und Theory X Mindset. Management 2.0, 3.0 who cares - das ist was für Personalentwickler und Coaches, aber nichts für erfolgreiche Führungskräfte. Wurde irgend jemand schon mal reich damit, Millionär oder gar Milliardär? Wenn dann doch eher durch bahnbrechende Technologien, Produkte und Dienstleistungen, die von einzelnen Genies erdacht wurden - den Gates, Jobs und Zuckerbergs dieser Welt - aber nicht immer ein Vorbild für Führungskräfte (von Jack Welsh garnicht zu reden)

Gut nur, dass die Digitale Revolution im Business eine enge Verbindung mit der Agilität im Valey eingegangen ist - wer weiß, wo das Thema Agilität ohne Lean Startup heute sonst stehen würde?

Ok, was heißt das dann alles für mich als Agile Coach?

Zunächst einmal finde ich es spannend, all diese vielen Ansätze besser kennenzulernen und deren Verständnis zu vertiefen. Das ist alles Pflichtlektüre für einen LeSS Trainer Candidate und das ist gut so! Ob es was hilft Managern die gleiche Pflichtlektüre aufzudrängen, wie Craig das oft tut, wage ich zu bezweifeln (er im übrigen auch :)

Zweitens hilft es mir als Coach die Unterschiede zwischen LeSS, SAFe und z.B. dem Spotify Ansatz besser zu verstehen, offen zu sein, für Variationsmöglichkeiten, die einen besseren Fit zwischen den Zielen der Organisation und den eingesetzten Praktiken und Frameworks erzeugen, aber auch zwischen mir als offenen Coach, der damit einen differentierteren Blick auf die methodische Vielfalt und Entwicklungsmöglichkeiten in der Organisation werfen kann und damit meine Anschlußfähigkeit und Effektivität steigert rsp. Widerstand gegen jedwede vorgefertogte Lösungen in Form von "Frameworks" reduziert.

Die Gefahr bei der Vielfalt ist eine gewisse Beliebigkeit: hilft das wirklich meinem Kunden? Wo will er denn eigentlich hin? Wo sind die größten Hebel für Veränderungen in die gewünschte Richtung?
Diese Fragen sind eigentlich völlig unabhängig von den Frameworks, dennoch ergibt sich da eine graduell bessere oder schlechtere Passform. So weiß ich zwar, dass Release Planungen a la SAFe oft eine zu große, nicht optimale Losgröße haben, aber das ist natürlich immer abhängig von den derzeitigen Transaktionskosten. Feature Teams, Continuous Integration, Delivery und Deployment läßt grüßen - all das kann man oft nicht an einem einzigen Tag oder einem Sprint einführen, obwohl es natürlich nicht unmöglich ist. Selbst wenn dies für ein kleineres Produkt oder Programm in wenigen Tagen möglich ist, bleibt oft immer noch die Wasserfallwelt der restlichen Soft-, Firm- und Hardware Entwicklung drum herum. Wie synchronisiere und integriere ich mich mit diesem Teil der Produktentwicklung? Ist da ein quartalsweiser Zyklus nicht erstmal ein guter, gar nicht so kleiner Schritt in die richtige Richtung? Was wäre der kürzeste Zyklus, zu dem das sinnvoll und möglich ist und wie entwickle ich mich schrittweise dort hin, indem ich auch in der Wasserfall-Entwicklung die Transaktionskosten weiter senke und dadurch häufigere Integration, Test und Lieferung ermögliche?

Man sieht auch hier, dass agile Konzepte wie häufige Integration, Feedback, Lieferung und Senkung der Transaktionskosten eigentlich im Mittelpunkt stehen! Den Zusammenhang von Lean und Agile Konzepten zu verstehen ist demnach eine Schlüssekompetenz für Coaches die - wie ich - Agilität im Großen einführen wollen.

Nochmal interessanter wird es, wenn man die Agilen Frameworks und Lean Thinkung durch die Systems Thinking Brille betrachtet und damit auch die Rolle mentaler Modelle. Ich bin gerade erst am Anfang dieser Reise, deswegen kann ich noch nicht so viel dazu sagen. Das Zusammenspiel der o.g. Faktoren Verbesserung von Mitarbeiterzufriedenheit, technischer Exzellenz, Code Qualität, Time to Market, Kundenzufriedenheit über längere Zeit hinweg rückt damit ins Zentrum der Betrachtung und wie diese Faktoren sich gegenseitig beeinflussen. Die Agilen und Leanen Frameworks der Produktentwicklung sind in diesem Zusammenhang Modelle, mit denen sich bestimmte Vorhersagen treffen lassen, wie diese Faktoren vomeinander abhängen und was die eigentlichen Akteure in Form von Rolleninhabern und die Interaktionen in Meetings sind, welche Veränderungen in Artefakten bewirken, die größtenteils sichbare Informationsspeicher darstellen, wie Backlogs, Code und Software Inkremente. Naja, ich sollte mal einen Kurs in System Dynamics machen oder vielleicht erst mal ein Buch lesen, dass diese Zusammenhänge schon einmal untersucht hat :-) Die LeSS Seite über Systems Thinking ist ein guter Einstieg dazu:
https://less.works/less/principles/systems_thinking.html

OK, damit genug der Reflexion für 2016 und genug der Pläne für 2017. Learning Organizations, System Dynamics, Mentale Modelle und Team Learning werden sicherlich mehr Raum in meinem Denken und Lernen in der Zukunft einnehmen. Shared Visioning ist auch gerade in LeSS ein wichtiges Thema, wenn es um Continuous Improvement towards Perfection und Perfection Vision geht. Auch im Kontext des Spotify Ansatzes finde ich Themen wie Definition of Awesome, Improvement Backlog und das einfache Ampelsystem zur Selbst_Evaluierung von Squads sehr spannend - aber das ist ein anderes Thema, das ich bei der ING DiBa Banking to Go besser kennegelernt habe, den Back to Basics Workshops, die maßgeblich zur Verbesserung von Ownership beim Way of Working (WoW) beigetragen haben.