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

Tobias Wielki | 09.01.2018 0 Kommentare

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 – was läuft hier konkret anders?

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?

Also erstmal ist es ja noch nicht schlechter als vorher, nach klassischen Methoden. Es ist auch nicht wirklich besser. Also erstmal dieselbe Ausgangslage. Sprich, irgendjemand rät aus seiner Erfahrung, ob er es für die entsprechende Menge Geld für realistisch hält, das zu schaffen. Theoretisch müsste man noch irgendwie einen Risikoaufschlag verlangen, je nachdem wie hart der Termin und wie schwierig die Herausforderung ist. Das ist erstmal ja ein Business wie immer.

Der Unterschied, der ja jetzt auftritt, wenn man tatsächlich sowas wie einen agilen Festpreis macht ist der, dass ich trotzdem in kleinen Iterationen dem Kunden schon mal zeige, worauf das was er sich da gewünscht hat eigentlich hinaus läuft. Und der Kunde nicht erst am Ende die Hände über dem Kopf zusammen schlägt und sagt: "Mist, das wollte ich gar nicht haben." Es geht darum, viel früher zu erkennen, wenn eine Lösung in die falsche Richtung geht.

Denn das ist sozusagen ja oft die Erfahrung, die in solchen, egal ob klassisch oder agil, Festpreisen passiert. Alles, was ich mir vorher überlegt habe wird nicht zu hundert Prozent genauso eintreten. Sondern ich werde Abweichungen entdecken. Die Welt dreht sich weiter, plötzlich brauche ich was anderes was viel wichtiger ist oder jetzt wo ich es sehe weiss ich "Ach nee, das war doch Blödsinn, brauche ich nicht." Also sowas passiert halt unterwegs. Dann besteht bei einem agilen Festpreis aber die Möglichkeit zu sagen, okay, wenn du jetzt eigentlich schon weisst, dass es so nicht hinkommt, was können wir jetzt noch tun?

Und, weil wir unser Product Backlog haben, um die Fachlichkeit zu beschreiben und die Planung voran zu treiben, kannst du jetzt natürlich auch sagen okay, alles was wir bisher gemacht haben, das haben wir gemacht, da können wir nichts mehr dran drehen. Aber alles was noch auf dem Plan steht, was noch dran kommen könnte, da können wir jetzt nach Tauschmasse suchen. Versuche das mal mit einem Pflichtenheft. Heute machen wir Seite 17 bis 19.

Im agilen Festpreis jedoch, wenn der Kunde feststellt, dass alles was wir bisher gemacht haben reicht gar nicht, er braucht mehr. Was dafür können wir weglassen, damit wir trotzdem den Termin schaffen. Um mehr geht es ja nicht. Zauberei können wir auch nicht. Also 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 gleichgross dimensionieren, damit man auch Tasks tauschen kann? Die müssen dann ja auch schlussendlich genauso gut machbar sein, wie die ausgetauschten Tasks.

Ich kann die Tasks auch gewichten. Ich muss halt nur für jedes Häppchen das Gewicht kennen. Und für denselben Wert tue ich was anderes wieder rein. 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 sozusagen 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, "Mist, das ist gar nicht das, was ich gebrauchen kann."

Ich male mal eine kleine Graphik auf. Bei Softwareentwicklung geht es ja auch irgendwie immer um die Frage von Transformation. Also ich habe hier das System. Ich baue das System aufgrund von irgendwelchen Anforderungen und wie komme ich auf die Idee Anforderungen zu machen. Naja, ich habe irgendwelche Ziele.

Ziele - Anforderungen - System

Und das ist total gemein, dass ich die Ziele jetzt als Wolke male. Aber oft ist es halt so, dass das so wolkig ist, es ist den Leuten meist nicht klar. Es könnte auch sehr klar sein. Jetzt ist das Problem, wir haben hier zwei Transformationen. Also einmal von unserem Ziel auf irgendwelche Anforderungen formuliert. Und dann von den Anforderungen auf das System. Und der klassische Festpreis befindet sich ja nur hier, im schwarzen Kasten. Das heisst das Risiko, das ich los werde ist nur dass die Anforderung in ein System umgesetzt wird.

