Agile Softwareentwicklung ist in aller Munde, Scrum ist der Schlachtruf, mit dem der klassischen Projektlandschaft der Kampf angesagt wird. queo 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: Was machst du bei queo?

Robert Tietze: Ich bin Technical Consultant und Account Manager bei queo. Als technologischer Konzepter entwickle ich gemeinsam mit dem Kunden Ideen und entwerfe Konzepte zur Umsetzung dieser Ideen. Ich prüfe Workflows sowie Anforderungen und betreue die Softwareprojekte der Kunden. Es ist meine Aufgabe, Ideen zu bewerten und mit dem Kunden die beste Lösung für sein Problem zu finden. Ich habe als Werkstudent an queos Social-Media-Konzept gearbeitet und bin dann bei queo ins Projektmanagement für Webseiten, Blogs und Social-Media gekommen. Ich bin nach Abschluss meines Wirtschaftsingenieur-Studiums aber recht schnell in den Technology Bereich gewechselt, weil mich die Konzeptarbeit und der Weg von der Idee zur Umsetzung von Software-Projekten am meisten gereizt haben. Dass meine Arbeit nicht nach der Erstellung des Konzepts aufhört, sondern die Projekte von mir bis zum Schluss betreut werden, war für mich am attraktivsten. Was einige vielleicht als Spagat empfinden, ist für mich eine tolle Schnittstelle. Dadurch, dass ich mehrere Bereiche bei queo kennenlernen konnte, habe ich einen großen Vorteil: Ich weiß, wer wie tickt und wo welche Kompetenzen liegen – zum Beispiel bei Softwareprojekten, bei denen ein Interactive oder UX-Designer gebraucht wird. Viele Kunden schätzen den übergreifenden Austausch.

JD: Was findest du am Projektalltag am besten? Was am herausforderndsten?

RT: Wenn der nächste Release gut ankommt und ich Feedback vom Kunden bekomme. Das ist das Schöne als Technology Consultant – ich bin direkt am Kunden dran und gleichzeitig die Schnittstelle zum Team. Ich bekomme Erfolg und Misserfolg hautnah mit. Am herausforderndsten ist es, meine Rolle als Account Manager für die Volkswagen AG und meine Rolle als Projektmanager auszufüllen ohne meine anderen Projekte zu kannibalisieren, da ich auf die gleichen personellen Ressourcen zugreife. Hier kommt mir der agile Ansatz sehr zugute.

Ich denke viele Kunden müssen noch stärker für den Ansatz der agilen Entwicklung sensibilisiert werden.

JD: Und was sind für deine Kunden die größten Herausforderungen bei Softwareprojekten?

RT: Für meine Kunden ist die Erwartungshaltung an das Ergebnis schwierig. Der Kunde hat meistens ein Lasten- oder Pflichtenheft, in dem 100 Funktionen drin stehen, von denen er 90 auf jeden Fall und 10 vielleicht haben möchte. Er möchte in einem Jahr das Ergebnis zum Preis X haben, aber im Detail fehlen noch viele wichtige Informationen. Manchmal bekomme ich genauso eine Liste mit der Bitte, es agil umzusetzen. Entweder, weil agile Entwicklung ein Buzzword ist, oder weil man schon viel Gutes darüber gehört hat. Ich hab das Gefühl, manche wollen den Weg gehen, weil man nach kurzer Zeit wirklich schon was in der Hand hat, vergessen dabei aber, dass agiles Vorgehen bestimmte Haltungen und Regeln mit sich bringt. Ich denke viele Kunden müssen noch stärker für den Ansatz der agilen Entwicklung sensibilisiert werden.

JD: Du sprichst von Regeln: Wenn dein Team agil arbeitet, haltet ihr euch immer an die „Regeln“?

