Entwicklungsteams enablen: Drei Wege aus der Anforderungsmisere

Wer schon einmal in einem Team Software entwickelt hat, erkennt sicher einige der folgenden Probleme wieder:

Als Ergebnis fühlen sich Entwickler:innen häufig nicht „mündig“ oder befähigt: Ihnen fehlt das Hintergrundwissen über Ziele und den Kontext der Anforderungen, weshalb sie nicht im Stande sind, eigenständig gute Entscheidungen zu treffen – schlicht weil ihnen Faktoren zur Bewertung dieser Entscheidungen fehlen oder ihnen die Priorität dieser Faktoren unklar ist. Product Owner werden durch die zusätzlich entstehende Belastung durch viele Nachfragen und erneute Diskussionen noch mehr zum Bottleneck, als sie das meist eh schon sind. Vorgegebene Lösungswünsche schränken Entwickler:innen in ihrer Flexibilität ein, Kompromisse auszuarbeiten und abzuwägen sowie denkbare Alternativen anzubieten. Häufige Kontextwechsel halten sie mental an der Oberfläche der Domäne, was Verständnis, Kreativität und letzten Endes auch die Einsatzbereitschaft von Entwickler:innen verringert.

Die Folgen sind mitunter verheerend: Der Fokus liegt auf der möglichst schnellen Umsetzung von vielen Anforderungen aus verschiedenen Themenbereichen (E-Mail-Funktionalität hier, mehr Auswahl im Dropdown dort, …), nicht zwangsläufig im Lösen der zugrundeliegenden Probleme (Bereitstellung gewisser Informationen mit dieser oder jener Verarbeitungsmöglichkeit hier, genauere Spezifikation von Daten zur optimaleren Bestimmung eines Preises dort, …) oder der effektiven Verfolgung von Business-Zielen (Integration eines Geschäftspartners für weiteres Upselling-Potential hier, Steigerung eines Verkaufsarguments für die eigene Software inkl. Erhöhung der Marge dort, …). Das gesamte Team beraubt sich außerdem der Möglichkeit, optimale Lösungen zu finden, aus Fehlern und Feedback zu lernen und neue Wege einzuschlagen. Zu guter Letzt wirkt sich der mangelnde Gestaltungsspielraum negativ auf die Motivation von Entwickler:innen aus, der Frust steigt und Effektivität und Effizienz sinken.

Im Folgenden betrachten wir die oben genannten Probleme etwas genauer und diskutieren mögliche Lösungsoptionen.

Aus der Misere…

Problem #1: Unklare Zielsetzungen und fehlender Kontext

Im Austausch zwischen Product Owner und Entwicklung sprechen diese meist nur über einzelne User Stories (oder welches Anforderungsformat auch immer ihr bei euch einsetzt). Dadurch fehlt häufig der fachliche Kontext, es wird nicht klar, was das zu lösende Problem genau auszeichnet und wo die konkreten Schmerzpunkte der Zielgruppe liegen. Insbesondere werden auch qualitative Ziele, Rahmenbedingungen und - nicht zu unterschätzen - die Business-Ziele, wie Upselling-Potential, Steigerung der Marge, Festigung der Marktposition oder strategische Kooperationen mit Partnern, selten thematisiert. Dadurch fehlen Anforderungen, die dann entweder nicht erfüllt werden oder es kommt zu Konflikten in der Lösungsfindung, weil betroffene Qualitätsmerkmale etwa nicht priorisiert wurden und das Team nun keine Entscheidung für oder wider einer Lösungsoption treffen kann.

Ein Effekt, den man hier häufig beobachten kann, ist die frühe Fokussierung in der Diskussion auf konkrete Akzeptanzkriterien, ohne zuvor etwa typische Situationen oder Herausforderungen, vor denen Anwender:innen stehen, beleuchtet zu haben. Dabei wird gerne auch viel Kritik zu einzelnen Akzeptanzkriterien laut; manche Stories werden von Entwickler:innen regelrecht „zerlegt“.
Findet ihr euch schon sehr früh in der Diskussion einer Anforderung in einer solchen Situation wieder, ist das häufig kein gutes Zeichen, auch wenn die Kritik an unvollständigen, inkonsistenten oder unverständlichen Akzeptanzkriterien durchaus berechtigt sein mag.
Steigt das Team zu diesem Zeitpunkt intensiv in den konkreten Diskurs ein, so fehlt meist das Verständnis für die Intention hinter den vorliegenden Akzeptanzkriterien. Die Optimierung der Kriterien führt zwar möglicherweise zu einer technisch umsetzbaren Story, ob das eigentliche Ziel noch erreicht wird, wird aber meist nicht diskutiert. Durch den fehlenden Kontext und das fehlende Verständnis für die verfolgten Ziele (sowohl aus Anwender:innen- als auch aus Business-Sicht) ist dies auch oft gar nicht möglich.

