Webprojekte agil umsetzen
Einmal agil, bitte!
In nahezu jeder Branche sind aktuell Aussagen zu hören wie “unsere Prozesse müssen agiler werden” oder “Diese Projekt machen wir jetzt agil!” Die Grundidee dahinter stammt aus der Software-Entwicklung, genauso wie der Wunsch, damit bessere Projekte umzusetzen.
Im Jahr 2001 veröffentlichte eine Gruppe von Software-Entwicklern, die mit den damals vorherrschenden Methoden in der Software-Entwicklung unzufrieden war, das Agile Manifesto. In diesem Dokument zeigten sie eine neue Herangehensweise in der Software-Entwicklung auf. Ziel war es, eine bessere Zusammenarbeit zwischen Design- und Entwicklungsteams zu erreichen und vor allem die Kommunikation den Kunden gegenüber zu verbessern.
Aus den Grundideen des agilen Manifests entwickelten sich konkrete Projektmethoden wie SCRUM und Kanban bzw. Kreativtechniken wie Design-Thinking, die bald ihren Weg aus der reinen Softwareentwicklung hin zu allgemeineren Projektmanagement-Ansätzen fanden.
Die Konzeptfalle – Am Ziel vorbeiplanen
Einer der Leitsätze des agilen Manifests ist “working software over comprehensive documentation”. Es soll also mehr Fokus auf lauffähige Ergebnisse gesetzt werden anstatt auf eine vollständige Dokumentation, was alles laufen sollte.
Was in der Planung nämlich oft nicht beachtet wird: Ziele ändern sich – oder genauer gesagt: Das Projekt selbst verändert das Ziel, und das aus mehreren Gründen:
- Jedes Projekt ist immer ein Lernprozess für alle Beteiligten: Die neue Website hat eine moderneres Backend, mit der sich Newseinträge besser bearbeiten lassen? Ihr Content-Team entwickelt mit den neuen Werkzeugen (unbewusst) einen neuen Ausdrucksstil, der sich dem neuen Webauftritt anpasst? Alte Abläufe erscheinen im Umgang mit neuen Webservices auf einmal nicht mehr so relevant? Im Projekt ist man nicht nur im Nachhinein, sondern bereits zwischendurch schlauer als am Anfang. Dieses Know-how lässt sich bei starren Zielen oft nur schwer einsetzen.
- In jedem Projekt vergeht Zeit. In dieser Zeit dreht sich die Welt außerhalb des Projektes weiter. Das Produktportfolio wird ergänzt, Ihr Unternehmen wird neu strukturiert und Trends und Technologien in der Kundenkommunikation können kommen und gehen. Auch wenn sich diese Entwicklungen abschätzen lassen, kann es bereits mit Projektabschluss der Fall sein, dass Ihr neuer Webauftritt oder Ihre neue Kampagne nicht mehr ganz den Anforderungen entspricht.
- Nicht alles lässt sich planen: Wechsel in der Belegschaft oder dem Projektteam, Veränderungen bei Lieferanten und Kunden oder globale Ereignisse wie die aktuelle Corona-Pandemie – kein Projekt ist vor Disruption sicher. Und auch wenn sich das eigentliche Ziel durch derartige Faktoren nicht ändern sollte, Sie werden wieder neue Dinge lernen müssen (siehe Pt. 1) und auch die Zeit läuft unbarmherzig weiter (siehe Pt. 2).
Sind Konzepte, Pläne und Ziele also von vornherein zum Scheitern verurteilt? Sollen wir alle drauf los entwickeln und einfach schauen, was dabei rauskommt? Oder müssen wir jetzt alle Scrum-Master und Product-Owner werden und unseren Arbeitsalltag in Sprints und Daily Scrums “planen”?
Weder noch. Aber es lohnt sich, Projekte einmal aus einer anderen Perspektive zu betrachten:
Webprojekte sind keine Bergtour
Eine Bergtour – mit dem klaren Ziel, einen bestimmten Berggipfel zu erreichen – ist aus Projektmanagement-Sicht ganz klassisch in verschiedene Phasen einteilbar, die nacheinander abgearbeitet werden müssen: In der Konzeptionsphase lege ich mein Ziel fest, plane die Route, plane Zeitpunkt von Anreise und Aufbruch und packe meine Ausrüstung und Proviant entsprechend meiner Pläne ein. Den eigentlichen Weg lerne ich erst kennen, wenn ich ihn beschreite und Disruptoren wie Schlechtwettereinbruch oder vergessenes Trinkwasser können das Projekt ganz schnell scheitern lassen.
Wir haben also ein klares, sich nicht veränderndes Ziel und kalkulierbare Risiken – je besser also meine Planung, umso besser wird auch mein Projekt: Die Gipfelbesteigung mit sicherer Heimkehr.
Webprojekte sind anders. Bei Webprojekten kommt man irgendwann drauf, dass der Gipfel vielleicht etwas höher oder weiter nördlich sein sollte, dass man doch noch länger in der Almhütte sitzen bleiben muss, um die Karte zu überarbeiten, oder dass die Person mit den benötigten Steigeisen seit der letzten Weggabelung mit einer anderen Gruppe mitgeht. Sie können sich vorstellen, dass so eine “agile Bergtour” schnell in einem Überlebenstraining ausartet oder im Not-Biwak “on hold” gesetzt wird.
Webprojekte sind Teamsport
Anders hingegen läuft Planung und Zielsetzung im Teamsport ab: Man hat zwar ein Konzept, das an das gegnerische Team angepasst ist, und das klare Ziel, gewinnen zu wollen. Alles dazwischen ist aber situationselastisch – agil eben. Immer wieder wird die eigene Situation neu evaluiert und auf das Verhalten des Gegenübers angepasst. Liegen wir in Führung, werden wir unsere Kräfte schonen und haben das Ziel, dem gegnerischen Team keine Punkte mehr zu erlauben. Sind wir im Rückstand, ändern wir unsere Taktik und setzen uns vielleicht als neues Ziel, zumindest noch ein Unentschieden zu erreichen. Im Verlauf des Spiels werden Personen ausgewechselt, der Gegner kommt mit völlig überraschenden Spielzügen daher und wir müssen uns so schnell wie möglich auf die neuen Gegebenheiten einstellen – das klingt doch schon vielmehr nach einem Webprojekt, oder?
So bringen Sie Agilität in Ihr Webprojekt
Aus dem Teamsport können wir also einiges lernen, um Webprojekte besser zu steuern und das agile Manifest in unser tägliches Tun aufnehmen:
- Unser Team muss sich immer wieder auf neue Situationen einstellen. Das gelingt durch regelmäßigen Austausch der beteiligten Personen und Neu-Evaluierung unserer Ziele (individuals and interactions over processes and tools)
- Kunde und Agentur spielen in der gleichen Mannschaft (nicht gegeneinander!) und alle Mitwirkenden tragen in ihren Bereichen zum Erfolg bei. Sowohl Sieg als auch Niederlage betrifft immer das gesamte Team, nicht nur einen Teil davon. (customer collaboration over contract negotiation)
- Wir wollen schnell die Ergebnisse unsere Taktik sehen, um sie anpassen zu können. Eine Halbzeit lang zu planen, um in der zweiten Halbzeit den Plan auszuführen, gibt der gegnerischen Mannschaft zu viel Spielraum (working software over comprehensive documentation)
- Ändern sich die Rahmenbedingungen, muss das Team die Situation neu evaluieren und die nächsten Spielzüge dementsprechend anpassen (responding to change over following a plan)
In diesem Sinne wünschen wir Ihnen alles Gute für das nächste Projekt!