News

Projektplanung, Kalkulation und Controlling – agil alles anders als klassisch?

In der Interviewreihe mit it-agile sprechen wir über zentrale Unterschiede zwischen agilen und klassischen Methoden. Im ersten Teil haben wir uns mit den Voraussetzungen für das Arbeiten mit agilen Methoden beschäftigt, in diesem Teil liegt der Fokus auf der Planung, Kalkulation und dem Controlling bei agilen Projekten. Wir möchten hier die konkreten Unterschiede verstehen.

Henning, wenn ich nach agilen Methoden arbeite und der Kunde möchte, dass 2 von 3 Dimensionen „fest“ sind, sprich die Lösung muss zum 01.05.2018 fertig sein und der Funktionsumfang ist definiert, diesen hätte ich gerne vertraglich in einem agilen Festpreis fixiert.

Dann habe ich ja quasi zwei Komponenten, die ich fest gezurrt habe. Habe ich dann überhaupt noch eine Chance mit Scrum das noch vernünftig zu planen und umzusetzen? Die Flexibilität ist dann doch eigentlich weg. Oder nicht?

Zunächst ist es ja noch nicht schlechter als vorher, nach klassischen Methoden. Es ist auch nicht wirklich besser. Es handelt sich also um dieselbe Ausgangslage. Irgendwer schätzt aus seiner Erfahrung, ob er es für die entsprechende Menge Geld für realistisch hält, das Ziel zu erreichen. Theoretisch müsste man noch einen Risikoaufschlag verlangen, je nachdem wie hart der Termin und wie schwierig die Herausforderung ist. Das ist erstmal übliches Business.

Der Unterschied bei einem agilen Festpreis ist der, dass dem Kunden in kleinen Iterationen aufgezeigt wird, worauf seine Wünsche eigentlich hinauslaufen. Der Kunde schlägt also nicht erst am Ende die Hände über dem Kopf zusammen und sagt: „Mist, das wollte ich gar nicht haben.“ Es geht konkret darum, viel früher zu erkennen, wenn eine Lösung in die falsche Richtung geht.

Denn das ist ja oft die Erfahrung, die man mit Festpreisprojekten macht, egal ob klassisch oder agil. Alle Vorüberlegungen werden nicht zu 100 Prozent genauso eintreten. Sondern es wird zu Abweichungen kommen. Die Welt dreht sich weiter, plötzlich verändern sich Prioritäten oder Anforderungen werden plötzlich überflüssig. Das passiert nun mal im Verlaufe eines Projektes. Dann besteht bei einem agilen Festpreis aber die Möglichkeit zu sagen, okay, wenn jetzt eigentlich schon klar ist, dass es so nicht hinkommt, was können wir jetzt noch tun?

Das Product Backlog, in dem wir die Fachlichkeit beschreiben kann nun herangezogen werden, um die Planung voran zu treiben. Alles was bisher gemacht wurde, ist erledigt. Da können wir nichts mehr dran drehen. Aber alles, was noch auf dem Plan steht, was noch dran kommen könnte, da kann nun nach Tauschmasse gesucht werden. Versuche das mal mit einem Pflichtenheft: „Heute machen wir Seite 17 bis 19.“

Bei einem agilen Festpreis jedoch, wenn der Kunde feststellt, dass alles, was wir bisher gemacht haben, nicht reicht, sondern noch mehr benötigt wird, kann er schnell schauen, was weggelassen werden kann, damit der Termin trotzdem eingehalten werden kann. Um mehr geht es nicht, wir können auch nicht mehr schaffen zum selben Termin, wo soll das plötzlich herkommen?

Dann muss man also für die Planung die Tasks in dem Product Backlog alle gleich gross dimensionieren, damit man auch Tasks tauschen kann? Die müssen dann ja auch schlussendlich genauso gut machbar sein, wie die ausgetauschten Tasks.

Man kann die Tasks auch gewichten. Man muss nur für jedes Häppchen das Gewicht kennen. Dann kann man etwas wegnehmen und für denselben Wert etwas anderes wieder reintun. Als wir noch selber Softwareentwicklung gemacht haben, haben wir damit auch gute Erfahrungen gemacht, mit solchen Verfahren zu arbeiten. Schwierig ist es halt immer dann, wenn die Kunden gar keine Tauschmasse mehr haben.

Aber auch dann passiert ja nichts Schlimmeres als es bei einem klassischen Festpreisprojekt auch passiert wäre. Am Ende kriegt der Kunde das, was er bestellt hat, und stellt fest, dass er das nicht so gebrauchen kann, wie er sich das ursprünglich gedacht hat. Ich male mal eine kleine Graphik auf. Bei Softwareentwicklung geht es ja auch immer um die Frage von Transformation. Also rechts das System. Das System wird aufgrund von Anforderungen entwickelt und die Anforderungen basieren auf den Zielen, die man erreichen möchte.

Die Ziele skizziere ich hier bewusst als Wolke. Denn oft sind die Ziele eher wolkig, manche allerdings auch sehr klar. Jetzt ist das Problem, dass wir hier zwei Transformationen vorfinden: Einmal von unserem Ziel auf Anforderungen und dann von den Anforderungen auf das System. Der klassische Festpreis befindet sich nur im schwarzen Kasten. Das heißt, das Risiko, das ich mit einem Festpreis los werde, ist nur das Risiko, dass die Anforderungen ins System umgesetzt werden.

Ob die Anforderungen aber überhaupt auf das erhoffte Ziel einzahlen, dieses Risiko liegt ausserhalb von klassischen Festpreisen. Doch genau das ist vermutlich das deutlich grössere Risiko. Denn das bleibt beim Kunden, wenn er einen Festpreis vereinbart, und das sollte dem Kunden klar sein. Ich meine, wenn ihr was wirklich Cooles machen wollt, dann bietet euren Kunden doch auch noch an, ihnen dieses Risiko abzunehmen.

Doch es ist schwer zu sagen, zu welchem Preis ihr das machen wollt, denn der Part ist vermutlich relativ gross. Dafür müsste man ziemlich viel beim Kunden kennen, um zu wissen, ob man genau mit diesen Anforderungen seine Ziele erreichen kann.

Das ist richtig. Je nach Kundengrösse ist das aber sogar machbar, Anforderungen aus seinen Zielen abzuleiten, wenn sich der Kunde auf diesen Dialog einlassen möchte. Nehmen wir dennoch mal an, wir starten bei den Anforderungen. Kann man denn dann pauschal sagen, dass wenn der Kunde einen Festpreis will, dann ist er per se im Nachteil?

Nein, finde ich nicht. Warum?

Plakativ gesagt: Bei einem Festpreis versuche ich doch als Anbieter, mit möglichst wenig Aufwand zum Ziel zu kommen und in diesem Preis zu bleiben. Wenn der Kunde die beste Lösung nach Time and Material wünscht, dann bekommt er die möglichst beste Lösung.

Natürlich hat er dann das Risiko, dass er auch mehr bezahlt als er eigentlich haben müsste, weil ein bisschen weniger gut hätte ihm auch schon gereicht. Also da ist dann nur da das Risiko dann.

Ich glaube das generell grössere Problem für den Kunden ist es, herauszufinden, was er eigentlich wirklich braucht. Wenn er das gut kann und weiss, welche Anforderungen er konkret hat, dann wäre ein Festpreis super. Das Problem ist vor allem immer „fester Preis, fester Umfang, fester Termin, feste Qualität“. Also wenn alles fix ist. Dann kann ich unterwegs nicht mehr reagieren, und wenn ich unterwegs schlauer werde, dann sind meine Handlungsmöglichkeiten total fixiert.

Insofern ist nicht der Festpreis das Problem, sondern fester Preis, fester Umfang. Also, wenn es ein Festpreis sein muss, brauche ich als Kunde diese Flexibilität beim Umfang. Das heisst nicht, dass es automatisch immer im Time and Material sein muss. Auch bei Time and Material werden die Kunden ja intern ihr Budget haben und eine Überlegung, was sie maximal ausgeben wollen. Man darf also nicht so eine Obsession mit dem festen Preis entwickeln, sondern der entscheidendere Punkt ist: so lange wie möglich die Flexibilität zu behalten!

Wie gehe ich denn mit Schwierigkeiten um, wenn ich jetzt beispielsweise auf technische Probleme stosse? Ich habe einen Festpreis, ich möchte dem Kunden irgendwas entwickeln und jetzt merke ich nach fünf Sprints das geht gar nicht?

Wie würde ich denn damit klassisch umgehen?

Projektabbruch wahrscheinlich.

