SCRUM ist eine agile PM Methodik und gleichzeitig ein Vorgehensmodell, das in den letzten Jahren stark an Bedeutung zugenommen hat. Gleichzeitig fällt es vielen Unternehmen schwer, die Scrum Prinzipien 1:1 umzusetzen. Diese sind beispielsweise (siehe hierzu auch die Grafik unten):
- Daily Scrum Meeting (15 Min.)
- Sprints (ca. 30 Tage)
- Scrum Roles „Product Owner“, „Scrum Master“, „Team“, „Scrum Team“
- Sprint Planning Meeting
- Sprint Review Meeting
- Sprint Retrospective
- etc.
Ken Schwaber ist einer der Begründer von Scrum. Er erläutert im obigen Video, dass es unter gewissen Umständen legitim ist, von den definierten Scrum Prinzipien abzurücken und diese anzupassen. Schwaber nennt dies „ScrumBut“. Diese Bezeichnung kommt von der Aussage „Yes, we use Scrum, but…“.
Blogger-Kollege Jurgen Appelo geht sogar noch weiter und behauptet, dass das volle Potenzial von Scrum erst dann entfaltet werden kann, wenn ScrumBut angewendet wird, sprich wenn das Konzept den jeweiligen Rahmenbedingungen und vor allem dem jeweiligen Team angepasst wird.
Auch der von mir sehr geschätzte Kollege Pawel Brodzinski plädiert inständig für eine sinnvolle Anpassung von methodischen Ansätzen und Vorgehensmodellen. Sein Beitrag ist allerdings etwas ironisch geschrieben – ich musste ihn 2 mal lesen, um die Argumentation zu verstehen.
Verhältnismäßig wenige Expert/innen sehen ScrumBut kritisch und raten strikt davon ab, das Scrum-Konzept zu „verbiegen“. Es scheint sich die Meinung durchzusetzen, dass ScrumBut legitim oder sogar zwingend notwendig ist.
FAZIT: Ich denke, ScrumBut ist in den meisten Fällen sinnvoll und notwendig. Allerdings sollte man es sich in der Praxis nicht zu leicht machen. Denn das „Herz“ von Scrum – so wie es auch im agilen Manifest beschrieben ist – sollte niemals verloren gehen. Für ein differenziertes ScrumBut tritt auch Scrum-Experte Boris Gloger ein: „ScrumBut – Eine genauere Betrachtung„.
Nachtrag vom 19.11.2010: Boris Gloger hat recht. Die Formulierung „ScrumBut ist in den meisten Fällen sinnvoll und notwendig“ ist so nicht richtig. Ich stimme ihm zu, dass man die Implementierung von SCRUM als Entwicklungsprozess betrachten sollte. Natürlich ist das Ziel, agile Prinzipien so weit wie möglich bzw. soweit es Sinn macht zu implementieren.
Du hast Recht, es ist sinnvoll darüber nachzudenken die Implementierung von Scrum zu modifizieren und sie an die jeweiligen Rahmenbedingungen anzupassen.
Ein Beispiel: Das Unternehmen hat eine Entwicklungsteam von 5 Personen, der GF ist der PO. Wer soll der ScrumMaster sein. Dieses Unternehmen würde es wahrscheinlich nicht schaffen, sofort einen ScrumMaster Vollzeit abzustellen. Geschweige denn einen SM einzustellen. Gut, dann nimmt man eben in Kauf, dass der SM auch noch entwickelt. ABER … man ist sich dessen bewusst!!!!!! Und versucht diesen Umstand abzustellen. In dem Moment, wo man sich die Verbesserung leisten kann.
Ich finde es bedenklich ScumBut als „ScrumBut ist in den meisten Fällen sinnvoll und notwendig“, zu „verkaufen“. Das ist es nämlich nicht. Sondern, die meisten Unternehmen sind in zu Anfang nicht in der Lage „richtig“ Scrum zu machen. Genauso wie es kein Unternehmen geschafft hat sofort CMMi Level 5 zu implementieren. Aber jeder war sich immer bewusst, dass man nicht das Ideal erreicht hatte, wenn er auf Level 3 war.
Wer weiss was er tut, also den Grad der Meisterschaft erreicht hat, darf auch gezielt verändern. Schülern, Anfängern und allen die sich grad mal ein Buch über Scrum gekauft haben rate ich dringend Scrum hardcore, als by the book zu machen. Dann erzielen sie auch die versprochen Resultate.
Nunja, das kann ich nur mit einem Zähneknirschen lesen. Scrumbut ist sehr oft einfach eine Ausrede die notwendigen Ungemütlichkeiten zu vermeiden die ein erfolgrecihes Projekt erfordert. Wenn Scrum But dazu benutzt wird sich in der Comfortzone zu bewegen isses für den Eimer.
Ich finde ScrumBut absolut sinnvoll und notwendig.
Wir haben einige Kunden und Interessenten, die nicht aus der Software-Branche kommen und bei ihren Produktentwicklungen mit ganz anderen Rahmenbedingungen konfrontiert sind. Die können mit Scrum in Reinkultur nichts anfangen. Und das hat nichts mit Bequemlichkeit oder so zu tun. Aber die können die Idee, die in Scrum steckt, mit Adaptionen sehr gut gebrauchen, um ihre ausgefahrenen Wege zu verlassen und mehr Dynamik in Ihre Abläufe zu bekommen.
I’m surprised by this article. Jeff Sutherland talks about „Scrum, but..“ as being a negative quality i.e. something that you should seek to avoid (see http://www.youtube.com/watch?v=M1q6b9JI2Wc) – „the Nokia test“ from 10:30secs onwards.
Modifying Scrum for your own purposes is okay as long as the core values of Scrum are adhered to. For me „Scrum, but“ is a reserved term for refering to team who claim they are performing Scrum whilst not adhering to the key principples – such as delivering working software at the end of sprint.