Ob aber die Anforderung überhaupt auf das Ziel einzahlt, dieses Risiko ausserhalb von klassischen Festpreisen. Das ist vermutlich das deutlich grössere Risiko. Also das ist das sozusagen was beim Kunden bleibt, wenn er einen Festpreis macht und das muss halt dem Kunden klar sein, dass das bei ihm bleibt. Ich meine, wenn ihr was wirklich Cooles machen wollt, dann bietet euren Kunden doch auch an, dieses Risiko abzunehmen.

Aber ich weiss nicht zu welchem Preis ihr das machen wollt. Weil das 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 ja relativ schwierig, dem Kunden seine Ziele vorzugeben. Denn damit wäre das Projektbudget meist über den Erwartungen des Kunden. Nehmen wir 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.

Ja, ich glaube das generell grössere Problem ist herauszufinden, was ist eigentlich das, was ich als Kunde wirklich brauche. Wenn ich darin gut bin und weiss welche Anforderungen ich wirklich brauche, dann wäre ein Festpreis super. Das Problem ist immer da fester Preis, fester Umfang, fester Termin, feste Qualität. Also wenn alles fix ist. Dann kann ich halt unterwegs nicht mehr reagieren und wenn ich unterwegs schlauer werde, dann sind meine Handlungsmöglichkeiten total fixiert.

Also insofern, ich glaube fester Preis ist nicht das Problem, sondern fester Preis, fester Umfang. Also, eigentlich 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. Ich glaube man darf sozusagen 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 ist. Also es war, es ging um eine Anwendung für ein iPhone und zumindest gab damals die Schnittstellen auf dem iPhone das nicht her.
Insofern haben wir einfach dann das da abgebrochen. Wie cool ist das oder? Also ist doch besser als wir hätten das erst nach einem Festpreis und acht Wochen Arbeit gemerkt, geht gar nicht technisch.

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 so in Personentagen, sondern eben sowas wie Storypoints. Also es ist nicht so, dass man Scrum nur machen kann mit abstrakten Schätzmassen. 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 bedeutet also zehn PT? In Wirklichkeit sind es drei Komma drei oder zehn oder dreissig. 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 sich deshalb, weil ich weiss, mein Team in Summe, schafft so und so viel Storypoints pro Sprint. Und es ist völlig egal, dass in Wirklichkeit einer die Hälfte davon geschafft hat und die anderen fünf die andere Hälfte.

So bekomme ich da 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 ja auch bei Personentagenschätzungen auch noch dazu die erfahrensten Leute schätzen zu lassen. Das sind aber nicht die, die die durchschnittliche Schätzung liefern, sondern eigentlich, die 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, da stand vier PT drauf. Habe ich irgendwas übersehen, ich gucke mir das nochmal genauer an. Ich mache noch ein bisschen Doku, ich mache das ein bisschen irgendwie ordentlicher, ich schreibe noch einen automatisierten Test. Also ich werde wahrscheinlich die vier Tage verbrauchen.

Die Wahrscheinlichkeit ist erstmal hoch, dass das passiert. So, also ich gewinne sozusagen an der Stelle nicht. Und gleichzeitig, selbe Aufgabe steht vier PT drauf, ich bin jetzt vielleicht seit sieben Tagen dabei. Also erstens mir geht es nicht gut, weil da stand ja vier. Das ist nicht schön. So, Entwickler kriegen das meistens irgendwie noch für sich so hingelogen, dass es irgendwie 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 irgendwie ganz ordentlich und in Ruhe den Task fertig machen, sondern jetzt heisst es eigentlich "zu Ende schrubbeln". Also die Wahrscheinlichkeit ist hoch, es ist teuer und wird auch noch schlecht. Das heisst, es fällt mir nachher nochmal auf die Füsse, muss nochmal repariert werden. Noch mehr Aufwand. Also es wird sogar noch schlimmer. Wo kann ich in dem Spiel gewinnen. Nie oder? Also ich verliere immer bei Personentagen. Ich könnte theoretisch sagen, ich müsste es vielleicht so anlegen, dass ich den Leuten gar nicht mehr verrate was ich an Schätzung hatte.

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, die meisten Leute sich zwar an Phasen orientieren, aber am Ende wursteln sie sich irgendwie durch. Jetzt könnte man ganz gutmütig sagen, naja, durchwursteln ist sowas ähnliches wie agil sein, ist ja auch super flexibel.

Aber man lebt eben mit so einer Planungslüge, also wir haben einen Plan, aber im Grunde genommen wissen wir alle, wann haben wir das letzte Mal einen Plan eingehalten? Es haut dann sowieso nicht hin und was soll es, solange es noch gut aussieht ist alles gut. Dann ist keine Management-Attention da, passiert uns 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, schaffen wir da eigentlich schon Wert? Kommt da das Richtige raus? Kriegen wir das Produkt schon wieder zusammengebaut oder sind wir eigentlich in so einem, "wir haben keine Ahnung wo wir stehen"? Ich behaupte in klassischen Projekten ist man 80 Prozent der Zeit zu 80 Prozent fertig.

Aber das hilft halt nicht so richtig. Also 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 sozusagen 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?

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 und aus meiner Sicht ist JIRA hierfür 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 wir machen dann doch am Ende Phasen, was war nach Festpreis, was war nach Time and Material?“. Ist aber 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, wo da die Unterschiede sind zu dem klassischen Controlling.

Die meisten eurer Kunden führen an der Stelle ja Projekte durch und haben deshalb irgendwie eine Projektsicht. Und so eine Projektsicht und eine Controllingsicht auf Projekte heisst immer ein „Bin ich im Plan?“ und dann gebe ich nicht mehr aus, als ich geplant habe etc. Das hat immer was von Soll-Ist-Vergleich.

Es gibt jetzt aber zum Beispiel einen Grund, warum man agiler Softwareentwicklung, also warum heisst zum Beispiel die Rolle Productowner und nicht Projectowner, also weil man sozusagen mehr so eine Produktsicht hat. Die Frage ist weniger „Konnte ich die Software für den richtigen Betrag herstellen?“, sondern „Übersteigt der Wert, den ich mit dieser Software erstelle, den Wert, den es mich gekostet hat, diese Software zu bauen?“.

Also das ist ja eine völlig andere Fragestellung. Und das ist sozusagen ein bisschen die Tücke, weil der eigentliche Wert im agilen Controlling ist ja „Schaffen wir genug Wert pro Sprint?“. Und das wir eben unterwegs auch Features schaffen und Dinge bauen und uns irgendwie Releases nähern, so wie man das klassisch sonst auch macht. Alles schön und gut, aber am Ende ist die interessante Frage, schaffen wir noch Wert? Oder sollten wir nicht auch bei manchen Produkten irgendwann einfach mal aufhören weiterzuentwickeln.

Weil wir haben zwar noch Ideen, aber wir schaffen gar keinen Wert mehr. Also wir haben zwar mehr Features, aber deswegen haben wir nicht mehr Kunden. Da ist die Software manchmal auch zu Ende entwickelt. Das zu erkennen, dass ist sozusagen im Agilen die viel grössere und spannendere Frage. Nichtsdestotrotz gibt es natürlich auch die andere Frage, wenn ich jetzt irgendwie Projekte durchführe, auf agile Art und Weise, dann habe ich natürlich trotzdem auch diese Frage von „Wo stehe ich denn jetzt eigentlich? Wie weit bin ich? Und passt es zu dem, was ich A an Budget und B an Zeit irgendwie eingeplant habe?“.

Und da ist ja mein Gefühl, dass wir im Grunde genommen das Agile sogar eigentlich noch ein Stück besser können, weil das was wir gebaut haben, die Backlog-Items oder die Features oder Storys oder wie auch immer, weil die halt komplett fertig in Produktionsqualität vorliegen. Ich bin nicht einfach nur in irgendeiner Phase, bei irgendwie so und so viel Prozent, sondern ich habe halt eine ziemlich gute Vorstellung davon, wenn ich auf mein gesamtes Backlog gucke, selbst wenn du die mal nicht gewichtest.

Wenn ich einfach sage, ich habe in meinem Backlog 250 Einträge und ich habe jetzt 125 davon fertig, hat wahrscheinlich ein Gefühl von, ja wahrscheinlich ungefähr die Hälfte der Zeit um. Und wenn ungefähr die Hälfte der Zeit um ist, würde ich mich wahrscheinlich ganz gut fühlen. Und hätte ein Gefühl von: „Ok, wir sind im Plan.“. Und umgekehrt, wenn ich irgendwie nach der Hälfte der Zeit von 250 erst 50 Tickets abgearbeitet habe, 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 sozusagen der grosse Vorteil, dass ich eben dann keine Massnahmen ergreifen, wie "nachher werden wir noch schneller" oder "das sparen wir nachher beim Testen", weil wir ja gleich so hohe Qualität gebaut haben. Irgendwie die Dinge, die man sich so in die Tasche lügt in klassischen Projekten, das haben wir halt alles nicht. Sondern wir haben halt die Features, Backlock-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. Da frage ich 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. Und ich will das gar nicht kleinreden, natürlich sollte ein Productowner ein Gefühl dafür haben, wo stehe ich hier? Also wie viel Geld gebe ich eigentlich für welchen Nutzen aus? Auf der anderen Seite ist meine lieblingspauschale Antwort zu Aufwandschätzung: "Es kostet ungefähr die Hälfte vom Nutzen". Also wir haben ja oft so eine Obsession auf der Kostenseite und keinen blassen Schimmer oder noch schlimmeres Gerate auf der Nutzenseite. Was bringt das denn?

So, die Frage ist ja eigentlich eine viel interessantere, wenn man jetzt mal ehrlich ist, weil wenn es sowieso nur fünf Euro am Tag bringt, dann brauche ich das wahrscheinlich generell nicht machen. Das ist dann völlig Wurst. Und wenn es 50 Millionen im Jahr bringt, dann ist das ja auch egal, ob das Feature jetzt 10.000 oder 40.000 kostet. Insofern ist eigentlich die Frage nach: „Wie viel bringt das?“ die viel interessantere. Das heisst 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, das ist auch extrem schwer, logischerweise. Also wie viel Nutzen wir jetzt mit irgendeinem Feature, also im Vorhinein zu beziffern, wie viel Nutzen das bringt.
Genau da sind wir wieder beim Unterschied Produkt und Projekt. Weil wenn ich jetzt sage ich habe ein Projekt, spielt es keine Rolle, du hast danach gefragt, du kriegst es, der Nutzen ist zweitrangig. Es wurde so bestellt. Da weiss ich auch, der Kunde zahlt mir X, ich sehe, wie viel Zeit haben wir verbraten und ich kenne den Value, beim Produkt weiss ich es natürlich erst, wenn es End of Life ist, wie oft habe ich es verkauft.

Das ist ein bisschen die Tücke bei Projekten und hat nicht so sehr mit agil oder nicht agil zu tun, sondern mit einer Sicht, wo ich im Grunde genommen ja nur für die Realisierung bezahlt werde. Und ja, dann verändert sich was, weil dann geht es ja letzten Endes 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 bauen, und dem, was ich halt 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 irgendwie 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. So und das ist so ein bisschen, das ist ja nicht die Situation. Ihr habt ja in Wirklichkeit Dienstleister, die nach Scrum arbeiten. Aber insofern ist da, also da ist ja sozusagen schon eine Indirektion drin. So und das die dann individuell unterschiedlich arbeiten, finde ich extrem nachvollziehbar.

Das ist auch ein bisschen Scrum-inhärent, weil Scrum an der Stelle ja nicht eine vorschreibende Methode ist, die jetzt genau sagt: „Und so und so macht ihr das Controlling.“, sondern erstmal ja im Grossen und Ganzen, versteht sich auch selber eher als Produktentwicklungsframework, also ein Rahmen, der eben vor allem auf diesen Inspect- und Adapt-Zyklen basiert.

Na ja und das dann irgendwie jeder zu anderen Lösungen für sich kommt, wie er das dann genau umsetzen möchte, finde ich total nachvollziehbar und meine Erwartung wäre sogar eher, dass die Leute da auch ihren individuellen Weg brauchen. So und nicht, das es nicht diese eine Lösung geben wird, das ist jetzt irgendwie das Scrum-Modul und genau so und so controllt man solche Projekte. Wahrscheinlich sind wir da noch weit von entfernt, das sich da so ein Standard raus bildet. Kann auch sein, dass das nie kommt.

Super, vielen herzlichen Dank für Deine Zeit.

Gerne.

 

Ergänzung zu Teil 1 und 3.

Was sagen Sie zu diesem Thema?
Diskutieren Sie mit!