#2 Agile Softwareentwicklung – das agile Manifest in der Praxis

Das agile Manifest gelesen zu haben, ist ein Anfang. Doch was bedeutet das für den Alltag?

In meinem ersten Blog-Beitrag bin ich vor allem auf den geschichtlichen Hintergrund von Agilität in der Softwareentwicklung eingegangen und habe erklärt, was Agilität in der Softwareentwicklung grundsätzlich bedeutet.

Nun ist es nicht notwendig, das Thema neu aufzurollen. 2001 haben 17 Softwareentwicklerinnen und -entwickler eine Erklärung geliefert, die uns bis heute hilft, das Ganze richtig anzuwenden und zu verstehen. Die Rede ist vom agilen Manifest sowie dessen 12 Prinzipien. Kleiner Spoiler vorweg: Zu diesen 12 Prinzipien wird es einen separaten Blog-Beitrag geben.

Das agile Manifest

Es ist kurz, schlicht, aber auch prägnant, wertvoll und mächtig. Im agilen Manifest stecken viele Informationen, die unseren Alltag im agilen Arbeiten verbessern können – wenn wir uns der Inhalte denn überhaupt bewusst sind.

Eine sehr klare Botschaft: „Wir gehen vor, wir zeigen, wie es geht, andere werden folgen.“ Der Plan ging auf, denn bis heute hat das agile Manifest auch nach 20 Jahren Bestand.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans
• Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
• schätzen wir die Werte auf der linken Seite höher ein.

Individuen und Interaktionen schätzen wir mehr als Prozesse und Werkzeuge

Wenn wir die Werte als Gesamtes im Unternehmen pflegen, diskutieren und uns auf diese einigen, hat dies bereits direkte Auswirkungen auf unseren Alltag. Schreibe ich jetzt via Teams, erstelle ich eine BPMN und verschicke sie oder versuche ich es erstmal mit einem zielgesteuerten Gespräch? Tooling ist nicht schlecht, keine Frage. Sicherlich ist es auch in vielen Situationen hilfreich, aber wie oft hätte ein kurzes Gespräch einen ähnlichen oder gar besseren Effekt gehabt? Wenn ich mir den Satz „Individuen und Interaktionen schätzen wir mehr als Prozesse und Werkzeuge“ von nun an öfter ins Gedächtnis rufe, werde ich vermutlich häufiger mal mit jemandem sprechen, anstatt mich hinter dem Tooling zu verstecken. Und genau diese Kommunikation wird dafür sorgen, dass wir mehr miteinander arbeiten, einander besser verstehen und voneinander lernen.

Dahinter steckt aber noch viel mehr. Wir legen einen Fokus auf die Individuen. Das bedeutet, wir respektieren, dass jede und jeder in der Lage ist, auf Basis ihrer oder seiner unterschiedlichen Erfahrungen und Fähigkeiten einen Mehrwert zu liefern. Je mehr wir kommunizieren, aktiv miteinander sprechen, desto eher profitieren wir von einer gewissen Schwarmintelligenz.

Funktionierende Software schätzen wir mehr als umfassende Dokumentation

Klingt doch eigentlich einleuchtend, oder? Was bringt mir eine perfekte Dokumentation, wenn die Lösung nicht funktioniert? Aber was bedeutet funktionierende Software für uns als Unternehmen oder Team und ist jedem diese Definition bekannt? Wann ist ein Stück Software fertig beziehungsweise funktional?

Je häufiger wir uns mit den Usern, für die ein Produkt gebaut wird, hinsetzen und ein gegenseitiges Verständnis voneinander gewinnen, desto mehr profitiert unsere Produktentwicklung davon. Je offener und transparenter unsere Umgebung miteinander und untereinander spricht und Informationen teilt, desto mehr lernen wir voneinander und desto schneller können wir auf Probleme reagieren. Je autarker und unabhängiger die Teams entwickeln können, desto schneller können wir Inkremente releasen und desto schneller können wir den Mehrwert, den wir liefern, messen. All das zahlt auf eine funktionierende Software ein. Wer würde hier nicht zustimmen? Dabei kam das Wort Dokumentation hier gar nicht vor.

Brauchen wir dann noch Dokumentation? Natürlich. Aber wie viel Dokumentation benötige ich für eine sich selbst erklärende Software?

Zusammenarbeit mit der Kundin oder dem Kunden schätzen wir mehr als Vertragsverhandlung

