Die acht häufigsten Mythen agiler Entwicklungsmethoden (in der Automotive-Branche)
Seite 2: Mythen
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."
Siehe dazu auf heise Developer:
Erfolgskritische Faktoren für das Requirements Engineering in agilen Projekten
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.
