Montag, der 31. Oktober 2022

Welche Formen des agilen Arbeitens gibt es?


Sie möchten oder sollen agil arbeiten, haben aber noch ein paar Fragen? Sie sind nicht allein. Ich bin zum Beispiel neulich gefragt worden: Welche Formen des agilen Arbeitens es gibt. So ganz allgemein.


Agilität ist mehr Haltung

als eine bestimmte Form des Arbeitens. Diese Tagsache ist wichtig und möglichst laut und bestimmt anzumerken.

Denn die bekannten und weitverbreiteten agilen Arbeitsrahmen wie z.B. Scrum oder Kanban und vor allem die skalierenden Frameworks LESS und SAFe haben sehr viel Mechanisches und Prozesshaftes an sich.



Das ist wahrscheinlich ein Vorteil. Aber es führt auch dazu, dass Menschen im ersten Moment oft übersehen, dass agile Arbeitsrahmen eben genau das sind: konkrete Rahmen, die es mit dem EIGENEN Leben zu füllen gilt. Scrum und Kanban sind eben (wie die anderen agilen Frameworks auch) KEINE konkrete Anleitung zur Selbstorganisation.

All jenen Menschen aber, die damit beginnen wollen, agil zu arbeiten, im Sinne also von selbstorganisiert, geben sie konkrete Hilfestellungen. 

Alle agilen Arbeitsrahmen fokussieren sich deshalb 

inhaltlich auf etwas anderes als auf rigide Arbeitsanweisungen, die bei feststehenden Produktionslinien durchaus ihren Sinn ergeben.

Heute aber arbeiten wir immer seltener unter solchen Umständen. Heute brauchen wir deshalb oft mehr organisatorischen Freiraum.

Zum Beispiel beim Neudesign und bei der Markteinführung von Produkten, beim Arbeiten in und an Projekten, beim reibungslosen Implementieren von neuen Features oder beim Organisieren und Abarbeiten von gleichbleibenden und auch gleichförmigeren Service-Aufgaben.

Hier brauchen wir einen Freiraum, der NICHT auf generelle organisatorische Absprachen und Verantwortungsbereiche verzichtet. (Die Absprachen, die wir beim agilen Arbeiten treffen, sind sogar teilweise noch rigider als in hierarchischen Organisationskonstrukten.)


Scrum hat die weiteste Verbreitung

Und das aus gutem Grund. Kanban ist ein weiteres, sehr oft eingesetztes Framework. Darüber hinaus werden DevOps und DesignThinking oft verwendet. 
 
Alle diese Arbeitsrahmen teilen dieselbe, oben angerissene agile Philosophie. Diese wird oft mit dem so genannten Deming-Kreis beschrieben: Planning – Doing – Checking – Adjusting. Bei ganzheitlicher Betrachtung der gesamten Wertschöpfung und deren Entstehung. Und bei maximalem Kunden- bzw. Marktfokus.

Außerdem geht es jedem Arbeitsrahmen

zunächst um die Arbeit von EINZELNEN Teams. Um zu verstehen, wie Agilität innerhalb eines Teams grundsätzlich vorgeht, ist es also sinnvoll, sich mit den Details von einem dieser Arbeitsrahmen zu beschäftigen.

Alle, die sich fragen, mit welchem Arbeitsrahmen am besten zu beginnen ist, starte (mit dem kostenlos verfügbaren) Scrum-Framework. Da kann man nichts falsch machen!


All jenen, jedoch, die darüber hinaus interessiert,

wie größere Projekte oder Unternehmungen agil zu organisieren sind, könnte das vielleicht nicht reichen. Natürlich sollten Sie zunächst verstehen, wie Agilität grundsätzlich, also im Kleineren funktioniert, bevor Sie sich der Frage zuwenden, wie Agile in größeren Kontexten funktionieren kann.

Jeff Sutherland, einer der Erfinder von Scrum, haut an dieser Stelle gerne den gar nicht so lustigen, sondern sogar begründeten Schenkelklopfer raus: „If you scale shit, you get scaled shit.“ Mit anderen Worten: Wer schlecht verstandenes oder funktionierendes Scrum skaliert, wird skaliertes schlecht verstandenes oder funktionierendes Scrum bekommen.

Dennoch: Für skaliertes Scrum empfehle ich, sich mit „Nexus“ und „Scrum@Scale“ zu beschäftigen. Beide Frameworks für größere Teams bzw. Unternehmen stammen von den Scrum-Erfindern. 


SAFe und LeSS

sind in diesem Zusammenhang auch noch zu erwähnen. Wer sich jedoch mit diesen beiden, naja, teil-agilen Hierarchie- und Prozessmonstern zu beschäftigen beginnt, wird schnell die Agilität vermissen und sich zurecht fragen, was denn nun genau der Unterschied zu den gestaffelten Prozess- und Ablaufstrukturen der Statushierarchien ist, von denen wir uns ja gerade wegbewegen möchten. 
 
Für sachdienliche Hinweise in dieser Frage wäre ich sehr dankbar. Denn ich weiß das auch nicht so genau.


Literatur

  • Anderson, David J.: Die Essenz von Kanban – kompakt.
  • Anderson, David J.; Reinertsen, Donald G: Kanban. Successful Evolutionary Change for Your Technology Business.
  • Nexus-Guide
  • Scrum@Scale Guide
  • Sutherland, Jeff: Scrum. The Art of Doing Twice the Work in Half the Time, New York, 2014. (Deutsch: Die Scrum-Revolution)
  • Schwaber, Ken; Sutherland, Jeff: Scrum Guide