Vertragsverhandlungen sind wichtig. Nichts anderes sagt das agile Manifest. Das Ganze geht schon etwas weiter. Je enger und regelmäßiger wir während des gesamten Prozesses mit den Kundinnen und Kunden zusammenarbeiten, desto weniger Details müssten wir doch eigentlich in einem Vertrag festhalten, oder?

Der Vorteil eines klassischen Vertrags, der jedes Detail enthält, das man für die Produktentwicklung benötigen könnte: Man muss nicht so viel denken und noch weniger kommunizieren. Aber ist das wirklich ein Vorteil? Im klassischen Vertrag legen wir dadurch automatisch einen gewissen Fokus aufs Detail. Und wenn dieses sich ändert, sorgt das für Probleme – schließlich wurde bereits viel Zeit in dieses Detail investiert.

Im agilen Bereich arbeiten wir gerne mit Zielen. Dadurch wird ein Fokus geschaffen. Wir können den Weg zum Ziel einigermaßen beschreiben. Die Details ergeben sich allerdings während der Arbeit, indem wir die Kundinnen und Kunden regelmäßig zum Stand der Entwicklung informieren und ein gegenseitiges Interesse aufbauen und Feedback von den Kundinnen und Kunden in die Softwareentwicklung einfließen lassen. Wir wissen, dass Umstände, Technologien und Anforderungen sich mit einer so hohen Wahrscheinlichkeit noch einmal verändern können, dass wir das auf uns zukommen lassen. Dabei können wir Fehler machen – klar, aber solange wir den Fokus (das Ziel) im Blick behalten, können wir nicht wirklich vom Weg abkommen. Wenn wir uns im Vorweg die Zeit für das Ausformulieren sämtlicher Details ersparen, könnten wir direkt mit dem „Machen“ starten. Im agilen Arbeiten sind Änderungen etwas Gutes. Jede Änderung führt uns einen Schritt näher an das, was die Kundin oder der Kunde tatsächlich benötigt.

Reagieren auf Veränderung schätzen wir mehr als das Befolgen eines Plans

Planlos agil? Keinesfalls! Auch im agilen Umfeld arbeiten wir mit Plänen. Üblicherweise sind diese Pläne nicht so umfangreich, wie man es im klassischen Projekt- oder Produktmanagement kennt (wir schätzen funktionierende Software mehr als umfassende Dokumentation), aber: Sie existieren.

Ein Plan fängt im agilen Arbeiten häufig mit einer Vision oder einem Ziel an. Diese Vision oder dieses Ziel wird oft mit den nötigen Stakeholderinnen und Stakeholdern geschärft beziehungsweise weiter ausformuliert (Zusammenarbeit mit der Kundin oder dem Kunden …). Dadurch schaffen wir Transparenz und Fokus. Diese Ziele sind meistens noch in weiter Ferne. Je größer ein Ziel, desto mehr Ungewissheit herrscht darüber, wann und wie wir dieses Ziel erreichen können. Deswegen kann es helfen, die großen Ziele in kleinere Ziele aufzuteilen. Diese kleinen, erreichbaren Ziele zahlen also nun auf unser großes Ziel ein.

Wenn sich nun Änderungen ergeben, passiert das in der Praxis eher weniger an den Zielen, sondern viel mehr an der Arbeit, die wir gerade verrichten. Das heißt, der Fokus bleibt, wir müssen uns nur an der ein oder anderen Stelle anpassen. Diese Änderung nehmen wir in Kauf, weil wir ein Ziel im Blick haben.

Eine Familie, die ein Haus zu bauen plant, wird mit einer Architektin oder einem Architekten ein Modell erarbeiten. Dieses Modell dient als Zielbild. Üblicherweise werden auch hier wie im klassischen Projektmanagement alle Details festgehalten und am Ende steht das fertige Haus. Und vermutlich ist die Familie sogar glücklich damit. Warum also was ändern? Ich stelle mir vor, wenn man während des Baus die Möglichkeit hat, das Fenster doch weiter außen zu setzen, der Küche mehr Platz als ursprünglich geplant zu geben oder den Abstellraum doch kleiner zu Gunsten des dann größeren Gästebades zu machen, dann würde man diese Chance nutzen. Am Ziel selbst hat sich nichts verändert, lediglich der Weg wurde etwas angepasst.

Wie transparent ist eurem Team das agile Manifest? Lebt ihr die vier Werte und, wenn ja, woran messt ihr das?

Weitere spannende Themen aus der adesso-Welt findet ihr in unseren bisher erschienenen Blog-Beiträgen.

Auch interessant:

• Agile Softwareentwicklung – wir arbeiten agil! Wirklich?