Von der Vision bis zum Produkt

Lucas Dohmen: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ-Podcast. Heute haben wir einen Folge zu verschiedenen Methodiken, die wir in der Produktentwicklung nutzen. Dafür habe ich mir zwei Gäste eingeladen: Nico und Roman.

Nicolas Inden: Hallo, Lucas.

Roman Stranghöner: Hi zusammen.

Lucas Dohmen: Nico, magst du eben vorstellen, wer du bist und was du bei INNOQ machst?

Nicolas Inden: Ja, gerne. Ich bin Nico und bin seit November letzten Jahres bei INNOQ als Consultant. Ich helfe hauptsächlich an der Schnittstelle zwischen uns und dem Kunden, bei Fragen, wie z.B.: Wie funktioniert der Prozess der Produktentwicklung? Wie kann man Stories formulieren und Features entwickeln? Ich bin also weniger auf der Entwicklerseite selbst unterwegs, als im “Schmierstoffbereich” zwischen den Teams.

Lucas Dohmen: Super! Und du, Roman?

Roman Stranghöner: Da ich nicht das erste Mal beim Podcast dabei bin, kennen mich einige vielleicht schon. Mein Name ist Roman Stranghöner und ich arbeite seit neun Jahren bei INNOQ als Senior Berater. Mein Fokus liegt dabei auf der Mensch-Maschine-Interaktion bzw. auf der Schnittstelle dazwischen und das in fast allen Bereichen: Von Front-End Technologien über Architektur, User-Experience Design, Produktentwicklungsthemen und Methoden mache ich eigentlich so gut wie alles.

Lucas Dohmen: Unser heutiges Thema ist ebenfalls in beiden Themenfeldern zu Hause. Was ist denn eure Motivation euch mit all diesen Werkzeugen zu beschäftigen?

Nicolas Inden: Wir haben mittlerweile schon einige Projekte gesehen und beobachtet, dass sie an den verschiedensten Punkten einsteigen. Die einen haben erst einmal nur eine Idee und fragen sich, ob das so richtig läuft und wie man die Idee validieren könnte. Andere sind schon viel weiter und stehen davor, die Arbeitspakete zu identifzieren und deren bestmögliche Umsetzung im Team zu verwirklichen. Für all diese Situationen hat sich bei uns ein Werkzeugkasten herauskristallisiert, den wir jetzt gerne einmal vorstellen würden, da wir davon überzeugt sind, dass diese Werkzeuge den Weg nach vorne ganz gut ermöglichen.

Lucas Dohmen: Wir beginnen mit dem ersten Tool, dem “Lean-UX-Canvas”. Roman, magst du erklären, was das ist?

Roman Stranghöner: Ja. Lean-UX-Canvas ist das Destillat aus dem Buch “Lean UX” von Jeff Gothelf. Der Canvas selbst ist von 2017 und wurde von Gothelf als komprimiertes Format zusammengestellt, um alle Themen des Buchs abzudecken. Einige, mich eingeschlossen, sind große Fans von diesem Buch und genau in dieser Zeit sind viele dieser Canvas Methoden aufgekommen, allen voran der “Business-Model-Canvas”. Vor allem in der Projekt-Vorphase ist dieses Format besonders schön, wenn der Kunde noch nicht so viele Dinge vorgedacht hat oder erst einmal nur eine grobe Idee davon hat, wohin er will, aber ganz viele Dinge noch gar nicht so richtig weiß: Weder die einzelnen Nutzergruppen, noch welche Bedürfnisse das Produkt adressieren soll. Wenn es also ganz viele Themen gibt, die noch sehr nebulös sind, eignet sich das Format sehr gut, um verschiedene Themenbereiche komprimiert abzuklappern. Typisch für diese Canvas Methoden ist, dass man auf einem großen Blatt Papier verschiedene Bereiche aufmalt und diese, wie eine Art Agenda, schrittweise durchgeht. Beim Lean-UX-Canvas sind es acht bis neun Schritte und man beginnt mit der Frage danach, welche Geschäftsprobleme es eigentlich im Unternehmen gibt, die einen dazu zwingen aktiv zu werden und irgendeine Art von Produkt auf den Markt zu bringen. Meistens sind es monetäre Gründe oder “Brand-Awareness”. Weiter geht es mit der Analyse der Kundensegmente: Welche Bedürfnisse sind vorhanden und wie will man diese Bedürfnisse adressieren? Welche konkreten Ideen wurden dafür schon gesammelt? Da bricht es ein wenig auf und man überlegt sich Hypothesen in einem sehr definierten Format. Alle diese Dinge werden jeweils in einem Satz zusammengefasst. Diese Hypothesen kann man sich auch wie testbare Statements vorstellen. Test-Driven-Development ist da eine schöne Analogie auf der ich rumreite. Das gibt es auch im Design. Und im Test-Driven-Design ist das das Statement gegen das man prüft und diese Hypothese ist nichts weiter, als eine ausformulierte Annahme in einem bestimmten Format. Die Hypothese formuliert man so, dass man sie mit “Ja” oder “Nein” beantworten kann.

Lucas Dohmen: Kannst du ein Beispiel für so eine Hypothese geben?

Roman Stranghöner: Das könnte so was sein wie: Wir haben nicht genug Umsatz in unserem Webshop. Eine Hypothese wäre: Indem wir unser Kundensegment XY (ohne das Alter des Segemnts jetzt genau zu kennen) in die Lage versetzen, über einen Quickcheckout sofort Dinge zu kaufen, könnten wir das Geschäftsproblem adressieren und dabei Mehrwert für den Kunden schaffen. Der Kunde kann jetzt schneller seinen Einkauf tätigen und uns gleichzeitig hoffentlich dabei helfen, die Kundenakzeptanz zu erhöhen. So etwas in der Art. Wenn die Hypothesen gefunden und schriftlich manifestiert worden sind führt das dazu, dass man sehr schnell merkt, welche Annahmen kritisch sind. Annahmen können bezüglich Zeit, Komplexität und Geld unterschiedlich kritisch sein. Um mit kritischen Dingen nicht auf die Nase zu fallen, sollte man sich überlegen, welche dieser Dinge zuerst validiert werden müssen, bevor man weitermacht. Da setzt auch der Lean-Ansatz an: Möglichst schnell zu lernen und Tests sowie Experimente zu diesen Tests zu entwickeln. Passend zu dem Beispiel mit dem Quickcheckout, könnte man einen Prototypen bauen und diesen mit einem kleinen Kundenkreis bzw. ausgewählten Leuten verproben. Man könnte damit schauen, ob das Feature tatsächlich so funktioniert, wie man sich es vorgestellt hat.

Lucas Dohmen: Dann verlassen wir aber schon das Lean UX-Canvas.

Roman Stranghöner: Genau. Das Canvas endet mit den Experimenten. Also mit den Fragen: Was müssten wir als erstes lernen und wie würden wir es tun? Das wären dann die nächsten Schritte.

Nicolas Inden: Daran schließt sich schon das Thema “Design-Sprint” an. Wenn man aus dem Lean-UX-Canvas mit einer bestätigten Vision herauskommt und weiß, was noch gelernt und getan werden muss, dann kann man sich überlegen, wie es zu manifestieren ist. Dafür gibt es den Design-Sprint, zu dem wir auch schon einmal eine Podcast-Folge gemacht haben, die wir in den Shownotes verlinken. Grob gesagt, geht es im Design-Sprint darum, dass ein kleines Team aus Produktdesigner, Entwickler, Produktowner und jemandem, der engen Kontakt zum Kunden bzw. Endbenutzer hat, zusammensitzt und gemeinsam überlegt, wie das Ganze aussehen kann. Es kann mit einem Papierprototypen anfangen: Man malt mit dem Stift auf Papier und schaut, ob die Schritte zueinander passen. Das Ganze wird dann in der Gruppe weiter evaluiert. Am wertvollsten ist am Design-Sprint, dass am Ende der vier Tage die entstandenen Prototypen, seien es Papier- oder Klickprototypen mit Tools wie Figma oder andere Mockups schon mit Nutzern getestest werden. Mittels Screenshare oder am besten vor Ort. Durch den Design-Sprint bekommt man direkt ein Feedback darüber, ob man als Nutzer versteht, wie das Feauture zu nutzen ist oder was an der ein oder anderen Stelle noch geändert werden muss.

