Designer

Developer

Workflow

in lean/agiler Umgebung

Designer

Developer

Workflow

in lean/agiler Umgebung

Artikel

10 Minuten Lesezeit

Divider

Einleitung

Um es gleich vorweg zu sagen: User Experience (UX) Design hat nicht den einen Workflow, der jedes Mal unverändert abgearbeitet werden kann [1]. One-Size-Fits-All-Praktiken und -Prozesse funktionieren nicht, genauso wie es keinen Königsweg gibt, der mustergültig von der Idee zum Markterfolg führt [B6:136]. Die Ansätze für lean im UX Design variieren und sind im agilen Umfeld mit Herausforderungen verbunden [5]. Deswegen kann dieser Artikel auch nur eine Perspektive sein, die zusammenführt, worauf UX-Designer und UI-Developer bei ihrer Zusammenarbeit achten können.

Divider

Was ist ein
Design-Developer Workflow?

Ein Workflow setzt Richtlinien und Vorgaben, gibt Tipps und Hilfe [ES6], läuft immer ähnlich ab und wird subsequent optimiert [ES10]. Ein Design-Developer Workflow unterstützt den Transfer von UX-Anwendungskonzepten in die Umsetzung [ES10]. Hilfreiche Workflows haben in der Praxis Slack, also Spiel. Prozessregeln dürfen nicht zu strikt sein, sondern müssen sich stets dem angestrebten Produkt unterordnen [B6:114]. Designer und Developer arbeiten zusammen effizient und erfolgreich, wenn sie ein gemeinsames Vokabular nutzen, eine Reihe von Grundsätzen teilen und gemeinsame Arbeitsschritte etablieren [abgeleitet aus 12]. Dazu gleich mehr. Kurzum: Ein Design-Developer Workflow in lean/agiler Arbeitsumgebung fördert die Zusammenarbeit und pflegt Gemeinsamkeiten.

Divider

Warum lean und agil?

In einer idealen Welt sind Wasserfallprojekte die effektivste Lösung. Auch in der realen Welt können Wasserfallprojekte noch  gut funktionieren, wenn das Projekt klein und gut definiert ist. Aber: Benutzerbedürfnisse, das technische Umfeld und die Geschäftsanforderungen sind dynamisch und ändern sich fortlaufend [1]. Um dem kontinuierlichen Wandel in der Entwicklung von Software zu berücksichtigen, hat sich als Gegenstück zum linearen Wasserfall die agile Entwicklung etabliert. Agil ist eine iterative Management-Methode zum Entwickeln von Software und legt eine starken Fokus auf Prozess- und Teamrituale [1]. Im Mittelpunkt des agilen Prozesses stehen User Stories [7]. Agil ist gut darin Arbeit zu managen, um „lauffähigen Code“ zu liefern. Doch Agil hilft nicht sicherzustellen, dass das Richtige gebaut oder das richtige Problem gelöst wird. Das „Gehirn“ im agilen Prozess kann die Lean-Methode sein. Der Kern von Lean ist die hypothesenbasierte Entwicklung [12]. Es folgt der Annahme, dass das erste, was wir entwerfen, fehlerhaft ist. Ziel von Lean ist es, etwas so schnell wie möglich zu schaffen, um es testen und messen zu können und damit die Probleme so schnell und kostengünstig wie möglich anzugehen [1]. Agil basiert auf Anforderungen, lean auf Annahmen.

Proj_CMarschner_DesignDeveloperWorkflow_LeanAgileWaterfall
Divider

Wie können lean und agil in einem Projekt zusammenwirken?

