Scrumbug, Humban und Klarsicht-Methoden - It’s not the spice, it’s the cooking itself
Inhaltsverzeichnis

Irrglaube 9: Scrum einführen ist ein klassisches Projekt (mit Ende)

  • „Eine Scrum-Einführung ist irgendwann (auch) zu Ende.“
No. That doesn’t work nor well.

Ich bekomme Projektanfragen, um eine Scrum-Einführung zu begleiten. Soweit, so gut. Schnell höre ich raus, dass das „Projekt“ – mal genauer angesehen, ein bekanntes Muster offenbart. Eine Scrum – Implementierung ist ein Projekt mit einem Start- und einem End-Datum, somit festgeschrieben und kann sich somit genau wie ein Projekt planen. Schwindel ergreift von mir Besitz – und weiter: Je nach Größe der Organisation und der Anzahl der Teams wird die Einführung x Monate dauern, danach sind alle Teams agil. Punkt – ich starre Inhaltsleer auf mein Telefon. Autsch! Ein Planungstrugschluss allerfeinster Güte, der allein auf einem phonetischen Irrtum incl. Wunschdenken aufsetzt.

Die Schwindel legt sich. Allein schon das Festlegen eines Enddatums beweist den unreflektierten, tayloristischen Blick durch die BWL / VWL-Brille, dass Menschen, hier gerne auch FTE’en genannt werden, als Maschinen betrachtet und kalkuliert werden. Ganz einfach gesagt: Ich bestelle die Einzelteile (suche / bestelle mir zu dem Team einen Scrum-Master / Coach / Agilisten), baue diese Maschine zusammen (lasse den sein Wissen an den Einzelteilen ausspeichern und z. B. Scrum anstarten), Strom drauf (reglementiere ein neues Verhalten und erhöhe die Spannung und Taktung im Team = Skalierung) und schon fluppt die Maschine (Mensch-Mitarbeiter) besser und produziert oder läuft wie geölt. Wie finden Sie das? mit dem geölt … , wobei unstrittig ist, das Scrum skaliert werden kann – keine Frage, aber Sie werden dann noch andere Inpediments finden. Die, die als unerwünschte Abhängigkeiten bekannt und als unwegbare Hindernisse deklariert sind.

Einzelnen Teams werden 1-3 Monate Zeit gegeben, um „auf Scrum umzustellen“ – kann ja mit 26 Seiten Scrum Guide nicht so schwer sein. Machen, so wie es da steht. Dabei werden verschiedene Aspekte auf mehreren Ebenen völlig und gerne außen Acht gelassen.

Auf Teamebene:

  • Jedes Team ist individuell. Solche, die regelrecht dafür brennen, etwas zu verändern. Andere sind verhalten bis extrem skeptisch. Lange Anlaufphasen sind nicht vorhersehbar. Später dazu mehr.
  • Bestehende Teamstrukturen sind historisch gewachsen. Wie vorgehen? Aufbrechen? Behalten? Macht es Sinn, sie vor dem Hintergrund eines schlanken, neuen Prozessrahmens neu aufzustellen? Diese Umstellung benötigt Zeit und neu zusammengestellte Teams müssen sich erst aufeinander einschwingen. Wie lange das dauert, ist nicht vorhersehbar.
  • Was ist mit den innerhalb eines Teams vorhandenen Strukturen? Gibt es einen ‘inoffiziellen’ Teamlead? Ein Alpha-Tier? Einen Architekten? Was soll aus diesen Rollen (bzw. den, die personell noch nicht existent sind), werden? Planen Sie mal +/- 3 Tage, bis wann Sie die fehlenden Ressourcen zusammen haben. Realistisch? Mind. 3 Monate, eher mehr …. also nicht vorhersehbar. Die Liste „unvorhersehbar läst sich (sehr) lang verlängern …

Auf Individualebene:

  • Jeder Mensch ist individuell. Der Bildungsweg und das Verhalten in seiner Arbeit sind eine immer währende Dressur. Erhebliche Einflüsse (soziales Umfeld, Eltern, Freunde, als auch Sachzwänge) zerren an diesem Menschen, mal offensichtlich, mal versteckt oder verdeckt. Aber sie zerren – jeden Tag. Auf welcher gesicherten (wissenschaftlichen) Grundlage wollen sie planen, ob und wann dieser Mensch der neuen Dressur folgt? Das ist nicht vorhersehbar.
  • Jeder Mensch (im Team) lernt, begreift und fühlt anders. Die Vermutung, nur weil es Agilität gibt, einen Scrum Guide mit überschaubarem Inhalt, einen Coach oder Trainer, der ein paar Wochen an Überzeugungen und Werten “herumschraubt”, dass dann dieser Mensch lernt und begreift wie gewünscht, am besten noch in 1-3 Monaten – Sorry, nicht vorhersehbar und illusorisches Wunschdenken. Wissenschaftlich (auch durch bildgebende Massnahmen und quantitativ umfassende Studien) bewiesen, somit Fakt und Stand der Dinge sind Erkenntnisse aus der Lern- und Hirnforschung, der Verhaltensökonomie und den gesammelten Erfahrungen, die als Sekundär-Literatur herangezogen werden können. Es ist erstaunlich wie (vehement) diese noch junge Wissenschaft ausgeblendet oder gar weg-ignoriert wird. Die Lern- und Umstellgeschwindigkeit ist nicht vorhersehbar.