Lucas Dohmen: Könnte man sagen, dass der Lean-UX-Canvas eher das schärft, was man als Unternehmen will und der Design-Sprint das, was die User wollen? Um beides zusammenzubringen?

Roman Stranghöner: Genau. Prinzipiell kann man den Design-Sprint als eine Art Experiment betrachten. Er funktioniert, mit Ausnahme von Meta-Themen, für viele Themen relativ gut: Alles, wo die Mensch-Maschine Interaktion im Vordergrund steht, wo klar definierte Kunden- bzw. Nutzersegmente vorhanden sind. Da lässt sich ein Design-Sprint effektiv nutzen, um Teilbereiche einer größeren Anwendung (oder eine kleine Anwendung komplett) prototypisch zu entwickeln und dabei zu schauen, ob Features so funktionieren wie geplant. Wie gesagt, es handelt sich hierbei nur um ein Werkzeug von vielen, das man an der Stelle nutzen kann, um so eine Hypothese zu validieren.

Lucas Dohmen: Sehr cool!

Nicolas Inden: Wobei man anfügen muss, dass so ein Design-Sprint, unabhängig davon, wie er ausgeht, definitiv wertvoll ist. Es kann z. B. auch herauskommen, dass die Nutzer kommunizieren, dass sie das Produkt nicht verstehen oder dass ihnen das ausgedachte Feature nichts bringt. Beide Richtungen sind im Ergebnis also möglich. Die eine Richtung bedeutet “weitermachen” und die andere hilft dabei, Geld einzusparen und sich etwas Neues auszudenken.

Roman Stranghöner: Damit wird insbesondere der Punkt adressiert, riskante Dinge zuerst zu testen. Wenn man sofort Feedback erlangt, ob das Feature eine “totale Katastrophe” ist, dann ist dieses Feedback natürlich sehr wertvoll. Es kann einen vor großen Fehlern bewahren und unter Umständen auch vor großen Investitionen, die dann vor die Wand gefahren werden würden.

Lucas Dohmen: Sowohl zu Design-Sprints, als auch zu Prototyping haben wir auch schon Folgen aufgenommen. Wer z. B. “Papier- oder Klickprototyp” noch nie gehört hat, kann alles dazu nachhören. Wenn wir uns jetzt weiter durchhangeln, dann hätten wir nun: Eine Vision und einen Prototypen. Wie würde es jetzt weitergehen?

Nicolas Inden: Wenn man dazu noch davon ausgeht, dass dieser Prototyp von den Nutzern bestätigt wurde und alles gut gelaufen ist, dann geht es Richtung Umsetzung. Um dabei strukturiert vorgehen zu können, bietet sich ein “User-Story-Mapping” an. Ein stückweit sind im Prototypen die Schritte, die der Nutzer machen soll, schon enthalten. In einem Story-Mapping beginnt man damit, diese Schritte zu formulieren. Wenn man sich z. B. einen Shop mit einer Shopping-Website vorstellt, möchte man vielleicht die Produkte ansehen, etwas in den Einkaufswagen legen können usw. Das wären typische Schritte, die in einer “User-Journey” auftauchen können. Diese werden erst einmal alle gesammelt und dann wird im Team überlegt, welche Dinge damit zusammenhängen und umgesetzt werden müssen. Typischwerweise werden dabei die Stories auf Post-Its unter die einzelnen Journeyschritte an eine große Wand mit viel Platz geklebt. Je nach Produkt kann das Ganze sogar extrem groß werden. Schön ist daran die Möglichkeit, schon einmal einen Blick darauf werfen zu könnnen, welche Stories wirklich essentiell sind. Das heißt man kann auch eine waagerechte Linie bis zu einen bestimmten Punkt ziehen, der all Stories umreißt, die durchlaufen werden müssen, um einen bestimmten Schritt in der Journey zu erreichen, bevor man überhaupt auf den Markt rausgeht. Alles unter der Linie ist dann Version zwei, drei, vier… Das alles bietet einem das User-Story-Mapping an. Aus meiner eigenen Erfahrung habe ich gemerkt, dass es dem gesamten Team hilft, zu einem Produkt oder Feature dieser Art einer Zusammenstellung von Journeyschritten und Stories zu haben. Es passiert nämlich sehr oft, dass man unter einer Flut von Stories nicht mehr vor und zurück weiß. Dieses Story-Mapping bietet dagegen immer Anhaltspunkte zur Orientierung und ein Ziel.