Die erste Phase des Projekts besteht in der Erforschung von Problemen, die gelöst werden müssen. Die Forschung wird als Problembeschreibung aggregiert und dient zur Identifikation von Potentialfeldern möglicher Lösungsvorschläge. Sowohl die Probleme als auch die Lösungsvorschläge basieren auf einer Reihe von Annahmen. Diese erste Phase sollte als Sprint 0 stattfinden, hier werden zentrale Designideen für das Projekt aufgestellt. Das Development ist hier mindestens als Sparing verfügbar [ES6+10]. Der Sprint 0 gibt dem Development damit eine Art von Bemessungsgrundlage für das Projekt vor. Sind die Annahmen identifiziert, können sie hinterfragt werden, indem sie als überprüfbare Hypothesen formuliert werden.  Liegen die Hypothesen priorisiert vor, kann damit der agile Zyklus gestartet werden [12]. In Folge sollte fortlaufend genug Design erstellt werden, um das Team in Bewegung zu halten, aber nicht zu weit voraus. Ergebnisse des Designs wie Wireframes und visuelle Designressourcen sollte etwa auf zwei Sprints im Voraus geplant werden, um die Zeitachse des Designs mit dem Sprintplan des Development in Einklang zu bringen. Der zweite Sprint hilft, um Design-Ergebnisse zu überprüfen und Stakeholder-Genehmigungen zu erhalten. Developer sind stets bei der Überprüfung der UX-Ergebnisse beteiligt. Anzustreben ist ein Co-Design von Designer und Developer: Wenn dies geschieht, können Skizzen als Wireframes übergeben, da alle Teammitglieder die Interaktionen bereits verstehen.

Was sind die Knackpunkte in der Zusammenarbeit?

Proj_CMarschner_DesignDeveloperWorkflow_Handover

Der neuralgische Punkt ist die Design-Development Übergabe - in beide Richtungen.
Vom Design ausgehend: Wie bekommt das Development die Informationen, um alles umzusetzen? Vom Development ausgehend: Wie kann eine Umsetzung sichergestellt werden, dass sie den UX-Anwendungskonzepten entspricht? [ES5]

Proj_CMarschner_DesignDeveloperWorkflow_Zusammenarbeit1_Motiviert
Proj_CMarschner_DesignDeveloperWorkflow_Zusammenarbeit1_Frustriert

Was sind die Grundsätze der Zusammenarbeit?

Proj_CMarschner_DesignDeveloperWorkflow_Communication
Divider

Ein Team

Das Team ist der kritischste Part in der Entwicklung von herausragenden digitalen Produkten. Mit falscher Besetzung braucht man erst gar nicht zu starten [B6:114]. Es gibt kein Developer- oder Designerteam sondern nur ein Projektteam. Ein Projektteam besteht mindestens aus Designer, Developer und Projekt Manager [B3:45]. Niemand weiß alles, Teammitglieder mit einem guten und breiten Skillset ergänzen einander [B5:220]. Es bedarf aber eines Gesamtprojektleiters im Team. Einerseits für übergeordnete Themen (Stichwort: „managing up and out“), denn mit der Freiheit die eigene Projekt-Agenda zu setzen, geht die Verantwortung einher die Agenda proaktiv zu kommunizieren [B2:120]. Anderseits als Entscheider, denn zögerliche Entscheidungen sind Energiefresser. Wenn das Team in langen Diskussionen steckt, sollte der Entscheider ein abschließendes Machtwort sprechen [B5]. Dem Projektteam sind alle Stakeholder bekannt.

Divider

Vereinbarte Regeln

Gemeinsame Regeln definieren klar und detailiert die Eckpfeiler der Zusammenarbeit [ES11]. Gerade im Projektauftakt (häufig in den ersten zwei Monaten) unterstützen vereinbarte Regeln maßgeblich die Orientierung in der Zusammenarbeit. Zu regeln sind von Anfang an im Team die Rollen und Verantwortlichkeiten, der Prozess und Vorgehen, der Arbeitsmodus (Meetings, Absprachen, etc.), gemeinsame Tools und woran der Erfolg gemessen wird. Im Projektverlauf werden diese Regeln fortlaufend hinterfragt und feinjustiert.

Rollen und Verantwortlichkeiten bedeutet: Wann ist wer in der Verantwortung, was zu tun? Aufgaben werden stets klar dezidierten Teammitglieder zugewiesen [ES5].

