© Henrik Kniberg

Agil, Marketing, Wert und Risiko

Agiles Marketing kommt mehr und mehr auch in Deutschland an. Die geforderte schnellere Reaktionszeit auf Veränderungen am Markt und der immer höhere Takt, in dem Marketingabteilungen agieren und reagieren sollen, sorgt dafür, dass Agilität als Ziel immer attraktiver wird.

Die Softwarebranche hat schon ein wenig mehr Erfahrung rund um diesen Begriff. Eine Erfahrung ist, dass die Ziele nicht erreicht werden, wenn man nur ein paar Methoden (formal) übernimmt. Agil zu sein erfordert hier und da eine andere Denkweise, ein anderes Mindset. Von besonderer Bedeutung sind hierbei die Begriffe Wert und Risiko.

Agil & Wert

Eine der zentralen Haltungen eines agilen Softwareentwicklers ist, dass nur funktionierende Software einen Wert darstellt. Diese Haltung findet sich gleich in mehreren der agilen Prinzipien, wie beispielsweise diesem hier:

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Keine funktionierende Software, kein Fortschritt. Kein Fortschritt, kein geschaffener Wert.

Marketing & Wert

Für einen Marketer ist diese Sichtweise oftmals nur schwer nachvollziehbar. Für das Marketing entsteht Wert erst dann, wenn der Markt bearbeitet wird; klar Marketing ist Marktbearbeitung; keine Marktbearbeitung, kein Wert. Der Wert entsteht für einen Marketer, wenn die Kampagne startet, die Website online geht, das E-Mailing versendet wird.

Ein wenig unglücklich ist, dass beide Seiten recht haben. Noch viel unglücklicher ist, dass der Marketer als Auftraggeber einen wichtigen Vorteil agiler Methoden kaum nachvollziehen kann.

Darum möchte ich einen anderen Blickwinkel auf den Sachverhalt anbieten:

Risiko

Risiko steckt in jedem Vorhaben, jedem Projekt — und zwar in unterschiedlichsten Arten. Das hochangesehene Autoren-Team DeMarco/Lister schrieb in einem ihrer Werke gar:

If There’s No Risk On Your Next Project, Don’t Do It.

Damit haben Sie natürlich recht, ein risikoloses Projekt wird niemanden weiterbringen. Nicht einmal einen feuchten Händedruck wird man als Dank erwarten können.

In Marketing-Projekten ist das Risiko sogar allgegenwärtig, weil mit unglaublich vielen Annahmen — also Unsicherheiten — gearbeitet wird. Und zwar solchen, die selbst wenn alles Wissen der Welt zur Verfügung stünde, kaum weniger unsicher wären, weil es Annahmen über die Zukunft sind. Und wir sind als Menschen eher schlecht beim Blick in die Zukunft, wussten schon Nils Bohr, Winston Churchill, Marc Twain und Karl Valentin, denen das Zitat

Prognosen sind schwierig, besonders, wenn sie die Zukunft betreffen.

zugeschrieben wird. Erheblich umfangreicher beschäftigt sich NN Taleb in The Black Swan (unter anderem) mit diesem Thema.

Leider wird in unserer Business-Welt ungern über Risiken gesprochen; fast so, als wären sie nicht da, wenn man nicht über sie spricht. Positives Denken ist angesagt, Lösungen müssen her, Risiken stören da nur — nun ja, manche wissen, dass das Quatsch ist und anständiges Risiko-Management zu einem erfolgreichen Projekt gehört.

Risiko & Agil

