W-JAX 2015: Agile Day

Im ersten Teil des Blogs habe ich angekündigt, dass sich dieser Part um Agilität drehen wird. Ich habe meine Erfahrungen mit den Erfahrungen der Referenten zusammengefasst und werde die Agilität aus Sicht eines Entwicklers, eines (Projekt-)Teams, eines Unternehmens und eines Konsumenten agil entwickelter Software betrachten.

Agil! = agil?

Zuerst möchte ich jedoch etwas Klarheit schaffen, was Agilität bedeutet. Judith Andresen hat in ihrem Vortrag „Agil wachsen“ interessante Fragen gestellt, um das Thema näherzubringen: „Werden wir offen und sprechen Probleme und Fehler direkt an, weil ‚agile Projektmethode‘ am Team klebt?“, „Werden wir uns anders verhalten, wenn wir neue Rollenbezeichnungen einführen?“ Gerrit Beine verfolgte in „Agile-Coach zu werden ist nicht schwer …“ ebenfalls den Ansatz, durch Fragen zum Denken anzuregen: „Wird man agil, wenn man Hierarchien und/oder Jobtitel abschafft und stattdessen möglicherweise Fantasietitel einführt?“. Dazu erzählte er eine Anekdote: In einem Unternehmen entschloss man sich, die Jobbezeichnungen auf Fantasietitel umzustellen. Der Chief Technology Officer wurde damit zum Chief Motivation Officer. Interessanterweise behielten nach der Umstellung alle Chiefs das C im Namen. Von nun an brüstete sich das Unternehmen als agil.

Diese Erfahrungen decken sich mit meinen. Agilität bedeutet nicht, dass man stur einer Methodik folgen muss oder dass man aufgrund neuer Stellenbezeichnungen produktiver, offener und motivierter wird. Agilität muss sich in einem Team/Unternehmen entwickeln. Es ist nicht nur eine Prozessumstellung, sondern eine Kulturumstellung. Man muss mit alten Angewohnheiten brechen und mutig genug sein, neue Wege zu beschreiten, auch wenn diese am Anfang gefährlich aussehen. Diana Larsen hat in ihrem Agile Fluency Model [1] die Stufen aufgezählt, die agile Teams erreichen können. Sie verdeutlicht damit, dass Agilität keine fest verankerte Definition für bestimmte Praktiken ist, sondern eine Bandbreite von Verhaltensmustern und Techniken, die auf unterschiedliche Weisen gelebt werden können. Konstantin Diener hat in seinem Vortrag „Ich gestalte mein Unternehmen mit!“ gezeigt, wie das Ganze in die Praxis umgesetzt werden kann.

Nachfolgend habe ich einige Aspekte aufgenommen, die mehr oder minder in allen agilen Projekten gelebt werden. Diese Aspekte habe ich auf die Erfahrungen der W-JAX-Teilnehmer in agilen Projekten vs. Wasserfall-Projekte gemappt und auf die unterschiedlichen Rollen zugeschnitten beschrieben.

Einige Aspekte von Agilität

  1. Inkrementelle Entwicklung
  2. Regelmäßige Interaktion mit dem Auftraggeber – feedbackorientiert
  3. Offener und stetiger Informationsfluss
  4. Schnelle Reaktionsfähigkeit, kurze Entscheidungswege
  5. Anpassungsfähigkeit an Veränderung, Innovationsfähigkeit

Agiler Entwickler

Als Entwickler im agilen Umfeld müssen wir uns darauf einstellen, unsere Arbeitspakete so klein und sinnvoll wie möglich zu schnüren, um sie kontinuierlich abarbeiten zu können. Was auf den ersten Blick einfach klingt, erweist sich in der Praxis meist als schwierig. Es bedarf einer Menge Übung, den „Walking Skeletton" [2] einer Anforderung zu finden, also die kleinste Implementierung des Systems, welches eine kleine End-to-end-Funktion ausführt. 

 

 

 

 

Auf dem Wege dahin erweisen sich Gespräche mit dem Auftraggeber als essenziell. Denn nur er weiß genau, was er will, besser gesagt, was er nicht will. Wir müssen dem experimentellen Lernen offen gegenüberstehen und können innovativ sein. Wir müssen nicht alles so machen, „weil es schon immer so gemacht wurde“, sondern können vieles ausprobieren: alte Dinge auf eine neue Art und Weise tun oder neue Dinge testen. Weitere sehr wichtige Eigenschaften, die wir mitbringen sollten, sind die Offenheit, Probleme anzusprechen, und die Bereitschaft, Verantwortung zu tragen.

Agiles Team

Als Team müssen wir uns auf mehr qualitative Kommunikation einstellen. Das bedeutet nicht, mehr und längere Besprechungen innerhalb und außerhalb des Teams einzuberufen, sondern tägliche kurze Absprachen darüber, wer gerade an was arbeitet und wo Hilfe benötigt wird. Genauso wichtig wie die Kommunikation innerhalb eines Teams ist auch die Kommunikation mit anderen Teams des Projekts. Jeder, der am Projekt arbeitet, sollte ungefähr wissen, was gerade auf welchen Baustellen passiert und wie sich die Teilergebnisse auf das Gesamtsystem auswirken.