Prozess und Vorgehen heißt alle Teammitglieder nehmen an Kickoff und Planung teil und kennen den Routenplan. Zur Routen gehören nach der Lean-Methode [ES2]:

  1. Das Scoping mit Problem Statement, destillierten risikoreichen Annahmen, Proto-Persona, Research-Plan;
  2. Die Inspiration mit As-is-Scenario, Best Practice und der Recherche nach Beispielen mit Fokus auf Top-Lösungen;
  3. Die Synthese und Ideation mit Insight Statements, Potentialfelder, „How might we…?“-Fragen 
  4. Das Konzept & Prototyping, indem Soll-Szenarien definiert und User Journey beschrieben werden, daraus Annahmen abgeleitet und die kritischsten davon in einen Testplan überführt werden, um sie mit Prototypen zu überprüfen.

Der Arbeitsmodus organisiert die Kommunikation im Team. Es sollten regelmäßige Dialogzeiten eingeplant werden, um Arbeitszeiten zu strukturieren [ES2]. Es ist zu klären wie Aufgaben/Tasks, Reviews und Abnahmen strukturiert sind. Beispielsweise können für Development-Task (z.B. in Git) Beschreibungsstrukturen vereinbart werden, genauso wie für Design Reviews die Struktur, Dokumentation, Frequenz und Nachverfolgung relevant sind. Retrospektiven werden zudem früh und regelmäßig vorgemerkt, um die Zusammenarbeit zu prüfen und ggfs. gegenzusteuern. (Mehr dazu im folgenden Abschnitt: Gemeinsame Team Events)

Tools klärt: Welche Arbeitsplattformen werden für den Austausch genutzt? (Mehr dazu im Abschnitt: kollaborative Tools)

Erfolgsmessung definiert für das Team, an welchen KPIs (Key Performance Indicators) der Projekt- und Teamerfolg gemessen wird.

Gemeinsam vereinbarte Regeln schaffen Klarheit über Verantwortlichkeit, Kommunikationskanäle, Strukturen und Vorgehen, als auch den Datenaustausch.
Die Regeln werden mit allen im Team abgesprochen, schriftlich fixiert und sind für alle einfach verfügbar zu halten [ES11].

Divider

Gemeinsame
Team-Events

Team Events helfen eine standardisierte Arbeitsweise zu etablieren und tägliche Routine aufzubauen. Beides gewährleistet eine größere Konsistenz, Klarheit und Kohäsion in der Zusammenarbeit. Zu den Team Events können zählen: tägliche Standups, gemeinsame Arbeitsplanung, regelmäßige Reviews, Präsentationen und Retrospektiven sowie ein fortlaufendes Anforderungsmanagement. [BS1:61]

Standups finden im Projektteam täglich statt und dauern ca. 15 Minuten. Die Treffen dienen dem gemeinsamen Projektaustausch, vermeiden Wildwuchs und forcieren wiederverwendbare  Entwicklungsleistung, auch hilft es das Kommunikationsrauschen im agilen Umfeld zu kanalisieren. Tägliche Standups setzen auch tägliche Arbeit am Projekt voraus.

Die Arbeitsplanung erfolgt zusammen im Projektteam, um die zu bearbeitenden Aufgaben zu organisieren. Dafür ist ein Termin ca. alle zwei bis vier Wochen regelmäßig eingeplant und dauert ca. zwei Stunden je gemeinsamer Woche Arbeit. Die Arbeitsplanung ist dem Projektteam in einer einfach verfügbaren Form bereitzustellen (z.B. als Wandkarten, Online-Board oder Summary-Mail).

Reviews erfolgen wöchentlich im Projektteam und sind eine kritische Überprüfung des Arbeitsfortschritt im Detail. Reviews folgen einem strukturierten Aufbau und werden auch so dokumentiert. Wöchentlich Reviews dauern ca. ein bis zwei Stunden.

In der Präsentation werden die erreichten Ergebnisse dem  Projektteam und allen Stakeholdern vorgestellt. Eine Präsentation erfolgt etwa monatlich und dauert ca. eine Stunde je geleisteter Woche Arbeit.

Retrospektiven finden regelmäßig im gesamten Projektteam statt, um die Zusammenarbeit und vereinbarte Regeln zu optimieren. Retrospektiven werden typischerweise nach einer ‚Präsentation‘ eingeplant und dauern ca. 30-45 Minuten je gemeinsamer Woche Arbeit. (Mehr dazu im Abschnitt: Retrospektiven)

Anforderungsmanagement findet kontinuierlich zwischen dem Entscheider im Projektteam und den Stakeholdern statt. Hilfreich kann hier auch eine User Story Map als Produktvision sein. Die Vision sollte regelmäßig im Team hochgehalten werden, weil durch das schrittweise arbeiten, schnell das große Gesamtbild verloren werden kann.

Regelmäßig, strukturierte Team Events organisieren die Zeit zum kommunizieren, minimieren Planungsaufwände und schaffen Zeiträume, um kreativ zu sein und coden zu können.

Divider

Kollaborative Tools

Einen entscheidenden Teil effektiver Zusammenarbeit machen die richtigen Tools aus. Adäquate Tools dienen der Zusammenarbeit und behindern sie nicht. Cloudbasierte Lösungen bieten sich dafür an. Zu einem kollaborativen Toolset gehören:

  • Real-Time Messaging mit einem dezidierten Projektchannel für eine schnelle, transparente und bezogene Kommunikation im Team.
  • Issue Tracking
  • Projektmanagement
  • Dokumentation
  • Offenes File-Sharing System für alle Teammitglieder, um sowohl Files beziehen als auch bereitstellen zu können.
  • Designtools, die für schnelle und flexible Rohlösungen geeignet sind. [B5:225]
  • Dev-Plattform, die Reviewsets gemäß den vereinbarten Regeln im Datenaustausch bereitstellt.
Divider

Geteilte Vision

Das Team fokussiert darauf, was einen Wert für den Kunden schafft. In einer gemeinsamen Produktvision formuliert es, was dieser ist [B1:56]. Eine User Story Map kann hier dienlich sein. Ohne eine klare Vision kann ein agiles Projekt schnell zu einer inkohärenten Sammlung von Funktionen werden, die ausschließlich von den priorisierten User Stories für jeden Sprint bestimmt werden [7]. Das Team sollte sich auf die Ergebnisse konzentrieren - also die Änderungen des Benutzerverhaltens, die sie sehen möchten - und nicht auf bestimmte Funktionen/Features [12].

Divider

Räumliche Nähe

Die räumliche Nähe des Projektteams ist kritisch und extrem wichtig bei lean/agilen Projekten – schon zwei Räume weiter kann problematisch sein [ES3]. Passende Räumlichkeiten haben kurze Wege, bieten Teamflächen für die Abstimmung und Ideation und stellen flexible Arbeitsplätze für das Design, Development oder gemeinsame Pairing-Sessions. Kurzum: Co-location wann immer möglich.

Divider

Schnelle Verfügbarkeit

Schnelle Verfügbarkeit umfasst die beteiligten Menschen, ihre Zeit und die gemeinsame Informationen.

  1. Bezogen auf die beteiligten Menschen ist Vorortpräsenz die beste Voraussetzung für eine schnelle Verfügbarkeit.
  2. Eine schnelle Verfügbarkeit erfordert zeitlich eine Ressourcenplanung die einerseits stets ausreichend Design Support für das Development berücksichtigt und anderseits anerkennt das Agilität heißt: 100% da zu sein für das Projekt und Team (bereits 80% reichen mitunter nicht aus) [ES5+9+10].
  3. Informationen und Dokumentation müssen für jeden im Team schnell verfügbar sein, das heißt: Leicht zu finden, einfach zu verteilen, einfach zu suchen und einfach zu benutzen [B2:48ff].
Divider

Gemeinsame Sprache

Für eine gemeinsame Sprache sollte wann immer möglich  Face2Face, mit Bildern und Prototypen kommuniziert werden [2]. Im Team sollte zudem auf eine konsistente Sprache geachtet werden, indem z.B. gleiche Maßeinheit, einheitliche Farbvariablen und vereinbarte Benennungskonventionen eingehalten werden [10]. Jedoch: Eine pauschale gemeinsame Sprache gibt es nicht. Ein Team braucht zusammen Zeit, um Fragen und Antworten in ihrer gemeinsamen Sprache formulieren zu können [ES9].

Divider

Gemeinsames Verständnis

Ein Projektteam sollte teilen, was es weiß, zusammen lernen, um damit als Team zu wachsen [1]. Ein gemeisames Verständnis setzt voraus, das allen die gleiche Information zugänglich ist und daran teilhaben. Für das Development heißt das, es sollte auch bereits im Sprint 0 als Sparing-Partner dabei sein, damit Produktideen bekannt sind, ein Design-Sparing frühestmöglich auf technische Machbarkeit erfolgen kann und fortlaufend ohne umfangreiches Briefing möglich ist. Für Projektinhalte empfiehlt sich dafür direkt von Projektbeginn ein zentrales, live Dokumentationssystem zu pflegen und hier die Informationen kompakt und konsolidiert zusammenzufassen und in Folge sukzessive zu erweitern (an Stelle eines umfangreichen Sets von Einzeldokumenten).

Proj_CMarschner_DesignDeveloperWorkflow_ChatQuote-1

Geschwindigkeit geht vor Ästhetik [B2:116] und ist insbesondere dem Designern immer wieder aufzuzeigen. Die Artefakte des Designs zeichnen detaillierte Entwurfsentscheidungen für die Interaktion auf, um ein klares Verständnis unter den Teammitgliedern sicherzustellen [7]. Das Development sollte sehen, was sie bauen, bevor sie es bauen müssen. Personas und Journey Maps sind nur zwei der beliebtesten Möglichkeiten, um die Design-Forschung zu destillieren [3]. Interaktive Prototypen bilden eine verlässliche Grundlage für das gemeinsame Verständnis im Team. Die Ausarbeitung zum Prototyp sollte so detailgenau wie nötig sein für die gewünschten Erkenntnisse, aber nicht perfektioniert werden [B5: 226]. Je mehr Zeit darauf investiert wird, um so geringer wird die Veränderungsbereitschaft.

Proj_CMarschner_DesignDeveloperWorkflow_ChatQuote-2

Ein interaktiver Prototyp sollte aber nicht die alleinige Dokumentation sein. Pragmatisch zusammenfassende Screencasts oder auch Interaktionsflowcharts unterstützen eine leichtgewichtige Dokumentation. Die Flowcharts können auf Skizze, Wireframes oder visuellen Screendesigns beruhen, abhängig vom Entwicklungsstands des Projekts. Hilfreich ist, wenn sie nicht nur visuellen Ansichten verbinden, sondern auch textuell annotiert sind hinsichtlich: Trigger, Systemfeedback und Regeln.

Für ein gemeinsames Verständnis haben sich auch Pairing-Sessions bewährt und sollte dafür in der Projektarbeit berücksichtigt werden, so dass Developer und Designer regelmäßig Seite an Seite arbeiten. Die Zusammenarbeit fördert das gemeinsame Verständnis vom Developer im UX und führt den Designer in die Entwicklung.

Divider

Wohlwollende Kultur und Haltung

Menschen wollen glücklich sein [B4:145]. Glücklichkeit, die aus einer aktiven erfüllten Beschäftigung resultiert. Leistung ist tief verwurzelt in Freude [B4:147].

Proj_CMarschner_DesignDeveloperWorkflow_ChatQuote-3

