Das Manifest der Agilen Softwareentwicklung

Die 12 Prinzipien hinter dem Agilen Manifest

Neben den vier Wortpaaren des Manifests haben dessen Autoren auch zwölf weiterführende Prinzipien verfasst. Sie liefern eingehendere Hilfestellungen und Empfehlungen für verschiedene Situationen.

Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.

Im Gegensatz zum klassischen Vorgehen, in dem häufig nur wenige Male (oder auch nur einmalig) gegen Ende des Projekts große Teile des Ergebnisses ausgeliefert werden, setzt der agile Ansatz darauf, bereits sehr früh und ab da kontinuierlich Arbeitsstände zu liefern, die dem Kunden bereits einen Mehrwert bieten. Gerade in der Softwareentwicklung geschieht es häufig, dass der Anwender erst im direkten Kontakt mit dem System feststellen kann ob dieses tatsächlich seine Anforderungen bzw. seine Arbeitsweise unterstützt.

Heiße Anforderungsänderungen selbst spät
in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen
zum Wettbewerbsvorteil des Kunden.

Durch das kontinuierliche Reagieren auf Anforderungsänderungen wird auch das Risiko von „disruptiven“ Anforderungen minimiert, also neue bzw. geänderte Anforderungen, die derart umfangreich sind, dass sie umfassende Änderungen am Gesamtsystem nach sich ziehen. Dadurch ist es i.d.R. auch zu einem fortgeschrittenen Zeitpunkt innerhalb des Projekts noch möglich, auf geänderte Wünsche des Kunden zu reagieren, was es ihm zudem auch ermöglicht, seinerseits deutlich flexibler zu agieren.

Liefere funktionierende Software
regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne.

Dieses Prinzip fordert ein iteratives Vorgehen ein und ermutigt dazu, die Dauer dieser Iterationen so kurz wie möglich zu halten. Werden diese Zeiträume zu lang, steigt das Risiko, dass sich bereits während der Entwicklung Anforderungen ändern. Folglich steigen erfahrungsgemäß auch die Planungs- und/oder Abstimmungsaufwände während der Entwicklungsphase.

Fachexperten und Entwickler
arbeiten während des Projektes
täglich zusammen.

Die Idee hierbei ist es, das Verständnis dieser beiden Gruppen füreinander zu stärken. Anstatt nur „blind“ Anforderungen aus einem Pflichtenheft umzusetzen (Stichwort „Code monkey“) ist der Entwickler angehalten, den direkten Kontakt mit seinem  Kunden oder idealerweise sogar dem Anwender zu suchen, um dessen Arbeitsweise besser nachvollziehen und folglich auch besser in der Software abbilden zu können. Gleichzeitig lernt der Fachexperte die Denk- und Arbeitsweise des Entwicklers kennen, was ihm wiederum in der Formulierung seiner künftigen Anforderungen hilft bzw. sogar dazu beitragen kann, effektivere Lösungen für seine Probleme zu erkennen.

Errichte Projekte rund um motivierte Individuen.
Gib ihnen das Umfeld und die Unterstützung, die sie benötigen
und vertraue darauf, dass sie die Aufgabe erledigen.

Das ist das umfangreichste der 12 Prinzipien, verbergen sich hier doch drei wesentliche Punkte:

Motivierte Individuen: Meiner persönlichen Erfahrung nach trifft es tatsächlich zu, dass eine agile Arbeitsweise zu einer deutlich höheren Motivation bei allen Beteiligten führen kann. Sobald die Teammitglieder einmal die Erfahrung gemacht haben, direkt auf Anforderungen und deren Umsetzung einwirken zu können bzw. sich nun nicht mehr auf eine langfristige Planung eines Anderen (z.B. Projektleiter, Vorgesetzter o.ä.) commiten zu müssen sondern sich selbst konkrete und kurzfristige Ziele zu setzen, öffnet dies ein oft ungenutztes Potential. Darüber hinaus fördert es auch das kundenorientierte sowie unternehmerische Denken der ehemals reinen Ausführenden.

