Im Rahmen einer Scrum-Einführung in Unternehmen hat man oft gegen Vorurteile zu kämpfen. Einige Argumente gegen Scrum stammen von Menschen, die den Einsatz von Scrum aus eigener Erfahrung kennen, der ihnen aber aus verschiedenen Gründen Unwohlsein bereitet hat. Der größere Anteil von Gegenargumenten stammt jedoch von Menschen, die zwar schon einmal etwas von Scrum gehört haben, die aber noch keine Gelegenheit hatten, es in Aktion zu erleben. In jedem Fall besteht der erste Schritt nun darin, die Ursachen für die Vorurteile zu finden, die Standpunkte zu erörtern und im besten Fall die Akzeptanz von Scrum zu erhöhen.

Ich habe eine Reihe von „Killerphrasen gegen Scrum“ gesammelt, um zur Diskussion anzuregen und Vorbehalte auszuräumen. Mittlerweile sind so viele Argumente zusammengekommen, dass ich mich entschlossen habe, eine Serie auf unserem Blog zu starten.

Sofortige Änderungen

„Meine Anforderungswünsche werden immer sofort auf Zuruf erfüllt. Bei Scrum geht das dann nicht mehr.“

Ein Projektleiter, der es gewohnt ist, seine Anforderungen innerhalb kürzester Zeit direkt vom Entwicklungsteam umgesetzt zu bekommen, sieht sich nun mit einem Scrum Master konfrontiert, der sich schützend vor das Team stellt und ihn darauf hinweist, sich mit Feature und Change Requests bitte an den Product Owner zu wenden.

Skepsis ist aus Sicht dieses Projektleiters daher absolut verständlich, denn schließlich hat er dafür Sorge zu tragen, dass die von ihm oder den Stakeholdern stammenden Wünsche so schnell wie möglich umgesetzt werden. Er fühlt sich sozusagen  eines gewissen Teils seines Verantwortungsbereichs beraubt.

Ich habe oft erlebt, wie gerade das Entwickeln auf Zuruf  zu unwartbarem Wildwuchs und einem instabilen System führt. Auch bei Scrum können Featurerequests und neue Ideen jederzeit eingebracht werden, kurzfristige Änderungen sind geradezu erwünscht. Allerdings werden diese Wünsche vom Product Owner im Hinblick auf die Vision bewertet, ihrem Nutzen nach priorisiert und gegebenenfalls im folgenden Sprint umgesetzt. Also beträgt die Wartezeit auf ein neues Feature, sofern es zum Gesamtkonzept passt und hoch priorisiert ist, oft nur eine Sprintlänge.

Hier möchte ich noch ergänzend hinzufügen, dass es immer auf das Unternehmen und das aktuelle Projekt ankommt. Es gibt Situationen, in denen ein Projektleiter mit Product Ownern zusammenarbeitet, in anderen Konstellationen wird er im Rahmen einer Scrum-Einführung selbst zu Product Owner, Scrum Master oder zum Softwareentwickler.

Code Ownership

„Meinen Code fasst keiner außer mir an.“

Mir sind schon einige Softwareentwickler begegnet, die sich sehr schwer damit tun, auch andere an ihrem Code arbeiten zu lassen. Sie betrachten ihr Geisteswerk  als eigenen Besitz, an den niemand außer ihnen selbst Hand anlegen darf. Liegt es daran, dass sie im Team wirklich durch ganz besondere Skills hervorstechen, oder trauen sie ihren Kollegen nicht so viel zu? Ist die Teamzusammensetzung verbesserungswürdig oder geht es gar um Machtkämpfe zwischen Entwicklern?

Es wird bestimmt für manche Entwickler oder Softwarearchitekten keine leichte Umstellung, dass der von ihnen geschriebene Code nun allen im Team „gehört“ und dass die ganze Gruppe für den Fehler eines Einzelnen verantwortlich sein soll. Aber am Ende ist die fertige Software eine Teamleistung, auch wenn einer mehr und ein anderer vielleicht etwas weniger dazu beigetragen hat. Wenn hingegen jeder auf seinem Stück Code beharrt, so kennt auch jeder nur diesen Ausschnitt, es wird sich nicht gegenseitig geholfen und es entstehen Wissensinseln. Diese machen sich besonders dann unangenehm bemerkbar, wenn der entsprechende Entwickler krank wird oder sich im Urlaub befindet. Gegenseitige Reviews und Pair Programming fördern den Teamgeist, tragen zur Verbesserung der Softwarequalität bei und erhöhen sogar das Entwicklungstempo.

Gesamtumfang

„Bei Scrum weiß ich nie, was ich an Gesamtleistung erhalten werde.“

Kunden möchten natürlich vor Projektstart genau wissen, was sie für ihr Geld bekommen. Sie befürworten daher die Erstellung eines umfangreichen und detaillierten Fachkonzepts, bevor mit der eigentlichen Entwicklung begonnen wird.

Ganz ehrlich: Auch das Vorliegen eines detaillierten Fachkonzeptes ist kein Garant dafür, dass allen Beteiligten klar ist, was letztlich an Gesamtleistung erbracht werden soll. Denn die Entwicklung komplexer Softwareprojekte stellt immer eine Art Forschungsprojekt dar. Es ist de facto nicht alles im Detail vorab planbar. Dies sieht man deutlich daran, in welchem Ausmaß gerade zum Ende eines klassischen Projekts um Change Requests gefeilscht wird.

Mit Scrum erhält der Kunde nicht das, was er irgendwann mal geplant hat, sondern das, was er tatsächlich braucht und nutzt. Gleichzeitig werden Kosten für überflüssige oder unbrauchbare Funktionalitäten gespart. Und wenn man mal in die falsche Richtung gelaufen ist, merkt man das im besten Falle schon nach einem Sprint und nicht erst nach einem oder zwei Jahren. Es gibt zum Projektende keine Kostenexplosion, sondern das Projekt ist jederzeit abbrechbar und befindet sich dennoch in einem nutzbaren Zustand. Die gemeinsame Arbeit mit dem Kunden ist nicht geprägt von Kosten- und Risiko-Abwälzungen, sondern es herrscht Offenheit, Transparenz und gegenseitiges Vertrauen.

Kommen euch die oben genannten Argumente gegen Scrum vielleicht bekannt vor? Wie würdet ihr darauf antworten?