Agile Praktiken: So vermeiden Sie Fehler Unser Marketing-Team hat Fehler gemacht

Das Geheimnis ist gelüftet. Agiles Projektmanagement verändert das Spiel - und Entwickler und IT-Mitarbeiter sind nicht mehr die einzigen, die davon erfahren.

Als Vermarkter haben Sie sicherlich von Agile gehört. Ihr Team verwendet möglicherweise einige agile Methoden wie Projektsprints und Stand-up-Meetings. Wenn ja, sind Sie in der Minderheit. Die Vorteile von Agile werden von Marketingteams noch weitgehend nicht genutzt. Laut einem neuen Bericht von Workfront und MarketingProfs verwenden nur 30% der Marketingteams einen agilen Ansatz, um ihre Prozesse zu verwalten. Die anderen 70% erleben wahrscheinlich die gleichen Frustrationen, die mein Team erlebt hat, bevor wir uns dazu verpflichtet haben, Agile zum Laufen zu bringen.

Unser siebenköpfiges Marketing-Team bei Emplify praktiziert seit fast einem Jahr Agile. Wir haben sechs Monate gebraucht, um es gut zu üben: Arbeit besser, schneller und mit mehr Energie und Engagement zu produzieren.

Als wir anfingen, Agile zu üben, haben wir viele Fehler gemacht. Tatsächlich so viele Fehler, dass wir eines Tages die Hälfte unseres Teams in einem Konferenzraum einsperrten und nicht gingen, bis wir einige wesentliche Mängel in unserem Ansatz festgestellt und behoben hatten. Zum Glück gab es Bier und es war ein Freitag. Trotzdem war es schmerzhaft und es dauerte einige Zeit, bis wir uns aus einigen tiefen prozessorientierten Löchern herausgegraben hatten.

In diesem Artikel teile ich diese Fehler, damit Sie eine schmerzhafte Blockade wie unsere vermeiden können. Agile kann die Fähigkeit Ihres Marketingteams revolutionieren, schneller zusammenzuarbeiten und Arbeit zu liefern - wenn Sie sich dazu verpflichten, dass der Prozess für Sie funktioniert.

Bevor wir beginnen, wollen wir einige Grundlagen behandeln:

Was sind agile Praktiken?

Agile Praktiken (oft als „agil“ bezeichnet) betonen die kontinuierliche Bereitstellung kleinerer Teile der Arbeit über Projekte mit größeren miteinander verbundenen Aufgaben, die Wochen oder Monate umfassen können (was traditionell als Wasserfall-Management bezeichnet wird).

Zu den agilen Grundlagen gehören:

• Scrum-Team: Dieses hochgradig kollaborative Team, das unter einem Scrum-Master organisiert ist, löst komplexe Probleme und liefert Lösungen in Iterationen mit fester Länge, die als Sprints bezeichnet werden und zwischen einer Woche und 30 Tagen dauern können. Ein Scrum-Team, das beispielsweise an Inhalten arbeitet, kann einen zweiwöchigen Sprint beginnen, bei dem eine neue Infografik oder ein neues Datenblatt erstellt wird.
• Minimum Viable Product (MVP): Bei der Planung eines Liefergegenstandes legen die Agile-Prinzipien Wert darauf, das Projekt so schnell wie möglich in die Natur zu bringen, damit Ihr Team frühzeitig auf echte Probleme reagieren kann. Um ein Modell für die kontinuierliche Bereitstellung zu erreichen, ermutigen Scrum-Master die Teams, den MVP zu definieren und die kreativsten Wege zu finden, um das Produkt innerhalb der Grenzen des Sprints fertigzustellen. Wenn Sie beispielsweise einen zweiwöchigen Sprint starten, um ein E-Book als MVP zu erstellen, und Ihr Designer krank wird, können Sie das MVP dieses Sprints als eine Reihe von Blog-Posts neu definieren und das E-Book im nächsten entwerfen Sprint.
• Tägliches Stand-up-Meeting: Die Teammitglieder stehen jeden Morgen etwa 15 Minuten lang im Kreis, um die erledigten Aufgaben, Fokusbereiche und Blocker des Scrum-Teams zu besprechen, die sie möglicherweise daran hindern, ihre zugewiesene Sprintarbeit zu beenden. Am Ende des Sprints liefern agile Teams eine definierte Reihe von Projekten, die dann bewertet und im nächsten Sprint verbessert werden. Einige Scrum-Teams bieten auch retrospektive Meetings an, in denen sie Prozessmängel besprechen, die im nächsten Sprint behoben werden können.

Warum sollten Vermarkter Agile verwenden?

National Public Radio verwendet agile Methoden, um neue Programme zu erstellen und zu testen. Denken Sie bei Ihrem nächsten „Einfahrt-Moment“ darüber nach. Obwohl die Wurzeln von Agile im IT-Management liegen, kann diese Form der Projektabwicklung auf viele Funktionen eines Unternehmens angewendet werden, einschließlich Marketing.

Durch die Einführung eines agilen Modells für die kontinuierliche Iteration kann Ihr Marketingteam neue Nachrichten oder Kampagnen schnell testen, schneller auf Produktaktualisierungen reagieren und Erwartungen an Stakeholder setzen, die Arbeit von Ihrem Team anfordern.

Der glänzende Moment meines Teams kam fast neun Monate nach Beginn unserer agilen Reise, als wir den Inhalt unserer Website aktualisierten, um einige Änderungen in unseren Produktnachrichten vorzunehmen. Wir haben definiert, was wir in einer Woche erreichen können, und diese Arbeit termingerecht geliefert. Den Inhalt, für dessen Aktualisierung wir in diesem Sprint keine Zeit hatten, haben wir uns vor der Navigation versteckt. Wir haben die Nachrichten auf diesen Seiten während unserer nachfolgenden Sprints kontinuierlich erweitert und aktualisiert.

Welche Fehler sollten vermieden werden?

Wenn Sie erwägen, Agile in Ihr Team aufzunehmen, sollten Sie die folgenden vier agilen Marketingfehler vermeiden, die unser Team gemacht hat, auch wenn Sie lediglich die Prozesse in Ihrem Marketingteam optimieren möchten:

1. Wir nannten uns Agile, ohne unsere Hausaufgaben zu machen.
2. Wir konnten keine Problembesitzer benennen.
3. Wir haben uns eher auf Ergebnisse als auf Probleme konzentriert.
4. Wir haben uns vollgestopft, anstatt Prioritäten zu setzen (und so getan, als könnten wir alles erledigen).

Fehler 1: Wir haben uns Agile genannt, ohne unsere Hausaufgaben zu machen

Als ich mit meinem Marketing-Team anfing, führte ich schnell tägliche Stand-Ups ein, um eine schnelle und schmerzlose Möglichkeit zum Einchecken in Projekte zu bieten. Ich nahm an, dass ich in früheren Rollen Stand-Ups durchgeführt und Sprints organisiert hatte, also hatte ich Erfahrung mit Agile, oder? Falsch.

Kommen Sie nicht an einem Montag zur Arbeit und verkünden Sie, dass Sie wie ich „agil“ werden. Nur weil Sie in zweiwöchigen Sprints arbeiten und täglich aufstehen, heißt das nicht, dass Sie ein agiles Team sind. Das Schöne an Agile ist, dass Ihr Team die Möglichkeit hat, sich gemeinsam für Projekte zu engagieren und eine Qualität zu definieren, die innerhalb eines festgelegten Zeitraums erbracht werden kann. Wenn Sie nur versuchen, so viel Arbeit wie möglich in zwei Wochen zu packen und die Qualität zu opfern, um die Ziellinie zu erreichen, wird diese Schönheit negiert.

Machen Sie Ihre Hausaufgaben, bevor Sie in Ihrem Marketing-Team agile Prozesse einführen. Öffne ein oder zwei Bücher. Ich empfehle, mit Scrum von Jeff Sutherland (vielen als einer der Väter von Agile bekannt) und Hacking Marketing von Scott Brinker zu beginnen. Lesen Sie auch einige der hervorragenden Artikel von CMI zum Thema Agiles Marketing.

Nachdem Sie Ihre Hausaufgaben gemacht haben, priorisieren Sie einige einfache Änderungen an Ihrem vorhandenen Prozess, um einen agilen Ansatz zu entwickeln, der für Ihr Team funktioniert.

Fehler 2: Wir konnten keine Problembesitzer benennen

Wenn das folgende Szenario nicht aufgetreten ist, können Sie diesen Abschnitt überspringen. Sie haben eine Art Marketing-Prozess-Nirvana erreicht, das ich noch nicht entdeckt habe.

Der Rest von Ihnen stellt sich Folgendes vor: Sie sind zu 98% durch ein großes Teamprojekt mit einer klaren Frist und einem überraschenden Stakeholder, der in der letzten Stunde mit Dutzenden von Überarbeitungen einspringt. Dann ist Ihr Team gezwungen, das Projekt um weitere zwei Wochen zu verlängern, um diese Änderungen zu beheben, da niemand behaupten kann, dass dieser Stakeholder falsch liegt.

Liest noch? Ich dachte auch.

Das Fehlen einer definierten Eigenverantwortung unseres Teams war das größte Hindernis für unseren Fortschritt als agile Marketingabteilung. Wir waren von der Arbeit überwältigt. Wir waren frustriert, als mehrere Stakeholder die Projektqualität belasteten. Und wir haben wegen Änderungen und Korrekturen in letzter Minute nichts aus der Tür bekommen.

Wenn Ihr Marketing-Team so etwas wie unser ist, haben Sie Schwierigkeiten zu wissen, wer der endgültige Eigentümer eines Projekts ist. Wer ist die Person, die direkt für den Erfolg eines Ergebnisses verantwortlich ist? Wer legt messbare Ergebnisse für eine Aufgabe fest, an der sich das Team ausrichten kann? Wer braucht dieses Projekt, um erfolgreich zu sein, damit er oder sie letztendlich auch erfolgreich sein kann?

Um Nacharbeiten in letzter Minute zu vermeiden, weisen wir jetzt jedem Projekt eine solche Person - einen Problembesitzer - zu.

Jedes Quartal legen wir für jeden unserer Hauptmarketingkanäle ein vertriebsqualifiziertes Lead-Ziel fest: Werbung, Veranstaltungen, organische Website-Leads usw. Dann wird jedem dieser Kanäle ein Eigentümer in unserem Team zugewiesen, und dieser Eigentümer wird zum Ansprechpartner für alle Leistungen, die unter diesen Kanal fallen.

Problembesitz war für unser Team aus mehreren Gründen besonders erfolgreich:

• Der Erfolg liegt bei einer Person , die zur Rechenschaft gezogen wird, wenn die Ziele nicht erreicht werden.
• Dies zwingt den Kanalbesitzer, Probleme frühzeitig aufzutauchen, damit das Team sie proaktiv angehen kann.
• Es ermöglicht dem gesamten Team, sich mit dem Brainstorming einer Lösung und der Implementierung eines Fixes zu befassen.
• Es gibt einer Person die Möglichkeit, die Qualität eines bestimmten Projekts zu bestimmen.

Wenn Ihrem Team nicht klar ist, wer das letzte Wort in Ihren Content-Projekten hat, setzen Sie sich mit Ihrer Abteilung zusammen und stellen Sie eine verblüffend einfache, aber herausfordernde Frage: "Wem gehört was?" Wenn Sie diese Frage beantworten und Ihre Antworten für alle sichtbar aufzeichnen, entsteht eine unermessliche Rechenschaftspflicht.

Fehler 3: Wir haben uns eher auf Ergebnisse als auf Probleme konzentriert

Ein weiterer bahnbrechender Moment für unser agiles Team war, als wir aufhörten, unsere Arbeit als eine Reihe von Ergebnissen zu betrachten und anfingen, über unsere Arbeit als eine Reihe von zu lösenden Problemen nachzudenken.

Denken Sie an die einzelnen Mitarbeiter in Ihrem Team: Entwickler, Texter, Designer und andere ähnliche Implementierungsrollen. Wie oft werden sie gebeten, „diese Folie zu entwerfen“ oder „dieses E-Book zu schreiben“, ohne dass ein Zusammenhang besteht, warum sie dies tun?

Das einfache Zuweisen einer Aufgabe zu einer Aufgabenliste, ohne Ihrem Team zu helfen, den eigentlichen Zweck des Projekts zu verstehen, führt zu mangelhafter Arbeit ohne persönliche Investition Ihres Teams.

In der Tat kann ein Mangel an zweckorientierter Arbeit schwerwiegende Auswirkungen auf mehr als nur Ihre Marketingtaktiken haben. In einer Umfrage unter LinkedIn-Mitgliedern planten mehr als 60% der Befragten, die keine zweckorientierten Jobs hatten, ihr Unternehmen innerhalb von drei Jahren oder weniger zu verlassen.

In unserem Team haben wir eine strenge Regel gegen den Start eines Projekts mit einem vorgeschriebenen Ergebnis. Seien wir ehrlich, Stakeholder wissen nicht immer, was sie wollen. Das Lösen von Problemen fördert die Zusammenarbeit, um bessere Ergebnisse zu erzielen.

Stattdessen starten wir jedes Projekt mit einer Problemstellung, die einem Format folgt, das in der agilen Entwicklungswelt regelmäßig als User Stories bezeichnet wird. Das Format sieht ungefähr so ​​aus:

Wenn __________ passiert, möchte ich ________, damit wir dieses messbare Ergebnis erhalten: ___________.

Hier ist ein Beispiel für diese Art von Problemstellung (oder User Story) aus einem hypothetischen Projekt:

Der Problembesitzer jedes Projekts bestimmt, welche Probleme das Team für dieses Projekt angehen wird. Beispielsweise könnte der Eigentümer dies als Problem betrachten, wenn die Website nicht für ein bestimmtes Keyword eingestuft ist oder wenn die Nachrichten für eine bevorstehende Messe aktualisiert werden müssen. Unabhängig vom Problem enthält die Problemstellung niemals eine Lösung. Nachdem wir uns entschieden haben, ein bestimmtes Problem zu priorisieren, analysiert unser Team das Problem gemeinsam und legt schließlich eine Lösung fest, die wir in unserem nächsten Sprint ausführen können.

Wenn Sie ein Problem als Team lösen, kann jeder am Ergebnis beteiligt sein.

Darüber hinaus zwingt dieser Ansatz das Team, Schwachstellen hinter dem Problem auf Oberflächenebene aufzudecken, um eine Lösung zu finden, die die Kernanforderungen und nicht die Eitelkeitsanforderungen erfüllt.

Zum Beispiel berichtete unser Verkaufsteam, dass einige potenzielle Kunden nicht zu ihren geplanten Demo-Meetings erschienen und nicht auf Anfragen zur Neuplanung reagierten. Unser Vice President of Sales wollte, dass das Marketing-Team ein animiertes Erklärvideo erstellt, mit dem sich die Aussichten für das Meeting verbessern lassen, obwohl dies Monate gedauert hätte.

Nachdem wir einige Fragen zum Verkaufsprozess gestellt hatten, stellten wir fest, dass die Kernprobleme des Verkaufsteams vor dem Demo-Meeting mit verbessertem E-Mail-Messaging gelöst werden konnten. Wir haben eine Tropfkampagne mit drei E-Mails gestartet, die ausgelöst wird, sobald ein Meeting geplant ist. Der Aufbau dieser Lösung dauerte nur zwei Tage. Seit dem Aufbau dieser Kampagne haben wir die Anzahl der Personen, die Besprechungen verschieben müssen, um mehr als die Hälfte reduziert.

Bevor Sie einem Teammitglied eine Aufgabe zuweisen, fragen Sie sich, warum diese Arbeit wichtig ist. Durch die Erstellung einer Problemstellung und die Zusammenarbeit an einer Lösung konnten wir eine schnelle Lösung finden, die sich für unser Team ausgezahlt hat. Wenn wir ein animiertes Video erstellt hätten, hätte sich das Verkaufsteam möglicherweise monatelang mit demselben Problem befassen können, während wir auf unser Update gewartet haben.

Fehler 4: Wir haben uns vollgestopft, anstatt Prioritäten zu setzen (und so getan, als könnten wir alles erledigen)

Wenn Sie wie wir versuchen, so viel wie möglich in jeden Agile-Marketing-Sprint zu integrieren, machen Sie es falsch.

Ohne ein gemeinsames Prioritätsgefühl haben Sie keine Ahnung, wo Sie Ihre Zeit konzentrieren sollen. Und ohne Fokus sagen Sie zu allem Ja. Und wenn Sie zu allem Ja sagen und keine Problembesitzer für Ihre Projekte haben, befinden Sie sich mitten in einem stressigen Viertel mit vielen halbfertigen Ergebnissen.

Viele agile Teams verwenden Schätzungen, um die Arbeit zu priorisieren und die Geschwindigkeit als Team zu erhöhen. Sie schätzen den Aufwand ein, den ein Projekt erfordert, oder diskutieren, wie viele Stunden es dauern kann, bis Einzelpersonen ihre Aufgaben erledigen. Im Laufe der Zeit erreichen viele agile Teams eine durchschnittliche Leistung pro Sprint, was ihnen hilft, neue Aufgaben zu planen.

In unseren ersten Monaten als agiles Team haben wir uns vorgenommen, diese Art der Schätzung vorzunehmen. Leider haben wir unsere Schätzungen manipuliert, um den Eindruck zu erwecken, dass wir alles erledigen können. Wir haben erraten, wie viel Arbeit ein Projekt kosten würde, und dann haben wir die Anforderungen festgelegt, um Platz für drei weitere Anfragen zu schaffen. Am Ende haben wir den Wert der Arbeitsschätzung negiert und ein Umfeld unerbittlichen Stresses aufrechterhalten.

Wir haben zwei oder drei Methoden zur Verfolgung der Geschwindigkeit ausprobiert (einschließlich der Planung von Poker, einer gängigen Methode zur Schätzung der Arbeit). Wir haben uns darauf konzentriert, mithilfe von Schätzungen zu beweisen, dass wir viel Arbeit erledigen können, und nicht, um ein effizienteres Team zu werden. Das war unser Fehler.

Ich habe mich kürzlich mit dem Director of Engineering unseres Unternehmens unterhalten, der den Agile-Prozess für unser Produktteam verwaltet. Als ich erwähnte, dass unser Team die Schätzung nie gemeistert hatte, sagte er Folgendes:

Wenn Ihre Stakeholder ständig nach Geschwindigkeitsberichten oder verbesserten Schätzungen von Ihrem Team fragen, treten wahrscheinlich größere Prozessprobleme auf, die die Fähigkeit Ihres Teams beeinträchtigen, ihnen rechtzeitig Arbeit zu liefern.

Wenn Ihr gut funktionierendes Agile-Team regelmäßig schnelle Iterationen eines Projekts liefert und die Interessengruppen auf Bedenken hinweist, wenn eine Frist nicht zumutbar ist, vermeiden Sie natürlich Fragen zur Leistung oder Produktivität Ihres Teams. Der Projektmanager oder Scrum Master ist dafür verantwortlich, diese Änderungen zu korrigieren und zu kommunizieren, wenn die Arbeit ins Hintertreffen gerät.

Haben Sie keine Angst, in Ihrem nächsten Sprint nur ein oder zwei neue Projekte (oder Probleme oder Geschichten) zu priorisieren, da Sie in Ihrem aktuellen Sprint noch einige Projekte übrig haben. Teilen Sie dem Stakeholder diese verbleibenden Arbeiten rechtzeitig mit und teilen Sie Ihre Pläne mit, das Projekt so schnell wie möglich abzuschließen.

Und haben Sie keine Angst davor, einen Führer zu benennen, der den ultimativen Aufruf an das macht, was priorisiert werden muss. Unser Team hat zum Beispiel allen Personen verboten, Trello-Karten in die Sprint-Spalte „Priorität“ zu verschieben, mit Ausnahme unseres Vizepräsidenten für Marketing. Dies brachte die Verantwortung mit sich, der Person mit der größten Sicht auf das gesamte Unternehmen Priorität einzuräumen.

Fazit

Unser Team passt, wie jedes Agile-Team, die Agile-Prinzipien so an, wie es für uns funktioniert. Unabhängig davon, welchen agilen Ansatz Ihr Team verfolgt, funktioniert dies nur, wenn Sie Gelegenheit für offenes Feedback zum Prozess bieten und flexibel genug sind, um Ihren Workflow regelmäßig zu ändern. Wenn ich ein Protokoll über jede Optimierung hätte, die wir bisher an unserem agilen Ansatz vorgenommen haben, wäre es länger als dieser Beitrag.

Welche Fehler haben Ihre Teams bei der Implementierung agiler Prozesse gemacht? Wie haben Sie diese Fehler angegangen? Lass es uns in einem Kommentar wissen.

Möchten Sie Ihre Struktur für die Effektivität des Content-Marketings verbessern? Melden Sie sich für unseren wöchentlichen Newsletter "Content Strategy for Marketers" an, der exklusive Einblicke von Robert Rose, Chief Content Adviser, bietet. Wenn Sie wie viele andere Vermarkter sind, die wir treffen, werden Sie sich jeden Samstag auf seine Gedanken freuen.

Titelbild von Joseph Kalinowski / Content Marketing Institute