Weiter im Text: Für den zweiten Teil unserer Scrum-Reportage werfen wir einen Blick in die Daily Stand-ups, in Refinements und auf die Entscheidungsfindung, was wir für den Besuch des Oberbürgermeisters nun planen. Teil 1 gibts hier.

Montag, 13. März, Refinement. Dabei handelt es sich um eine viermal pro Sprint angesetzte Möglichkeit, Tasks zu ergänzen sowie neue User Stories anzulegen. Jira erscheint auf den Teams-Bildschirmen. Hinter Max Karl ein Poster, darauf ein Affe mit Kopfhörern, hinter Michael ein digitaler smart-and-public-Hintergrund in knalligem Türkis, sonst nur zu erahnende Heimbüros hinter einem Blur-Filter.

Wir befinden uns – wie in allen ungeraden Kalenderwochen – allesamt im Homeoffice. Bei smart and public arbeitet die gesamte Belegschaft wechselwöchig im Büro respektive von zu Hause aus. Bastian erklärt aus der digitalen Kachellandschaft heraus, man benötige möglicherweise einen „Enabler“ für die „Account-Management-Seite“. Es wird genickt. Keiner quatscht dazwischen. Einigkeit. Was er genau damit meint? Für unbedarfte Ohren bleibt die Fachdiskussion kryptisch. Wie gut, dass für gewöhnlich nur Profis an derlei Sessions teilnehmen.

Sichergestellt wird dies bereits im Recruiting-Prozess. Sua und Marcus prüfen darin selbstredend die fachliche Eignung und Kompetenz für die ausgeschriebene Stelle. „Uns ist jedoch genauso wichtig, dass die Kandidat:innen ins Team passen, mit der Offenheit hier klarkommen und gerade in den technischen Jobs Erfahrung im agilen Arbeiten mitbringen“, berichtet Sua.

„Agil“, das ist das Zauberwort im Scrum-Kosmos. Die Aufteilung in kleinere Arbeitsblöcke, die häufigen Absprachen und die Dokumentation erlauben eine ständige Anpassung des Prozesses und somit auch des Produkts. Niemand schmort hier in seinem eigenen Saft. Wendig und flink müssen smart-and-public-Entwickler:innen sein. „Vor allem, weil wir Scrum-Scrum machen“, führt Marcus fort. „Lehrbuchmäßig und nicht ein bisschen hiervon und ein bisschen davon.“

Alle(s) auf Augenhöhe

Genau das soll am 22. März auch der angekündigte Besuch erfahren dürfen. Statt der Teilnahme an der Review ist mittlerweile ein kleiner Workshop geplant, um den herum das Team vorgestellt und dessen Arbeitsweise – inklusive Scrum – kurz skizziert werden sollen. Der Sprint kann also ungehindert fortfahren, alle Termine bleiben wie gehabt.

Dazu gehören auch Daily Stand-ups. Das sind morgendliche Kurztreffen zum gegenseitigen Austausch über den aktuellen Fortschritt. Pull Request hier, Docker Compose da, Exploratory Testing dort: Sie werden schon wissen, von was sie reden … Häufig heißt es nach den angesetzten 15 Minuten: „Bleiben wir drin?“ Man konferiert also noch weiter und bespricht Code-Zeilen, Vorhaben und Herausforderungen.

Was beim Beobachten all dieser Aufeinandertreffen auffällt: Scrum ist hierarchielos. Dominik als Product-Owner verpackt die von ihm überbrachten Kundenbedürfnisse und Anforderungen an das Produkt niemals als Diktat oder Befehl.

Vielmehr bietet er an, gibt zur Diskussion frei. Backend-Entwickler Michael ist fast doppelt so alt wie Frontend-Entwickler Tim, Tim dafür weit länger Teil des Teams. Im Gefüge spielt all das keine Rolle.

Michael: „Wenn es um die Arbeit geht, verlassen wir die Sachebene nicht. Wer von der Materie am meisten Ahnung hat, trägt vor.“

Tim: „Gleichzeitig scheut sich aber auch niemand, Bedenken einzubringen – selbst, wenn man fachfremd ist.“

Michael: „Genau. Es geht immer um eine Homogenisierung der Ansichten. Niemand bestimmt vom Elfenbeinturm aus.“

Der Wurm ist drin

Dieses Framework verlangt auf alle Fälle viel Kommunikation von seinen als Eigenbrötler:innen verschrienen Protagonist:innen. Wird bei Scrum zu viel gelabert, Max Karl? Lenken die vielen Meetings nicht vom Eingemachten ab, dem Programmieren? „Würde ich nicht sagen“, erwidert der Backend-Entwickler, ohne lange nachdenken zu müssen. „Um zielgerichtet arbeiten zu können, muss ich wissen, was die anderen machen und welche Erfahrungen sie gesammelt haben.“ Fürs reine Programmieren, ergänzt er, bleibe aber dennoch genügend Zeit. „Alleine am meetingfreien Mittwoch in den Homeoffice-Wochen schaffe ich superviel weg.“

Wieder Wochenwechsel, zurück im Büro. Allerdings alles andere als vollzählig. Michael ist die ganze Woche krank und Karina fehlte bereits in der Vorwoche. Sie ist erst wieder am Mittwoch fit – rechtzeitig also zum Empfang des hohen Besuchs. Denkste, es ist wie verhext: Auch Sua lässt sich im Laufe der Woche entschuldigen. Ohne die Geschäftsführerin ergibt ein Termin mit OB und Aufsichtsratsmitgliedern keinen Sinn. Der Workshop wird verschoben.

Eine logische Folge dessen: Im Daily am Dienstag, 24 Stunden vor der Review, fällt der gemeinsame Blick auf das sogenannte Burn-Down-Diagramm, das Jira per Mausklick ausspuckt. Stirnrunzeln, verschämtes Lächeln, sogar Galgenhumor. Der flache Graph ganz oben besagt, dass noch keine User Story auf „Done“ geschoben werden konnte. Zum gewissenhaften Testing und damit zum endgültigen Abschluss komme man derart personell geschröpft nicht, heißt es zur Erklärung. „Es funktioniert aber alles so weit“, beschwichtigt Bastian. „Bei der Review morgen wird es was zu sehen geben.“

Hatten wir zwei Teile angekündigt? Mag sein. Doch es wurden drei. Hier gehts zum finalen Part.