Direkt zum Hauptbereich

Stolpersteine beim Bootstrapping SCRUM

Ich habe mittlerweile in mehreren Unternehmen miterlebt, wie Scrum quasi via "Bootstrapping" eingeführt wurde. Mit Bootstrapping meine ich, dass innerhalb eines Teams, in dem ein gewissen Scrumwissen vorhanden war Scrum (zumindest intern) verwendet wurde. Ggf. wurde noch ein Buch dazu gelesen, die Rollen verteilt und los geht es mit den Sprints.

Ein Tweet und damit verbundener Link von Patrick Koglin hat mich gerade wieder darauf aufmerksam gemacht:




Leider habe ich bei diesen Vorhaben immer wieder ein paar Stolpersteine entdeckt, welche ich hier mal Auflisten möchte:


  • Missachtung von Shu Ha Ri
    Scrum sieht ein Inspect & Adapt vor. Aber anstatt Scrum erstmal anzuwenden und später zu Anpssungen zu kommen wird als erstes das Rahmenwerk destabilisiert (angepasst) weil "bei uns ist das alles anders". Die Gefahr besteht hier da drin, dass ein Unerfahrenes Team (ohne Coach) nicht überblicken kann was die Auswirkungen sind und so Scrum und dessen Sinn hier unterläuft.
  • Teilzeit ScrumMaster
    Die Rolle des ScrumMasters wird von einem Teammitglied z.B. Entwickler übernommen welcher seine "alte" Rolle in Teilen beibehält. Oft beschränkt sich das Verständnis der ScrumMaster Rolle auf Prozessüberwachung. Also nutzt er seine Zeit um die Termine zu erstellen, Charts zu malen etc. Für seine Aufgabe, die Teamperformance zu verbessern hat er keine Zeit, sie beschränkt sich auf Retrospektiven oder auch einfach keine Ermächtigung.
  • Scrum wird als Prozess gesehen
    Weil die Organisation seit jeher Prozessorientiert ist sieht sie Scrum auch nur als weiteren Prozess. Dass es um eine ganz andere Transformation geht bleibt ein blinder Punkt.
  • Inspect & Adapt ist Contextsensitiv
    Die Anpassungen und funktionierenden Tools und Methoden sind Contextsensitiv. D.h. was für das eine Team / Projekt / Unternehmen Sinn macht kann wo anders ganz daneben sein. Trozdem wird immer wieder versucht diese einfache zu Übernehmen. (Was auch in Teilen zu Verbesserungen führen kann) Ein gutes Beispiel dafür ist, dass viele Methoden, welche in agilen Umfeldern erfolgreich war als agile Methoden / -Tools bezeichnet werden.
  • Scrum ist nicht agile
    Oft wird Scrum als Synonym für agile gesehen. Aber Scrum ist ein Framework welches auf einem agilen Weg helfen kann kein agiles Ziel. Man kann Scrum auch ganz ohne agile einsetzen. (siehe auch nächsten Punkt)
    Scrum ohne agiles Manifest
    Oft habe ich erlebt, dass bei einer Scrum Einführung das agile Manifest keinmal erwähnt wird. Dabei gilt: agile ist wenn man die Werte und Prinzipien! des agilen Manifests einhält. (Hab dazu auch mal einen Tweet oder Blog von einem der Unterzeichner des Manifests gesehen - kann mir da wer mit der Quelle helfen?)
  • Fehlendes Management Support
    Das ganze Vorhaben wird am Management vorbei gemacht. So sind die Rollen nicht richtig Ermächtigt um ihre Aufgaben zu erfüllen. Wenn das Management davon Kenntnis hat, wird es "Geduldet" und wenn es "funktioniert" hat das Management zwar noch keine Ahnung aber freut sich nun auch agile zu sein. - Wozu nun noch mehr investieren?
  • Iterativer Wasserfall
    Nun gibt es zwar Sprints und die neuen Meetings aber das StandUp ist eher Reporting als Micromanagement in Crossfunktionalen Teams und das Backlog ist auch nur ein Projektplan in anderem Format.
  • ScrumMaster Ausbildung
    Obwohl die ScrumMaster oder ProductOwner Zertifizierungsvorbereitung in der Regel nur 2 Tage dauert (im Gegensatz z.B. zum PMP) wird sie als Ausbildung angesehen. Hier fängt das lernen aber eigentlich erst an.
Grundsätzlich spricht natürlich nichts gegen ein "Bootstrapping" aber es gibt halt einige (sicher noch mehr als mir gerade eingefallen sind) Stolpersteine welche zu beachten sind. Ein erfahrener Coach kann da sicher helfen.

Kommentare

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte. Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen ve rteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Mit dem Rücken am Tellerrand

Es ist gut auch mal über den Tellerrand zu schauen. Manchmal sind wir so in "unserer Welt" gefangen, dass wir den Rest gar nicht mehr wahr nehmen. Zum Beispiel muss ich mich immer wieder daran erinnern, dass nicht alle Menschen mindestens ein Smartphone haben. Oder das agile noch lange nicht Mainstream ist. Nur weil wir uns in einem Umfeld bewegen, in dem die Dinge so scheinen wie sie sind, heißt das noch lange nicht, dass dem auch so ist. Ein Typisches Beispiel für den Unterschied von Realität und Wahrnehmung der Realität. Aber auch um neuen Ideen eine Chance zu geben, welche scheinbar nicht funktionieren können, weil sie nicht in unsere Gedankenwelt passen ist es sinnvoll ab und an über den Tellerrand zu schauen. Heute habe ich noch einen Tweet, welcher darauf hinweist gesehen: Wenn uns das einmal bewusst geworden ist, dann neigen wir (oder zumindest geht es mir so) dazu möglichst oft über diesen Tellerrand zu schauen. Dabei kann es aber passieren, dass wir so

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität. Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus: Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit. Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist. (Was nun was bedingt, lass ich mal dahingestellt) Dadurch haben sich natürlich auch di