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?
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.
- Kleines Scrum-Glossar
Was meint eigentlich Scrum, Product Owner oder Backlog? Wir stellen Ihnen die wichtigsten Begriffe und ihre Bedeutung vor. - Scrum
Der Begriff stammt aus dem Rugby und bedeutet wörtliche "Gedränge". In der Softwareentwicklung bezeichnet er ein Vorgehensmodell der agilen Softwareentwicklung, das 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle veröffentlicht wurde. - Das Scrum-Team
Aufgabe des Teams ist es, die Anforderungen der Fachabteilung umzusetzen. Es bietet drei Rollen: - 1. Rolle: Product Owner
Er vertritt den Auftraggeber, also die fachliche Seite. Also zeichnet er für die Priorisierung der Anforderungen verantwortlich und letztlich auch für den Nutzen, den das Projekt dem Unternehmen bringt. - 2. Rolle: Scrum-Master
Er ist quasi der Herr über die Prozesse. Er sorgt dafür, dass die Scrum-Regeln im Projekt eingehalten werden, er fördert die Transparenz, unterstützt das Team bei der Beseitigung von Hindernissen und sucht ständig nach möglichen Verbesserungen. - 3. Rolle: Die Entwicklergruppe
Sie besteht idealerweise aus sieben Entwicklern. - Sprint
Mit diesem Begriff bezeichnet Scrum einen Iterationszyklus, innerhalb dessen ein Scrum-Teams eine Anforderung umsetzt. Ein Sprint dauert mindestens zwei Wochen und maximal einen Monat. - Backlog
So heißt in Scrum die priorisierte Anforderungsliste für das zu entwickelnde Produkt. Sie wird vom Product Owner verantwortet und gepflegt. - Definitionen von fertig
Dabei handelt es sich um die Kriterien, unter den ein Produkt als umgesetzt akzeptiert wird.
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.