Scrumbug, Humban und Unsicht

Anstatt lesen: Unterwegs hören!

Irrglaube 11: Scrum Master gibt es an jeder Ecke …

• “um gut zu “Scrum-Mastern” braucht es nicht viel (Hmm: Traue keinem unter 40)”

Die daraus abgeleitete Frage ist: “Wo soll denn die Berufs- (besser noch Lebens-) Erfahrung herkommen? Von Zetteln und Zertifizierungen?” “Zettel” (Zertifizierungen) sind so, aber definitiv nur die eine Sache. In guter Absicht definiert können diese Zettel nur die Grundlagen legen. Und: Was gerne übersehen wird: Derartige Zettel beweisen, dass der Stoff gut und repetierfähig gelernt wurde – eine Aussage über das Verstehen belegt dieser nicht.

Selten kommt aber dann das dabei raus, was sich Personaler, Projektleiter oder Manager dann darunter vorstellen. Der Bezug zu Können ist ein anderer. Ein nicht diskutables Beispiel zeigt es: Sie wollen fahren und machen einen Führerschein. Sie bestehen die Prüfung und erhalten eine gültige Fahrerlaubnis. Ob Sie fahren können (und in kritischen Situationen mit dem Gerät “Motor-Vehikel” (bitter, es kann auch als Waffe benutzt werden) sinnvoll, weit- und vorsichtig umgehen, ist eine ganz andere Geschichte. Nicht wegzudiskutieren sind die Unfallstatistiken von jungen Menschen. Damit sollte die Verzerrung zwischen Wunschdenken und Wirklichkeit als Irrtum 11 aufgedeckt sein.

Egal, welche Zertifizierung man nimmt, Scrum Alliance oder Scrum.org, dieser Zettel alleine reicht keinesfalls aus. Erst recht bei Scrum gilt die alten Regel: Soziale Kompetenz ist Trumpf. Wer andere Menschen anleiten will, muß wissen, was er ‘mit den Menschen’ tut. Das ist kein Leistungsnachweis, sondern langjährige Erfahrung. Und je mehr Erfahrung gesammelt wird, wird (zwangsläufig) der Scrum-Master älter. Erfahrung sammeln ist ein linearer Vorgang, der durch keinen Zettel ersetzt oder durch Abkürzungen verringert werden kann. Somit komme ich zu dem Schluss: Traue keinem (Scrum-Master) unter 40.

Nur einige Beispiele:

• Er muß Erfahrung im Umgang mit verschiedensten Typen von Menschen gesammelt haben und auch mit deren Macken umgehen können.
• Er muß abschätzen können, welche Typen er vor sich hat und wie diese zu behandeln sind.
• Kommunikationsfähigkeit wird vor allem für das Überzeugen gebraucht. Wer Scrum einführt, gewinnt nur, wenn er Leute von dieser Idee überzeugen kann. Auch und gerade gegen Widerstände, die sich bei einer derartigen Veränderung erwartungsgemäß einstellen. Das braucht viel Einfühlungsvermögen bzw. Empathie.
• Er muß in kürzester Zeit Beziehungsnetzwerke schmieden können, um z.B. ein Gegengewicht zu Widerständlern aufbauen zu können.
• Er muß sowohl auf der Ebene des Managements als auch unter Team-Mitgliedern taktieren können, um seine Sache voranbringen zu können. Dabei ist Durchhaltevermögen der Schlüssel zum Erfolg.
• Er muß die Ideen von Scrum verinnerlicht haben, um andere wirklich davon überzeugen zu können.
• Er sollte selbst mal in dem Dilemma gesteckt haben, das zur Entwicklung des Scrum Frameworks geführt hat. Tiefe Überzeugung läßt sich nicht anlesen, hier braucht es Lebenserfahrung.
• Er muß Teams auch menschlich betreuen. Heißt: Nicht nur die Scrum Regeln beibringen.
• Er muß feine Antennen für die Befindlichkeit des Teams haben, um im richtigen Moment mit den richtigen Maßnahmen einzugreifen.
• Er muß mit Unsicherheit ebenso umgehen können wie mit überschwänglicher Euphorie. Beide Extrema können sich in regelmäßigen Abständen ablösen und erfordern ein geschicktes Gegensteuern.
• Im Idealfall: Er sollte sich etwas mit der Psychologie und einhergehenden Gruppendynamiken, insbesondere im ökonomischen Umfeldern beschäftigt haben. Letztendlich geht es um das Verstehen menschlicher Verhaltensmuster in den jeweiligen Rollen und Lebensräumen, in denen sie sich bewegen, und der Interaktion von Individuen untereinander.
• Und: Finger weg von Scrum!Wenn …
  • das Projekt bereits in Schieflage ist. Er muß wissen und erkennen, daß Scrum als Allheilmittel angesehen wird, aber keine der Hoffnungen auf akute Verbesserung erfüllen kann (siehe weiter oben: etwa schneller zu werden, um verlorene Zeit wieder reinzuholen). Zur Erfüllung dieser Hoffnungen müßten die Projektmitglieder, das Management und der Kunde gemeinsam eine 180 Grad Kehrtwende im Kopf vollziehen. Die Realität zeigt, daß mindestens einer von diesen nicht dazu bereit ist, weil: Kultur findet nicht im Scrum statt, sondern in den Interaktionen zwischen Menschen.
  • bereits bereits gefestigte Projektstrukturen existieren und entsprechende Rollen gelebt werden. Besonders wenn die Führungsebene den Command- und- Control- Ansatz (C&C) lebt, wird Scrum eine Entmachtung einleiten, gegen die eine oder mehrere Personen politisch taktieren werden. Der notwendige Energieaufwand für einen Sinneswandel ist in diesen Fällen destruktiv und viel zu hoch. Und: schlaue Know-How-Träger werden abwandern – das können Sie glauben, ich habe es gesehen (4 in 2 Monaten mit ‘ruck’, ganz ‘artig’ – und WEG).
  • sich Mitglieder im Team befinden, die sich selbst mit dem C&C Ansatz engagiert haben. Die Idee des verantwortlichen, selbstbestimmten Arbeitens wird Irritation schaffen. Es entsteht Ablehnung oder Gleichgültigkeit und in jedem Fall wird die  Produktivität negativ beeinflußt.
  • die Ressourcen fehlen, die Scrum Rollen auszufüllen. Nichts ist schlimmer, als ein Rollenmix zwischen Scrum Master, Product Owner oder Entwickler (siehe weiter oben) bzw. der Wegfall einer dieser Rollen. Ebenso ineffizient ist der Mix zwischen im Projekt existierenden, beibehaltenen Rollen mit den neu eingeführten von Scrum. Eine saubere Trennung dieser Rollen durch eine einzelne Person ist weder emotional noch physisch durchzuhalten. Scrum wird verwässert.
  • der Projektmanager seine konventionelle Leitungsfunktion nicht aufgeben will. Dies macht selbstbestimmtes Arbeiten der Team-Mitglieder unmöglich und die einsetzende Demotivation lähmt schließlich alles.
  • der Kunde nicht zur Verfügung steht. Soweit nur eine Kommunikation via Dokumenten, gesharten Tickets, Trello oder Mail möglich ist und eine mündliche Kommunikation mit dem Kunden die Ausnahme bleibt, wird die Rolle Product Owner nicht gelebt werden. Das Scrum-Haus mit seimen Framework zerbröselt in Reiberei und Ineffizenz.
  • der Management-Support fehlt. Wenn der kurzfristige Abbruch der Einführung von Scrum wie ein Damoklesschwert über dem Projekt schwebt, weil das Management schnelle Resultate sehen will, wird sich das Projekt nicht einschwingen können. Lernen braucht Zeit. Genau das und die ist aber die Voraussetzung für die Realisierung möglicher Effizienzsteigerungen. In diesem Fall kontakariert das Management das selbst herbeigewünschte Ergebnis. Was für ein Trugschluss – deluxe – mit Goldkante.

Irrglaube 12: Der Scrum (-Master / Agilist / Coach / Trainer) ist dein Freund!

• “Weil wir uns im Team alle lieb haben (werden), wird alles besser!”

“Der Scrum-Master ist nicht der Freund des Entwicklungsteams!” – Das kann er auch nicht, weil ER damit seinen Auftrag im Team konterkariert. Diese etwas PROvozierende Aussage zeigt einen weiteren Irrglauben, der auf einem Trugschluss basiert, auf. Es ist (öfters) anzufinden als vermutet. der Scrum-Master kann und darf nur sehr bedingt der Freund des Entwicklungsteams sein, weil er einen Auftrag hat, diese (auch mit etwas schmerzbehafteten Methoden) in eine neue/andere Richtung zu führen – Im Kopf, Im Herz und im Verhalten (siehe weiter oben). 2 Beispiele, die es ohne weitere Diskussion plakatieren:

• Training, Geräteturnen, bitte stellen Sie sich das bildlich vor: Wie oft hat der Sportler seinen Trainer (und sich selbst) verflucht, weil er am Reck oder an den Ringen in 2 Metern Höhe daneben gegriffen und (schmerzhaft) unsanft auf dem Boden gelandet ist?
• Handwerk, Kochen: Wie viele versuchte Gerichte hat der Lehrling, trotz korrekter Anweisungen des Lehrkochs, letztendlich doch entsorgen müssen (das schmerzt, Lebensmittel weg zu werfen), bis er es richtig (und auch in der richtigen Reihenfolge) konnte? In beiden Fällen: 1x? 10x? Oder 100x?

Der Auftrag des Scrum-Masters ist, einerseits das Team (nennen wir es unfreundliche) Übergriffe von dem unangenehmen (sogar teilweise feindlich betrachteten) Product Ownern, Stakeholdern, Managern, Vertriebsmitarbeitern und Anwendern zu beschützt oder gar vollständig abzuschirmen. Andererseits ist die eigentliche (und einzige) Verantwortung des Scrum-Masters, die kontinuierliche Produktivität des gesamten Scrum-Teams (und nicht nur des Entwicklungsteams) sicherzustellen und auch möglichst zu steigern, (s. Bsp. Sport-Trainer). Alle konkreten Aufgaben, die ein Scrum-Master hat, lassen sich in meiner Welt darauf zurückführen. Dies sollte nie und nicht aus den Augen verloren werden.

Bei der Aufgabe als Wächter und Förderer des Scrum Prozesses kommt die Produktivität zum Tragen. Durch die Förderung werden agile Werte und Prinzipien implementiert, diese steigert damit wiederum langfristig die Produktivität, die sich verbessert. Und das, gerade vom Scrum-Master, kann es bei entsprechendem Fehlverhalten auch erfordern, konsequent bis direktiv, zumindest sehr deutlich, aufzutreten. Somit ist dieser Trugschluss aufgeklärt: Der Scrum-Master muss dem gesamten Prozess / Projekt positiv gegenüberstehen und dementsprechend mit allen Projektbeteiligten (Achtung: Nach innen in das Team UND nach außen in die Organisation) sinnvoll agieren. Und weil es immer um (mehr oder weniger) Befindlichkeiten geht, kann er nicht NUR Freund sein. Oder geben Sie eine Ihrer Befindlichkeiten (die mit Verlustaversionen einher gehen) freiwillig und ohne Diskussion auf? Muster: “Ab morgen fahre ich (und Sie nicht mehr) Ihr Auto.” Reflex gemerkt? Überzeugen Sie mich mal …so und freiwillig glaube ich das nicht.

---