Wie haben agile Methodiken in den letzten Jahren die Softwareentwicklung verändert, und was hat das gebracht? Was sind die grössten Fehler bei der Anwendung und wie geht es weiter? inside-it.ch hat drei Experten mit diesen Fragen konfrontiert: Scott Ambler, Dean Leffingwell und Dan North. Alle drei werden an der GOTO-Zurich-Konferenz für Entwickler auftreten.

Wer als inside-it.ch-Leser bei der Registrierung den Promocode "insideit" erwähnt, erhält Hundert Franken Leserrabatt.

Heute äussert sich Scott Ambler, Initiator der Methodologien Agile Modeling (AM), Agile Data (AD), Disciplined Agile Delivery (DAD) und Enterprise Unified Process (EUP) sowie Autor des Agile-Scaling-Modells (ASM). Die Antworten von Dean Leffingwell und Dan North werden wir in den kommenden Wochen publizieren.

Scott Ambler: Es hat einige Fortschritte gegeben, aber der Diskurs über Agile ist bezüglich der Vorteile immer noch übertrieben optimistisch. Ich mache regelmässig Umfragen in der Industrie, um herauszufinden, was tatsächlich vor sich geht. Eine dieser Umfragen konzentriert sich auf die Erfolgsraten von Projekten. Seit 2006 sehen wir, dass agile Teams tatsächlich höhere Qualität, bessere Kundenzufriedenheit, schnellere Lieferzeiten und ein besseres Return on Investment produzieren - im Durchschnitt. Die aktuellsten Resultate findet man hier.

Zusammengefasst: Ja, es ist eine gute Idee. agile und "schlanke" Strategien anzuwenden. Aber erwarten Sie nicht, dass alle Ihre Teams dadurch doppelt so produktiv oder sogar noch produktiver werden, wie das manche Leute behaupten.

Das grösste Problem ist, dass viele agile Teams Schwierigkeiten bekommen, die agile Methode zu skalieren, also an grössere Projekte anzupassen. Traurigerweise machen einige der Phrasen, die ihnen in den verschiedenen Zwei-Tages-'Expertenkursen' beigebracht werden, die Dinge nur noch schlimmer. Die entscheidende Erkenntnis ist, dass einen dieselben simplen agilen Strategien, die für kleine, am selben Ort arbeitende Teams sehr gut funktionieren, in ernsthafte Schwierigkeiten bringen, sobald man kompliziertere Situationen vorfindet. Man muss diszipliniert genug sein, um den Kontext der Situation, in der man sich befindet, zu erkennen und seine Vorgehensweise daran anzupassen. Das Prozessentscheidungsframework Disciplined Agile Delivery (DAD) kann mit seinem zielorientierten Ansatz durch solche Entscheidungen führen.

Ja. Ich habe mehrere erfolgreiche Projekte gesehen. bei denen Offshoring und ein agiler Ansatz kombiniert wurden. Leider kenne ich auch Projekte, bei denen das nicht so gut läuft. Das führt mich zu meiner Aussage zurück, dass man den Kontext der Situation, in der man sich befindet, verstehen muss. Wenn man einen Teil der Arbeit offshort, muss man seine Strategie daran anpassen.

Eine verteilte Organisationsstruktur ist einer von verschiedenen Skalierungsfaktoren, mit denen ein agiles Team konfrontiert werden kann. Offshoring ist ein extremes Beispiel. Andere Faktoren sind unter anderem die Teamgrösse, die geografische Verteilung, technische Komplexitäten, die Komplexität von Domains sowie Compliance-Anforderungen. Auch darüber habe ich Daten gesammelt. Die gute Nachricht ist, dass man für alle Grössenordnungen dieser Faktoren agile Strategien anwenden kann. Die schlechte Nachricht ist, dass dabei nicht jedermann erfolgreich ist. Um bei grossen Projekten mit agilen Methoden erfolgreich zu sein, muss man disziplinierter an die Sache herangehen als in einfachen Situationen.

Dazu habe ich einige Voraussagen:

Erstens: In zehn Jahren wird Software immer noch von Menschen für Menschen entwickelt werden. Das magische "higher-level of abstraction modeling tool" wird immer noch nicht da sein - nicht einmal annähernd.

Zweitens: Der Gebrauch von externen Software-Sevices - beziehungsweise dem, was aus SaaS und der Cloud bis dann geworden ist - wird eine häufig angewendete Option für IT-Abteilungen sein. Aber ich glaube, es ist unwahrscheinlich, dass dies der alles beherrschende Ansatz sein wird. IT-Organisationen werden immer noch gleichzeitig auch selbst Software entwickeln und weiterentwickeln, Standardpakete installieren und daneben SaaS- beziehungsweise Cloud-Offerings nützen. Der Hauptunterschied wird sein, wie häufig diese veschiedenen Möglichkeiten genützt werden.

Drittens: Viele der Java-, Ruby- und .Net-Programmierer von heute werden den Sprung in die Cobol-Entwicklung machen. Diese Voraussage mache ich aus verschiedenen Gründen. Zum einen hat Cobol immer noch eine riesige Codebasis, die keineswegs in näherer Zukunft einfach verschwindet. Zum anderen kommen die Cobol-Programmierer von heute zunehmend ins Pensionsalter. Zudem werden diese Jobs sehr gut bezahlt sein, weil Unternehmen immer verzweifelter nach Möglichkeiten suchen, ihre Codebasis noch weiterzupflegen. Und wenn Programmierer mal ihre Vorurteile über Bord werfen, werden sie erkennen, dass viele sehr interessante Systeme in Cobol entwickelt worden sind.

Viertens: Agile und Lean werden komplett in die Entwicklungslandschaft integriert sein. In zehn Jahren werden wir nicht einmal mehr viel über diese beiden Themen sprechen, sie werden etwas von dem sein, was wir tun.

Fünftens: Entwicklerteams werden einen "kontextbewussten" Ansatz bei der Produktion verwenden, ich hoffe in der Art, wie ihn die "Disciplined Agile Delivery" beschreibt. Ein kleines Team an einem Ort wird anders arbeiten, als ein grosses Team, das über verschiedene Standorte verteilt ist. Dieses wiederum arbeitet anders als ein mittelgrosses Team, das mit einer unumgänglichen Compliance-Situation umgehen muss. Und dieses wiederum anders als ein Team, das gleichzeitig verschiedene Lösungen integriert, pflegt und weiterentwickelt, die auf verschiedenen Plattformen laufen. Teams in unterschiedlichen Situationen brauchen unterschiedliche Strategien, um erfolgreich zu sein. Genau darüber werde ich in meiner Keynote an der kommenden GOTO-Konferenz in Zürich sprechen. (Fragen und Übersetzung: Hans Jörg Maron)

(Interessenbindung: inside-it.ch ist Medienpartner der GOTO Zürich)