Interview zu Agilität mit Johan Karlsson, Perforce Software „Agile Transformation ist eine nie endende Erkundungsreise“

Kürzere Entwicklungszyklen, eine schnelle Bereitstellung neuer Software-Funktionen, mehr Automatisierung: die Software-Entwicklung kann offenbar gar nicht agil genug sein. Dev-Insider hat sich mit Johan Karlsson von Perforce Software über die Vorteile und Probleme agiler Prozesse ausgetauscht.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Perforce Software UK Ltd.

Dev-Insider: Im Privatleben geht der Trend hin zu bewusster Prokrastination, in der Welt der Entwickler ist das genaue Gegenteil der Fall. Warum haben agile Konzepte gerade jetzt einen so regen Zulauf?

Johan Karlsson: Agile Prozesse zielen nicht darauf ab, unseren Geschäftsalltag noch hektischer zu machen. Vielmehr können agile Prozesse Unternehmen dabei helfen, ihre Innovationsrate zu erhöhen. Software ist in vielen Aspekten sehr abstrakt und eröffnet uns so völlig neue Möglichkeiten, unsere Vorstellungskraft bei der Produktentwicklung zu nutzen – und diese Flexibilität erwarten Kunden heutzutage regelrecht von Unternehmen.

Dies hat natürlich Auswirkungen auf die Produktivität, aber auch auf die generelle Zielsetzung eines Unternehmens, denn große Firmen beobachten zunehmend, wie deutlich kleinere Unternehmen einen viel höheren Mehrwert liefern und ihnen Marktanteile abluchsen. Große Unternehmen jedoch, die glauben, eine agile Transformation würde vorhandene Ressourcen noch stärker auslasten, gehen höchstwahrscheinlich falsch an die Sache heran. Eine erfolgreiche agile Transformation löst das Versprechen ein, „mehr mit weniger“ zu erreichen.

Dev-Insider: Die wenigsten Unternehmen können ihre Prozesse von Grund auf neu aufbauen. Wo liegen denn die größten Stolpersteine bei der Einführung des agilen Projektmanagements?

Karlsson: In Wahrheit ist vielen erfolgreichen Unternehmen oft gar nicht bewusst, dass sie bereits agil sind – in dem Sinn, dass sie gut darin sind, auf veränderte Marktanforderungen zu reagieren. Einige unserer Kunden sind bereits seit hundert Jahren und länger am Markt und haben sich damit in einer der turbulentesten Zeiten unserer Geschichte bewährt – wenn das nicht der beste Beweis für eine agile Mentalität ist!

Eine der Schlüssellektionen, die man hieraus lernen kann, ist, dass man agile Vorgehensweisen nicht in Form einer Revolution einführen sollte (von einem Tag auf den nächsten alles ändern) – sondern die Einführung vielmehr als eine Evolution betrachten sollte, bei der man bestehende Prozesse Schritt für Schritt verbessert und es quasi zu einem natürlichen Prozess wird, jeden Tag ein paar weitere kleine Verbesserungen und Veränderungen vorzunehmen. All diese kleinen Veränderungen summieren sich und bilden so den Innovations- und Produktivitätsschub, nach dem viele große Unternehmen heutzutage so händeringend suchen.

Eine agile Denkweise in träge gewordenen Unternehmen einzuführen, erfordert volle Unterstützung vom Top-Management. Wenn es keine klare Bedrohung von außen gibt (etwa durch Konkurrenz oder Veränderungen im Markt), ist dies oft das größte Hindernis. Die Teammitglieder selbst sind sich der Notwendigkeit, auf agile Methoden umzusteigen, oft bewusst. Doch da es sich bei einem solchen Projekt auch um eine Investition im Rahmen eines Veränderungsmanagements handelt und neue Prozesse und Tools eingeführt werden, ist dies ohne Unterstützung der Führungsebene oft zum Scheitern verurteilt.

Eine weitere, sehr typische Stolperfalle ist, dass große Unternehmen nicht erkennen, dass viele der Lehrbuch-Methoden für agile Prozesse auf ein Team oder eine spezifische Konstellation für Großprojekte zugeschnitten sind. Jedes große Unternehmen muss daher seine eigene „agile Geschmacksrichtung“ finden, die in seinem individuellen Kontext Sinn ergibt und ihm einen Wettbewerbsvorteil verschafft – eine individuelle Anleitung hierfür kann kein geschriebenes Lehrbuch bieten. Eine agile Transformation ist daher sehr oft eine Erkundungsreise, die nie einfach so „zu Ende“ ist.

Dev-Insider: In einer Case Study berichtet der Satellitenbauer „OHB Sweden“ über ein hybrides Development-Konzept, bei der Scrum mit einem traditionellen Wasserfallmodell verknüpft wurde. Was sind die Vorteile solcher Hybridkonzepte?

Karlsson: Einen Satelliten ins Weltall zu schicken, ist ein gutes Beispiel – hier werden keine Fehler toleriert und die erforderliche Qualität muss in jeder einzelnen Komponente des Gesamtprodukts garantiert sein. So gesehen betreibt jedes Unternehmen ein wenig Raketenwissenschaft: In jedem Unternehmen bestehen bestimmte Grundanforderungen bezüglich Qualität oder Leistung, die eine Dienstleistung oder ein Produkt auf jeden Fall erfüllen muss.

Aus Sicht der Projektplanung sind dies Kriterien, die sich bereits im Voraus planen lassen. Und eine sehr gute Möglichkeit, Entscheidungen in solchen „festgelegten“ Dimensionen zu visualisieren und zu treffen, bezeichnen wir als Wasserfall-Modell (wobei manche Vorgehensweisen wie ein GANTT-Plan nicht notwendigerweise als ein Wasserfall-Prozess strukturiert sein müssen).

Darüber hinaus gibt es aber auch flexible Aspekte in jeder Produktentwicklung, bei denen ein Unternehmen agiler handeln kann oder muss. Ein Muss für agiles Vorgehen besteht beispielsweise dann, wenn etwas zum ersten Mal entwickelt wird und es noch kein Pauschalrezept gibt, wie dies genau zu bewerkstelligen ist. Eine Möglichkeit für agiles Vorgehen ergibt sich hingegen beispielsweise dann, wenn Produktteile entwickelt werden sollen, die viel Freiraum für Flexibilität bieten, oder eine besonders hohe Kundenzufriedenheit erreicht werden soll, indem die Erwartungen übertroffen werden.

Johan Karlsson

Dev-Insider: Und wo liegen die potenziellen Fallstricke eines solchen Hybridkonzepts?

Johan Karlsson: Die Schwachstellen solcher Systeme – sowohl bei festen als auch bei variablen oder unbekannten Anforderungen – sind meist die Integrationspunkte. Besonders wenn unterschiedliche Teams in unterschiedlicher Art und Weise arbeiten, wird dies deutlich. Soll die Arbeit eines Teams mit den Ergebnissen eines anderen Teams zusammenpassen, kommt es oft zu hohen Fehlerquoten und komplexen Troubleshooting-Prozessen.

Einer der Hauptvorteile von hybriden Methoden besteht daher darin, dass sie die Integrationsrisiken minimieren und Methoden wie „Continuous Integration“ ermöglichen, indem sie etwa fest definierte Anforderungen bzw. User Stories im Vergleich zu sich verändernden visualisieren.

Ein häufiger Fallstrick besteht darin, dass Unternehmen nicht sauber trennen, welche Aspekte tatsächlich fest vorgegeben sind und bei welchen sie etwas agiler sein können – es besteht die Tendenz, mehr Aspekte festzulegen als tatsächlich notwendig wäre. Der Grund hierfür ist nicht nur Gewohnheit („So haben wir es doch schon immer gemacht“), sondern auch die Tatsache, dass ein strenges Gerüst auch ein falsches Gefühl davon vermittelt, das Projekt zu verstehen. In der Folge ergeben sich jedoch unnötige Deadlines und komplexe Change-Management-Prozesse.

Dev-Insider: Ist es nicht auch immer eine Frage der Unternehmenskultur, ob agile Methoden überhaupt funktionieren?

Karlsson: Doch, das ist in der Tat ein Faktor. Allerdings ist es wichtig, zwischen der mentalen Einstellung und der praktischen Umsetzung zu unterscheiden. Agil zu denken macht es erforderlich, die Umsetzung von Veränderungen wirklich zu internalisieren. Dies hängt natürlich in der Tat von der Unternehmenskultur ab sowie von der subjektiv empfundenen Notwendigkeit, die Art und Weise zu verändern, wie Dinge bislang bewerkstelligt werden.

Es ist daher wahrscheinlich wenig verwunderlich, dass es oft die Führungsebenen sind, in denen sich der höchste Widerstand dagegen beobachten lässt. Denn agil zu werden, bedeutet einen geringeren Bedarf an Managern und stattdessen mehr dezentralisierte und vertrauensbasierte Entscheidungsfindungsmodelle.

Eine Herausforderung besteht darin, dass sich viele Unternehmen zu sehr auf die praktische Umsetzung fokussieren, bevor diese Aspekte der Unternehmenskultur angegangen werden. Dies ist sehr oft der Fall, wenn wir von „gescheiterten Transformationen“ hören. Die Teams waren „agil“, sie haben ihre agilen Techniken wie Sprints (Zeitfenster zur Umsetzung einer agilen Aufgabe), Daily Stand-Ups (tägliche Besprechungen) und so weiter durchgeführt, doch es entstand keine wirkliche Agilität oder eine Veränderung bezüglich der Art und Weise, wie das Team die geforderte Wertschöpfung zum Kunden bringt.

Dev-Insider: Manche Wirtschaftsbereiche eignen sich sicherlich besser als andere, wenn es um Agilität geht. In welchen Unternehmen können Sie agile Methoden uneingeschränkt empfehlen?

Karlsson: Agile Methoden sind eine Vorgehensweise, die sich prinzipiell alle produktgesteuerten Unternehmen genauer ansehen sollten, und zwar unabhängig von der Branche. Überlebenswichtig sind entsprechende Prozesse in besonders wettbewerbsstarken Branchen.

Agile Konzepte können aber auch den Pionieren der jeweiligen Branche sehr zugute kommen, sei es Toyota in den 1950ern oder dem Fintech-Sektor in der heutigen Zeit. In der Regel verfügen alle Akteure der einzelnen Branchen über ein ähnlich hohes Kompetenzniveau in ihrer Belegschaft, daher bestehen Unterscheidungsmöglichkeiten vor allem darin, wie Aufgaben bewerkstelligt werden – und dafür ist „Agile“ der neue Standard.

Dev-Insider: Perforce hat sich in diesem Bereich nun mit der Übernahme des Agile-Spezialisten Hansoft Technologies breiter aufgestellt. Wie gut ließen sich die Tools aus den beiden Welten verquicken?

Karlsson: Es war in der Tat recht einfach, die beiden Tools zu kombinieren, da es bereits viele gemeinsame Kunden gab, besonders in der Spieleentwicklungs-Branche. Wenn Kunden bereits entscheiden konnten, welche Tools sie in ihr Ökosystem aufnehmen wollen (und eine Integration mit Helix Core bereits bestand), machte dies die Integration deutlich einfacher.

Johan Karlsson ist Senior Consultant bei Perforce Software.

(ID:45404554)