Software Systeme haben oft die unangenehme Eigenschaft, mit der Zeit immer weiter zu wachsen und schwerfällig zu werden. Dies wird noch weiter dadurch befeuert, in dem stetig neue Features hinzugefügt werden, die eine schnelle Lösung für ein aktuelles Problem darstellen. Doch dabei kommen während der Produktentwicklung weder optimierte Userflows zum Einsatz, noch finden detaillierte Analysen des Mehrwertes oder der Ausgestaltung statt.
In diesem Artikel berichten wir aus einem unserer Projekte und stellen dar, wie wir mit dem Einsatz unseres Baukastens enbl.it echten Mehrwert durch messbare Verbesserungen in der Produktentwicklung für unseren Kunden schaffen konnten.
Was ist enbl.it?
Enbl.it ist unser Baukasten der dabei hilft, Produkte strukturierter und effizienter zu entwerfen. Dabei werden sowohl Unternehmensziele als auch die Bedürfnisse der Nutzer:innen sowie die Produktanforderungen berücksichtigt. Im Ergebnis erreichen unsere Kunden ihre Ziel damit wesentlich schneller und präziser. Zusätzlich werden die Kundenanforderungen wieder in den Mittelpunkt der Produktentwicklung gerückt.
Die Situation in unserem Kundenprojekt
Wie schon eingangs erwähnt haben Software Systeme oft die unangenehme Eigenschaft, mit der Zeit immer weiter zu wachsen und schwerfällig zu werden. Es werden neue Features hinzugefügt, die eine schnelle Lösung für ein aktuelles Problem darstellen, ohne optimierte Userflows oder eine detaillierte Analysen des Mehrwertes.
Eine ganz ähnliche Situation fanden wir auch bei einem unserer Kunden vor. Die Software des Unternehmens bestand aus einer Menge einzelner Komponenten. Wurde nun ein neues Feature benötigt, das sich über mehrere Komponenten erstreckt, wurde reflexartig ein Epic in Jira angelegt. Mit der Zeit entstanden Stories, die voneinander abhängig waren und einen so großen Umfang hatten, dass eine Schätzung des Zeitaufwands für die Entwicklung nahezu unmöglich war.
Dennoch erstellte das Team eine Roadmap. Diese Roadmap entbehrte jedoch jeglicher Aufwandschätzung. Dabei überrascht nicht, dass die erwünschten Lieferfristen regelmäßig nicht eingehalten wurden.
Was haben wir unternommen, um die Produktentwicklung zu verbessern?
Bevor wir auf die Werkzeuge aus dem enbl.it Baukasten zurückgriffen, haben wir analysiert, welche Methoden den Prozess überhaupt optimieren könnten. Um beispielsweise das Problem der zu großen Stories in den Epics zu lösen und somit eine Planbarkeit zu ermöglichen, wurden die Initiativen (Miniprojekte innerhalb des Projekts) für die Zielsetzung sowie Customer Journeys (Beschreibung der Nutzerinteraktion mit dem Produkt) für die Nutzersicht aus enbl.it verwendet. Dadurch konnten wir eine neue Ebene über den Epics mit Hilfe der Initiativen abbilden. Die Epics werden weiterhin benutzt, um die Anforderungssicht, die sich aus der Customer Journey ableitet, abbilden zu können und die Stories logisch zu gruppieren.
Die Initiativen und Customer Journeys werden in Confluence gepflegt und sind daher auf einen Blick einsehbar. Zuvor wurde für jedes neue große Feature ein Epic in Jira mit sehr vielen Stories erstellt. Mittlerweile wird dafür eine Initiative geschrieben, die Customer Journeys für einzelne logische Bausteine enthält. In jeder Customer Journey sind alle Komponenten enthalten, die für diesen logischen Baustein notwendig sind. Dadurch wird bei jeder Customer Journey querschnittlich über alle beteiligten Komponenten reflektiert und sichergestellt, dass die Stories nicht zerfasern. Ebenfalls wird durch dieses Vorgehen verhindert, dass die Stories zu groß werden und nicht mehr geschätzt werden können.
Um den Überblick zu behalten, werden die Initiativen, Customer Journeys und Stories in Confluence dokumentiert und mit Jira Tickets verlinkt. Durch das Verlinken der Epics und Stories bietet Confluence einen sehr guten Überblick über den Status der Epics und Stories.
Ein wesentliches Charakteristikum von enbl.it ist das Baukastenprinzip – man kann alle Teile verwenden, muss es aber nicht. Im Gegenteil: an Stellen, wo die aktuelle Herangehensweise gut funktioniert, kann diese natürlich beibehalten werden. So auch bei unserem Kunden. Gemeinsam haben wir entschieden, statt der im enbl.it Baukasten vorgesehenen Personas (Stellvertreter aus der Zielgruppe) mit den bereits erarbeiteten, detaillierten Rollenbeschreibungen des Kunden im Projekt fortzufahren.
Wie hat der Prozess geholfen, den Status Quo zu verbessern?
Durch die Einführung einer weiteren Ebene – der Initiativen – haben wir sowohl einen besseren Überblick über den gesamten Produktentwicklungsprozess, als auch eine verbesserte Planbarkeit für die Roadmap geschaffen. Jede Customer Journey kann durch eine Grobschätzung eingeordnet werden. Durch Auswertungen der letzten Sprints kann so eine sinnvolle Roadmap erstellt werden. Diese Roadmap ist allerdings nicht in Stein gemeißelt und wird angepasst, sobald neue Erkenntnisse vorliegen.
Durch die strukturierte Vorgehensweise sind sowohl Interaktion als auch Kommunikation mit und bei unserem Kunden deutlich klarer geworden. Dank des Userflows, der in einer Customer Journey beschrieben wird, beschäftigen sich alle Beteiligten aktiver mit der Interaktion der Nutzer:innen mit dem Produkt. Schon bei der Entwicklung des Userflows werden Unstimmigkeiten sichtbar und können direkt aufgelöst werden. Diese Unstimmigkeiten sind vor dem Einsatz von enbl.it erst beim Review oder im schlimmsten Fall erst nach Auslieferung aufgefallen.
Ein weiterer positiver Nebeneffekt ist, dass die Fachkonzepte direkt als Initiative bzw. Customer Journey dokumentiert werden. Dadurch ist es möglich, sich auf das Wesentliche zu konzentrieren und sich nicht mit einer Anforderung zu beschäftigen, deren Umsetzung die Nutzer:innen vielleicht (noch) gar nicht benötigen. Somit wird sichergestellt, dass der Fokus auf dem Thema liegt, das für die Zielgruppe am wichtigsten ist. Mögliche Varianten können dennoch in der Customer Journey erfasst und zu einem späteren Zeitpunkt umgesetzt werden.
Geschrieben von Heinz Lethaus.
