Techblog

„Wir werfen die konventionellen Ansätze über Bord“

 und Judith Grabmayer
17. Mai 2019

Zusammen mit BMW haben wir bei MaibornWolff im Juli 2018 die erste Teambox gestartet. Bei der Teambox sagt uns der Kunde was wir erreichen wollen, wir sagen, wie wir zum Ziel kommen.

Im Projekt-Format „Teambox“ geht eine Idee in wenigen Monaten live. Sie ist in vier Phasen unterteilt: In der Pitchphase prüfen Kunde und wir Art und Reifegrad einer Idee in zwei Tagen auf Herz und Nieren. Wichtig ist uns hier zum Beispiel, dass das gewünschte Ergebnis in wenigen Sprints umsetzbar ist.

Projekte, die diese Hürde schaffen, kommen in die Vorbereitungsphase: Sechs Menschen – drei von uns, drei vom Kunden – bereiten das Projekt fachlich, technisch und organisatorisch vor. Zum Ende gibt es ein initiales Backlog und ein Architektur-Konzept. In der Umsetzungsphase entwickelt das interdisziplinär besetzte Scrum-Team drei Monate lange den MVP. Zwei bis drei Entwickler aus unserem Team überführen den Prototyp anschließend in die Produktion Transfer: zwei Tage intensiv – drei Leute von uns, drei von Ihnen.

Im Interview erzählt Daniel Seidewitz, wie es ihm in dem Projekt ergangen ist und warum sich diese Art der Konzeptarbeit lohnt.

Die erste Teambox ist, wie vorgesehen, nach vier Monaten zu Ende gegangen. Wie geht es dir damit?

Die begrenzte Laufzeit gehört zum Konzept der Teambox, dennoch kam das Ende plötzlich. Wir haben noch fachlich gearbeitet, im letzten Sprint noch Features umgesetzt. Kein langsames Auslaufen wie bei ‚normalen‘ Projekten - selbst der Kunde war überrascht.

Bei der Teambox sind klare Phasen und Konzepte vorgesehen. Das Projekt ist zeitlich auf vier Monate begrenzt und der Kunde muss ein Team stellen. Die Menschen des Kunden und wir arbeiten konstant zusammen. Ist dieses Konzept aufgegangen?

Es hat Vorteile, so einen zeitlichen Rahmen zu stecken. Es zwingt zum Priorisieren. Ich finde, das hat sehr gut funktioniert. Das geht aber meiner Meinung nach nur, wenn der Kunde so stark eingebunden ist, wie es hier der Fall war. Es funktioniert nicht, wenn er nicht greifbar ist oder nur alle zwei Wochen einmal vorbeigeschaut. Der Kunde muss eng mit dem Team zusammenarbeiten, live den Fortschritt mitbekommen und sofort aktuelle Informationen weitergeben können.

Bevor das Projekt zum Projekt wurde, wurde die Idee in einem Pitch auf Herz und Nieren geprüft. Was hat es damit auf sich?

Für mich ist der Pitch ein wesentlicher Bestandteil. Denn: Mit so vielen Jahren Projektexpertise kennen wir die wichtigen Eckpfeiler und die Bedingungen für einen guten Projektverlauf. Das sind Faktoren wie eine klare Produktvision oder das richtige kulturelle Mindset. Genau diese Faktoren klären wir im Pitch ab. Wenn diese nicht gegeben sind, bleiben wir konsequent und machen das Projekt nicht.

Der Pitch soll das Projekt noch einmal kneten. Es geht für den Kunden darum, sich bewusst zu machen, was er genau vorhat. Wir schauen, ob der Scope klar definiert ist. Bei diesem Projekt haben uns zum Beispiel auf zwei Kern-Funktionen geeinigt. Das brauchst du bei so einem Time-geboxten Projekt und steigert am Ende die Erfolgschancen.

Damit alle Entwickler_innen gleich ab Tag 1 produktiv werden können, habt ihr das Projekt in einer dedizierten Vorbereitungsphase mit einem kleineren Team aufgesetzt. Was habt ihr in dieser Zeit gemacht?

Das Ziel war es, bereits am Ende des ersten Sprints etwas in der Umgebung am Laufen zu haben. Dafür hat unser Business-Analyst in der Vorbereitungsphase mit dem PO des Kunden Epics und User Storys entwickelt. Ich habe als Chef-Architekt überlegt, wie wir die Architektur bauen möchten und welchen Technologie-Stack wir einsetzten wollen. Diese Infrastruktur haben wir gleich aufgesetzt, um die Sachen dorthin deployen zu können. Ohne diese Vorabrieten hätten wir nicht gleich am ersten Tag von Sprint 1 mit dem Umsetzen der User Stories loslegen können.