Selbst wenn in einem hypothetischen Modell auf Teamebene alle Parameter auf Erfolg stehen, bedeutet „auf Scrum umstellen“ im Kontext eines Teams nur die Bildung eines lokalen Optimums. Wenn es ein Optimum „von der Stange“ gäbe, könnte es ja jeder. In dem vorstehenden Satz sind drei Weichmacher verborgen – die aber dem geneigten Hirn des Entscheiders fluffig gefallen. Dieses Gefallen ändert aber nichts an den Weichmachern, oder? Das ist die Realität.

Oft wurde versucht, Agilität zu definieren. Die meisten Definitionsversuche fangen ungefähr wie folgt an. „Agilität ist die Fähigkeit einer Organisation, sich auf Veränderungen einzustellen und flexibel zu reagieren.“ Lokale Optima in den Teams durch Scrum sind sicher gewünscht und erstrebenswert. Es gilt aber auch, den Überbau – die Organisation – entsprechend zu justieren – und da, nicht (nur) ‚unten‘, fängt Agilität, auch mit dem Kulturaspekt, an.

Sehr hilfreich ist, direkt und ohne Hierarchien untereinander im Team zu kommunizieren und an den Grenzen des Teams möglichst frei zu interagieren. Allen muss klar sein, dass die aktuelle als auch die künftige Teamstruktur nicht in Beton gegossen ist. Je nach Anforderung und im Sinne einer stetigen Verbesserung kann diese verändert werden. Unter dieser gedanklichen Vorgabe sollte schnell klar sein, dass man eine Scrum-Einführung nicht als ein Projekt betrachten kann. Wer es trotzdem macht, (kehren wir mal wieder zu Kochen zurück), wedelt geistig mit einem potenten Gasbrenner-Flammbierer herum und hat wenig Ahnung / Erfahrung, ob er genau damit ein rohes Stück Fleisch zu einem leckeren Steak gezaubert bekommt (Wunschbild mit falschem Thema, falschem Werkzeug, falschem Vorgehen mit falschem Ansatz). Es kann bestenfalls ein Anschub für ein Umdenken und ein permanentes Streben nach Verbesserung sein. Eine Scrum-Einführung ist ein andauernder Prozess, dessen Ergebnisse sich in sich selbst verbessern. Kein Projekt. Das leisten Menschen – keine Maschinen (Computer).

Irrglaube 10: Ein Scrum-Master muss produktiv entwickeln können

  • „Wie sonst soll denn geführt werden, wenn der Scrum-Master fachlich dem Entwicklerteam nicht auf die Finger klopfen kann?“

