So wird Scrum zu einem toten Pferd

Kennen Sie die Parabel vom toten Pferd?
Eine Weisheit der Dakota-Indianer sagt: „Wenn du entdeckst, dass du ein totes Pferd reitest, steig ab„.
Doch allzu oft steigen wir in unserem beruflichen Projektmanagement eben nicht ab, sondern versuchen andere Strategien, als es der gesunde Menschenverstand gebietet  …
Ein Beitrag von Andrea Mattner,
Agile Business Coach und Gründerin des #Leader Labs

Wenn das Pferd tot ist, steig ab

 

 

 

 

 

 

  1. Wir besorgen eine stärkere Peitsche.
  2. Wir wechseln die Reiter.
  3. Wir sagen: „So haben wir das Pferd doch immer geritten.“
  4. Wir gründen einen Arbeitskreis, um das Pferd zu analysieren.
  5. Wir besuchen andere Orte, um zu sehen, wie man dort tote Pferde reitet.
  6. Wir erhöhen die Qualitätsstandards für den Beritt toter Pferde.
  7. Wir bilden eine Task Force, um das tote Pferd wiederzubeleben.
  8. Wir schieben eine Trainingseinheit ein, um besser reiten zu lernen.
  9. Wir stellen Vergleiche unterschiedlich toter Pferde an.
  10. Wir ändern die Kriterien, die besagen, ob ein Pferd tot ist.
  11. Wir kaufen Leute von außerhalb ein, um das tote Pferd zu reiten.
  12. Wir schirren mehrere tote Pferde zusammen an, damit sie schneller werden.
  13. Wir erklären: „Kein Pferd kann so tot sein, dass man es nicht noch schlagen könnte.“
  14. Wir machen zusätzliche Mittel locker, um die Leistung des Pferdes zu erhöhen.
  15. Wir machen eine Studie, um zu sehen, ob es billigere Berater gibt.
  16. Wir kaufen etwas zu, das tote Pferde schneller laufen lässt.
  17. Wir erklären, dass unser Pferd „besser, schneller und billiger“ tot ist.
  18. Wir bilden einen Qualitätszirkel, um eine Verwendung für tote Pferde zu finden.
  19. Wir überarbeiten die Leistungsbedingungen für Pferde.
  20. Wir richten eine unabhängige Kostenstelle für tote Pferde ein

Da ich ein großer Pferde-Fan bin und meine Pferde über alles liebe, wechsle ich nun einmal auf ein anderes Bild: Auch im agilen Projektmanagement gibt es überaus wirksame Methoden, um erstens alle Werte, Prinzipien, Rollen, Aktivitäten/Timeboxes und Artefakte zu sabotieren und um dann in diesem k.o.-Zustand zu verweilen und sich zu wundern, warum „Scrum, Kanban oder Lean PM bei uns nicht funktioniert“.

 

In meinem kleinen Beitrag möchte ich mit Ihnen gemeinsam am Beispiel von Scrum auf solche Boykottierungs-Tools schauen. Wohlgemerkt: Ich erhebe keinen Anspruch auf Vollständigkeit – nach meinen Erfahrungen in den letzten Jahren weiß ich, dass es noch viel mehr fantasievolle/fantastische Mittel der perfekten Sabotage von agilem Vorgehen gibt J. Ach ja: und ganz ernst gemeint ist der Artikel auch nicht. Mein Wunsch ist es, Sie für die Stolpersteine im agilen Projektmanagement zu sensibilisieren. Viel Spaß und ebenso viele Erkenntnisse beim Lesen wünsche ich!

 

Scrum, richtig verstanden und gelebt, ist für mich – mal ganz kurz umschrieben

  • Gesunder Menschenverstand und instinktiv-lösungsorientiertes Teamverhalten, das auch in kritischen/heißen Situationen gut funktioniert. Lassen Sie mich dies kurz genauer definieren:
  • Zuerst das Wichtigste!
  • Und nicht alles gleichzeitig!
  • Die richtigen Dinge tun – also das, was der Kunde braucht, d.h. es findet eine ständige Rückkoppelung zum Kunden statt
  • Die Dinge richtig tun – dazu gehört auch, das, was man tut, bis zum Ende fertig zu bringen
  • Effiziente Kommunikation
  • form follows function
  • Alle für einen und einer für alle – Verbindlichkeit und Vertrauen – das eine geben, das andere bekommen und umgekehrt

 

