2 Jahre agil als Marketer – The Good, The Hard, The Ugly

Agil arbeiten ist definitiv anders als agil predigen: Nach 2 Jahren als agiles Dev-Team-Mitglied gibt es hier jetzt – meine ganz subjektiven Eindrücke – vom Arbeiten in einer agilen Organisation.

Etwas über zwei Jahre ist es her, dass wir uns bei nexible dazu entschieden haben, alle Funktionen des Unternehmens progressiv auf agile Fundamente zu stellen: Egal ob Backend- oder Business-Development, alle Beteiligten waren plötzlich an agile Grundwerte und Vorgehen gebunden. Mit diesem Umbau wurde ich Teil des Teams, das Entwicklung und Darstellung des Frontends verantwortete. Das bedeutete für mich als Marketer by Trade zwar nicht, dass Kampagnen-Optimierungen ab sofort in diesem Rahmen passierte, aber viele meiner anderen Tätigkeitsfelder (Tracking-Implementierung, Business Analytics, Web Experimentation, On-Page SEO) rutschten dadurch in Kanban-Prozesse und wurden deutlich kollaborativer durch die Partizipation mehrerer Team-Members innerhalb dieser Themenkomplexe.

Für mich – der eigentlich im Laufe seiner Karriere immer das Neue, Digitale bzw. Innovative gesucht hat – war dies ein interessante Umstellung. Dies mag überraschend klingen wenn man als Berater bereits Scrum Zertifizierungen geführt hat, die es einem erlaubt haben in den Zombie-Scrum Organisationen seines Kunden zu arbeiten (ich kannte vorher schon alle Buzz-Words). Das echte agile Leben ist aber noch einmal deutlich anders.

Diese Umstellung hat mein Denken über Organisationen und Organisationspsychologie nachhaltig verändert. In diesem Beitrag werde ich meine signifikantesten Erfahrungen und Learnings aus der Vergangenheit teilen: Ohne Garantie auf Vollständigkeit, kein Anspruch auf korrekte Einschätzung der Ereignisse und Gegebenheiten.

Das ganze ist in drei Meta-Kategorien geteilt:

1. The Good – spannende, positive Erfahrungen und Erkenntnisse im agilen Arbeiten der letzten Arbeiten.
2. The Hard – Challenges, die ich und meine Kollegen in den letzten Jahren individuell und im Team zu meistern hatten.
3. The Ugly – störende und hinderliche Auswüchse in meiner agilen Welt.

Rahmenbedingungen und Einschränkungen

Das agile Enforcement in meiner Umgebung beinhaltete vor allem, dass sowohl technische als geschäftliche Entwickler sowie weitere Experten in dedizierten Teams vereint wurden.

In meiner Grundphilosophie bin ich kein Scrum Master Product Owner agiler Prediger, der das Wort des Scrum Guides als heilig betrachtet, in jedem Meeting zitiert und keine göttlichen Schriften daneben zulässt. Ich bin Dev Team Member – nicht mehr, nicht weniger. Meine Grundeinstellung als Manager besagt vor allem, dass es mein Job ist innerhalb einer Organisationsstruktur oder daran vorbei Initiativen auf den Weg zu bringen, die Wert stiften. D.h. ich muss z. B. wissen, dass ich in einer Top-Down-geführten Organisation meinen Chef häufig zum Essen einladen muss, um meine Themen platziert und implementiert zu bekommen. Entsprechend gibt es in meinem Verständnis von Management und Organisation viele Wege (neben agilen Frameworks) zum Ziel / Erfolg zu kommen. Ob die dann Spaß machen oder erfüllend sind, steht auf einem anderen Blatt geschrieben …

The Good – Think for yourself

„Agil“ bedient sich an grundlegenden menschlichen Bedürfnissen

Von vielen bisher erlebten Arbeitsmodellen sind agile Herangehensweisen aus meiner Sicht diejenigen, die sich am nächsten an menschlichen Bedürfnissen und natürlichen Verhaltensmustern bewegen. Mehr noch: Sie machen diese Verhaltensweisen für die Organisation und ein Produkt überhaupt erst nutzbar. Damit meine ich grundlegende Mechaniken des menschlichen Verhaltens:

• Menschen haben einen höheren Qualitätsanspruch an Dinge und Initiativen, mit denen sie nach außen und nach innen persönlich verbunden sind (oder ihr Name dran steht).
• Es fällt Menschen schwer Dinge zu fokussieren oder zu erreichen, die entweder sehr sehr groß sind (Vorstellungskraft) oder sehr weit in der Zukunft liegen (Geduld & Abstraktion).
• Menschen möchten von Natur aus partizipieren und bei etwas mithelfen – häufig auch abseits von (zusätzlicher) monetärer Kompensation.
• Menschen haben zu nahezu allen Umständen in ihrem Leben eigene Ideen und Meinungen.
• Menschen in Gruppen haben (entgegen populärer Meinung) ein intrinsisches Interesse sich nicht als schwächstes, langsamstes oder faules Mitglied in einer Kette zu sehen und arbeiten proaktiv um dies zu vermeiden.

In agilen Strukturen können viele dieser Verhaltensweisen deutlich besser utilisiert werden als in klassischen Modellen: Übertragung von Ownership an selbstorganisierte Teams, Break-Down von Missionen in kleine erreichbare Etappen, kollaborative Refinements und aktive Mitgestaltung finden hier deutlich bessere Anwendung als in Prozessen, die designed werden um Verantwortung und Entscheidungsfreiheiten von Individuen zu reduzieren. Die Erfahrungen waren dabei in vergangenen Jahren immer wieder beeindruckend: Team-Members, die ihre “Spezialisierungen” vergessen und dem Gesamtfortschritt der Organisation zu helfen, Menschen die proaktiv Resultate von Initiativen präsentieren oder Kollegen, die zusätzliche Arbeit investieren, um etwas on-time oder viel besser zu releasen.

Quality Assurance über agile Prozesse

Dass Produkte aus nachhaltiger agiler Produktion in meiner Wahrnehmung besser sein können als andere zeigt bereits der erste Punkt. Eine weitere interessante Agil-Erfahrung ist aber auch, dass Quality Assurance über agile Prozesse deutlich einfacher ist als erwartet.

Zum einen kommen viele Frameworks (Scrum, Kanban) aus der Box bereits mit geplanten Iterationsschleifen und Reviews daher. Wenn korrekt implementiert, hat man aber auch zusätzlich jederzeit fünf bis sechs Dev-Team Members die die Augen offen halten auf der Suche nach Fehlern oder Fehlkonzeptionen vor einem Produkt-Release – weil sie ein intrinsisches Interesse am Produkt und dessen Funktionalität haben. Entsprechend mitigieren agile Methoden in vielen Fällen auch typische Not My Department Kulturen. Dieser Mechanismus entfaltet seine volle Kraft meistens aber noch vor dem ersten Bleistiftstrich: So eignen sich gute agile Teams auch sehr gut dafür dumme und fehlerhafte Ideen in der Entstehung zu erkennen und zu eliminieren – noch bevor eine Art von Ressource darin investiert wurde.

Eine der überraschendsten Erfahrungen im agilen Kontext war bei mir aber sicherlich die Modellierung von Prozessen und Kontrollen auf Basis von agilen Workflows. Die Haupterkenntnis: Mit etwas Improvisations-Sinn kann man aus einem einfachen Kanban-Board einen risikofreien Finanz-Konzern-Prozess mit Kontrollen modellieren. Eine Aussage, die ich gerne jedem Konzern-CEO erläutere, der auf agile Methoden aufgrund von Risiko-Bedenken oder der Zugehörigkeit zu einer stark regulierten Industrie verzichten möchte.

Zahlen, Hypothesen und Experimente – Meine persönliche Situation

Rückblickend (und auch vorausschauend) amplifiziert agiles Arbeiten meine Stärken, Eigenschaften und auch meine Produktivität: Ich bin in meiner Natur sehr analytisch, zahlengetrieben und faul (in dem Sinne, dass ich nicht gerne Arbeit für etwas investiere, dass ich als sinnlos erachte). Was ich traditionell nicht so gut kann: Reden mit und über Gefühle schwingen oder in einem Raum mit 10 Leuten am lautesten schreien. Der agile Arbeitsmodus hat meine persönliche Arbeitsweise in drei verschiedenen Dimensionen verbessert bzw. supported:

1. Die zahlen-getriebene Value-Betrachtung der Unternehmungen hat vielen meiner Ideen in der Organisation mehr Raum zum atmen gegeben als das in einer Welt, die qualitativen Herangehensweisen und lauten Forderungen bestimmt wird, der Fall gewesen wäre.
2. Die Notwendigkeit große Unternehmungen in kleinere Versionen herunterzubrechen hat mir und uns in Vergangenheit viel Arbeit gespart. D.h. es war immer wieder aufs Neue möglich die Sinnhaftigkeit von Aufgaben und Features frühzeitig zu belegen bzw. zu widerlegen.
3. Das Hypothesenbasierte Arbeiten innerhalb von agilen Teams verknüpft Aktivitäten aus dem echten Leben direkt mit der Zahlenwelt, die sich sonst mit dem Abstrakten und Aggregierten beschäftigt. Durch die Ausbildung einer Hypothese wird es einfacher Metriken zu benennen, die sich im Falles eines Gelingens oder Misslingens verändern werden. Die tatsächliche Prüfung der Hypothese füllt dann die entsprechenden Datenbanken mit Empirie.

