Die Ausgangslage
Eine Behörde wollte einen Geschäftsprozess mit 40.000 Vorgängen im Monat automatisieren. Das Projekt war auf zwei Jahre angelegt, das Team bestand aus fünf Entwicklern, einem Product Owner und einem Scrum Master. Wir sind nach dem ersten Jahr eingestiegen.
Wie sich der Engpass gezeigt hat
Das erste Jahr war komplett für technische Grundlagen draufgegangen. Das Entwicklungsteam kannte deshalb die Fachlichkeit des Projekts noch nicht. Vom Fachbereich gab es noch kein einziges Feedback. Ob die Anforderungen richtig verstanden waren, wusste nach einem Jahr niemand.
Woher er kam
Der Plan hatte ein ganzes Jahr Technik vor jede fachliche Arbeit gestellt. Solange nichts Fachliches gebaut wurde, konnte der Fachbereich auch nichts prüfen. Das Feedback fehlte also aus einem einfachen Grund: Der Ablauf sah es erst am Ende vor.
Was wir gemacht haben
Prozess
Wir haben die Sprints so angepasst, dass immer mindestens eine fachliche Story umgesetzt wurde. Dadurch konnte zum ersten Mal geprüft werden, ob die Anforderungen des Fachbereichs richtig verstanden waren. Mit dem Blick auf den Nutzen für die Anwender sind wir iterativ vorgegangen und konnten so schon vor Projektende Wert liefern.
IT
Wo Abhängigkeiten die Entwicklung sonst blockiert hätten, haben wir mit Dummy-Daten gearbeitet. Entwickelt wurde fast vollständig im Mob-Programming. Das hat verhindert, dass sich Wissensinseln bilden, und den Overhead durch Merges und Code-Reviews reduziert.
Was davon bleibt
Den vollständigen Projektumfang haben wir rund 3 Monate vor dem geplanten Ende geliefert. Weil das Team von da an fachlich gearbeitet hat, war schon vor Projektende klar, dass die Fachlichkeit korrekt abgebildet ist. Und weil im Mob entwickelt wurde, lag das Wissen beim ganzen Team.
