Agile vs. klassische Projektmethoden Teil 2

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.

Tobias: 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?

Henning: 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?

Tobias: 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.

Henning: 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.

Tobias: 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?

Henning: Nein, finde ich nicht. Warum?

Tobias: 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.

Henning: 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!

Tobias: 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?

Henning: Wie würde ich denn damit klassisch umgehen?

Tobias: Projektabbruch wahrscheinlich.

Henning: 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.

Tobias: 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?

Henning: 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.

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

Henning: 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.

Tobias: Worauf kommt es denn wirklich an?

Henning: 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?

Tobias: 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?

Henning: 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.

Tobias: 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?

Henning: 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.

Tobias: 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?

Henning: 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.

Tobias: Super, vielen herzlichen Dank für Deine Zeit.

Henning: Gerne.

Nach diesem vertiefenden Einblick in die Themen Planung, Kalkulation und Controlling, wollen wir im dritten und letzten Teil der Interviewreihe mit Henning Wolf von it-agile auf die unterschiedlichen Vertragsarten für agile Projekte eingehen.