Ein Irrtum, der aus den Ursprüngen von Scrum (aus der IT- und Developerwelt) herausgewachsen ist – und sich auch hartnäckig hält. Nach neuesten, kommunikativen Entwicklungen (und auch den bisher bekannten Verwerfungen) ist „entwickeln können“ mehr und mehr ein Attribut, ein Feature mit „nice to have“, weil die Erkenntnisse der Verhaltensökonomie, gerade in den heutigen Zeiten, immer wichtiger werden. Laut Scrum Guide ist dieses Attribut weder im Scrum-Guide noch in direkten Kommentaren dazu genannt – durch Verwerfungen in den Anforderungen wurde dieses Feature bis zur konkreten Anforderung „herbeigewünscht“ und bleibt somit ein Irrglaube. Sehen wir uns die Rollen, die Charaktere mal genauer an. Wir reden über Rollen und Funktionen, die im Team übernommen und auch ausgefüllt werden sollen.

  • Jede Rolle im Scrum Setup hat einen anderen Schwerpunkt.
    Die Aufgabenverteilung in Scrum ist recht klar verteilt und auch getrennt. Der Product Owner muss sich überlegen, WAS und WANN entwickelt werden soll. Der PO ist somit sach- und zeitgetrieben – mehr die technische Komponenten. Das WAS sollte unabhängig von den Fähigkeiten des Teams geschehen, das WANN in Hinblick auf die Auslastung des Teams. Es fehlen noch das WIE und WOMIT. Darum, um nichts anderes, kümmert sich der Scrum-Master. Der Scrum Master hilft dem Team, dieses Ziel erreichen zu können – also die humane und Umsetzungskomponente. Aber nicht damit, dass er am Code oder Prozeduren, die das Team erstellt hat, „rummäkelt“, sondern indem er genau wahr nimmt, WO (erst recht in der 2. Reihe) Störungen sind, die dieses Team davon abhalten, Bestleistungen abzuliefern. Ebenso sollte der Programmierer eines Teams nicht auch noch gleichzeitig Tester sein. Sicherlich kann ein guter Programmierer testen und ein guter Tester programmieren. Jedoch ist es sehr sinnvoll, diese beiden Rollen zu trennen. Ein guter Tester beherrscht seine Testwerkzeuge, ein Programmierer seine Coding Tools und seine Quellen, wie und womit er seinen Code erzeugt. Da sehe ich klare Abgrenzungen.
  • Jeder Einzelne hat auch so genug zu tun
    Die Rolle als Scrum-Master bzw. die Rolle als Product Owner erfordert die gesamte Aufmerksamkeit einer Person. Nicht selten hantiert ein PO mit hunderten von Tasks, Tickets oder Stories in seinem Backlog. Die alle im Blick zu haben ist Auslastung genug. Ebenso hat der Scrum-Master nicht nur eine Person, die er begleitet, sondern 6-8 pro Team (im Idealfall), und jedes Mitglied ist ein einmaliges Individuum, das betreut werden soll. Auch eine Vollzeitauslastung – sonst wird das ausser halbherzigen „Herumgeschraube an Oberflächlichkeiten“ nichts mit der Scrum-Masterei. Hier ist der Charakterzug des Verantwortungsbewusstseins gegenüber dem Team gefordert. Würde man einer Person beide Rollen übergeben, würde eine der beiden definitv hinten runter fallen. Erst recht, wenn diese 2 Persönlichkeiten vom Management einer Person übergeholfen wurden und der Ausführende sich emotional nur für eine entscheiden kann. Führt er beide aus, gerät er in einen Interessenskonflikt.
  • Beiden Rollen erfordern unterschiedliche Persönlichkeiten
    Die Fähigkeiten und Wesenszüge, die gute Scrum-Master und Product Owner ausmachen, überschneiden sich an einigen Stellen. Um in der Mengenlehre zu bleiben: Schnittmengen. Aber keine Inklusions-Menge, weil die Anforderungen und Ausprägungen der Rollen sehr unterschiedlich sind. Ein Beispiel (es hinkt etwas), aber in die richtige Richtung zeigt: Aus dem Kochen: Sie haben ein leckeres Fisch / Fleisch Gericht und ein leckeres Pasta / Salat Gericht hergestellt. Essen möchten Sie beide Gerichte, jetzt und sofort. Machen Sie mal, Sie werden sich überessen, mit allen Konsequenzen. Besser ist, sich zu entscheiden: Heute das eine, morgen das andere – und Sie haben mehr davon. Und auch viel angenehmere Konsequenzen. Es ist recht unwahrscheinlich, dass jemand in beiden Rollen – gleichzeitig – wirklich gut ist. Spätestens, wenn emotionale Interessenkonflikte spürbar werden.
  • Es muss eine natürliche Spannung zwischen den Rollen geben
    Die natürliche Spannung zwischen den beiden Rollen ist mit den 5W (Was, Wann // Wie, Womit, ergänzend mit Warum und Wofür) gegeben. Beide Rollen getrennt sollen maßgeblich am Erfolg des Produkts oder Systems interessiert sein. Product Owner sind Business getrieben, Scrum-Master eher nicht, weil sie hingegen die Probleme der Ausführenden im Blick haben, die genau dann aufkommen, wenn ein Team mehr, mehr und mehr leisten soll. Es baut sich ein Gleichgewicht auf: Der Product Owner geht seiner natürlichen Neigung nach, mehr zu fordern – er ist der verlängerte Arm der Stakeholder. Der Scrum-Master passt dann darauf auf, dass es nicht zu viel oder besser human-verträglich wird. Und dann vor allem sinnvoll im Sinne des Teams, des Endkunden und dann der Stakeholder bleibt. Ein einfaches Sprichwort sagt: „Du biegst einen Bogen – bis er bricht.“ Der PO biegt, der Stakeholder fordert, der Scrum-Master verhindert (kontrolliert) das Brechen (des Teams). Also: Das Ausführen mehrerer Rollen in nur einer Person wird (früher oder später) scheitern. Die Anforderung dafür ist absehbarer Humbug.

©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend