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:

Bin gerade aufgewacht und mir kam die Idee wie man Scrum schnell & günstig einführen kann. Profitiert auch davon! http://t.co/08Nxp0IOeH
— Patrick Koglin (@patrickkoglin) 10. Februar 2015

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.