Geht man dann in die Umsetzung über, ist im Zweifel die Hemmung bei Entwickler:innen groß, Unklarheiten zu thematisieren und in einem weiteren Gespräch zu beseitigen, da die Story bereits in allen Einzelheiten vermeintlich besprochen wurde. Am Ende wird das entwickelt, was sich in einem einzigen Gespräch als Ergebnis herausgestellt hat – nicht zwangsläufig das, was tatsächlich benötigt wird.

Was tun?
In jede gute User Story gehört ein Feld „Kontext“. Hier solltet ihr das zu lösende Problem grob, gerne auch exemplarisch beschrieben: Was ist eine typische Situation, in der die neue User Story hilft? Wer hat das Problem wann? Was sind derzeit bekannte Workarounds?

Falls es besondere qualitative Anforderungen oder Rahmenbedingungen gibt, solltet ihr diese hier ebenfalls vermerken. Einige Qualitätsanforderungen lassen sich ggf. in konkreten Akzeptanzkriterien unterbringen (etwa „Das Ergebnis ist nach spätestens 5 Sekunden verfügbar“), dennoch lohnt das klare Formulieren von Qualitätszielen in diesem Abschnitt, weil ggf. günstigere Lösungsoptionen gefunden werden können, die die Zielgruppe ebenfalls zufrieden stellen.

Die Story sollte im Bereich „Kontext“ außerdem wortwörtlich in den Kontext der stattfindenden Entwicklungen gesetzt werden: Welche anderen Stories sind durch diese Story berührt, blockiert oder anderweitig abhängig? Gibt es besondere Ansprechpartner? Ist Austausch mit einem anderen Team von Nöten? Ist die Story Teil von etwas Größerem und ist es nötig, umgesetzte Teile vor Anwender:innen bis zu einem späteren Zeitpunkt zu verstecken?

Weiter könnt ihr Entscheidungen, die im Vorfeld getroffen wurden und Einfluss auf die vorliegende User Story haben, an dieser Stelle vermerken. Insbesondere ist das der Fall, wenn es augenscheinlich „naheliegendere“ Varianten der Story gegeben hätte oder wenn die Anforderung auf den ersten Blick etwas hemdsärmelig oder auch viel zu komplex erscheint. Häufig wurden hier bereits Diskussionen geführt und andere Optionen ausgeschlossen, sei es aus Kostengründen oder weil noch unklar ist, in welche Richtung sich die Gesamtfunktionalität entwickeln wird. Durch das Festhalten dieser Informationen vermeidet ihr nicht nur anstrengende Diskussionen (die bereits geführt wurden), man motiviert das Team auch, die Augen nach Verbesserungspotential offen zu halten. Gerade wenn Entscheidungen unter noch nicht evaluierten Annahmen getroffen wurden oder man nach der Umsetzung auf Feedback für die Weiterentwicklung warten möchte, können Entwickler:innen mit diesen Informationen während der Umsetzung kritisch auf die gemachten Annahmen blicken und sich auf die größere Wahrscheinlichkeit eines Änderungsbedarfs einstellen. Kommuniziert ihr also z.B. deutlich, dass eine gewisse Anforderung ein Experiment ist, stellen sich Entwickler:innen eher darauf ein, dass hier Änderungen zu erwarten sind. Gleichzeitig motiviert es sie, zum Gelingen des Experiments beizutragen und etwa für den Erfolg entscheidenden Input zu liefern.

Mit diesem Kontext kann die Entwicklung bessere Einschätzungen zu konkreten Lösungsoptionen abgeben oder bei Unklarheiten bessere Annahmen treffen und Vorschläge ausarbeiten.

Natürlich: Nicht für jede User Story ist hier ein ellenlanger Roman zu schreiben. Es gibt Stories (ich nenne sie gerne Brot-und-Butter-Stories), die eine für das Team weitere Standardanforderung nach Schema F darstellen, wie etwa die Erweiterung eines Datensatzes um weitere Felder. Doch auch hier lohnt es sich kurz innezuhalten und die konkreten Ziele zu beleuchten, die durch die Erweiterung erreicht werden sollen.