Das Umfeld und die Unterstützung: Zusammenfassen ließe sich dies unter dem englischen Begriff „servant leadership“. Das Team bekommt selbst die Freiheit, sich, seine Arbeit und Prozesse zu organisieren. Dennoch wird es früher oder später zwangsläufig auf Hindernisse stoßen. Angefangen bei der kaputten Kaffeemaschine bis hin zur eingeschobenen top-prio Anforderung des Managements. Damit solche Störungen keine negativen Auswirkungen auf die selbst gesteckten Ziele des Teams haben können ist es sinnvoll, diese so weit wie möglich zu vermeiden. In Scrum ist dies z.B. eine der Hauptaufgaben des Scrum-Masters.

Vertrauen: Einer der wichtigsten Punkte für agiles Vorgehen überhaupt. Dies betrifft das Team, aber auch das Management und zwar jeweils sowohl beim Dienstleister, als auch beim Kunden. Dadurch, dass der genaue Umfang zum Start des Projekts noch nicht feststeht erfordert es das Vertrauen auf Seiten des Managements des Kunden dahingehend, dass die eigenen Fachexperten in der Lage sind, im Laufe der Entwicklung selbst die richtigen Anforderungen zu definieren um schlussendlich einen Mehrwert erzielen zu können. Zwischen den Fachexperten sowie dem Entwicklungsteam benötigt es das gegenseitige Vertrauen, gemeinsam die besten Lösungen für die bestehenden Anforderungen zu finden. Das Management des Dienstleisters wiederum muss dem eigentlichen Umsetzungs-Team dahingehend vertrauen können, dass es sich selbst und seine Arbeit stets optimal organisiert.

Die effizienteste und effektivste Methode, Informationen
an und innerhalb eines Entwicklungsteams zu übermitteln,
ist im Gespräch von Angesicht zu Angesicht.

Ich glaube dieser Punkt ist nicht nur selbsterklärend sondern auch selbstverständlich.

Funktionierende Software ist das
wichtigste Fortschrittsmaß.

Wichtig ist, was am Ende jeder Iteration geliefert wird und, dass dies zum Mehrwert des Kunden beiträgt. Es gibt zwar auch im agilen Umfeld Möglichkeiten, über größere Zeiträume hinweg zu planen, der Fokus liegt aber vor allem auf den aktuellen bzw. unmittelbar bevorstehenden Anforderungen und daher auch auf einer strikten Priorisierung der Aufgaben. Um eine gute Priorisierung zu gewährleisten werden anhand der ausgelieferten Arbeitsergebnisse Praxiserfahrungen gesammelt und der Erfolg, wo immer möglich quantifiziert.

Agile Prozesse fördern nachhaltige Entwicklung.
Die Auftraggeber, Entwickler und Benutzer sollten ein
gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Auch hier verbergen sich zwei relevante Aussagen:

Synchrones Arbeiten bei allen Beteiligten: Durch das Arbeiten in Iterationen wird es erforderlich bzw. überhaupt erst möglich, bei allen Beteiligten eine synchrone Arbeitsweise zu etablieren. Durch die Regelmäßigkeit mit der zum Beispiel Planungs- oder Release-Phasen in festen Abständen konzentriert stattfinden wird es für alle Beteiligten einfacher, sich die entsprechenden Termine vorzumerken und die Zusammenarbeit zu bündeln.

Das Tempo unbegrenzt halten zu können bedeutet im Wesentlichen den Versuch, „Crunch-Zeiten“ so weit möglich zu vermeiden. In den Umfeldern, in denen agiles Arbeiten Sinn ergibt findet sich meist auch eine Arbeitsweise, die ein gewisses Maß an Kreativität erfordert. Solche Tätigkeiten können zeitlich nicht beliebig ausgedehnt werden ohne Gefahr zu laufen, signifikant an Qualität einzubüßen. Natürlich kann es auch im agilen Umfeld zu Situationen kommen, wo zur Erreichung eines Iterations-Ziels Mehrarbeit geleistet werden muss, da sich das Team entweder verschätzt hat oder unvorhergesehene Einflüsse eingetreten sind. Dennoch hat das Team in der nächsten Iteration die Möglichkeit, die so erlangten Erkenntnisse in einen ggf. verringerten Iterations-Umfang einfließen zu lassen. Es wird also versucht, die verfügbare Zeit so effektiv wie möglich zu nutzen und somit die Notwendigkeit für Mehrarbeiten zu reduzieren.

Ständiges Augenmerk auf technische Exzellenz und
gutes Design fördert Agilität.

