Melting-Pot – Agile Defekte thumbnail 1

Scrum ist ein Problem, nicht DIE Lösung

denn Agile braucht keine Prozesse

Jetzt werden (seit einiger Zeit), als ’neue‘ Idee, Agilität und Prozessmanagement in einem Atemzug genannt. Oder: auch gerne postuliert: Agilität ist ein Prozess. Alles nur ein Hype oder ist etwas dran am agilen Prozessmanagement? Agilität und Prozesse scheinen nicht nur unterschiedlich, sondern gegensätzlich zu sein. Die Prozessorientierung (das klassisches Prozessmanagement) soll Geschäftsabläufe so weit es geht, durchplanen, strukturieren und standardisieren. Fehler, Hindernisse und Probleme werden erkannt, benannt und beseitigt, damit das Unternehmen, was ja auch nichts anderes ist als ein Mega-Gesamtprozess, möglichst reibungslos abläuft. Das ist die Arbeit ‚IM System‘.

Das hat Ähnlichkeit mit Kunstharz, eher Beton, der nach dem Giessen aushärtet. Bei ersterem, wenn es Klarsichtharz ist, können Sie noch etwa durch-„blicken“, bei zweiterem nicht. Agilität hingegen ist vergleichbar mit Knete. Sie ist offen, leicht formbar und anpassungsfähig. Sie möchte sich Starrheit und Kontrolle widersetzen. Drücken Sie links in die Knete, kann sich rechts eine Ausbuchtung zeigen. Somit sind wir von einem gemeinsamen Nenner etwas entfernt? Oder nicht? Wo liegt das Problem? Das Drücken in die Knete ist ‚Arbeit AM System‘ – Knete.

In einer Fehlinterpretation! Methoden sind weder gut noch böse – sie passen zum Problem oder nicht – auch nicht in etwa! Dieses „in etwa“ ist eine undefinierte Teilmenge und genau die andere Menge ist das Dynamit … Ein Problem ist nicht der Mensch, sondern Menschen machen Probleme, indem Sie Problem als Etikett drankleben. Nicht die Waffe tötet, sondern dieser Mensch (also das, was er denkt oder wovon er überzeugt ist) MIT der Waffe. Nicht die Luft braucht den Menschen, sondern der Mensch die Luft – zum atmen. Und ebenso verhält es sich mit ITIL, SCRUM, KANBAN, blabla … und was auch immer für einer Methode. Und, hier eine erste Klarstellung: Eine Methode ist nur eine Abfolge von mind. 2 einzelnen Techniken. Zu Techniken komme ich gleich noch. Werden die schon nicht beherrscht, wird das auch nichts mit Scrum. An anderer Stelle bezog ich mich auf Shu-Ha Ri. Ein Shu enthält KATA.

Alles nur übergeholfen, so meine Wahrnehmung. Entweder passt die Methode zum vorgefundenen Problem und wird entsprechend angewendet oder sie passt nicht – dient aber bis zum Erkennen dessen erst als schickes Feigenblatt (zum Verstecken) und dann bei nächstmöglicher Gelegenheit als Sündenbock. Ist die Gelegenheit gleichwohl günstig (für das Refreshment von Ressourcen), werden à-la-longue betroffene Menschen gönnerhaft dem freien Arbeitsmarkt wieder zur Verfügung gestellt (Abscheuliche Formulierung). Die haben es ja verbockt, oder? So, genug geätzt … über die Defekte in der fragilen Agilität.

Was ist es dann?

