sehr interessante 'Diskussion'. Noch eine Anmerkung zur letzten langen Frage (Altsystem neu machen, alles fein, Arbeit macht Spaß, irgendwann ist es weitgehend fertig, die Externen gehen, dann kommt Unterforderung auf) - Ja - richtig - das ist nunmal so. _Entwickeln_, im Sinne von etwas Neues _erschaffen_ , ist etwas anderes als Wartungsmodus, wenn etwas weitgehend fertig ist und nur noch ein paar Fehler, kleine Nachforderungen oder Performance-Probleme erledigt werden müssen. Andere Arbeit - anderer Spaßfaktor. Und anderer Aufwand - man braucht dann nicht mehr 10 agil motivierte creative Entwickler - sondern vielleicht nur noch 2 oder 3 kriminalistisch veranlagte, sehr sorgfältig arbeitende Leute, die die letzten Probleme aufspüren und beseitigen - ohne dabei was kaputt zu machen. Ganz andere Aufgabe - ganz anderes Mindset!
Ich finde das auch nachvollziehbar. Man muss allerdings sagen, dass Ideen wie "nachhaltige Geschwindigkeit" eher den Eindruck hinterlassen, dass man bei agilen Ansätzen eben dauerhaft eine hohe Last hat. Ich finde da Beispiel deswegen auch gut, um zu zeigen, dass manchmal Agilität für langfristig eher keinen Sinn macht.
Ich würde argumentieren dass du für kein Projekt 10 creative Entwickler brauchst. Auch einen „Wartungsmodus“ wird es so eigentlich im Agilen setup nie geben. Die Idee ist, dass du ein Team von 3 bis 4 Leuten hast, die extrem gut sind in dem was Sie tun - diese sollten dann die kleinst möglichen Inkremente der Gesamtvision, step by step umsetzen. Die Visions, bzw. das Produkt ist dabei nie wirklich fertig. Es gibt immer neue Änderungen die man implementieren kann um Marge zu erhöhen und Profit zu steigern.
@@SM-cs3nt Das sagt das klassische Verständnis von Agilität, richtig. Das letzte Beispiel aus dem Reaktion-Stream zeigt IMHO eine Entwicklungsphase und eine Wartungsphase bei mindestens zwei Projekten. Da sind dann andere Vorgehensweisen sinnvoll.
@@EberhardWolff Das größte Problem der klassischen Agilität mMn. sind die Kostenaufwände für die Entwickler die keinen direkt ersichtlichen Gegennutzen haben. Bei einem Team von 4 Mann, sprechen wir von jährlichen Personalkosten von 500.000€ (sehr günstig gerechnet) Dagegen muss erst einmal ein Profit stehen - der sich über die Jahre auch hält. Verstehe da schon warum viele Firmen lieber den Fixed Scope abstecken möchten (und ein Budget und Business Case dahinter legen) Für 300.000€ kann ich an eine Agentur gehen, einen Werksvertrag schließen und habe am Ende die Software die ‚nur noch‘ gewartet werden muss. Die software erfüllt den im Business case geplanten Nutzen und der Umsatz kann erzielt werden. (Wenn er sich rechnet, plane ich die nächste Iteration und wenn nicht dann halte ich das Projekt im Wartungsmodus oder schließe ab. Im Gegensatz dazu steht die Agilität bei der ich keine genau Prognose habe dafür welche Features ich umgesetzt haben werde zu welchem Zeitpunkt. Die 500.000 fallen sofort an - und wiederholen sich im nächsten Jahr wieder. Was nun wenn ich nach einem Jahr die gewünschten Features nicht umgesetzt habe und somit nicht Wettbewerbsfähig bin? Im worst-case habe ich also 500.000 in den Sand gesetzt + 4 Entwickler die ich entlassen muss + lein Produkt. Im nicht agilen case habe ich 300.000 für ein Produkt gezahlt dass nicht mevr markttauglich ist weil sich die Marktgegebenheiten so stark geändert haben (was auch sehr unwahrscheinlich ist - in der Realität ändert sich der Markt nicht so schnell.). Durch den Werksvertrag habe ich also eine Risikominimierung weil das Risiko auf die Agentur ausgelagert wird.
@@EberhardWolff wird es denn nochmal einen Beitrag zu soziotechnischen Systemen geben? Mich würde mal die Auftragsdefinition dort interessieren im Vergleich zur Auftragstaktik. Reaktionen kriegst du ja genug ich glaube nur du hast mittlerweile gar keine kapazitäten 💗
@@marcm3623 Aufträge kein zwingender Teil eines soziotechnischen Systems. IMHO ist es aber grundsätzlich so, dass klare Delegation hilfreich sein kann. Ein formaler Prozess dafür wäre sicher nicht schlecht.
Ich wollte nicht implizieren, dass du den gleichen Kritikpunkt hattest, sondern dass die Einführung von Agilität nicht automatisch zu besserer Software führt und sich das in meiner Erfahrung eben durch diese Planungsfaulheit geäußert hat.
Vielleicht noch eine Anmerkung: Ich sehe bei solchen Folgen das Problem , dass ich auf schriftliche Dinge antworte und die kann ich falsch verstehen oder darstellen. Ich hoffe, das war OK für Dich so.
