#3 Agile Softwareentwicklung – vom Prinzip her agil

Das agile Manifest, das ich im vorherigen Blog-Beitrag vorgestellt habe, gilt es nun zu leben. Doch wie? Dafür wurden zwölf Prinzipien aufgestellt, die als Verhaltens- oder Spielregeln verstanden werden können. Mit Hilfe dieser Prinzipien gibt es also eine Hilfestellung, um Agilität leben zu können, aber nicht, um sie auch zu messen. Alle zwölf Prinzipien in einem Blog-Beitrag durchzugehen ist nicht ganz so einfach, daher teile ich sie auf zwei Blog-Beiträge auf – eine Fortsetzung ist also schon garantiert. ;)

Wir folgen diesen Prinzipien ...

Dem agilen Manifest entnehmen wir folgende Prinzipien:

Auf das Minimale heruntergebrochen bedeutet es, dass wir regelmäßig und früh Software bereitstellen wollen. Das heißt, es werden kleine Inkremente – also Teilfunktionen der Software – bereitgestellt und man nähert sich dem großen Ganzen iterativ. Das Feedback, das wir erhalten, nutzen wir, indem wir unser Tun mit der nächsten kleinen Iteration anpassen und verbessern.

Grundsätzlich wollen wir in der agilen Welt Komplexität reduzieren und das schaffen wir unter anderem durch eine kontinuierliche Auslieferung von Inkrementen. Komplexität wir reduziert, wenn man im gleichen Rhythmus bleibt, anstatt unregelmäßig und nach Bedarf Software bereitzustellen. Im agilen Vorgehen versuchen wir Meetings, Events und vieles mehr zur selben Zeit am selben Ort stattfinden zu lassen. Je besser wir das schaffen, desto weniger müssen wir uns Gedanken um die Organisation des Alltages machen. Das Prinzip legt hierbei einen Fokus auf die Kundinnen und Kunden beziehungweise Stakeholder, denn schlussendlich machen wir all dies am Ende für den Auftraggeber.

Unzufriedene Kundinnen und Kunden möchte niemand. Die Zufriedenheit können wir auf unterschiedliche Arten und Weisen beeinflussen. Entscheidend ist hierbei, Ängste zu nehmen, Sicherheit zu geben. Wie könnte das besser gelingen, als den Stakeholdern regelmäßig kleine Fortschritte aufzuzeigen und sie mit in den Entwicklungsprozess zu integrieren? Vertrauen wird dabei geschaffen, indem das Feedback ernst genommen und innerhalb der nächsten Iteration aufgezeigt wird, dass wir dazugelernt haben.

Änderungen sind etwas Gutes und wir haben verstanden, dass diese zum Prozess dazugehören. Statt den Mehraufwand als Last zu verstehen, begrüßen wir diesen als eine Chance, die Dinge noch besser zu machen.

Wenn wir regelmäßig und in kurzen Etappen Software liefern und offen für einen regen Austausch mit den Kundinnen und Kunden sind, erhalten wir stetig Änderungen und Anpassungen durch sie auf unserem gemeinsamen Weg. Dadurch entsteht eine wesentlich kundenbedarfsgerechtere Lösung und genau das wollen wir in der agilen Softwareentwicklung erreichen. Wir schaffen hierdurch einen echten Mehrwert für Kundinnen und Kunden und können ihn mit jedem Gespräch aufs Neue messen, bewerten und gegebenenfalls korrigieren.

Wir sind mutig und versuchen innerhalb von beispielsweise zwei Wochen statt zwei Monaten, kleine Inkremente zu liefern. Dazu gehört vor allem der Mut, nur kleine Schritte zu machen. Auch da müssen Kundinnen und Kunden mitspielen, da es einen Unterschied macht, nur kleine Teilfunktionen in regelmäßigen Abständen zu prüfen anstatt eine große Funktion nach einigen Monaten.

