Weder SCRUM noch Wasserfall – „WATER-SCRUM-Fall“
Was ich oft in den Schulungen beobachtet habe ist, dass viele Unternehmen zu „Water-SCRUM-Fall“ tendieren. Also der Mischung von SCRUM und Wasserfall – böse Zungen könnten es auch Rosinenpickerei nennen.
Das sieht in etwa so aus:
- In einem Sprint wird herausgefunden, was von den Stakeholdern gewünscht ist
- Weil das Team versucht agil zu sein, werden User Stories erstellt. Diese sind aber nicht wie von SCRUM gewollt, Platzhalter für weitere Diskussionen, sondern eine Minispezifikation dessen, was umgesetzt werden soll. Sie sind zu detailliert beschrieben.
- Im zweiten Sprint wird dann das Interface designed
- Einige im Team sehen Lücken in den Anforderungen – sehen dies aber als Teil der Agilität an und setzen weiter um
- Die Entwickler setzen anschließend das um, was in der User Story steht und jedes Detail, wie sich die Implementierung verhalten soll
In einem Schaubild gesprochen sieht dies in etwa wie folgt aus:
Erst die Analyse, in einem weiteren Sprint das User Interface Design und in einem dritten Sprint die eigentliche Implementierung und das parallele Testing. Genau das ist aber nicht agil – sondern ein iteratives Wasserfallmodell oder „Water-SCRUM-Fall“.
Im Gegensatz zum klassischen Wasserfallmodell ist das Projekt zwar in User Stories aufgeteilt aber die Bearbeitung erfolgt dennoch sequentiell und oftmals in der oben geschriebenen Abfolge.
Agil wäre es hingegen, wenn alle Arbeitspakete zur gleichen Zeit bearbeitet werden. Also Analyse, Design, Entwicklung und Testing. Dies ist sicherlich eine Idealvorstellung, aber diese Vorstellung liegt SCRUM zugrunde. Demnach erfolgt auch erst die genaue Spezifikation in dem Sprint oder frühstens im kurz vorhergegangenen Refinement Meeting.
In jedem Fall sollte aber vermieden werden, alles genau zu definieren. Denn was passiert dann? Es wird „stupide“ das umgesetzt, was gefordert wird. Es erfolgt kein Input mehr des SCRUM-Teams über eine wirklich zielführende und wertsteigernde Umsetzung – das Inkrement, also der Output am Sprintende, liefert keinen Mehrwert für den User. Hierbei gehen wesentliche Aspekte von SCRUM verloren.
Das SCRUM-Team sollte stets das Ziel verfolgen, die Arbeitspakete möglichst überlappend zu bearbeiten. Die Voranalyse erfolgt so spät wie möglich und sollte so wenig detailliert wie möglich. Die User Stories stellen keine Spezifikation dar, sondern eine Grundrichtung über die gewünschte Funktionalität aus Usersicht und lassen Raum für Diskussionen/weitere Spezifikationen für das gesamte Team.