Lucas Dohmen: Das bedeutet also, dass das User-Story-Mapping schon weit über einen Sprint hinaus geht, also weiter in die Zukunft plant? Also: “Wo wollen wir hin in…?”

Roman Stranghöner: Ja. Im Prinzip hat man immer eine Journey klar vor Augen und das auch immer für einen konkreten Nutzerkreis, der in Form einer Persona schon ausdefiniert ist. So hat man immer einen roten Faden in der Entwicklung: Man weiß, was man baut, für wen und warum. Ist es wirklich das Ziel des Endanwenders, für den ich das hier gerade baue? Das ist also der eine große Vorteil. Ein anderer besteht für mich persönlich darin, dass es, seit ich von dieser Methode gehört habe, für mich undenkbar geworden ist, Backlogs noch anders zu strukturieren. Wir waren in so vielen Projekten, in denen das Backlog nur aus einem Jira mit einem unendlichen Schwall an Tickets bestand, die mit völlig willkürlichen Zahlen gelabelt waren: 8000, 8500, 8999…ich weiß nicht was. Irgendwelche schrägen Zahlen, die Prioritäten abbilden sollten, damit man immerhin noch wusste, welche Tickets nach oben geschoben werden sollten, um den nächsten Sprint vorzubereiten. Da fehlte einfach alles. Man hatte da so einen “flach geklopften Haufen Stories”, die teilweise in keinem Zusammenhang standen. Diese Maps hingegen, wenn sie offen erstellt und öffentlich gehalten werden -wobei “öffentlich” das Team oder Teile des Teams meint, dann kann man sich jederzeit wieder einen Gesamtüberblick verschaffen: Wo sind wir gerade? Warum machen wir das Ganze? Die Priorität wird auch ganz anders wahrgenommen. Die waagerechte Linie, von der schon gesprochen wurde, ist zwar im Podcast schwer zu beschreiben. Wenn man aber diese Map als große Post-It-Wand vor Augen hat, wird am Ende, wenn alle Post-Its mit allen Schritten, Journeys, Tasks und Stories geschrieben sind, diese Linie eingezogen, die dann die Baseline darstelllt. Alles, was an Features oberhalb liegt, ist das Minimalset, was man haben muss, damit diese ganze Journey funktioniert und alles andere zieht man unter die Linie. Und man merkt: Das macht richtig klick! Man kann sehr schnell entscheiden, ob etwas gerade essentiell ist, oder später gemacht werden kann. So bekommt man, sowohl auf Feature-, als auch auf Produktbasis, sehr schnell ein gutes Gefühl für einen MVP, ein “Minimal-Viable-Product”. Da wird dann klar ohne welche Features das Produkt keinen Sinn macht, die Journey nicht erfüllt ist und ohne die der Nutzer nicht an sein Ziel und das Unternehmen nicht an die Lösung der Geschäftsprobleme kommt. Auf dieser Ebene kann man sehr schnell argumentieren und die Wichtigkeit der Dinge entscheiden. Darunter wird es, zugegeben, komplizierter. Man muss sich darüber einigen, was in der nächsten Iteration gemacht wird, Stichwort “Release-Planning”. Das kann man auf dieser Basis aber sehr schön durchführen. Ich finde, es ist ein super Format, um diese Dinge gemeinsam im Team zu entscheiden.