RT: Wir versuchen schon seit vielen Jahren immer weniger nach dem klassischen Wasserfallmodell und immer stärker agil zu arbeiten. Man muss aber realistisch sein: Manchmal geben es die Projektteamgrößen einfach nicht her, dass man 1:1 agil vorgeht. Es macht auch nicht immer Sinn, sich ganz streng an die „Regeln“ zu halten, das ist auch vom jeweiligen Projekt abhängig. Trotzdem bedienen wir uns an den agilen Werkzeugen und Methoden, um das beste Ergebnis zu erzielen. Das nennen wir dann liebevoll „agile Wasserfälle“. Demnach arbeiten wir nicht 100%ig nach Scrum. Wir entwickeln agil und haben uns entsprechend aufgestellt, haben das Beste aus den Methodensets mitgenommen. Selbst im agilen Manifest ist nicht alles in Stein gemeißelt, zum Beispiel die Product Vision – auch wenn sie gerade bei größeren Projekten wirklich sinnvoll ist.

JD: Du kennst beide Seiten, klassisches Projektmanagement und Scrum-Modelle, was sind die größten Unterschiede in der Arbeitsweise?

RT: Der größte Unterschied sind die zeitnahen Ergebnisse, die ich mit Scrum erziele. Große Umfänge sind besser umsetzbar und Zwischenstände bewertbar. Aber man muss schon ehrlich sein: Im Klassischen gibt es genauso Tests. Aber diese intensive Nutzerinteraktion – das ist schon ein Alleinstellungsmerkmal. Genauso wie der Raum, um ursprüngliche Ideen immer wieder zu bewerten, zu hinterfragen und die Sinnhaftigkeit zu prüfen. Ich würde keinem Kunden unterstellen, dass er nicht weiß, was er will. Gerade wenn ein Pflichtenheft erstellt wurde, dann ist schon sehr viel Arbeit reingeflossen. Problematisch ist meistens eher die Definition der tatsächlichen Anforderung an die Anwendung. Im Agilen kann ich in solchen Fällen auch die A/B-Entwicklung laufen lassen und wirklich zwei unterschiedliche Varianten ausprobieren, beispielsweise mit zwei unterschiedlichen Nutzergruppen – und nicht nur durchdenken. So bin ich viel näher am Nutzer dran. Was will er, was nimmt er besser an? Gerade für die Usability ist das elementar – das kann man auch nur sehr schwer vordenken. Oft wird nur Arbeit in die Funktionen gesteckt, und die UX wird vernachlässigt – dabei gibt es so viele Wege, die nach Rom führen, und welcher Weg es wird, das ist letztlich für den Nutzer ausschlaggebend. Ganz klassischer Anwendungsfall aus der Industrie: „Das ist unsere Excel-Tabelle, die soll sicher werden und ins Web.“ Mehrere Nutzer sollen gleichzeitig daran arbeiten können und die Daten sind vertraulich. Wenn man klassisch vorgeht, hat man nach der Entwicklungszeit eine Excel, die im Web ist. Agil haben wir aber die Möglichkeit, einzelne Daten, Funktionen und auch optische Aspekte zu hinterfragen.

JD: Welche Auswirkungen hat agiles Vorgehen auf die Zusammenarbeit mit dem Kunden?

RT: Man arbeitet enger zusammen, man lernt sich besser kennen. Im Klassischen ist es tatsächlich so: Du holst dir dein Heft ab, machst die Zeitschiene auf und vielleicht gibt es noch einige kleinere Absprachen, aber es ist bei Weitem nicht so ein Miteinander wie im Agilen. Du bist im Prinzip „gezwungen“, immer wieder miteinander zu sprechen. Der Abstimmungsaufwand ist zugegebenermaßen größer – aber das was hinten rauskommt, ist immer besser. Ein Entwickler entwickelt eben auch nicht gerne für die Tonne. Es hilft niemandem, wenn er sich ein Vierteljahr einschließt und dann heißt es, die Funktion brauchen wir eigentlich doch nicht. Der regelmäßige Austausch mit dem Kunden ermöglicht uns Consultants, unsere Kunden besser kennenzulernen. Wie tickt der, was ist seine Erwartungshaltung – gerade wenn er eine Beschreibung abgibt – was steckt da noch zwischen den Zeilen? Eine partnerschaftliche Ebene ist wichtig und man darf sich nicht als ein Dienstleister verstehen, der ohne zu hinterfragen Dinge einfach nur umsetzt. Die Kommunikation lohnt sich immer. Man hat gemeinsam etwas entwickelt, was gebraucht wird, was genutzt wird und was wirklich einen Mehrwert hat. Als Dienstleister hat man damit ein Gesicht, unsere Kunden schätzen das sehr. Tonne