Problem #2: Unklare Priorisierung

Viele Projekte leiden unter häufigen Änderungen an der Priorisierung der fachlichen Themen. Die Gesamtzahl der Themenbereiche, an welchen in kurzer Zeit gearbeitet wird, ist sehr hoch und Kontextwechsel sind an der Tagesordnung. Je kleinteiliger die Dinge sind, deren Priorität sich ständig ändert, umso gravierender sind diese Effekte.
Abgesehen von den dadurch verursachten Diskussionen und der Verwirrung im Team, fehlt es Entwickler:innen häufig am Verständnis für die Gründe der sich ständig ändernden Prioritäten. Entsprechend schwer fällt es ihnen, im geeigneten Rahmen nach Lösungen zu suchen. Der Anspruch von Stakeholdern an die Umsetzung einer Anforderung wird immer weniger greifbar, was die eigene Prioritätensetzung in der Lösungsfindung beeinträchtigt. Wenn Stakeholder die Prioritäten ständig ändern und die Gründe dafür nur schlecht kommunizieren, fällt es Entwickler:innen sehr schwer, das tatsächlich verfügbare Budget (Zeit, Personen, Geld, Verfügbarkeit von relevanten Stakeholdern) einzuschätzen und folglich haben sie Probleme, Lösungen an diesem verfügbaren Budget auszurichten.

Schließlich sinkt die Motivation, gute Lösungen für eine konkrete Problemstellung zu finden, dramatisch ab, da die Entwickler:innen nun jederzeit damit rechnen, dass ihre Arbeit noch vor Abschluss durch eine „noch wichtigere“ Aufgabe unterbrochen oder abgelöst wird.

Was tun?
Bei jedem neuen, größeren Thema solltet ihr den Kontext (siehe oben) in einer Sammelstelle für verschiedene (fachliche wie qualitative) Anforderungen ordentlich dokumentieren, z.B. in einem Epic (oder Feature, oder wie auch immer ihr eure Anforderungen gruppiert). Auf Story-Ebene könnt ihr dann unter Verweis auf das Epic auch einige Informationen weglassen und diese damit schlanker gestalten.

Besonders nützlich ist es hierbei, im Epic den inhaltlichen Scope anzugeben und insbesondere zu vermerken, was derzeit noch nicht genauer geplant und erarbeitet werden soll. Damit haltet ihr das Epic übersichtlich und reduziert die Komplexität zu einem gewissen Grad. So hat ein Epic nicht nur eine realistische Chance, „fertig“ zu werden, es motiviert auch, tatsächlich später neue Freiräume für ein weiteres Epic zu schaffen, in welchem ihr einzelne Teile des Vorgängers erweitert oder anpasst. Das Abschließen eines Epics sollte für euch nicht bedeuten, dass ihr an diesem Themengebiet nicht weiterarbeiten könnt. Genau das Gegenteil ist der Fall: Da sich Anforderungen im Laufe der Zeit immer ändern werden, habt ihr mit kleiner geschnittenen Epics viel mehr Flexibilität, auf diese Änderungen durch neue Epics reagieren zu können.

Lasst euch durch den Begriff „Epic“ keinen epischen Umfang diktieren.

Epics, die eher Labels als tatsächliche in sich abgeschlossene Teile sind, tendieren dazu, zu großen und immer weiterwachsenden Behältern für unzählige Anforderungen zu mutieren. Am Ende fällt es schwer, solche riesigen und inhaltlich vielschichtigen Epics zu durchdringen und als Ganzes zu priorisieren. Durch das klare Begrenzen von Epics ist es deutlich leichter, neue Erkenntnisse zu identifizieren, zu erfassen und zu bewerten und iterativ und inkrementell das Feature zu verfeinern.
Im Zweifel hilft es, Epics noch einmal zu unterteilen, wobei ihr darauf achten solltet, dass die entstehenden Teile für sich genommen einen Wert liefern. Das bedeutet jedoch nicht, dass diese Teile unabhängig voneinander sein müssen.

Epics sollten entsprechend erklären, was sie wertvoll macht, sowohl für die Anwender:innen als auch für uns als Unternehmen. Ein Epic sollte einen messbaren Wert liefern, um initial priorisierbar zu sein.