Ich denke, der Ansatz hat auf jeden Fall funktioniert. Das Kernteam hat so sehr effizient die Voraussetzungen geschaffen, damit am Tag eins der Hauptphase das komplette Team durchstarten kann.

Was passiert dann während des Projektes: Wird der Scope noch mal in Frage gestellt?

Ja und nein: Wir haben die zwei Kernfunktionen zunächst in einzelne Epics hinuntergebrochen. Diesen Initialstand konnten wir als Grundumfang verteidigen.

Als wir die Epics in User-Stories konkretisiert haben, gab es welche, die hineingepasst haben, und welche, die unserer Meinung nach erst mal nicht so wichtig für das erste MVP waren. Außerdem sind immer mal User Stories dazu gekommen oder weggefallen. Hier gab es also schon Veränderung. Wir haben deswegen kontinuierlich geschaut, was noch in die Box hineinpasst.

Die Teambox schafft einen Rahmen um ein agiles Vorgehen. An welchen agilen Frameworks habt ihr euch orientiert?

Wir haben die konventionellen Ansätze über Bord geworfen. Stattdessen haben wir vieles ausprobiert, von dem wir überzeugt waren, dass es in diesem Setup funktioniert. Viele Sachen werden im Projektalltag aus Gewohnheit gemacht. Wir haben immer überlegt, ob es leichtgewichtigere Alternativen gibt.

Zum Beispiel haben wir nicht geschätzt, wie aufwendig eine User Story ist. Wir haben versucht alle Storys möglichst klein und gleich groß zu halten und dadurch eine gute Fortschrittsprognose zu bekommen. Für mich ist es Teil des agilen Mindsets: Baue nur Sachen, die du wirklich brauchst.

Gab es Verzögerungen während des Prozesses?

Ich hätte mir gewünscht nach vier Sprints die Nutzer auf Produktion zu haben, um das Feedback in die aktuelle Entwicklung einbauen zu können. Es könnte nicht schaden, das beim nächsten Pitch noch stärker zu beachten.

Wie wirkt sich die enge Zusammenarbeit mit dem Kunden aus, im Gegensatz zu anderen Projekten?

Ich habe noch nie erlebt, dass das gemeinsame Produkt ein Team so stark zusammenschweißt. Der Kunde und wir haben uns dank gemeinsamer Vision als großes Produktteam gefühlt.

Woran lag es, dass ihr so arbeiten konntet?

Ich glaube, da spielen mehrere Faktoren mit hinein. Zum einem, dass wir uns nur vier Monate Zeit geben, diese Beschränkung hat dazu geführt, dass wir das Ziel nie aus den Augen verloren haben. Zum anderen haben die Leute, die dabei waren, das Projekt ohne Einschränkungen mitgetragen. Und, dass wir von Anfang an gesagt, wie es laufen soll. Dabei konnten wir uns auf unsere Erfahrungen aus den agilen Festpreisprojekten stützen.

Den bei vielen agilen Festpreisprojekten muss man Punkt genau festlegen, was umgesetzt wird – so nimmt man die ganze Agilität wieder heraus. Hier haben wir das nicht gemacht. Es gab eine Vision, an der wir zusammengearbeitet haben und diese hat sich von Anfang bis Ende durchgesetzt.

Der Erfolg der Teambox beruht auch darauf, dass wir vorgeben wie das optimale Team ausschauen muss - denn um effizient arbeiten zu können brauchen wir alle Kompetenzen. Wir hatten BAs, UX aber auch einen Vollzeit Scrum-Master dabei.

Es ist cool mal miterlebt zu haben, wie es nach dem Bilderbuch läuft. Aber wir haben hart dafür gearbeitet. Das Gefühl, „Wir erschaffen etwas“ führt dazu, dass man noch mehr Einsatz zeigt.

Auf welchem Stand ist das Produkt jetzt?

Wir haben die Nachbetreuungsphase abgeschlossen, mittlerweile ist das Nachfolgeprojekt gestartet - ebenfalls als Teambox.

Dein Teambox-Fazit?

Ich glaube für den Kunden kommt am Ende mehr heraus, als bei einem klassischen Modell. Auch, wenn es sehr viel beidseitiges Vertrauen braucht.

Mehr Informationen zur Teambox gibt es hier: maibornwolff.de/teambox

Neuen Kommentar schreiben

Public Comment form

  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3>

Plain text

  • Keine HTML-Tags erlaubt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

ME Landing Page Question