Benutzerhandbücher schreiben, den manuellen Testplan einmal ausführen, den Legacy Code mit Tests versehen oder endlich mal gemeinsam Code-Teile refactorn. Dies sind Aufgaben, die die Entwickler gerne an die QA, technischen Redakteure oder studentische Hilfskräfte weitergeben. Fakt ist aber meistens, dass Entwickler diese Aufgaben viel besser erledigen können, als andere Kollegen. Wir erledigen solche Aufgaben in Mini-Sprints.
Was sind Mini-Sprints?
Mini-Sprints sind ein bis zwei Tage, in denen das Team sich einer Aufgabe widmet, die sonst gerne aufgeschoben wird. Das Team trifft sich also einen Tag und arbeitet gemeinsam an einer größeren Aufgabe. Mini-Sprints werden entweder von dem Team selbst organisiert oder von an einer anderen Abteilung, die Unterstützung und die Expertise der Entwickler benötigen. Wenn also das Team gerne mal einen Tag damit verbringen möchte, den Code an einer bestimmten Stelle mit Unit Tests zu versehen, bereiten ein, zwei Entwickler diesen Mini-Sprint vor. Diese Entwickler stellen am Morgen den Mini-Sprint vor, erklären was aus Ihrer Sicht zu tun ist und das Team plant gemeinsam den Tag.
Tipps:
- Ungestörtes Arbeiten: Es dürfen also keine Teammitglieder an Meetings teilnehmen oder alltägliche Supportanfragen annehmen.
- DenTag besonders machen: Gemeinsam mittags Pizza essen, eventuell nicht im Büro arbeiten, sondern zusammen in ein Meetingraum coden und/oder den Abend mit einem Bier ausklingen lassen. So ein Mini-Sprint soll etwas besonderes sein.
Bei Atlassian machen wir auch Mini-Sprints, die von anderen Teams für die Entwicklung organisiert werden:
Benutzerdokumentation auffrischen
Unsere technischen Redakteure sind verantwortlich für die Auslieferung der Dokumentation. Die Dokumentation soll einheitlich aussehen und formuliert sein. Wenn es aber um Dokumentation zur Benutzung unserer Schnittstellen geht, kennen sich die Entwickler natürlich inhaltlich viel besser aus. Es wird also ein Mini-Sprint zum Erstellen eines User Guides der API organisiert. Die technische Redaktion organisiert alles um diesen Tag herum. Die Entwickler kerstellen die Doku, die technischen Redakteure überarbeiten diese später und wir haben eine korrekte Beschreibung, wie man unsere Schnittstellen benutzt.
Gemeinsam Testen
Es gibt wenig Entwickler, die manuelles Testen der gesamten App mögen. Dafür haben wir ja zum Glück die QA… Aber wir wissen ja eigentlich, dass die QA nicht für die Qualität unserer Software verantwortlich ist. Softwareentwickler kennen Funktionalität viel besser und haben ein ziemlich gutes Gefühl, wo etwas schief gehen könnte in der Software. Bei Atlassian gibt es wenige QA Mitarbeiter. Bei uns gibt es sogenannte DOTs (Developer on Tests). Die Entwickler sind also mit fürs Testen verantwortlich. Um jetzt aber vor einem Release die gesamte Software einmal manuell durchzutesten, führen wir sogenannte Blitz Tests durch. Das gesamte Team oder sogar Mitarbeiter aus anderen Teilen des Unternehmens nehmen an diesem Mini-Sprint teil. Auch hier übernimmt unsere QA die Organisation und die Nachbereitung dieses Mini-Sprints.
Aber… das muss doch in die Sprintplanung
Es gibt immer Aufgaben, die aufgeschoben werden, wie den Code aufräumen, auf eine neue Java Version wechseln oder Performance Tests schreiben. Die diese Aufgaben nicht gut in die Sprintplanung passen, kann man regelmäßig Mini-Sprints durchführen. Ich weiß, viele meinen das dies zur Iteration dazugehören sollte. Ich habe aber viel zu oft gesehen, dass solche Aufgaben gerne verschoben werden, auch wenn Sie wichtig sind. Warum also nicht alle 2-3 Wochen solche Aufgaben in einem Mini-Sprint erledigen?
Tripple Win
Win 1: Eine unliebsame Aufgabe wurde erledigt. Geteiltes Leid ist halbes Leid. Es kommt aber auch ziemlich oft vor, dass diese Aufgabe gar nicht so nervig ist, wenn man erst mal mit ihr beginnt. Manchmal sehen Dinge einfach aus näherer Distanz nicht mehr so Schlimm aus.
Win2: Man hat am Ende das Gefühl, etwas gemeinsam geschafft zu haben. Auch kommt man aus der täglichen Sprint-Routine mal raus, macht was besonderes, die Arbeit wird nicht eintönig und ein Mini-Sprint erweitert den Horizont.
Win3: Wir entlasten andere Abteilungen. Ich fand es schon immer unfair, wenn die technische Dokumentationsabteilung als Flaschenhals für ein Release angesehen wurde, man diese aber kaum unterstützt hat. Man bekommt eine gemeinsame Verantwortung für das gesamte Produkt… Ja die Dokumetation ist wirklich ein Teil des Produkts.
Sven Peters 
Finde ich gut. Wir haben von einer anderen Firma folgendes abgeschaut: Jeden zweiten Freitag machen wir einen “casual friday”. An diesem Tag können die Entwickler machen “was sie wollen”, vorausgesetzt, es zahlt auf das Produkt ein. Die einen räumen an dem Tag auf, die anderen probieren was aus. Wir haben so einen Tag auch schon für einen “konzertierten” Testtag eingesetzt. Positiv ist vor allem, dass man mal Luft holen kann bei der ganzen Sprinterei.
Nicht verheimlich möchte ich, dass wir derzeit den Freitag ausgesetzt haben, da ein wichtiger Termin vor der Tür steht. Aber wir werden das wieder reanimieren.
Eine andere Herausforderung ist der Umstand, dass wir dabei sind die Timeboxes zwischen den drei Teams zu de-synchronisieren, bzw. abzuschaffen. Wie wir dann diesen Tag wieder synchroniseren, wissen wir auch noch nicht so recht…. Evtl. einfach eine Karte “Aufräumen” anhängen 🙂
Danke für deinen Erfahrungsbericht. Du hast geschrieben, dass ihr dabei seid, eure Teams asynchron laufen zu lassen. Was spricht denn dagegen trotzdem einmal im Monat (oder so) die 3 Teams an einem Tag “konzentriert” testen zu lassen? Oder bezog sich das nur auf euren “casual Friday”?