Warum (agile) Projekte kippen

Agilität bietet höhere Produktivität und bessere Ergebnisse für die Projekte - daher wird sie sich durchsetzen! Die Realität sieht leider manchmal ganz anders aus: Erst ist das Projekt agil, produktiv und alle sind begeistert. Wenige Monate später: wichtige Personen haben das Projekt verlassen und von den agilen Techniken ist nur noch wenig übrig . In diesem Vortrag geht es uns um das “Kippen” von Projekten und Gründe sowie Möglichkeiten diskutieren, um mit einer solchen Situation umzugehen.
Links
Folien speakerdeck.co...
Prof. Christiane Floyd zu “menschenzentrierter Software-Entwicklung” software-archi...
Vortrag Wahrheiten über Software Entwicklung: Darüber möchte ich nicht mehr sprechen
müssen! • Wahrheiten über Softwa...
Welchen Sinn hat agiles Coaching? mit Johannes Link software-archi...
Blog: Hilft "kaputte"
Agilität? www.heise.de/b...
Auftragstaktik - Agilität beim Militär? mit Sönke Marahrens software-archi...
Crew Ressource Management - Wie geht die Luftfahrt mit dem Faktor Mensch um? software-archi...
Linda Rising - Fearless Change and the Unconscious Mind software-archi...
Beyond Budgeting bbrt.org/
Das Kippen agiler Software-Projekte software-archi...
Agilität software-archi...
Extreme Programming (XP) - eine Retrospektive software-archi...

[@i-am-the-slime]

Hat mir sehr gut gefallen. Ich habe es persönlich auch oft erlebt, dass man Agilität als Ausrede für das Ausbleiben von Planung heranzieht. Jetzt gucke ich das Video mit dem Fearless Change.

[@EberhardWolff]

Danke für das positive Feedback - freut mich sehr!

[@aFrInaTiOn]

Wait what?! War mir entfallen, dass Linda Rising als Gast bei Eberhard war - habe ihr Buch hier liegen & jetzt weiss ich was ich analog zu Dir tun werde, nämlich das andere Video zu schauen.. 😍

[@EberhardWolff]

@@aFrInaTiOn viel Spaß!

[@ecblack]

Sehr interessanter Vortrag, der das Thema von verschiedenen Seiten beleuchtet und mir viele neue Impulse gegeben hat. Ich habe aber in dem Kontext "Warum setzt sich agil nicht durch, wenn es besser bzw. überlegen ist?" eine Perspektive vermisst - die systemische Sicht, die aber zugegebenermaßen sehr komplex ist und genug Stoff für einen eigenen Vortrag bieten würde. Nur weil etwas (objektiv) besser funktioniert, würde ich nicht davon ausgehen, dass es sich durchsetzt. Bei jeder Form von Veränderung wird es systemische Widerstände auf sämtlichen Ebenen in verschiedensten Ausprägungen geben, die man zunächst verstehen muss um danach mögliche Handlungsoptionen abzuleiten. In der Regel kann man bei jedem konkreten Beispiel sehr genau erklären, warum Agile scheitert bzw. nicht die gewünschten Ergebnisse bringt. Auch sehr spannen fand ich die Themen Agilität und Business Value, sowie "Sustainable Development", hier würde ich bei der Interpretation definitiv widersprechen. Aber das würde jetzt den Rahmen sprengen... ;-) Insgesamt ein sehr guter Vortrag, vielen Dank!

[@EberhardWolff]

Danke für das Feedback! Ich glaube, man kann noch eine Vielzahl weiterer Vorträge in dem Bereich halten - gerade nach den Reaktionen auf diesen Vortrag. Aber mein Thema war hier funktionierende agile Organisationen, die kippen - und die haben Widerstände bereits überwunden…

[@enolive123]

Sehr gute, nüchterne Analyse! Was mir im Bezug auf die Wettbewerbsfähigkeit gefehlt hat, ist die Frage ob ein Unternehmen mit agileren Vorgehensweisen gegenüber einem traditionellen im Arbeitnehmermarkt IT signifikante Vorteile hat. Ich meine, dass dies so ist kann es aber nicht mit Zahlen belegen. Meine aber zu wissen, dass die DORA Reports einen Zusammenhang zwischen Zufriedenheit und gewissen (agilen) Praktiken feststellen. Das wäre dann ein möglicher kausaler Zusammenhang zwischen Happyness/Fun bei der Arbeit und Business Value

[@EberhardWolff]

Danke für das nette Feedback ! Ich bestreite nicht, dass zufriedenere Leute produktiver sein können. Dennoch gibt es beispielsweise Beratungen, die auf jeder Uni-Jobmesse vertreten sind, weil sie neue Mitarbeiter:innen benötigen. Die verbleiben dann höchstens ein paar Jahre in dem Unternehmen. Danach müssen sie entweder aufgestiegen sein oder sich einen neuen Job suchen . Die Arbeitsbedingungen - insbesondere die langen Arbeitszeiten - sorgen außerdem dafür, dass die Leute da gar nicht bleiben wollen. Das ist halt Ausbeutung und funktioniert in der IT genauso gut wie anderswo auch. Also gibt es unterschiedliche Strategien: Ausbeutung und zufriedene Mitarbeiter:innen sind zwei.

[@SM-cs3nt]

Das große Problem ist, dass Agilität nicht immer die richtige Lösung ist. Für manche Projekte braucht es eine sehr ausdetailiert Planung. Budgets müssen 1 Jahr im voraus delegiert werden - Investoren brauchen klare Planung und Umsatzprognosen. All dass ist sehr schwierig wenn man noch nicht konkret beschreibt was man entwickeln möchte.

[@EberhardWolff]

Das ist ein anderes Thema. Die kurze Antwort ist, dass mindestens Iterationen immer sinnvoll sind, selbst wenn sich Anforderungen nicht ändern würden. Weil sie das aber tun, sollte man sich darauf auch ausrichten und dann ist man bei Agilität. kzbin.info/www/bejne/qJObgqGco52repY diskutiert das alles im Detail.

[@christophschmidt123]

Zum Thema agiles Manifest vs business value: Typischerweise hat man in agilen Projekten einen product owner der Aufgaben/Storys nach business value bewertet und priorisiert. Damit das Problem doch schon gelöst?

[@EberhardWolff]

Genau da bin ich mir nicht so sicher. IMHO ist die Priorisierung von Features gegenüber Wartbarkeit ein zentrales Thema: Am Ende hat man ggf. unwartbare Legacy oder ein wartbares System, aber kein Product / Market Fit. Dort den richtigen Kompromiss zu finden ist schwierig. Und die Priorisierung und das Verständnis für das Gehschäft sollte breiter im Team verstreut sein als nur beim PO. Architektur und damit Architekt:innen haben auch massiven Einfluss auf den Geschäftswert.

[@christophschmidt123]

@@EberhardWolff Stimmt. Kenne ich sogar tatsächlich so dass auch die Architektur/Entwickler einen Prozentsatz der "Story Points" für technische Themen verplanen darf.

[@frankjuno_kafvka]

"Working software is the primary measure of progress" - hätte man dies berücksichtigt anstatt technical excellence, wäre man bei der EM (vielleicht) doch reich geworden. Progress meint Fortschritt in der Entwicklung, nicht Unternehmenserfolg. Und "Continuous attention to technical excellence and good design enhances agility." meint doch nicht, dass technical excellence wichtiger sei als andere Werte, oder die Entwicklung bremsen können dürfte (siehe ersten zitieren Satz bzgl. Progress), sondern dass man stets die technische Exzellenz mit im Blick behalten sollte, also anstreben sollte wo es möglich ist.

[@EberhardWolff]

Wenn wir uns einig sind, dass es um Geschäftswert gehen soll, ist IMHO alles gut. Ich kenne genügend Situationen, in denen Techniker:innen auf beispielsweise auf ihre Interpretation von technischer Exzellenz gedrängt haben, auch wenn es aus geschäftlicher Perspektive keinen Sinn ergab. 🤷‍♂️

[@Jhumanghjngg]

Aus meiner Sicht fuehrt deine Analyse am Kern vorbei. Der wirtschaftliche Vorteil durch Anwendung von Agilitaet kommt natuerlich nicht von besonders guten Designs, langfristiger Wartbarkeit oder weniger Dokumentation. Sondern resultiert aus der Etablierung eines effizienten feedback cycles. Fail fast (and cheap) and improve. Das scheinst du gaenzlich auszublenden. Moegliche Gruende fuer das Scheitern solcher Prokekte leiten sich dann auch direkt daraus ab. Z.b., - Feedback und Verbesserungsdruck kann fuer schwaechere MA sehr herausfordernd sein. Strikt einem Plan zu folgen, fuer dessen Scheitern im Zweifelsfall dann jemand anderes verantwortlich ist, kann sehr viel bequemer sein. - Je nach Umfeld kann das Generieren von tatsaechlich hilfreichem Feedback schwer bis unmoeglich sein. - Feedback muss geplant, interpretiert und in weiteres Vorgehen ueberfuehrt werden. Das bekommen auch nicht alle Organisationen fehlerfrei hin.

[@EberhardWolff]

Danke für das Feedback! Mittlerweile glaube ich, man kann da eine ganze Batterie von Talks zu machen. Du hast recht, Feedback ist ein massiver Vorteil. Das erklärt aber nicht, warum funktionierende agile Organisationen rückabgewickelt werden bzw. das können nicht alle umsetzen. Die Konsequenz kann aber IMHO nicht sein, Agilität immer noch als das beste Konzept anzusehen. Bei einer solchen Organisation funktioniert es eben leider nicht. Ich glaube, dass das nicht allen klar ist….

[@Jhumanghjngg]

@@EberhardWolffAn ein bestes Konzept glaube ich auch nicht. Bei uns hatte es sicher 5..7 Jahre gedauert, bis zumindest ein Großteil der Teams Scrum verinnerlicht hatte. Da helfen auch diverse, oft ein wenig weltfremd daherkommende Coaches nicht, eher im Gegenteil. Automatisch besser wird auch nichts, im Gegenteil, viel mehr Leute müssen regelmäßig "das Richtige" tun, wo vorher vielleicht bisweilen ein cleverer und durchsetzungsstarker PM ausreichte. Es gibt sicher 99 Stolperfallen, in welche man früher oder später tappsen wird. Mich wundern Rueckabwicklungen nicht.