DesOps & Tri-Track Agile

Andreas Odermatt
Andreas Odermatt, 11. Februar 2019

Bei DesOps (DesignOps) dreht sich alles um die Schnittstelle zwischen UX-Designern, Entwicklern und Product Ownern. DesOps ist mehr als nur ein trendiges Buzzword. Es ist ein Ansatz, der es bei richtiger Umsetzung schafft, Design und User Experience wieder in den Mittelpunkt zu stellen.

«Agile» ist ein iterativer Softwareentwicklungsansatz, bei dem interdisziplinäre Teams in einem agilen, iterativen Vorgehen Projekte realisieren. Die Prinzipien dieses Ansatzes wurden bereits 2001 im Manifesto for Agile Software Development festgehalten. Seither wurde Agile zur de-facto Norm in der Entwicklung von digitalen Services (z.B. mit dem Scrum-Framework). Leider ist ein rein Agile ausgerichtetes Umfeld für UX-Designer nicht gerade förderlich.

Wichtige Designpraktiken wie «Understanding & Discovery» (verstehen und erforschen) haben mit Agile grosse Schritte rückwärts gemacht. Denn mit Agile wurde der Fokus primär auf die Geschwindigkeit (Velocity) gelegt. Entwickler und Produktmanager messen den Erfolg daran, ob ein Produkt oder Feature rasch released wurde und nicht daran, ob die Lösung (und somit das Design) die Bedürfnisse der Benutzer erfüllt und sich effizient und stabil betreiben lässt. Folgende Gegenüberstellung verdeutlicht die Unterschiede:

Ein weiteres Problem von Agile für UX-Designer: Man ist fix in Teams integriert, jeweils aber der einzige UX-ler und somit oft isoliert von anderen Designern. Es findet oft nur noch wenig oder kein Austausch mehr unter den Designern gleicher oder anderer UX-Disziplinen statt. Wichtige Erkenntnisse, Know-How-Transfer, Best-Practices und Feedbacks unter Gleichgesinnten gehen so verloren und skalieren kaum. Wichtig dabei ist auch, dass UX verschiedene Disziplinen hat. Ein UX-Designer ist meistens (wie auch die Software Engineers) spezialisiert auf einen UX-Aspekt wie z.B. User Research oder UI-Design. Somit findet also für den UX-Designer die Arbeit in interdisziplinären Teams in Bezug auf UX nicht wirklich statt.

Die DevOps-Bewegung brachte neues Leben in Agile. Geschwindigkeit alleine war nicht mehr das Ziel, sondern ein Nebenprodukt der Automatisierung (z.B. mit Continuous Integration & Delivery). Wichtige Aspekte wie Qualität und Betriebsthemen wurden zentrale Bestandteile des agilen Vorgehens.

Die bessere Integration von UX-Designern und der stärkere Fokus auf die Bedürfnisse der User im Agile Prozess blieben aber weiterhin ein ungelöstes Problem. Um diese Zusammenarbeit zu optimieren, gibt es aber diverse Lösungsansätze. Diese nennen wir – angelehnt an die Erfolge der DevOps-Bewegung – auch DesOps (oder DesignOps).

 

DesOps?

Für den Begriff DesOps gibt es zwei verschiedene Betrachtungsweisen:

  1. DesOps als Mindset
  2. DesOps als Rolle/Abteilung

Im «DesignOps Handbook» wird primär auf die Rolle resp. Abteilung «DesignOps» eingegangen. Dabei wird mit DesOps eine neue Abteilung (oder Einzelperson) bezeichnet, die den Designprozess innerhalb eines Unternehmens plant, definiert und verwaltet. In dieser Betrachtungsweise ist es das Ziel von DesOps, dass das Designteam zu einer eingespielten Einheit wird, die mit viel Effizienz, geringer Reibung und hoher Skalierung arbeitet und qualitativ hochwertige und abgestimmte Designergebnisse liefert.

