Agile Contentproduktion — geht das?

Bild: David Mühlfeld

Agile Arbeitsmethoden kennen die meisten aus der Software Entwicklung. Aber auch der Alltag um mich herum in der Berliner Digitalagentur Aperto ist ziemlich agil. Bei uns sind in interdisziplinären agilen Teams z.B. auch UXler und Designer zu finden, aber ziemlich selten Redakteure und Content-Strategen. Warum eigentlich? Ist es nicht der Content, für den die Webseiten gebaut werden? Und was ist eigentlich, wenn ein Team gar nicht codet, sondern „nur“ Content produziert? Kann es dann auch agil arbeiten? Genau das wollte ich herausfinden — und hab es einfach mal gemacht.

Agil ist nicht gleich Scrum

Dabei möchte ich gleich mal betonen, dass Scrum vielleicht die bekannteste, nicht aber die einzige agile Arbeitsmethode ist. Für unser Team war Scrum leider nicht besonders geeignet, schon allein, da wir jede Woche eine fertige mit Content gefüllte Webseite abliefern mussten, an der danach nichts mehr geändert werden konnte — wirklich iterativ arbeiten kann man da nicht. Außerdem waren wir ein kleines Team, ohne Scrum Master, ohne Product Owner und ohne einen Kunden, der seine Prozesse grundlegend ändern wollte.

Daher entschieden wir uns für Kanban — denn diese Methode verlangt nicht, dass man seinen kompletten Arbeitsablauf ändert und in Sprints organisiert. Kanban setzt da an, wo man ist, und ermöglicht dann die kontinuierliche Verbesserung der Prozesse.

Generell bin ich der Meinung, dass agile Methoden die Arbeit erleichtern und das Produkt verbessern sollten, nicht einengen und verkomplizieren.

Deswegen ging es bei unserem Versuch vor allem darum, herauszufinden was für uns als Team, für unser Produkt und für unsere Agenturumgebung passt, nicht darum, eine Methode möglichst „by the book“ zu befolgen. Denn so steht es schließlich schon in den vier Werten des Agilen Manifests.

Der Hintergrund: Team, Projekt und Pain Points

Wenn ich „wir“ sage, dann meine ich das Kernteam, das an der Contentproduktion für einen unserer Kunden maßgeblich beteiligt war — bestehend aus Content-Konzeption, Design, Text, Content Management und Client Management. Unsere Aufgabe war, einen Online-Shop mit relevanten, unterhaltenden und nützlichen Inhalten zu ergänzen. Dafür inszenierten wir Produkte so, dass Storytelling im Vordergrund stand und durch Emotionalisierung Kundeninteresse geweckt und Kundenbindung ermöglicht wurde. Jede der in meist wöchentlichem Rhythmus veröffentlichten Content-Seiten sollte einen ganz eigenen, unverkennbaren Look haben, sich aber dennoch in den Gesamtkontext der Markenkommunikation und des Online-Auftritts einfügen.

Das Projekt lief schon seit etwa einem halben Jahr, als ich die Idee des agilen Experiments hatte. Bisher war das Projekt zum großen Teil nach dem klassischen Wasserfall-Prinzip abgelaufen. Es gab einen detaillierten Projektplan und einen Client Manager, der den Überblick hatte und die einzelnen Aufgaben an die Mitarbeiter der verschiedenen Gewerke verteilte. Es gab ein „Daily Stand-Up“, das allerdings nicht obligatorisch war und auch nicht immer von allen Beteiligten wahrgenommen wurde.

Die Kommunikation mit dem Kunden fand in wöchentlichen Telefonaten statt, per Mail und zum Teil über die Kollaborations-Software Confluence. Die Zusammenarbeit war angenehm und erfolgreich, trotzdem hakte es an manchen Stellen. Hin und wieder kam es zum Beispiel vor, dass Layouts abgeliefert wurden, mit denen der Kunde nicht zu hundert Prozent zufrieden war, weil er sich eine andere Umsetzung vorgestellt hatte. Die Korrekturen zu so einem späten Zeitpunkt kosteten dann viel Zeit.

