Story Splitting (1/4): Es ist eine Kunst, und wir brauchen Entwickler dafür

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.

Liebe Entwicklerinnen und Entwickler. Ich frage mich, ob Ihr in Eurem Job ins Story Splitting eingebunden seid? In welchen regelmäßigen Abständen findet es statt? Inwiefern ist es für Euch von Bedeutung? In welcher Weise unterstützt es Euch (oder auch nicht)? Was schätzt ihr daran?

Ich stelle (mir) diese Fragen, weil ich über das Thema ein paar Beiträge schreiben möchte. In diesem Beitrag lege ich meine Motivation dar und deute die Komplexität des Themas an. Drei weitere Beiträge folgen.

Story Splitting ist eine Kunst. Wie komme ich zu dieser Aussage? Ich denke, dass erfolgreiches Story Splitting eine Reihe von Zutaten benötigt, die selten alle vorliegen. Hier meine Liste:

1. Die Entwicklerteams müssen beteiligt sein.
2. Man braucht eine ordentliche User Story. Kein x-beliebiges Jira-Ticket, dem man willkürlich den Tickettyp “Story” verpasst hat. Was eine “ordentliche” User Story ausmacht, kann Bände füllen. Wenn Ihr in Eurem Team darüber sprechen möchtet, sind die INVEST-Kriterien ein guter Impuls für einen Dialog. Soll heißen: Ich würde die INVEST-Kriterien nicht als normativ ansehen; aber sie sind schon ziemlich gut.
3. Es ist handwerkliche Professionalität erforderlich. Damit meine ich, dass man Story Splitting üben kann.
4. Kreativität ist hilfreich, um gute Ergebnisse zu liefern. Damit man als Entwickler/in bei dieser Aufgabe kreativ sein kann, muss man das Business oder zumindest das Anliegen der ursprünglichen Story aus Business-Sicht verstehen. Hier ist der PO gefordert, klarzumachen welchen Wert eine zu splittende User Story fürs Unternehmen besitzt.
5. Der richtige Zeitpunkt innerhalb des Arbeitsablaufs ist wichtig, weil der Zeitpunkt bestimmt, welche Personen beteiligt sind.

Im Gespräch mit meinen Kolleginnen und Kollegen ist mir ein Punkt aufgefallen, den ich zunächst nicht bedacht hatte: Wenn die Entwicklung in Komponententeams stattfindet, ist die Wahrscheinlichkeit hoch, dass die Teams keine User Story zu Gesicht bekommen. Im Allgemeinen wird kein User eine Teilimplementierung brauchen. Der Wert entsteht erst durch die Integration der Teile.

Viele Themen also. Zu viele für einen Blogartikel und über manche gibt es schon gute Beiträge. Deshalb werde ich mich auf zwei Aspekte beschränken: Was kommt beim Splitting heraus? Und. Wer splittet wann eine User Story? (Um Was, wer, wann geht es in den folgenden Beiträgen.)

Bevor es im nächsten Beitrag mit dem Thema weitergeht, noch ein Disclaimer: Wenn ich Begriffe wie User Story und Story Splitting höre oder verwende, gehe ich automatisch von einer agilen oder möchte-gern-agilen Arbeitsweise aus. Das ist heutzutage nicht mehr selbstverständlich, weil viele Begriffe längst außerhalb ihres ursprünglichen Kontextes und fernab ihrer ursprünglichen Bedeutung verwendet werden. Das sorgt einerseits dafür, dass hervorragende Konzepte nicht (mehr) funktionieren und andererseits, dass die Kommunikation über Ursachen und Lösungen nicht gelingt. Damit das hier nicht passiert, weise ich ausdrücklich auf den (mehr oder weniger) agilen Kontext hin.

(rme)