Offen und neugierig auf Neues, ständige Bereitschaft zu lernen, kommunikativ und emphatisch, Mut zu scheitern sind nur einige Merkmale für eine gelungene Team-Kultur. Sympathie im Team ist dafür enorm wichtig [ES7+9]. Empathisch gegenüber dem „anderen“ ist nötig für eine erfolgreiche Zusammenarbeit [ES9]. Um den Teamspirit zu frönen und den Drive zu halten, darf Fortschritt gefeiert werden, wird alles dafür sichtbar gemacht und auch Eigenheiten im Team werden kultiviert (z.B. „Happy Socks Day“). Über Retrospektiven und Feedback-Gespräche können Probleme und Spannungen frühzeitig erkannt und angegangen werden. Ein jeder im Team ist verantwortlich eine wohlwollende Haltung und achtsame Sprache vorzuleben, um eine produktive Zusammenarbeit zu ermöglichen. Diese Verantwortung sollte offen kommuniziert werden.

Divider

Radikale Transparenz

Anzustreben ist eine „pflegeleichte“ Transparenz hinsichtlich der anstehenden Arbeit und Aufgaben, Tools, Aufwände, Ideen, Ziele und Erfolg, für die Kommunikation und Verfügbarkeit.

Arbeit, die visualisiert wird, ist die Arbeit, die erledigt wird. Deswegen sollte Platz geschaffen werden, um Arbeit dauerhaft im Umfeld sichtbar zu haben und über das Projekt sichtbar zu behalten [B2:113].

Proj_CMarschner_DesignDeveloperWorkflow_ChatQuote-4

Ein kollaboratives Toolset ist offen für das gesamte Projektteam (auch für den Kunden des Projekts). Das Toolset sollte dabei möglichst schlank sein, um die Pflegeaufwände zu minimieren. Über wöchentliche Summary Mails, Wandkarten oder Online Boards können Aufgaben für die Teammitglieder gebündelt werden, ein Projektchannel hilft die Kommunikation sichtbar und nachvollziehbar halten. Ein Abschätzen von Zeitaufwänden (z.B. für Git Tasks) ist für Planung und Terminierung förderlich [ES10]. Dem Projektteam muss dabei klar sein, wie Erfolg aussieht und woran er gemessen wird. Die Erfolgsmessdaten sollten an öffentlichen Orten angezeigt werden, und zeigen, wie Fortschritte gegenüber den Kennzahlen erzielt wird [B3:53]. Eine Sichtbarkeit über Projektgrenzen hinaus kann dabei Austausch fördern und Motivation schaffen.

Divider

Gemeinsame Validierung

Das Überspringen von User Research und Validierung ist äußerst riskant, denn selbst die besten Designideen sind nur Annahmen [8]. Deswegen sollten im Projekt die Annahmen explizit aufgedeckt werden. Um eine validierte Designausarbeitung mit einem fortlaufenden Development in Einklang zu bringen, sollten nur die riskantesten oder kritischsten Annahmen so früh wie möglich getestet werden [12]. Grundlage dafür kann das Backlog sein, indem jedes Teammitglied für die Inhalte das wahrgenommene Risiko und den wahrgenommenen Wert einschätzt [B3:40].

Proj_CMarschner_DesignDeveloperWorkflow_ChatQuote-5

Die Testumgebung für eine Validierung sollte möglichst einfach gehalten werden [B2: 78ff]. Hierfür gilt: Besser wenige und leichtgewichtige Tests, dafür aber häufiger. Fünf Interviews ist die magische Zahl. Die Anzahl ist ausreichend und hilfreich um Muster zu erkennen [B5:235]. Das ermöglicht zu lernen und darauf basierend den nächsten Test zu machen [B3:43]. Einhergehend damit einen Probanden-Pool aufzubauen, ist zweckdienlich für fortlaufende Validierungsschleifen [ES4].

Wer sollte beim Test zuschauen? Im Ideal: Das ganze Team! Testen und Validierung sollte eine Gruppenaktivität sein. Die Beobachtung der Tests, die Aufnahme des Feedbacks, das Reagieren in Echtzeit erfordert in Summe weniger Nachbesprechungen [B2:78ff].

Divider

Regelmäßige Reflexion

Gemeinsame Retrospektiven hinterfragen immer wieder, was wichtig und nötig in der Zusammenarbeit ist. Diese Art der Reflexion sollte bereits nach kurzer Projektlaufzeit im Team erfolgen, um die Zusammenarbeit zu prüfen und gegebenenfalls gegenzusteuern [ES11]. In weiterer Folge sollten Retrospektiven regelmäßig eingeplant werden. Ein Richtwert sind ca. 30-45 Minuten je gemeinsamer Projektarbeitswoche. Hilfreich können auch offene Retrospektiven sein, so dass die freie Teilhabe einen Austausch ermöglicht und Einblicke gewährt, wie andere Teams arbeiten. Wichtig ist dabei ein produktives Gleichgewicht zwischen Schaffen und Reflektion im Auge zu behalten [ES6]. Das Schaffen steht über der Analyse: Zuerst kommt das Machen, dann das Lernen [1].

DividerWhite

Abschluss

Proj_CMarschner_DesignDeveloperWorkflow_SameLingo

Das Fundament für die Zusammenarbeit von Developer und Designern ist gegenseitiges Verständnis. Es bedeutet Fragen und Antworten in einer gemeinsamen Sprache formulieren zu können. Viel und gut kommunizieren [ES5], eng zusammen und kurze Wege [ES6], mit kleinen Teams [ES6] in kurzen Zyklen arbeiten [B3:33ff], geteiltes Wissen und kollaborative Tools, „Go and see“ bei User Research, Validierung und im Pairing.  Dabei stets das gemeinsame Ziel im Auge behalten: Ein tolles digitales Produkt mit herausragender UX zu schaffen.

Den Endanwendern ist es letztlich egal, ob mit Wasserfall, Agile, Lean oder Design Thinking gearbeitet wurde. Sie kümmert allein, dass großartige Produkte und Dienstleistungen ihre Probleme für sie effektiv lösen [B3:53].

Quellen und Referenzen zum Artikel

Literatur 
Schreibweise im Text = [Quelle:Seitenzahl]

  • [B1] Organisation in einer Digitalen Zeit: Ein Buch für die Gestaltung von reaktionsfähigen und schlanken Organisationen mit Hilfe von skalierten Agile & Lean Mustern (2016) von Malte Foegen und  Christian Kaczmarek 
  • [B2] Lean UX: Applying Lean Principles to Improve User Experience (2013) von Jeff Gothelf 
  • [B3] Lean vs. Agile vs. Design Thinking: What You Really Need to Know to Build High-Performing Digital Product Teams (2017) von Jeff Gothelf
  • [B4] Scrum: The Art of Doing Twice the Work in Half the Time (2015) von Jeff Sutherland 
  • [B5] Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (2016) von Jake Knapp und John Zeratsky
  • [B6] Transformationale Produkte: Der Code von digitalen Produkten, die unseren Alltag erobern und die Wirtschaft revolutionieren (2017) von Matthias Schrader

Ergosign 

  • [ES1] Remote Board of Leads 2016
  • [ES2] Lean UX Kickstarter Tim Klauck
  • [ES3] Interview Marven Rochau 12.5.2017
  • [ES4] Interview Michael Richter 16.5.2017
  • [ES5] Interview Hannes Musekamp 27.9.2017
  • [ES6] Interview Dorian Bauer 28.9.2017
  • [ES7] Interview Patrick Alt 29.9.2017
  • [ES8] Interview Markus Schwetje 2.10.2017
  • [ES9] Interview Friedemann Metzger 4.10.2017
  • [ES10] Interview Matthias Roos 9.10.2017
  • [ES11] Lessons Learned Designer Developer 24.11.2016
  • [ES12] Board of Leads 2017
Das kranke Rotkäppchen
Privates Projekt – Case Study
Maschinensteuerung
Case Study
Passwort erforderlich
Work_CMarschner_TeaserImg_GeoVis2
Showcase
Logo_White_C_70