Wir entwickeln das große Ganze in kleinen Schritten und bekommen im besten Fall nach jedem abgeschlossenen Schritt eine Abnahme durch die Auftraggeber. Diese Abnahme ist wichtig, denn wir wollen so früh wie möglich wissen, ob wir mit unserer Implementierung das realisiert haben, was der Auftraggeber gewünscht hat. Falls die „gemeinte“ Anforderung nicht der verwirklichten Anforderung entspricht, ist es unser Anliegen, dies zu ändern.

Wir legen viel Wert auf ein gutes Arbeitsklima und ein ausgeprägtes Zusammengehörigkeitsgefühl. Deshalb sprechen wir auch Probleme, die nicht direkt mit einer Aufgabe zu tun haben, offen und ehrlich an. Wir wissen, dass Fehler auch dem Besten passieren können, und leben eine offene Fehlerkultur.

Agiles Unternehmen

Agilität in Projekten verändert auch die Unternehmenskultur und andersherum. Wenn die Unternehmenskultur keinen Raum zur inkrementellen Weiterentwicklung der Software und ihrer Entwickler lässt, wird das „agile Projekt“ sehr schnell nur noch auf dem Papier als „agil“ geführt. Agilität ist am Anfang wie eine Mimose: Wenn man sie im Unternehmen etablieren will, muss man für sie erst einmal den Boden bereiten und alle negativen Einflüsse fernhalten. Nach und nach werden sich die Mitarbeiter an das „neue“ Vorgehen gewöhnen und es lieben lernen. Nicht umsonst sagt man „Gut Ding will Weile haben“; so ist es auch mit der Transformation auf das agile Vorgehen.

Als agiles Unternehmen sind wir in der Lage, schnell auf wechselnde Kapazitätsansprüche sowie veränderte funktionale Anforderungen zu reagieren. Unsere IT unterstützt uns bei unserem Kerngeschäft und spürt IT-gestützte Innovationen auf.

Agiler Konsument

Zu guter Letzt möchte ich noch die Auswirkung der agilen Entwicklung auf uns als (private) Konsumenten beispielhaft verdeutlichen. Jeder, der bei Facebook [3] oder XING [4] nach einer Versionsnummer sucht, sucht vergeblich. Diese Software wird so schnell und oft aktualisiert, dass sich die Entwickler relativ früh entschlossen haben, die Versionsnummer nicht zu veröffentlichen. Facebook praktiziert das Agile Manifesto [5] im Bezug auf Customer Collaboration und Responding to change auf eine vorbildliche Weise: Neue Funktionalitäten werden für den Live Test an kleine Nutzergruppen ausgerollt, um sehr schnell Feedback zur User Experience einzuholen. Wenn das Feedback positiv war, wird das Rollout für eine größere Nutzergruppe vorgenommen. War das Feedback nicht wie gewünscht, wird das Feature eingestampft [6]. Es wird kein Geld an Unnützes verschwendet; nur Features, in welchen der User einen Mehrwert sieht, indem er diese benutzt, werden weiterentwickelt.

Als agiler Konsument müssen wir bereit sein, Software zu kaufen, die noch nicht komplett fertig ist und sich erst mit der Zeit entwickelt. Wir müssen uns an regelmäßige Updates in kurzen Intervallen gewöhnen. Wir können indirekten Einfluss auf die Systeme nehmen, indem wir konstruktiv Kritik äußern bzw. indem wir unser Nutzerverhalten auswerten lassen. Die meisten Software-Anbieter werden diese Informationen gerne entgegennehmen und ihr Produkt entsprechend anpassen.

Fazit

Abschließend kann ich zusammenfassen, dass die vielfältige Erfahrung der W-JAX-Agile-Day-Teilnehmer und -Vortragenden einen gemeinsamen Nenner in puncto Agilität aufweist: Agilität hat keine Definition, sondern kann sich auf unterschiedlichste Weise präsentieren. Die fünf genannten agilen Aspekte sind in jedem agilen Projekt vertreten und werden von den unterschiedlichen Projekt-Stakeholdern unterschiedlich gelebt. Agilität ist keine Methodik, die erlernt und dann praktiziert werden kann, sondern ein Kulturwechsel. Dementsprechend braucht es eine gewisse Vorlaufzeit, um Früchte zu tragen. In der Praxis hat es sich bewährt, die Agilität erst einmal durch ein kleineres Projekt und/oder Team mit Unterstützung eines Coaches in das Unternehmen einzubringen, sozusagen die Keimzelle. Richtig gepflegt, kann sich von dort aus das Pflänzchen entwickeln und auf weitere Teams und Projekte ausbreiten.