Agil: Wann was bewerten?

Vor kurzem habe ich zusammen mit meinem Kollegen Henning Wolf einen Workshop bei der Nordakademie zum Thema Lean Management und Scrum mitgestaltet. Für uns war es eine besondere Erfahrung, weil unter den Teilnehmern so gut wie niemand war, der Software entwickelt. Ca. die Hälfte der Teilnehmer beauftragt die Entwicklung oder Einführung von Software, die andere Hälfte entwickelt physikalische Dinge wie Züge, Tablettenpressmaschinen oder Gabelstapler - individuell oder in Serie.
In diesem Sinne hatten wir interessante Diskussionen, die sich vor allem um die Frage drehte, wie man mit den Scrum-Sprints umgehen soll: Bei der Entwicklung eines Zuges hat man erst sehr spät den Zug und kann den nicht bereits am Anfang dem Kunden zeigen. Außerdem stand die Frage im Raum, wie man vom klassischen Vorgehen schrittweise in Richtung Scrum kommt. Dabei hat sich herauskristallisiert, dass es drei zusammenhängende Aspekte gibt, die man gemeinsam in Richtung Scrum entwickeln muss:

1. Was wird präsentiert?


2. Wem wird es präsentiert?


3. Wann wird es präsentiert?

Klassisch hat man einen Projektplan mit Meilensteinen. Bezogen auf die o.g. Fragen gilt für das klassische Projektvorgehen:

1. Was wird präsentiert? Immer unterschiedlich, je nach Meilenstein. Mal eine Konzeption, mal ein physikalisches Teil.


2. Wem wird es präsentiert? Manchmal dem Kunden. Häufig gibt es aber gar keinen richtigen Kunden für das, was das präsentiert wird. Es sind nur interne Dokumente.


3. Wann wird es präsentiert? In unregelmäßigen Abständen, jeweils wenn ein Artefakt fertig ist. Wenn es zum geplanten Zeitpunkt nicht fertig ist, wird der Termin häufig verschoben.

Scrum hingegen fordert:

1. Was wird präsentiert? Das, was der Kunde später auch bekommt, wofür er bezahlt.


2. Wem wird es präsentiert? Dem Kunden. Wenn es ein Serienprodukt für viele (vielleicht anonyme) Kunden ist, übernimmt ein Kundenvertreter (Produktverantwortlicher) die Kundenrolle.


3. Wann wird präsentiert? In der Regel alle 2 bis 4 Wochen, aber auf jeden Fall in regelmäßigen Abständen (Timeboxing).

Wie kommt man jetzt von Meilensteinen zu Scrum? Der erste Schritt ist einfach: Man macht Punkt drei genauso wie Scrum es fordert: Man definiert einen festen Rythmus, in dem man den Projektfortschritt bewertet und ggf. die Pläne anpasst. Seine Meilensteine kann man erstmal parallel dazu bestehen lassen. Es ist jedoch das Ziel, die Meilensteine komplett zu ersetzen.
Und jetzt muss man sich für die Punkte eins und zwei schrittweise an Scrum annähern. Derjenige, dem präsentiert wird, muss dem Kunden immer ähnlicher werden und das, was präsentiert wird, muss dem immer ähnlicher werden, wofür der Kunde bezahlt.
Das wird im ersten Schritt häufig bedeuten, dass man intern einen Kundenvertreter benennt, der den Kunden vertritt - selbst dann, wenn es einen echten Kunden gibt. Wenn sich mit dem Kundenvertreter das Vorgehen intern eingespielt hat, lädt man den Kunden zu den Präsentationen mit ein. Und schließlich kommt der interne Kundenvertreter nicht mehr. im gleichen Zuge wie der interne Kundenvertreter durch den echten Kunden ersetzt wird, muss sich das Artefakt ändern, das präsentiert wird. Schließlich muss der Kunde auch bewerten können, was er präsentiert bekommt. Und hier ist es natürlich auch bei der Entwicklung physikalischer Dinge so, dass man sie in Einzelkomponenten zerlegen kann. Und diese Einzelkomponenten werden weitgehend unabhängig voneinander entwickelt und getestet. Einige Einzelkomponenten können also auch bereits lange vor Ende des Projektes präsentiert werden. Und dort wo es nicht geht, muss man Dinge finden, die der Kunde versteht: Prototypen, Konzepte und Präsentationen in der Sprache des Kunden etc.

Fazit 1: So anders ist die Entwicklung physikalischer Dinge auch wieder nicht.
Fazit 2: Das skizzierte Vorgehen funktioniert genauso gut für Softwareprojekte, die den Sprung ins kalte Scrum-Wasser scheuen und sich lieber schrittweise vorarbeiten wollen.

Post bewerten