Von Stalking bis zu Hackerangriffen – seit ich mit der Erforschung der bei Agile-Projekten und Transformationsinitiativen begonnen habe, bin ich mit dem Fundamentalismus konfrontiert worden, der unter den ergebensten Anhängern des Agile-Ansatzes vorherrscht. hohen Misserfolgsquote Wenn schutzlose Patienten eines Wunderheilers einer Krankheit erliegen, weil eine Scheinbehandlung nicht anschlägt (und er normalerweise eine beträchtliche Summe Geld „gespendet“ hat), behauptet der „Heiler“ oft, es sei die Schuld des Patienten, weil er nicht inbrünstig genug gebetet habe. Dieses Thema wurde von Derren Brown ausführlich in der TV-Sondersendung und in seiner Netflix-Sondersendung „ behandelt. Ein solcher Trugschluss wird oft als eine Version des „ “-Trugschlusses oder als „ “ beschrieben. „Miracles for Sale“ Miracle“ Kein wahrer Schotte Appell an die Reinheit Fundamentalisten in der Agile-Community verwenden häufig ähnliche Behauptungen, wenn Agile-Projekte scheitern. So schreibt Greg Kihlstrom beispielsweise in seinem Artikel „ “: Failing at Agile? You're Doing It Wrong Sie könnten beispielsweise den enthusiastischsten Scrum Master in Ihrem Team haben, aber wenn es im Produktteam einige Neinsager gibt oder solche, die einfach nicht durchhalten oder nicht verstehen, was getan werden muss, werden Sie vor Herausforderungen stehen. Manchmal ist dies eine Frage der Ausbildung oder des Coachings, und manchmal ist es eine Frage der Teamdynamik und -kultur. Finden Sie heraus, was die Ursache ist, und gehen Sie entsprechend damit um. Für eine solche Annahme gibt es jedoch keine wissenschaftliche Grundlage. In einem im November 2021 veröffentlichten Artikel mit dem Titel “ wurde eine Metaanalyse zahlreicher Übersichten wissenschaftlicher Agile-Studien durchgeführt und festgestellt: „Das Ergebnis der tertiären Studie ist, dass die Beweise für die Agile-Methodik tatsächlich bestenfalls spärlich sind.“ „Best Practice“ ohne Beweise – Agile Software-Methodik als Beispiel Dies ist jedoch bei weitem nicht die einzige kognitive Verzerrung, die von denjenigen übernommen wird, die eine fundamentalistische Haltung gegenüber Agile einnehmen. In diesem Artikel möchte ich mich auf die Strohmannargumente konzentrieren, die häufig zur Rechtfertigung der Agile-Methodik herangezogen werden. Was ist ein agiler Strohmann? In der Agile-Community von LinkedIn sind Beiträge wie die folgenden keine Seltenheit – scheinbar eine Unterhaltung, die einen Agile-Anwender schlagfertig erscheinen lässt und die Methodik gegenüber einem Softwareentwickler verteidigt, der es wagt, sie in Frage zu stellen. Ich persönlich bin der Meinung, dass diese Unterhaltungen im Allgemeinen frei erfunden sind: Der Oxford English Dictionary definiert einen Strohmann wie folgt: In einem Streit, einer Debatte usw.: eine absichtlich schwache oder falsch dargestellte Behauptung, die aufgestellt wird, weil sie leichter zu widerlegen ist als das eigentliche Argument eines Gegners oder weil sie die Aufmerksamkeit davon ablenkt und den oberflächlichen Eindruck erweckt, dass der ursprüngliche Vorwurf widerlegt oder entkräftet wurde. Es gibt jedoch weitaus tiefer verwurzelte Strohmannargumente, die den Kern des Agile-Ansatzes zu treffen scheinen. Ein Artikel auf der Website SecretGeek wirft die Frage auf: „ “. Während der Autor behauptet, dass die anderen dogmatischen Elemente von Agile, von Ritualen bis hin zur Doktrin, tatsächlich vorhanden seien, war er sich in einem Punkt nicht sicher: in der Frage, ob Agile eine „Mythologie“ darstellt. Ist ‚Agile‘ eine Religion? (Oder bloß ein Kult) Ich bin davon überzeugt, dass diese Strohmannargumente im Wesentlichen den Mythos von Agile ausmachen. Der Wasserfall-Mythos Es ist schwierig, Agile zu diskutieren, ohne Waterfall zu diskutieren. Eine vermeintliche Projektmanagementmethode, die im Gegensatz zu Agile steht. Eine Methode, die streng dokumentierte Schritte erfordert und niemals Änderungen vornimmt. Dies wirft jedoch die Frage auf, wo sich die Waterfall-Konferenzen oder Benutzergruppen befinden, auch historisch gesehen? Vielleicht geben uns die Ursprünge der Methodik einige Hinweise. In Jon Pearces an der San Jose State University stellt er fest: „ “ Vorlesungsnotizen Das Wasserfall-Lebenszyklusmodell ist das Strohmann-Argument unter den Lebenszyklusmodellen. Es wurde erstmals 1970 von Wynn Royce als Beispiel für einen fehlerhaften Prozess beschrieben … Der Softwareentwickler Christian Findlay äußerte sich in : einem Beitrag auf X ähnlich und erklärte „Der Wasserfallansatz ist ein Strohmann, den es nie wirklich gab.“ Allerdings wird die Situation undurchsichtiger, wenn wir tiefer in die Geschichte von Agile eintauchen. Der Toyota-Mythos Das Toyota Production System (TPS) ist die geistige Geburtsstätte der Agile-Methodik. Obwohl die überwiegende Mehrheit der Transformationsinitiativen scheitert, verweisen viele auf die von Toyota verwendete Methodik. Toyota selbst hat jedoch eine weniger als ideale Geschichte, wenn es um Softwareentwicklung geht. In einem es: „Ohne die Haftung einzugestehen, hat Toyota seit 2014 537 Klagen beigelegt, in denen plötzliche Beschleunigungen für Unfälle verantwortlich gemacht wurden, bei denen Menschen getötet oder schwer verletzt wurden, wie aus einem Gerichtsdokument hervorgeht, das Toyota im September 2019 eingereicht hat.“ Bericht in Capitol Weekly heißt Diese unbeabsichtigten Beschleunigungsfehler führten in zahlreichen Fällen nicht nur zu tödlichen Unfällen. Im Fall von Koua Fong Lee führte der Fehler nicht nur zu einem Autounfall, bei dem drei Menschen starben und weitere verletzt wurden, als er seine schwangere Frau und die Kinder von der Kirche nach Hause fuhr, sondern auch dazu, dass ihm die Schuld gegeben und er zu einer Gefängnisstrafe verurteilt wurde. Im Gerichtsverfahren hatte Toyota versucht, einer Theorie, warum sich das Fahrzeug so unberechenbar verhielt, mit der Behauptung entgegenzutreten, dass es strenge Testprotokolle gebe. Kurz vor dem Prozess reichte Toyota jedoch eine Erklärung des Ingenieurs ein, wonach . das Unternehmen tatsächlich keine derartigen Tests durchgeführt habe Nachdem , der ihn zwar freigelassen hätte, ihn aber als Kriminellen gebrandmarkt hätte, wurde Lee schließlich freigelassen, nachdem eine Neuverhandlung angeordnet worden war und die Staatsanwaltschaft es ablehnte, den Fall erneut vor Gericht zu bringen. er sich geweigert hatte, einen Deal einzugehen Der Fall Bookout V. Toyota rückte Toyotas Softwareentwicklungspraktiken in den Fokus, nachdem ein weiterer unbeabsichtigter Beschleunigungsfehler zu Todesfällen geführt hatte. Während dieses Verfahrens, bei dem letztlich festgestellt wurde, dass die Softwaresysteme unbeabsichtigte Beschleunigung verursachen könnten, wurden Beweise vorgelegt, darunter eine interne Kommunikation innerhalb von Toyota, in der es hieß: „In Wahrheit ist Technologie wie Failsafe nicht Teil der DNA der Toyota Engineering-Abteilung“: Im Anschluss an diesen Fall Toyota für hochzuverlässige Projekte einen traditionellen Ansatz bei der Softwareentwicklung übernommen haben und dabei die Programmiersprache SPARK Ada verwenden, bei der strenge Designverträge dabei helfen, die Korrektheit der Software mathematisch zu verifizieren – ein Ansatz, der in hochzuverlässigen Umgebungen wie der Luftfahrt und Verteidigung übernommen wurde. soll Dieser Ansatz, bekannt als „Design-by-Contract“, wurde ursprünglich vom französischen Softwareentwickler Bertrand Meyer erfunden, der selbst das Buch „ “ geschrieben hat. Zu Meyers Kritikpunkten an Agile gehören die Abwertung des Vorabdesigns und der Fokus auf User Stories statt verallgemeinerbarer Spezifikationen. Agile!: The Good, the Hype and the Ugly Diese Kritikpunkte werden im Video „ “ von Edensoft Labs ausführlicher beschrieben: The Ugly of Agile (mit Dr. Bertrand Meyer) https://youtube.com/watch?v=Xi4WG-FVT6Q Abschluss Die verschiedenen Strohmannargumente in Agile machen uns bewusst, wie wichtig es ist, dass wir alle kritisch sind, bevor wir Lösungen annehmen, deren Wirksamkeit noch nicht bewiesen ist. Verstehen Sie mich nicht falsch, wir brauchen keine Metaanalysen systematischer Übersichten randomisierter kontrollierter Studien, um jedes Urteil im Leben fällen zu können, aber wir sollten vorsichtig sein, wenn wir Beweise mit einer höheren Beweislage als solche mit einer niedrigeren Beweislage abwerten (wie jene, die uns von Autoritätspersonen als dogmatische Wahrheit präsentiert werden). Geschichten über Veränderungen gehen uns Menschen trotz aller Widrigkeiten zu Herzen und wir alle wollen glauben, dass es Superhelden gibt, die uns heilen können. Blinder Zynismus kann jedoch auch dazu führen, dass wir uns von den Fortschritten abschotten, die die Gesellschaft voranbringen. Wenn wir versuchen, diese emotionalen Aspekte zu ignorieren, anstatt sie anzuerkennen, sind wir ihnen stärker ausgeliefert, wenn wir versuchen, rationale Entscheidungen zu treffen. Eines der Dinge, die ich seit dem Schreiben des Buches „ “ am bemerkenswertesten fand, ist die Art und Weise, wie die Dogmatiker auf beiden Seiten der Agile-Meinungskluft die emotionalen und psychologischen Aspekte ignorieren, die tatsächlich den Großteil des Buches ausmachen und - wie mir die Fakten zeigen - den Kern wirklich erfolgreicher Transformationsinitiativen bilden. Impact Engineering: Transforming Beyond Agile Project Management Dies ist eine eindringliche Erinnerung daran, dass wir, bevor wir uns zu tief in das Kaninchenloch begeben, uns daran erinnern müssen, dass die Lehren aus Wissenschaft und Technik darin bestehen, dass das Hinterfragen von Orthodoxie und das Sammeln von Beweisen den Kern wirklich bemerkenswerter Entdeckungen bilden.