Und dennoch: Änderungen der Prioritäten kommen vor. Daher arbeiten wir gerne agil; nicht alles lässt sich voraussehen und planen. Auch hier unterstützen uns sauber geschnittene und beschrieben Epics, da nun übersichtliche und zu einem gewissen Grad verstandene Blöcke umpriorisiert werden. Priorisiert ihr hingegen ständig auf einem Story-Level um, ist die Gefahr der Verwirrung und damit der Fehleranfälligkeit durch häufige Kontextwechsel deutlich größer. Es empfiehlt sich also, Epics zu schneiden, die groß genug sind, um einen echten Mehrwert zu bieten und gleichzeitig klein genug sind, um einigermaßen mühelos umpriorisierbar und abschließbar zu sein.

Zudem solltet ihr die Begründung für Änderungen der Reihenfolge kommunizieren. Einen Teil der Begründung sollte man stets aus dem Epic selbst herauslesen können. Das Epic sollte nämlich den Wert des abgedeckten Funktionsumfanges sichtbar machen und damit erklären, warum das Epic aus Business-Perspektive wertvoll ist.
Häufig spielen aber auch andere Faktoren für die Priorität eines Themas eine Rolle, etwa Risiken und technische Herausforderungen, die durch das Thema adressiert werden und die das Thema wichtiger werden lassen, als es der reine fachliche oder geschäftliche Nutzen erahnen lässt. Tatsächlich tauchen solche Punkte sogar eher auf dem Radar der Entwicklung auf und sollten von Entwickler:innen genauso in die andere Richtung kommuniziert werden. Sämtliche Faktoren, die für die Einordnung des Themas relevant sind, solltet ihr aufführen.

Das ersetzt aber nicht die mündliche Kommunikation. Gerade größere Änderungen sollten Anforderer:innen dem Team vorstellen und erläutern. Nur so hat das Team eine gute Chance, sich auf die Änderung einzustellen und eigene Prioritäten begründet zu setzen.

Problem #3: Lösungsanforderungen statt fachlicher Anforderungen

Immer wieder findet man sich als Entwickler:in mit Lösungsanforderungen und nicht mit fachlichen (oder qualitativen) Anforderungen konfrontiert. Das ist problematisch, denn es verhindert das Verständnis des zugrunde liegenden Problems durch eine unmittelbare Fokussierung auf die vorliegende Lösung. Damit fallen Alternativen nicht nur direkt aus dem Betrachtungshorizont, es fördert zudem eine Umsetzung von eventuell ungeeigneten Lösungen, da die präsentierte Lösung in sich technisch umsetzbar ist und bei Entwickler:innen die Haltung „Die werden schon wissen, wofür sie es brauchen – bauen kann ich es jedenfalls“ hervorruft.
Selbst mit einem gut beschriebenen Kontext in jeder einzelnen Story kann so das dahinterliegende Ziel verborgen bleiben. Die Anforderungsseite beraubt sich so selbst dem wertvollen Input, den Entwickler:innen liefern können.

Ein weiterer Faktor ist, dass das Präsentieren von Lösungen häufig auch bereits Modellierung der Domäne beinhaltet. Das Modellieren als Aufgabenstellung wird damit komplett vorweggenommen und Entwickler:innen fällt es schwerer, die Modellierung zu durchdringen und diese konform in Code zu gießen. Aus Entwicklungssicht bleibt das Modell häufig etwas Fremdartiges, was auf Dauer der Wartbarkeit schadet und die Kreativität von Entwickler:innen hemmt.

Was tun?
Die größte Herausforderung besteht darin, überhaupt zu erkennen, dass eine Anforderung in Wahrheit eine Lösungsanforderung ist. Der Grad hier ist schmal, denn schließlich wollen Akzeptanzkriterien eindeutig, konsistent und verständlich sein. Um das zu erreichen, muss man doch eine Lösung beschreiben, oder nicht?
Das ist korrekt: Wenn eine User Story vorsieht, dass Anwender:innen neue Daten erfassen können, so wird man in der Regel beschreiben, um welche Daten es sich handelt und welche Validierungen durchgeführt werden müssen. Eine fachliche Lösungsanforderung ist hier also unumgänglich, um brauchbare User Stories zu erhalten. Auf der anderen Seite sollten Akzeptanzkriterien keine technischen Vorgaben machen, d.h. die Forderung „Das Modul speichert die Daten in folgende Datenbanktabelle“ wäre unnötig einengend für die Entwicklung. Stattdessen sollte fachlich festgehalten werden, wo die Daten noch zur Verfügung stehen. Die Platzierung der Daten in einer gewissen Tabelle wäre dann ggf. ein technischer Lösungsansatz für diese Forderung.
Solche Dinge fallen aber meist in Refinements recht schnell auf und lassen sich oft ad hoc beheben.