Aber am wichtigsten: DesOps soll dem Designteam helfen, die Resultate seiner Arbeit wieder in den Entwicklungszyklus zurückzuführen. Und genau auf diesen Aspekt, der eben dem Mindset von DesOps entspricht, gehe ich in diesem Artikel ein. Dabei stimme ich dieser Aussage von Gus Correia völlig zu:

DesignOps is not a new design department. It’s ‘how’ interfaces between design, product, engineering are managed. Also DesignOps is about creating a culture of user centricity and agility over time. It puts design not as just another step along the way, but as a continuous ritual of handovers and feedback. — Gus Correia

DesOps versucht also, die Barrieren zwischen dem Designteam, dem Produktmanagement und den Engineering-Teams abzubauen und das user-zentrierte Design in der Kultur zu verankern. Auf der anderen Seite geht es auch darum, dass die oft verteilt arbeitenden UX-Designer wieder eng zusammenarbeiten, sich austauschen und inspirieren. Jedes Unternehmen mit mehr als einem Designer benötigt also eine Form des DesOps-Denkens. Einfach nur, weil Sie sicherstellen sollten, dass Designer nicht in Silos arbeiten. Wenn die Designer dann auch noch die gleichen Tools, Templates und Workflows anwenden, entsteht eine wesentlich höhere Qualität und Effizienz im Designprozess.

DesOps darf aber nicht mit Design Management oder Designsystemen verwechselt werden. Diese Methoden zielen darauf ab, Design in die Managementpraktiken von Unternehmen zu integrieren und die Arbeit in den Designteams zu standardisieren.

In den nächsten Abschnitten zeige ich Lösungsansätze auf, wie diese Barrieren abgebaut und die Zusammenarbeit optimiert werden kann.

Dual-Track Agile als Lösungsansatz für DesOps

Dual-Track Agile ist eine Erweiterung der klassischen, agilen Entwicklungsvorgehens. Dabei ist es bei dieser Methode ebenso wichtig herauszufinden, was zu bauen ist, wie der eigentliche Entwicklungsprozess selber. Dazu wird dem Delivery-Track ein zweiter «Discovery-Track» hinzugefügt.

Dabei bricht der Discovery-Track die UX-Silos auf. Die Designer arbeiten nun gemeinsam und interdisziplinär innerhalb dieses Tracks. Der Track arbeitet dabei für ein oder auch mehrere Delivery-Tracks rsp. Projekte. Nebst den UX-Spezialisten sind auch die Product Owner fixer Bestandteil dieses Tracks. Der (oder die) Lead Engineer(s) der Delivery-Tracks sollten wenn möglich auch Teil davon sein. Optimalerweise wird regelmässig das gesamte Entwicklungsteam einbezogen. So erhält der Delivery-Track wertvolles Wissen aus den Gesprächen mit Anwendern und Einblicke in die Resultate aus den Experimenten. Andererseits können die Engineers wertvolle Inputs bzgl. der technischen Machbarkeit geben. Um das erarbeitete Wissen während der gesamten Entwicklung sicherzustellen ist es sinnvoll, dass der UX-Lead (z.B. ein UX-Architekt) aus dem Discovery-Track die ganze Zeit Teil des Delivery-Tracks ist.

Das Vorgehen von Dual-Track Agile orientiert sich also auch an den «Lean Startup-Methoden». Hier werden von den Produkt-Teams kleine, eng begrenzte Wetten, die als Experimente bezeichnet werden, angegangen. Mit diesen Experimenten konnten diese Team rasch feststellen, ob die eingeschlagene Produktrichtung valide ist oder nicht. Das Geschäftsrisiko konnte so weiter reduziert werden.

Ziel des neuen Tracks ist es also herauszufinden, ob eine Produktidee gut ist und ob es Sinn macht diese zu bauen. Aber woher wissen wir nun, ob unser Produktteam eine gute Idee hat?

How to «Dual Track»

Die UX-Designer des Discovery-Tracks haben dazu eine Vielzahl von Methoden, die sie verwenden können, um genau das herauszufinden. Primär werden experimentelle Ansätze verwendet. Bevor in Ideen investiert wird, werden diese basierend auf User-Verhalten evaluiert. Die Zeit, in der Entscheidungen primär auf eigenen Annahmen beruhten sind somit vorbei. Ganz nach dem Motto «Guess Less!».