exemplarisch: Falsche Beweggründe (eine #Auswahl)

# 1: Scrum „von oben“ – Wir bringen da mal frischen Wind rein … sagte die neue Führung / Abt. Leiter etc. – unwissend, dass Scrum echt „Dreck“ aufwirbeln kann – den genau dieses Management gar nicht sehen will. Warum? Es greift eine Wahrnehmungsverzerrung, zu denen ich schon geschrieben habe.

# 2: Scrum „von unten“ – „Die (da oben) verstehen uns sowieso nicht … Wir machen einfach“. In der Entwicklung wird „unter dem Teppich der offiziellen Akzeptanz“ begonnen, agil zu agieren und gehofft, dass andere Bereiche dann mitziehen. Also eine positive Infiltration. Der Ansatz ist löblich und zum Scheitern ausgerufen (muss aber nicht …). Wird der Support vom Management verwehrt (‚Ober sticht Unter‘ funktioniert da sehr präziese), na, Sie wissen schon. Und dazu gibt es auch wissenschaftliche Belege. Sofern Sie nicht eine kritische Masse (ähnlich wie in der Biologie) erreichen, erstickt dieser Ansatz mit guter Motivation im Keim – dazu schreibe ich später mehr.

# 3: Scrum wegen übertriebener Agilität des Managements – „Mir ist gestern Abend mal eine Idee gekommen…“ – Das kann gefährlich werden, wenn diese Idee globalgalaktisch direktiv, ohne die Antwort auf die Frage nach dem Warum und der Übereinkunft, wer wie womit „diese Idee“ trägt, eingekippt wird. Das hat Folgen. „Agilität“ im Management wird dazu genutzt, täglich Anforderungen zu ändern, hinzuzufügen, zu löschen oder in ihrer Priorität zu ändern, Denn es gibt immer wieder Versuche des Managements, sogar in laufende Sprints einzugreifen. (‚Ober sticht Unter‘ …) – womit dann Methoden wie Scrum „elegant, aber agil“ vor die Wand (letztendlich: „nur steril“) fahren. Scrum und andere Tools greifen nicht, wenn die Kultur da drunter sich nicht (ver-) ändert.

# 4: Scrum wegen fehlender Vision – „Wir haben keine Vision, aber wir fangen mal an …“ #4 ist #3 nicht unähnlich, nur vermutet schlimmer. Hier lungert unter der fehlenden Vision möglicherweise der Defekt, dass das Unternehmen eine Krise hat und eine Vision deshalb fehlt. Die Krise blockiert agiles Denken – und z.B. Scrum wird dann schonungslos diesen und noch tiefer liegende Defekte aufdecken. Scrum ist nicht dazu geeignet, eine Vision zu finden – sondern sich innerhalb dieser Vision agil zu bewegen. In meinem Sprachgebrauch steckt da ‚visio‘, also sehen / erkennen drin. Microsoft hat es auch so interpretiert.

# 5: Scrum, ohne Blick auf die Kultur

(Kommunikations-) Kultur kann nicht angeordnet werden. Sehr oft sehe ich in Unternehmen wohlfällige Kultur-Leitlinien (oft vom Marketing – und auf der Meta-Ebene) in Fluren, Räumen und Kaffee-Küchen. Leider habe ich (selten bis gar nicht) 2 oder mehr Menschen davor stehen und über die Punkte, die dort plakatiert wurden, sprechen, diskutieren oder gar einen positiv kritischen Dialog führen sehen. Selbst der Versuch, derartiges „anzuzetteln“ – verpufft. Achten Sie mal dann auf die Antworten – und Sie werden ahnen, dass hier nicht an dem Plakat (Aushang) etwas falsch ist, sondern in der Kultur und Haltung in den Köpfen, die davor stehen. Mehr in einen gesonderten Beitrag.

Schlau erkannte Stolpersteine

  • „Fassaden-Scrum“ – Intern wird alles gleich gelassen, Rollen und Begriffe werden scrumifiziert – drübergegossen – fertig ist die Fassade.
  • Fundamentale Bedeutung wird ignoriert – und eindimensionale, pragmatische Lösungen bevorzugt (bis durchgedrückt), ohne diese auf Sinnhaftigkeit zu hinterfragen (unerwünschtes, soziales Verhalten)
  • Prinzipien und Werte hängen hübsch an der Wand – tropfen aber elegant an den Köpfen eines jeden einzelnen ab – denn dafür ist keine Zeit. Also schnell weg …
  • Es wird nicht reflektiert, sondern (bei Fehlern) lamentiert und schöne Erfolge postuliert. Ja, schon gesehen: auf anderen Ebenen, Bereichen oder Themen – damit weiter „gekuschelt“ werden kann.
  • Es wurde nicht (alles) schlimmer, sondern Defekte wurden (plötzlich) sichtbar und transparenter. Somit schwoll der Kragen wegen dieser „Störungen“ – Störungen will keiner handhaben (müssen)
  • Es wird eine einfache Fehlerkultur akzeptiert – mach erst keine (Fehler). Dann stolpert (und lernt) niemand – was ja stört. Keine Fehler zu machen ist ein Wunschdenken, das direkt auf Metriken und KPI`s einzahlt. Und diese Ergebnisse lehren nicht, siehe weiter oben.
  • Je mehr (KPI’s) gemessen werden, desto gleichmässig stabiler gestolpert ist das Framework. Lost in Reports – der Mensch arbeit mehr für KPI’s anstatt für die Lösungen, die das Geschäftsziel sind (sein sollten) – und die Menschen sind weg.
  • (davon gibt es noch mehr …)

Unterschied: Der Prozess reglementiert

erst sichtbares, dann unsichtbares, dann unangenehmes

Wenn Du fährst und auf einen Baum zuhältst, wird Scrum dir dabei helfen (wie ein defekter Kollisionsdetektor), diesen noch schneller und treffsicherer zu erreichen.“ Scrum ist ein Prozess, wie eine Maschine, die (nur) in Gänze mit Präzision und Vorhersage funktioniert. Wird die Maschine falsch gesteuert oder bedient, … Na ja. Ebenso: Wird die Maschine verändert (modifiziert), können Geschwindigkeit und Treffsicherheit ungeahnte Auswirkungen (also nicht Baum 3-5, sondern gleich der erste) zeigen. Auch wenn es immer noch gerne ausgeblendet, weggedrückt oder auch weg reglementiert (bis zum Scrum Master als solches, gerade weil er mit Methode (Scrum, Kanban, etc.) Defekte aufdeckt), wird:

  • Scrum löst keine Probleme und wird es auch nie machen. Das war auch nie der Anspruch und steht auch nicht im Scrum Guide drin. Defekt des halluzinatorischen Wunschdenkens.
  • Scrum ist keine Methode oder Technik, sondern ein (Management-) Framework, um herauszufinden, ob eine Organisation oder etwas IN der Organisation dysfunktional ist.
  • Scrum ist der Regelprozess des Blicks in den Spiegel der Wahrheit – und die Wahrheit will nicht jeder sehen.
    Scrum ist nicht das Problem der Realität, sondern die Realität ist selbst das Problem. Scrum (und andere ‚Hilfskonstrukte‘) sind das Mittel zum Zweck.
  • Scrum ist Ihr Zahnarzt: Er hat einen Auftrag. Von Ihnen und von der Kasse. Er sieht genau hin, sammelt Daten, um dann damit und an Ihnen zu arbeiten. Es wird weh tun. Mit oder ohne Spritze, früher oder später.
  • Scrum ist wie im Krankenhaus, Schwester ‘Rabiata’. Sie hat einen Auftrag (vom Krankenhaus). Den Patienten schnell und nachhaltig wieder auf die Beine zu bringen – der nächste Patient wartet (auf Ihr Bett). Ja, das ist auch schonungslos.
  • Scrum bringt keinen Mehrwert, solange die Orga die aufgedeckten Probleme ignoriert und / oder nur fadenscheinige Maßnahmen mit konformen Lippenbekenntnissen (dazu später mehr) ergreift. Dann bringt es noch mehr Probleme.
  • Somit ist Scrum nicht agil, solange die involvierten Menschen aus dem, was mit Scrum passiert, nicht lernen und die richtigen Schlüsse für ihre eigene Entwicklung ziehen.
  • Somit sind es nicht Prozesse, die lernen, sondern Menschen. Solange Menschen für die Agilität kein Grundverständnis haben, wird jeder Prozess, nach innen betrachtet, scheitern.

und die Agilität exploriert (erforscht)

Ich schrieb: „Eine Methode ist nur eine Abfolge von mind. 2 einzelnen Techniken.“ Also Basis- Techniken (Basics). Hier ist im Kontext zu KaiZen (etc.) der Ansatz „KATA“ zu sehen (und auch zu postulieren) Dieser stammt (sehr ursprünglich) aus dem asiatischen Kampfsport und bezeichnet Denk- und Verhaltensweisen, die sich durch stetiges Üben und Anwenden zu Routinen entwickeln. Die Abfolgen werden dann beinahe reflexartig ausgeführt, da sich diese durch Üben und Anwenden zur Routine (Shu-Ha-Ri) entwickelt haben. Aha, kein Prozess, keine Prozessbeschreibung, sondern Denkprozesse, die ihre Zeit einfordern. Es ist einfachste, kleinteilige Technik + Üben + Machen.

Funktionieren Basis-Techniken nicht, können auch Methoden UND demzufolge auch keine Prozesse (also noch eine Stufe höher) funktionieren. Ganz abgesehen davon, dass Prozesse das spätere, ausgehärtete Produkt einer agilen Entwicklung werden können. Und das ist der Grund, warum Agile keine Prozesse braucht und auch keiner ist. Oben brachte ich das Beispiel mit der Knete. Solange Knete Knete ist, ist sie formbar, je flinker, dynamischer und flexibler, desto besser. Landet Knete im Ofen und wird gebacken, wird sie steinhart – halt wie Beton – und obendrein auch noch sehr brüchig. Das ist auch die Antwort darauf, wenn Prozesse brechen, dass dann wie bei einem Domino-Effekt vieles, was an dem Prozess (abhändig) dran- oder umgebacken wurde, ebenfalls bricht. Weiche Knete beult nur aus …

Kurzum: Es ist alles ein Change – der, sinnvoll (aus-) gestaltet, viel tiefer ansetzten soll als bisher postuliert (siehe oben Beweggründe). Dieses Prinzip, um Defekte jedweder Art zu behandeln, hat meiner Meinung nach an Relevanz verloren: „A Scrum Master should reveal, not resolve.“ (Ein Scrum Master sollte offenbaren, nicht auflösen.) Ein Scrum-Master (Agilist) soll die richtigen Fragen in der richtigen Methode stellen und dafür Sorge tragen, dass eigenes Denken, also lernen, einsetzt. Mehr nicht.

Mein Fazit (zu Scrum):

Mein Fazit hier: Scrum haftet das Problem an (eigentlich nicht wirklich, wird aber gerne so missbraucht), das es erstmal vieles, was verborgen war, aufdeckt. Mehr nicht. JETZT fängt die eigentliche Problemarbeit erst mal an – das Lösen der Probleme mit KVP, Agilität im Denken und Handeln. Dann und danach, wiederum z.B. mit Scrum, können die potentiellen Verbesserungen gesehen werden. Somit ist Scrum einem Prozess näher, also einer Methode, somit eine Abfolge von einzelnen Techniken, die in sich eine Verbesserung bringen – und deshalb einfach gelernt werden müssen. Lesen Sie bitte nochmal die ersten 4 Worte aus den Scrum-Guide: „Srum ist ein Rahmenwerk …“ (Dazu werde ich noch einen Kurs aufbauen und anbieten.)


1 Kommentar
  1. […] wissenschaftlich und auch in der Agilität schwer zu fassen (mir ist noch keine KPI dafür bekannt). Es durchzieht gleichwohl unser gesamtes soziales Miteinander und: Ohne […]

Einen Kommentar verfassen

©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend