Agile vs. klassische Projektmethoden – Teil 1

Scrum, Rapid Prototyping, V-Modell – sind agile Methoden eine Modeerscheinung oder wirklich immer und überall besser?

Aus meiner täglichen Arbeit und der Arbeit unserer Kunden sind mir primär die klassischen Projektmanagementmethoden geläufig. Natürlich habe ich auch schon einiges über agile Methoden und Scrum gelesen, aber weniger Berührungspunkte in der Praxis gehabt. Um einige zentrale Aspekte agiler Methoden mal genau unter die Lupe zu nehmen, traf ich mich mit Henning Wolf, Geschäftsführer der it-agile GmbH, zu einem Interview.

Hier steht weniger die Theorie im Fokus, sondern praxisrelevante Informationen und Erfahrungen von Profis im Bereich der agilen Methoden. Das Interview ist in 3 Teile gegliedert. In diesem ersten Teil sprechen wir generell über die Herausforderungen bei der Einführung von Scrum und hinterfragen unser eigenes agiles Vorgehen mit Rapid Prototyping in Kundenprojekten.

Henning, gibt es entscheidende Rahmenparameter, die man braucht um Scrum einzuführen? Wie sind da deine Erfahrungen, was sind Rahmenparameter, ohne die man das sowieso nicht einführen könnte?

Vermutlich muss man sich auf dem Weg zu Agilität darauf einlassen und damit leben, dass das nicht auf Anhieb ein Erfolg wird. Wenn agiles Arbeiten neu ist, wie sonst auch bei neuen Arbeitsweisen, dann geht meistens die Leistung erstmal ein ganz bisschen runter. Vielleicht manchmal nicht nur ein bisschen, vielleicht manchmal sogar viel, weil man noch nicht weiß, wie das Neue funktioniert.

Wenn man auf ITIL umsteigt, passiert genau dasselbe. Das es erstmal schlechter wird, weil unklarer. Und da muss man einfach durch, muss man sich drauf einlassen. Natürlich gibt es Dinge, die die Einführung von Scrum begünstigen oder erschweren.

Oft haben Unternehmen die Leute in zu vielen Projekten eingeplant. Also ein Entwickler ist in fünf Projekten gleichzeitig. Das funktioniert nie gut. Das funktioniert auch mit Scrum nicht gut. Das liegt aber nicht daran, dass Scrum kaputt ist oder dass man für Scrum andere Vorausbedingungen braucht, sondern dass das einfach keine clevere Idee ist, dass jemand in fünf Projekten gleichzeitig arbeitet.

Idealerweise hat man also Leute im Scrum Team, die nicht nur für zwei Minuten in diesem Scrum-Team sitzen, sondern die nahezu Fulltime-Mitglieder des Scrum-Teams sind. Wir sagen immer: 70 bis 80 % seiner Arbeitszeit in einem Team zu sein, das wäre schon eine wünschenswerte Voraussetzung für Scrum.

In klassischen Unternehmen kommt ja häufig der Chef vorbei, der immer wenn irgendwo etwas in Schieflage kommt, interveniert und aus Projektteams Mitarbeiter dringend für etwas Anderes benötigt.
Wenn ich nun Scrum eingeführt habe und da gibt es einen Scrum-Master, der jetzt plötzlich sagt: „Moment mal, so funktioniert das nicht.“, gibt es da Erfahrungen, funktioniert das mit Scrum besser oder stelle ich mir das jetzt zu einfach vor? Gibt es da nicht auch die gleichen Interessenkonflikte?

Natürlich gibt es da einen Interessenskonflikt, aber den gibt es ja im Klassischen auch. Ein klassischer Projektleiter würde ja auch nicht darüber erfreut sein, dass der Chef reinkommt und ihm da Ressourcen abzieht. Was wir bei Scrum haben, ist so etwas wie die Rolle des Scrum-Masters, eben jemand, der dafür sorgt, dass sowas möglichst selten passiert und mindestens mal klar macht: „Wenn du das jetzt tust, dann ist dir hoffentlich klar, dass wir in diesem Sprint vermutlich nicht erfolgreich liefern werden, weil du uns ja gerade Leute abziehst.“

Ok, nochmal einmal zurück zu den Vorausbedingungen. Was ist denn für it-agile eine große Herausforderung bei der Scrum Einführung?

Was wir mit einigermaßen Erschrecken feststellen ist, dass wir in relativ vielen Unternehmen, wenn wir Agilität einführen, in Wirklichkeit den Leuten erstmal Teamarbeit beibringen müssen. Und ich glaube, auch klassische Vorgehensweisen würden extrem davon profitieren, wenn die Leute besser als Team zusammenarbeiten würden. Das hat mit Agilität ja erstmal nichts zu tun, außer dass auch agile Vorgehensweisen darauf setzen, dass Teams funktionieren.

Auf der anderen Seite, im Klassischen würde man auch extrem davon profitieren, wenn die Leute gute Teamworker wären. Und stattdessen merken wir halt, dass doch viele mit hochgradiger Spezialisierung arbeiten und relativ stumpf ihren Teil betrachten. Und damit können wir im Agilen nicht so viel anfangen, das würden wir verändern. Und ich glaube, die meisten anderen müssen das auch verändern, unabhängig davon, ob sie agil werden.

Ansonsten ist klar, dass ich eine extrem hohe Menge an Projektleitern brauche, die genau diese Spezialisten koordinieren, die nicht miteinander reden. Aber es wäre ja schlauer, die Leute reden einfach miteinander. Kommt wahrscheinlich was Besseres raus, als ständig Stille Post über den Umweg Projektleiter zu spielen.

Kann man pauschal sagen, wenn ich meine Organisation umstelle auf Scrum, dann bin ich besser, bin ich neuer, bin ich weiter, als wenn ich klassisch arbeite, oder liegt das am Umfeld und an anderen Parametern?

Naja, agil vorzugehen oder Scrum zu machen hat ja keinen Wert in sich. Man sollte sich immer die Fragen stellen: „Was ist für mein Umfeld oder die jeweiligen Projektsituation angemessen? Was habe ich für ein Umfeld? Muss ich so schnell reagieren können, wie mir das Scrum bietet?“ Umgekehrt, wenn jetzt eine Firma in 95 Prozent aller Fälle mit Wasserfallprojekten sehr, sehr erfolgreich ist, warum sollten sie das ändern?

Vielleicht um noch erfolgreicher zu werden, schneller zu werden?

Ja, kann sein, aber dann würde man das vermutlich trotzdem nicht zu 100 Prozent und überall umstellen, weil es ja häufig gut genug funktioniert und Unternehmen damit erfolgreich sind. Ich glaube man muss schon genau gucken, was ist eigentlich das Problem, was wir lösen wollen? Weil es sonst so ein Selbstzweck wird, dass wir 100 Prozent Scrum oder 100 Prozent V-Modell machen müssen.

Man sollte das tun, wenn man sich etwas Spezielles davon erhofft, dass es leistet. An der Stelle ist wahrscheinlich am wichtigsten: Was auch immer wir für einen Prozess nutzen, sollten wir reflektieren, ob der eigentlich angemessen ist und unsere Probleme löst? Oder bleiben relevante Probleme übrig, die eben genau dieser Prozess nicht löst?

Muss ich mich immer entscheiden, wir arbeiten agil, bzw. machen Scrum oder wir arbeiten klassisch nach V-Modell, Wasserfall oder kann man das auch situativ entscheiden?

Ich habe prinzipiell nichts dagegen, dass man Modelle mixt und z.B. sagt: „Wir fahren jetzt eigentlich sowas wie V-Modell, aber die Realisierungsphase machen wir agil.“ Ich glaube, man hofft dann irgendwie, die Vorteile von beidem zu haben, ich befürchte aber man erntet mehr die Nachteile von beidem.

Die Gefahr ist einfach hoch beim Mixen, dass man an Stellen, an denen es wehtun würde sich zu ändern (wo es aber vielleicht auch ganz viel bringen würde), es nicht tut. Insofern ist mein Verhältnis zu so hybriden Ansätzen ein bisschen schwierig, und das heißt nicht, dass das nicht funktionieren kann. Es heißt erstmal nur, man muss sich genau überlegen, warum man das tun will? Ist das die Übergangslösung, und ich will eigentlich mal was anderes, aber ich kann im Moment noch nicht? Oder kneife ich hier an irgendeiner Stelle, weil es mir zu schwierig ist, jetzt ein selbstorganisiertes Team hinzustellen.

Die Unternehmen, die ich kenne, die mit Scrum entwickeln, die sind sehr erfolgreich. Ich frage mich, ob die jetzt weniger erfolgreich wären, wenn sie das nicht tun würden? Mir liegen keine Vergleichswerte vor, aber bei diesen Unternehmen läuft das sehr gut.

Ja, genau, das ist auch unsere Erfahrung. Wobei man sagen muss, wir haben natürlich immer eine eingeschränkte Sicht auf den Markt. Wir lernen im Wesentlichen nur die Leute kennen, die bereit sind was Agiles zu machen. Insofern kennen wir gar nicht so viele, die im Vergleich dazu klassisch arbeiten. Das liegt in der Natur der Sache.

Ist es denn so, dass die Kunden zu Dir kommen, vermehrt sagen, wir möchten jetzt lernen mit Ihnen zusammen Scrum einzuführen, weil wir klassisch nicht erfolgreich sind oder nicht erfolgreich genug sind? Ist das sowas wie das Rezept um diese wieder auf die Beine zu bringen oder die besser zu machen?

Ja. Um irgendeine Form von Verbesserung geht es eigentlich immer. Und das kann mal sein: „Wir haben das Gefühl wir sind nicht schnell genug.“ Das kann mal sein: „Wir treffen eigentlich nicht die Bedürfnisse unserer Kunden.“ Es könnte sein: „Die Qualität stimmt nicht, die wir da liefern.“ Das sind alles Gründe, die ich gut nachvollziehbar finde. Und alles Themen, bei denen wir mit agilen Ansätzen helfen können.

Wir kriegen jetzt zunehmend auch mal Kunden, die sagen: „Naja, wir wollen das mal machen, weil das alle machen. Jetzt machen alle Agil oder die Generation Y erwartet, dass wir irgendwie agile Prozesse einsetzen.“ In diesen Fällen ist die Gefahr hoch, dass die Unternehmen es eben nicht ernst meinen. Und dann wird es auch nicht richtig funktionieren. Insofern: Für uns ist die Veränderung in der Regel einfacher, wenn man auch ein passendes Problem hat. Wenn man sagt „Wieso, läuft doch alles gut, wieso sollten wir jetzt da irgendwas ändern?“ ist es verständlich, dass die Bereitschaft für Veränderung nicht so hoch ist.

Das deckt sich mit meinem Empfinden, dass häufig die Fragestellung ist: „Machst du denn schon Scrum oder arbeitest du noch klassisch?“ Ist das nach wie vor so ein Trend?

Ja, eine Tendenz ist da auf jeden Fall zu sehen.

Henning, werfen wir mal einen Blick auf unsere Arbeit in Kundenprojekten. Unser kleinster Kunde ist der 1-User, da waren wir nach wenigen Stunden Dienstleistung live, unser größter Kunde hat 1.100 Lizenzen, das sind ganz andere Projektdimensionen in der Einführung und kontinuierlich gibt es Change Requests und Erweiterungen.

Um die Kundenanforderungen präzise zu verstehen und einen verlässlichen Preis für das Einführungsprojekt nennen zu können, bieten wir unseren Kunden in der Regel zunächst ein Vorprojekt an. Hier erstellen wir mittels Rapid Prototyping einen Prototypen für unsere Kunden und schreiben ein Einführungskonzept in Zusammenarbeit mit dem Kunden. Ist denn Rapid Prototyping was ganz anderes, oder kann ich das nennen wie die kleine Schwester von Scrum?Rapid Prototyping beschreibt ja in Wirklichkeit nur den Teil, wie man mit dem Anforderungsmanagement umgeht. Ich zeige sehr frühe Versionen, die aber nur Prototypen sind, das heißt also im Zweifelsfall kann man diese westernstadtmäßig hinterher zusammenklappen. Nur damit man früh klar hat, so wird es aussehen, das ist es, was sie hinterher kriegen. Aber es ist noch nicht fertig.Und bei Scrum oder anderen agilen Ansätzen geht man erstmal davon aus, dass wir in so kleinen Iterationen vorgehen, aber keine Westernstädte bauen, sondern richtige. Vielleicht bauen wir dann erstmal nur ein Haus und dann das nächste Haus. Aber das Haus, was du dann siehst, ist schon fertig. Gerade für kleinere Projekte, z. B. einem Projektaufwand von nur 10 oder 20 Personentagen, eignet sich Rapid Prototyping. Da ist möglicherweise noch nicht der entscheidende Punkt erreicht, um Scrum einzusetzen.

Mit Rapid Prototyping liefern wir schnelle Resultate, gehen schnell mit dem Kunden in den Dialog und prüfen, ob die Lösung so in die richtige Richtung geht. Wenn der Kunde gut mitmacht und die Zusammenarbeit gut läuft, verlaufen diese Projekte sehr erfolgreich.
Es gibt auch Kunden, die, etwas zugespitzt formuliert, sagen: „Ruf mich an, wenn du fertig bist.“ Das geht zwar auch, aber in Zusammenarbeit werden die Lösungen immer noch eine ganze Spur besser. Da kann man schon eine Menge draus ableiten, oder?

Ja klar, eine enge Zusammenarbeit bringt immer bessere Resultate. Man sitzt in einem Boot, hat ein gemeinsames Interesse und jetzt werden die Feinheiten austariert. Und es ist schön, wenn Kunden das im Griff haben. Aber natürlich gibt es auch Kunden, die sich dabei in Details verlieren, die zu lange an Details polieren und deren Produkt am Ende des Budgets nicht wirklich fertig ist. Die haben dann die tollste Stammdatenverwaltung der Welt, die nützt nur alleine nichts.

Also braucht es ja auf Kundenseite jemanden, der einen Blick für die große Linie hat und eine Idee davon, wo es sich lohnt noch zu feilen und wo ist es jetzt vielleicht auch mal egal ist. Und das ist nicht so einfach. Das Business ist auch nicht so einfach. Deswegen gibt es in Scrum die Rolle Product Owner, also jemanden, der diese Entscheidungen möglichst gut treffen kann.

Und der ist ja im Idealfall der Kunde, aber da ist deine Aussage, wenn er das nicht kann, dann bringen wir so einen mit oder?

Naja, für so eine Welt wie Vertec, wo ihr euch natürlich mit eurem Produkt besser auskennt als irgendjemand anders auf der Welt, kann ich mir nicht vorstellen, wie ein Kunde Product Owner sein kann. Also vermutlich wärt ihr immer selber eher Product Owner, wahrscheinlich werden eure Projektleiter heute ähnliche Aufgaben wahrnehmen, weil sie sich mit dem Produkt besser auskennen als die Kunden und die Kunden sind dann eher Stakeholder, die man berät, welchen Teil sie wo wie im Produkt umsetzen können.

Das ist genau der Fall, der sich meist in der Beratungsleistung unserer Projektleiter widerspiegelt. Vielen Dank für Deine Einschätzung hierzu, ich merke, hier liegen wir mit unserem Vorgehen auf dem richtigen Weg.

Teil 2 des Interviews wird sich mit der Projektplanung und Kalkulation, sowie dem Projektcontrolling befassen. In Teil 3 gehen wir auf die unterschiedlichen Vertragsarten für agile Projekte ein und erfragen, welche Erfahrungen Henning Wolf hier in der Praxis gesammelt hat.