Ja, im schlimmsten Fall das. Also wir haben tatsächlich mal einen Fall gehabt, wo wir im allerersten Planning vom allerersten Sprint ein Projekt abgebrochen haben. Weil der Kunde was haben wollte, was technisch nicht machbar war. Es ging damals um eine Anwendung für ein iPhone und damals gaben das die Schnittstellen auf dem iPhone nicht her.
Insofern haben wir dann einfach abgebrochen. Und das ist doch super! Das ist doch besser, als hätten wir das im Rahmen einer Festpreisvereinbarung erst nach acht Wochen Arbeit gemerkt, dass das technisch gar nicht geht.

Zur Abschätzung wollte ich noch eine Frage stellen. Wenn ich jetzt klassisch schätze, ich gehe die Features durch und ich sage okay, ich schätze hierfür brauche ich 20 Tage, dafür brauche ich 50 Tage und je grösser das Feature ist, desto ungenauer wird die Schätzung.
Jetzt habe ich in dem Buch von der Fibonaccifolge gelesen. Was bringt mir genau das, wenn ich in solchen Werten denke? Ich kann ja auch ungenau mit Tagen rumhantieren. Ist das nicht nur eine andere Einheit, aber das Gleiche?

Man kann da so draufgucken. Es gibt aber eine ganze Reihe von Gründen, warum so viele agile Teams eben in abstrakten Schätzmassen arbeiten. Also nicht in Personentagen, sondern etwas wie Storypoints. Es ist nicht so, dass man Scrum nur mit abstrakten Schätzmassen machen kann. Wenn man mit Personentagen glücklich ist, kann man auch Personentage schätzen. Aber Personentage sind immer abhängig von Personen.

Wenn man den Performanceunterschied zwischen Entwicklern sieht, dann ist man in Unternehmen bei mindestens einem Faktor drei, wenn nicht mehr. Was bedeuten dann also zehn PT? In Wirklichkeit sind es 3,3 oder 10 oder 30. Es hängt davon ab, wer es geschätzt hat und wer es hinterher macht. Wenn ich in sowas wie Storypoints schätze, nivelliert der Wert sich deshalb, weil ich weiss, was mein Team in Summe schafft: Eine Menge an Storypoints pro Sprint. Und es ist dabei egal, dass in Wirklichkeit einer die Hälfte davon geschafft hat und die anderen fünf die andere Hälfte.

So bekomme ich eine Unabhängigkeit von einzelnen Personen hin. Das ist der eine ganz wichtige Grund, der ja auch immer zu einem gewissen Frust führt. Denn häufig neigt man bei Personentagenschätzungen dazu, die erfahrensten Leute schätzen zu lassen. Das sind aber nicht die, die eine durchschnittliche Schätzung liefern, sondern häufig eine zu positive Schätzung. Der zweite Effekt ist ein psychologischer. Und zwar die Erfahrung der meisten Leute mit Personentageschätzungen ist ja, wir verschätzen uns, aber immer nur in eine Richtung.

Bei einer Schätzung spricht ja überhaupt nichts dagegen, dass wir daneben liegen. Es ist sogar sehr wahrscheinlich, denn es ist nur eine Schätzung. Aber wir sollten halt genauso oft links wie rechts daneben liegen. Dann ist unsere Schätzung gut. Jetzt gibt es aber so einen psychologischen Effekt, wenn ich eine Aufgabe habe und da steht drauf, die dauert vier PT. Und ich bin nach drei PT fertig. Was mache ich dann als Entwickler? Wahrscheinlich denke ich dann, dass ich vermutlich irgendwas übersehen habe und gucke mir das nochmal genauer an. Ich schreibe noch ein bisschen Doku, ich mache das ein bisschen ordentlicher, ich schreibe noch einen automatisierten Test. Also, ich werde wahrscheinlich die vier Tage verbrauchen.

Die Wahrscheinlichkeit ist erstmal hoch, dass das passiert. Ich gewinne sozusagen an der Stelle nicht. Gleichzeitig, selbe Aufgabe, steht vier PT drauf, und ich bin jetzt vielleicht seit sieben Tagen dabei. Erstens: mir geht es nicht gut, weil da stand ja vier. Das setzt einen unter Druck. Manche Entwickler kriegen das noch für sich verargumentiert, dass es an anderen Leuten liegt, warum das so ungenau geschätzt wurde. Aber das hilft ja trotzdem für das Unternehmen erstmal nicht.

