Agile Transformationen nehmen ihren Anfang meist in der Entwicklungsabteilung eines Unternehmens. So auch im Fall der Thalia eCommerce IT, deren Wandel zu einer agilen Produktorganisation mit selbstorganisierten Teams ich als Coach unterstützen durfte. Dass diese Veränderung jedoch auch massive Auswirkungen auf die Betriebsabteilung im Unternehmen mit sich bringt, wurde mir erst so recht bewusst, als ich mit deren Leiter im Rahmen einer Schulung zum Thema “Agiles Mindset” ins Gespräch kam. Dank meiner Operationsvergangenheit entwickelte sich schnell die Idee, dass ich ihn und sein Team bei der Reise in die schöne, neue, agile Welt begleite. Die Erfahrungen, die wir dabei gemacht haben, habe ich nun in einem Blogpost zusammengefasst.

“Klingt ja im Prinzip gut, aber den zusätzlichen Aufwand können wir dem Management gegenüber nicht verkaufen.”. Das höre ich oft, wenn ich in meinen Coachings die Prinzipien der Testgetriebenen Entwicklung vorstelle. Ähnlich wie beim Pair Programming bezweifeln die meisten Projektmitglieder nicht die Vorteile von TDD, haben aber große Bedenken, wenn sie die Stakeholdern davon überzeugen sollen. Die positiven Auswirkungen der Testgetriebenen Enbtwicklung sind vermeintlich zu technisch, als dass sie ohne das entsprechende Expertenwissen verstanden werden können. Anhand einer Situation aus dem Projektalltag möchte ich daher zeigen, wie man aus unternehmerischer Sicht von der Testgetriebene Entwicklung profitieren kann. Zum Artikel.

Als überzeugter TDD Practioner bin ich immer überrascht, welche verschiedenen Vorstellungen es zur Testgetriebenen Softwareentwicklung gibt, wenn ich diese Methodik im Rahmen meiner Coachings vorstellen. Um ein besseres Verständnis dieser Vorgehensweise zu schaffen, habe ich in meinem letzten Blogbeitrag die verschiedenen Aspekte etwas genauer unter die Lupe genommen.

Wenn ich in meinen Schulungen den Sinn und die Inhalte des Daily Scrum erläutere, ziehe ich gerne die Auszeit in Sportarten wie Eishockey oder Basketball als Vergleich heran. Hierbei kommt das gesamte Team zusammen und bespricht, mit welcher Taktik der größtmögliche Erfolg erzielt werden kann. Die Realität, die ich bei vielen agilen Teams beobachte, sieht leider etwas anders aus. In den meisten Fällen wird das Daily Scrum lediglich dazu genutzt, untereinander transparent zu machen, woran jeder einzelne gerade arbeitet. Die Koordination und Planung der nächsten Aufgaben mit Blick auf das gemeinsame Ziel spielt nur eine untergeordnete Rolle und so geschieht es nicht selten, dass am Ende des Sprints zwar viele Arbeitspakete abgearbeitet sind, das Sprintziel aber dennoch nicht erreicht wurde.
Um das zu verhindern, gebe ich diesen Teams eine alternative Methode an die Hand, mit der sie dieses Meeting so gestalten können, dass der Fokus weniger auf die individuellen Arbeit und mehr auf der Maximierung des Gesamtergebnisses liegt.

Um schnell auf Änderungen in der Softwareentwicklung reagieren zu können, werden in agilen Vorgehensmodellen möglichst alle hierfür nötigen Aufgaben in die Verantwortung des krossfunktionalen und selbstorganisierenden Entwicklerteams gegeben. Hierzu zählt auch der Entwurf und die Umsetzung der Software Architektur. Doch nach konkreten Ansätzen, wie diese Aufgabe bewältigt werden kann, sucht man in agilen Prozessen wie Scrum vergeblich und so laufen viele Teams Gefahr, das Ziel einer konsistenten und anforderungsgerechten Architektur zu verfehlen. In meinem Vortrag gehe ich auf die vier Kernelemente agiler Architekturarbeit ein und zeige, wie und an welchen Stellen sich diese in den Entwicklungsprozess integrieren lassen. Darüber hinaus stelle ich in der Praxis bewährte Methoden und Werkzeuge vor, die bei einer erfolgreichen Umsetzung helfen können.

In klassischen Wasserfallprojekten findet der Entwurf der Software Architektur in einer Designphase vor der Implementierung statt. Ein oder mehrere Software Architekten analysieren dabei die Anforderungen und legen die entscheidenden Rahmenbedingungen fest, innerhalb derer später die Entwicklung zu erfolgen hat. Anders sieht es hingegen in agilen Vorgehensmodellen wie Scrum aus. Hier liegt die Verantwortung für diese Aufgaben gemeinschaftlich bei dem Entwicklerteam, das die Architektur in regelmäßigen Intervallen überprüft, anpasst und weiterentwickelt. Doch wie ist sichergestellt, dass eine in sich schlüssige und tragfähige Architektur entsteht, die den Anforderungen genügt und deren Prinzipien auch von allen Entwicklern befolgt werden?

Wie die Erfahrung zeigt, ist das Aufsetzen von Integrationsumgebungen in Projekten häufig ein enorm zeitintensives Unterfangen. Es führt nicht selten zu langwierigen Projektvorlaufzeiten und bremst den Start der sonst so agilen Projekte aus. Aber auch im späteren Projektverlauf kann es immer wieder zu Verzögerungen kommen, wenn neue Softwarekomponenten installiert werden müssen oder die Kapazitätsanforderungen steigen und eine Skalierung der Infrastruktur erforderlich machen. Mein Artikel im Objektspektrum zeigt, wie sich mit Hilfe des Konfigurationsmanagement-Werkzeugs „Docker“ im Zusammenspiel mit der „Google Cloud Engine“ in wenigen Minuten bedarfsgerechte Systeme automatisiert aufsetzen lassen.