Anstatt lesen: Unterwegs hören! |
- Hybride(s) Gemische …
- 12 Scrum-Irrtümer
- Mythen und Fehl-Erwartungen
- Irrglaube 1: Lasst uns Scrum nutzen und alles wird schneller (oder besser)
- Irrglaube 2: Mit Scrum haben wir viel mehr Probleme
- Irrglaube 3: Mit Scrum sind wir schneller (als vorher)
- Irrglaube 4: Jede Projekt ist tauglich für Scrum
- Irrglaube 5: Wir machen schon Scrum und sind agil
- Irrglaube 6: Wir können Scrum ohne Werte und Prinzipien verwenden
- Irrglaube 7: Planen? Brauchen wir nicht
- Irrglaube 8: Scrum schafft Manager ab. Manager – wozu?
- Irrglaube 9: Scrum einführen ist ein klassisches Projekt (mit Ende)
- Irrglaube 10: Ein Scrum-Master muss produktiv entwickeln können
- Irrglaube 11: Scrum Master gibt es an jeder Ecke …
- Nur einige Beispiele:
- Irrglaube 12: Der Scrum (-Master / Agilist / Coach / Trainer) ist dein Freund!
- Fazit (zumindest für Scrum)
- Mythen und Fehl-Erwartungen
- Kanban ist auch (k)ein (All-) Heilmittel
- Fakten und Irrtümer in Kanban
- (Un-) bewusst gestreut: Kanban in der IT
- Kanban funktioniert nicht mit „verteilten Teams“
- Pull anstatt Push, was soll das bringen?
- Kanban optimiert nur klassischen “Wasserfall”
- Kanban startet vom “Status quo” und Leute sträuben sich vor Veränderungen.
- Das Kanban Board wird nach einer Weile sowieso nicht mehr gepflegt
- Irrtümer in Kanban, die vermeidbar sind
- Irrtum 1: Doch nicht wagen? Finger weg, wenn das Management mit Kanban, Lean, Pull, Push, etc. unschlüssig ist …
- Irrtum 2: Ohne komplizierte wissenschaftliche Methoden kann Kanban nichts optimieren …
- Irrtum 3: Kanban für IT ist (nur) ein Modell für die Entwicklung von Software
- Irrtum 4: Kanban verhindert Zusammenarbeit von Gruppen
- Irrtum 5: Kanban ist nur ein Visualisierungs-Tool (daher mögen Mitarbeiter Kanban nicht)
- Fakten und Irrtümer in Kanban
Vorweg: “It’s not the spice, it’s the cooking itself”. Einige Dinge in der gelebten Agilität, wie beim Kochen, ändern sich nur sehr widerwillig bis gar nicht. Wie komme ich zu diesem Vergleich? Mehrfach ist mir aufgefallen, wie auch beim Kochen, dass es Dinge gibt, die im Vorfeld entweder eindeutig geklärt oder einfach vorhanden sein müssen, um darauf sinnvoll aufzusetzen. So entsteht Scrumbug, Humban und Unsicht. Sehen wir mal genauer hin.
Hybride (s) Gemische …
bei agilen Methoden – Sinn bis Unsinn
Die Frage ist: Warum hat ein Kochkundiger ein Rezept geschrieben? Um sicherzustellen, dass sein Gericht funktioniert. Wird etwas aus der Zutatenliste weggelassen oder modifiziert, wird das Ergebnis anders – zumindest unvorhersehbar. Ganz einfach: Je mehr ver- oder geändert wird, schon bei der Zubereitung, desto unvorhersehbarer das Ergebnis. Und somit bekommt der Satz: “It’s not the spice, it’s the cooking itself” im Kontext der Agilität eine wichtige Ausrichtung: Nur dass ich etwas mehr Gewürze beifüge (oder weg lasse), wird das (vergurkte) Gericht nicht besser, weil im mentalen Angang des Kochens, später dann in der Zubereitung schon gepfuscht wurde. Das kann es nicht sein … Dieses Verhalten im Kontext der Agilität wird in diesem Artikel beleuchtet.
Im ersten Step: (Basis-) Kommunikation
Ein Basis-Irrtum ist schon in der Kommunikation zur Agilität versteckt, den ich hier offen lege. Es wird in den oft verwendeten Worten (so ähnlich, es geht nicht um die Worte als solches, sondern um die Mechanik) deutlich sichtbar. Diese sind: “verstanden”, “begriffen” und “verinnerlicht”. Das sind 3 unterschiedliche Zustände, die ein Ergebnis und eine in Zukunft zu erwartende Veränderung in die gewünschte Richtung implizieren. Es wird dann vorab bestätigt “auf Teufel komm raus …”. Deutlich möchte ich hier auch abgrenzen, daß das Gehörte noch nicht das Verstandene ist – und somit eine weitere, 4. Schwachstelle darstellt. Und ganz außer acht gelassen, weil es dann unfair und fies wird, ist der Umstand der bewusst veränderten Realität, besser (verborgen) angedeutet mit diesem Bild (was ein anderes Thema ist) – sind Sie sicher?

