Agiles und kollaboratives Projektmanagement

Der Shop ging pünktlich online

Der Shop ging am 15. November live. Pünktlich zum Weihnachtsgeschäft. Dienstagvormittag, 10:30 Uhr, Agile-Schulung: Hanna blickt zurück auf die sechs Wochen, in denen ihr E-Commerce-Team den Relaunch ohne detaillierten Gesamtplan durchgezogen hat.

Sechs Wochen vorher sah es so aus: Der Zahlungsdienstleister liefert seine Schnittstelle erst am 1. November. Marketing will drei Landingpages umbauen. Wer gerade an was arbeitet, weiß niemand. Jede Woche Verzögerung kostet rund 20.000 Euro Umsatz.

Der Vergleich zwischen klassischen und agilen Ansätzen ist die Grundlage für die Antwort: Statt eines Sechswochenplans arbeitete Hannas Team in zweiwöchigen Sprints - kurzen Arbeitszyklen mit fester Struktur und klaren Rollen. Aber wer entschied, was in welchen Sprint kommt? Und wer sorgte dafür, dass das Team ungestört arbeiten konnte?

Drei Rollen steuern den Sprint

Im Relaunch übernahmen drei Rollen die Steuerung:

Der Product Owner entscheidet, WAS gebaut wird: Aufgaben priorisieren (erst Produktseiten, dann Landingpages, zuletzt Zahlungsintegration) und das Product Backlog pflegen - die sortierte Aufgabenliste für das gesamte Projekt.

Der Scrum Master sorgt dafür, WIE das Team arbeitet: tägliche Kurzmeetings moderieren, Hindernisse beseitigen (z.B. fehlende Testdaten vom Zahlungsdienstleister) und das Team vor ungeplanten Zusatzaufgaben schützen.

Das Entwicklungsteam entscheidet selbst, WER welche Aufgabe übernimmt. Im Relaunch verteilten die Teammitglieder die Arbeit eigenständig - ohne Zuweisung von oben.

🎬 Vorstellung: Stell dir vor, du stehst morgens im Daily Standup von Hannas Team. 15 Minuten, alle im Kreis. Jede Person sagt in 90 Sekunden, woran sie arbeitet und wo sie feststeckt.

Ein Sprint von Anfang bis Ende

Jeder Sprint beginnt mit dem Sprint Planning. Das Team wählt Aufgaben aus dem Product Backlog und formuliert ein Sprintziel - das konkrete Ziel für die nächsten zwei Wochen.

Für Hannas Sprint 1 lautete das Ziel: Alle 120 Produktseiten auf das neue Layout migrieren. Fünf User Stories beschrieben die konkreten Anforderungen:

1. "Als Kund:in will ich Produktbilder zoomen können." Akzeptanz: Zoom funktioniert auf Mobilgeräten und Desktop.
2. "Als Kund:in will ich Bewertungen auf der Produktseite lesen." Akzeptanz: Letzte 10 Bewertungen sichtbar, Durchschnittsnote angezeigt.
3. "Als Kund:in will ich den Warenkorb-Button sofort sehen." Akzeptanz: Button ohne Scrollen erreichbar auf allen Bildschirmgrößen.
4. "Als Kund:in will ich Größe und Farbe per Dropdown wählen." Akzeptanz: Auswahl aktualisiert Preis und Verfügbarkeit live.
5. "Als Kund:in will ich die Lieferzeit vor dem Kauf sehen." Akzeptanz: Lieferzeit aus dem ERP-System live abgerufen.

Jede User Story hat Akzeptanzkriterien - messbare Bedingungen, an denen das Team erkennt, ob die Aufgabe fertig ist.

Drei feste Termine halten den Sprint zusammen

Neben dem Sprint Planning gibt es drei wiederkehrende Termine:

Das Daily Standup (täglich, 15 Minuten): Jede Person beantwortet drei Fragen. Was habe ich gestern geschafft? Was mache ich heute? Wo hänge ich fest?

Das Sprint Review (letzter Sprinttag): Das Team zeigt den Stakeholdern, was fertig geworden ist. Im Relaunch präsentierte das Team die migrierten Produktseiten im Staging-System. Feedback floss direkt ins Backlog für den nächsten Sprint.

Die Sprint Retrospektive (nach dem Review): Das Team reflektiert den Arbeitsprozess. Was lief gut? Was ändern wir? In Hannas Team kam heraus, dass Testdaten vom Zahlungsdienstleister zu spät kamen. Der Scrum Master übernahm die Klärung.

🤔 Frage dich: Wie würdest du das Sprintziel formulieren, wenn dein Team statt Produktseiten den gesamten Checkout-Prozess neu bauen müsste?

Zwei Fälle, in denen agil an Grenzen stößt

Agile Sprints setzen voraus, dass das Team seinen Arbeitsumfang selbst steuern kann. Zwei Szenarien zeigen, wo drei Dimensionen - Vertragsstruktur, Planbarkeit und Liefersicherheit - Probleme erzeugen:

Fall 1: Externe Lieferantenintegration. Der Zahlungsdienstleister lieferte seine Schnittstelle erst am 1. November. Das Team konnte die Zahlungsfunktion vorher nicht testen. Der externe Zeitplan gab den Takt vor, nicht das Team. Vertragsänderungen brauchten Wochen statt Tage. Trotzdem kann agil hier funktionieren: Blockierte Aufgaben wandern in spätere Sprints, das Team arbeitet parallel an anderem.

Fall 2: Festpreisvertrag mit Abnahmedatum. Ein Vertrag legt fest: Am 15. November werden genau 47 Features abgenommen. Agiles Arbeiten lebt davon, den Umfang anzupassen - ein Festpreisvertrag verbietet das. Nachträgliche Änderungswünsche erzeugen Vertragskonflikte. Der fixe Termin drückt das Team in Überstunden. Hier ist ein klassischer Ansatz oft sicherer: Der Vertrag erlaubt keine Umfangsänderung, und der fixe Termin verhindert das nachhaltige Sprint-Tempo.

So lief es bei Hannas Relaunch

Zurück zu Hannas Relaunch: Das Team schaffte den Go-Live am 15. November, aber nicht mit allen 47 geplanten Features. Die Product-Owner-Rolle entschied nach Sprint 2: Lieber 38 Features stabil als 47 mit Bugs. Das war möglich, weil der interne Projektauftrag Spielraum beim Umfang ließ.

Wäre der Relaunch über einen Festpreisvertrag mit einer externen Agentur gelaufen, hätte diese Entscheidung einen Vertragsbruch bedeutet. Agil heißt nicht: alles geht. Agil heißt: Das Team entscheidet innerhalb klarer Grenzen, was den größten Wert liefert.

📝 Fasse mental zusammen: Unter welcher Bedingung funktioniert agiles Vorgehen trotz externer Abhängigkeiten - und wann ist ein klassischer Ansatz sicherer?