Der Agile Day der W-JAX 2013

Building Software that matters!

Mirko Schrempp

Die Agile Days auf der JAX und W-JAX gehören zu den erfolgreichsten Special Days des Konferenz-Duos. Seit dem ersten Mal im Jahr 2006 sind die Days beträchtlich gewachsen, und auch in diesem Jahr waren auf der W-JAX in München rund 200 Teilnehmer anwesend. In gleicher Weise ist der Tag auch in seiner inhaltlichen Ausrichtung weiter gewachsen und vorangeschritten. Die Sprecher des stellten agile Erfahrungen und Realitäten vor, die weit von dem entfernt sind, was noch vor sieben Jahren diskutiert wurde. Entsprechend war die Zielsetzung auch, Impulse und Anregungen für die Arbeit mit agilen Methoden und Organisationen zu geben. Impulse, die die Teilnehmer in ihre Unternehmen mitnehmen können, um dort ihre Arbeitsweise weiterzuentwickeln.

Über den Tag zeigte sich vor allem, dass für den Erfolg immer noch die Kommunikation der zentrale Faktor ist. Außerdem muss die Bereitschaft vorhanden sein, das eigene agile Modell immer wieder an die Situation im Team oder im Unternehmen anzupassen. Viel wichtiger wird aber nach Ansicht der Sprecher der Bewusstseinswandel dahin, dass man mit jedem Stück ausgelieferter Software ein Produkt auf den Markt bringt, das über das Entwicklungsprojekt hinaus reicht. Hierbei nur im Rahmen des Projekt zu denken und dessen „Ziele“ zu erreichen, könnte zu kurz gedacht sein, weil das Produkt beim Kunden weitergenutzt wird und im besten Fall zu Folgeaufträgen führen kann, die im ersten Produkt idealerweise angelegt sind.

Große Teams remote oder co-located?

Ein Aspekt, der heute in der agilen Entwicklung zur Realität gehört ist, dass die Teams oder Unternehmen größer werden. Zum Start in den Tag zeigten die ersten beiden Sessions von Matthias Lübken (Pivotal) zu Staying Lean und Nathaniel Schutta (Solution Architect) zu Agile in the Large, wie „agil“ in Unternehmen mit vielen unterschiedlichen Entwicklerteams und Steakholdern funktionieren kann. Die Sprecher beschrieben Szenarien in Unternehmen, die weit davon entfernt sind, ein kleines Team zusammenzustellen, das agile Methoden überhaupt erst für den Einsatz testet. Für Matthias Lübken stehen dabei drei Dinge im Mittelpunkt: Embrace Change, Fuel Motivation und Support Learning. Die Mitarbeiter und Unternehmen müssen offen dafür sein, Änderungen als Chance wahrzunehmen, neues Wissen zu erwerben und alte Zöpfe abzuschneiden.

Lübken empfiehlt Unternehmen dazu, die Weiterbildung der Mitarbeiter in kleinen Zyklen zu organisieren. Dabei sei auch darauf zu achten, eine „adaptable company“ zu bauen, die sich schnell auf Neues einstellen kann. Zur Förderung der Motivation dazu bieten sich nach seiner Erfahrung z.B. Hackathons an, die den Mitarbeitern erlauben, zusammen neue Sachen auszuprobieren oder einfach Lösungen zu entwickeln, wozu sie im „normalen“ Alltag keine Zeit haben. Zum einen können durch solche Aktionen Dinge entstehen, die für das Unternehmen und seine Kunden direkt nützlich sind. Zum andern baut sich dadurch Wissen auf, das sich auf lange Sicht auszahlt.

Für Nathaniel Schutta standen die praktischen Aspekte der Teamarbeit im Vordergrund. In einer klassischen Organisation müssen Arbeitsräume für agile Teams geschaffen werden, in denen sie Meetings machen können, und andere Räume, in denen sie ungestört arbeiten können – auch wenn das nicht den Gewohnheiten im Unternehmen entspricht. Die Leute sollen sich wohlfühlen und die Aufgabe erfüllen, die ihrer Rolle entspricht. Dazu muss man verstehen, wer für was verantwortlich ist. Und dann muss die Person das auch tun dürfen und können.  „People are People, not resources – if you treat them that way, that does not work” .

Diese Diskussion wurde erweitert durch die Session (Home)Office von Martin Lippert (Pivotal) und Matthias Lübken (Adcloud), in der beide aus ihren Erfahrungen mit Teams berichteten, die zusammen in einem Büro sitzen (co-located) und mit komplett verteilten Teams (remote teams), die ohne gemeinsames Büro über alle Kontinente und Zeitzonen verteilt miteinander arbeiten. Nach ihrer Überzeugung funktionieren beide Ansätze für agile Teams sehr gut, auch wenn die Remote-Idee ursprünglichen agilen Gedanken zu widersprechen scheint. Die Grundbedingung sei nur, dass man keine halben Sachen mache. Wenn man ein Remote Team hat, dann müssen alle danach arbeiten. Und auch im co-located Team sei es nicht unbedingt gut, wenn Mitarbeiter für einige Tage im Home-Office seien, aber nicht voll in die Projektarbeit integriert werden können, weil die Strukturen dafür nicht vorhanden sind.