Die Stufen im einzelnen:
“verstanden” beinhaltet nur das geistige nachvollziehen einer Argumentation. Über den gewünschten Zustand, ob das auch umgesetzt wird, wird nichts ausgesagt. Es kann ein beobachteter Widerstand mit einer Wahrscheinlichkeit von bis zu 75% eintreten.
“begriffen” beinhaltet das emotionale Element des be-greifens (taktile Wahrnehmung, spüren) einer Argumentation. Im Moment des Wahrnehmens wird ein emotionaler Bezug zur Aussage aufgebaut. Der gewünschten Ziel- Zustand wird deutlich sicherer, bis zu 60%.
“verinnerlicht” ist eine wertvolle Rückmeldung, da es einen Bezug wie bei “begriffen” gepaart mit “darüber nachdenken” und auch “reflektiert” beinhaltet. Das Gewünschte wird bewertet und mit einer passenden Entscheidung zutreffend in die die eigene Sicht “eingebaut”. Die gewünschte Veränderung wird (deutlich eher mehr als weniger) eintreten.
Im zweiten Step: Die Auftragsvergabe
Auffällig nach vielen Projekten ist, retrospektiv gesehen, nach der Vergabe des Auftrages, folgendes herausgekommen, wobei eine Absicht nicht angenommen werden kann.
- Der Wahrheitsgehalt von Anforderungen, die zu einem Projekt führen sollen oder können, ist entweder in sich selbst widersprüchlich oder wird immer unklar(er)
- der selbige Stabilitätsfaktor in den Anforderungen ändert sich, (meisst schleichend bis vernebelnd), wenn das Projekt schon läuft
- Die mentalen Eigenschaften von (übergeordneten) Funktionsträgern, wenn diese merken, dass an ihren eigenen Pfründen gerüttelt wird, zementieren sich Richtung Abwehr
- die zu ändernden (inneren) Haltungen von Kollegen und Mitarbeitern, die involviert sind, steigert sich in eine Verlust-Aversion.

Jeder Scrum-Master ist gut beraten, sofern er im Vorfeld eine inhaltliche Differenz oder Unstimmigkeit entdeckt, diese klar und offen zu kommunizieren, (Wie geht das? Nur mit zuhören und hinterfragen) – und auch hartnäckig zu bleiben. Rechnen Sie mit “eigenartigen” Reaktionen – die auf Unwissenheit bis Trotz deuten. Aber genau dafür sind Agilisten ja da. Schätzen Sie für sich genau ab, welches Risiko Sie eingehen wollen (und können …)
Im dritten Step: Drin im Daily Business
In der Agilität, vorweg Scrum, sind Irrglauben und Ammenmärchen zu finden, die hellhörig machen (sollten).
Projekte werden durch agile Methoden (nicht automatisch) erfolgreicher (Scrumbug)
Bekannte Großprojekte (ob abgeschlossen oder nicht), wie Stuttgart 21 oder der BER sind Vorhaben, die durch lange Planungen und Zyklen und einhergehender, mangelnde Flexibilität zum Scheitern verurteilt – scheinen. Worüber nicht öffentlich gesprochen wird, und da sehe ich des Übels Wurzel: Klare Absprachen, politische oder finanzielle Aversionen und “Püppchen rücken”, auch “Ränkespiele” genannt auf Nebenschauplätzen. Die Agilität in den Projekten, sofern richtig eingesetzt, verspricht die “zuckersüße” Lösung. Die Umsetzung soll schneller und zielgerichteter gelingen, und das alles soll mit weniger Fehlern passieren. Ich finde hier 3 Weichmacher, die auf Wunschdenken, einer verzerrten Erwartungshaltung sowie Mythen (dazu später mehr) basieren. Wie sieht es die Wissenschaft? Kann diese die höheren Erfolgsquoten von agilen und iterativen Projekten bestätigen? Und nur der Vollständigkeit halber: Im Artikel “Die agile ENT- Täuschung” wird das Thema erst ganz un-agil und dann agile beleuchtet.
Die Mechaniken sind hinlänglich bekannt. Die ersten Ansätze agilen Arbeitens stammen aus der Programmierung und Entwicklung von Software (z. B. Kent Beck (1999)) und drücken auch bzw. erst eine Geisteshaltung aus. Genau hier findet die erste Verzerrung statt: Eine Geisteshaltung wird nicht gemacht oder wie ein Projekt-Plan abgearbeitet (mechanisches erledigen), sondern diese entsteht durch Einsichten und Erkenntnisse (ja, auch aus Fehlern) und vor allem nicht über Nacht. Valide, statistische Studien belegen, dass Erkenntnisgewinn und anschliessende Veränderung daraus im Schnitt 40 Tage dauern. So wurde 2001 aus agilen Grundsätzen und Werten das Agile Manifesto (Sutherland, Beck, Cunningham et al.) formuliert, ein Dokument, dessen Liste an befürwortenden Unterzeichnern bis heute wächst.
Interessant: Wächst. Der Hinweis, dass Erkenntnis nur nach und nach wachsen kann. Beispiel: Erwarten Sie mal von einem 4-jährigen Kind, in dem Sie ihm das Fahrradfahren theoretisch erklären oder aufmalen, dass es sofort und unmittelbar Fahrad fahren kann?
Der Stand der Dinge
Was kennt die Wissenschaft heute (2016)? Es dominiert der Einsatz agiler Methoden – besonders im Softwaredevelopment – zu 90 % in Unternehmen. In IT-nahen Projekten nutzen 41 % der Unternehmen die agilen Methoden, während in Projekten ohne IT-Bezug nur 27 % der Unternehmen dies taten. Diese Zahlen und der Trend, dass immer mehr Unternehmen und in denen organisierte Projektteams agiles Arbeiten anstreben, beruhen auf den Ergebnissen der Studie vom BPM-Labor für Business Excellence der Hochschule Koblenz in Zusammenarbeit mit der GPM sowie der IPMA aus dem Jahr 2015 (2016).
Die über 600 Teilnehmer aus 30 Ländern gaben in der Studie „Status Quo Agile“ zum zweiten Mal Einblicke in Verbreitung und Nutzen agiler Methoden. 50 % der Befragten setzte Mischformen (Hybride) aus agilen und klassischen Projektmanagementansätzen ein, 25 % rein agile Methoden und ca. 15 % nutzen klassische Tools. Agile Praktiken schneiden in allen untersuchten Kriterien, wie Ergebnisqualität, Teamwork, Mitarbeitermotivation, Termintreue, Effizienz, Kundenorientierung und Transparenz besser ab als klassische Projektmanagementmethoden.
Kernaussage ist: Die Anwendergruppe, die komplett und konstant agil arbeiten, sind erfolgreicher in ihren Projekten als die hybriden Anwender, die aufgrund Inkonsistenz gescheitert sind. Erst, wenn man genau weiß, was man macht, kann weiterführendes Wissen hierzu hilfreich sein. Insbesondere auch das Wissen, wie “man” es nicht macht. Wie z.B. mit Scrumbug, Humban und Unsicht – davon handelt dieser Beitrag.