Bei uns kann er alles mitnehmen, was bis dahin entstanden ist: Code, Tickets, Dokumentation, Entscheidungen und den aktuellen Arbeitsstand. Viele unserer Kund:innen haben deshalb nicht nur Zugriff auf Jira und Confluence, sondern auch direkt auf GitLab. Sie können verfolgen, wie sich der Code entwickelt – und sind nicht darauf angewiesen, dass wir ihnen den Stand des Projekts erklären.
Natürlich beginnen wir kein Projekt mit dem Ziel, es vorzeitig zu beenden. Viele unserer Kunden arbeiten über Jahre mit demselben punkt.de-Team zusammen. Aber genau diese Freiheit gehört für uns zu einer vertrauensvollen Partnerschaft: Das Projekt gehört dem Kunden, nicht der Agentur.
Im ersten Teil dieser Serie ging es darum, wie wir über den Punktlandungsworkshop und das Strategiepapier zu einem gemeinsamen Projektverständnis kommen. Jetzt wird daraus tägliche Zusammenarbeit.
Nach der Beauftragung übersetzen unsere Product Owner:innen das Strategiepapier in zwei Strukturen: Epics für die inhaltliche Arbeit und Budgettöpfe für das Controlling.
Vorher findet ein interner Workshop mit dem zukünftigen Projektteam und den beteiligten Berater:innen statt. Dort werden nicht einfach Dokumente übergeben. Es geht um die Informationen zwischen den Zeilen:
Aus diesem Wissen schneiden der oder die Product Owner:in und das Team die ersten Epics und legen sie in Jira an. Der Kunde hat über den initialen Workshop bereits an ihrer Grundlage mitgearbeitet und sieht anschließend die konkrete Struktur. Korrekturen sind möglich, große Neuschnitte aber selten nötig.
Wir konzipieren zu diesem Zeitpunkt bewusst nicht jedes Detail bis zum Projektende. Die Epics geben Richtung und Zusammenhang. Die konkrete Ausarbeitung erfolgt dann, wenn ein Bereich tatsächlich näher an die Umsetzung rückt. So planen wir nicht monatelang an Erkenntnissen vorbei, die erst während der Arbeit entstehen.
Auch Budgettransparenz braucht den richtigen Detailgrad. Ein einziger Topf für das Gesamtprojekt ist zu grob: Man erkennt erst spät, wo etwas aus dem Plan läuft. Dutzende kleine Positionen sind nicht automatisch besser. Im schlimmsten Fall verschwindet das eigentliche Problem in einer großen Datenmenge.
Deshalb teilen wir das angebotene Budget in wenige aussagekräftige Töpfe. Ab dem ersten Monat sieht der Kunde regelmäßig, wie viel in jedem Bereich vorgesehen und wie viel bereits verbraucht ist.
Diese Aufteilung ist ein Controlling-Instrument, kein Korsett. Läuft ein Topf schneller leer, betrachten wir zunächst die anderen. Vielleicht gleicht sich die Entwicklung im Gesamtprojekt aus. Wenn mehrere Töpfe deutlich schneller Budget verbrauchen, muss das Team reagieren. Dafür gibt es drei Stellschrauben:
Keine davon ist automatisch angenehm. Aber alle drei sind besser, als eine Abweichung erst kurz vor Projektende zu entdecken.
Der Kunde erhält Zugriff auf das Jira-Board, auf dem auch wir arbeiten. Dort liegen operative und technische Tickets – nicht nur eine aufbereitete Auswahl für den nächsten Statusbericht.
Dasselbe gilt für Confluence: Protokolle, Entscheidungen und Dokumentation entstehen in einem gemeinsamen Projektraum. In vielen Projekten kommt GitLab hinzu. Der Kunde kann sehen, woran entwickelt wird, welche Änderungen in den Code einfließen und was bis zu diesem Zeitpunkt tatsächlich entstanden ist.
Niemand muss jedes Ticket lesen oder jeden Commit prüfen. Manche Kund:innen möchten tief einsteigen, andere konzentrieren sich auf fachliche Entscheidungen. Beides ist möglich. Der Grad der Mitarbeit ist verschiebbar, der Zugang zu den Informationen nicht.
Das hat einen sehr praktischen Effekt: Wenn Ansprechpartner:innen wechseln, Wissen übergeben werden muss oder die Zusammenarbeit endet, fängt der Kunde nicht bei null an. Der Projektstand steckt nicht nur in den Köpfen unserer Entwickler:innen und auch nicht in einem internen System, das wir allein kontrollieren.
Für uns ist das gelebte digitale Souveränität: nicht als abstraktes Versprechen, sondern als konkrete Möglichkeit, informiert zu entscheiden und handlungsfähig zu bleiben.
Tickets sagen, was zu tun ist. Sie beantworten aber nicht automatisch, woran sich eine gute Entscheidung orientiert. Deshalb entwickeln wir mit dem Projektteam möglichst früh ein Projektmanifest.
Darin halten wir wenige Leitsätze fest, die die gemeinsame Richtung beschreiben. Bei einer späteren Entscheidung können wir fragen: Passt sie zu unserem Manifest?
Wenn nicht, gibt es zwei legitime Möglichkeiten. Wir verändern die Entscheidung. Oder wir passen das Manifest an, weil sich die Rahmenbedingungen oder unsere Erkenntnisse verändert haben. Wichtig ist, dass der Widerspruch sichtbar wird und die Kursänderung bewusst erfolgt.
Unsere Kolleg:innen von made in zeigen ausführlich, wie ein Projektmanifest gemeinsam entwickelt wird. Für uns ist es kein feierliches Dokument für die Ablage. Es ist eine Abkürzung für die schwierigen Diskussionen im Projektalltag.
Ein gemeinsames Board allein schafft noch keine gute Kommunikation. Ab Projektbeginn sprechen wir deshalb mindestens alle zwei Wochen in einem Jour fixe mit dem Kunden. In großen Projekten wird die Zusammenarbeit enger: Dann nehmen Kund:innen auch an Scrum-Events teil, in intensiven Phasen teilweise sogar an Dailys.
Dazwischen nutzen wir, was für die Situation sinnvoll ist. Kurze Rückfragen laufen häufig per Chat zwischen Product Owner:in und Kunde. Konkrete Aufgaben gehören ins Ticket. Komplexe oder dringende Fragen klären wir am Telefon oder im Videocall.
Entscheidend ist nicht, jeden Austausch in einen Prozess zu zwingen. Entscheidend ist, dass Fragen schnell bei den richtigen Menschen landen und relevante Ergebnisse anschließend für das Team nachvollziehbar sind.
Neue Funktionalitäten übergeben wir einzeln auf einem Staging-System und bitten den Kunden um Abnahme. Vor dem ersten Livegang existiert meist zunächst nur diese geschützte Umgebung; später stehen Staging und Produktivsystem nebeneinander.
Die einzelne Abnahme verkürzt die Feedbackschleife. Wenn eine Funktion anders verstanden wurde oder sich in der Benutzung nicht richtig anfühlt, merken wir das früh. Wir entwickeln nicht über Monate ein großes Bündel und stellen dann fest, dass wir gemeinsam in die falsche Richtung gelaufen sind.
Das erfordert Mitarbeit auf Kundenseite. Nicht jede technische Entscheidung muss dort getroffen werden. Aber fachliches Feedback können wir nicht durch Agenturwissen ersetzen.
Auch mit Budgettöpfen, Jour fixes und kurzen Abnahmeschleifen läuft ein komplexes Projekt nicht immer wie geplant. Der Unterschied ist: Abweichungen entstehen normalerweise nicht über Nacht. Beide Seiten können sehen, wie sie sich entwickeln.
Das operative Team versucht zunächst, gemeinsam nachzusteuern. Reicht diese Ebene nicht aus, gibt es in vielen Projekten ein Steering Board. Dann schauen wir mit der Managementseite des Kunden auf die Situation und entscheiden über Scope, Prozesse, Zusammenarbeit oder Budget.
Manchmal komme auch ich als zusätzliche Eskalationsstufe dazu. Nicht, um die Verantwortung des Teams zu übernehmen, sondern um eine festgefahrene Situation aus einer anderen Perspektive zu betrachten und gemeinsam mit dem Kundenmanagement wieder entscheidungsfähig zu werden.
Das gehört für mich zu dem Anspruch, den wir in unserem Loveletter formulieren: erfrischend direkt, ehrlich und bodenständig. Ehrlichkeit beweist sich nicht, solange alles grün ist. Sondern dann, wenn man eine schwierige Entwicklung früh anspricht.
Unsere Kund:innen sollen wissen, woran wir arbeiten, wie sich das Budget entwickelt und welche Entscheidungen anstehen. Sie sollen sich beteiligen können, ohne jedes technische Detail selbst steuern zu müssen. Und sie sollen jederzeit auf das zugreifen können, was in ihrem Auftrag entstanden ist.
Das klingt zunächst wie eine Absicherung für das Ende einer Zusammenarbeit. In der Praxis ist es für uns eine Grundlage für lange Partnerschaften. Wer bleiben muss, weil Wissen, Code oder Dokumentation bei einer Agentur eingeschlossen sind, vertraut ihr nicht. Wer jederzeit gehen könnte und trotzdem bleibt, schon eher.
Im dritten Teil dieser Serie geht es um den Weg zum Livegang – und darum, warum ein Launch für uns kein einzelner großer Moment sein muss.
