Story Splitting (4/4): Agil ohne Story Splitting bringt zahlreiche Nachteile

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

In einem zurückliegenden Beitrag habe ich über zu frühes Story Splitting geschrieben. Heute geht es um zu spätes Splitting, was für mich bedeutet: kein Splitting.

Was folgt daraus? Ganz einfach: Man gibt dem Team eine “große” Story, und es geht damit in die Planung. Daraus ergeben sich alle Nachteile zu großer Arbeitspakete. Etwa: Es dauert sehr lange, bis etwas fertig wird. Man bekommt erst verspätet Feedback für die Arbeit, sehr spät Return on Investment, man erkennt spät, wenn man in die falsche Richtung arbeitet und so weiter.

Im vergangenen Jahr konnte ich bei einem Team Tickets beobachten, die schon im siebten Sprint lagen, und ein Ende war nicht absehbar. Darauf angesprochen bekam ich die Antwort, dass sich das Team darauf geeinigt hat, dass Tickets von einem Sprint zum nächsten mitgenommen werden können. Dagegen habe ich nichts einzuwenden, getreu dem Motto "jeder ist seines Glückes Schmied". Allerdings war niemand begeistert von den vielen Meetings, die im Kalender standen.

Dazu gehörte in meinen Augen der ganze Scrum-Firlefanz. Das wird nämlich aus den Scrum-Events, wenn man so arbeitet. Für Tickets, die mehr als vierzehn Wochen in Sprints liegen, brauche ich offensichtlich keine Sprintplanung. Im Daily Scrum 14+ Wochen lang zu sagen, dass an dem Ticket gearbeitet wird, hat mit der Intention des Meetings nichts mehr zu tun. Und im Review immer wieder zu sagen, dass es Fortschritte gibt, aber kein Ergebnis erzielt wurde, ist überflüssig. Von Sprintzielen und Produktzielen muss ich gar nicht erst reden.

Wer so arbeiten möchte, sollte wenigstens sich selbst gegenüber ehrlich sein und den Kalender von Ballast befreien. Es sei denn, man braucht die dysfunktionalen Meetings, um in der Stellenausschreibung “New Work” und “agil” platzieren zu können. Der Preis dafür ist allerdings sehr hoch.

Mein Rat ist im Allgemeinen ein anderer: Egal, was Ihr macht, macht es gut! Also entweder Verzicht auf unnütze Meetings oder – mein Favorit – vernünftiges Splitting, damit es möglich wird, in kleinen Abständen Erfolge zu erzielen.

Fazit

Am Ende einer kleinen Serie zum Thema Story Splitting lautet mein Fazit: Es führt kein Weg daran vorbei, dass das Entwicklungsteam lernt, User Stories zu splitten. Dazu dürfte es im Netz zahlreiche gute Quellen geben, und vielleicht ist das auch eine Reihe von Artikeln in diesem Blog wert. Das Team sollte seine Beteiligung gegebenenfalls einfordern. Wenn man jedoch darauf verzichtet, ist die Gefahr hoch, dass die Arbeit zu einer Feature Factory wird.

Die Kurzserie zu Story Splitting besteht aus vier Teilen:

1. Es ist eine Kunst, und wir brauchen Entwickler dafür
2. Zerlegung in Komponenten?
3. Nicht ohne meine Developer
4. Wasserfall ohne Plan

(rme)