JD: Merkt man, ob der Kunde Scrum-erfahren ist?

RT: Wenn ausgebildete Leute da sind, dann auf jeden Fall. Da ist die Herangehensweise und auch Erwartungshaltung eine ganz andere. In meinen Projekten war es meist so, dass der Kunde bereits vom agilen Vorgehen gehört hat. Viele Kunden sind bereit, von uns zu lernen. Wir regen immer an, einen Verantwortlichen festzulegen – das geht in Richtung Product Owner – und wenn wir denjenigen gut abholen, also seine Rolle definieren, und klären, wie wir zusammenarbeiten wollen, dann funktioniert das schon ganz gut. Es gibt aber durchaus auch Kunden, die nach Scrum ausgebildete Teams haben. Da brauchen wir dann nur ein Wiki- oder ein Bugtracking-System und wir kriegen Tickets beziehungsweise Userstories und können in die Umsetzung starten. Wenn der Kunde Scrum richtig kennt und einen Product Owner bereitstellen kann, ist das natürlich optimal. Aber wenn der Kunde ein Bewusstsein für die Rollenverteilung entwickelt hat, reicht das zumeist auch schon. Aus diesem Grund führen wir Workshops durch, in denen wir zeigen, wo die Unterschiede von Product Owner und Projekt Manager liegen, und wir den Teilnehmern die Grundlagen und Methoden von Scrum vorstellen. Wir diskutieren in diesen Workshops, warum rund 20 % aller IT-Projekte abgebrochen werden, jedes zweite länger oder teurer als geplant wird und ob Planbarkeit und Einhaltung des Projektbudgets Gegenspieler von agilen Methoden sind. Um gemeinsam ein Projekt erfolgreich agil durchzuführen, sind diese Workshops als Vorbereitung optimal.

JD: Wem empfiehlst du agile Modelle und wem nicht?

RT: Alle Projekte die länger laufen, eignen sich für agiles Vorgehen. Der Mehrwert ist auch bei allen möglichen Anwendungen gegeben. Einzig bei sehr kleinen, kurzweiligen Projekten muss man aufpassen, dass kein Kommunikationsoverhead entsteht – da sollte man dann kritisch abwägen. Agil geht eigentlich immer und überall – man muss es nur wollen.

JD: Du arbeitest in deinen Workshops mit Bällen, um die Scrum-Rollen zu verinnerlichen – warum?

