Warum Agile wichtig ist

Kürzlich erhielt ich eine E-Mail, in der ich gefragt wurde, warum wir uns um Agile kümmern sollten, wenn der gesamte Produktentwicklungsprozess, einschließlich Mechanik und Elektronik, in Jahren gemessen wird und komplett auf Wasserfall basiert. Die Frage hat mich überrascht. Ich arbeite nun seit fast zwei Jahrzehnten mit agilen Methoden und für mich ist es selbstverständlich, dass schnelle Feedbackschleifen besser sind als langsame.

Nach genauerem Nachdenken wurde mir jedoch klar, dass die Frage auf einigen Annahmen beruht, die wiederum auf unseren Überzeugungen über unsere Fähigkeit zur Vorhersage beruhen. Die erste Annahme bezieht sich auf unsere Fähigkeit, die Anforderungen an unsere Produkte Monate, Quartale oder Jahre im Voraus optimal vorherzusagen. In vielen Branchen, in denen die Produkte mechanische und elektronische Komponenten enthalten, erfordert die Produktionspipeline lange Vorlaufzeiten. Folglich werden die Produktanforderungen lange vor Beginn der Produktion formuliert. Der Trugschluss ist natürlich, dass sich die Anforderungen ständig ändern, weil neue Technologien verfügbar werden, sich die Kundenpräferenzen ändern, die Konkurrenz aktiv wird und so weiter. Eine Faustregel in der Softwarebranche besagt, dass sich Anforderungen mit 1 Prozent pro Monat ändern – eine sehr konservative Schätzung, wenn Sie mich fragen.

Wie kann man also auf die sich ständig ändernden Anforderungen reagieren? Es gibt im Grunde zwei Ansätze. Entweder Sie machen sich die Agilität zu eigen und reagieren kontinuierlich auf Änderungen oder Sie wehren sich gegen Anforderungsänderungen, lehnen alles ab, was Sie können und akzeptieren zähneknirschend diejenigen, die Sie wirklich nicht ignorieren können. Das Ergebnis des letzteren Ansatzes ist natürlich ein minderwertiges Produkt, da es auf den besten Erkenntnissen von vor Jahren basiert.

Die zweite Annahme ist, dass wir die Auswirkungen unserer Anforderungen vorhersagen können. Diese sind so definiert, dass wir hoffen, ein bestimmtes Ergebnis als Folge der Umsetzung der Anforderung zu erreichen. Wir sehen dies am häufigsten bei den Anforderungen an die Benutzerfreundlichkeit, aber es erstreckt sich im Grunde auf jedes Qualitätsmerkmal des Systems. Online-Unternehmen verwenden A/B-Tests von Lösungen, um die Auswirkungen verschiedener Realisierungen von Funktionen und Merkmalen auf die Benutzer zu ermitteln. Diese Unternehmen tun das nicht, weil sie so schlecht im Requirements Engineering sind, sondern weil die Wirkung von Funktionen und Merkmalen grundsätzlich unbekannt ist, wenn es darum geht, wie Menschen auf Softwarefunktionen reagieren.

Traditionelle Ingenieurbüros sind stolz auf ihre Fähigkeit, die Fähigkeiten von Systemen vorherzusagen, bevor sie sie bauen, denn die Ingenieurskunst bietet eine Reihe von mathematischen Werkzeugen zur Modellierung, Simulation und Vorhersage. Diese Modelle werden dann in der Regel durch Labortests und in einigen Fällen durch kleinere Tests in der Praxis bestätigt, bevor man sich ganz auf ein bestimmtes Design festlegt. Obwohl dies in vielen Fällen recht gut funktioniert, ist es nach wie vor so, dass Messungen in der realen Welt eine viel höhere Aussagekraft haben als mathematische Modelle und Labortests. Wie ich bereits in früheren Beiträgen erwähnt habe, zeigen Untersuchungen von uns und anderen, dass mindestens die Hälfte aller Funktionen in einem typischen System nie oder nur so selten genutzt wird, dass die Investitionen in Forschung und Entwicklung umsonst waren. Daher sollten wir überall dort, wo wir Techniken einsetzen können, um Teile von Funktionen oder Merkmalen einzusetzen und die Auswirkungen zu messen, bevor wir weitere Funktionen entwickeln, dies tun, da dies die Effektivität unserer F&E erheblich verbessern kann.

Obwohl viele verstehen, dass Experimente in der realen Welt in Bezug auf Benutzerfreundlichkeit und Benutzerverhalten eine Notwendigkeit sind, gilt das Gleiche für alle Qualitätsmerkmale. Denken Sie nur an all die Sicherheitskorrekturen, die wir einführen müssen. Oft handelt es sich dabei um Schwachstellen, die bereits vor der Fertigstellung des Systems bekannt waren. Es hat sich einfach herausgestellt, dass die von den Ingenieuren in das System eingebauten Abhilfestrategien nicht ausreichten. Wissen wir auch mit Sicherheit, dass das aktuelle Systemdesign die höchste Leistung, die beste Robustheit und die höchste Energieeffizienz bietet? Nein, natürlich nicht! Statt uns auf Modelle und Labortests zu verlassen, brauchen wir reale Experimente mit unseren Produkten bei Kunden vor Ort, um uns ständig zu verbessern. Die Modelle und Labortests werden immer noch benötigt, aber hauptsächlich, um uns vor den Nachteilen weniger erfolgreicher Experimente vor dem Einsatz zu schützen.

Zusammenfassend lässt sich sagen, dass Sie Agile nicht brauchen, wenn Sie in der Lage sind, den optimalen Anforderungssatz für ein System oder Produkt bereits Jahre vor dem Start der Produktion oder der Bereitstellung perfekt vorherzusagen und wenn Sie in der Lage sind, die Auswirkungen jeder Anforderung auf den Benutzer, den Kunden und die Qualitätsattribute des Systems genau vorherzusagen. In allen anderen Fällen bietet Agile (sowohl vor als auch nach der Bereitstellung – DevOps) die Möglichkeit, die Effektivität Ihrer F&E (gemessen am Wert, der für jede F&E-Einheit geschaffen wird) massiv zu verbessern. Es ist nicht so, dass wir keine Produkte mit traditionellen Wasserfallprozessen entwickeln können – natürlich können wir das, denn wir haben das jahrzehntelang getan. Die Herausforderung besteht darin, dass wir dabei viel weniger effizient sind, was das Risiko von Unterbrechungen für unser Unternehmen erhöht.