Die beiden Sprecher sehen die Punkte „Vertrauen in die Fähigkeiten und Zuverlässigkeit jedes Einzelnen“, die Transparenz der gesamten Arbeit, die gemeinsame Vision des Produkts als wichtig an, aber auch Zeiten, in denen das gesamte Team sich trifft, um auch persönliche Beziehungen im direkten Austausch aufbauen zu können. Doch auch dabei sei das Paradigma der Arbeitsorganisation: „remote as default culture“. 

In jedem Fall sei aber die Einarbeitung der Mitarbeiter in das neue Denkmodell die wichtigste Voraussetzung für den Erfolg – ein Aspekt, den auch Katja Findeis (cimt AG) in ihrem Bericht über den Verlauf eines Scrumprojekts im RUP Mantel hervorhob.

Buchtipps: Remote: Office not required von Jason Fried und David Heinemeier Hansson (37signals) und The Year without pants von Scott Berkung (WordPress)

Neue Geschäftsmodelle denken

Die drei weiteren Sessions des Agile Days stellten neue Denkweisen zur Frage des Geschäftsmodells und der eigenen Perspektive auf Ziele und Ergebnisse in den Mittelpunkt. Jens Coldewey empfahl in seiner Session „Mit dem Hammer auf die Schraube – Wenn Produkte wie Projekte behandelt werden“, sich von der reinen Projektdenke zu verabschieden und das Ergebnis der eigenen Arbeit immer als Produkt zu verstehen. Zur Verdeutlichung dieser Position nutzte er die Metapher des Spiels. Dazu unterschied er endliche und unendliche Spiele. Während die ersten von begrenzter Dauer sind, einem klaren Set von Regeln und bekannten Strategien folgen und als Ziel das Gewinnen haben, zeichnen sich offene Spiele dadurch aus, dass sie kein definiertes Ende haben, die Regeln sich ändern, Strategien vorab unklar sind, Mitspieler kommen und gehen, aber das Ziel ist: im Spiel bleiben!

Coldeweys These für die Softwareentwicklung ist daher: (Fast) Alle Softwaresysteme sind Bestandteile unendlicher Spiele! Die Software soll langfristig laufen. Das heißt – Softwaresysteme sind nicht die Folge von Projekten, sondern Produkte, die auf langfristig angelegte Ziele ausgerichtet sind. Innerhalb eines unendlichen Spiels können auch endliche Spiele ablaufen. Aber diese endlichen Spiels, bzw. Projekte, müssen an dem übergeordneten Ziel „im Spiel bleiben“ orientiert sein. Diese langfristige Sichtweise bedeutet ein Umdenken für viele Softwareentwickler.

Der wichtigste Aspekt in diesem Zusammenhang ist nach Ansicht von Matthias Bohlen das Verständnis vom Wert eines Produkts. Produkte sind nicht mehr nur Objekte, zu deren Kauf man die Kunden bewegen muss. Produkte werden, dank des heutzutage gut informierten Kunden, zu Objekten, die ihren Wert nicht „in sich tragen“. Erst durch die Nützlichkeit und Verfügbarkeit in einem Kontext für den Nutzer bekommen sie ihren Wert. Damit wird aus der Value Proposition eine Resource Proposition – App Stores sind ein Beispiel dafür. Dort kann der Kunden genau die App für seinen aktuellen Bedarf beziehen, in dem Moment, in dem er sie braucht. Und es kann dabei der Fall sein, dass das Produkt über diesen einen Moment hinaus keinen Wert für den Kunden hat. Es geht also darum, nicht einfach ein Produkt auf den Markt zu werfen, weil man meint, der Kunde brauche es, sondern Produkte zu entwickeln, die der Kunde haben will, weil sie für ihn zu einem bestimmten Zeitpunkt einen Wert haben. Das müsse man in der Planung der eigenen Produkte und dem Weg, wie der Kunde sie finden und beziehen kann, voraussehen, so Bohlen. Damit lasse sich das Risiko, dass man ein Produkt anbietet, das keiner kaufen, will reduziert.

Zur Frage, wie man die Anforderungen eines Produkts entwickelt, stellte Nils Wloka (codecentric AG) Impact Mapping als flexible Methode zur agilen Anforderungsanlayse vor. Wloka bezeichnete das Verfahren Impact Mapping von Gojko Adzics (http://impactmapping.org/) als inklusives, kooperatives und kreatives Verfahren, das jeder Mitarbeiter eines Projekts einfach nutzen kann. Agile Softwareentwicklung in dieser Form könne helfen, so Wloka, bei einem Problem, dessen Lösung man nicht kennt, das Ziel zu erreichen: Software that matters!

 

Geschrieben von
Mirko Schrempp
Mirko Schrempp
Mirko Schrempp ist Redakteur für den Windows Developer, das Business Technology Magazin und das SharePoint Kompendium.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.