Auch wenn dieser Leitsatz auf den ersten Blick eher technisch anmutet, betrifft dies meiner Erfahrung nach auch die Geisteshaltung eines jeden Einzelnen seiner eigenen Arbeitsweise gegenüber. Das kann z.B. heißen, sich permanent selbst weiter zu bilden und sich dadurch auch persönlich weiter zu entwickeln. Damit verbunden ist ein hoher Qualitätsanspruch an sich selbst und seine Arbeitsergebnisse.

Einfachheit — die Kunst, die Menge nicht
getaner Arbeit zu maximieren — ist essenziell.

Nach dem vorhergehenden Punkt bzgl. der technischen Exzellenz klingt dieser Leitsatz nun beinahe wie eine Einschränkung. Tatsächlich bezieht er sich allerdings eher auf das Pareto-Prinzip. Dieses besagt, dass sich 80% des Gesamtaufwands in 20% der zur Verfügung stehenden Zeit umsetzen lassen. Die restlichen 80% der Zeit werden danach für Umsetzung der verbleibenden 20% der Anforderungen benötigt.

Im agilen Umfeld wird stets versucht, den maximal möglichen Mehrwert mit dem minimal nötigen Aufwand zu generieren und somit die zur Verfügung stehende Zeit so effektiv wie möglich zu nutzen.

Neben diesem gewichtigen Argument ist hier allerdings auch ein technischer Aspekt betroffen: Nicht nur als Softwareentwickler sondern auch als Fachexperte ist man häufig versucht, Lösungen so allgemein gültig und offen wie irgend möglich zu halten, um etwaige zukünftige Anforderungen einfacher umsetzen zu können. In der Praxis führt dies allerdings zu sehr komplexen und zunehmend schwerer wartbaren Systemen, während die Funktionalitäten für die man vorbereitet sein wollte nur selten tatsächlich angefordert werden. Daher versucht man im agilen Umfeld Anforderungen mit einem möglichst geringen Aufwand zu realisieren und entsprechend größere Lösungen erst dann umzusetzen, wenn diese tatsächlich aufgrund neuer Anforderungen unumgänglich werden.

Die besten Architekturen, Anforderungen und Entwürfe
entstehen durch selbstorganisierte Teams.

Um dies zu erreichen versucht man im Team alle Personen zu vereinen, die zur Erreichung des Ziels notwendig sind. Neben der Vermeidung von überflüssigen Abstimmungen mit anderen Teams eröffnet sich damit auch die Chance alle nötigen Arbeiten innerhalb des Teams abbilden zu können. Je stabiler die Team-Zusammensetzung ist desto eingespielter, effektiver, aber vor allem auch eigenständiger kann sich die Arbeit des Teams gestalten.

In regelmäßigen Abständen reflektiert das Team,
wie es effektiver werden kann und passt sein
Verhalten entsprechend an.

Neben der Arbeit in Iterationen ist dies meiner Meinung nach die zweite Säule agiler Arbeitsweise. Jeder Aspekt der Zusammenarbeit unterliegt einem permanenten Kontroll- und Verbesserungs-Prozess und wird an die aktuellen Gegebenheiten und Erkenntnisse angepasst. In der Praxis geschieht dies im Rahmen der sogenannten Retrospektive. In diesem Termin wird nicht das Arbeitsergebnis sondern die Prozesse, die zu diesem geführt haben betrachtet, bewertet und ggf. angepasst mit dem Ziel, zukünftig noch effektiver arbeiten zu können. Dabei liegt der Fokus eher auf wenigen (z.B. maximal drei) konkreten Ableitungen für die weitere Zusammenarbeit. Dadurch und durch die Regelmäßigkeit dieses Termins steigt auch die Nachhaltig- und somit die Wirksamkeit der vereinbarten Änderungen enorm.

Fazit

Ich hoffe, ich konnte Ihnen mit diesem Artikel das Manifest der Agilen Softwareentwicklung und dadurch auch die agile Denkweise etwas greif- und begreifbarer machen. Man muss nicht erst zu 100% nach Scrum arbeiten oder einen vollständig skalierten Agilen Prozess in seinem gesamten Unternehmen etabliert haben, um „agil“ zu sein. Es geht viel mehr darum, die Kernideen dieser Denkweise zu verinnerlichen und, wo immer möglich und vor allem auch nötig, in seine eigene Arbeit einfließen zu lassen.