Hallo Spaß-Coder,

im zweiten Teil der Artikelreihe wollen wir uns damit beschäftigen, welchen Arten von Veränderungen ein Unternehmen begegnen muss und wie uns Agilität dabei hilft. Im ersten Teil der Artikelreihe haben wir uns in erster Linie damit beschäftigt, warum es für ein Unternehmen notwendig ist, sich ständig zu verändern und anzupassen, und wie wir als Team diese Veränderung Schritt für Schritt gehen.

 

Änderungen sind notwendig

Dass im Leben eines Unternehmens Änderungen notwendig sind, sollte nun unbestritten sein. Als Beispiel lassen sich hier ein paar klassische Fälle anführen, in denen Unternehmen die Veränderungen am Markt um ein Haar verpasst hätten. Etwa Hersteller klassischer Fotoapparate, als die Digitalkamera Einzug erhielt, Glühlampenhersteller nachdem mehr und mehr auf LED gesetzt wurde, Handyhersteller, die kein Smart-Phone im Portfolio hatten, …

Im Softwarebereich sind solche Beispiele nicht ganz so prominent, fallen uns nicht so direkt auf und werden selten in der Tagesschau erwähnt, sind aber trotzdem vorhanden (siehe Statistiken zur IT- und Softwarebranche in Deutschland). Unternehmen müssen in der Lage sein, schnell auf Änderungen am Markt zu reagieren, um das eigene Überleben langfristig zu sichern.

Bei uns in der Software-Entwicklung kommt es sehr darauf an auf die – sich ständig ändernden – Kundenanforderungen einzugehen. Das startet bereits in kleineren Kundenprojekten, in denen der Kunde zu Beginn noch gar nicht weiß, was er eigentlich braucht und im Laufe des Projekts ändern sich seine Anforderungen. Diese Veränderungen müssen wir willkommen heißen! Nur wenn wir auf die geänderten Anforderungen eingehen, wird der Kunde am Ende des Projekts zufrieden sein mit dem Ergebnis. Er hat in dem Projekt gelernt, er kann sich auf uns verlassen. Dieser Kunde wird uns in einem nächsten Projekt mit hoher Wahrscheinlichkeit erneut das Vertrauen schenken. Laut des agilen Manifests ist Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlungen. Wir sollten die Software entwickeln, die unser Kunde braucht, nicht die, die wir am Anfang mit ihm vereinbart haben.

Auch die Entwicklung von Standardprodukten, bei denen wir weniger auf konkrete Kundenanforderungen, sondern viel mehr auf Anforderungen eines bestimmten Markts eingehen müssen, lebt von einer hohen Veränderungsbereitschaft. Was Anfang des Jahres eine gute Idee war, muss es jetzt gar nicht mehr sein, weil sich um uns herum so viel verändert hat. Da müssen wir uns anpassen. Und das betrifft nicht nur die Entwicklungsabteilung im Unternehmen! Auch andere Unternehmensbereiche müssen reagieren, mitziehen zusammenarbeiten. Es gilt Veränderungen zu erkennen und gemeinsam die neue Richtung festzulegen.

 

Änderungen überstehen

Im agilen Manifest sprechen wir auch davon, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge. Ein fixierter Prozess hilft mir nicht dabei, eine Änderung zu erkennen oder mit ihr umzugehen. Im Gegenteil, mit Hilfe eines Prozesses kann ich mich zurückziehen und die Veränderung ignorieren und das auch noch gut begründen. Hieraus entstehen dann Aussagen, die sicherlich jeder von euch schon mal gehört hat:

• „Das haben wir schon immer so gemacht!“
• „Da steht aber, dass ich das so machen soll, also mach ich das so!“
• „In meinem Arbeitsvertrag steht nicht, dass ich diese Aufgabe machen soll!“

Wenn wir auf Veränderungen nicht eingehen wollen, fällt es uns leicht Argumente dafür zu finden, warum wir dieser Veränderung nicht folgen möchten. Nicht alle sind so offensichtlich wie die oben genannten Beispiele.

