Weg vom Wasserfallmodell, hin zu agilen Methoden: So lautet die Devise in immer mehr Softwarehäusern und Unternehmen, die auf die Vorteile agiler Softwareentwicklung setzen. Wichtig bei der Umsetzung sind aber Strategie und geplantes Vorgehen, um die Entwicklerteams und andere Unternehmensbereiche bei der Transformation mitzunehmen. [...]
Das klassische Wasserfallmodell „plan and build“ wird auch in kleinen und mittleren Unternehmen vermehrt durch agile Methoden abgelöst. Angesichts kurzer Innovationszyklen als Antwort auf die Digitalisierung erweisen sich die traditionellen Modelle als ungeeignet. Der Grund: Teams, die nicht parallel an Entwicklung, Code Review sowie Qualitätssicherung arbeiten und erst gegen Ende des Projekts ihre Entwicklungen testen, können dem Innovationsdruck nicht standhalten. Immer wieder erweisen sich Deadlines in der Praxis als nicht haltbar. Und gegen Ende eines lang geplanten Entwicklungszyklus wird es nicht selten stressig, weil Probleme auftreten und es viel Zeit benötigt, die Entwicklungsschritte zu rekapitulieren. Kommt dann das Feedback der Qualitätssicherung erst ganz zum Schluss, muss nicht selten nachgearbeitet werden, oder es werden sogar einige Entwicklungsergebnisse komplett über den Haufen geworfen. Das führt zu einer Verschwendung von Ressourcen und Demotivation innerhalb eines Entwicklerteams. Besser ist es dagegen, den Entwicklungsprozess in kleinere Abschnitte zu unterteilen und deren Ergebnisse kleinteilig unter die Lupe zu nehmen.
Ist die Führung eines Unternehmens davon überzeugt, dass sie auf agile Entwicklungsmethoden umstellen will, stellt sich die Frage nach der Transformation. Die Kernfrage sollte dabei lauten: Wie kann die Entwicklungsmethode ohne große interne Reibungsverluste gewechselt werden? In der Praxis hat sich gezeigt, dass ein Umstieg von jetzt auf gleich wenig Erfolg verspricht. Einem Team, das viele Jahre nach dem Wasserfallmodell gearbeitet hat, kann man nur sehr schwer die agile Entwicklung „überstülpen“. Dazu unterscheidet sich die Methodik zu sehr vom althergebrachten Modell, was Eigenverantwortung, Flexibilität, Kommunikation und Teamorientierung angeht. Auch sollte vermieden werden, dem Team das Gefühl zu vermitteln, im Vorfeld sei alles falsch gewesen, und dass Agilität nun von oben verordnet wird. Es empfiehlt sich also, die Entwicklertruppe von vornherein in die Entscheidungsfindung pro Agilität einzubinden und von den positiven Aspekten zu überzeugen. Gleichzeitig sollen alle Beteiligten früh ihre Bedenken äußern dürfen.
Weitere Unternehmensbereiche nicht ausklammern
Es ist selbstverständlich, dass das bestehende Entwicklungsteam die Transformation mittragen muss. Schließlich müssen die Entwickler ihre bisherige Arbeitsroutine ändern. Aber auch andere Unternehmensbereiche wie Vertrieb, Marketing oder auch Buchhaltung sollten sich umstellen. Die Praxis zeigt, dass beispielsweise eine Marketingabteilung, die gewohnt war, die Aktivitäten von Major Release zu Major Release zu planen, nun auch einem gewissen Veränderungsdruck ausgesetzt ist, weil in kürzeren Abständen kleinere Neuentwicklungen und Verbesserungen veröffentlicht werden. Gleichzeitig kann aber eine erhöhte Transparenz auch zu mehr Verständnis und Akzeptanz für die technischen Prozesse sorgen. Beispielsweise in dem man tägliche Stand-up-Meetings des Entwicklungsteams zugänglich macht oder auch turnusmäßige Sprint Reviews ansetzt, an denen alle Unternehmensbereiche teilnehmen können und über die aktuellen Entwicklungsschritte informiert werden. Damit wird auch dem häufig seitens der Entwickler geäußerten Gefühl entgegengewirkt, dass der Rest des Unternehmens gar nicht weiß und schätzt, was die Software Engineers leisten.
Es ist selbstverständlich, dass das bestehende Entwicklungsteam die Transformation mittragen muss. Schließlich müssen die Entwickler ihre bisherige Arbeitsroutine ändern. Aber auch andere Unternehmensbereiche wie Vertrieb, Marketing oder auch Buchhaltung sollten sich umstellen. Die Praxis zeigt, dass beispielsweise eine Marketingabteilung, die gewohnt war, die Aktivitäten von Major Release zu Major Release zu planen, nun auch einem gewissen Veränderungsdruck ausgesetzt ist, weil in kürzeren Abständen kleinere Neuentwicklungen und Verbesserungen veröffentlicht werden. Gleichzeitig kann aber eine erhöhte Transparenz auch zu mehr Verständnis und Akzeptanz für die technischen Prozesse sorgen. Beispielsweise in dem man tägliche Stand-up-Meetings des Entwicklungsteams zugänglich macht oder auch turnusmäßige Sprint Reviews ansetzt, an denen alle Unternehmensbereiche teilnehmen können und über die aktuellen Entwicklungsschritte informiert werden. Damit wird auch dem häufig seitens der Entwickler geäußerten Gefühl entgegengewirkt, dass der Rest des Unternehmens gar nicht weiß und schätzt, was die Software Engineers leisten.
Ein besonderer Pluspunkt der agilen Entwicklung ist, dass schneller auf Markt- und Kundenbedürfnisse reagiert werden kann. So gelingt es viel besser, flexibel auf das Feedback der Kunden einzugehen, deren Ideen sowie Anregungen zu berücksichtigen und sie durch kürzere Veröffentlichungszyklen umzusetzen. Dieses Argument überzeugt. Darüber hinaus finden sich Entwickler mit ihren Ergebnissen schneller und in kürzeren Abschnitten im Produkt wieder. Das stärkt die Identifikation mit ihrer Arbeit und schlussendlich auch mit dem Unternehmen. Wenn es dazu noch gelingt, weitere Stakeholder im Unternehmen davon zu überzeugen, dass starre Ziele über drei Monate hinaus eher kontraproduktiv sind, dann sollte die nötige Akzeptanz für die Transformation geschaffen sein.
Keine Dogmen
Es darf nicht der Eindruck entstehen, Agilität werde verordnet. Das Team muss Veränderungen mittragen, sollte sich selbst einbringen und mitentscheiden, welche Werkzeuge aus dem „Werkzeugkasten“ der Agilität verwendet werden sollen. Auch hier gilt es, flexibel auf die Ansprüche zu reagieren und nicht, dogmatische Entscheidungen zu fällen. Verantwortliche Führungskräfte sollten bei Problemen nicht an der Kompetenz der Mitarbeiter zweifeln, sondern an den angebotenen und eingesetzten Methoden. Selbstverständlich lassen sich häufig die weichen Faktoren wie Kommunikationsfähigkeit trainieren. Wichtig ist, dass die Entwicklungsmannschaft keine passive Rolle einnimmt. Sie sollte von Anfang an dazu motiviert werden, aktiv, agil zu sein.
Es darf nicht der Eindruck entstehen, Agilität werde verordnet. Das Team muss Veränderungen mittragen, sollte sich selbst einbringen und mitentscheiden, welche Werkzeuge aus dem „Werkzeugkasten“ der Agilität verwendet werden sollen. Auch hier gilt es, flexibel auf die Ansprüche zu reagieren und nicht, dogmatische Entscheidungen zu fällen. Verantwortliche Führungskräfte sollten bei Problemen nicht an der Kompetenz der Mitarbeiter zweifeln, sondern an den angebotenen und eingesetzten Methoden. Selbstverständlich lassen sich häufig die weichen Faktoren wie Kommunikationsfähigkeit trainieren. Wichtig ist, dass die Entwicklungsmannschaft keine passive Rolle einnimmt. Sie sollte von Anfang an dazu motiviert werden, aktiv, agil zu sein.
Fazit
Der Wechsel vom Wasserfallmodell zu agilen Methoden ist eine organisatorische Herausforderung weit über Abteilungsgrenzen hinaus. Grundsätzliche Voraussetzung ist die Akzeptanz für den Wandel. Um diese zu erreichen, sollten Mitarbeiter bereits sehr früh involviert werden und auch bei der Ausgestaltung des Arbeitsalltags ihren Input geben. Das schafft Vertrauen und Motivation, den neuen Weg nicht nur mitzugehen, sondern aktiv mitzugestalten – die wichtigste Voraussetzung auf dem Weg zum agilen Unternehmen.
Der Wechsel vom Wasserfallmodell zu agilen Methoden ist eine organisatorische Herausforderung weit über Abteilungsgrenzen hinaus. Grundsätzliche Voraussetzung ist die Akzeptanz für den Wandel. Um diese zu erreichen, sollten Mitarbeiter bereits sehr früh involviert werden und auch bei der Ausgestaltung des Arbeitsalltags ihren Input geben. Das schafft Vertrauen und Motivation, den neuen Weg nicht nur mitzugehen, sondern aktiv mitzugestalten – die wichtigste Voraussetzung auf dem Weg zum agilen Unternehmen.
* Daniel Weuthen ist Director of Engineering bei der MailStore Software GmbH.
Be the first to comment