Inhalt
Um sich dieser Verbindung dennoch zu nähern, lohnt es sich den Begriff Design genauer zu betrachten, der als zusammenfassende Begrifflichkeit diverse Design-Bereiche in sich vereint. Er umfasst in diesem Fall sowohl User Experience Design, Visual Design und Interaction Design.
Durch die tägliche Arbeit im agilen Umfeld und durch den Diskurs mit verschiedenen fachnahen Personen bereitet es mir Freude, Designpraktiken und -prozesse zunehmend in die agilen Rahmenwerke und Methoden zu integrieren. Dabei sind vor allem die nachfolgenden Punkte wichtig, die Designer/innen und auch das restliche agile Team beachten sollten, um effizient miteinander arbeiten zu können.
Ein Teil des Delivery Teams
Der mitunter wichtigste Punkt bei der Integration von Design in die Agilität ist, dass Design kein kurzweiliger Prozess vor der Entwicklung ist, sondern das Produkt im gesamten Entwicklungsprozess begleitet.
Viele Fachberichte und Bücher wie Lean UX (1) beschäftigen sich ebenfalls mit der Frage, wie Design in agile Prozesse integriert werden kann. Doch das Problem bei der praktischen Umsetzung von Agilität ist oftmals ein hoher Interpretationsraum und das Auslegen der verschiedenen Prinzipien für die Integration des gestalterischen Bereichs. Erst bei der Betrachtung und Verwendung einzelner Methoden und Rahmenwerke können diese Interpretationsräume ausgeglichen werden. Denn sobald feste Timeboxes und Rollen, wie bspw. in Scrum, vermittelt und gelebt werden, wird die direkte Einbeziehung von Designern im agilen Team erleichtert.
Eine eng verzahnte Arbeit in interdisziplinären Teams ist ein wesentlicher Schlüsselpunkt. Doch die Realität sieht oftmals anders aus. Viele Organisationen und Unternehmen exkludieren Design-Leistungen aus ihren Sprints hin zu vorgelagerten „Research“- oder „Design“-Sprints, um in den eigentlichen Sprints Inkremente entwickeln zu können. Dadurch geht den Designer/innen jedoch viel Zeit verloren. Aufgrund eines vorgelagerten Sprints ist diese Arbeit dem Entwicklungsteam einen Schritt voraus und von dem eigentlichen Prozess entkoppelt. Es wird konzipiert, entworfen, entwickelt und anschließend getestet. Design wird dadurch in einem Wasserfallprozess und nicht iterativ/inkrementell abgehandelt, sodass die meisten Design-Aufgaben kaum oder gar nicht während des eigentlichen Prozesses weiterentwickelt werden.
Aus den separierten Prozessteilen kann eine mangelnde Kommunikation resultieren, die schließlich zu einer Diskrepanz zwischen Design und Entwicklung führt. Die bspw. zuvor erarbeitete User Experience kann nur schwer nachvollzogen und somit nicht optimal implementiert werden. Das Ergebnis ist ein Produkt, das nur in Ansätzen dem gleicht, was zuvor konzipiert wurde. Hierdurch entstehen hohe Mehrkosten durch das anschließend erforderliche Refactoring. Im schlimmsten Fall wird das Produkt zwar produktiv genommen, aber nur kurz oder nie verwendet.
Doch wie kann man solche Hindernisse beseitigen? Die Antwort ist einfach und komplex zugleich: Design muss fest in das Entwicklungsteam integriert werden. Konkreter ausgedrückt, muss der Designprozess in die Sprints integriert und im Team verankert werden. Somit wird sichergestellt, dass Design-Aufgaben frühzeitig erkannt, priorisiert und iterativ umgesetzt werden können. Hierzu gehört auch, dass es in jedem Sprint ein klar definiertes Sprint-Ziel und die dazu passenden Inkremente geben muss, die es erreichen lassen. Nicht nur die Artefakte, auch die Events und Rollen des jeweiligen, agilen Rahmenwerks müssen ein fester Bestandteil der Designer/innen werden.
Das Product Backlog
Ein weiterer wesentlicher Punkt ist die Organisation des agilen Teams. Dabei ist vor allem die Transparenz der abzuarbeitenden Aufgaben der Mitglieder essenziell. Bereits im agilen Manifest wird hierfür der Grundstein in zwei von vier Werten gelegt: Durch die Interaktion und Kommunikation der Teammitglieder in Zusammenarbeit mit dem (internen oder externen) Kunden wird jedem klar aufgezeigt, an was gearbeitet wird. (2)
Frameworks wie Scrum arbeiten mit einem Product Backlog, einer Sammlung an Product Backlog Items (kurz: PBIs) die Anforderungen und Bedürfnisse von Nutzern zentralisieren. Die PBIs werden vom Product Owner verwaltet, beschrieben und sortiert. Von groben und mit wenigen Anforderungen beschriebenen, bis hin zu spezifisch ausdifferenzierten Items kann alles enthalten sein. Im Planning verfeinert das Scrum Team (im besten Fall natürlich mit dem integrierten Design) gemeinsam die PBIs. Als Best Practice haben sich hierbei die sogenannten User Stories etabliert.
Bei dem Product Backlog ist es sehr wichtig, dass Design-Aufgaben integriert werden. In der Theorie sollen diese Aufgaben in den PBIs integriert werden. Eigentlich eine grundsolide Idee, da es Überschneidungen bei Agilität und (UX) Design in Fragmenten wie Iterationen und die Definition von Anforderungen auf Grundlage von User Stories gibt.
Doch ein wesentliches Problem hat sich in der Praxis leider zu oft bewahrheitet: Design, speziell UX Design, wird nicht ausreichend in Plannings berücksichtigt oder oftmals nicht messbar aufbereitet. Können Outcomes und Outputs nach einer Iteration nicht gemessen werden, versickern die Vorteile der iterativen Arbeitsweise und der große Mehrwert vom UX Design geht restlos verloren. Es bleibt dann unklar, ob das entwickelte Inkrement die Bedürfnisse der nutzenden Person abdeckt und das für Agilität typische „Inspect and Adapt“ zusätzlich ausgehebelt wird.
Da sich die Integration der Design-Aufgaben innerhalb der regulären PBIs als schwierig erweist, wird in der Praxis oftmals eine Kompromisslösung angestrebt. Hierbei werden die Design-Aufgaben zwar in das Product Backlog integriert, jedoch als einzelne PBIs. Dies hat sowohl Vor- als auch Nachteile. Abhängigkeiten können auch so klar aufgezeigt und alle Aufgaben transparent gemacht werden. Allerdings können dadurch auch Silos innerhalb des Teams entstehen und die PBIs sind weniger miteinander vergleichbar. Letzteres kann dazu führen, dass manche PBIs Lern- und andere „Done“-Inkremente produzieren.
Es ist also leichter gesagt, als durchzuführen. Die Designer/innen müssen schlussendlich eng mit dem Team und vor allem dem Product Owner zusammenarbeiten. So wird gewährleistet, dass die Design PBIs aufgenommen, definiert und messbar geschärft werden. Für jeden Sprint ist es wichtig, Items umzusetzen, die bis zum Ende eines Sprints erledigt werden können oder ein Teilbereich präsentiert werden kann.
Sprints und ihre Hürden
Designer/innen erfahren oftmals den Bedarf seitens des Teams oder der Product Owner, ihre Prozesse in die Sprints zu integrieren. Dies kann klappen. Doch einige Design-Aufgaben, wie bspw. ein mehrwöchiger Researchprozess, können nicht in einem Sprint abgehandelt werden.
Was wäre in solch einem Fall zu tun? Josh Seiden (Designer, Autor, Speaker und Strategie-Coach) stellt in seinem Artikel (3) zur Integration von Design in agile Prozesse folgende drei Prinzipien auf:
-
Keine „Sprint X“-Phase
-
Arbeite nicht wie vorher, nur schneller
-
„Done“ bedeutet Transparenz
Das erste Prinzip habe ich bereits behandelt. Die beiden anderen sind neu und bedienen sehr wichtige Ansätze für die Praxis. Im Wesentlichen beschreibt das zweite Prinzip, dass ein (neues) agiles Team meist so mit z.B. Scrum arbeiten möchte, wie es ohnehin immer gearbeitet hat – nur eben zeitlich komprimierter, um die Sprints einzuhalten. Allerdings können mehrwöchige Prozesse und Methoden bei gleicher Ergebnisannahme nicht einfach auf (maximal) vierwöchige Zyklen herunter gebrochen werden. Vielmehr ist es wichtig, sich auf die agile Arbeitsweise einzulassen und Iterationen als gesetzte Timebox zu verstehen. Gerade im Design gibt es viele Methoden und Prozesse, die eine Sprintlänge überdauern können (wie der oben erwähnte, mehrwöchige Researchprozess).
Hier kommt dann das dritte Prinzip ins Spiel. Auch hier ist Transparenz der Schlüssel. Überdauert eine Aufgabe eine Sprintlänge, sollte eine angepasste „Definition of Done“ (kurz DoD) mit dem restlichen Team kommuniziert werden. Scrum arbeitet mit dem „Done“ in der Form, dass jeder am Sprintende aufzeigen muss, inwieweit die geleistete Arbeit mit der DoD übereinstimmt. In der Praxis wird dann oftmals ein Design-Fragment, z.B. ein Erfahrungsbericht, Schlussfolgerungen und aufkommende Fragen, im Review dargelegt und als „Done“ definiert. Es kann somit eine große Aufgabe in zuvor zugeschnittenen Segmenten in verschiedenen Sprints bearbeitet werden. Denn auch erste Erkenntnisse oder Designaufschläge sind wesentliche Bestandteile für das gesamte Team und fördern eine hohe Transparenz in der Zusammenarbeit.
Mit dem richtigen Mindset arbeiten
Ein ebenfalls wichtiger Punkt, den ich immer wieder in der Praxis bei der Arbeit in agilen Teams erlebe ist, dass das Mindset der Designer/innen ein wesentlicher Dreh- und Angelpunkt in der interdisziplinären Zusammenarbeit bildet. Weg von den exklusiven Designer/innen, die Design erstellen – Hin zum Design Enabler (4), die Design dem Team zugänglich machen, supervisieren und moderieren. Mit diesem Mindset entsteht eine deutliche Parallele zu den Aufgaben eines Scrum Masters. Wo der Scrum Master moderierend und vorantreibend hinsichtlich des Rahmenwerks ist, konzentriert sich der Designer auf das interdisziplinäre Designverständnis und das Human-Centered Design. Es ist also nicht abwegig, dass Designer/innen die Rolle des Scrum Masters in einem Scrum Team ergänzen oder in anderen agilen Teams kombinieren kann.
Im Kern ist diese Verschmelzung der fachlichen Expertise und der Arbeit als Scrum Master meiner Ansicht nach die Essenz von Agilität. Denn die Praxis sollte weg vom Silodenken, hin zu einem gemeinsamen Ziel, der dadurch erhöhten Teamleistung und Effizienz.
Take-Aways für Designer
-
Kommunikation ist mitunter der wichtigste Punkt bei der Integration. Sei offen zu Deinem Team und zeige Deine Aufgaben und Prozesse transparent auf.
-
Organisiere Deine Aufgaben im Projekt Product Backlog, nicht in einem eigenen.
-
Gib Design Aufgaben, wenn möglich, auch in Dein Team. Moderiere kleine Workshops zur Entwicklung von z.B. Design-Elementen.
-
Involviere Dein gesamtes Team nach Möglichkeit in Feedbackschleifen von Nutzer/innen oder Kund/innen während Research-Phasen. Auch das Moderieren und Beobachten Deiner Teammitglieder erbringt wichtige Erkenntnisse.
-
Teile große Aufgabenpakete, wenn nicht anders möglich, über mehrere Sprints. Hierbei musst Du transparent Deinem Team spiegeln, was Du während der Sprints tust und welchen Mehrwert es für das Produkt hat.
-
Hol Dir schnell Feedback von Deinem Team und Deiner Zielgruppe ab (z.B. durch Prototypen)
-
Du kannst durch die iterative Arbeitsweise schnell auf Änderungen eingehen, ohne einen hohen Kosten- und Zeitaufwand zu investieren.
Take-Aways für das restliche Team
-
Kombiniert Discovery und Delivery Aufgaben, um eine hohe Effektivität und Frequenz der Increments zu gewährleisten.
-
Pflegt ein gemeinsames Product Backlog. Das heißt auch, dass dieses aktuell gehalten werden und Aufgaben transparent „in Bewegung“ bleiben müssen.
-
Lasst Euch auf Design-Prozesse und -Methoden ein.
-
Arbeitet eng mit Designer/innen zusammen und verzahnt die Prozesse miteinander. Hierbei ist der Schlüssel eine sinnvolle Priorisierung, damit alle Teammitglieder parallel arbeiten können.
-
Jedes Scrum-Team sollte eine/n Vollzeit-Designer/in im Team haben, um die parallele Arbeit überhaupt realisierbar zu machen.
-
Macht im Design Review auch UX Design sichtbar. Denn auch Research-Ergebnisse, Konzepte oder Analysen fließen maßgeblich in die Entwicklungsarbeit mit ein und sind daher ein wesentlicher Bestandteil des jeweiligen Increments. Eine Sichtbarmachung der Designprozesse erleichtert im nachfolgendem Planning die Priorisierung der User Stories.
-
Auslagerung von Design-Aufgaben ist manchmal unumgänglich, führt aber zu wasserfallähnlichen oder vorgelagerten Sprints. Integriert auch externe Designer/innen bestmöglich in das Scrum Team.
Fazit: Von der Theorie in die Praxis
Den ultimativen, „richtigen“ Weg gibt es hierbei leider nicht, da jedes Team und jedes zu entwickelnde Produkt individuell betrachtet werden sollte. Mit Hilfe der genannten Techniken und Methoden lässt sich Design ohne weiteres in agilen Methoden und Rahmenwerken integrieren.
Wichtig ist, dass das Team offen und transparent kommuniziert und im ständigen Austausch miteinander arbeitet. Hierfür empfiehlt es sich, die räumliche Nähe der einzelnen Teammitglieder möglichst gering zu halten. Dadurch bekommt jedes Mitglied die Arbeit der anderen mit, das Team spielt sich und seine Prozesse schneller ein und ein reibungsloser Ablauf ist gewährleistet. Dabei ist es auch von Vorteil, wenn der Product Owner für Fragen hinsichtlich der PBIs schnell für das Team erreichbar und im Idealfall im selben Raum anwesend ist. Eine Alternative stellt dabei die Integration eines bereits voll eingespielten und auf sich abgestimmten externen Teams dar. Dieses beginnt mit der Gestaltung und Entwicklung des jewieligen Produkts und wird nur so lange benötigt, bis die Inkremente ausreichend und die Stakeholder mit dem Ergebnis zufrieden sind.
Bei einer startenden Agilisierung ist es ratsam darauf zu achten, dass Rollen wie der Scrum Master und der Product Owner möglichst von bereits geschulten und erfahrenen Personen besetzt werden, damit die Transformation, und die darin enthaltene Integration von Design, bestmöglich umgesetzt werden kann. Ebenso können (externe) Agile Coaches neue, agile Teams bei einer solchen Überführung in die Agilität behilflich sein.
Erfahrenes agile Consulting und der laufende Prozess der agilen Transformation bilden eine Symbiose mit den genannten Techniken und Methoden, um eine reibungslose Integration zu ermöglichen.
Quellen
Über Felix Piepenschneider
