In erfolgreiche agile Projekte einklinken

Ob mit Scrum, Kanban oder einer anderen Methode aus der agilen Softwareentwicklung – zur alltäglichen Arbeit in agilen Teams findet sich haufenweise Literatur. Geht es jedoch konkret um die ersten Schritte eines Projekts, so lautet der Rat zumeist: «Einfach damit anfangen!»  Doch wie muss man sich das genau vorstellen?

Der Gedanke, einfach mit dem Programmieren loszulegen und Prototypen zu entwickeln, ist verführerisch. Ein gewisses Verständnis der Voraussetzungen, Beschränkungen und Ziele eines Produkts ist jedoch hilfreich, wenn man sich nicht verzetteln will. Dies gilt vor allem dann, wenn es sich bei der zu entwickelnden Software nicht um ein internes Produkt, sondern um einen Kundenauftrag handelt. Oftmals ist man ja – gerade zu Beginn eines Projekts – mit den geschäftlichen Vorgaben eines Kunden nicht oder nur wenig vertraut.

Ich persönlich verwende die ersten Tage eines Projekts deshalb gerne damit, mir einen Überblick über den Kontext und die Ziele des Produkts zu verschaffen. Damit kann ich zusammen mit den an der Umsetzung beteiligten Kolleginnen und Kollegen ausreichend Informationen erarbeiten, um im Verlauf des Projekts eine gewisse Autonomie und eine gemeinsame Zielvorstellung zu gewährleisten. Das bedeutet nicht, immer mehr und noch detailliertere Anforderungen einzuholen, sondern ein Verständnis dafür zu entwickeln, worum es bei dem Produkt eigentlich geht. So verschafft man sich zuerst einen Überblick über die Produktvision, die Stakeholder sowie die Priorisierung der gewünschten Qualitätsziele.

Es sollte also eine gewisse Zeit investiert werden, um herauszufinden, worum es bei einem Produkt eigentlich geht, gefolgt von agilen Iterationen und häufigen Lieferungen

Mit diesem Wissen ausgestattet, ist es häufig ein Leichtes, eine erste Story Map zu erstellen und ein Walking Skeleton, also ein «Projekt-Skelett» zu entwickeln. Solche «Findungsphasen» sollten so kurz wie möglich gehalten werden. Mögliche Lücken können auch zu einem späteren Zeitpunkt gefüllt werden. Denn je schneller man mit der Entwicklung des Produkts beginnt, desto schneller gibt es auch ein konkretes Feedback.

Die Projektvision – weshalb sich ihre Entwicklung lohnt

Um den Kontext eines Projekts zu verstehen, sollte man zuerst ein Verständnis der dahinterstehenden Vision entwickeln. Und das bedeutet nicht nur, zu verstehen, was man erreichen möchte, sondern vor allem auch, weshalb. Die Vision hinter einem Produkt zu verstehen, hilft etwa, bei einem allfälligen Backlog zu reagieren. An diesem Punkt lasse ich den Kunden zumeist erst einmal die Idee Erklären, um dann mithilfe der 5-Why-Methode nachzuhaken und reichlich Notizen zu machen.

Und fast immer liegt der Teufel im Detail: Anstatt «warum entwickeln wir das Produkt?» frage ich «warum sollte ich das Produkt nutzen wollen?». Dabei wechsle ich die Perspektive vom Produktanbieter zum Produktanwender. Auf diese Weise erhalte ich oftmals die besseren Informationen. Ist die Vision noch ein wenig unscharf, lohnt es sich für gewöhnlich, etwas mehr Zeit zu investieren, um einen Value Proposition Canvas zu entwickeln. Und ja, es ist mir auch schon passiert, dass das Projekt an diesem Punkt abgebrochen wurde, weil wir feststellen mussten, dass eigentlich keiner so recht wusste, weshalb wir diese spezielle Software entwickeln sollten.

Die Stakeholder Map – wer ist involviert?

Haben wir eine ungefähre Idee davon, wohin wir mit einem Produkt wollen, sollten wir uns als Nächstes ansehen, wer davon profitiert. Ein gerne gemachter Fehler besteht darin, alle Stakeholder als «unsere Nutzer» oder «unsere Kunden» zusammenzufassen. Die Gruppe der Stakeholder ist häufig wesentlich heterogener und vielfältiger als ursprünglich angenommen. Ich nutze dafür gerne die sogenannte Stakeholder Map.

Auf der Map werden die wichtigsten Nutzer im Zentrum platziert. Je weiter am Rand sich ein Nutzer befindet, desto geringer ist sein Interesse und sein Einfluss auf das Produkt. Eine Aufteilung nach Organisationszugehörigkeit hilft zusätzlich, die jeweiligen Verbindlichkeiten und Interessen im Hinblick auf das Produkt zu identifizieren.

Die Auswirkungen eines Produkts auf die unterschiedlichen Stakeholder-Gruppen zu identifizieren, hilft, die unterschiedlichen Erwartungen erfüllen zu können. Eine simple Faustregel ist dabei, die Anforderungen der Stakeholder im Mittelpunkt der Karte zu priorisieren.

Die Qualitätsmetriken – was bedeutet «gut»?

