Vertec im Gespräch mit it-agile: Agile vs. klassische Projektmethoden Teil 1

Tobias Wielki | 03.01.2018 0 Kommentare

Henning Wolf, Geschäftsführer it-agile GmbH und Tobias Wielki, Geschäftsführer Vertec GmbH

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 Prototying 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, wenn man sich auf agile Sachen einlässt, auch etwas damit leben, dass das nicht auf Anhieb ein Erfolg wird. Sondern, dass das meistens bedeutet erstmal was Neues zu lernen und wenn man was Neues lernt, geht meistens die Leistung erstmal ein ganz bisschen runter. Vielleicht manchmal nicht nur ein bisschen, vielleicht manchmal sogar viel, weil man das noch nicht weiß, wie das Neue funktioniert.

Also diese Art von Veränderung passiert immer und nicht nur, wenn man auf was Agiles wie Scrum umsteigt, sondern auch, wenn man andere Sachen ändert. Also wenn man auf ITIL umsteigt, passiert genau dasselbe. Das es erstmal schlechter wird, weil unklarer. Und da muss man sozusagen einfach durch, muss man sich drauf einlassen. Und natürlich gibt es Dinge, die die Einführung von Scrum begünstigen. Oft haben Unternehmen die Leute in zu vielen Projekten eingeplant.

Also ein Entwickler ist bei 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 in diesem Scrum-Team sitzen für zwei Minuten, sondern die nah an Fulltime-Mitgliedern des Scrum-Teams sind. Also 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 vor, 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 ziehst uns ja gerade Leute ab.

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. Also und ich glaube auch klassische Vorgehensweisen würden extrem davon profitieren, wenn die Leute besser als Team arbeiten würden. Das ist sozusagen erstmal was, das hat mit Agilität ja erstmal nichts zu tun. Ja, das sind Verfahren, die 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 irgendwie eine extrem hohe Menge an Projektleitern brauche, die genau diese Spezialisten, die nicht miteinander reden, irgendwie koordinieren, 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. Also das ist ja immer eine Frage von „Was ist für mein Umfeld angemessen?“ oder von den jeweiligen Projektsituationen. "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 häufig funktioniert es ja gut genug und Unternehmen sind damit erfolgreich. Ich glaube man muss schon genau gucken, was ist eigentlich das Problem, was wir damit lösen wollen? Weil es sonst genau dieses Selbstzweckding bekommt, dass wir 100 Prozent Scrum oder 100 Prozent V-Modelle machen muss.

Man sollte das tun, weil ich mir irgendwas davon erhoffe, dass es das für mich leistet. An der Stelle ist wahrscheinlich am wichtigsten, was auch immer wir für ein Prozess haben, zu reflektieren, ist der eigentlich angemessen und löst der unsere Probleme? Oder bleiben Probleme übrig, die eben genau dieser Prozess nicht löst?

it-agile Wandmalerei

So oder so ähnlich sieht Agilität aus

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-Modelle, aber die Realisierungsphase machen wir agil." oder ähnlich. Ich glaube man hofft dann irgendwie, die Vorteile von beidem zu haben, ich befürchte aber man hat mehr die Nachteile von beidem.

Die Gefahr ist einfach hoch beim Mixen, dass man an allen Stellen, an denen es wehtun würde sich zu ändern, wo es aber vielleicht auch ganz viel bringen würde, es dann nicht tut, weil man sagt: "Och, wir mixen das halt.". Insofern ist mein Verhältnis zu so hybriden Ansätzen ein bisschen schwierig und das heißt nicht, dass das nicht funktionieren kann.

Sondern es heißt erstmal nur, man muss sich genau überlegen, warum tue ich das? Ist das sozusagen die Übergangslösung und ich will eigentlich mal was anderes, aber ich kann im Moment noch nicht anders? Oder kneife ich hier an irgendeiner Stelle, weil es mir irgendwie 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 und das ist auch unsere Erfahrung. Wobei man sagen muss, wir haben natürlich immer eine eingeschränkte Sicht auf den Markt, also 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?

Also um irgendeine Form von Verbesserung geht es eigentlich immer, ja. Und das kann mal sein: „Wir haben das Gefühl wir sind nicht schnell genug.“, das kann man sein „Wir treffen eigentlich nicht die Bedürfnisse unserer Kunden.“, es könnte sein „Die Qualität stimmt nicht, die wir da liefern.“ und das sind alles noch finde ich Gründe, die finde ich gut nachvollziehbar und da kann man auch zeigen, dass das sogar dann besser wird.

Wir kriegen jetzt zunehmend ja auch mal Kunden, die sagen: „Naja, wir wollen das mal machen, weil das alle machen.“. Jetzt machen ja alle Agil oder die Generation Y erwartet, dass wir irgendwie so agile Prozesse machen und da ist eben die Gefahr hoch, dass man das eben nicht ernst meint. 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 erstmal nicht die Bereitschaft da ist, Neues auszuprobieren, oder diese zumindest 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. Nämlich ich zeige sehr frühe Versionen, die aber nur Prototypen sind, das heißt also im Zweifelsfall kann man diese westernstadtmäßig hinterher zusammenklappen. Also nur damit man früh klar hat, so wird es aussehen, dass ist das was sie hinterher kriegen. Aber es ist noch nicht fertig.

Und bei Scrum oder anderen agilen Ansätzen geht man ja erstmal eher davon aus, dass man sagt, ja, wir gehen auch in so kleinen Iterationen vor, aber wir bauen keine Westernstädte, sondern richtige. Also das heißt wir bauen dann erstmal vielleicht ein Haus und dann das nächste Haus. Aber das Haus, was du dann siehst ist schon fertig. Gerade bei kleineren Projekten, z. B. ein Projektaufwand von nur 10 oder 20 Personentagen oder so, eignet sich Rapid Prototyping. Da ist jetzt auch noch nicht der entscheidende Punkt, dass dann da mit Scrum zu bearbeiten.

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 sozusagen 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, also die auch zu lange an Details polieren und eigentlich am Ende des Budgets nicht wirklich ihr Produkt fertig ist. Die haben dann die tollste Stammdatenverwaltung der Welt, die nützt nur alleine nichts.

Also insofern braucht es ja auch auf Kundenseite jemanden, der so ein Blick für die großen Linien hat und eine Idee davon, wo lohnt es sich jetzt noch zu feilen und wo ist es jetzt vielleicht auch mal egal. Es ist nicht perfekt für uns, aber gut genug. Und das ist ja nicht so einfach. Also das Business ist auch nicht so einfach. Deswegen gibt es in Scrum ja auch die Rolle Product Owner, also jemanden, der möglichst gut entscheiden kann, wo ist es jetzt gut genug und wo müssen wir nochmal polieren, weil es vielleicht genau für uns den entscheidenden Unterschied macht.

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. Der nächste Teil folgt in Kürze.

Was sagen Sie zu diesem Thema?
Diskutieren Sie mit!