Zurück zu den agilen Methoden und ihrer funktionierenden Software. Gehen wir mal durch ein hypothetisches und einfaches Website-Projekt und schauen uns das Risiko an. Zuerst in einem eher klassischen Ablauf:

  • Lastenheft bzw. Briefing schreiben: Die Idee ist, dass ein Lastenheft die Anforderungen beschreibt. In der Fachliteratur wie auch unter Praktikern ist bekannt, dass dieses Ziel entweder gar nicht oder nur auf einem dermaßen abstrakten Niveau erreicht wird, dass keine Reduktion des Risikos stattfindet.
  • Dann wird ein Pflichtenheft geschrieben, basierend auf unklaren, unvollständigen Anforderungen und einer ebenso unklaren Visualisierung, Zielgruppenbeschreibungen und vieles mehr. Hinzu kommen diverse Annahmen über technische Details, über den Content, dessen Qualität und Quantität, und und und. Risiko-Reduktion: quasi keine.
  • Wireframes und Layouts werden erstellt. Risiko-Reduktion: ebenfalls quasi keine. Warum? Kann das Layout und Design wirklich so umgesetzt werden? Es ist doch ein besonderes, vom Wettbewerb differenzierendes, einmaliges, oder nicht? Funktioniert freilich auch auf mobilen Geräten, oder? Welche iPhone Generation hatte der Vorstand noch? Der Term User Experience multipliziert das Ganze dann mit diversen Zielgruppen, deren Fähigkeiten und Erwartungen.
  • Die eigentliche Produktion beginnt. Ein ganzer Haufen Programmierer arbeitet sich Schicht für Schicht durch — ein Teil vom sogenannten Frontend ein anderer vom Backend. Irgendwann trifft man sich in der Mitte und ist fertig — so der Plan. Haben wir Risiko reduziert? Ein kleines bisschen vielleicht.
  • Nun kommt es drauf an. Integration aller Bestandteile. Eine einzige fehlerhafte Annahme im Pflichtenheft — und viele andere kleine Fehler, die es noch geben kann — bringt das ganze System zum Stehen. Nun wird gefixt, gebogen und ein Workaroud nach dem anderen implementiert, denn Zeit, es richtig zu machen, ist nun nicht mehr. Lassen wir das mit dem Risiko, sprechen wir besser von Glück, Zufall oder Ähnlichem.

Wie würde so ein Projekt agil ablaufen?

  • Die erste Anforderung — idealerweise eine User Story nebst Akzeptanz-Kriterien — ist klar. Ein Prototyp wird erstellt, das für diese Anforderung nötige Layout in paar kurzen Schleifen verfeinert — und zwar direkt in HTML — , die Programmierung wird erstellt. Irgendwann ist diese Anforderung voll implementiert. Sie sieht noch nicht perfekt aus, der Code wird noch paar Mal angepasst werden. Macht nichts, mehrere Iterationen sind Bestandteil des Arbeitsmodells. Eines ist aber klar: Es funktioniert. Der agile Software-Entwickler hat Wert erzeugt, für den Marketer wurde das Risiko reduziert.
  • Parallel wurden weitere User-Stories gemeinsam mit dem Marketing erarbeitet. Das oder die Teams schnappen sich jene, die vom Auftraggeber am höchsten priorisiert wurden. Mit jeder fertigen User-Story reduziert sich das Risiko. Und da die wichtigsten Stories zuerst bearbeitet werden, wird viel Risiko reduziert.
  • Die Annahmen zu User-Story XYZ stellen sich als falsch heraus. Ist dem Team egal, es wurde noch nicht daran gearbeitet. Das ist die risikoreduzierende Wirkung des sogenannten Late-Commitment. So lange eine User Story nicht in Arbeit geht, kann sie geändert, gelöscht oder re-priorisiert werden.
  • Durch unerwartete Änderung der Rahmenbedingungen muss eine neue User-Story aufgenommen werden. Aber die Deadline rückt näher. Kein großes Problem. Da die Priorisierung der User-Stories wirklich konsequent umgesetzt wurde, können die niedrig priorisierten Anforderungen unter diesen Umständen auch etwas verspätet umgesetzt werden und die neue Anforderung vorgezogen werden. Diese Flexibilität reduziert ebenfalls das Risiko.

Fazit

Ich gebe gerne zu, dass ich den agilen Ablauf etwas idealisiert dargestellt habe — als Ausgleich habe ich dem phasenorientierten Ablauf zugestanden, dass es keine Änderung der Anforderungen im Projektverlauf gibt.

Zweifellos scheitern auch mit agilen Methoden geführte Projekte. Vor wenigen Jahren behaupteten manche, agil sei eher für kleine, tendenziell einfache Projekte geeignet. Inzwischen ist die überwiegende Meinung, dass insbesondere komplexe Projekte von agilen Denkweisen profitieren. Zudem gibt es genug Statistiken, bei denen agil geführte Projekte erheblich höhere Erfolgsquoten aufweisen.

Das hat ganz klar damit zu tun, dass, beginnend mit dem ersten Tag eines agilen Projekts, konsequent das Risiko reduziert wird. Und zwar ganz im Gegensatz zu Phasenmodellen, die erstmal nur Dokumente mit vielen Annahmen erzeugen, deren risikoreduzierende Wirkung — entgegen weit verbreitetem Glauben — nahezu null ist.


Fox & Habbit ist eine Agentur für digitale Marken-Infrastrukturen. Mit Websites, digitalen Kampagnen und Mobile Apps schaffen wir Erlebnisse, die Kaufentscheidungen vereinfachen, Marken verändern und Unternehmen erfolgreicher machen.