Wir müssen also mental noch einen Schritt zurück machen:
Das übergeordnete Ziel, die Funktionalität, die in einem Epic erfasst wird, sollte eine Problemstellung sein. Die einzelnen Stories dienen dann der Beschreibung der konkreten Lösung. Und damit liegt die eigentliche Lösung der Problematik darin, wie die Stories selbst zustande kommen. Hier ist eine tatsächliche enge Zusammenarbeit und nicht nur die (nun hoffentlich etwas optimierte) Übergabe von Anforderungen vonnöten. In Form einer Product Discovery kann eine solche Zusammenarbeit gelingen. Verschiedene Formate für unterschiedliche Organisationsstrukturen werde ich in einem späteren Blog-Beitrag thematisieren.

Einzelne Stories beschreiben eine (fachliche) Lösung sehr konkret. Die Gesamtheit der Stories aus einem Epic sollte selbst jedoch keine Lösungsanforderung sein.

Für den Moment: Bringt die Fach- und die Entwicklungsseite früh zusammen. Anforderer:innen präsentieren Ideen für Epics früh dem betroffenen Team, sammeln Feedback und lassen sich mit einer Magic Estimation ein Gefühl für Komplexität und Grad des Verständnisses der Entwicklung vermitteln. Geschieht dies vor dem Ausformulieren aller User Stories, haben die Anforderer:innen bereits eine Indikation, was verschiedene Lösungsoptionen sein könnten. Die Entwickler:innen profitieren auf ihrer Seite von einem besseren Überblick über anstehende Aufgaben und haben frühzeitig die Chance, gemeinsam mit der Anforderungsseite ein Modell der Fachlichkeit zu entwickeln und dieses dann Stück für Stück zu verfeinern.

Noch ein allgemeiner Hinweis

Ich plädiere oft dafür, Informationen schriftlich festzuhalten. Das wird zu Mehrarbeit führen; hier müsst ihr selbst einen guten Weg zwischen zu viel und ausreichend viel Dokumentation für euch finden. Außerdem solltet ihr euch einigen, wer welche Änderungen an Dokumenten vornehmen kann. In kleinen Teams empfiehlt es sich, dass alle Beteiligten erhaltene Informationen bei Bedarf nachtragen dürfen. Hier ist jedoch bei vielen Tools Vorsicht bei gleichzeitigem Editieren geboten. Bestimmt zur Not im Meeting, wer die Informationen im Nachgang einpflegt.
In größeren Konstellationen könnt ihr z.B. mehr über die Kommentarfunktionen, die Tools wie Jira oder DevOps bereitstellen, arbeiten. Dann sollte aber etwa ein Product Owner dafür sorgen, dass relevante Informationen an entsprechender Stelle abgelegt werden, damit nicht jeder gezwungen ist, immer eine langatmige Diskussion nachzulesen und dann selbst die richtigen Schlüsse zu ziehen. Optimalerweise ergänzt ihr mit Entwickler:innen und Anforderer:innen gemeinsam Informationen, sobald diese in Diskussionen ans Licht kommen.
In beiden Fällen bin ich kein Freund davon, Entwickler:innen das Recht, Tickets in einem solchen Tool zu bearbeiten, vorzuenthalten.

Fazit und Ausblick

Viele typische Probleme, die zwischen Anforderungs- und Entwicklungsseite im Arbeitsalltag auftreten, lassen sich mit Struktur und passender Kommunikation reduzieren. Den Blick dafür zu schärfen, welche Informationen und Fragestellungen relevant sind und entsprechendes an passenden Orten festzuhalten, unterstützt die Zusammenarbeit zwischen auf beiden Seiten.

Man muss sich aber auch eingestehen, dass eine reine Strukturierung mit Kontext, sauberen Epics und klaren Problemstellungen nicht sämtliche Probleme auf einen Schlag beheben wird. Insbesondere haben wir hier kaum über die umgekehrte Richtung gesprochen und diskutiert, wann etwa die Fachseite durch die Entwicklung „enabled“ werden könnte.

Um tatsächlich eine starke Einheit zwischen Anforderung und Umsetzung zu erzielen, bei welcher sich das gesamte Potential eines Teams entfaltet, bedarf es doch etwas mehr – nämlich tatsächlicher, enger Zusammenarbeit zwischen Anforderungs- und Lösungsseite. In einem späteren Blog-Beitrag besprechen wir Formen dieser Zusammenarbeit und wie diese ganz konkret in Organisationen etabliert werden kann.