Scrum-Einführung im Startup

Plötzlich Product Owner

Hans Königes ist Ressortleiter Jobs & Karriere und damit zuständig für alle Themen rund um Arbeitsmarkt, Jobs, Berufe, Gehälter, Personalmanagement, Recruiting, Social Media im Berufsleben. Zusätzlich betreut das Karriereressort inhaltlich das Karrierezentrum auf der Cebit.
Was macht ein Startup, das eine neue Software braucht, ein begrenztes Budget hat, klare Vorstellungen und einen festen Zeitrahmen? Etengo-Chef Nikolaus Reuter berichtet von seinen Scrum-Erfahrungen.

CW: Wie sind Sie bei der Auswahl Ihres Lieferanten vorgegangen?

REUTER: Als wir einen Partner für die Softwareerstellung suchten, spielte Agilität für uns noch keine Rolle, ich konnte mit dem Begriff nicht viel anfangen. Klar waren dagegen die Anforderungen: Wir wollten einen Personaldienstleister etablieren, der schnell, einfach, transparent und preiswert IT-Freelancer vermittelt. Dazu brauchten wir eine leistungsfähige und neuartige Software. Also musste unser Partner fähig sein, innerhalb von neun Monaten aus unseren Ideen eine Software zu entwickeln. Bei der letztendlichen Entscheidung haben wir dann auch eine persönliche Empfehlung berücksichtigt.

CW: Wie war Ihre Ausgangslage?

Nikolaus Reuter, Etengo: "Ich hatte nur eine vage Vorstellung, was auf mich zukommt."
Nikolaus Reuter, Etengo: "Ich hatte nur eine vage Vorstellung, was auf mich zukommt."
Foto: Privat

REUTER: Wir hatten das Startkapital, aber eben nur neun Monate Zeit, um auf den Markt zu kommen. Das Karlsruher Softwarehaus Andrena bot mir an, nach der Scrum-Methode vorzugehen. Das sollte mir helfen, ein kontinuierliches Risiko-Management zu betreiben. Scrum sieht vor, in kurzen Abständen lauffähige Software zu liefern. Das senkt das Risiko.

CW: Inwiefern?

REUTER: Die Programmierarbeit wird in kurze, zeitliche Intervalle gegliedert, die Sprints. Am Ende jedes Sprints wird Software geliefert. Andrena hielt uns die Möglichkeit offen, nach jedem Sprint auszusteigen. Wir sahen also immer gleich, ob wir bekommen, was wir brauchen, und hätten uns andernfalls ausklinken können.

CW: Sie standen als Product Owner mitten im Entwicklerteam, das nach Ihren Anforderungen arbeiten sollte. Wie funktionierte das?

REUTER: Ich hatte nur eine vage Vorstellung davon, was in der Rolle des Product Owner auf mich zukommt. Aber eines war mir intuitiv klar: Dass die Entwickler den Geschäftsablauf und die Abläufe unserer Personaldienstleistung verstanden haben müssen. Also begannen wir mit einem Workshop, um über das IT-Freelancer-Geschäft ein gemeinsames Verständnis aufzubauen. Das hatte nichts zu tun mit der oft kolportierten Haltung "Hier ist ein Pflichtenheft, und jetzt seht zu, dass ihr das hinbekommt." Im Nachhinein kann ich sagen, dass auf dieser Veranstaltung der Funke übergesprungen ist, denn die Entwickler haben gemerkt, wie sehr ich dahinter stehe und wie leidenschaftlich ich unsere Idee verfolge.

CW: Entsprachen Ihre ersten Erfahrungen dem, was Sie erwartet hatten?

REUTER: Nicht immer. Mir wurde schnell klar, dass ich bestimmte Dinge anders formulieren und klarer vermitteln muss. Ich musste lernen, welche Informationen die Entwickler von mir brauchen und ob sie, wenn sie Fragen haben, damit zu mir kommen oder sie lieber unter den Tisch fallen lassen sollen. Ein Team zu bilden ist immer ein gegenseitiger Lernprozess.

CW: Bei Festpreisprojekten wandert das Projektrisiko sozusagen mit der Unterschrift zum Auftragnehmer, bei agilen Projekten nicht. Wie haben Sie als Project Owner Ihr Kapital gesichert?

REUTER: Indem wir konsequent die Instrumente der agilen Entwicklung genutzt haben. Das Instrumentarium wie etwa das Product Backlog und der Burndown Chart liefern genügend Steuerungsinstrumente, mit denen wir auch ohne Festpreis am Ende der Entwicklungsphase wirklich das bekommen, was wir brauchen. Nur weil man einen Festpreis vereinbart, heißt das im Umkehrschluss ja noch lange nicht, dass es bei den geplanten Kosten bleibt. Dann werden eben kleinste Abweichungen vom Pflichtenheft sofort als Sonderaufwand deklariert und extra abgerechnet.

CW: Was sollte ein Project Owner Ihrer Erfahrung nach auf keinen Fall tun?

REUTER: Er sollte keinesfalls vom Pfad der Tugend abweichen. Auch in unserem Projekt kam es an einem Tag X dazu, dass Akteure der Fachseite in alte Muster zurückfielen und versucht hatten, einen Bypass am Product Owner vorbei zu legen. Das muss sofort unterbunden und gerügt werden. Im Scrum-Prozess hat eben nur einer den Hut auf.

CW: Was hat Sie am stärksten davon überzeugt, dass Ihre Entscheidung für agiles Entwickeln richtig war?

REUTER: Erstens sind die Kosten überschaubar. Ich bezahle nach jedem Sprint, also für bereits geleistete Arbeit, und kann anhand der Ergebnisse immer gleich beurteilen, ob das Gelieferte sein Geld wert ist. Zweitens verringere ich das Risiko, weil ich laufend Ergebnisse bekomme, die ich testen und bewerten kann. Ich riskiere nicht, nach Monaten Entwicklungszeit auf den Markt zu gehen und dann zu hören, sorry, das brauchen wir nicht. Und drittens muss ich nicht in Vorleistung gehen und ein Pflichtenheft abgeben. Der letzte Punkt hatte für mich große Bedeutung, weil ich nicht sechs Monate in einem Kämmerlein sitzen und etwas vordenken wollte, was ich vielleicht gar nicht vordenken kann, weil ich die technischen Möglichkeiten nicht kenne.

CW: Wie viel Aufwand handelt sich ein Product Owner ein?

REUTER: Sehr viel. Wenn man diese Rolle ernst nimmt, kann das ein Fulltime-Job sein. Aber man lernt sehr viel. Und es kann auch sehr befriedigend sein, mal schnell und einfach Entscheidungen zu treffen.