Eine Veränderung an sich macht uns keine Angst. Veränderungen führen aber dazu, dass wir uns unsicher fühlen. Was kommt da auf mich zu? Schaffe ich das? Ist das Risiko nicht viel zu groß für mich? Welche Gefahr besteht für mich, wenn ich der Veränderung folge? Dieser Unsicherheit begegnen wir im agilen Umfeld durch den Fokus auf die Individuen. Wir arbeiten in Teams zusammen, nicht jeder einzelne muss eine Veränderung durchmachen, wir machen das gemeinsam! Wir stützen uns, nehmen uns gegenseitig die Ängste, gehen aufeinander ein.

Wenn wir nun doch wieder in Richtung Prozess denken, dann versuchen wir in der Agilität die Veränderungen durch Methodiken zu institutionalisieren. Im Scrum etwa arbeiten wir in kurzen Zyklen von wenigen Wochen. Nach jedem Sprint schauen wir zurück und Fragen uns, was wir verändern sollten, damit es noch besser funktioniert. Wir erkennen die notwendigen Veränderungen selbst und gestalten sie miteinander – im Team, nicht alleine. Innerhalb eines Sprints führen regelmäßige Iterationsgespräche mit dem Product-Owner oder dem Stakeholder zu schnellem Feedback, welches zu Änderungen an den Anforderungen führt. Auch hier wird die Änderung gemeinsam getragen. Niemand bleibt mit seiner Unsicherheit allein.

Damit das aber auch tatsächlich funktioniert, müssen wir Änderungen willkommen heißen. Jeder einzelne um Team muss eine Veränderung als Chance sehen und nicht als Bedrohung. Bedrohungen führen dazu, dass wir in eine Abwehrhaltung gehen und der Situation nicht mehr konstruktiv gegenübertreten. Sehen wir hingegen Chancen, sprudeln wir nur so vor Ideen. Und jede dieser Ideen kann das neue Erfolgsrezept sein.

 

Ständiges lernen

Ein weiterer Aspekt in der Agilität, die dabei hilft, Veränderungen positiv gegenüberzutreten ist, dass wir alles in kurzen Zyklen machen. Sei es die Entwicklung eines riesigen Features, bei dem wir erst einmal kleine, klar abgegrenzte Teile umsetzen, oder ein neues Vorgehen bei der Automatisierung unserer Tests. Wir machen einen Schritt, schauen uns um und sehen, wo wir stehen. Sind wir in der richtigen Richtung unterwegs? Müssen wir die Richtung anpassen, oder müssen wir gar wieder einen Schritt zurück machen?

Wir dürfen Fehler machen! Wir sollen sogar Fehler machen. Aus Fehlern lernen wir. Wichtig ist dabei, das wir die Auswirkung unserer Fehler klein halten. Wir probieren etwas Neues aus, wir starten ein Experiment und nach kurzer Zeit (in aller Regel nach einem Sprint) schauen wir, was an dem Experiment gut war und was wir noch verbessern können.

Das Mantra „fail fast, fail often“ spielt hier eine wichtige Rolle. Wir probieren viel Neues, gehen mutig nach vorne, auch mal Wege, die vielleicht nicht so sicher oder bequem sind, Wege, auf denen Gefahren lauern. Aber wir sind dabei niemals alleine, wir sind immer ein Team, wir begegnen Gefahren gemeinsam. Wir schauen uns die Situation regelmäßig an, lernen, passen an, verändern. Dauernd.

Das setzt natürlich eine Kultur voraus, in der Fehler schnell erkannt werden und auch auch direkt offen angesprochen werden (können). Das können individuelle Fehler sein, aus denen ich selbst lerne. Es kann ein Fehler in einer Teamentscheidung sein, aus der das Team lernt. Es kann ein Fehler in einer Unternehmensentscheidung sein, aus dem wir alle lernen. Wichtig ist, dass wir lernen wollen!

Zum Schluss dieses Artikels steht auch das letzte Zitat aus dem agilen Manifest, und ich denke nach dem Lesen dieses Artikels spricht er für sich: Reagieren auf Veränderung wichtiger als das Befolgen eines Plans.

Das Ziel ist es nicht, Software zu entwickeln. Das Ziel ist es, gute Produkte auszuliefern, sich ständig weiterzuentwicklen und auf Veränderungen eingehen können und wollen.

 

Wir hoffen, euch auch hiermit wieder einen Denkanstoß gegeben zu haben. Versucht mal für euch selbst zu reflektieren, was das bedeutet und welchen Beitrag ihr leisten könnt, um in eurem Unternehmen Veränderungen besser umsetzen zu können.

Eure Spaß-Coder