Teil 2: Warum Agile Softwareentwicklung nicht funktioniert

Die etwas provozierende Aussage dieses Blog-Titels ist natürlich nicht falsch zu verstehen. Agile Softwareentwicklung kann sehr wohl funktionieren: Wenn alle Stakeholder und Projektbeteiligten verstehen, was Agilität bedeutet und das Management zulässt, sie auch wirklich zu leben.

Wann Agilität jedoch nicht funktioniert und worüber viele Unternehmen bei der Einführung einer agilen Vorgehensweise stolpern, haben wir euch in folgenden Pitfalls zusammengefasst:

Zu wenig Commitment und Verständnis für agile Methoden

Um die Transformation von traditionellem zu agilem Projektmanagement zu meistern, braucht es Commitment und die Bereitschaft, Dinge zu verändern. Und das nicht nur bei den Entwicklern und Projektleitenden, sondern auf allen Stufen - vom Praktikanten bis zum Management.

Nebst mangelndem Commitment fehlt es in vielen Unternehmen schlicht am Wissen, wie Agilität erfolgreich angewendet und gelebt werden kann.

Mit der Einführung von neuen Tools und Frameworks ist es nicht gemacht

Einige Unternehmen gehen davon aus, dass man mit der Einführung von einem Daily Standup und einem Jira- oder Trello-Board nun agil unterwegs sei. Sie ahnen es: weit gefehlt. Eine wirklich agile Vorgehensweise erfordert viel mehr als das Einführen von Tools oder einem Framework, wie beispielsweise Scrum (Achtung! Scrum und agile Softwareentwicklung sind keine Synonyme. Scrum ist eines von verschiedenen agilen Frameworks, das Teams in einem volatilen Umfeld hilft, iterativ und effizient funktionale Software zu liefern).

Einsparungen am falschen Ort

Es besteht teilweise die Auffassung, dass Retrospektiven oder bei Anwendung des Scrum Frameworks der Scrum Master keinen Business Value kreieren. Sie werden in vielen Fällen einfach wegrationalisiert. Selbes gilt für Code Reviews oder das Schreiben von automatischen Tests. Das ist ein Irrtum und kann zum Verhängnis werden. Während eine User Story direkt nach der Umsetzung neuen Business Value in Form einer neuen Funktionalität generiert, wirken sich Retros oder der Scrum Master eher langfristig auf die Qualität und auch auf die Velocity (Geschwindigkeit des Teams) aus. Wer hier also Geld spart, wird langfristig noch mehr Geld ausgeben.

Zu wenig Kollaboration zwischen Business und Entwicklung

Im klassischen Wasserfall-Modell zog sich das Entwicklungsteam nach der Konzept- und Spezifikationsphase zurück und sah den Kunden oder die Kundin erst an der Demo des fertigen Produkts wieder. Das Business wusste nicht, wo das Team mit seinen Entwicklungen stand und das Entwicklungsteam wusste wiederum nicht über das Daily Business und evtl. geänderte Umstände oder Anforderungen Bescheid.

Um auf besagte Dinge schnell reagieren zu können, braucht es Transparenz. Alle Beteiligten müssen jederzeit über den Projektstatus, mögliche Probleme oder geänderte Anforderungen informiert sein. Genau dies wird verunmöglicht, wenn das Entwicklungsteam zu wenig involviert und somit zu wenig Kontakt zum Business hat.

Verträge und Rahmenbedingungen lassen keine Agilität zu

Oft ist eine agile Vorgehensweise und gleichzeitig ein genauer Projektplan mit Meilensteinen und einem Festpreis gewünscht. Um einen Festpreis angeben zu können, sind sehr genaue Anforderungen nötig. In der Regel müssen ca. 80% der Anforderungen bekannt und sauber dokumentiert sein. Ist dies der Fall, macht eine agile Vorgehensweise definitiv keinen Sinn. Denn eine der vier Grundprinzipien sagt uns: "Responding to change over following the plan". Man soll also auf geänderte Umstände oder Prioritäten reagieren, statt stur an einem ursprünglichen Plan festzuhalten. Ein Festpreis und daran gekoppelte Projektpläne können bei Projekten mit einem kleinen Scope durchaus Sinn machen. Agilität hat in diesen Projekten aber keinen Platz.

Rückfall in "alte" Verhaltensmuster

Es ist vollkommen normal, in alte Verhaltensmuster zurückzufallen, wenn man viele Jahre nach Wasserfall gearbeitet und mit Hilfe von Meilensteinen und Festpreisen Projekte realisiert hat. So kommt es häufig vor, dass Unternehmen zwar agil sein wollen, aber gerade in hektischen Situationen nicht entsprechend reagieren.

Übersteuerung des selbstorganisierten Teams durch das Management

Es gibt Teams, die verstanden haben, wie sie nach den Grundregeln des Agile Manifesto arbeiten können. Sie haben beispielsweise Scrum als Framework implementiert und haben einen Weg gefunden, wie Agilität für sie funktioniert.

Solange es sich finanziell auszahlt und alles nach Plan verläuft, wird dies vom Management mit wenig Erfahrung im Umgang mit agilen Methoden auch oft gutgeheissen. Gerät das Unternehmen jedoch in Schieflage ist Schluss damit. Egal, wie der Scrum-Prozess des agilen Projektteams gelebt wird, beginnt das Management zu intervenieren - und da es das Management ist, kann es das leider tun - und übernimmt die Kontrolle. Genau da hört die Agilität wieder auf.

Das heisst nicht, dass Führungspersonen bei Projekten oder in der Produktentwicklung nichts zu sagen haben. Ganz im Gegenteil. Wichtig ist aber, dass auch sie sich an die definierten Prozesse halten und auch wenn sie in der Hierarchie vielleicht weiter oben angesiedelt sind, keine Entscheidungen des Scrum-Teams übersteuern dürfen.

Fazit

Kommt Ihnen einer der aufgeführten Pitfalls bekannt vor? Mehrere? Sie sind damit nicht alleine. Viele Unternehmen hadern mit der agilen Transformation und dies nicht ohne Grund. Bekannte Projektmanagement-Methoden und Vorgehensweisen zu ändern, agil zu arbeiten, das ist eine Herausforderung. Geben Sie sich Zeit und bleiben Sie dran.

Im dritten Beitrag zu unserer "Agile Softwareentwicklung" Trilogie zeigen wir auf, mit welchen Tipps Sie die Transformation zur agilen Softwareentwicklung schaffen können.