The Hard – Do you think agile is easy?

Nicht alles in der agilen Welt ist rosig. Wer glaubt mit der Beschaffung von 10 jira-Lizenzen und einem Stand-Up-Regeltermin würden Teams besser und produktiver arbeiten, der kann sich noch auf die ein oder andere Überraschung freuen. Im Laufe der letzten zwei Jahre mussten wir als Team viele Learnings verbuchen – hier zusammengefasst als “The Hard”.

Verlerne, was du du gelernt hast: Denken und Mitreden

Ohne das Skill-Level von Kollegen und Team-Mitgliedern herabwürdigend zu wollen, ist eine der größten Herausforderungen für selbstorganisierte, agile Teams sich das selbstständige Denken zwischen 9 Uhr und 18 Uhr wieder beizubringen. Was platt und herablassend klingt, ist aus meiner Sicht lediglich eine natürliche Konsequenz aus weit-verbreiteten Sozialisierung-Bräuchen in unserer Gesellschaft. Auch wenn Erziehung uns heutzutage mehr Freiheiten in der Verfolgung unserer Träume einräumt, scheint das Gesetz der Malocher noch immer zu gelten:

Klingt bekannt? Tatsächlich ist es für uns als Menschen auch ein sehr komfortabler Operationsmodus. Ein paar meiner Lieblings-Nebenjobs aus den vergangenen Jahren haben keine kognitive Eigenleistung meinerseit erfordert.

Im täglichen agilen Arbeiten hat man diese Challenge an verschiedenen Stellen gemerkt:

• Im Kontext von agilen Teams sind Aufgaben häufig sehr offen gehalten. D.h. lediglich das Was ist gegeben und das Wie muss den Team-Members noch erdacht werden. Entsprechend sind Qualität und Geschwindigkeit der Implementierung maximal von Denkfähigkeit der einzelnen Team-Members abhängig.
• Häufig merkt man erst im Laufe einer Implementierung, dass Fehler hätten vermieden werden können, wenn mehr Leute Konzept und Ansätze beleuchtet hätten.
• Nur wenn alle Mitglieder eines agilen Team in der Lage sind Ideen von außen kritisch und fundiert zu hinterfragen, kann vermieden werden, dass wenig relevante Features und Konzepte in die Umsetzung gelangen.
• Auffällig ist des Weiteren wie agil-getriebene Systeme von Menschen abhängig sind, die ihre eigenen Gedanken in Gruppen kundtun können, da sonst kollaborative Formate wie Retros und Refinements weitestgehend wirkungslos, wenn nicht sogar kontraproduktiv in Schweigen enden. In meinem persönlichen Eindruck können stärker hierarchische Systeme schweigende und passive Mitglieder besser kompensieren.

Ich produziere etwas? – Iterationen bestimmen

Eine weitere erschreckende wie erleuchtende Erkenntnis aus dem Start des agilen Vorgehens war diese: Wir alle, die wir Experten für unsere Gebiete sind, wissen wie das Endresultat unserer Arbeit aussehen soll. Wir haben sogar gelernt in Währungen wie Tagen, Wochen und Monaten so rückwärts zu planen, dass wir am Ende genau am heutigen Tag wieder rauskommen. Aber: Wehe jemand fragt uns, was wir auf dem Weg zu diesem Endresultat zwischendurch produzieren! Aus welchen separaten Komponenten besteht unser Zielbild? Welche Dateiformate entstehen zwischendurch? Wer arbeitet damit weiter?

In einem Sprint-Vorgehen führt diese implizite Lernkurve anfänglich immer wieder zu Problemen. Eine Sprintlänge orientiert sich nicht an der Balken-Länge einer Rückwärtsplanung. Wer keine Iterationen von seinen Unternehmungen ableiten kann, der kann nach Ende eines Sprints nichts releasen und kann keine kollaborativen Sprint-Ziele formulieren.

Um ein Beispiel aus der Marketing-Welt zu nehmen, das die Problematik von Zwischenprodukten verdeutlichen soll. Eine Kampagne – sei sie Marken- oder Performance-orientiert – kann verschiedene Komponenten haben, die in der ein oder anderen Form released werden können:

• Ein spezifischer Kanal, der bereits Werbemittel ausspielt (in der Abgrenzung zu einem Go-Live in allen Kanälen zur gleichen Zeit)
• Ein finales Banner-Set in 10 Formaten und zwei Variationen, das in die Aussteuerung übergeht und somit den Realm des Teams verlässt.
• Fertige Keyword-Cluster, Zielgruppen-Analysen (vllt. Als Excel-Doc oder Datenbank) etc., die intern produktiv sind, sobald andere Teams darauf arbeiten (können).
• usw.

Dieses Herangehen ist in vielen anderen erlernten Vorgehen (Big Bang) kontra-intuitiv, kann aber mit höherer Awareness für das tägliche Arbeiten schnell erreicht werden. Diese Challenge kann häufig durch Erfahrung innerhalb eines Teams etwas kompensiert werden. Denn: Wer schon häufiger bis zum Endprodukt gearbeitet hat, kann sich tatsächlich an Inkremente erinnern, die währenddessen Dreh- und Angelpunkt der Arbeiten waren und muss sich diese nicht abstrakt vorstellen.

Leute, die immer noch glauben, dass “agil” dieses Ding “ohne Planen” sei, werden in diesen Szenarien feststellen, dass agil häufig “Planen auf Steroiden” ist, weil ich in der Implementierung den Prozess der Planung in diversen Iterationen von vorne nach hinten und wieder zurück durchlaufe. Es ist so etwas wie ein Time Travel Paradoxon der agilen Arbeitswelt: Ich muss in meinem Kopf den Weg bis zum Ende gegangen sein, um nicht von Beginn an gezwungen zu sein den ganzen Weg gehen zu müssen, um produktiv oder effektiv zu werden.

Die Grenzen von Ressourcen und Fähigkeiten

Ein häufiger Knackpunkt beim Setup von agilen Teams ist die Bereitstellung von dedizierten Ressourcen in Form von Menschen und Technologie:

• Spezialisten (kommen Sie aus Technologie oder Business) sind ein seltenes und teures Gut und werden als Privileg verwaltet. Die Abstellung eines absoluten Experten für nur einen Purpose ist mit der klassischen Management-Brille quasi Veruntreuung.
• Technische Systeme sind wie deutsche Vorgärten. Sie gehören umzäunt und partitioniert. Niemand hat etwas im Garten des Nachbarn zu suchen, wenn nicht explizit zur Grillparty eingeladen wurde.

Wer diese Art von Denken als Organisation beilegen kann, der kann überlegen agil umzustrukturieren und den agilen Teams End2End-Fähigkeiten zu ermöglichen – meine Meinung. Aus den Erfahrungen der letzten Jahre gibt es keine größeres Hemmnis für agile Teams als technische Entwickler, die für 5 Teams und Produkte gleichzeitig arbeiten oder ein Experte, der nur Sonntag zwischen 17 Uhr 18 Uhr gebucht werden kann und jedes Sprint-Ziel reißt.

Auf der System-Zugriffsseite ist es immer wieder interessant zu sehen, dass Teams aus eigenen Erfahrungen aktiv daran arbeiten geschlossene Systeme abzulösen, mehr Durchgriff in der eigenen Plattform einplanen und bereitwillig Ownership für angrenzende System übernehmen möchten – nur um dadurch schneller produktiv werden zu können.

Damit verknüpft ist es eine weitere Erfahrung, die ich im Kontext agil teilen möchte: Mit einem höheren Fokus auf End2End-Fähigkeiten wird man als Dev-Team-Member auch immer wieder herausgefordert neue Fähigkeiten zu erlernen. Was manchmal spannend ist, wirft Leute an manchen Stellen auch direkt aus der Komfortzone ihrer Kern-Expertise – für das große Ganze. Aber es ist schon zu beobachten, dass Members von agilen Teams eher in der Lage sein müssen neue Fähigkeiten zu erlernen und vor allem Lernen zu wollen. Dies ist kein zwangsläufiger und absoluter Zustand in meiner Einschätzung. Man macht keinen Mathematiker zu einem Gärtner oder andersherum. Wenn gewisse Expertisen innerhalb eines Teams wiederkehrend fehlen, kann das Team angepasst oder erweitert werden. Aber es kann schonmal sein, dass ein Mathematiker dann mal für einen Tag zum Marktforscher werden muss.

The Ugly – Wo sich Kontrolle und Deadlines die Klinke in die Hand geben

Zugegeben, ich habe noch nicht viele hässliche Szenarien im agilen Kontext gesehen und die meisten waren noch zu retten. Ich habe aber mal ungewöhnliche oder riskante Auswüchse von agilen Methoden, die ich bisher gesehen habe, in zwei Themen-Cluster gefasst:

Metaplanwand-Mania: Ein Projekt, 5 Sichten

Das erste agil-Phänomen, das ich beobachtet habe, habe ich Metaplanwand-Mania in meinem Kopf getauft: Es beschreibt die Duplizierung von Aufgaben, Projekten, Zielen und Initiativen über verschiedene Dimensionen innerhalb einer Organisation und Erstellung verschiedener Sichten auf ein und dieselben Sachverhalte.

Bottom Up kann man es sich so vorstellen: Ein Team hat ein Board, ein Backlog und Items, die Aktivitäten von kleinen Spezifika bis hin zu großen Meta-Initiativen dokumentieren und visualisieren. Aus Transparenz-Prinzipien sind diese Sichten meistens für nahezu alle Teilnehmer der Organisation einsehbar. D.h. Person A kann hergehen daraus eine neue Sicht bauen, die sein Bedürfnis zu sequentiellen Abfolgen befriedigt und arbeitet damit weiter. Person B wiederum will nur Überschriften und keine Vorgehen für seine Kommunikationszwecke und arbeitet mit seiner Sicht weiter. Person C wiederum schaut immer gerne, was alles und wie viel gleichzeitig stattfindet und produziert Sicht #3. Sicht vier entsteht dann zum Beispiel durch die Zuordnung von Datumsangaben zu Aktivitäten und Initiativen.

Je nach Einsatz, Legitimierung, Zweck und Verankerung dieser Sichten innerhalb der Organisation können diese zu zwei hässlichen Problemen führen:

1. Sind die Teams für die akkurate Füllung der verschiedenen Sichten verantwortlich führt dies relativ schnell zu Mehrarbeit, Waste und Frustration.
2. Mit dem Stille-Post-Prinzip weichen die verschiedenen Sichten mit zunehmender Zeit voneinander ab. Priorisierungen ändern sich und Organisations-Teile außerhalb der gemonitorten Teams nehmen veraltete Informationen für bare Münze in ihrer täglichen Arbeit.

Diese Auswüchse entstehen häufig durch das Bedürfnis für Information außerhalb der Teams (klassisch genannt Stakeholder Management), das aber aber häufig gepaart wird mit der Tatsache, dass die Sichten-Ersteller zu Terminen der Reviews oder Demos Parallel-Termine haben. Der Weg aus diesem Dilemma ist nicht schwarz oder weiß. Es ist nicht verkehrt mehr als eine Sicht auf Vorgänge innerhalb von Teams zu haben. Allerdings bietet sich die aktuellste Sicht – die des Teams – jedoch meistens als führende und dominante Sicht an.

Agil und Deadlines: Eine missverstandene Hassliebe

Hässlich wird in agilen Modi auch häufig wenn Deadlines mit ins Spiel kommen. Nach 2 Jahren sehe ich das Verhältnis zwischen agilen Frameworks und Deadlines als Hassliebe. Diese wird in vielen Kontexten noch von Vorurteilen und Missverständnissen befeuert. Ohne zu ausufernd werden zu wollen, hier ein paar Anmerkungen zu dieser Beziehung.

1. Aus meiner Sicht ist es möglich zu sagen, dass man agile Methoden verwenden kann um Deadlines schneller und besser zu halten.
2. Deadlines können auch die Priorisierung innerhalb agiler Methoden leiten / informieren.

Im zweiten Szenario stoßen Deadlines aber häufig auf Frustration in Teams und womöglich auch bei Deadline-Gebern. Deadlines haben in agilen Organisationen manchmal die Eigenschaften oder mindestens den Geruch eines Value- und Priorisierungs-Workarounds. Während die proaktive Entwicklung von Features und Initiativen innerhalb der Teams häufig ausgiebigen Value-Betrachtungen und Case-Rechnungen unterliegen, passiert es schnell, dass Deadline-Themen ohne die Anlieferung dieser Informationen ihren Weg in Backlogs finden. Darüber hinaus sind Deadline-Themen häufig auch absolut und in der Implementierung perfekt, sodass die entsprechenden Iterationen des Endbilds nicht angeliefert werden können.
Dies sind nur ein paar Aspekte, die das Spannungsfeld agil und Deadlines ein wenig erklären soll.

Aus der reinen Development-Team-Perspektive sind Deadlines immer schwer zu handeln. Interessante Beobachtungen sind jedoch, dass traditionell Ansagen aus einem Team wie …

Das ist Prio 1 bei uns!

Es ist das Sprint-Ziel!

Das kommt als nächstes!

… mehr wert sind als die bloße Nennung eines Wochentages mit einem spezifischen Datum dahinter.