Wir wollten also den Kunden mehr und vor allem in kürzeren Intervallen einbeziehen, um so überflüssige Arbeit zu verhindern und ein für alle zufriedenstellendes Ergebnis zu erreichen.

Auch intern war es nicht immer einfach, dass das Team auf demselben Informationsstand war. Schon allein dadurch, dass wir nicht alle in einem Raum saßen und jeweils noch in andere Projekte involviert waren, war es für den Client Manager viel Arbeit sicherzustellen, dass jede Information beim Zuständigen ankam. So musste beispielsweise Feedback zum Design, das der Kunde im Telefongespräch mit dem Client Manager geäußert hatte, protokolliert und dann an den Designer weitergegeben werden. Dieser hatte dann eventuell eine Nachfrage, die der Client Manager wiederum richtig formuliert an den Kunden geben musste…. ihr versteht, was ich meine.

Wir hatten also drei Ziele anzugehen:

· Die Kundenzufriedenheit steigern.

· Die Teamzufriedenheit steigern und interne Kommunikation verbessern.

· Unsere Effizienz steigern.

Und ich wollte wissen: Können agile Methoden uns dabei helfen?

Maßnahme 1: Bessere Kommunikation

Um unsere Ziele zu erreichen, haben wir verschiedene Teile unseres Prozesses verändert — nicht alles auf einmal, sondern nach und nach. Ein wichtiger Punkt war die Kommunikation: intern und mit dem Kunden.

„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“

Das ist eines der zwölf Prinzipien hinter dem agilen Manifest und eigentlich auch gesunder Menschenverstand. Je direkter die Kommunikation ist, desto weniger Missverständnisse entstehen. Da wir nicht alle in einem Raum sitzen konnten, einigten wir uns trotzdem darauf, so viel wie möglich persönlich zu sprechen und richteten darüber hinaus einen Team-Slack-Kanal ein, um die endlosen E-Mail-Ketten zu vermeiden.

Die Kommunikation mit dem Kunden wollten wir verstärkt auf Confluence durchführen — also da, wo der Gegenstand der Diskussion, nämlich das Konzept, der Text oder das Bild direkt lagen. Außerdem sollte JEDER aus dem Team mit dem Kunden kommunizieren, also beispielsweise der Designer die Nachfrage zu einer Farbauswahl direkt beantworten. Zu diesem Punkt mussten wir uns natürlich erst die Zustimmung des Kunden holen — denn nicht jeder möchte mit 5 verschiedenen Agentur-Mitarbeitern kommunizieren.

Maßnahme 2: Kanban-Methode

Die größte Änderung war das Einführen der Kanban-Methode. Der Projektplan wanderte kurzer Hand in den Müll, dafür gab es nun ein Board, an dem alle jederzeit den Status des Projekts ablesen konnte. Dass das Board ständig aktuell war, war die Verantwortung eines jeden einzelnen.

Keiner teilte mehr einem anderen Aufgaben zu. Wir beschlossen zusammen, was getan werden musste, und jeder nahm sich seine Aufgaben, die er dann eigenverantwortlich zu Ende brachte.

Also: Pull statt Push-Prinzip. Wer für den Tag welche Aufgaben übernahm und wo gegebenenfalls Hindernisse lauerten, klärten wir im zehnminütigen täglichen Stand-Up, dass nun obligatorisch war. Wann immer ein kleines Arbeitspaket fertig war, wurde es direkt an den Kunden gegeben. So konnte der Kunde zu jedem Zeitpunkt wertvolles Feedback geben und wir kamen gar nicht erst in die Gefahr, lange Zeit in eine falsche Richtung zu arbeiten.

Unser Kanban-Board bestand nicht nur aus den üblichen drei Spalten „To Do, Doing, Done“, sondern noch aus allerlei weiteren, die direkt auf unseren Prozess zugeschnitten waren. Auf den Karten hielten wir neben der Aufgabe auch die Anzahl der Feedback-Schleifen und die Cycle Time fest, also die Zeit vom Anfang der Bearbeitung bin zum erfolgreichen Abschluss. Unser Board erarbeiteten wir uns in einem Team-Kick-Off-Termin mit Unterstützung von agile42, die Aperto bei agilen Prozessen beraten. Es war — wie man sieht — nicht besonders schön, aber dafür leicht zu bearbeiten, wenn uns auffiel, dass wir beispielsweise noch eine neue Spalte brauchten.