Während des Discovery-Prozesses sollte das Team Antworten auf die folgenden Fragen sammeln:

  • Ist es wertvoll? (valuable) → Werden es die User benutzen?
  • Ist es benutzerfreundlich? (usable) → Können es die User benutzen?
  • Ist es realisierbar? (feasible) → Können wir es den Usern liefern?

Dazu werden im Discovery-Track User-zentrierte Methoden und experimentelle Ansätze angewendet. Ein zentrales Element ist dabei das Prototyping und die rasche Validierung mit (echten) Usern. Das Vorgehen kann etwa so aussehen:

  1. Idee generieren/auswählen
  2. Hypothesen aufstellen
  3. Mit Usern über die Idee sprechen –> They like it!
  4. Mit Stakeholdern sprechen –> They love it!
  5. Einen Prototyp erstellen und mit Usern validieren –> They can use it!
  6. Mit den Engineers eine Schätzung machen –> We can build it!
  7. Weiter mit Usern experimentieren…

Danach gibt es zwei Möglichkeiten:

  1. They will use it → Yeah! → vom Discovery ins Delivery geben → code it!
  2. They will not use it → Fail! → nun sind wir schlauer → neue Idee validieren

Die Lieferobjekte des Delivery-Tracks sind also validierte Stories für das Delivery-Backlog. Zudem werden weitere Assets wie z.B. UI-Designs geliefert. Die Stories werden anschliessend im Delivery-Track mit Agile Development und Lean-UX Methoden implementiert.

Dual-Track Agile ist also ein optimaler Prozess, um Ideen zu validieren bevor sie realisiert werden. So weit so gut. Doch woher stammen die Ideen und wie können wir diese entwickeln?

Die Antwort: Füge noch einen dritten Track hinzu!

In dem dritten Track, dem «Understanding-Track», werden Ideen generiert und entwickelt. Hier geht es auch darum, das eigene Produkt sowie dessen Markt und Kunden stets besser zu verstehen. In diesem dritten Track arbeiten also primär die Product-Owner mit den UX-Leads zusammen.

Das Team formuliert auch die Produktvision sowie die Ziele (z.B: Kundenbindung oder Neukundengewinnung). Die wichtigste Arbeit ist es also, Wege zu finden um die Vision und Ziele zu erreichen. Durch laufende Marktbeobachtung, User-Feedbacks und Gesprächen mit internen Stakeholdern (wie z.B. den Support-Teams) werden laufend Ideen für Verbesserungen oder Erweiterungen des Produkts generiert.

Zur Entwicklung dieser Ideen bieten sich verschiedene Ansätze und Templates an. Nützlich sind hier sogenannte «Canvas» wie z.B. das Opportunity Canvas. Unabhängig der gewählten Methode sollten diese drei Fragen beim «Idea Framing» beantwortet werden:

Wieso soll das umgesetzt werden?
• Für wen ist das nützlich?
Wie würden die User es nutzen?

Nachdem das Team die passende Ideen formuliert hat, werden diese an den Discovery-Track zur Validierung übergeben.

Natürlich erhöht sich mit Tri-Track Agile auch die Komplexität des Projektmanagements. Vorallem die Planung und Ressourcenzuweisung wird anspruchvoller. Nichts desto trotz überwiegen meiner Meinung nach die Vorteile dieser zusätzlichen Tracks.

Tri-Track Agile kann zudem chaotischer werden, wenn viele Ideen scheitern. Das Scheitern ist aber genau die Stärke von dieser Methodik. Denn gescheiterte Experimente sind viel günstiger als Features ohne Mehrwert zu entwickeln. Dieser «fail fast» Prozess bringt die Teams auch fachlich weiter: Sie lernen, bessere Produkte zu bauen, die dem User nicht nur helfen, sondern ihn auch begeistern.


Quellen