.st0{fill:#FFFFFF;}

Scrum Einführung

Scrum Spezifikation: das sind die Fehler!

 Juni 15, 2016

von  Sebastian

Scrum Spezifikation?

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.

Scrum Team agile Menschen

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.

Sebastian

Ein paar Worte über den Autor
Agile Team Facilitator Sebastian Schneider
Agile Team Facilitator Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

__CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"62516":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"62516":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]}}]}__CONFIG_colors_palette__
Hier gehts lang!
>