Die acht häufigsten Mythen agiler Entwicklungsmethoden (in der Automotive-Branche)

Inhaltsverzeichnis

Im regulierten Umfeld der Automobilelektronik sind agile Entwicklungsmethoden lange ignoriert oder abgelehnt worden. Das ist merkwürdig, da andere Embedded-Branchen wie die Luftfahrt oder der Verteidigungssektor agile Vorgehensweisen seit vielen Jahren erfolgreich einsetzen. Trotz der technologischen Innovationsleistung der Fahrzeugindustrie wirkt hinter den Kulissen der Elektronikentwicklung ein Branchenkonservatismus, der sich bereits bei der Ablehnung von Open-Source-Konzepten abzeichnet.

Das hat mehrere Ursachen: Erstens war in der Luftfahrt mit der Produktkomplexität der Leidensdruck höher. Das führte zur Offenheit gegenüber neuen Vorgehensweisen. Zweitens hatten viele Zulieferer gerade erst ein methodisch-strukturiertes Software Engineering etabliert. Ein integriertes System Engineering für mechatronische Systeme steht vielerorts noch aus. Diese Anstrengung wollen sie nicht durch agile Methoden gefährden. Und drittens ist mit agilen Methoden scheinbar ein Kontrollverlust verbunden. Die mehrstufigen Hersteller-Lieferanten-Beziehungen der Branche setzen beispielsweise Termintreue voraus – klassische Stage-Gate-Planungen vermitteln hier eine Scheinsicherheit und vermeintliche Transparenz. Auch wenn jeder Beteiligte weiß, dass diese minutiöse Planung im Projektalltag nicht lange Bestand haben wird.

Vor fünf Jahren haben Pioniere bei Automobilherstellern und -zulieferern unabhängig voneinander begonnen, in einzelnen Projekten mit agilen Methoden zu experimentieren. Dies ergaben die Branchenstudien "Agile in Automotive. State of Practice 2014/2015". Agile Early Adopters von BMW, Bosch, Continental, Daimler, Gentex, Hella und anderen Unternehmen berichteten von ihren Erfahrungen bei der Einführung von Scrum, Kanban oder XP in ihren Projekten. Durch die zunehmende Komplexität der Vernetzung und Digitalisierung scheint der Leidensdruck inzwischen groß genug zu sein, dass ein Umdenken stattfindet. In den vergangenen zwei Jahren sind immer mehr Unternehmen bereit, agile Methoden und Praktiken auch im großen Maßstab einzusetzen. Die Anwendung agiler Methoden wie Scrum, Kanban oder Continuous Integration geht allerdings mit einer Kulturveränderung einher. Doch zuvor gilt es, einigen verbreiteten Mythen entgegenzutreten.

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."

Mehr Infos

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.

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.

Die einzige Lösung für dieses Problem ist es, falsche Vorstellungen um agile Entwicklungsmethoden immer wieder zu entlarven – selbst wenn es sich manchmal wie eine Sisyphusarbeit anfühlt.

Sergej Weber
ist seit 2014 Process Consultant und Agile Coach bei Kugler Maag Cie. Sein Beratungsschwerpunkt liegt im Automotive-Bereich bei Kanban und Scrum. (ane)