Story Splitting (3/4): Nicht ohne meine Developer

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 der lockeren Folge über User Story Splitting widme ich mich der folgenden Frage:

Wer ist am Splitting beteiligt und wann findet es statt?

Ich habe im Wesentlichen zwei Anti-Patterns beobachten können, die man meiner Meinung nach abstellen sollte:

• zu frühes Splitting durch Business-Analysten, Product Owner, Product Manager oder einen vergleichbaren Titel;
• zu spätes Splitting, nämlich niemals.

Im heutigen Beitrag geht es um den ersten Punkt; ein weiterer Artikel wird den zweiten Aspekt behandeln.

Was bedeutet zu früh und was ist das Problem dabei? Zu früh bedeutet, dass die Entwickler nicht beteiligt sind. Selbst wenn das Ergebnis des Splitting “gut” ist, ist es nicht gut, die Entwickler auszuschließen.

Es besteht sonst die Gefahr, vermeidbare technische Schulden zu erzeugen; nämlich dann, wenn der Scope der kleineren User Story, die aus dem Splitting entsteht, so klein ist, dass der größere (und für manche Personen bekannte) Kontext in der kleinen Story nicht mehr gesehen wird. Den daraus entstehenden Schaden (technische Schulden im ursprünglichen Sinne) kann man nach dem Splitting noch dadurch vermeiden, dass man die resultierenden Stories zusammenhängend bespricht (z.B. im Refinement) und bei der Implementierungs-/Sprint-Planung die Zusammenhänge beachtet. Das können aber oft nicht die Entwickler und Entwicklerinnen initiieren, weil sie dazu wissen müssten, dass es zu einer gerade betrachteten Story noch einen größeren Kontext gibt. Doch der wurde durch das Splitting womöglich gerade ausgeblendet. Ohne Kontext werden die Entwicklerinnen und Entwickler zu reinen Erfüllungsgehilfen in einer Feature Factory. Statt ihnen den Kontext nachträglich zu erklären, halte ich es für viel sinnvoller, sie in das Splitting einzubeziehen, um das technische Know-how am Tisch zu haben.

Ein Sonderfall ist die Arbeit in Komponententeams. Hier ist die Wahrscheinlichkeit hoch, dass die Entwicklerteams die ursprüngliche User Story gar nicht sehen. Man kann dem entgegenwirken, indem man alle Komponententeams auf geeignete Weise in das Aufteilen einbezieht. Ich habe gute Erfahrungen mit einem an LeSS (Large-Scale Scrum) angelehnten Refinement-Ablauf gemacht.

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)