Lucas Dohmen: Ich könnte ja auch erst einmal meine Linie für meinen MVP malen und dann entscheiden, den Rest irgendwann später zu machen.

Nicolas Inden: Das wäre absolut valide.

Roman Stranghöner: Es wächst genauso mit wie alles andere in den Sprints auch.

Nicolas Inden: Wenn man eine frische Story zu einem Feature macht, muss man auch daran denken, dass es eine Menge Zeit und scharfes Nachdenken braucht. Im Rahmen eines größeren Treffens ist es mir selbst schon passiert, so eine Story-Map mit vielen Leuten machen zu wollen und dann hat es nicht geklappt weiter als bis zu einem bestimmten Punkt zu kommen. Danach kam einfach nicht mehr viel. Dafür muss man sich Zeit nehmen und am besten auch ein eingespieltes “Trüppchen” sein.

Roman Stranghöner: Genau. Die Leute, die daran teilnehmen, sollten vorher auf jeden Fall sehr gut kommuniziert sein, denn es ist kein Format für jeden. Obwohl es sehr zugänglich ist, da viel mit Post-Its und Stiften gearbeitet wird. Die Intention ist dabei schon, dass jeder mitmachen kann und sich einbringen soll. Die Hemmschwelle ist durch die Abwesenheit von Tools, die man erst lernen muss, sehr niedrig gehalten. Es stimmt aber, dass eine größere Teilnehmeranzahl auch mehr Output bzw. Post-Its produziert. Dadurch wird das Ganze entweder sehr überladen oder, wenn sich einzelne Personen aus politischen Gründen nicht ganz so gut verstehen und sich deshalb bewusst zurück halten, wird es schwierig den Leuten Dinge “aus der Nase zu ziehen”. Wir versuchen meistens, das Eis zu brechen, in dem wir vorher, am besten sogar einen ganzen Tag vorher, diese Journeys definieren. Ähnlich wie im Design-Sprint erklärt, mit einem ganz einfachen Graphen, Akteuren und einzelnen Schritten in der Journey simpel herzuleiten: Was ist die Journey? Wer sind unsere einzelnen Endanwender und wie stehen sie im Verhältnis zu anderen Personen oder am Prozess beteiligten Stakeholdern? Welche Schritte durchlaufen sie? Wenn man das alles gemeinsam in der Gruppe erarbeitet hat, dann ist das Eis schon etwas gebrochen. Das Ergebnis lässt sich dann als erste Aktivität für das eigentliche User-Story-Mapping verwenden und damit hat man schon einmal das “Backbone” der Map: Die einzelnen Nutzerschritte der Journey. Damit kann man dann schon etwas tiefer reinspringen und ich glaube damit ist dann auch die Hemmschwelle, konkrete Lösungen zu generieren, weg.

Lucas Dohmen: Was auf den einzelnen Post-Its steht, ist aus der Userperspektive, richtig? Also: “Als User möchte ich Folgendes machen könnnen…”-

Nicolas Inden: Damit: Benefit.

Lucas Dohmen: Genau. Die konkrete Umsetzung hat mit dem User-Story-Mapping also noch gar nichts zu tun?

Nicolas Inden: Nein.

Roman Stranghöner: Was man Ende damit erhält ist auch keine komplette User-Story im traditionellen Sinn, denn dazu gehört ja viel mehr als eine Kurzbeschreibung. Ich glaube, zu dem Thema was eine gute User-Story ausmacht, könnten wir auch einmal eine Folge machen. Zu einer kompletten User-Story gehört eigentlich noch die zumindest grobe Beschreibung und erste Wireframes, damit man sich als Entwickler später gut vorstellen kann, wie das Ganze aussehen soll, was man implementieren soll. Außerdem gehören noch Akzeptanzkriterien und ein ganzer Schwall anderer Dinge dazu. Ich glaube, eine perfekte Definition kann man nicht aufstellen, da es für jeden subjektiv noch etwas anders ist. Man braucht aber schon ein gewisses Grundset an Dingen, um mit der Entwicklung starten zu können und um zu wissen, was denn eigentlich gebaut werden muss. Das alles erhält man mit diesem Format des Story-Mappings natürlich noch nicht. Was man erhält, ist nicht mehr als die Post-Its, auf denen maximal ein, wie ich es nenne, “Rumpf” einer Story steht: “Als Nutzer möchte ich … damit ich …, weil so und so.” Dieser eine Satz und mehr nicht.

