Das Agile Manifesto wurde vor kurzem 20 Jahre alt. Anno 2001 kamen damals Vertreter zusammen von Extreme Programmierung, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature Driven Development, Pragmatic Programming und anderen. Ziel war es, eine gemeinsame Alternative zu dokumentationsgetriebenen, schwergewichtigen Softwareentwicklungsprozessen zu finden. So schrieben sie also das Agile Manifesto, welches aus meiner Sicht bis heute seine Wichtigkeit behält.
Beim Entwickeln von Software hat die Menschheit leider noch keine jahrzehntelange Erfahrung, speziell für die Entwicklung von individueller Software. Bei der Entwicklung von Individuallösungen liegt die Herausforderung in der Erfüllung der Kundenerwartungen.
Den Einfluss der Agilen Softwareentwicklung auf unsere Arbeit bei Leuchter möchte ich in diesem Blogbeitrag näher bringen.
Das Manifest für agile Softwareentwicklung
Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
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.
Von Individuen und Interaktionen
Jeder Mensch ist anders, jeder Kunde sowieso 😉
Dieser Fakt begleitet mich bei der täglichen Arbeit und macht es spannend mit den unterschiedlichsten Menschen zusammenzuarbeiten. Aus diesem Grund ist es auch nachvollziehbar, dass die Interaktion mit dem Kunden und den individuellen Projektmitgliedern sehr viel wichtiger ist, als einen steifen Prozess zu befolgen, welcher im Endeffekt keinen Mehrwert bringt. Von sehr IT-affinen Personen, die sich für die Entwicklung ihrer Software bis zum letzten Detail interessieren, bis hin zu den Personen, bei denen sich die IT-Kenntnisse sehr in Grenzen hält, treffe ich bei unseren Kunden unterschiedlichste Menschen an. Wichtig ist es, die richtige Balance zu finden, um mit einem gemeinsamen Vorgehensmodell den Kunden in seiner Position zu bestärken. Ich sage oft, dass ich die Software nur so schreibe, wie das Business funktioniert. Wie sich die Software verhalten soll, müssen wir gemeinsam herausfinden. Um dem nachzugehen, gibt es unterschiedliche Werkzeuge. Wir verwenden oft Mockups (papiergezeichnete Benutzerschnittstellen), damit wir gemeinsam mit dem Kunden die Applikation durchspielen können. Der Kunde bekommt ein Gefühl, wie sich die Software verhalten wird und gibt mir ein besseres Verständnis, was sich der Kunde erhofft.
Ein weiteres Werkzeug ist die Definition einer Buyer-Persona, die den typischen Anwender beschreibt. Dies kann während der Entwicklung schon viele Fragen klären. An unserem Projekt eines grossen Schweizer Sicherheitsanbieters hatte uns die Buyer-Persona „Rüdhisüli“ während der gesamten Projektentwicklung begleitet. Er ist bei unseren Entwicklern und Projektmitglieder bekannt und jeder weiss, dass er ein Herr mittleren Alters ohne grosse IT-Vorahnung ist und während der Nacht mit einer mobilen App arbeitet.
Funktionierende Software über detaillierte Planung
Wer mit dem „Wasserfallmodell“ vertraut ist und dies noch von der Softwareentwicklung her kennt, der weiss, dass diese Vorgehensweise nicht tauglich ist. (Freue mich auf eure gegenteilige Beweise in den Kommentaren). Als ich während meiner Lehrzeit noch Structured Analysis und Structured Design lernte, dachte ich mir „ach herrje, welchen Berufszweig hab ich mir hier ausgesucht.“ Reihenweise Dokumentationen erstellen ohne je Software geschrieben zu haben, jeden Algorithmus bis ins Detail zu planen, um am Schluss herauszufinden, dass wir bei der Planung und Design doch etwas vergessen haben. Somit war schnell klar, dass das einzige Mass in welchem der Fortschritt eines guten IT-Projekts gemessen werden kann, die Geschwindigkeit ist, in welcher funktionierende Software geliefert werden kann.
Das iterative Vorgehen welches oft in Verbindung mit agiler Projektführung gebracht wird, hat genau dies zum Ziel. Die sogenannten Sprints (kurze intensive Programmierphasen) sind bei uns Standard. Wir versuchen in jedem Projekt ein iteratives Vorgehen mit dem Kunden zu vereinbaren, wobei wir innerhalb von zweiwöchigen Sprints jeweils ein Ziel vereinbaren, daraufhin arbeiten und dieses am Ende des Sprints dem Kunden präsentieren. Innerhalb von zwei Wochen erhält der Kunde die Software, welche bereits einen Teil der gewünschten Funktionalität abdeckt. Daraufhin hat der Kunde bereits die erste Möglichkeit das Projekt in die richtigen Bahnen einzulenken. Hierfür kann er bei der Sprint-Demo entsprechende Änderungswünsche eingeben und bereits selber mit der Software arbeiten.
Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
Wer in einem agilen Projekt gearbeitet hat, weiss, dass dies für beide Seiten intensiv ist. Gerade in meinem Bereich der individuellen Softwareentwicklung ist das auf der Seite des Kunden sogar sehr intensiv. Wir können meistens bereits früh erkennen, ob der Kunde die Zusammenarbeit ernst nimmt und seine Pflichten in dieser Vereinbarung auch wahrnimmt. So fällt das Projektgeschehen erfahrungsgemäss erfreulich und positiv aus. Leider ist es jedoch oft so, dass der Kunde die intensive Zusammenarbeit nicht ernst nimmt und daher entrüstet ist, dass die gelieferte Software nicht dem entspricht, was er sich gewünscht hatte. Dies endet dann traurigerweise mit den Vertragsverhandlungen, wo man nicht hingelangen möchte.
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Du kennst vielleicht den Ausdruck „Moving Target“? Bei dieser Entwicklung einer Software handelt es sich meist um solche Fälle. Das bedeutet, man weiss am Anfang noch nicht, was man eigentlich möchte. Während der Entwicklung des Projektes sollte sich dies aber immer klarer herauskristallisieren. Daher ist die vom agilen Manifesto vorgeschriebene Empfehlung logisch. Was hat es aber zur Folge, wenn die Änderungswünsche willkommen geheissen werden? In fast all meinen Projekten möchte der Kunde vor Projektbeginn einen genauen Kostenvoranschlag, ist dann aber erstaunt, wenn er für einen Änderungswunsch plötzlich wieder eine Offerte erhält. Uns werden dann böse Unterstellungen zugewiesen wie: „Ihr versucht uns, übers Ohr zu hauen“ oder mein Favorit: „Das ist doch logisch!?“
Wie du vielleicht jetzt erkennen kannst, ist die Entwicklung einer Idee alles andere als logisch. Auch wenn von Anfang an klar sein muss, was es kosten soll, können wir uns leider auch nicht anders vor Änderungen schützen, als jeweils wieder den Kunden zur Kasse zu bitten. Leider kennen wir hierfür auch kein Patentrezept. Für mich ist es ein Geben und Nehmen und ich finde, dass man miteinander offen und ehrlich über Budgetvorstellungen und Kosten sprechen soll, um einen Einklang zu finden.
Ich hoffe, dass ich dir einen kleinen Einblick in unser agiles Leuchter Manifesto bieten konnte und freue mich sehr auf Rückmeldungen, Kommentare und Inputs.
Falls du für die obenstehenden Herausforderungen eine Lösung hast, dann teile uns das gerne mit. 😉
Für agile Unterstützung bei einem individuellen Projekt, beraten wir dich auch sehr gerne persönlich, kostenlos und unverbindlich:
