Bei sehr komplexen Projekten oder bei einem Schritt in bisher unerforschte Technologien für ein neues Projekt kann es sinnvoll sein, vor dem eigentlichen Projektbeginn einen oder mehrere Explorationssprints einzufügen, die dazu dienen, notwendiges Wissen zu erwerben und ggf. Architekturentscheidungen zu treffen. Solche Dinge sind jedoch kaum planbar, was uns vor ein größeres Problem stellt.
Vor dem eigentlichen Projektbeginn (in aller Regel während der Erstellung des Releaseplans) sollte man sich mit den Entwicklern zusammensetzen und über die technische Umsetzung sprechen. Auch wenn der Product Owner selbst über keinen Entwicklerhintergrund verfügt, empfehle ich ihm die Teilnahme an diesen Treffen, um zumindest einen ganz groben Überblick zu bekommen.
Selbstverständlich ist es nicht notwendig für einen PO, selbst über Entwicklerwissen zu verfügen, schließlich hat er sich aus diesen Fragen auch herauszuhalten, ich empfehle dennoch jedem Product Owner, sich ein paar Grundkenntnisse anzueignen. Es ist sehr hilfreich, wenn man seine Entwicklerkollegen versteht – das jedoch nur als kleinen Einwurf.
Zurück zum eigentlichen Thema: Im Verlauf dieser technischen Vorbesprechung werden die größeren Schwierigkeiten und Probleme offenkundig, mit denen sich das Entwicklerteam beschäftigen muss. Es kann sich dabei um neue Technologien handeln, mit denen bislang noch niemand aus Ihrem Team Erfahrungen gesammelt hat. Es kann sich um Architekturfragen handeln, die eine genauere Betrachtung erfordern. Es kann um Schnittstellen zu Drittanbietern gehen, die noch getestet werden müssen.
Wenn Sie feststellen, dass noch so viele Dinge ungeklärt sind, dass das Team noch nicht sofort in die eigentlich Entwicklung einsteigen kann, empfehle ich Ihnen, einen Explorationssprint anzusetzen. Überführen Sie die Inhalte ins Backlog, auch wenn es sich dabei nicht um Produktfeatures handelt. Sie sollten später jedoch dokumentieren können, was das Team in dieser Zeit überhaupt gemacht hat (irgendwann wird Sie irgendjemand fragen), und das Backlog ist nun einmal unser zentrales Repository.
Auch wenn sich das Team auf eine Sprintlänge von z.B. zwei Wochen geeinigt hat, empfehle ich Ihnen, keine feste Dauer für den Explorationssprint anzusetzen. Diese Dinge sind kaum planbar, daher halte ich es auch für nicht sinnvoll, sie in einen festen Zeitrahmen pressen zu wollen. Ein erfahrener Entwickler, Projektmanager, Architekt wird erkennen, wenn das Team der Verlockung erliegt, ohne Deadline zu arbeiten, und nur noch Tetris spielt.
Den ersten produktiven Sprint können Sie ansetzen, wenn die meisten Fragen geklärt sind. Hierbei ist es durchaus möglich, einen Teil des Teams weiter forschen zu lassen, während die anderen bereits am Projekt arbeiten. Achten Sei jedoch darauf, dass erworbenes Wissen allen zur Verfügung gestellt wird. Dies erreichen Sie durch gemeinsame Schulungen, in denen ein Kollege den anderen neue Technologien vorstellt.
Ich gehe in den Explorationssprints am liebsten folgendermaßen vor: Zu Beginn werden alle aktuell zu betrachtenden Probleme auf die große Tafel im Entwicklerbereich geschrieben (falls Sie keine große Tafel im Entwicklerbereich haben, besorgen Sie eine – die kann man immer brauchen). Zu Beginn des Projekts betrachten wir jedoch ausschließlich die Dinge, die zu diesem Zeitpunkt auch wichtig sind. Probleme, die Features betreffen, deren Umsetzung noch in weiter Ferne liegt, ignorieren wir vorerst. Ungenutztes Wissen geht verloren, und es ist auch durchaus möglich, dass sich die Dinge noch ändern.
Die Reihenfolge, in der wir uns die Dinge ansehen, ergibt sich zum Teil aus Abhängigkeiten in der Entwicklung, so kann eine Architekturentscheidung den Weg in die eine oder in die andere Technologie weisen. Der Kanban-Tradition folgend versuchen wir auch, nicht zu viele Baustellen gleichzeitig aufzumachen, selbstverständlich können wir aber nicht immer das gesamte Team an die Betrachtung einer einzigen Schwierigkeit setzen. Hier ist die Erfahrung Ihrer Kollegen gefragt, ob man sich eine Sache allein, zu zweit oder in der gesamten Gruppe ansehen muss.
Wichtig (und ich kann das nicht genug betonen) ist, dass wir nichts glauben, was wir nur irgendwo lesen. Alles wird mit ausführbarem Code getestet. Wie oft hat man schon erlebt, dass sich ein Blogeintrag als nicht richtig herausgestellt hat?
Schon eigenartig, dass ich das als Blogger schreibe …
Zurück zum Thema: Das Ergebnis wird eine Reihe von Wegwerfprototypen sein. Niemand produziert gern für die Tonne, das ist vollkommen klar, doch dafür verfügen wir über gesicherte Erkenntnisse und nicht nur über die Hoffnung, dass irgendjemand das auch getestet hat, was er geschrieben hat.
Die meisten dieser Prototypen werden nur aus wenigen Zeilen Code bestehen. Es kann jedoch vorkommen, dass komplexere Testfälle erarbeitet werden müssen. Ich verstehe, wenn Ihnen das Herz dabei blutet, diese Dinge wegzuwerfen. Entwicklerzeit ist teuer. Der Entwicklungsleiter oder Architekt kann durchaus auch entscheiden, dass man einen Prototypen weiter verwendet und in den eigentlichen Projektcode übernimmt. Es ist nicht in Stein gemeißelt, dass man alles wegwerfen muss.
Alle geklärten Fragen werden auf der Tafel abgehakt, damit man den Fortschritt jederzeit sehen kann. Besonders wichtig ist während dieser Phase das Daily Scrum. Hier kann man sich schnell darauf verständigen, sich ggf. am Nachmittag für eine kurze Schulung unter Kollegen zu treffen, um das erworbene Wissen zu teilen.