Nicolas Inden: Wenn man Glück hat, stehen dort auch noch ein oder zwei Akzeptanzkriterien, wenn sie einem gerade an der Stelle einfallen.

Roman Stranghöner: Genau, ja. Auf Basis dieser Rümpfe wäre danach eine Folgeaktivität: Die einzelnen Stories mit dem, was man für die weitere Entwicklung braucht, andicken. Und, da bin ich ganz ehrlich, das muss das Team für sich selbst entscheiden. Eigenlich sollte zwischen PO und Team sehr klar sein, was in so einer Story enthalten sein muss, damit man sie auch wirklich bearbeiten kann. Und das kann total unterschiedlich sein.

Nicolas Inden: Im Prinzip wäre das auch schon das nächste Glied in der Kette bzw. das nächste Werkzeug: Refinement. Man setzt sich mit allen zusammen und überlegt, wie man das Ganze umsetzen kann. Bis zu diesem Zeitpunkt hat man nämlich noch gar nicht über das “Wie” gesprochen: Was sind die technischen Anforderungen? Was muss man vorher realisiert haben, damit man das Feature umsetzen kann? Refinement ist der nächste Schritt, in dem diese Fragen dran kommen.

Lucas Dohmen: Ist es die gleiche Art von Refinement, wie man sie aus agilen Werkzeugen kennt oder ist es eine andere Art?

Roman Stranghöner: Joa. Ich würde schon sagen, dass die Aktivitäten dazu führen, einer noch nicht so konkret formulierten Story etwas mehr Information hinzuzufügen, damit das Entwicklungsteam die Aufgaben, die hinter der Story stecken, in Time und Budget vernünftig lösen kann. Es handelt sich dabei nicht um eine einmalige Aktivität. Zwar wird im Vorfeld eines Projekts für die ersten ein bis zwei Sprints vorgearbeitet, damit man für die erste Iteration schon etwas hat, das man picken kann. Aber Storyentwicklung ist etwas, was auch danach kontinuierlich weiter getan werden muss und dann ist es mit Sicherheit so etwas wie ein Refinement. Im Wesentlichen würde ich die Ausgangsfrage also mit einem “Ja” beantworten.

Lucas Dohmen: Heißt das also, dass die Schritte für einen oder vielleicht zwei Sprints konkretisiert werden? Oder wie sieht das aus?

Nicolas Inden: Das hängt von der Komplexität ab. Erst einmal wird geschaut, dass genug vorhanden ist, um mit einem Sprint anfangen zu können. Gewöhnlich ist der Fall, dass man sich innerhalb eines Sprints schon Gedanken über die nächsten Dinge machen muss. Refinement ist ja nichts, was man einmal macht und dann ist für alle Stellen klar, wie es funktioniert und alle sind glücklich. Stattdessen muss man immer wieder zusammen darauf gucken. Gerade weil sich zwischendurch Dinge auch ändern, gerade weil man durch “Product-Discovery” erfahren hat, dass etwas anders gemacht werden soll.

Lucas Dohmen: Es bedeutet also, dass man in einen iterativen Prozess übergeht und auch das MVP nicht “durchrefined” wird, sondern dass man mit einem oder zwei Sprints startet.