Dabei gilt: je kürzer die Zeitspanne, in der man mit den Kundinnen und Kunden die funktionierende Software prüft, desto kleiner das Feature und desto öfter sprechen wir miteinander. Der Vorteil ist, dass wir hierbei regelmäßig Feedback von den Kundinnen und Kunden erhalten, das in der Entwicklung berücksichtigt und genutzt werden kann.

Kernelemente des agilen Arbeitens: die Klärung von Fragen, das Aufbrechen von Silos und das abteilungsübergreifende Denken – alles bedingt regelmäßige Zusammenarbeit. Wir wollen von der Schwarmintelligenz profitieren und das schaffen wir am besten durch einen täglichen Austausch zwischen Fachexpertinnen und -experten sowie Entwicklerinnen und Entwicklern. Fachexpertinnen und -experten sind diejenigen, die über das „Was“ Bescheid wissen. Entwicklerinnen und Entwickler sind diejenigen, die über das „Wie“ entscheiden.

Wenn beide Gruppen miteinander sprechen, statt über Dokumentation zu kommunizieren, schafft man auf beiden Seiten ein besseres Verständnis von dem, was benötigt wird und eigentlich gewollt ist. Und ganz nebenbei steigt in den meisten Fällen auch die Kundenzufriedenheit. Transparenz und Kommunikation fördern Vertrauen. Und auf der anderen Seite steigt auch bei der Entwicklung die Zufriedenheit, weil sie den geschaffenen Mehrwert besser erleben und verstehen können.

Vertrauen. Wir verabschieden uns davon, dass alle nur auf ihren Zuständigkeitsbereich schauen und wenig Interesse darüber hinweg äußern. Wir arbeiten gemeinsam, als motivierte Kolleginnen und Kollegen, an einem gemeinsamen Ziel. Wir vertrauen darauf, dass alle Beteiligten ihr Bestes geben, um funktionierende Software zu entwickeln. Das führt im Übrigen dazu, dass alle die Möglichkeit haben, aus sich das Bestmögliche herauszuholen. Je mehr Vertrauen wir haben, desto mehr Mut finden wir, um kreative Lösungen zu entwickeln.

Der Schwerpunkt im Agilen liegt in der Kommunikation miteinander, und zwar im direkten Gespräch und nicht über Mails oder Dokumentation. Kurze und zielgeführte Meetings können nicht in allen Fällen Dokumentation oder Schriftverkehr ersetzen. Sie sorgen jedoch dafür, dass Hindernisse oder Unklarheiten direkt geklärt werden können. Dadurch wird Zeit gespart sowie schneller und besser ein gemeinsames Verständnis von dem, was erreicht werden soll, geschaffen. Je mehr wir zielorientierte zwischenmenschliche Interaktionen ermöglichen und unterstützen, desto schneller kann ein Team zusammenwachsen. Ein agiles Team verabschiedet sich von individuellen und persönlichen Zielen und setzt den Fokus auf gemeinsame Werte und Ziele.

Vom Prinzip her agil

Noch fehlen uns die restlichen sechs Prinzipien. Doch wenn auch nur eine Person, die diesen Blog-Beitrag gelesen hat, aus Neugier jetzt schon die restlichen sechs Prinzipien recherchiert, dann war es die Mühen und den Aufwand wert.

Wir können das, was wir tun, gerne agil nennen. Wir können gerne sagen, dass wir nach Scrum arbeiten und deswegen agil sind. Wir können auch behaupten, dass wir agil sind, weil wir den Kundinnen und Kunden öfter mal zwischendurch ein Ergebnis zeigen. Niemand verbietet uns das. Aber sind wir da ehrlich mit uns selbst?

Luther wird zur Bibel zitiert mit „Jeder Christ soll die Bibel selbst lesen und verstehen“. Nun möchte ich keinesfalls die Bibel und das agile Manifest gleichsetzen, aber ich würde mich gerne anschließen: Wer Agilität leben möchte, der sollte das agile Manifest und seine Prinzipien selbst lesen und verstehen.