Scrum Spezifikation?
Eine Spezifikation kennt so ziemlich jeder, der sich mit Entwicklung von Produkten befasst. Eine solche Spezifikation beschreibt auf einem sehr detaillierten Level, wie etwas umgesetzt werden soll. Im agilen Projektmanagement Scrum kennen wir das so nicht, aber wie reagieren denn Teams, die von klassisch zu Scrum wechseln? Werfen Sie Ihre Spezifikationen weg? Nein, in der Regel stehen alle vor dem gleichen Problem - sie versuchen die Spezifikation in Scrum abzubilden und scheitern mit einem Wasserfall-Scrum. Einiges im Umgang von Spezifikationen und Scrum in diesem Artikel!
Was ist diese Spezifikation?
Wir finden dazu schnell und abstrakte Hilfe bei Wikipedia. Deshalb erspare ich mir die Details, aber ich denke ich spreche vielen aus der Seele, dass es genau die Dokumente sind, die gerne in einem Office-Schreibprogramm verfasst werden und zahlreiche Elemente und Informationen enthalten. Schnell sind mal 20, 30, 50 oder noch mehr Seiten dazu gekommen. Zudem folgenden ganze Glossare, was denn die einzelnen Begriffe überhaupt bedeuten. Um so ein Dokument ansatzweise zu lesen, ist ein 2-Stunden-Termin im Nu vorbei.
Was passiert in Scrum mit Spezifikationen?
Nicht wenig Teams, die ich in meiner Laufzeit betreut und gesehen habe, starten bei einer Einführung von Scrum immer nach dem folgenden Muster: Wir zerlegen einfach diese Spezifikation in kleinere Teile. Das wird dann gerne auch mal User Story genannt, wobei der Name und die Art keine Rolle spielen.
Wenn die Teams wenig oder keine Erfahrung mit Scrum haben, ist das verständlich. Deshalb findet sich das Muster der Scrum Spezifikation oft dann, wenn die Rahmenbedingungen einer Transition nicht klar sind oder die Grenzen in der Organisation (noch) nicht abgesteckt sind.
Das Team muss sich dann oft den Anforderungen stellen, mit denen es sonst auch arbeitet. Und das ist und bleibt oft die Spezifikation. Ein Vorgehen ist dann in etwa das folgende:
- Die Spezifikation wird gelesen und der (angehende) PO oder gerne auch der Projektleiter teilt dann die Themen darin auf, er weiß wer das umsetzen kann und verteilt.
- Diese Aufgaben werden dann in einem der nächsten Sprints versucht umzusetzen.
So funktioniert Scrum aber nicht
So gerne ich trotzdem mit solchen "Scrum Spezifikation"-Teams arbeite und den A-ha-Effekt dieser Teams erlebe: genau damit steht die Einführung von Scrum unter einem schlechten Licht. Es kann nämlich nicht funktionieren, da die folgenden Dinge auf dieser Ebene immer passieren:
- Das Team bekommt in dem beschriebenen Fall das WIE vorgegeben und bestimmt es nicht selbst! Zudem muss es sich damit auf eine fremde Lösungen noch committen. Die Motivitaion für ein Team als "verlängerte Werkbank" zu dienen ist nicht gerade hoch.
- Diese Spezifikation so aufzuarbeiten, dass es im Refinement oder gar im Planning ansatzweise durchgesprochen werden kann ist aufgrund der Länge nicht möglich und verschlingt massiv Zeit!
- Oft resultieren Fehler aus der Spezifikation, da das WIE so detailliert und verwirrend in "Spezifikationsdeutsch" formuliert wurde, damit sich jede Partei absichert. Dann werden diese Fehler diskutiert und hin und her geschobene, statt Mehrwert für den Kunden zu schaffen.
- Die Spezifikation wird einfach in kleine Teile geteilt und dann als Aufgaben oder User Stories in den Sprint geschoben. Das kann man machen, ist dann halt Sch... 🙂 Damit fokussieren wir kein Produktinkrement am Ende des Sprints und damit nehmen wir dann auch keinerlei Produktrisiko mehr aus dem Projekt, denn es wird eh alles nur nach dem X. Sprint fertig.
- Die Scrum Meetings werden plötzlich unglaublich lange und komischerweise dauern die viel länger als im Scrum Guide steht 😉 Ja natürlich, Scrum ist als Framework sehr effektiv. Die Effizienz muss jeder selbst in den Prozess bekommen. Wenn ich aber das falsche im Termin noch so effektiv mache, bringt das dem Projekt rein gar nichts.
Zusammenfassend: die Scrum Spezifikation gibt es nicht und das hat seinen guten Grund. Teams, die im Übergang von einem klassisch geprägten Umfeld, hin zu einer agilen sind, können dem Problem gegenüberstehen. Auch dann hilft nur: verbessern Sie sich immer kontinuierlich. In Scrum machen Sie das mit der Retrospektive, ist die Zeit einmal sehr knapp, probieren Sie doch unterschiedliche Formate der Retrospektive.