Mittlerweile wissen wir also, was wir tun wollen und für wen. Im nächsten Schritt geht es nun darum, herauszufinden, was das Produkt gut macht. Dazu sammle ich die Qualitätsmerkmale, die das Produkt erfüllen muss. Da ich aus dem Bereich Medizintechnik komme, sind die Qualitätsmerkmale gemäss ISO 25000 hier der natürliche Ausgangspunkt für mich. Man kann diese Merkmale auch noch um Eigenschaften wie Skalierbarkeit oder Patientensicherheit erweitern. Grundsätzlich sollte die Zahl der Qualitätsmerkmale jedoch überblickbar bleiben.

Eine umfassende Quality-Function-Deployment-Analyse (QFD) durchzuführen, ist zu diesem Zeitpunkt meines Erachtens meist übertrieben. Eine QFD-ähnliche Matrix, in der die Anforderungen den priorisierten Qualitätsmerkmalen gegenübergestellt werden, hilft jedoch bei der frühzeitigen und schnellen Entscheidungsfindung im Hinblick auf die spätere Softwarearchitektur. Eine Priorisierung der Qualitätsmerkmale gibt wiederum Hinweise darauf, welche Schritte im Walking Skeleton an erster Stelle stehen sollten.

Story Mapping – ein Narrativ entwickeln

Nun sind wir endlich bei den Storys und der Entwicklung eines schlanken Backlogs angelangt. Meine Methode der Wahl zur Entwicklung eines Backlogs und zur Definition eines Walking Skeletons ist das Story Mapping. Ziel der Story Map ist es, die gewünschten Produktmerkmale in ein Narrativ und einen Kontext einzuordnen. Mein oberstes Ziel ist dabei, zuerst ein übergeordnetes Narrativ zu entwickeln und erst dann die einzelnen Storys zu entwerfen. Bei der Priorisierung sollte man hier sehr strikt vorgehen. Alles, was nicht dringend erforderlich ist, wird rausgeworfen oder zu einem späteren Zeitpunkt zugeordnet. Da wir uns am Anfang des Entwicklungsprozesses befinden, sind die User Storys noch sehr grob formuliert, sie weisen oft noch nicht die detaillierten Abnahmekriterien aus. Das ist Absicht. Das Slicing und die Entwicklung eines vollständigen schlanken Backlogs kommen später.

Sie sollten die Stakeholder Map und die Story Map so oft wie möglich miteinander abgleichen. Sollten auf der Story Map einige der wichtigsten Stakeholder fehlen, ist es gut möglich, dass ein wichtiger Teil des Produktes fehlt oder die Stakeholder-Analyse unvollständig ist.

Das Walking Skeleton definieren – ein vertikaler Spike

Fast geschafft! Das Narrativ für das Produkt steht. Jetzt wird verschlankt! Bei der schlanken und agilen Softwareentwicklung kommt es auf frühzeitiges und häufiges Feedback an. Erstes Ziel ist es deshalb, um festzustellen, ob der zentrale Use Case des Produktes funktioniert oder nicht. Als Faustregel gilt auch hier: Alles, was Stakeholder ausserhalb der Kerngruppe oder Spezialfälle betrifft, wird auf später verschoben. Sie sollten sich bei jeder Story fragen: «Gibt es eine Möglichkeit, zunächst mit einer Behelfslösung zu arbeiten?» Beispielsweise könnte die Rechnungsstellung für einen Onlineshop bei den ersten 100 Kunden manuell via E-Mail abgewickelt werden.

Es zahlt sich aus, hier radikal vorzugehen und das Walking Skeleton auf das absolute Minimum zu trimmen. Machen Sie keine ausgefallenen Zusatzarbeiten oder Grenzfälle, es sei denn, dies ist rechtlich erforderlich. Bei den meisten Produkten, an denen ich bisher mitgearbeitet habe, liess sich das Walking Skeleton in weniger als zehn Storys definieren. Natürlich werden diese später noch weiter unterteilt, wenn das Team mit der Implementierung beginnt, aber für die ersten Schritte reicht das vollkommen. Sollte man die Basis des Projekts nicht in zehn oder weniger Sätzen erklären können, ist es gut möglich, dass das Walking Skeleton zu kompliziert ist.

 … und los geht‘s!

Nun kann die eigentliche Entwicklungsarbeit beginnen. Präzisieren Sie die erste Story, brechen Sie sie auf eine verwertbare Grösse herunter, formulieren Sie Akzeptanzkriterien und beginnen Sie mit dem Programmieren. Den Produktkontext von der Vision bis hin zur Story Map zu entwerfen, dauert meist nur ein paar Tage, die aber oft einen unglaublichen Mehrwert liefern. Die erste Story oder der erste Spike sollte dann innerhalb weniger Tage oder Wochen vorliegen, um frühzeitig Feedback von den betroffenen Stakeholdern einholen zu können.

Denken Sie daran, dass es sich bei einer Story Map um ein lebendes Dokument handelt, das sich kontinuierlich ändern wird. Vergleichen Sie das Narrativ mit dem, was Sie seit der letzten Iteration gelernt haben, und passen Sie es entsprechend an. Die Stakeholder Map, die Vision und die Qualitätsmerkmale haben tendenziell eine etwas längere Lebensdauer als die Story map. Sie sollten jedoch trotzdem regelmässig überprüft werden. Machen Sie diese Dokumente bei Ihren daily standups sichtbar und überarbeiten Sie es jedes Mal, wenn Sie langfristige Strategien besprechen, beispielsweise beim Entwurf einer agilen Roadmap.

Dieser Text erschien zuerst auf Englisch im Blog von Dominik Berner.