Vorletzten Donnerstag war es endlich soweit! Nach langem Warten fand der dritte Hamburger ProductTank diesmal im Rahmen des Reeperbahnfestivals statt. Neben produktbezogen-Autor Daniel Neuberger stand diesmal Lean-UX Autor Jeff Gothelf mit auf der Bühne.
TL;DR
Da es sich hier um einen sehr langen Artikel handelt, habe ich mich entschieden, meine Key-Learnings im Vorfeld zusammenzufassen. So könnt ihr euch schnell einen Überblick verschaffen.
- Agile doesn’t have a brain – Auch die agile Softwareentwicklung hält nicht für alles Lösungen bereit – Wir müssen unsere Unternehmenskulturen weg von Kulturen der Umsetzung, hin zu Kulturen des Lernens entwickeln
- Roadmaps und Deadlines sind Artefakte der „old Economy“. Sie fokussieren auf Output in Form von Features oder Produktlaunches, statt auf Nutzer- und Geschäftswert
- Das relativ starre Rollenverständnis agiler Produktentwicklung, wie auch traditioneller Managementmethoden, führt nicht immer zum Ziel
- Sich nochmals mit diesen Themen zu beschäftigen lohnt sich. Auch wenn das für uns alles ein alter Hut zu sein scheint, ist es spannend, seine eigene Arbeit mal zu reflektieren. Also lest den ganzen Artikel ;)
The old economy still alive
„Software is eating the world“ (Marc Andreessen)
Nahezu jedes Unternehmen heutzutage ist ein Softwareunternehmen. Amazon investiert schwer in Logistiksoftware. Die New York Times kämpft mit Buzzfeed & Co. Ford sieht sich mit Tesla einen völlig neuen Herausforderer gegenüber. Napster besiegte vor Jahren die RIAA. Auch wenn es unter Anderem durch Metallica’s Lars Ulrich zu Fall gebracht wurde, so findet man die Musik seiner Band heute auf Spotify. Last but not least schaffte es Netflix, das gesamte DVD-Verleihgeschäft auf den Kopf zustellen.
Wenn man etwas länger drüber nachdenkt, ist es schockierend, wie wir in unserem wirtschaftlichem Tun Management-Praktiken der Industrialisierung auf Software übertragen. Daniel hatte bereits in seinem produktbezogen-Artikel Das Biest Unternehmenskultur beschrieben, wie stark sich heutige Managementmethoden an die von Frederik Taylor 1911 veröffentlichten Methoden anlehnen. Wir versuchen Methoden zum managen von Fließbandarbeit direkt auf die Softwareentwicklung zu übersetzen – Stichwort Wasserfall. Das Problem ist jedoch, dass dies nur funktioniert, wenn wir den Ausgang kennen. Bei einem Auto wissen wir ziemlich genau, wie es genutzt wird. Wir wissen auch, wie das Auto am Ende der Fabrikationsstrecke aussehen soll. Und wenn es einmal fertig ist, wird es auch nicht mehr verändert – oder eben nur alle paar Jahre.
Bei Software ist dies jedoch nicht der Fall. Softwareentwicklung ist nicht endlich. Hier gelten andere Rahmenbedingungen. Allerdings hat auch die agile Softwareentwicklung nicht die Antworten auf all diese Fragen. Doch wie schaffen wir es, hierbei möglichst schnell auch den Geschäftswert zu validieren?
Lernen – der Kern von Lean UX
Wenn ihr dieses Bild seht, wer ist das?
Erstaunlich, oder? Wenn ihr dieses Bild vor 30 Jahren gesehen hättet, hättet ihr voraussagen können, dass darauf ein, vielleicht sogar zwei zukünftige Präsidenten der vereinigten Staaten zu sehen sind? Eher nicht.
Amazon released alle 11.6 Sekunden in ihrer Produktivumgebung. Warum tun Sie das? Ganz einfach: Weil Sie so schneller lernen!
„You need to setup and organize so that you can do as many experiments per unit of time as possible“ (Jeff Bezos)
Durch die Produktnutzung sprechen ihre Kunden mit ihnen. Natürlich kann man das nicht vollständig automatisieren. Der Mensch brauchen Zeit, um Ergebnisse zu interpretieren und Maßnahmen daraus abzuleiten. Wenn man sich jetzt aber vorstellt, dass eine gesamte Organisation dies tut, ist das schon beeindruckend.
Neue (Produkt-)Strategien
Wir wissen in dieser schnelllebigen Zeit einfach nicht, was als Nächstes in der Welt passiert, wie Kunden auf eine Veränderung oder unser neues Produkt reagieren. Daher werden unsere Strategien zukünftig flexibler auf Marktereignisse reagieren müssen. Strategien, die in einem Meetingraum von ein paar wenigen Menschen entwickelt werden, sind nicht mehr zielführend. Wir brauchen flexible Strategien, getrieben von dem Drang, den Kunden besser zu verstehen und daraus Mehrwerte für ihn zu schaffen. Aus Produktmanagement-Sicht bedeutet das nicht, dass Dinge wie eine Produktvision völlig obsolet werden. Im Gegenteil! Sie dienen immer noch als Zielbild und sind unersetzlich. Es heißt auch nicht, dass wir uns auf den Beifahrersitz setzen und einfach die Ereignisse abwarten, die da kommen. Ein experimenteller, iterativer Produktentwicklungsprozess erzwingt bewusst Markt- bzw. Nutzerverhalten. Damit sind wir auch am Steuer. Doch dafür gibt es einige Voraussetzungen:
1. Das richtige Team
Wie typisch im agilen Umfeld sollten die Teams klein (6-8 Leute) und cross-funktional sein. So können alle notwendigen Tätigkeiten ohne Hilfe von Außen bewältigt werden. Wenn irgendwie möglich, sollte das Team an einem Standort sitzen – dies vereinfacht die Kommunikation erheblich. Des Weiteren müssen die Teams fokussiert auf diesem einen Projekt arbeiten – „Nebenbeiveranstaltungen“ sind tabu. Soweit ist also alles typisch agil und wer Marty Cagan’s Ansatz kennt, wird hier viele Parallelen feststellen.
2. Keine Roadmaps
Eine Empfehlung von Jeff: Keine Roadmaps! Das Problem mit diesen Dokumenten ist, dass sie auf Output (=Features, etc.) abzielen, statt auf Outcomes (Ziel des Nutzers) und den damit verbundenen Impact (=Geschäftswirksame Steigerung von Kennzahlen). Ich höre schon Kommentare: „Ja, aber manchmal ist Output notwendig, um Outcome zu erreichen.“ Stimmt wohl! Das bedeutet aber nicht, dass wir vorher wissen, wie der Output aussehen soll bzw. was er tun soll. Die Aufgabe des Managements ist es, den Teams ein klar definiertes Ziel zu geben. Features oder Produktlaunches allein sind keine Maßgabe für Erfolg. Viele Manager haben Angst davor, loszulassen. Sie haben Angst davor, dass es nur inkrementelle Verbesserungen gibt, aber der große Schritt nach vorn übersehen wird. Das alles lässt sich auf ein Kernproblem zurückführen: Sie vertrauen ihren Mitarbeitern und Teams nicht! Ein schönes Beispiel wie es auch anders gehen kann ist die Gilt Group.
„We don’t maintain a Roadmap Document. Our Roadmap ist simply the sum of active initiatives. We revisit the set of prioritized initiatives every few months.“ (Scaling Agile at Gilt)
Interessanter Ansatz. Allerdings ist auch hier Vorsicht geboten. Die Simplifizierung kann auch schnell dazu führen, dass man zu viele aktive Initiativen gleichzeitig hat. Wenn nun auch noch Abhängigkeiten unter den einzelnen Teams bestehen, gibt es rasch Zielkonflikte. Mit Disziplin ist das aber auch zu lösen.
3. Fokus auf Outcome, nicht Output
Es liegt also in der Verantwortung des Managements, einem Team ein Problem zu geben, welches es lösen soll, nicht die Lösung selbst. Das Team muss herausfinden, wie es dieses Ziel erreicht. Der Weg darf nicht durch eine HIPPO (Highest Paid Persons Opinion) bestimmt werden. Damit fühlt sich das Team dann für die Lösung verantwortlich und das Management gewinnt mehr vertrauen in zukünftige Entscheidungen des Teams.
Auch hier hat die Gilt Group einen interessanten Ansatz gefunden. Jede „Initiative“ ist verbunden mit einer sog. strategischen KPI. Dies sind zentrale Metriken, die direkten Einfluss auf den Geschäftserfolg haben. Bei einem Online-Shop könnte das z.B. der Umsatz sein. Das Team wiederum wählt für seinen Auftrag passende taktische KPIs. Z.B. Konversions- oder Warenkorbabbruch -raten, Warenkorbgröße, etc. Diese Kennzahlen können sich im Verlauf eines Projektes durchaus ändern, sollte das Team bemerken, dass sie nicht zielführend sind. Wichtig ist dabei aber, dass taktische Kennzahlen immer eine Auswirkung auf die strategischen haben müssen.
Wie ein Team NICHT arbeiten sollte
Soweit hört sich alles stark nach agilem Arbeiten an, oder? In vielen Teilen stimmt dies auch. Kollaboration ist z.B. ein zentrales Element. Interessant waren aber vor allem die Anti-Pattern.
Starres Rollenverständnis
Jeff erzählte von Jeff „Skunk“ Baxter. In den 70er Jahren war er Rockgitarrist bei Steely Dan und den Doobie Brothers. Weiß jemand was er heute macht? Er ist Berater des US-amerikanischen Verteidigungsministeriums in Sachen Raketenabwehr!
Was können wir daraus lernen? Jedes Teammitglied sollte in der Lage sein, seine Stärken und Fähigkeiten einzubringen. Unabhängig von seiner/ihrer Rolle. Viele von uns haben wahrscheinlich versteckte Talente, die sie im Alltag gar nicht einbringen können. Warum sollte ein Designer nicht auch mal coden? Warum ein Entwickler nicht auch designen?
Angst vor Fehlern
„Agile doesn’t have a brain“ (Bill Scott, Sr. Director of Business Engineering @ PayPal)
Agiles Projektmanagement wurde erdacht, um das Ausliefern von Software effizienter zu gestalten. Es löst das Problem des „Wie“, jedoch beantwortet es nicht das des „Was“. Dies können wir nur verändern, wenn wir darauf achten, dass alles was wir tun uns mehr über unseren Kunden lernen lässt. Teil der Lösung liegt in Techniken wie Design Thinking und Product Discovery. Rainer hat auf diesem Blog schon einige Artikel zu letzterem Thema geschrieben: Product Discovery im Scrum-Alltag und Product Discovery – aber bitte richtig geben spannende Einblicke. Viel wichtiger als Techniken und Methoden ist jedoch das Mindset.
Schon als Kinder werden wir dazu sozialisiert, Fehler zu vermeiden. Es gilt jedoch Fehler sogar zu erzwingen! Wenn wir Fehler machen, lernen wir. Selbstverständlich muss sichergestellt werden, dass das Gelernte wiederum in den Wissenpool einer Organisation übergeht. Fehler sollen natürlich nicht mehrmals gemacht werden und große Erfolge möglichst schnell überall dort eingebaut werden, wo sie Sinn machen.
In seinem Buch „Do It Wrong Quickly: How the web changes the old marketing rules“ beschreibt Mike Moran, dass beispielsweise Netflix erwartet, dass 90%(!) der Dinge welche sie ausprobieren und testen schief gehen. Eine solche Fehlerrate kann auch als Managementtool dienen. Gerade bei sehr iterativem Vorgehen verliert man schnell den Blick für das große Ganze. Man optimiert zu Gunsten eines lokalen Maximums, übersieht dabei aber das Globale. Um sicherzustellen, dass dies nicht geschieht, kann man nun die Fehlerrate im Auge behalten. In dem man zumindest dafür sorgt, dass ein gewisser Anteil „riskanter“ Experimente pro Zeitperiode vorhanden ist, verhindert man ein zu kleinteiliges Denken. Sollte die durchschnittliche Fehlerrate viel zu niedrig sein, könnte dies darauf hindeuten, dass das Team nicht genug Risiken eingeht.
Deadlines
Deadlines können ein tolles Motivationstool sein, nicht jedoch wenn sie, auch nur scheinbar, willkürlich gesetzt werden. Seien wir doch mal ehrlich: Jedes Mal wenn wir eine Deadline setzen passiert Folgendes: Wir verschieben die Deadline oder wir reduzieren den Scope. Dabei ist der Grundgedanke hinter den Deadlines gar nicht mal verkehrt. Es geht doch eigentlich darum, zu einem bestimmten Zeitpunkt ein gewisses Ergebnis zu erreichen. Auf einer Metaebene betrachtet geht es also um die Allokation bestimmter Ressourcen zur Erreichen eines Geschäftsergebnisses.
Aus diesem Betrachtungswinkel lassen sich Deadlines mit allen Lean- und Agile-Ansätzen gut vereinbaren. Sie sind mit dem Funding eines Startups vergleichbar. Warum nicht eine Deadline folgendermaßen nutzen:
Am Anfang eines Quartals gibt es einen klarer Auftrag. Beispiel: „Erhöhen wir den durchschnittlichen Wert des Warenkorbes um 15%“. Nun macht sich das Team auf die Suche nach einer Lösung für dieses Problem. Alle 3 Monate gibt es einen Checkpoint, in welchem das Team seine Ergebnisse, seien es Erfolge oder Niederlagen, präsentiert. Nach einem solchem Meeting können Stakeholder und Senior Management eine Entscheidung treffen. Soll das Team weiter auf diesem Projekt arbeiten? Oder haben sich Prioritäten verändert? Ist dieses Projekt nach wie vor Erfolgsversprechend, oder muss das Team zurück ans Whiteboard?
Der Schlüssel ist die Unternehmenskultur
Ohne eine entsprechende Unternehmenskultur werden all die Punkte oben nicht umgesetzt werden können. Wir alle kennen Unternehmen, in denen sich Mitarbeiter hinter ihrer Rollenbeschreibung verstecken, anderen die Schuld zuschieben. In denen Entwicklungsteams einfach nur ausführen und umsetzen, statt aktiv mitzugestalten. In denen Erfolg definiert ist als das Fertigstellen einer Funktionalität, statt das zentrale Geschäftsmetriken positiv verändert werden oder wir etwas Neues über unsere Kunden gelernt haben. In denen ein Team aus Angst vor Fehlern keine Risiken eingeht. Sie könnten Zeit verlieren, mit ihren Hypothesen komplett falsch liegen, usw. Dieser Herausforderung stehen wir alle gegenüber. Um wettbewerbsfähig zu bleiben müssen wir unsere Unternehmenskulturen verändern:
„You must transform from a culture of delivery to a culture of learning.“ (Jeff Gothelf)
Unternehmenskultur ändern – aber wie?
Am Ende werden sich alle Unternehmen dieser Herausforderung stellen müssen. Warum? Nun, im Jahr 2020 wird laut einer Studie der PricewaterhouseCoopers die globale Arbeitswelt zu 50% aus der sogenannten „Generation Y“ bestehen. Sie sind sozusagen das Negativ des Arbeiterverständnisses von Taylor. Dieser ging davon aus, dass Arbeiter Arbeit meiden, Führung benötigen, sowie Denken und Umsetzen strikt voneinander zu trennen sind. Die Generation Y dagegen ist vernetzt und arbeitet kollaborativ. Kombiniert eine hohe technische Affinität mit guter Ausbildung und einem entsprechend ausgeprägtem Selbstbewusstsein. Statt Seniorität erwarten sie Kompetenz. Sie wünschen sich Autonomie, Verantwortung und eine offene, ehrliche Kommunikation. Unternehmen müssen lernen, ihren Mitarbeitern alle Informationen zur Verfügung zu stellen, die sie benötigen. Nicht nur die, die Ihrer Hierarchiestufe entsprechen. Doch wie verändert man nun eine Kultur? Im Grunde gibt es eigentlich nur eine Möglichkeit. Den Support des Top-Level Managements.
Doch wie erreicht man diesen, wenn die Initiative nicht von dort ausgeht? Eigentlich kann man es nur vorleben. Bildet eine sog. „Kulturzelle“ und lasst eure Erfolge für sich sprechen. Es wird kein leichter Weg. Ihr müsst immer wieder aufzeigen, wie eure Kultur Teil eures Erfolges ist. Transparenz, Kommunikation und Durchhaltevermögen sind hier der Schlüssel.
Natürlich gibt es kein Patentrezept für Produktentwicklung. Auch ist Produktentwicklung nicht die einzige Funktion in einem Unternehmen. Doch wir sollten genug Mut besitzen, diese neuen Vorgehensweisen auszuprobieren und uns Voll und Ganz auf sie einlassen. Wir brauchen ausreichend Selbstreflektion, um Anpassungen an unsere Kultur vorzunehmen, ohne dabei vorschnell in alte Verhaltensweisen zurückzufallen.
So das war es aber jetzt! Wir hoffen, euch beim nächsten ProductTank Hamburg am 27. November begrüßen zu dürfen. Diesmal haben wir Mark von Stuffle und Moritz von Soundclound als Speaker gewinnen können. Tretet einfach unserer Gruppe auf XING bei und bleibt auf dem Laufenden.
Bis dahin – Viel Erfolg mit euren Produkten!
Arne, Marc und Timo
P.S. Für alle, die nicht dabei sein konnten:
- Slides zu Jeffs Vortrag (Slideshare)
- Akustischer Mitschnitt von Jeffs Vortrag von UXHH-Radio
- Slides zu Daniel’s Vortrag (Slideshare)
- Fotos zum ProductTank (Flickr)