Drive Now & Das Neue App Team
Gute Produkte, werden nachhaltig gute Produkte durch großartige Teams!
Sebastian Borggrewe
Gute Produkte, werden nachhaltig gute Produkte durch großartige Teams!
“Sebastian hat uns nicht nur geholfen, ein leistungsfähiges Mobile Team aufzubauen, sondern auch das Produkt entscheidend mitgeprägt. Er ist in jeglicher Hinsicht die Schnittstelle zwischen Business und IT, die wir uns gewünscht haben.”— Britta Hirsch, Head of Product - DriveNow
Wir lieben unsere Kunden, weil Sie jeden Tag unsere Welt ein Stück verändern. Das Produkt Team von DriveNow hat die letzten 6 Jahre ein Produkt aufgebaut, welches die Art und Weise wie wir über Autos und Mobilität nachdenken, grundlegend verändert hat. Mit über 1 Millionen Kunden in 9 Ländern, die Tag für Tag über 6000 Fahrzeuge bewegen, ist DriveNow heute der zweitgrößte Carsharer weltweit.
DriveNow will im Sommer 2017 mit der Entwicklung eines neuen Produktes beginnen, welches den Aufbau eines zweiten App Engineering Teams notwendig macht.Da zum Zeitpunkt des Projektstarts, aus Kapazitätsgründen, in-house kein erfahrener Mobile Experte verfügbar war, kam DriveNow auf Sebastian zu (zu diesem Zeitpunkt war Sebastian noch als Freiberufler tätig).
Für das Produkt und das Team gab es klare Zielsetzungen. Zum einen sollte Sebastian mit DriveNow ein Produkt konzipieren, was die Bedürfnisse des Users in den Mittelpunkt stellt (user-centric product development).Zum Anderen sollte er ein App Team mit zwei Entwickler rekrutieren (iOS & Android) und eine geeignete agile Umgebung für das Team schaffen, sodass sie das Produkt selbständig ausbauen und ausliefern können. Auf den Punkt gebracht: Sebastian sollte seine eigene Erfahrung mit dem Team teilen, sodass dieses Ihn nach und nach immer weniger braucht. Als zusätzliche Anforderung kam hinzu, dass er gleichzeitig eng mit den verschiedenen Backend Teams zusammenarbeiten und seine technische Expertise in das Produkt Team von DriveNow einbringen sollte.Im Folgenden wollen wir einen Einblick in unseren Prozess geben. Von der Lösungs-Validation, über Recruiting des Team, bis hin zur Entwicklung der App, und abschließend den Knowledge Transfer, der über die komplette Projektlaufzeit stattfand.
Der Kickoff war ein Workshop mit Britta (Head of Product, DriveNow), Susann (Product Manager, DriveNow), Christian (UI/UX Expert, Freelancer) und Sebastian (Tech, Productsquads). Wir nahmen uns gemeinsam einen ganzen Tag, um mit einer Methode, die sich Story Mapping nennt, alle Berührungspunkte des Users mit dem Produkt aufzuzeigen. Von dem Zeitpunkt wo er das erste Mal von dem Produkt hört, über die Registrierung, Nutzung und schließlich dem Beenden der Beziehung mit dem Nutzer.Diese Workshops machen nicht nur unglaublich Spass, sondern geben allen Beteiligten (Product/Business, Design & Tech) ein gemeinsames Verständnis, wie die Customer Journey aussieht. Die Ergebnisse des Workshops (teilweise auf dem Foto sichtbar) waren Grundlage für den ersten Prototypen.
Nutzerzentriertes Arbeiten ist wichtig für schnelle Erfolge!
Im ersten Schritt sollten Prototypen immer so einfach wie möglich gehalten werden, damit erste Fehler schnell gemacht und schnell behoben werden können (Fail early, fail often).Für den ersten Prototypen brauchten wir daher nur 2 Tage und Stift & Papier.Wir nahmen diesen Prototypen und zeigten ihn mit dem Produkt Team den Stakeholdern - Geschäftsführung, potenziellen Nutzern, Partnern und Entwicklern.Ziel war es eine Diskussion in Gang zu bringen, Wissen zu teilen, über das Businessmodel und fehlende Funktionalität zu sprechen. So konnten wir auch konkreter über mögliche Technologie nachdenken (App & Backend) und wie ein gestaltetes Endprodukt aussehen könnte.Der Vorteil eines offensichtlich rudimentären Prototypen ist, dass alle Beteiligten immer noch das Gefühl haben, dass es einfach ist Änderungen herbei zu führen und das noch jede Menge Gestaltungsspielraum gegeben ist.
Nach den Tests mit dem Pen&Paper Prototyp und den Insights, welche wir mit dem Kunden auf diese Weise sammeln konnten, baute Christian eine Mehrzahl von besseren Prototypen (High-Fidelity Prototypes). Das bedeutet konkret, dass man etwas schafft, dass sich fast schon wie das Endprodukt anfühlt (ohne das man es schon programmieren muss).Wir erstellten mit Christian zwei unterschiedliche Arten von Prototypen:
Das User Profil des zweiten Prototypen
Eine klickbare, gestaltete Variante unseres Pen&Paper Prototypen, welcher die Customer Journey für den User erfahrbar macht. (siehe rechts) Tool: Invision https://www.youtube.com/watch?v=qkvS5II6zY8
Es gibt in vielen Produkten komplexe Interaktionskonzepte, die mit einem einfachen, klickbaren Prototypen nicht vertestet werden können. Auch hier brauchten wir Interaktions-Prototypen, die nur einen kleinen Teil der App Interaktion abbilden und sich besonders für komplexe Interaktionen eignen, da der Nutzer wirklich das Gefühl hat mit einer echten App zu interagieren (ohne den damit verbundenen Programmieraufwand).Tool: Principlehttps://www.youtube.com/watch?v=-LClkJcv2xI Susann & Christian validierten die Prototypen in verschiedene Flurtests. Flurtest heißt, dass man sich einfach einen Mitarbeiter auf dem Flur schnappt, ihr den Prototyp in die Hand drückt und sich sofort Feedback einholt. Auf diese Weise validierten wir teilweise mehrfach am Tag.Für die großen Interaktionskonzepte nahmen wir am Testessen in Munich teil. Beim Testessen treffen Firmen auf echte Nutzer. Es gibt Bier & Pizza, alle haben eine gute Zeit und man kriegt innerhalb von kürzester Zeit richtig gute Antworten auf die Frage: Was funktioniert und was nicht? Win - Win. Das Format ist eine klare Empfehlung.
Der finale, klickbare Prototyp war in gewissermaßen die Blaupause für die App und wurde vom Kunden auch genutzt um potenzielle Partner für das neue Produkt zu begeistern. Wir konnten dadurch die Backend Tech Teams in das Thema einführen und ihnen zeigen wie sich das finale Produkt anfühlen soll. Das ist daher so wichtig, weil Backendler oftmals sehr wenig bis gar keinen Endnutzer Kontakt haben.
Zu Beginn machten wir uns Gedanken, wie wir die Entwicklung des Produktes ordentlich strukturieren. Klar war, dass agil entwickelt wird. Unklar war anfangs, ob Kanban oder Scrum (Beides agile Methoden). Sebastian & Susann entschieden sich allerdings schnell für Scrum und 2-Wochen Sprints, da man durch diese Methode im Verlauf des Projektes schon früh Prognosen über die Einhaltung der Deadline machen kann. Im Nachhinein stellt sich die Entscheidung als richtig heraus, da Sebastian dank Scrum, bereits 4 Monate vor Launch in den Piloten, einen Kapazitätsengpass identifizieren, DriveNow drauf hinweisen und gegenzusteuern konnte.Außerdem sorgt Scrum durch Reviews am Ende des Sprints dafür, dass alle Stakeholder immer im Loop sind. Review? Das sind Präsentationen des Produktstandes für die Stakeholder und eine Möglichkeit für das Team ihren Fortschritt zu präsentieren. Wir sorgen dadurch für maximale Transparenz in der Produktentwicklung.
Für die Android App kam mit Serhii zum Start ein Entwickler aus einem anderen in-house Team. Von Anfang an hat Sebastian mit Serhii einen Plan erarbeitet wie wir ihn in die Rolle des Tech Lead aufbauen können. Sebastian übernahm interimsmäßig die iOS Entwicklung. Parallel suchten wir nach einem iOS Entwickler.Das anfängliche Team bestand somit aus Susann (Product Owner), Serhii (Android) und Sebastian (Tech Lead/Scrum Master).
Da Sebastian die iOS Entwicklung nur interimsmäßig übernommen hatte und es klar war, dass die Hauptaufgabe im Teamaufbau und dem technisches Support für das Produktmanagement liegen würde, suchten wir direkt zu Beginn nach einem geeigneten Senior iOS Entwickler. Mit Slavik machten wir das Tech Team nach nur 6 Wochen komplett und er fing 2 Wochen später mit dem 4. Sprint an. Im Dezember kam mit Amelie, als Trainee, darüber hinaus noch eine dedizierte Testerin ins Team. Ab diesem Zeitpunkt war der Testsupport dringend notwendig geworden und sie half dem Team ein noch besseres Produkt bauen zu können.
Als das Team komplett war, war der Scrum Prozess essenziell, um qualitativ immer besser zu werden und außerdem schneller. Ein zentraler Aspekt waren dabei die Retrospektiven (kurz Retro). Die Retro ist ein zwei-wöchentliches Meeting am Ende jedes Sprints, bei dem das ganze Team zusammenkommt und reflektiert, wie die letzten 2 Wochen gelaufen sind - in der Regel nach der Review mit den Stakeholdern.Dabei gibt es eine Vielzahl von Spielen & Übungen, die helfen können das Feedback ehrlich und erlebbar zu machen:Es kann einfach nur eine Liste sein: 1. Was haben wir gut gemacht und 2. Was können wir noch besser machen.Oder aber auch etwas emotionalere Übungen wie:“Sag etwas Posivites über deinen rechten Nachbarn” oder “Male, wie sich während des Sprints die Zusammenarbeit im Team angefühlt hat”. Wenn man hier zum ersten Mal über diese Methodiken stolpert, mag es sich etwas ungewohnt anfühlen. Fakt ist jedoch, das diese Art Feedback einzuholen, dazu führt, dass alle offener und ehrlicher miteinander umgehen, sich besser kennenlernen und daher viel besser miteinander arbeiten.
Das ist die Philosophie auf dessen Basis die Productsquads, im Anschluss an dieses Projekt, von Sebastian gegründet wurden. Deswegen waren Sebastian & Britta sich auch einig, dass schon früh Verantwortung und Wissen auf die neu-gewonnen Entwickler im Mobile Team übertragen werden sollte.Wie bereits oben erwähnt war der Plan von Anfang an Serhii zum Team Lead aufzubauen. Er sollte die technische Rolle von Sebastian zu 100 % übernehmen. Daher machten wir am Anfang des Projektes schon einen Plan, wie dieser Übergang aussehen sollte.Nach 4 Monaten übernahm Serhii die technische Verantwortung für das Mobile Team. Nach 6 Monaten übernahm er die Koordination mit den Backend Teams.Zu diesem Zeitpunkt nahm Sebastian noch seine Rolle als Scrum Master wahr und half die User Stories für die das Mobile Team zu schreiben.In dieser Schlussphase war das Ziel vor allem dem neuen Mobile Team zu helfen noch besser zu werden und mögliche Hindernisse aus dem Weg zu räumen, sodass alle ihren Job so gut wie möglich machen konnten. Das Entwicklungsteam war während des Projektes größtenteils Remote. Auf dem Bild ist eine Grooming Session zu sehen, in der Aufwände von Features geschätzt werden.
Im Mai 2018 war unser Ziel, nach nur 9 Monaten, erreicht. Sebastian war für die weitere Entwicklung des Produktes nicht mehr notwendig und so konnte er das Team, 4 Wochen vor Launch in den internen Piloten, verlassen. Serhii hatten zu diesem Zeitpunkt die technischen Verantwortung vollständig übernommen. Slavik hat sich als eine perfekte Ergänzung zum Team bewährt und ist voll verantwortlich für die iOS App. Susann ist immer noch eine großartige Produktmanagerin, aber ist nun außerdem eine Expertin im Arbeiten mit einem Mobile Team.
Für Sebastian wird der Kunde DriveNow und dieses Projekt immer etwas ganz besonderes bleiben, weil Beides zum Gründen der Productsquads beigetragen hat. Einen besonderen Dank an das ganze Produkt Team von Britta Hirsch und natürlich an das neue App Team, an Susann, Serhii und Slavik. Mittlerweile haben Sie sogar einen Namen: The Hornets.
Links:DriveNow (Jetzt SHARE NOW)
Großartige Produkte werden langfristig In-House gebaut - nicht von Agenturen.
Die Methodik, die hier beschrieben wurde, ist repräsentativ für unsere Arbeitsweise. Seit diesem Projekt gibt es Sebastian nicht nur Solo, sondern, mit den Productsquads, auch als Team. Wir stellen je nach Projektbedarf ein komplettes Team zur Verfügung, welches nach und nach in ein internes Team gewandelt werden kann. Wir sind keine Agentur. Das bedeutet: Das Team konzentriert sich auf ein Projekt- So stellen wir sicher, dass wir so nah wie möglich an den Bedürfnissen unserer Kunden arbeiten können.