Geschrieben am

„Wir arbeiten agil und brauchen daher keine Spezifikation“

Unbenannt

Machen wir uns nichts vor

In „klassischen“ Projektvorgehensweisen, etwa nach dem Wasserfall- oder dem V-Modell wird viel Papier erzeugt und jede Menge an Spezifikationen geschrieben, die sich im späteren Verlauf als nicht haltbar herausstellen. Viel Mühe — und meist völlig umsonst.

Agiles Vorgehen im Projekt geht dieses Problem folgendermaßen an.

  1. Kurzer zeitlicher Abstand zwischen Konzeption und Umsetzung: Die Zeit von der genauen Konzeption eines Inkrements bis zur Umsetzung erfolgt im Scrum-Prozess im Sprint Planning Meeting. Zwischen dem Sprint Planning Meeting und dem Sprint selbst vergeht nicht viel Zeit, so lange kann man sich auch komplexere Dinge meist einfach merken.
  2. Der Product Owner ist involviert: Der Product Owner — also der Kunde selbst oder sein in-house Vertreter — ist bei der Konzeption eng mit dabei und nicht nur ein Jahr im Voraus in der Spezifikationsphase wie im klassischen Wasserfall- oder V-Modell-Vorgehen.
  3. Das Entwicklungs-Team ist involviert: Die Entwickler sind bei der Konzeption involviert, wissen also auch, was entschieden und vereinbart worden ist — und lesen es nicht erst lange später „aus zweiter Hand“ nach.
  4. Die Abnahme liegt ja von der Konzeption nur einen Sprint „entfernt“: Das bedeutet, auch zum Zeitpunkt der Abnahme wissen noch alle, was vereinbart war. Im Original-Scrum-Prozess sind das nur wenige Wochen.

Diese vier Regeln sorgen dafür, dass zu Beginn jedes einzelnen Sprints bei allen Beteiligten ein sehr hohes Verständnis und ein hoher Konsens darüber besteht, was im Sprint entwickelt wird und wie es genau entwickelt wird.

Dann besteht doch eigentlich keine Notwendigkeit, das alles minutiös aufzuschreiben — oder?

Sollte man meinen. Oder?

Es gibt aber einige Aspekte, die auch in einem agilen Projektvorgehen für Spezifikationen sprechen.

Der Faktor Zeit

Folgender Fall:

Product Owner Paul geht mit einem sehr aufwändigen, aber hoch priorisierten Feature ins Sprint Planning Meeting. Es stellt sich heraus, dass dieses Feature zu aufwändig für den anstehenden Sprint ist — also gesplittet werden muss.

Für den anstehenden Sprint wird beschlossen, die Hälfte des Features (für den Kunden unsichtbar, nur die Änderungen „unter der Haube“, sowie einige andere billige Product Backlog Items) umzusetzen und die zweite Hälfte des teuren Features im folgenden Sprint zu machen.

Auf eine detaillierte schriftliche Spezifikation wird verzichtet, weil zum einen die dafür notwendigen Aufwände nicht zur Verfügung stehen und zum anderen die Konzeption jedem klar ist und Konsens herrscht.

Wie besprochen wird im anstehenden Sprint also die erste Hälfte umgesetzt. Zeitgleich erfährt Paul von seinen Ansprechpartnern beim Kunden, dass überraschend der größte Mitbewerber eine großartige neue Funktionalität in sein Konkurrenzprodukt gebracht hat. Die muss jetzt sofort nachgezogen werden.

Es kommt wie es kommen muss: die zweite Hälfte der umfangreichen Änderung kommt nicht wie geplant. Sie kommt sogar erstmal 4 Sprints lang gar nicht. Diese Sprints werden dazu benötigt, hektisch dem Mitbewerber hinterherzuarbeiten.

Endlich kehrt Ruhe ein und Paul kann die zweite Hälfte des vor langer Zeit konzipierten Features in das Sprint Planning einbringen. An das Konzept kann sich leider niemand mehr so genau erinnern. Und spezifiziert hatte man es auch nicht.

Dieser Fall ist nicht unüblich — Sprints sind i.d.R. nur wenige Wochen lang. Selbst in mittelgroßen Teams sind da keine Quantensprünge an Änderungen am Produkt erwartbar. Wenn außerdem einzig und alleine das Sprint Planning Meeting für die genauere Konzeption des (möglicherweise nur aus User Stories bestehenden) Product Backlogs verwendet wird, besteht für Konzeptarbeit nur wenig Zeit. Und für das Aufschreiben dann gar keine.

Das Scrum-Manifest ermutigt sogar zu diesem nicht-dokumentierten Vorgehen, weil es explizit

Wir schätzen […] Individuen und Interaktionen mehr als Prozesse und Tools

fordert.

Nichts ist beständiger als der Wandel

Folgender Fall:

Zwei Senior Developer des Entwicklungs-Teams scheiden überraschend aus. Der eine geht in Elternzeit und der andere wird Scrum Master bei einem anderen Arbeitgeber.

