Schluss mit agilen Mythen!

Agilität ist in aller Munde. Fast jedes Unternehmen hat bereits erste Erfahrungen mit agilen Projekten gesammelt.
Leider kursieren immer noch zu viele “agile Mythen” im Projektumfeld mit denen Enttäuschungen, Schwierigkeiten und unbefriedigende Projekte vorprogrammiert sind.

Blue Chameleon hilft damit aufzuräumen:

Mythos #1: Durch agile Methoden werden Teams schneller:

Schneller zu sein oder die Zeit zur Marktreife zu reduzieren, ist einer der häufigsten Gründe, warum Unternehmen agile Entwicklungsmethoden wie Scrum einsetzen möchten. Damit liegt dem Prozess allerdings von Beginn an ein Missverständnis zugrunde. Denn “Agile” bedeutet nicht, schneller zu liefern, sondern öfter. Geschwindigkeit im Sinne der agilen Entwicklung heißt: die richtigen Prioritäten zu setzen, kontinuierlich wertvolles Feedback zu sammeln und an der richtigen Stelle gewisse Dinge bewusst nicht umzusetzen.

Mythos #2: Agile ist ein Regelset, das nur angewendet werden muss:

Um in einer Organisation erfolgreich agile Prinzipien umzusetzen, reicht es nicht, Praktiken wie tägliche Stand-up- Meetings anzuwenden oder agile Features wie Task Boards zu nutzen. Man muss viel mehr das agile Mindset im Unternehmen etablieren. Das bedeutet, dass das gesamte Team die zwölf Prinzipien des agilen Manifests verinnerlichen muss. Letztlich ist Agilität Einstellungssache: Alles Neue unter “lesson learned” verbuchen, die eigenen Aktionen laufend an das gesammelte Feedback anpassen und sich kontinuierlich verbessern.

Mythos #3: Agile steht für Scrum:

Oft verwechseln Menschen Scrum mit Agile – oder noch schlimmer, sie setzen einzelne agile Praktiken wie tägliche Stand-ups mit agiler Entwicklung gleich. Doch Agile ist ein Oberbegriff für eine Vielzahl verschiedener Ansätze: Scrum, Kanban, Extreme Programming (XP), um nur einige zu nennen. Wer sich nur mit Scrum auskennt, sollte sich auch mit Kanban und XP vertraut machen. Schnell wird man entdecken, dass es eine ganze Fülle von Möglichkeiten gibt, um den Teamprozess zu verbessern.

Mythos #4: Agile bedeutet “keine Dokumentation”:

Die Vorstellung, dass mit agilen Projektmethoden keine Dokumentation mehr erforderlich sei, ist ein verbreiteter Irrtum. Er beruht wohl auf einer Fehlinterpretation des agilen Manifests, das besagt: “Eine funktionierende Software ist wichtiger als eine umfassende Dokumentation“. Das bedeutet jedoch nicht, auf Dokumentation gänzlich zu verzichten. Insbesondere in Scrum wird die Dokumentation genau so wie jede andere Aufgabe behandelt. Bei Bedarf wird sogar ihr Umfang abgeschätzt und priorisiert, so wie jede andere User Story auch.

Mythos #5: Agile bedeutet nur, Code zusammenzuhacken:

Oft wird Agile mit technischem Laissez-faire oder anarchischer Kreativität gleichgesetzt. Dabei verlangen die damit einhergehenden Prinzipien in Wirklichkeit das genaue Gegenteil: Agile ist ein sehr diszipliniertes Vorgehen, um kontinuierlich Software zu liefern. Das neunte Prinzip des Agile Manifesto besagt, dass ständiges Streben nach technischer Exzellenz und gutem Design die Agilität erhöhe. Wer wirklich agil sein will, muss unablässig testen, Feedback sammeln, regelmäßig Produktverbesserungen versenden und vor allem ständig den Plan ändern.

Mythos #6: Agile ist nur für die Softwareentwicklung:

Obwohl der Fokus des agilen Manifests auf der Softwareentwicklung liegt, lässt sich Agilität in einer Vielzahl von Business-Kontexten anwenden, die starker Volatilität und Variabilität unterliegen. Wer die Anfänge der agilen Softwareentwicklung betrachtet, entdeckt unweigerlich Referenzen aus Lean Manufacturing und organisatorischem Lernen. Diese Ideen entstanden zunächst einmal außerhalb der Softwareentwicklung. Agile kann deswegen durchaus auch auf Nicht-Softwareprojekte angewendet werden, wie mechanische und Hardwareprojekte. Selbst in den Bereichen Human Resources oder Einkauf lassen sich agile Praktiken anwenden.

Mythos #7: Agile ist der Königsweg schlechthin:

In der Automobilentwicklung ist Agile gerade in aller Munde. Es ist jedoch nur ein Ansatz, Produkte zu entwickeln, und es gibt viele andere, gleichwertige Ansätze. Es gibt keinen Grund, einen bestimmten Ansatz dogmatisch zu verfolgen. Waterfall etwa ist geeignet, wenn man in einem vorhersehbaren, nichtvolatilen Umfeld arbeitet, in dem Kundenanforderungen von Anfang an klar und stabil sind. Nur wenn das nicht der Fall ist, ist ein agiler Ansatz zu bevorzugen.

Mythos #8: Agile ist einfach zu implementieren:

Agile Ansätze sind zwar leicht zu verstehen, dafür jedoch umso schwerer anzuwenden. Oft unterschätzen Team und Management den Aufwand für die Umsetzung. Menschen haben nichts gegen Veränderung, aber etwas dagegen, geändert zu werden. Für Organisationen ist es meist leichter, Dinge zu verkomplizieren, als sie zu vereinfachen. In den meisten Fällen funktionieren agile Implementierungen “nach Buch” deswegen nicht, sondern müssen auf den jeweiligen Fall maßgeschneidert werden.

Fazit: Obwohl agile Methoden und Praktiken bereits einige Jahre eingesetzt werden, bleiben die Mythen und Missverständnisse darum bestehen. Die Folgen sind weitreichender: Normalerweise führen falsche Wahrnehmungen dazu, dass die Betroffenen agile Methoden und Praktiken verurteilen. Dann werden nicht selten bereits begonnene Change-Programme in der Mitte abgebrochen, die beteiligten Personen bleiben unzufrieden zurück und die angestrebten Verbesserungen werden ins Gegenteil verkehrt.


Quelle: https://www.heise.de/developer/artikel/Die-acht-haeufigsten-Mythen-agiler-Entwicklungsmethoden-in-der-Automotive-Branche-3462027.html?seite=all


Bildquelle: https://blogs.itemis.com/hs-fs/hubfs/Blog/Agile/was-ist-dieses-agile.gif?t=1538385647736&width=1448&name=was-ist-dieses-agile.gif

Leave a comment