Es ist sooo einfach, dieses lebendige, sich selbst-energetisierende System zu boykottieren und er zu einem „toten Pferd“ zu machen. Dazu hacken Sie sich in eine oder am besten in alle Scrum-Dimensionen und platzieren dort einfache, aber wirksame Impediments – nichts leichter als das!

 

Implementierung – Tipps zum eleganten, nachhaltigen Ausbremsen:

Verkaufen Sie Scrum als allheilende Alternative für den Entwicklermangel oder das schlechte Projektmanagement in Ihrem Unternehmen/Team.  Denken Sie nicht mal dran, das Team, das scrummen soll, in irgendeiner Form mitzunehmen und beharren Sie darauf, dass Scrum eine reine Methode ist, die nichts mit einem spezifischen Menschenbild zu tun hat. Im nächsten Schritt ersetzen Sie einfach nur die Begriffe aus dem klassischen Projektmanagement durch Scrum-spezifische Begriffe  – Monate werden z.B. zu Sprints. Wenn Sie dann noch SOFORT damit beginnen, die Scrum-Bestandteile zu verändern, haben Sie schon viel erreicht.

 

Rollen-Sabotage

Augen zu bei der Personalauswahl! Hier müssen Sie ganz einfach die einzelnen Rollen von innen heraus unterwandern. Besetzen Sie z.B. die Rolle des Product-Owners mit jemandem,

  • der sich nicht als Teil des Teams versteht. Um dies zu untermauern, binden Sie ihn im Unternehmen an möglichst vielen anderen Stellen fest ein, so dass er ständig „busy“ ist und keine Zeit hat. Kleiner Tipp: beliebt ist hier die Einbindung in alle möglichen strategischen Meetings.
  • der entweder ständig versucht, Kundenwünsche in den aktuellen Sprint zu schmuggeln.
  • Auch eine schöne Finte: besetzen Sie die Rolle des Product Owners und des Scrum-Master durch EINE Person – die Rollenverschmelzung von Product-Owner und Scrum-Master birgt die große Chance, dass sich an der klassisch gedachten Projektleiterdenke nichts ändert 😉

 

Der Scrum-Master darf auf keinen Fall greifbar sein für das Team. So richtig voran kommen Sie mit Ihrem Sabotageversuch, wenn Sie es bei der Rollenbesetzung so einrichten, dass der Scrum Master möglichst wenig systemisches Verständnis und soziale Kompetenz mit sich bringt. Auch wäre es schön, wenn Durchsetzungsvermögen fehlt. Zu guter Letzt sollte Empathie für ihn ein Fremdwort sein.

 

Wenn nun das Team nicht bereits zur (inneren) Kündigung motiviert ist, können Sie es noch wie folgt darin unterstützen:

  • auf keinen Fall Eigenverantwortung fordern/fördern/ zulassen
  • den Einsatz von möglichst vielen Tools unterstützen – wer braucht schon Kommunikation?
  • De-Spezialisierungen unterbinden, stattdessen Fachkönige heranziehen
  • Auf jeden Fall die langfristige Roadmap verheimlichen, damit niemand im Team den Kundenwunsch und Gesamtüberblick hat/hält
  • Impediment keine Beachtung schenken – also weder den Impediments an sich noch einem Lösungsversuch.

 

 