Und die Motivation ist jetzt nicht, ganz ordentlich und in Ruhe den Task fertig machen, sondern jetzt heisst es: „so schnell wie möglich fertig machen“. Die Wahrscheinlichkeit ist dann hoch, dass es teuer und auch noch schlecht wird. Das heisst, es fällt mir nachher nochmal auf die Füsse, muss nochmal repariert werden. Noch mehr Aufwand. Es wird sogar noch schlimmer. In diesem Spiel kann man dann nicht mehr gewinnen. Ich verliere immer bei Personentagen. Theoretisch kann man sagen, dass man es so aufgleisen sollte, dass den Leuten gar nicht mehr verraten wird, was die Schätzung war.

Spannender Aspekt. Gehen wir mal zum Projektcontrolling. Ist da nach agilen Methoden irgendetwas erheblich neu oder anders als im klassischen Projektcontrolling?

Die Wahrheit ist ja nicht, dass alle Leute wasserfall- und phasenbasiert arbeiten und das so wahnsinnig gut funktioniert. Sondern die Wahrheit ist, dass sich die meisten Leute zwar an Phasen orientieren, aber am Ende „wursteln“ sie sich irgendwie durch. Jetzt könnte man ganz gutmütig sagen, naja, das ist ja sowas Ähnliches wie agil, ist ja auch super flexibel.

Aber man lebt eben mit einer Planungslüge. Es gibt zwar einen Plan, aber im Grunde genommen wissen alle, der wird sowieso nicht eingehalten. Es geht dann schlussendlich sowieso nicht auf, aber solange es noch gut aussieht, ist alles gut. Dann ist keine Management-Attention da, uns passiert nichts, aber das ist ja nicht das, worauf es wirklich ankommt.

Worauf kommt es denn wirklich an?

Am Ende kommt es darauf an, dass wir Wert schaffen und das ist ja mit der Grund, warum man bei agilen Ansätzen wie Scrum in so kurzen Zyklen unterwegs ist, damit man einfach sehr früh sieht, ob wir da eigentlich Wert schaffen. Kommt da das Richtige raus? Kriegen wir das Produkt wieder zusammengebaut oder sind wir in einem „wir haben keine Ahnung wo wir stehen“-Bereich? Ich behaupte, in klassischen Projekten ist man 80 Prozent der Zeit zu 80 Prozent fertig.

Aber das hilft nicht so richtig. Das heisst, man weiss eigentlich gar nicht so genau, wo man ist. Klassisches Controlling ist ja Plan und Ist-Vergleich. Aber wenn der Plan schlecht war, vergleiche ich gegen irgendwas, was nicht hilft. Was nützt es dann, dass ich den zu 100 Prozent erfüllt habe, aber es kommt hinterher nicht die Software raus, die ich gebrauchen kann?

Ja, das ist absolut nachvollziehbar. Bleiben wir mal beim Controlling. Vertec ist u.a. ein sehr gutes Tool für das kaufmännische Projektcontrolling, die Budgetverwaltung, die ganze kommerzielle Abbildung von Projekten. Und ich kenne JIRA recht gut, das ist für agile Projektarbeit aus meiner Sicht sehr gut geeignet. Was meinst du, was aus kaufmännischer Sicht relevant wäre, wie können wir die kommerzielle Abbildung speziell für agile Projekte unterstützen?

Gibt es ein Interesse in agilen Projekten z.B. den Deckungsbeitrag eines Sprints oder das Gesamtprojekt zu betrachten? Oder werden am Ende dann doch wieder Phasen, je nachdem ob Festpreis oder nach Time and Material im Controlling überprüft, völlig losgelöst davon, wie viele und welche Sprints wir haben? Oder ist das schwer, sowas pauschal zu beantworten, wie ein Controlling im agilen Umfeld aussehen muss bzw. wo die Unterschiede sind zu dem klassischen Controlling?

Die meisten eurer Kunden führen ja Projekte durch und haben deshalb eine Projektsicht. Hier heisst es für das Controlling primär immer „Bin ich im Plan?“ Es geht dann primär um Soll-Ist-Vergleich.

Bei agiler Softwareentwicklung, geht es primär um eine Produktsicht, so heisst zum Beispiel die Rolle auch Product Owner und nicht Project Owner. Die Frage ist weniger „Konnte ich die Software für den richtigen Betrag herstellen?“, sondern „Übersteigt der Wert, den ich mit dieser Software ermögliche, den Wert, den es mich gekostet hat, diese Software zu bauen?“.

Das ist eine völlig andere Fragestellung. Und das ist die Tücke dabei, weil der eigentliche Wert im agilen Controlling sein sollte: „Schaffen wir genug Wert pro Sprint?“. Unterwegs schaffen wir dabei auch Features und bauen Dinge, nähern uns Releases, so wie man das klassisch sonst auch macht. Am Ende steht die interessante Frage, schaffen wir noch Wert, oder sollten wir nicht auch bei manchen Produkten irgendwann einfach mal aufhören weiterzuentwickeln?

Es gibt vielleicht zwar noch Ideen, aber wir schaffen gar keinen relevanten zusätzlichen Wert mehr. Wir haben zwar mehr Features, aber deswegen bekommen wir nicht mehr Kunden. Dann ist die Software zu Ende entwickelt. Das zu erkennen, dass ist sozusagen im Agilen (und im Klassischen) die viel grössere und spannendere Frage. Nichtsdestotrotz gibt es natürlich auch die andere Frage, wenn ich jetzt Projekte auf agile Art und Weise durchführe. Es stellt sich natürlich trotzdem auch die Frage „Wo stehe ich denn eigentlich? Wie weit bin ich? Und passt es zu dem, was ich A an Budget und B an Zeit eingeplant habe?“.

Da bin ich der Meinung, dass wir im Grunde genommen das mit agilen Methoden sogar noch ein Stück besser können. Denn das, was wir gebaut haben, die Backlog-Items oder die Features oder Storys, die liegen komplett fertig in Produktionsqualität vor. Wir sind nicht einfach nur in irgendeiner Phase, bei so und so viel Prozent, sondern haben mit Blick auf das gesamte Backlog eine ziemlich gute Vorstellung, wo wir stehen, selbst wenn du die mal nicht gewichtest.

Wenn man beispielsweise in einem Backlog 250 Einträge hat und 125 davon fertig sind, hat man das Gefühl, dass wahrscheinlich ungefähr die Hälfte der Zeit um sein sollte. Und wenn ungefähr die Hälfte der Zeit auch um ist, würde ich mich wahrscheinlich ganz gut fühlen und meinen, wir sind im Plan. Umgekehrt, wenn nach der Hälfte der Zeit von 250 erst 50 Items abgearbeitet sind, hätte ich auch ein Gefühl von „Wahrscheinlich nicht so gut, irgendwie müssen wir was ändern, so werden wir das nicht schaffen.“.

Das ist der grosse Vorteil, dass eben dann keine Massnahmen ergriffen werden müssen, wie „nachher werden wir noch schneller“ oder „das sparen wir nachher beim Testen“, weil wir ja gleich so hohe Qualität gebaut haben. Die Dinge, die man sich in klassischen Projekten eher in die Tasche lügt, das haben wir mit agilen Methoden alles nicht. Sondern wir haben halt die Features, Backlog-Items, wir haben die einzelnen Schätzungen und natürlich können wir das controllen, sogar relativ einfach.

Auf dem Markt gibt es ja Software für Scrum- Abbildung, da habe ich ein Scrum-Board in der Software. Ich frage mich ob es eigentlich sinnvoll ist an der Stelle oder ist das nicht das Team, was zusammensteht und das gemeinsam an einem Chart plant.
Also wie kann ich mit Software diesen Scrum-Prozess wirklich unterstützen? Mal abgesehen davon, dass ich die Tickets jetzt in einem System habe, wo ich die abarbeite. Ich beziehe mich hier auf die Controllingsicht, ist das wirklich sinnvoll oder geht es da eher um Gimmicks?

Nach meinem Gefühl geht es tatsächlich meistens eher um Gimmicks. Ich will das gar nicht kleinreden, natürlich sollte ein Product Owner ein Gefühl dafür haben, wo das Vorhaben steht. Wie viel Geld geben wir für welchen Nutzen aus? Auf der anderen Seite ist meine pauschale Lieblingsantwort zu Aufwandschätzung: „Es kostet ungefähr die Hälfte vom Nutzen“. Wir haben ja oft so eine Obsession auf der Kostenseite und keinen blassen Schimmer oder schlimmes Gerate auf der Nutzenseite: „Was bringt das denn?“

