Agile Softwareentwicklung ist in aller Munde, Scrum ist der Schlachtruf, mit dem der klassischen Projektlandschaft der Kampf angesagt wird. queoflow setzt bereits zahlreiche Projekte agil um. In dieser Gesprächsreihe berichten Mitarbeiter von ihren Erfahrungen in agilen Projekten und wie Lego, Papierflieger und Bälle unsere Softwareentwicklung besser machen.

Johanna Darbritz: Kurz und knapp: deine Aufgabe bei queo?

Tobias Hugk: Ich bin Projekt Manager bei queo und verantworte dabei vor allem Projekte der Marke queoflow, also aus dem Umfeld der Individualsoftware-Entwicklung. Damit bin ich quasi das Bindeglied zwischen den queos und dem Kunden.

JD: Was sollte ein PM deiner Meinung nach mitbringen?

TH: Gute Frage, es gibt vieles, was einem in den unterschiedlichen Augenblicken des Projektalltages helfen kann. Als Projekt Manager muss man sich schnell auf neue Gegebenheiten einstellen können. Man sollte über ein gewisses Organisationstalent verfügen und das auch in stressigen Situationen noch abrufen können. Auch wenn man besprochene Punkte sofort wieder vergisst, ist es vielleicht der falsche Job. Ansonsten gibt es Tools, die einem bei der Arbeit helfen.

Mir persönlich hilft es, dass ich recht ausgeglichen und gelassen an die Projekte rangehe. Außerdem habe ich eine Weile lang selbst als Entwickler gearbeitet. Begeisterung, sich immer wieder in neue Projekte und Aufgaben reinzudenken sollte man auf jeden Fall mitbringen. Und gern mit vielen verschiedenen Menschen zusammenarbeiten wollen

Die größte Herausforderung liegt also darin, den Nebel zu beseitigen und bei allen Beteiligten die notwendige Klarheit zu bekommen.

JD: Was sind in deinem Arbeitsalltag als Projekt Manager die größten Herausforderungen?

TH: Nicht selten gibt es zum Start des Projektes eine lange Liste an Wünschen, einen konkreten, meist sehr nahen Zeitpunkt, wann alles fertig sein soll, und ein fixes Budget. Die größte Herausforderung für mich liegt aber darin, zu verstehen, was der Kunde wirklich für ein Problem hat und gemeinsam mit ihm und dem Entwicklerteam eine Lösung dafür zu erarbeiten, d.h. aus der Liste von Wünschen, diejenigen herauszusuchen, die wir in der zur Verfügung stehenden Zeit realisieren können und die den Kunden weiter bringen. Die größte Herausforderung liegt also darin, den Nebel zu beseitigen und bei allen Beteiligten die notwendige Klarheit zu bekommen. Bei den Entwicklern dafür, was sie erschaffen sollen, und beim Kunden dafür, was er am Ende des Projektes erwarten kann.

Ansonsten Dinge aus dem Projektalltag: Manchmal dauert etwas länger als am Anfang geplant, Entwickler werden krank oder müssen in anderen Projekten eingesetzt werden, dem Kunden fallen doch noch wichtige Punkte ein, die unbedingt berücksichtigt werden müssen: Aber das sind alles Dinge, mit denen man umzugehen lernt.

JD: Was bedingt die genannten Punkte – und wer hat Schuld an deren Entstehung?

TH: Das kann ganz verschiedene Ursachen haben und einen Schuldigen kann man nur schwer ausmachen: Manchmal hat sich der Kunde am Anfang noch nicht mit den wichtigen Punkten beschäftigt – da kommt im Projektverlauf schon mal was ganz Neues auf. Teilweise kommen komplett neue Stakeholder hinzu, denen dann ganz andere Features am Herzen liegen. Oder aber die Anforderungen auf Kundenseite sind klar, doch während der Entwicklung stellt sich heraus, dass die Entwickler etwas anderes verstanden haben und dementsprechend auch anders umgesetzt haben.

Wenn agiles Vorgehen nur dazu dient, sich nicht festlegen zu müssen und den Kurs ständig zu ändern, dann hat man was falsch verstanden.

JD: Klingt fast, als ob es in einigen Projekten nicht ganz rund läuft?

TH: Das kommt drauf an, was man als „nicht ganz Rundlaufen“ definiert. Eine gewisse Abweichung findet sich in fast jedem Projekt. Das ist einer der Gründe, warum wir bei queo häufig einen agilen Entwicklungsprozess vorschlagen. Damit können wir uns gemeinsam mit dem Kunden iterativ in kleinen Schritten, sogenannten Entwicklungs-Sprints, seinen Wünschen nähern. Leider hatte ich aber auch schon Projekte, bei denen am Anfang so wenig Klarheit herrschte, dass wir uns in unheimlich vielen Iterationen dem Ziel nähern mussten, also die Entwickler von einem zum nächsten Sprint die Lösung nicht verfeinern konnten, sondern in eine komplett andere Richtung entwickeln mussten. Auch bei einem agilen Vorgehen ist es also wichtig, eine Vision für das fertige Produkt zu haben. Wenn agiles Vorgehen nur dazu dient, sich nicht festlegen zu müssen und den Kurs ständig zu ändern, dann hat man was falsch verstanden.

JD: Du hast dich als Product Owner ausbilden und zertifizieren lassen – kannst du seither in deiner Arbeitsweise Unterschiede feststellen?

TH: Prinzipiell ist es nicht so, dass ich meine Aufgaben als Projekt Manager bei queo komplett anders angehe. Als Product Owner aufzutreten ist ja auch etwas anderes, als die typischen Aufgaben eines Projekt Managers zu erfüllen. Optimalerweise wird die Rolle des Product Owners vom Kunden besetzt. Doch obwohl die Rolle des Product Owners bei einem agilen Vorgehen wichtig ist, wird sie häufig noch stiefmütterlich behandelt. Wenn beim Kunden keine Ressourcen zur Verfügung stehen, sodass die Rolle von ihm besetzt wird, dann kann ich nun besser einspringen und versuchen, die Aufmerksamkeit des Kunden stärker auf die Aufgaben dieser Rolle zu lenken. Also auf die Sachen, die er tun muss, besser gesagt, die ein Product Owner bei ihm tun müsste. Zu den Aufgaben des Product Owners gehören unter anderem, dass die Anforderungen klar benannt sind, die Belange aller Stakeholder berücksichtigt sind, die Aufgaben für die Entwickler priorisiert im Backlog enthalten sind und den einzelnen Sprints zugeordnet werden. Wenn ich als Product Owner auftrete, versuche ich im Prinzip den Kunden bei uns im Projektkontext innerhalb des Teams zu repräsentieren.

JD: Das klingt nach Interessenskonflikt: Stellt dich das zwischen zwei Stühle?

TH: Ja, das stellt einen immer etwas zwischen die Stühle. Ich kann die Kundenanforderungen sehr gut nachvollziehen, sehe aber auf der anderen Seite was das Team leisten kann. In der Rolle als Product Owner steht vor allem das Produkt im Fokus, als Projekt Manager die Zeit und das Budget. Da kann es schon mal zu einem Interessenskonflikt kommen. Schlussendlich muss aber beides zusammenpassen. Wie genau die Lösung aussieht, kann nur gemeinsam mit dem Team und dem Kunden entschieden werden. Es läuft also in beiden Fällen darauf hinaus, diesen Prozess zu moderieren. Schlussendlich muss es für Entwickler und Kunden tragbar sein und nicht für mich.

Am Ende zählt ein gutes Ergebnis. Und da ist dann egal, ob ich als Projekt Manager oder Product Owner dazu beitragen konnte.

JD: Aber hilft es dir, beide Rollen zu kennen?

TH: Auf jeden Fall. Den Blickwinkel zu ändern hilft einem dabei, zu erkennen, wo das Projekt gerade wirklich steht. Vor allem wenn es keinen Product Owner auf Kundenseite gibt, kann ich damit Fehlentwicklungen entgegensteuern, indem ich diese Rolle bewusst übernehme. Ich kann schneller warnen: „Das wird so nicht funktionieren!“ Nicht erst, wenn das Projekt schon aus dem Ruder gelaufen ist. In diesem Sinne hilft einem Projekt Manager der Perspektivenwechsel auch in nicht agilen Projekten. Am Ende zählt ein gutes Ergebnis. Und da ist dann egal, ob ich als Projekt Manager oder Product Owner dazu beitragen konnte.

Wenn nicht klar ist, was am Ende wirklich rauskommen soll, und keiner sich verantwortlich fühlt, diese Klarheit zu schaffen, dann wird es schiefgehen.

JD: Was empfindest du bei agilem Vorgehen als positiv, was als negativ?

TH: Für mich in der Rolle des Projekt Managers ist es gut, jederzeit zu wissen, wo das Projekt steht. Dank abgenommenen Zwischenständen, der Klarheit für den nächsten Entwicklungssprint und einem gepflegten Backlog, in dem steht, wo die Reise noch hingehen soll, hat das Projekt einen verlässlichen Rahmen. Als Product Owner habe ich den letzten Zwischenstand intensiv getestet, weiß, was schon geht und was nach dem aktuellen Sprint gehen wird. Ich kann sofort gegensteuern, wenn ich merke, dass die aktuellen Funktionalitäten noch Verbesserungsbedarf haben.

Negativ wird es vor allem dann, wenn zentrale Punkte vernachlässigt werden. Wenn aus dem Backlog nicht hervorgeht, was noch zu tun ist, wenn der Product Owner die Anforderungen nicht beschreibt oder zu Beginn eines Sprints noch nicht alle Entscheidungen getroffen wurden, die für diesen Sprint notwendig sind, oder noch Zuarbeiten fehlen. Agiles Vorgehen bietet einige Vorteile, es ist aber vor allem auch die Bereitschaft, sich mit dem Produkt zu beschäftigen. An dieser Stelle unterscheiden sich agile und klassische Projekte dann auch nicht viel. Wenn nicht klar ist, was am Ende wirklich rauskommen soll, und keiner sich verantwortlich fühlt, diese Klarheit zu schaffen, dann wird es schiefgehen. Egal, ob ich gleich komplett in die falsche Richtung entwickle oder in kleinen Schritten immer wieder was anderes tue.

JD: Die Vor- und Nachteile sind sicherlich auch den Kunden bekannt: Wie stehen die eigentlich zum agilen Vorgehen?

TH: Heutzutage hat definitiv jeder IT-Verantwortliche schon davon gehört und viele liebäugeln damit, auch große Firmen mit großen Projekten. Viele Kunden kommen auf uns zu und wollen gern agil arbeiten. Klingt ja auch gut. Doch der Wunsch allein reicht leider nicht. Auch die Rahmenbedingungen müssen stimmen. Wichtig ist, dass Kunde und Dienstleister gemeinsam etwas erreichen wollen und sich gegenseitig vertrauen können. Gerade wenn nicht im Vorfeld detailliert beschrieben ist, was der Kunde am Ende in den Händen hält, muss sich der Kunde darauf verlassen können, dass die Entwickler ihr Bestes geben. Und als Kunde muss einem klar sein, dass es nicht reichen wird, am Anfang ein Briefing auf den Tisch zu legen und am Ende zu schauen, ob alles umgesetzt wurde, sondern der Kunde genauso hart für den Erfolg des Projektes mitarbeiten muss wie die Entwickler. Wenn sich alle Beteiligten darüber einig sind, dann findet sich auch für die ewig misstrauische Konzernbeschaffung ein Weg, dass sie das notwendige Budget freigeben.

Ob es dann Meilenstein, Zwischenabnahme oder Sprint heißt, ist am Ende nur Wording. Wichtig ist es, die richtigen Werkzeuge auszuwählen.

JD: Wem empfiehlst du agile Modelle und wem nicht?

TH: Empfehlen würde ich es bei Neuentwicklungen, wo man bei null anfängt und noch nicht genau weiß, wo die Reise hingehen soll. Da liegen die Vorteile klar auf der Hand. Wenn ein Projekt irgendwann eine Phase erreicht hat, wo es nur noch betreut wird und kleine Supportanfragen bearbeitet werden müssen, dann hilft agiles Vorgehen nicht mehr viel. Ansonsten ist es einfach ein Modell und kann ganz unterschiedlich angewendet werden. Man kann es sich als ein Methodenset mit verschiedenen Werkzeugen vorstellen. Viele Werkzeuge zu kennen und anwenden zu können, wird einem Projekt Manager immer helfen, egal um welches Projekt es sich handelt. Ob es dann Meilenstein, Zwischenabnahme oder Sprint heißt, ist am Ende nur Wording. Wichtig ist es, die richtigen Werkzeuge auszuwählen. Aber wenn man sich für ein agiles Vorgehen entscheidet, dann sollten einem auch die sich daraus ergebenden Aufgaben bewusst sein

JD: Wird im IT-Umfeld künftig nur noch agil entwickelt?

TH: Nein. Das denke ich nicht. Der Anteil an agilen Projekten wird sicherlich zunehmen. IT-Projekte werden in jedem Fall immer komplexer werden. Es wird immer mehr Schnittstellen geben und immer schwieriger werden, im Vorfeld alle Bedingungen genau zu definieren. Dadurch wird agiles Vorgehen für solche Projekte immer interessanter und dafür ist es geeignet. Aber es wird auch Projekte geben, wo einfach am Anfang klar gesagt werden kann, was am Ende rauskommen soll.

JD: Du bist seit einiger Zeit nach Scrum zertifizierter Product Owner. Wie sah das Seminar aus und brauchen das jetzt alle Mitarbeiter?

TH: Im Seminar haben wir in Teams gegeneinander Papierflugzeuge gebaut. Wir hatten ein konkretes Ziel: in einer bestimmten Zeit, also einem Sprint, möglichst viele Flieger zu produzieren, die dann über eine bestimmte Linie segeln. Nach einem Sprint haben wir geschaut, was wir optimieren können: Die Falttechnik zum Beispiel. Oder die Aufgabenteilung im Team. Dazu stand uns ein Product Owner zur Verfügung, mit dem wir unsere Optimierungen abstimmen mussten.

Wir haben uns vergegenwärtigt, stets die Sinnhaftigkeit der Anforderungen zu hinterfragen. Das kann wirklich hilfreich sein. Warum sollten wir ein A4 Blatt in 4 kleine Stücke zerschneiden und daraus Flugzeuge bauen, obwohl die Anzahl der zur Verfügung stehenden Blätter unbegrenzt war und die großen Flugzeuge auch noch viel weiter fliegen können, als die kleinen. Ein anderes Team kam auf die Idee, das Papier einfach zu zerknüllen und hinter die Linie zu schmeißen. Das Papier ist dann zwar an Ort und Stelle, aber als Flugzeug wird man das Knäuel wohl kaum bezeichnen können. Das ist auch eine Aufgabe des Product Owners. Die Entscheidung herbeizuführen, ob die Optimierung dem Produkt dienlich ist. Aber: Man muss nicht unbedingt eine Zertifizierung haben, um agil arbeiten zu können. Viele Kollegen, die in den Scrum-Teams arbeiten, haben sich schon so an die Arbeitsweise gewöhnt, dass ein Zertifikat für sie keinen Unterschied mehr machen würde. In vielen Momenten kamen mir während der Schulung Aha-Effekte: Mensch, das machen wir doch schon lange so. Aber die Weiterbildung hat mir geholfen, alles nochmal zu durchdenken und die tägliche Arbeit zu reflektieren und sich bewusst zu machen, warum etwas in bestimmten Situationen geholfen hat und warum vielleicht auch gerade nicht. Das war sehr wertvoll.