Wir sind nicht nur als Slogan #herzblutonliner, sondern aus Überzeugung – und das soll sich auch in unserer Arbeitsweise spiegeln. Wie unser Weg hin zu agilem Arbeiten verlaufen ist, wollen wir in diesem Text nach und nach beschreiben.
#herzblutonliner: Den Worten folgen Taten
Agiles Arbeiten ist für uns kein Lippenbekenntnis, sondern das ernsthafte Bestreben, unsere Fähigkeiten optimal einzusetzen, um die Bedürfnisse unsere Kunden noch besser erfüllen zu können sowie ein wertschätzendes Arbeiten zu fördern.
In diesem Text, der nach und nach erweitert werden wird, wollen wir über unsere Beweggründe, Erfahrungen und auch Rückschläge berichten. Sie wollen von Änderungen erfahren? Folgen Sie uns auf LinkedIn oder melden Sie sich für unseren Newsletter an.
Gründe für die agile Transformation
Als Digitalagentur arbeiten wir mit Kund:innen einerseits bei großen und komplexen Website-Projekten zusammen, die meist über einen relativ klar definierten Zeitraum laufen – z.B. komplette Relaunches, oft auch mit direkter Anbindung der Website an interne Systeme und Daten. Andererseits betreuen wir aber auch langfristig angelegte Maßnahmen, die im Umfang geringere, aber kontinuierlich auftretende Arbeiten erfordern.
Wir haben uns überlegt, wie es uns gelingen kann, diese unterschiedlichen Typen von Aufgaben intern besser unter einen Hut zu bringen. Wie also können wir unsere Arbeit so organisieren, dass wir den Bedürfnissen unserer Kunden noch besser und schneller nachkommen und es für uns einfacher wird, kleine Aufgaben und große Projekte parallel durchzuführen.
Agil nach innen, flexibel nach außen
Dabei spielte es für uns natürlich auch eine Rolle, dass wir vermeiden wollten, dass sich Phasen großer Belastung mit Zeiten abwechseln, in denen sehr wenig zu tun ist. Die Arbeitslast sollte sich möglichst gleichmäßig verteilen. Eine agile Arbeitsweise, bei der die Teams selbst einschätzen, welche Arbeit sie in welchem Zeitraum realistisch abarbeiten können, ist dafür ein sehr guter Weg.
Zugleich war uns bewusst, dass diese Arbeitsweise nicht immer dem Vorgehen entspricht, dass unsere Kund:innen praktizieren oder praktizieren können. Deshalb arbeiten wir mit ihnen je nach Anforderung und Projekt sowohl agil nach Scrum als auch “konventionell” zusammen, zum Beispiel mit einem Projektplan, der nach dem Wasserfallprinzip funktioniert.
Unsere interne Arbeitsplanung allerdings, so der Plan, wollten wir für alle Aufgaben agil mit Kanban umsetzen, vor allem auch um die Rolle der einzelnen Kolleg:innen in den Teams zu stärken.
Denn wir verstehen uns als Agentur, in der die einzelnen Mitarbeiter:innen nicht nur aufgrund ihrer Expertise geschätzt werden, sondern auch aufgrund ihrer individuellen Persönlichkeit. Um diese entfalten zu können, brauchen sie bei ihrer Arbeit viel Freiraum und sollen Verantwortung übernehmen können.
Da ist es nur konsequent, dies auch ins Zentrum unserer organisatorischen Neuorientierung zu stellen, wie es eine agile Arbeitsweise notwendigerweise tut, in der die Arbeit nicht von oben verteilt wird, sondern innerhalb eines Teams geschätzt, strukturiert und übernommen wird.
Freiheit und Verantwortung
Vor allem haben wir mit der Neuorganisation auch kleine, interdisziplinäre Teams (bei uns “Squads” genannt) geschaffen, die sich jeweils auf einen festen Kundenstamm ausrichten, ihre gemeinsame Arbeit beständig selbst weiterentwickeln und in denen der Austausch zwischen den unterschiedlichen Disziplinen intensiviert werden kann.
Die Arbeitsweise im Wasserfall führt leider häufiger dazu, dass die unterschiedlichen Disziplinen asynchron arbeiten und der Austausch über die Disziplingrenzen zu kurz kommt – das soll sich ändern, denn nur im Dialog entstehen die bestmöglichen Lösungen für unsere Kund:innen, und wir können auch über den Tellerrand unserer eigenen Arbeit hinausschauen und dadurch dazulernen.
Damit wollten wir auch den einzelnen Mitarbeiter:innen die Möglichkeit geben, ihre eigene Arbeit stärker selbst planen und einteilen zu können – die Erfahrung zeigt, dass das nicht nur die Zufriedenheit steigert, sondern auch dafür sorgt, dass die Mitarbeiter:innen gerne Verantwortung für ihre Aufgaben übernehmen.
Zugleich erhoffen wir uns von dieser Transformation auch, dass wir als Agentur flexibler auf Anforderungen von außen reagieren können, das bedeutet insbesondere:
- Kundenbedürfnisse besser erkennen und erfüllen
- Umsetzungsgeschwindigkeit erhöhen
- Zukunftsfähigkeit sichern
Was bedeutet agile Transformation für eine Agentur wie uns?
Die Umstellung unserer Agentur auf eine agile Arbeitsweise im laufenden Betrieb war und ist natürlich eine große Herausforderung. Zwar hatten wir schon gute Erfahrungen mit Scrum auf Projektebene gesammelt, aber die Neuorganisation der ganzen Agentur stellte sich doch noch einmal anders dar.
Transformation benötigt Zeit, Planung und Geduld
Der zeitliche Aufwand für die Planung und Umsetzung der Transformation darf nicht unterschätzt werden. Über ein halbes Jahr hinweg gab es regelmäßigen Austausch zwischen verschiedenen Beteiligten.
Unsere Erfahrung dabei hat gezeigt, dass es wichtig ist, alle Mitarbeiter:innen möglichst frühzeitig zu informieren und einzubinden. Das heißt nicht, dass alle Entscheidungen im Konsens aller Mitarbeitenden geschehen müssen – das ist ja oft gar nicht möglich.
Viele Wünsche und Verbesserungsmöglichkeiten waren schon bekannt – wir reden miteinander. Zugleich haben wir zusätzlich – informell über einzelne Gespräche und z.B. über kleine Pilotprojekte als Testballons – geprüft, welche Arbeitsweise bei den Kolleg:innen auf Interesse und Zustimmung stößt. Auf dieser Basis kann dann für den Beginn der Transformation bereits ein Rahmen vorgegeben werden:
- Welche agile Methode verwenden wir genau?
- Welche Meetings werden für die einzelnen Squads festgelegt?
Transformation ist ein Teamsport
Innerhalb dieses Rahmens sollten, so unsere Erfahrung, die Squads jedoch die Möglichkeit haben, sich selbst zu organisieren. Wir haben uns z.B. für die Nutzung von Kanban-Boards entschieden – wie diese genau ausgestaltet werden, entwickelt jedes Squad für sich. So können auch die Squads gegenseitig von unterschiedlichen Ansätzen in der Ausgestaltung lernen.
Unser Ansatz sieht vor, dass in der derzeit alle 2 Wochen stattfindenden Retrospektive besprochen wird, was gut gelaufen ist und was noch optimiert werden muss … und welche Veränderung möglicherweise eine Verbesserung bringen kann. Diese Veränderung kann dann ausprobiert und getestet werden, bevor sie übernommen oder wieder rückgängig gemacht wird. Das Ziel: Jeder Arbeitszyklus führt auf ein “inspect and adapt” hin, einen Rückblick, der Anpassungen für die Zukunft vorschlägt.
So wird die Arbeit mit den Boards, im Team und in den Terminen iterativ optimiert (und manchmal natürlich auch verschlimmbessert). Dies kann nur in Zusammenarbeit und im Team passieren, erfordert aber Freiraum und vor allem Zeit für alle Mitarbeiter:innen – das darf nicht unterschätzt werden! Die gelegentlich aufscheinende Frustration, dass nicht alles sofort klappt und funktioniert, sollte möglichst durch die Motivation ausgeglichen werden können, dass die Mitarbeiter:innen sich weiterentwickeln können und selbst Einfluss darauf haben, wie ihr Arbeitsalltag organisiert ist.
Transformation braucht einen entschlossenen Übergang
Eine Frage, die uns sehr beschäftigt hat: Wie gelingt uns der Rollout, der Übergang in den einzelnen Projekten von der alten Arbeitsweise zum agilen Vorgehen?
Die ehrliche Antwort lautet: Es ist gar nicht so einfach.
Zunächst hatten wir überlegt, als erste Maßnahme alle Arbeitsprozesse, die wir im Rahmen langfristiger, fortlaufender Betreuung mit teilweise festen Stundenkontingenten absolvieren, auf Scrumban umzustellen. Erst im zweiten Schritt sollten dann die abgeschlossene, größere Relaunch-Projekte folgen. Das war keine gute Idee.
Denn der Versuch, die Projekte so aufzuteilen, hätte insgesamt für großes Durcheinander gesorgt, weil auf einmal in allen Teams parallel nach beiden Vorgehensweisen gearbeitet worden wäre.
Vom Erfahrungskurveneffekt profitieren
Gute Erfahrungen haben wir allerdings damit gemacht, nicht in allen Teams zur gleichen Zeit mit dem Rollout zu beginnen. Denn so wurden nicht alle Squads zeitgleich mit ähnlichen Anfangsproblemen konfrontiert. Stattdessen konnten die “Early Adopter” ihre ersten Erfahrungen machen und an die anderen Squads weitergeben, so dass diese nicht alle Fehler nachmachen mussten.
Eine zusätzliche Komponente gestaltete den Übergang bei uns komplizierter: Mit der Einführung des Kanban-Systems sollten künftig grundsätzlich feste Teams als Squads zusammenarbeiten. Allerdings stimmten zu Beginn diese Squads nicht mit jenen Teams überein, die bei bereits bestehenden Projekten zusammenarbeiteten – und diese Teams sollten selbstverständlich bis zum Abschluss der Projekte nicht getrennt werden.
So gab es einen Zeitraum, in dem die Arbeit nicht nur in den Squads organisiert wurde, sondern manche Teams auch über Squadgrenzen hinweg an bestimmten Projekten arbeiteten – aber auch in diesem Kontext wurde bereits Kanban genutzt, um so ein Durcheinander zu vermeiden, dass entsteht, wenn zwei unterschiedliche Formen der Arbeitsorganisation parallel zueinander laufen.
Bald geht es weiter
Die Transformation unserer Arbeitsweise war bis jetzt nicht ganz ohne kleine und große Unebenheiten – richtig interessant wird es natürlich in der Umsetzung und in der Zusammenarbeit mit Externen. Und jede Veränderung bringt erst einmal neue Herausforderungen, an die vorher niemand gedacht hat.
Veränderung ist Chance und Risiko zugleich. Wir versuchen, die Risiken zu minimieren, und ergreifen die Chancen, die sich auftun.
Ronald Hajdo, Gründer und Geschäftsführer von VERDURE
Sie wollen über unsere Erfahrungen bei diesem Prozess auf dem Laufenden bleiben? Melden Sie sich jetzt für unseren Newsletter an!