Die Frage ist ja eine viel interessantere. Denn wenn es sowieso nur fünf Euro am Tag bringt, dann brauche ich das wahrscheinlich generell nicht machen. Das ist dann völlig nutzlos. Wenn es 50 Millionen im Jahr bringt, dann ist es ja egal, ob das Feature jetzt 10.000 oder 40.000 EUR kostet. Insofern ist eigentlich die Frage nach dem Nutzen viel zentraler. Das heißt, eigentlich müsste man Controlling machen auf der Ebene von Value, also wie viel Wert haben wir eigentlich geschaffen?

Man muss aber auf der anderen Seite auch sagen, dass das  extrem schwer ist, logischerweise. Also im Voraus zu beziffern, wie viel Nutzen wir jetzt mit irgendeinem Feature stiften.
Genau da sind wir wieder beim Unterschied Produkt und Projekt. Bei (Festpreis-)Projekten ist der Nutzen zweitrangig. Du bekommst, was du bestellt hast. Da weiss man, der Kunde zahlt mir X; ich sehe, wie viel Zeit haben wir verbrauchen, und ich kenne den Wert. Beim Produkt weiss ich es natürlich erst, wenn es am Ende seines Lebenszyklus angekommen ist, wie oft ich es verkauft habe.

Das ist die Tücke bei Projekten und hat nicht so sehr mit agil oder nicht agil zu tun, sondern mit der Sicht, wenn man im Grunde genommen nur für die Realisierung bezahlt wird. Letzten Endes geht es ja darum, dass ich meine Mannschaft in irgendeiner Weise verkaufe, „monetarisiere“, und darin irgendein Delta haben möchte, zwischen dem, was die mich kosten, um irgendwas zu schaffen, und dem, was ich vom Kunden an Geld dafür bekomme.

Bei einem Anbieter wie Vertec, wird es für das ein oder andere Feature, für den einen oder anderen Kunden auch Entscheidungen geben, wo ihr nicht kostendeckend arbeitet. Weil man sagt, dafür ist das hinterher ein guter Kunde von uns, der hat viele User, das Feature schenken wir ihm, wenn er dafür unterschreibt und kauft, alles gut.

Wir haben jetzt einige Kunden, die agil entwickeln, die werden mit Vertec controllen wollen und jeder möchte das so ein bisschen anders tun. Und da frage ich mich, ist das so oder gibt es nicht sowas wie eine Vorlage im Controlling für Scrum-Teams?
Ich habe das Gefühl, da hat jeder völlig andere Anforderungen. Da frage ich mich, ist Scrum so, dass das auch immer so sein wird und vielleicht deswegen haben wir auch eine Stärke dadurch, dass wir sagen: „Schaut doch mal wie du dein Controlling aufbaust.“ oder kann man da eine Schablone überstülpen und sagen, wenn du Scrum richtig machst, so wird dein Controlling aussehen?

Man könnte auch sagen, wenn du Scrum richtig machst, dann gibt es dazwischen keine Dienstleisterschnittstellen. Also dann machst du das mit deinen Entwicklern für dein Produkt in deinem Haus. Aber das ist ja nicht die Situation. Ihr habt ja in Wirklichkeit häufig Dienstleister, die nach Scrum arbeiten. Da ist ja schon eine Indirektion drin. Dass die dann individuell unterschiedlich arbeiten, finde ich extrem nachvollziehbar.

Das ist Scrum-inhärent, weil Scrum keine vorschreibende Methode ist, die jetzt genau sagt: „Und so und so macht ihr das Controlling“. Scrum versteht sich selbst als ein Produktentwicklungsframework, also einen Rahmen, der vor allem auf Inspect-und-Adapt-Zyklen basiert.

Dass dann jeder zu anderen Lösungen für sich kommt, wie er das genau umsetzen möchte, finde ich total nachvollziehbar, und meine Erwartung wäre sogar, dass die Leute ihren individuellen Weg brauchen. Es kann also kaum ein Scrum-Modul geben, dass für jedes Scrum-Projekt passt. Wahrscheinlich sind wir da noch weit von entfernt, dass sich ein Standard herausbildet. Kann auch sein, dass das nie kommt.

Super, vielen herzlichen Dank für Deine Zeit.

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.