Roman Stranghöner: Wenn man sich vorstellt, dass man für eine wirklich gute und aussagekräftige User-Story schon Aufwand betreiben muss mittels Wireframing oder dass sich drei bis vier Leute zusammenschließen, um erst einmal über die Fachlichkeit zu reden. Dabei geht schon etwas Zeit ins Land und das sind Aufwände, für die unter dem eigentlichen Sprint, in dem etwas entwickelt wird, Kapazitäten eingeplant werden müssen. Ich persönlich glaube nicht daran, dass man ein gesamtes Produkt einmal komplett vorbereiten kann und es dann nur noch abarbeitet. Wie auch eben schon gesagt wurde, lernen wir ja auch während des Sprints hoffentlich durch Nutzertests oder Feedback aus den Fachbereichen, ob die Dinge, die wir bauen, auch funktionieren oder nicht. Das schnelle Feedback, das wir über unsere Arbeit bekommen, beeinflusst natürlich maßgeblich alles, was man für die Zukunft bereits geplant hat. Wenn man beispielsweise das erste Feature aus einer Kette von Features umsetzt und sich dabei herausstellt, dass es nicht gut funktioniert, dann hätte man sich die Umwandlung der anderen Features in Storys inklusive Ausarbeitung komplett sparen können. Ich glaube schon, dass man ganz gut damit fährt, nur die nächsten ein bis zwei Sprints, die ja auch unterschiedlich lang angesetzt sein könnnen, im entsprechenden Detailgrad auszuarbeiten, sodass das Team in der nächsten Iteration die Möglichkeit hat, die Dinge herauszuziehen, die wirklich Sinn ergeben.

Lucas Dohmen: In welchem Personenkreis macht man das dann im Sprint?

Nicolas Inden: Also beim Refinement sollten auf jeden Fall der PO und das Entwicklerteam dabei sein. Wenn man ihn als separate Rolle betrachtet, also nicht als Teil des Entwicklerteams, dann würde ich auch den Produktdesigner mit dazuholen. Damit hat man alle, die man braucht. Der PO kann entscheiden, ob die besprochenen Änderungen aus Nutzersicht sinnvoll sind. Die Entwicklerseite muss die Informationen vom PO bekommen und auch verstehen, das heißt: Was ist gewollt und was ist gemeint?

Roman Stranghöner: An der Stelle kann man auch hinzufügen, dass wir große Fans interdisziplinärer Entwicklerteams sind. Das heißt nicht nur zu programmieren, sondern auch konzeptuelle Arbeit auf UX-Ebene, also visuelle Designarbeit. All diese Dinge gehören für uns in einem Team dazu.

Lucas Dohmen: Im Gegensatz zu den anderen Methoden, die wir bereits besprochen haben, sind beim Refinement also keine User-Gruppen mehr dabei, sondern eher das Team?

Roman Stranghöner: Ja, das ist auf jeden Fall Teamaufgabe.

Nicolas Inden: Geanu. Damit sind wir auch schon im iterativen Zyklus drin. Das nächste Feedback hätte man dann im Review zur Seite, was man der Stelle weiterverwenden und worauf man reagieren kann.

Lucas Dohmen: Da wir gerade schon beim Team sind: Der letzte Baustein ist ja das “Team-Building”. Was habt ihr euch darunter vorgestellt?

Nicolas Inden: Team-Building ist ganz klassisch, kein Werkzeug an sich. Es lässt sich aber ganz gut mit “Socialising” beschreiben, glaube ich. Auf der einen Seite, wenn man es in Verbindung mit den anderen Bausteinen setzt, hatte man bisher nie den Punkt, an dem alle beteiligten Personen an einem Tisch gesessen haben, sondern immer nur eine Teilmenge davon. An dieser Stelle geht es aber darum, dass wirklich alle auf Stand gebracht werden: Wo wollen wir hin? Was ist die Mission? Es hat sich gezeigt, dass es sehr wertvoll ist, wenn man im Team zusammengesessen und auch vielleicht mal über nicht-technische Dinge geredet hat. Wenn man sich untereinander kennt. Das Gemeinschaftsgefühl zu stärken und gemeinsam an etwas zu arbeiten, das ist der Sinn dahinter.

Lucas Dohmen: Gerade als Consultant kommt man von außen herein und muss erst einmal zu einem Team werden.

Nicolas Inden: Richtig.

Roman Stranghöner: Absolut. Ich halte Team-Building auch gerade dann für noch wichtiger, wenn Teile des Teams später remote arbeiten.