RT: Hinter der Ballthematik versteckt sich das Prinzip des selbstlernenden Teams. Man hat eine Aufgabenstellung, die zunächst etwas komisch, oder sagen wir schwierig, klingt. Diese Aufgabe könnte der Einzelne aus dem Stehgreif gar nicht lösen. Innerhalb des Teams macht man sich dann Gedanken dazu. Das zahlt darauf ein, dass agile Teams untereinander kommunizieren und sich austauschen. Die Bälle werden nach bestimmten Regeln weitergegeben und Ziel ist es, die Regeln innerhalb des Teams zu hinterfragen. So entstehen schnell praxisnahe und lösungsorientierte Ideen zur Optimierung dieser Regeln. Man kommt viel schneller zu einer Lösung, als wenn jeder für sich grübelt, wie er das am besten angehen könnte. Dadurch wächst auch das Teamgefühl. Als Einzelner hätte ich vielleicht gar nicht gemerkt, dass die Regeln keinen Sinn machen oder nicht funktionieren. Das kann man sich analog zu Anforderungen in der Softwareentwicklung vorstellen. Auch da macht es Sinn, zu hinterfragen und Wissen beziehungsweise Erfahrungen auszutauschen. Die Lernkurven im Agilen sind für die Teams sehr steil und man kann viel besser reagieren. Der zukünftige Product Owner lernt durch das „Ballspiel“ am eigenen Leib, wie ein Scrum-Team arbeitet. Er erkennt, dass alle an einem Strang ziehen und dass in dem Team Sachen entwickelt werden, die wirklich was bringen. Jemand, der vorher noch nicht agil gearbeitet hat, kann so ein Gefühl für agile Methoden entwickeln. Der Workshop bietet Raum, um einfach auch mal zu scheitern, oder sich an einer dieser Regeln die Zähne auszubeißen – so lernt man das am besten. Manche verrennen sich, andere gehen ganz kreativ damit um. Wir wollen mit den Workshops sensibilisieren. Was nützt es, wenn der Dienstleister von agilem Vorgehen schwärmt, der Kunde aber gar nicht die Möglichkeit hat, Vertrauen in dieses Vorgehen zu entwickeln?

JD: Wie wird sich die Projektlandschaft im IT-Umfeld deiner Meinung nach künftig entwickeln?

RT: Ich vermute, es wird weiterhin klassisches und agiles Vorgehen geben, wobei der Trend auf jeden Fall zu agilem Vorgehen geht. Wenn ich mir alleine die Marketingargumente betrachte: Produktentwicklung in überschaubaren Iterationen, rege Kommunikation mit Kunden und Teammitgliedern, kürzere Entwicklungszeiten mit handfesten Zwischenergebnissen, die Umsetzung von Änderungen im Projektverlauf. Wen spricht das nicht an? In dem Seminar, in dem ich nach Scrum zertifiziert wurde, waren auch Teilnehmer aus dem E-Government-Umfeld. Daran kann man erkennen, dass sich auch Themen mit sensiblen Daten und mit Fokus auf Sicherheit für agile Entwicklung eignen.

JD: Was war für dich bisher die außergewöhnlichste Erfahrung im Scrum-Kontext?

RT: Ich muss sagen, dass für mich inzwischen eher das klassische Vorgehen befremdlich und damit außergewöhnlich ist.

Als ich angefangen habe, sind wir schon „teil-agil“ vorgegangen. Für mich ist agiles Vorgehen eigentlich die logische Konsequenz, wenn man Software-Projekte erfolgreich durchführen will. Ich war vorher allerdings nicht im Software-Bereich und als ich eingestiegen bin, war agiles Vorgehen schon in aller Munde. Wenn ich die Theorie hinter klassischen Methoden betrachte, denke ich mir oft: „So will ich nicht arbeiten.“ Der hohe Anteil der Kommunikation im Agilen ist für mich das Außergewöhnliche: Ich will mit meinem Team sprechen, ich will mit meinen Kunden interagieren. Für den Kunden ist sicherlich das Budget-Thema außergewöhnlich. Wir können agil und budgetkonform arbeiten und das können sich viele nicht vorstellen, besonders Kunden, die mit dem Thema noch ein bisschen fremdeln. Ich stelle diesen Kunden gerne vor, wie wir agile Softwareentwicklung leben und wie wir damit umgehen – die meisten erkennen den Sinn und wollen es auch gerne ausprobieren. Ich habe bisher nur wenig Feedback bekommen, wo agile Methoden abgelehnt wurden. Der Kunde sieht die Vorteile. Und wenn ich ihn in die Entwicklung einbeziehe und die Vorteile, die Scrum bietet, nicht nur anpreise, sondern auch lebe, dann habe ich den Grundstein für die Akzeptanz von neuer Software schon gelegt. Wenn der Nutzer sieht, hier wurde etwas für mich entwickelt, hier wurde mein Feedback berücksichtigt – das ist so viel wert.