Agile Day auf der IPC und WebTech-Con 2014

Agilität: Warum es an der Zeit ist, umzudenken
Kommentare

Agile Methoden sind in vielen Unternehmen bereits Standardpraxis und werden für unzählige Projekte benutzt. Im Rahmen des Agile Day der International PHP Conference und WebTech Conference gaben die Speaker in spannenden Keynotes und Sessions Einblicke in die Erfahrungen agiler Berater, Kunden und Entwickler und zeigten, wie sich agile Vorgehensweisen erfolgreich auf Software-Entwicklungsprojekte anwenden lassen. 

„Rewire your brain“: Warum Unternehmen in Produkten und nicht in Projekten denken müssen

Björn Schotte erklärte in seiner Eröffnungskeynote, dass ein anderer Fokus nötig sei, weil das finale Produkt über einen längeren Zeitraum genutzt wird. Darum ist es nicht damit getan, für eine vergleichbar kurze Zeitspanne an der Entwicklung zu arbeiten und nach dem Release das Produkt Produkt sein zu lassen. 

Deshalb ergebe die Anwendung agiler Methoden erst dann Sinn, wenn es tatsächlich darum geht, Produkte zu entwickeln – und zwar nur, wenn dafür eine kontinuierliche Planung stattfindet; immerhin sollen die Nutzer das finale Produkt permanent nutzen. Letztendlich sind es also die Konsumenten, die die Verlagerung des Marktes antreiben, nicht die Unternehmen und darum muss unablässig in die Entwicklung neuer Funktionen für Online-Projekte investiert werden. 

Doch das Geheimnis des agilen Erfolgs endet nicht hier. Bei der Anwendung agiler Methoden gehe es nicht nur darum, sich während der Sprint-Phase vorzunehmen, soundso viele Features zu entwickeln und wenn es eben statt fünf nur zwei werden, ist das eben so. 

Stattdessen soll der größtmögliche Business Impact herausgeholt werden. Im Vordergrund steht eben der Nutzen und der Wert des Produkts – und den erreicht man eben erst, wenn genau dieses Umdenken stattfindet und sich auf die kontinuierliche Lieferung von „wertvollen“ Produkten fokussiert wird.

Schwierigkeiten in Projekten erfolgreich meistern – mit Kommunikation und Struktur

Trotzdem sind Schwierigkeiten in Projekten normal. Die Frage ist natürlich, wie man mit ihnen umgeht und was man tun kann, um das Software-Projekt wieder auf die richtige Spur zu bringen. In ihrer Session Agile Xchange: Schwierigkeiten in Projekten erfolgreich meistern erklärten Björn Schotte und Dominik Jungowski darum anhand einiger Real-Life-Beispiele, wie solch eine Problemlösung aussehen kann. 

Der Erfahrungsaustausch stand dabei besonders im Vordergrund: Wie kann die Zusammenarbeit von agilen und nicht agilen Teams verbessert werden, wie steht es mit Operations vs. Agil, und was kann man eigentlich tun, wenn der Kunde der Geschäftsführer ist? All das waren Fragen aus dem Publikum, denen sich die Speaker angenommen und gemeinsam mit den Zuhörern nach Lösungsansätzen gesucht haben. 

Am Ende zeigt sich dabei vor allem eins – das Kommunikation und Struktur in vielen Fällen der Schlüssel ist, um Schwierigkeiten bei Projekten in den Griff zu bekommen. 

 

Was Papierflieger mit Software-Entwicklung gemeinsam haben

Wenn auch die intensivste Kommunikation nicht mehr weiterhilft, kann man ja immer noch Papierflugzeuge mit seinem Team basteln. Das klingt auf den ersten Blick vielleicht ein wenig absurd, doch Dominik Jungowski zeigte in seiner Session Kanban Paper Airplanes, welche Vorteile Work-in-Progress-Limits haben – indem er die Teilnehmer Papierflugzeuge bauen ließ. 

Das Experiment sollte vor allem zeigen, wie Engpässe bei der Software-Entwicklung entstehen und wie sie sich in den Griff bekommen lassen. Dabei sollten die Teams in der vorgegebenen Zeit so viele Papierflugzeuge wie möglich basteln, die zum erfolgreichen Bestehen des Tests anschließend mindestens zehn Meter fliegen mussten. 

Für das Bauen des Papierfliegers sind mehr Arbeitsschritte nötig, als Teammitglieder vorhanden sind, dadurch lastete automatisch mehr Druck auf einer Station, es kam zu mehr fehlgeschlagenen Tests. Eine Situation, die Entwicklern bekannt sein dürfte…

Die Lösung des Problems gestaltete sich dann recht einfach: mit einem Puffer wird der Druck von der Partei genommen, die mehrere Arbeitsschritte übernehmen muss. So wird der Output gesteigert (im Fall des Experiments wurden mehr Flieger gebaut) und die Qualität nimmt zu (mehr erfolgreich bestandene Tests). 

Back to the roots: Was Software-Developer von US Marine Corps lernen können

„Wandel kann man nur begegnen, wenn man selber wandelbar ist und bleibt.“ Das sagte Gordon Oheim in seiner Session Commando Code – what software developers can learn from the US Marine Corps und traf damit den Nagel auf den Kopf. Gerade der Wandel, das Umdenken bei der Software-Entwicklung sei es, womit sich auseinandergesetzt werden müsse. 

Dabei könnten Entwickler einiges vom Militär lernen – sei es, welche Strategien für das Treffen besserer Entscheidungen übernommen werden können, oder wie sich das Konzept „Mission Command and Control“ auf die Software-Entwicklung auswirkt. Dabei geht es insbesondere darum, wie man sich selbst führen und den „Commander’s Intent“ umsetzen kann.

Vor allem das Herausbilden einer professionellen Identität sei es, das für eine bessere Performance der Entwickler sorgen könnte – doch gerade das Selbstverständnis wer und was man sein will und wie die Ziele umgesetzt werden können, fehle vielen Entwicklern. Am Ende gilt allerdings: 

Everyone unites under a strategy, everyone matters and everyone pulls in the same direction.

Es ist also an der Zeit, umzudenken. Der Tag auf dem Agile Day der IPC und WebTechCon 2014 zeigte uns eben das ganz deutlich.

Aufmacherbild: Wooden cubes spelling agile von Shutterstock / Urheberrecht: joreks

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -