Über die Herausforderungen in der Zusammenarbeit von interdisziplinären agilen Teams.
#Agile #digitalagency #failforward #interdisciplinaryteams #agenturalltag
Die Vorteile agilen Arbeitens
Agiles Arbeiten in interdisziplinären Teams ermöglicht einen kurzfristigen und schnellen Austausch zwischen Team und Stakeholdern. Dadurch können schneller Entscheidungen getroffen werden, das Team ist effizienter und kommt schneller zu Ergebnissen. Kompetenzen und Erfahrungen der einzelnen Disziplinen gehen ab einem frühen Projektstadium in die Entwicklung ein, was zu insgesamt besseren und kreativeren Lösungen führt. Abgesehen davon macht es natürlich Spaß, wenn sich im Team eine Dynamik entwickelt, man sich gegenseitig herausfordert und gemeinsam zu noch besseren Lösungen kommt.
Super Sache also! Bleibt nur die Frage nach dem optimalen Prozess.
Agiler Produktionsprozess mit vorgelagerter Basiskonzeption
In bisherigen Projekten war es bei uns oft so, dass das UX Team einen Sprint vorgearbeitet hat. In diesem Sprint entstand in der Regel neben Personas, User Journeys und einer Liste mit Anforderungen bereits das, was wir als Basiskonzeption bezeichnen.
Man muss dazu sagen, dass bei uns als Digitalagentur die Projekte oft nicht auf der „grünen Wiese“ starten. Sie haben bereits eine Vorgeschichte und meist erhalten wir schon mit dem Kundenbriefing eine mehr oder weniger vollständige Liste an Anforderungen.
Die Basiskonzeption umfasst:
- Navigationsstruktur (Sitemap)
- Übersicht der Templates/Views & Module (Siteflow) und allg. Architektur (Hierarchien)
- Design Attribute, Farben, Fonts, Key Visuals (Moodboard)
- Technische Architekturskizze (Flowchart)
Während der Basiskonzeption ist ein Sparring mit der Entwicklung vorgesehen. Wenn die Entwickler in das Projekt eingestiegen sind, waren die Grundlagen aber weitestgehend bereits gelegt.
Was wir an diesem Vorgehen bemängelten, war die unzureichende Abstimmung zur technischen Umsetzbarkeit und ein zu spätes Feedback und Hineindenken der Entwicklung in das Konzept. Vor allem hatten wir das Gefühl, den eigentlichen Vorteil des interdisziplinären Teams zu verschenken – alle Kompetenzen in einem frühen Stadium der Konzeption einbringen zu können.
Es kam vor, dass das UX Design an der Technik „vorbei“ konzipierte oder Details in kurzen Abstimmungen von der Technik als machbar eingeschätzt wurden, die später aber zu erheblichem Mehraufwand geführt haben, weil es dann doch nicht so einfach war. Es fehlte der Gesamtzusammenhang für eine vernünftige Einschätzung.
Die Entwicklung auf der anderen Seite, fühlte sich ausgeschlossen und vor vollendete Tatsachen gestellt. Das Sparring mit dem UX Team im Rahmen der Basiskonzeption gestaltete sich schwierig, weil das Dev-Team mit dem Kopf noch voll in anderen Projekten steckte.
Es fühlte sich irgendwie zu „wasserfallig“ an. Weshalb wir nach einem besseren gemeinsamen und agileren Einstieg in die Produktentwicklung suchten. Mit dem nächsten Projekt, der Entwicklung einer Radio App, sollte das ganze Team gleichzeitig starten.
Das Experiement
Was also passiert, wenn man ein neues Team, bestehend aus UX, UI, Android, iOS, Testing und PO ohne weitere Vorbereitung in einen Raum schmeißt mit dem Ziel, eine App in ihren Details weiter auszuspezifizieren?
Braucht es wirklich einen zeitlichen Vorlauf für die UX Konzeption neuer Produkte oder kann man direkt gemeinsam in die technische Konzeption und das UX Design starten? Wir haben uns auf das Experiment eingelassen, mit zunächst durchwachsenem Ergebnis.
Meine naive Vorstellung war, dass wir gemeinsam Anforderungen in Form von Stories formulieren, das Produkt damit in bearbeitbare Teile zerlegen und priorisieren, um dann mit der weiteren Spezifikation der Stories zu beginnen.
Das Meeting war für mich Augen öffnend. Obwohl das Team aus erfahrenen Mitgliedern besteht, die bereits einige Produkte erfolgreich von der Idee bis zum Launch erarbeitet und auch schon gemeinsam Produkte umgesetzt haben (allerdings mit dem besagten Vorlauf von UX) redeten wir aneinander vorbei. Es war, als würden wir zwar eine Sprache, aber unterschiedliche Dialekte sprechen, die uns die Verständigung erschweren.
Wir gingen hoch motiviert in den Termin. UX und Entwicklung kamen aus zwei völlig unterschiedlichen Richtungen, hatten eine komplett andere Perspektive. Entsprechend wählten sie verschiedene Denkansätze und Methodiken um sich dem zu konzipierenden Produkt anzunähern.
Während die eine Seite erstmal „high level“ definieren wollte welche Nutzeranforderungen in welchen Situationen erfüllt sein müssen, dachte die andere Seite über Systemarchitektur und die in den APIs zur Verfügung stehenden Parameter und Inhalte nach.
Wir versuchten uns über Use Cases als gemeinsamen Nenner einander anzunähern, doch kamen in der Diskussion vom Hundertsten ins Tausendste ohne klare Struktur. Das gewünschte, sich gemeinsam der Spezifikation nähern, kam irgendwie nicht zustande.
Das Resultat waren über den Fortschritt enttäuschte Entwickler und sich bedrängt fühlende UX Designer. „Fight Club Stimmung“, beschwerte sich eines der Teammitglieder über die etwas gereizte Diskussion. Nach zwei Stunden haben wir den Termin abgebrochen und mussten das alle erst mal sacken lassen.
Was haben wir daraus gelernt?
Am nächsten Tag haben wir den Termin in einer gemeinsamen Retrospektive ausgewertet und folgende Learnings gezogen:
- Jeder Termin braucht ein klar definiertes Ziel: Was wollen wir bis zum Ende des Termins erreichen?
- Es sollte definiert werden, wie man das definierte Ziel erreichen möchte (Vorgehen und gewählte Methodik). Das kann einem Teammitglied als „Host“ übertragen werden oder auch gemeinsam bestimmt.
- Es sollte eine Diskussionsgrundlage geben, von der aus man gemeinsam startet. Dafür eignet sich ein Flow, eine Skizze, Wireframes oder auch anderweitig formulierte und visualisierte Ideen.
Wir sind zu dem Schluss gekommen, dass es weiterhin richtig und wichtig ist, als Team gemeinsam in die Konzeption zu starten. Das Meeting sollte aber besser strukturiert und vorbereitet werden. Die Art von Meeting, die es für den Anfang braucht, habe ich als kollaboratives Konzept Meeting definiert oder auch Concept Workshop.
Eine wichtige Erkenntnis war vor allem, dass dieser Concept Workshop vom UX Design angeleitet werden sollte. Ein Produkt ist dann erfolgreich, wenn es die Bedürfnisse der Nutzer bestmöglich erfüllt. Durch den Lead des UX Designs ist garantiert, dass die Konzeption einen nutzerzentrierten Fokus hat und sich nicht zu früh in technischen Details verliert.
Für die nächsten Schritte der Produktspezifikation haben wir einen Mix aus der Bearbeitung von Teilaufgaben innerhalb der Kompetenzbereiche, One-on-ones sowie gemeinsamen Sessions gewählt. Die Reihenfolge der zu bearbeitenden Themen haben wir vorab gemeinsam in einer Sprint- und Releaseplanung definiert. Features mit dem höchsten Wert für Nutzer und hoher technischer Komplexität zuerst.
Einen Sprint später waren wir sehr zufrieden mit der Zusammenarbeit im Team und dem bisherigen Ergebnis. Entwicklung und UX Design haben sich wieder lieb!
Nachträglich habe ich im Buch Lean UX von Jeff Gothelf und Josh Seiden eine Passage gefunden, die mich in diesem Ansatz bestärkt: “Collaborative design is still a designer-led activity. It is the designer’s responsibility to not only call collaborative design meetings but to facilitate them, as well. Sometimes you’ll have informal chats and sketching sessions. Sometimes more structured one-on-one sessions with a developer at a whiteboard. Other times, you will gather the entire team for a Design Studio exercise. The Key is to collaborate with a diverse group of team members.” [Jeff Gothelf aund Josh Seiden, Lean UX, S. 49]
Bei Interesse an agiler Arbeitsweise lest auch gern meinen Text How we work!
