In einem netten Artikel verweisen die Autoren vom Innovationsblog darauf, dass in hierarchischen Organisation mehrere Systeme nebeneinander existieren. Mit den gleichen Grundprinzipien und Werten ist es möglich parallel die Finanz-, IT-, Personal- und andere Abteilungen zu führen. D.h. mehrere „Betriebsmodi“ existieren parallel, der Innovationsblog nennt es Multi-Modalität. Warum sollte das nicht auch mit einem weiteren Modus funktionieren?
Ich kenne vor allem Scrum als Framework im Kontext vom agilen Arbeiten. Dort stellte ich immer wieder fest, dass in einem nicht agilen Umfeld die Agilität des einzelnen Teams immer an den Systemgrenzen der nicht agilen arbeitenden Organisation scheitert. Der Anspruch an einen Scrum Master ist organisatorische Impediments zu adressieren. D.h. der Scrum Master befindet sich in einem fortwährenden Konflikt zwischen seinem Team und der Organisation.
Er bekämpft, ob bewusst oder unbewusst, die Modi in deren andere Bereiche des Betriebes arbeiten. Er bekämpft nicht das Was gearbeitet wird, sondern häufig das Wie gearbeitet wird. Das obliegt, agil oder nicht, in der Hoheit des Teams und Managements der jeweiligen anderen Betriebseinheit.
D.h. der Konflikt ist zwischen Scrum Master, der lediglich agil arbeiten möchte, dessen Team lediglich hochgradig effizient sein möchte, und dem anderen Team, was es tut, wie es das tut etc.
Über kurz oder lang gibt es mehr als einen Scrum Master und je nach diplomatischen Geschick ist entweder eine Grass-Roots, zeitlupenlangsame Transformation im Gange oder es wird auch dem Management gewahr, dass etwas passieren muss, da der Druck von unten, lateral, teilweise aber auch von oben zu groß wird.
Bis es dazu kommt, haben sich die Begrifflichkeiten und Fronten verhärtet. Wasserfall wird mittlerweile gleichgesetzt mit hierarchischen Arbeiten – was natürlich nichts miteinander zu tun haben muss. Aber im Eifer des Gefechts wird nicht mehr unterschieden. Da ist Scrum und Agil auf einmal eine Mischung aus Kommunismus und Demokratie, während klassisches Arbeiten Diktatorisch ist. Agiles arbeiten ist fluffig, sehr viele Buzzwords, sehr wenig Konkretes. Beweise mir doch einmal, bevor wir eine agile Transformation machen, dass es sich lohnt. Also nicht in einem Buch, sondern konkret für unseren speziellen Fall.
Die Agilisten sind nach mehreren Jahren stetigem Rumnörgelns oft genug latent gereizt ob der Begriffstutzigkeit ihrer Umgebung, die Umgebung latent genervt von diesem immerwährenden Agile, DevOps, was auch immer. Der eine will liefern, der andere redet ständig über Verbesserungen die sich irgendwann in der Zukunft vielleicht, vielleicht auch nicht auszahlen. Der eine hackt mit der stumpfen Axt im Wald, der andere schlägt regelmäßiges Schärfen vor, inklusive einer kurzen Pause um darüber nachzudenken, wie man effektiver und effizienter Holz hacken könnte. Das hält nur auf bzw. ohne das geht es nicht. Hüh oder Hott. Team oder Einzeloptimierer. Jemand der zu langsam Holz hackt ist faul oder unfähig, das löst man nicht über Teamwork und Prozessoptimierung. Dafür gibt es Zielvereinbarungen, Bonuskürzungen und Management-Ansprachen.
Und so geht das Spiel immer weiter. Beide, der Agilist als auch der Konservative, beide wollen das gleiche. Liefern. Aber die Methoden sind nicht nur grundverschieden, sondern geprägt von Gegensätzen. Man könnte auch sagen, dass der Konservative eher das umgekehrte Manifest unterschreiben würde. Prozesse und Tools über Menschen und Interaktionen.
Und damit endet meine Hypothese: Der Grundbaustein des Glaubenskriegs ist in dem darunterliegenden Wertesystem verankert und hat mit der Methodik an sich nichts zu tun. Intuitiv riecht auch der Nicht-Agilist den Braten, das hier etwas eingeführt wird, dem er von A bis Z skeptisch gegenüber steht, weil sich vieles bis alles davon nicht mit seiner Erfahrungswelt und seiner Art zu arbeiten deckt.