Nicolas Inden: Absolut.

Roman Stranghöner: Im Idealfall, und das funktioniert sehr gut, sitzt das Team immer zusammen, aber das ist aus Gründen nicht immer gegeben. Insbesondere dann finde ich es sehr hilfreich, wenn man sich in so einem Team vorher von Angesicht zu Angesicht kennengelernt hat und weiß, wie man welche Person zu verstehen hat. Es gibt viele Dinge, die über remote Tools, z. B. Slack oder andere digitale Kanäle, passieren, die man dann ganz anders aufzunehmen weiß. Ich finde es unersetzlich, wenn man sich in einem Projekt, das später remote ablaufen soll, vorher kennengelernt hat und eine gemeinsame Arbeitsgrundlage geschaffen hat. In Form von z. B. banalen Dingen, wie Einigung über Code-Conventions bis hin zum menschlichen Miteinander, ähnlich einem Code-of-Conduct. Oder im agilen Sinne die “Definiton-of-Done” aufzusetzen. Auch der soziale Aspekt, abends zusammen einmal ein Glas Wein zu trinken oder Essen zu gehen. All diese Dinge gehören für mich zu einem guten Team-Building dazu. Die Chemie, die da entsteht, ist eine viel angenehmere und es ist mehr Miteinander drin, als wenn alles “zusammengewürfelt” wurde. Da schaukeln sich eher Dinge hoch, weil man sich nicht kennt und es gibt diese Unstimmigkeiten, die schwierig wieder auszubügeln sind, wenn man sich nur alle zwei Wochen zu Sprint-Meetings trifft. Ich finde, man kann schon am Anfang proaktiv viele Dinge in die richtige Richtung lenken und zwar durch ein paar kleine Dinge, wie ein gemeinsames Treffen für zwei Wochen oder einen Sprint, komplett vor Ort und dann erst remote. Da gibt es von-bis relativ viele Formate, in denen man so etwas zusammen erarbeiten kann. Gerade in der Projektvorphase.

Lucas Dohmen: An dieser Stelle möchte ich hervorheben, dass allen diesen Dingen gemeinsam ist, dass man sie auch immer mal wieder einsetzen kann und zwar im gesamten Projektverlauf. Bisher klang es zwar nach einer Abfolge, aber es ist nicht so, dass der erste Baustein einmal an Tag eins eingesetzt wird usw.

Roman Stranghöner: Unbedingt. Du hattest es anfangs unseren “Fahrplan” oder “Bauplan” genannt. Das klingt jetzt etwas “wasserfallmäßig”: “Wir machen das jetzt alles einmal vorab vor dem Projekt und dann ist das Team gesettelt und dann geht’s los und es wird nur noch gebaut!” Genau das ist nicht unsere Intention. Wir möchten all diese Bausteine kontinuierlich weiter verwenden. Team-Building braucht man vielleicht nicht wieder und wieder, sobald es einmal läuft. Höchstens beim On- oder Offboarding von Teammitgliedern. Die anderen Formate von Lean-UX-Canavs zu User-Story-Mapping, bis hin zu Design-Sprints dienen dem kontinuierlichen Lernen und Neuausrichten unserer Entwicklung. Daher müssen diese Dinge auch parallel zur Entwicklung selbst in Iterationen weitergeführt werden. Meist auch etwas phasenversetzt, z. B. mit etwas Konzeptarbeit im Voraus. Deshalb bietet sich die Vorphase eines Projekts gut an und von dort aus steigt man in die Entwicklung ein. Alles andere läuft dann phasenversetzt, parallel zur Entwicklung, weiter, sodass man immer beide Tracks hat: Continuous-Development und Continuous-Discovery, wie wir sie nennnen.

Lucas Dohmen: Ich danke euch beiden für diese ausführliche Vorstellung.

Roman Stranghöner: Sehr gerne!

Nicolas Inden: Gerne, danke dir!

Lucas Dohmen: Den Hörerinnen und Hörern: Bis zum nächsten Mal!

Roman Stranghöner: Bis zum nächsten Mal.

Alle: Tschüss.