Product Owner Paul bringt zwei neue Features ins nächste Sprint Planning Meeting mit, bei denen er keine großen Probleme erwartet. Bei der Konzeption und Schätzung der Features entsteht im Entwicklungs-Team jedoch große Unsicherheit. Die beiden Features bedienen sich einer bereits vorhandenen Funktionalität — wie teuer dies jedoch ist, ist unklar, weil deren Funktionsweise unklar ist. Die beiden Senior Developers, die es wüssten, sind nicht mehr verfügbar. Eine Spezifikation existiert nicht.

Kann ebenfalls passieren. Auch diese Situation wird durch das agile Manifest durchaus gefördert:

Wir schätzen […] funktionierende Software mehr als umfassende Dokumentation

Erwarte niemals, dass der Kunde Dir sagt, was er will… geschweige denn, was er braucht…

Paul muss noch einmal herhalten.

Product Owner Paul kommt zurück vom Treffen mit dem Kunden und hat einige Wünsche im Sinne von User Stories für den nächsten Sprint im Gepäck. Der Kunde selbst ist in einer anderen Stadt und kann Paul daher ins Sprint Planning Meeting nicht begleiten. Rückfragen beim Sprint Planning werden daher so gut es geht und in der Kürze der Zeit selbst beantwortet.

Paul präsentiert den priorisierten Product Backlog, im Sprint Planning Meeting wird ein Konzept erstellt und ein Sprint Backlog an Tasks aufgebaut.

Dann startet der Sprint. Feedback des Kunden nach Sprintende ist jedoch: „Das System tut, was es soll — ich hätte es mir aber anders gewünscht und einige Dinge sind einfach absolut unüblich für die Branche geworden und werden so keine Akzeptanz finden.“

Auch dies ein nicht an den Haaren herbeigezogener Fall. Es wurde keine Zeit auf genauere Konzeptarbeiten verwendet. Und selbst wenn ein Product Backlog Refinement stattgefunden hätte: man hätte dessen Ergebnisse dokumentieren müssen, sie sind üblicherweise zu komplex als dass man sie sich hätte gut merken können.

Empfehlung

Sie können es sich vielleicht schon denken, mein Vorschlag ist recht simpel: Verwenden Sie Spezifikationen! Ich schlage Ihnen nicht vor, nach Altvätersitte Jahre im Voraus fein granuliert aufzuschreiben, was Jahre später wie genau umgesetzt wird, aber ein Fachkonzept bzw. ein technisches Konzept haben manchmal wirklich Vorteile.

Das geht sogar sehr simpel und ohne dass Sie Ihren Scrum-Prozess in irgendeiner Weise ändern müssen. Hier ist, wie:

Als Product Owner:

  1. Erzeugen Sie zu jedem Product Backlog Item auch ein korrespondierendes Product Backlog Refinement Item.
  2. Behandeln Sie ein Product Backlog Refinement Item genau wie ein Product Backlog Item.
  3. Kippen Sie im Scrum Planning Meeting zunächst das Product Backlog Refinement Item ein, bevor Sie das zugehörige Product Backlog Item einkippen. Lassen Sie sich eine Schätzung der Entwicklung geben für die Konzeptarbeiten. Stehen Sie für die Konzeptarbeiten für Rückfragen zur Verfügung und kommunizieren Sie auch dem Kunden, dass er zur Verfügung stehen möge.

Als Scrum Master:

  1. Wehren Sie sich für das Entwicklungsteam dagegen, dass Product Backlog Items im Sprint Planning Meeting an Sie herangetragen werden, ohne dass Sie vorher Zeit hatten für dazugehörige Product Backlog Refinement Items.
  2. Kommunizieren Sie Ihrem Team, dass es in seinem eigenen Interesse liegt, sich zunächst konzeptionell mit einem Thema zu beschäftigen, bevor es in die Tasten oder zum Lötkolben greift. Es ist demotivierend, etwas zu bauen, wenn man es nachher wieder einreißen muss (weil es anders gewünscht war).

Als Entwicklungsteam-Mitglied:

  1. Niemand außer Ihnen kann die Fallstricke erkennen, die in der Umsetzung eines Product Backlog Items (d.h. einer User Story) lauern.
  2. Niemand außer Ihnen kann sagen „Ich bekomme 95% des Geforderten 2 Tagen hin, für die restlichen 5% geht aber der restliche Sprint drauf“. Nutzen Sie diese Expertise und helfen Sie so dem Produkt.
  3. Wenn der Product Owner Ihre Konzept-Gedanken zu Papier bringt, schauen Sie ihm über die Schulter, dass er auch alles richtig aufschreibt. Er wird Sie im nächsten Sprint beim Einkippen des zum Konzept gehörigen Product Backlog Items daran erinnern.

Wie Sie gute Spezifikationen bzw. Fach- und technische Konzepte schreiben, erfahren Sie auch hier im Blog. Oder Sie kontaktieren mich einfach auf der Kontakt-Seite.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.