Auch wenn Dee V. Lopment nun seine vorlesungsfreie Zeit nutzen kann, ist er gedanklich noch längst nicht im Urlaubsmodus. Er macht sich immer noch Gedanken über ein Projekt, in dem er dem CONNAMIX-Team bereitwillig zur Seite steht.
Da der Informatikstudent sowohl für die Uni als auch für CONNAMIX mit dem Thema der agilen Softwareentwicklung zu tun hat, überlegt er, die Ferien tatsächlich zum Lernen zu nutzen. Übereifrig greift er nach seinem Laptop und öffnet die Vorlesungsfolien, die Prof. Agiel bereits für die nächsten Wochen hochgeladen hat. Nachdem Dee die Dokumente mitsamt der Sekundärliteratur als PDF auf seinem Desktop gespeichert hat, bereut er seine Entscheidung sofort. Stöhnend sieht er auf die Seitenzahl der ersten Sekundärliteratur.
„Manifest für Agile Softwareentwicklung. Das ist kein Manifest, sondern die ganze Sammlung von Brockhaus …“ schimpft er vor sich hin in den leeren Raum. „Na gut… was soll’s.“, schulterzuckend macht er es sich bequem und fängt an zu lesen:
Manifest für agile Softwareentwicklung
Das agile Manifest beschreibt Verhaltensregeln und Werte agiler Teams und ist einer der wesentlichen Meilensteine der modernen agilen Bewegung.
Doch wie setzt man agile Prinzipien für die Entwicklung von Teams und Unternehmen ein?
Softwareentwicklung als Referenzmodell
Trotzdem oder gerade wegen seines Ursprungs in der Softwareentwicklung bietet das agile Manifest auch eine Referenz für die Kooperation von agilen Teams in weiteren Kontexten – ganz getreu dem Motto »wenn es in der Softwareentwicklung funktioniert, dann funktioniert’s überall«.
Schließlich haben Softwareprojekte eine hohe Komplexität, die technologische Entwicklung verläuft sehr dynamisch: es bedarf vieler unterschiedlicher Kompetenzen und grade als Softwareentwickler gilt die Erfassung von Kundenbedürfnissen als eine der obersten Prioritäten. Es ist also nicht verwunderlich, dass agile Prinzipien in einer Industrie geboren wurden, die schon vor über 20 Jahren an die Grenzen linearer Wasserfall-Modelle gestoßen sind.
Erstunterzeichner des agilen Manifests
Das Manifest wurde von 17 nennenswerten Personen erstunterzeichnet:
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
„HA! 2 von denen sagen mir sogar was!“; freut sich Dee V. Lopment, „Ken Schwaber und Jeff Sutherland sind die Begründer des SCRUM Frameworks. Das hat mir mein Chef, also Ugur Özkeser, erst neulich erklärt.“
Vier Leitsätze für Agilität
Das Fundament des agilen Manifests bilden 4 kurze und stichhaltige Leitsätze. Zur Verdeutlichung seiner Kernaussagen greift das agile Manifest dabei auf eine Gegenüberstellung zurück. Agile Werte werden durch die Abgrenzung zu herkömmlichen und traditionellen Vorgehensmodellen deutlich hervorgehoben.
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.
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.
Im Manifest gibt’s Agilität in 4 Leitsätzen
Mittlerweile hat der Informatikstudent die Sekundärliteratur grob überflogen (man muss ja schließlich nicht übertreiben!) und sitzt nun mit einer Tasse heißer Schokolade an seinem Schreibtisch, wo er die Folien von Prof. Agiel zum Manifest aufmerksam durchgeht, auf denen die 4 Leitsätze ausführlich beschrieben werden:
1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
Der Mensch (egal ob Team, Mitarbeiter oder Kunden) steht im Fokus und der direkte Austausch ist von größerer Wichtigkeit als Formalismen. Das heißt, kein noch so ausgefeilter und gut dokumentierter Prozess ersetzt ein persönliches Gespräch. Welche Bedeutung der persönliche Austausch für agile Teams hat, zeigt auch die Forderung, dass ein Team räumlich möglichst eng zusammensitzt. Durch die räumliche Nähe wird die osmotische Kommunikation gefördert.
2. Funktionierende Software ist wichtiger als umfassende Dokumentation
Konkrete Arbeitsergebnisse statt zweideutiger PowerPoint. Dieser Leitsatz bringt die hohe Wert- und Ergebnis-Fokussierung agiler Teams zum Ausdruck. Für einen Agilisten ist es wichtiger, eine Aufgabe oder Teilaspekt zu erledigen, als sich nur mit einer Dokumentation oder einer Präsentation aufzuhalten. Gerade in großen Organisationen mit klassischer Projektkultur wird häufig mehr Zeit in die Erstellung von PowerPoint Präsentationen für Lenkungsausschüsse als in das Erledigen der eigentlichen Aufgabe gesteckt.
3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
Der Kunde ist zentraler Teil in der Arbeit agiler Teams. Er ist Part des Prozesses und stellt mit seinen Bedürfnissen und Problemen sogar eine wichtige Bereicherung für das Team dar. Eine (persönliche) Auseinandersetzung mit dem Kunden ist dabei wichtiger als ein formaler Vertrag. Auch mit diesem Punkt stellt das agile Manifest den direkten Austausch über Formalien.
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
Schließlich sind agile Teams sehr adaptiv und verlangen von sich eine hohe Anpassungsfähigkeit. Allerdings bedeutet das nicht, dass agile Teams keinen Plan haben und willkürlich, sprunghaft oder gar chaotisch arbeiten. Agile Teams sind auf ein Ziel fokussiert, weichen aber auch gerne vom eigentlichen Plan ab, wenn es für das Team, die Organisation und den Kunden sinnvoll ist und es Aussicht auf einen höheren Wertbeitrag gibt.
Ausblick auf den nächsten Teil:
Grade als Dee V.Lopment sich nach einer Ausrede suchend im Zimmer umsah, um nicht weiter lernen zu müssen, klingelte sein Handy und der Bildschirm zeigte an: Ugur Özkeser, CEO CONNAMIX.
„Hallo Dee. Na, ich hoffe, du hattest schöne Weihnachtsfeiertage? Du hör mal, wenn du nächste Woche kommst, hätte ich eine neue Aufgabe für dich. Kannst du bitte eine Präsentation erstellen bzgl. Agilität durch Digitalisierung im Unternehmen und wie diese erreicht werden kann? Ganz allgemein gehalten, noch nicht auf Softwareentwicklung bezogen. Danke dir. Wir sehen uns. Bis dann, Ciao.“