Wasserfall als Scrum verpackt


Geld ist fertig, Projekt auch, das Resultat jedoch ist überhaupt nicht befriedigend. Von den 10 Requirements, wurden 5 Umgesetzt, 3 verlegt und 2 sind unter den Tisch gefallen. Von den 5 Umgesetzten sind 4 nicht reif genug für die Produktion und eines wird gar nicht mehr benötigt. Typisches Wasserfallproblem und dennoch mein tägliches Brot. In der heutigen Agilen Zeit eigentlich erstaunlich und dennoch wahr. Das Projekt wurde zwar unter der Aufschrift "Agil" vertrieben und betrieben, aber in Realität ist es ein klarer Wasserfall.

Ich habe gelernt, dass ein Sprint alleine Scrum nicht ausmacht. Es ist zwar ein gutes Gefühl, wenn der Entwickler nach 3 Wochen sagen kann, dass es fertig ist, aber wem nützt das dann, wenn es nicht auf einem Testsystem ist. Immerhin, der Statusreport ist grün. Und schon kommt der nächste Sprint, was die Situation nicht besser macht. Done ist done, wenn der Product Owner sagt und nicht vorher.

Daraus ergeben sich zwei wichtige Erkenntnisse:

  • Requirements
  • Done, is Done

Requirements

User Stories erzählen eine Geschichte. Eine Geschichte kann nachgespielt werden. Eine Geschichte lässt jedoch auch viel technischen Freiraum. Für mich als Enduser ist vor allem wichtig, dass ich ein Ziel erreichen kann, wie ist mir egal:

Untrainierter Nutzer X kann eine neue Site anlegen, um dadurch unabhängig von Abteilung X zu sein.

Daraus ergeben sich dann entsprechende Tasks:

  • Neuer Button hier
  • Vereinfachte Settings
  • usw.

Bisher bin ich immer gleich in die resultierenden Tasks gegangen und habe diese spezifiziert. Das führt dazu, dass der grosse Kontext fehlt, was das High level Testing erschwert.

Done, is Done

Meine zweite Erkenntnis. Done und der Highlevel Test im Voraus definieren. Wenn ein User Story vorhanden ist, ist das auch denkbar einfach. Unsere vorherige Userstory lässt sich ganz einfach mit folgendem Test testen: "Ein normaler Nutzer kann eine neue Site erstellen". Das lässt sich dann auch wunderbar in einem Sprint Review testen und der Entwickler muss nicht einen Excel Status anzeigen, und frech das Requirement auf grün setzen, dabei ist es vielleicht höchstens dunkel gelb.

Ach und übrigens: Eine kleine Demo auf dem Entwicklungsrechner ist nicht gut genug! Es wird dort garantiert laufen, aber wie sieht es hinter der Firewall, auf einem anderen Rechner aus?