Und weiter geht`s mit den Artefakte – so lassen die Verantwortlichen sie zu einer Farce verkommen:

 

Product Backlog: Sie halten es nicht aktuell im Sprint Planning Meeting und entziehen dem Meeting damit die Planungsgrundlage. Sabotieren Sie weiter mit übergroßen, nichtssagenden Epics statt klarer User Stories und unterlassen Sie eine durchgängige Priorisierung, die darüber hinaus NICHT mit dem Kunden abgestimmt ist. Kurz: Stellen Sie dem Team ein Dickicht an Möglichkeiten bereit!

 

Sprint Backlog: Führen Sie die Altlasten nicht mit und sehen Sie auch keine Tasks für das „allgemeine Rauschen“ vor. Sorgen Sie für weitere Intransparenz, indem Sie das Backlog im Daily nicht vorhalten. Ein weiterer guter Trick: Schauen Sie, dass möglichst viele, unüberschaubar viele Tasks sich „in progress“ befinden – und verzichten Sie darauf, diesen Status konkreter zu visualisieren 😉

 

Burn Down Chart: Führen Sie das Tool als Management-Tool, nicht als Teamtool ein. Und ziehen Sie trotzdem keine Konsequenzen.

 

Impediment Backlog: Weglassen!

 

 

Timeboxes – was für ein schablonenhafter Unsinn!

 

Sprint: degradieren Sie mit ewig langen Sprints die Begriffe „Iteration“ und „Inkrement“ zu Worthülsen. Idealerweise wechseln Sie auch den Takt möglichst häufig. Sehr effektiv: Priorisieren Sie im Sprint immer wieder um und fügen Tasks hinzu, ohne andere zu streichen. Da Sie im Sprint Backlog keine Zeiten für das „allgemeine Rauschen„  eingeplant haben, wird das ziemlich schnell ein großer Spaß werden.

 

Sprint Planning Meeting: Wir sprachen schon drüber: nutzen Sie ein nicht-aktuelles Product-Backlog als Planungsgrundlage und sorgen Sie für stundenlange Diskussionen über riesige, schwammige Epics/User-Stories. Lassen Sie am besten generell ein Endlosmeeting daraus werden. Damit es dann am Ende schneller geht, sollte das Schätzen durch einen Kollegen geschehen – am bester durch den Kollegen, der im Team der dominanteste ist.

 

Daily Scrum: Weekly statt Daily – ein generell sehr gern gesehener Kompromiss. Zusätzlich lassen Sie am besten die drei Fragen in den Hintergrund rücken und das Sprint-Backlog unsichtbar – so ist die Konzentration schnell dahin. Letzter Tipp an dieser Stelle: Impediments nicht ernst nehmen und nicht weiter angehen.

 

Sprint Review: Ach ne – da droht der lästige Kunde! Bloß nicht sein Feedback einfließen lassen, damit bringt er nur alles durcheinander. Wenn Sie den Kunden mehr und mehr unzufrieden machen wollen, zeigen Sie ihm überwiegend unfertige Stories.

 

Sprint Retrospektive: Muss das denn wirklich nach JEDEM Sprint? Und MUSS das immer so emotional sein mit Stuhlkreis? Gehen Sie hier auf keinen Fall strukturiert vor – nicht mitschrieben, nichts vereinbaren oder nachverfolgen. Und nach den ersten Erfolgen einfach aufgeben. Auch ein sehr schöner Schachzug: einfach mal den Chef mit einladen 😉

 

Ein weiterer Angriffspunkt sind die Scrum-Regeln und -Tools:

  • Definition of Done nicht ernst nehmen – weder leben noch nachjustieren
  • Flipcharts nicht nutzen – das macht viel zu viel Arbeit
  • Für alles ein (anderes) Tool einsetzen
  • Feiern am Ende eines Sprints – wie albern ist das denn???!

 

Das war meine kleine Anleitung zur Sabotage von Scrum – leicht übertragbar auf andere agile Methoden, finde ich – oder?

 

Sie sehen: Es ist gar nicht so schwer, das gesamte Team in seinem Bemühen, im Sinne des Kunden wirksam zu sein, zu torpedieren. Fettnäpfe finden sich überall – bei den Bestandteilen, in jeder Implementierungsphase und sowohl nach Innen als nach Außen.

 

 

Ideen – Hub

Wir möchten Ihnen hier  eine Plattform bereitstellen, auf der Sie sagen können, was Sie aktuell beschäftigt. Wir nehmen Ihren Beitrag auf, anonymisieren ihn und veröffentlichen ihn in unserem Ideen Hub. Wir finden das wichtig, weil Sie damit einerseits den kontinuierlichen Verbesserungsprozess unserer Angebote anfeuern und weil Ihr Beitrag andererseits die Öffentlichkeit interessieren könnte.

Einen Beitrag für den Hub erstellen

13 + 10 =

Pin It on Pinterest

Share This