Denn die erste Version eines Kanban-Boards ist immer nur das: eine erste Version. Wie gut es darin ist, die Realität abzubilden, merkt man erst, wenn man damit arbeitet — und es dann immer wieder hinterfragt und verbessert.

Maßnahme 3: Auf Unnötiges verzichten

„Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.“

Das ist ein weiteres agiles Prinzip: sich auf die Dinge zu konzentrieren, die dem Kunden direkten Mehrwert bringen und vom Rest so viel wie möglich wegzulassen. In der Praxis hieß das für uns auf den kleinteiligen Projektplan zu verzichten und auch alle anderen Prozesse und Auslieferungsgegenstände auf das Nötigste zu reduzieren. Wir stimmten beispielsweise immer über ein „Look & Feel“ mit dem Kunden die generelle visuelle Richtung der jeweiligen Content-Seite ab. Dieses bestand zuvor aus einer hübschen Präsentation, die aber recht aufwändig zu erstellen war. Unser Designer kam auf die Idee, die entsprechenden Bilder und Beschreibungen einfach bei Confluence hochzuladen — was zwar nicht ganz so toll aussah, aber trotzdem den Zweck erfüllte und dem Kunden auch die Möglichkeit gab, direkt am Dokument Fragen zu stellen.

Das Ergebnis

Das Experiment lief über einen Zeitraum von etwa drei Monaten. Dass das Team zufriedener war und die Kommunikation reibungsloser klappte, war sehr schnell klar. Der Kunde war ebenfalls höchst zufrieden: Er war bei jedem Arbeitsschritt dabei und konnte früh Feedback einbringen. Die Sorge, dass dadurch wesentlich mehr Änderungswünsche kommen könnten, hat sich nicht bestätigt. Vielmehr lernten wir von Woche zu Woche die Vorstellungen des Kunden besser kennen und konnten so die Feedbackschleifen mit der Zeit reduzieren.

Die Teammitglieder kannten sich besser, kommunizierten schneller und hatten mehr Spaß. Letzteres lag sicherlich auch daran, dass es einfach ein schöneres Gefühl ist, sich eine Aufgabe selbst zu nehmen und ihre Auswirkung auf das große Ganze zu kennen, als etwas auf den Schreibtisch gelegt zu bekommen und danach wieder aus den Augen zu verlieren.

Man fühlt sich, als würde einem mehr zugetraut: mehr Verantwortung, mehr Kreativität und die Entscheidungsfreiheit, die Aufgabe so zu lösen, wie man es für richtig hält. Das motiviert.

Aber wie sieht es mit der Effizienz aus? Um das herauszufinden, hatte ich für eine bestimmte Anzahl von Conten-Seiten aus dem Zeitraum vor unserem Experiment errechnet, wie viele Stunden jedes Team-Mitglied durchschnittlich geleistet hatte. Das konnte ich dann mit dem Durchschnitt aus den Content-Seiten seit Beginn unseres Experiments vergleichen. Das Ergebnis ist erstaunlich. Bestimmt ist es nicht ausschließlich auf die agilen Methoden zurückzuführen, sondern auch darauf, dass wir als Team immer besser eingespielt waren. Doch ich denke unsere Methoden hatten einen großen Anteil daran.

Insgesamt konnten die Aufwände pro Seite durchschnittlich um 32 % reduziert werden. Besonders merklich war das beim Design (41 % weniger) und beim Client Management (44 % weniger).

Unsere Ziele hatten wir also erreicht! Mich überraschte vor allem, wie gut die interdisziplinäre Zusammenarbeit klappte und wie viel wir voneinander lernen konnten. Am wichtigsten aber war für mich die Erkenntnis, dass man durchaus auch Content agil entwickeln kann und dass es dafür nicht unbedingt eine bestimmte Software oder Zertifizierung braucht, sondern vor allem eines: ein agiles Mindset.