Von Sprints und Brouhahas

In meinem Job als Softwareentwickler arbeiten wir nach dem “Scrum” Modell der agilen Softwareentwicklung.
Das ist ein Vorgehensmodell bei dem die Arbeit in zeitlich vorgegebene “Sprints” unterteilt (z.B. 4 Wochen) wird an deren Ende jeweils wieder ein funktionsfähiges Stück Software stehen muss.

Das steht im Gegensatz zum klassischen Ansatz bei dem ein fester Projektumfang definiert wird der erreicht werden soll und bei der einer langen und detaillierten Planungsphase eine sehr lange Umsetzungsphase folgt an deren Ende das fertige Produkt steht.
Sprints sorgen hingegen dazu dass man “agiler” ist, d.h. schneller auf sich Verändernde Anforderungen oder aber auch Rahmenbedingungen, wie z.B. die verfügbaren Ressourcen, reagieren kann und am Ende eines Sprints trotzdem ein “Produkt” hat das zwar möglicherweise weniger Funktionen hat aber eine fertige Komponente darstellt.

Als ich mir heute die Liste der offenen ToDos ansah von denen einige bis zum Pornichet Select 6.50 (dem ersten Rennen für mich dieses Jahr am 13.4.) erledigt sein müssen, andere aber noch bis zum Start des Azorenrennens im Juli Zeit haben da fielen mir die Parallelen zu meinem Job auf.
Das “Produkt” in diesem Sinn ist die Kombination aus einem rennfertig vorbereitetem Boot und einem ebenso vorbereiteten Skipper.
Also habe ich beschlossen meine weitere Vorbereitung von nun an in Sprints zu organisieren an deren Ende sowohl ich als auch das Boot theoretisch sofort zu einem Rennen ablegen könnten.
Und das ist gar nicht so einfach wenn man sich ansieht welche Themen die ToDo Liste momentan enthält. Die beginnt beim Rigg (Mast trimmen, Fallen spleissen) über Elektrik (Sicherungskasten überarbeiten, Brennstoffzelle einbauen), Elektronik (Data Logger neu verkabeln, neuen Wecker an Kollisionsalarm des AIS anschließen) über persönliche Vorbereitung (Fitness, Wetter-Wissen).

Auch diese Thematik ist mir als Softwareentwickler wohl bekannt. Bei der (Weiter-)Entwicklung eines Produkts gibt es häufig verschiedene Aspekte die gleichzeitig vorangetrieben werden müssen, z.B. Entwicklung neuer Features, Bugfixing, Performanceoptimierung, Schnittstellendefinition, Dokumentation, etc.
Da die Effektivität massiv sinkt wenn man sich andauernd einem neuen Thema zuwenden muss legen wir in der Softwareentwicklung daher regelmäßig sogenannte “Brouhaha”s ein.
Ein Brouhaha ist ein Zeitraum von 2-5 Tagen an denen man sich ausschließlich einer bestimmten Thematik, z.B. Performanceoptimierung, widmet. Es ist erstaunlich welche Fortschritte sich bei einem so fokussierten Arbeiten binnen weniger Tage erzielen lassen.

Dieses Vorgehen werde ich ebenso auf meine Rennvorbereitung adaptieren und in meine Sprints je nach Bedarf Brouhahas einlegen um einen besonderen Teilbereich der Vorbereitung fokussiert abschließen zu können.

Also, Sprints und Brouhahas werden hier die nächsten Wochen und Monate dominieren, es sind nur noch 4 1/2 Monate bis zum Start des Azorenrennens und bis dahin wollen knapp 2000sm erfolgreich gesegelt worden sein.

This post is also available in: Englisch


brouhaha, preparation