Was ist an Scrum in Agenturen besonders?
Agenturen und Dienstleister arbeiten nicht für ein eigenes Produkt, sondern für Kunden, die Budgets, Termine und vertraglich zugesicherte Leistungen erwarten. Gleichzeitig profitieren gerade Kundenprojekte von agiler Arbeit: Anforderungen an Websites, Apps oder Kampagnen sind zu Beginn selten vollständig klar, und frühes Feedback verhindert teure Fehlentwicklungen. Scrum lässt sich deshalb auch in Agenturen einsetzen, braucht aber Antworten auf Fragen, die in einem internen Produktteam nicht entstehen.
Die wichtigsten Unterschiede betreffen die Rolle des Kunden, das Vertragsmodell, die Abrechnung und die Auslastung der Teams über mehrere Kunden. Wer diese Fragen vor Projektbeginn klärt, kann die Stärken von Scrum nutzen. Wer sie offen lässt, erlebt Konflikte über Umfang und Budget, die durch das agile Vorgehen eher verschärft als gelöst werden.
Wer ist in einem Kundenprojekt der Product Owner?
Der Scrum Guide beschreibt den Product Owner als eine Person, die für die Maximierung des Produktwerts verantwortlich ist und deren Entscheidungen von der gesamten Organisation respektiert werden müssen [1]. In Kundenprojekten liegt diese Verantwortung fachlich beim Kunden, denn nur er kann entscheiden, was für sein Geschäft am wertvollsten ist. Es gibt drei verbreitete Modelle, die je eigene Stärken und Risiken haben.
| Modell | Beschreibung | Stärke | Risiko |
|---|---|---|---|
| Product Owner beim Kunden | eine Person des Kunden ordnet den Backlog und nimmt Ergebnisse ab | direkte Entscheidungen, hohe Identifikation | Person hat zu wenig Zeit oder Erfahrung |
| Product Owner bei der Agentur | die Agentur stellt den Product Owner, der eng mit dem Kunden abstimmt | Methodenkompetenz, Verfügbarkeit | Entscheidungen ohne echte Befugnis des Kunden |
| Tandem | fachlicher Product Owner beim Kunden, unterstützt durch eine Person der Agentur | Verbindung von Fachwissen und Methode | unklare Verantwortung, wenn nicht sauber abgegrenzt |
In der Praxis hat sich das Tandem bewährt, solange klar ist, dass die Entscheidungsbefugnis beim Kunden liegt. Die Person der Agentur unterstützt beim Formulieren von Einträgen, bei der Priorisierung und bei der Vorbereitung der Reviews, entscheidet aber nicht über den Backlog. Wichtig ist, dass die Person beim Kunden ausreichend Zeit hat, typischerweise mehrere Stunden pro Woche. Fehlt diese Zeit, ist das ein erhebliches Projektrisiko, das schon im Angebot angesprochen werden sollte.
Welche Vertragsmodelle passen zu Scrum?
Klassische Festpreisverträge mit vollständig beschriebenem Umfang passen schlecht zu agiler Arbeit, weil sie Änderungen zum Konflikt machen. Das Agile Manifest stellt die Zusammenarbeit mit dem Kunden über die Vertragsverhandlung [2]; in der Praxis braucht es trotzdem Verträge, die Sicherheit für beide Seiten schaffen. Bewährt haben sich Modelle, die Budget und Zeit festlegen und den Umfang über Priorisierung steuern.
| Modell | Funktionsweise | Geeignet für |
|---|---|---|
| Aufwand mit Kostendach | Abrechnung nach Aufwand, Gesamtkosten nach oben begrenzt | Projekte mit unsicherem Umfang und vertrauensvoller Beziehung |
| Festpreis pro Sprint | fester Preis für ein Team über einen Sprint, Umfang je Sprint priorisiert | laufende Weiterentwicklung, planbare Budgets |
| Festpreis pro Release mit Tauschrecht | Grobumfang fixiert, Einträge gleicher Grösse dürfen getauscht werden | Kunden, die einen Gesamtpreis brauchen |
| Rahmenvertrag mit Abrufen | Konditionen fixiert, Kapazität wird abgerufen | langfristige Zusammenarbeit |
| Phasenweise Beauftragung | Konzept- oder Discovery-Phase zuerst, danach Umsetzung | neue Kunden, sehr unklare Anforderungen |
Ein häufiger Kompromiss ist der Festpreis pro Release mit Tauschrecht: Der Kunde erhält einen Gesamtpreis, und neue Wünsche können aufgenommen werden, wenn dafür Einträge gleicher Grösse herausfallen. Das verbindet Planungssicherheit mit Flexibilität, setzt aber eine verlässliche relative Schätzung voraus, siehe Agile Schätzverfahren. Für öffentliche Auftraggeber gelten zusätzlich die Regeln des Vergaberechts.
Wie werden Budget und Fortschritt transparent gemacht?
Variable Umfänge verlangen hohe Transparenz, damit der Kunde jederzeit weiss, was er für sein Geld erhält. Bewährt haben sich drei Elemente: ein für den Kunden einsehbarer Backlog mit Reihenfolge und Schätzungen, ein Burn-up-Chart, das erledigte Arbeit und Gesamtumfang zeigt, und ein Budgetbericht, der verbrauchtes und verbleibendes Budget sowie die Prognose bis zum Release ausweist. Im Sprint Review werden diese Informationen gemeinsam besprochen, und der Kunde entscheidet über die nächsten Prioritäten.
Für die Agentur ist die Zeiterfassung pro Projekt und Eintrag die Grundlage dieser Transparenz und zugleich der Abrechnung. Sie zeigt, wie viel Aufwand tatsächlich angefallen ist, und erlaubt nach einigen Sprints, Schätzungen und Angebote auf eigene Erfahrungswerte zu stützen. Wie der Fortschritt mit Burn-up und anderen Kennzahlen dargestellt wird, beschreibt der Beitrag Agile Metriken richtig nutzen.
Was tun, wenn ein Team für viele Kunden arbeitet?
Viele Agenturen haben nicht ein Team pro Kunde, sondern Teams, die gleichzeitig für mehrere Kunden arbeiten, oft an vielen kleinen Aufträgen. Scrum mit einem Product Goal und einem Product Owner passt hier schlecht, weil die Prioritäten verschiedener Kunden nicht in einem Backlog sinnvoll geordnet werden können. Kanban ist in dieser Situation oft die bessere Wahl: Aufträge verschiedener Kunden fliessen über ein Board, WIP-Limits verhindern Überlastung, und Serviceklassen regeln, wie dringende Anfragen behandelt werden. Wie das funktioniert, beschreibt der Beitrag Kanban einführen.
Eine Mischform ist ebenfalls verbreitet: Grosse Kundenprojekte werden in festen Teams mit Scrum umgesetzt, kleinere Aufträge und Wartung laufen über ein Kanban-System. Entscheidend ist eine Übersicht über die Auslastung aller Personen über alle Kunden, damit Zusagen an Kunden nicht an fehlender Kapazität scheitern.
Beispiel: Website-Relaunch im Sprint-Modell
Eine Agentur vereinbart mit einem Kunden einen Website-Relaunch über sechs Sprints von zwei Wochen zu einem Festpreis pro Sprint. Im ersten Sprint entstehen mit dem Kunden Zielbild, Seitenstruktur und ein priorisierter Backlog. Die Marketingleiterin des Kunden ist Product Owner und wird von einer Projektleiterin der Agentur unterstützt. Jedes Sprint Review zeigt funktionierende Seiten auf einer Testumgebung, und die Marketingleiterin entscheidet über die nächsten Prioritäten. Nach dem vierten Sprint zeigt das Burn-up, dass der Backlog um neue Wünsche gewachsen ist.
Im Review legt die Agentur zwei Optionen vor: zwei zusätzliche Sprints für die neuen Wünsche oder Livegang nach Plan mit den wichtigsten Seiten und einer zweiten Etappe. Die Marketingleiterin entscheidet sich für den Livegang nach Plan, weil eine Kampagne daran gekoppelt ist. Der Vertrag lässt das ohne Nachverhandlung zu, weil Budget und Zeit fix und der Umfang variabel vereinbart waren. Beide Seiten wissen jederzeit, wo sie stehen, und der Konflikt über Mehrleistungen, der bei einem klassischen Festpreis entstanden wäre, bleibt aus.
Typische Fehler bei Scrum in Kundenprojekten
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Klassischer Festpreis mit Scrum-Etikett | Streit über jede Änderung | Vertragsmodell mit variablem Umfang wählen |
| Kunde ohne Zeit für die Rolle des Product Owners | Entscheidungen bleiben liegen, Reviews ohne Kunde | Zeitbedarf im Angebot festhalten, Tandem-Modell |
| Backlog nicht für den Kunden sichtbar | Misstrauen, Überraschungen | gemeinsamer, einsehbarer Backlog |
| Ein Team gleichzeitig in vielen Kundenprojekten mit Scrum | Prioritätskonflikte, kein echtes Sprint Goal | Kanban oder feste Teams pro grossem Kunden |
| Abrechnung ohne Bezug zu Einträgen | Kunde versteht Kosten nicht | Zeiterfassung pro Eintrag, Budgetbericht im Review |
Wie formuliert man ein agiles Angebot?
Ein agiles Angebot beschreibt nicht jede Funktion im Detail, sondern Ziel, Rahmen und Vorgehen. Es enthält das angestrebte Ergebnis und den Nutzen für den Kunden, einen ersten priorisierten Grobumfang mit relativen Schätzungen, die Teamzusammensetzung, die Sprintlänge, das Vertragsmodell mit Budget und Zeitrahmen sowie die Mitwirkung des Kunden, insbesondere die Zeit der Person in der Rolle des Product Owners. Wichtig ist eine klare Aussage, wie mit neuen Wünschen umgegangen wird: Sie werden in den Backlog aufgenommen und priorisiert, und bei festem Budget verdrängen sie andere Einträge.
Viele Kunden sind mit dieser Form zunächst nicht vertraut. Hilfreich ist eine kurze Discovery- oder Konzeptphase zu einem Festpreis, in der Ziele, Backlog und Schätzungen gemeinsam erarbeitet werden. Danach kann der Kunde auf einer fundierten Grundlage entscheiden, ob und mit welchem Budget die Umsetzung erfolgt. Diese Zweiteilung entspricht der Logik eines Projektauftrags mit anschliessender Freigabe, siehe Projektauftrag schreiben.
Scrum in Kundenprojekten und Projektmanagementstandards
Für Kundenprojekte gelten oft zusätzliche Anforderungen an Vertrag, Steuerung und Dokumentation, etwa wenn der Kunde nach HERMES oder einem eigenen Projektmanagementstandard arbeitet. Die Norm ISO 21502 lässt agile und hybride Liefermodelle ausdrücklich zu und betont die Abstimmung des Vorgehens mit dem Auftraggeber [3]. In der Praxis bedeutet das: Das agile Vorgehen wird im Projektauftrag festgehalten, mit klaren Regeln für Budget, Änderungen und Abnahmen. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.