Agile Prinzipien – das «Agile Manifest»
Im Februar 2001 trafen sich in den Wasatch-Bergen des amerikanischen Bundesstaates Utah in einer Ski-Lodge 17 Menschen, um gemeinsam zu reden, Ski zu fahren und zu entspannen. Sie alle waren mit der Art und Weise, wie Software-Entwicklung stattfand, nicht zufrieden und glaubten, dass Alternativen zu dokumentationsträchtigen, schwergewichtigen Software-Entwicklungsprozessen notwendig seien. Dies war die Geburtsstunde der agilen Prinzipien in Scrum.
Diese Gruppe organisatorischer Anarchisten, die sich «The Agile Alliance» nannten, formulierten und unterschrieben gemeinsam das «Agile Manifest». Dabei ist zu beachten, dass die anwesenden Personen später ganz unterschiedliche Wege gegangen sind und unterschiedliche Methoden und Frameworks basierend auf der gemeinsamen Grundlage «Agiles Manifest» entwickelt haben. (Mit-)Entwickler von «Extreme Programming», «Scrum», «DSDM», «Adaptive Software Development», «Crystal» und anderen legten hier einen gemeinsamen Grundstein für die weitere Entwicklung von Software-Entwicklung und in vielen Fällen auch für weit über die Software-Entwicklung hinausgehende Fragestellungen.
Manifest für agile Softwareentwicklung
Wir erschliessen 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 heisst, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.
In kurzen Worten beschreibt das Manifest damit die Grundlagen agilen Denkens.
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Das Befolgen von Prozessen und der richtige Einsatz von Werkzeugen ist zweifellos ein zentraler Erfolgsfaktor für die Durchführung erfolgreicher Entwicklungsprozesse. Trotzdem stellt ihnen das agile Manifest zu Recht «Individuen und Interaktionen» voran. Nur Individuen sind in der Lage, sich permanent weiterzuentwickeln und damit eine stetige Verbesserung des Entwicklungsprozesses und der entwickelten Produkte zu erzielen. Die Interaktion zwischen Individuen bietet zusätzliches Potential, dass aus der Arbeit eines Teams mehr wird als die Summe der Einzelleistungen. Andererseits kann ein Team nur dann optimal wirken, wenn jedes Teammitglied auch als Individuum mit Stärken, Schwächen und eigener Persönlichkeit wahrgenommen und als solches einbezogen wird.
Funktionierende Software mehr als umfassende Dokumentation
Das Festhalten von Anforderungen im Vorfeld sowie die Dokumentation der umgesetzten Resultate sind eine Grundlage für die Verständigung über Produktinhalte und die Grundlage für erfolgreiche Wartung und Weiterentwicklung. Gelingt es aber nicht, ein funktionierendes Software-Produkt zu erstellen, ist ihr Nutzen sehr begrenzt.
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Verträge und Vereinbarungen zwischen Kunden und Herstellern sind von grosser Bedeutung. Sie bilden eine wichtige Basis dafür, sicherzustellen, dass alle Beteiligten einen Auftrag gleich verstehen. Trotzdem können Verträge nicht jedes mögliche Szenario detailliert abbilden und jedes mögliche Ereignis vorwegnehmen. Sie entstehen basierend auf dem Kenntnisstand zu einem bestimmten Zeitpunkt. Im Verlauf eines Projektes entwickeln sich aber sowohl Kunde als auch Lieferant weiter. Das verfügbare Wissen zum gemeinsamen Projekt nimmt zu und auch Rahmenbedingungen verändern sich. Um dieser Entwicklung im Rahmen des Projektes Rechnung zu tragen, ist eine gute und intensive Zusammenarbeit mit dem Kunden unabdingbare Voraussetzung.
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Pläne sind wichtig und die Vorstellung, dass agile Vorgehensweisen, wie beispielsweise Scrum, ohne Pläne auskommen würden, ist absurd. Man könnte sogar sagen, dass bei agilen Techniken weit mehr geplant wird. Hauptunterschied ist, dass Planung in agilem Umfeld nicht primär zu (oder vor) Projektbeginn stattfindet, sondern laufend und dies immer mit einem «Just in Time»-Approach. Es macht keinen Sinn, auf Monate und Jahre hinaus detaillierte Pläne zu erstellen, wenn man das Feedback des Kunden und das Reagieren darauf als Grundlage für die Ermöglichung einer maximal wertschöpfenden Entwicklung begreift.
Die zwölf agilen Prinzipien
Erstes Prinzip: «Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.»
Die Zufriedenheit des Kunden ist unsere höchste Priorität. Durch wertbasierte Priorisierung in Kombination mit der Auslieferung umgesetzter Lösungsteile schon während des Entwicklungsprozesses schaffen wir nicht nur frühzeitig die Möglichkeit für ein tiefer greifendes Kundenfeedback, sondern tragen auch dabei, dass der Kunde wenn möglich schon vor Projektabschluss Nutzen realisieren kann.
Zweites Prinzip: «Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.»
Während in komplett durchgeplanten Projekten jede Änderung eine Störung bedeutet, welche womöglich dazu führt, dass Wochen und Monate intensiver Planungs- und Koordinationsarbeit neu erstellt werden müssen, sind neue und angepasste Anforderungen in agiler Entwicklung nicht nur von vornherein mit eingeplant, sondern auch bewusst gewollt. Während der Entwicklung eines Produktes lernt sowohl der Auftraggeber als auch der Auftragnehmer laufend mehr über das zu entwickelnde Produkt. Die Resultate dieses Lernprozesses sollen nicht erst in einem möglichen Folgeprojekt oder mittels späterer Anpassung (nach Auslieferung) realisiert werden, sondern so früh wie möglich in die Entwicklung einfließen. Das kann heißen, dass bereits vorgesehene Funktionalität angepasst oder sogar weggelassen werden muss oder dass vollkommen neue Anforderungen plötzlich höchste Priorität geniessen. Nur so sind wir in der Lage, unserem Kunden baldmöglichst einen größtmöglichen Nutzen zu ermöglichen.
Drittes Prinzip: «Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.»
Agile Entwicklung geschieht als gemeinschaftliche Leistung von Auftragnehmer und Auftraggeber. Während der Auftragnehmer seine Entwicklungsressourcen einbringt, bringt der Auftraggeber sein fachliches Know-how und seine Kenntnis der existierenden oder künftig gewünschten Prozesse ein. Diese gemeinsame Entwicklung kann dann besonders erfolgreich sein, wenn eine häufige und fundierte Kommunikation stattfindet. Diese wird durch häufige Auslieferung und das daraus entstehende Feedback gefördert. Sie gibt dem Entwickler die Möglichkeit, sicherzustellen, dass sich sein Produkt in die richtige Richtung entwickelt, und bietet dem Auftraggeber die Zuversicht, dass das erstellte Produkt seinen Anforderungen entspricht.
Viertes Prinzip: «Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.»
Agile Software-Entwicklung ist vom laufenden Austausch von Fachexperten und Entwickler geprägt. Dieser beschränkt sich nicht auf den Projektbeginn in der Anforderungsdefinition und zu Projektende in der Lösung-Abnahme, wie das bei herkömmlichem Projektvorgehen oft der Fall ist. Die Zusammenarbeit findet laufend statt, sei es bei der Definition von Anforderungen und den entsprechenden Akzeptanzkriterien oder dann im Feedback bei Iterationsende. Auch dazwischen ist die Einbindung zur Klärung von Fragen und Anforderungen wichtig.
Fünftes Prinzip: «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.»
Agile Software-Entwicklung kann nicht erfolgreich sein, wenn sie von unmotivierten Menschen durchgeführt wird, welche Anforderungslisten abarbeiten. Vielmehr ist wichtig, dass die Entwickler einen Sinn und Nutzen in ihrer Arbeit sehen und den Wunsch haben, etwas Nützliches zu produzieren. Nur so kann auch sichergestellt werden, dass optimaler Kundennutzen realisiert wird.
Sechstes Prinzip: «Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.»
Kennen Sie die Unsitte, innerhalb von Teams durch E-Mails mit dem ganzen Team als Verteiler zu kommunizieren? Jeder liest irgendwie mit und jeder hat die Vorstellung, dass er selbst eigentlich nicht gemeint sei. Die Kommunikationswissenschaften haben längst belegt, dass der reine Wortlaut nur einen minimalen Teil der Gesamtkommunikation ausmachen. Mimik/ Gestik, aber auch Betonung tragen einen weit grösseren Teil zur Kommunikation und Verständigung bei. Kommunikation von Angesicht zu Angesicht bietet viele Vorteile: Nutzen aller Sinne in der Kommunikation (Wie hat er/sie das gemeint?), die Möglichkeit, direkt zurückzufragen, Informationen kommen beim richtigen Adressaten an.
Siebtes Prinzip: «Funktionierende Software ist das wichtigste Fortschrittsmass.»
Eine zu 99% realisierte Lösung ist immer noch nicht fertig und wahrscheinlich auch so nicht nutzbar. Ohne tiefgreifende Analyse ist es kaum möglich, zu sagen, ob Software nun zu 90 % oder 70% umgesetzt sei – und selbst wenn. Welchen Nutzen – man könnte auch fragen «welchen Wert» – hat diese Lösung für den Kunden? Nur fertiggestellte, funktionierende Software bietet den angestrebten Nutzen. Was am Ende einer Iteration nicht den Anforderungen an die fertiggestellte Software (Akzeptanzkriterien, Definition of «Done») entspricht, fällt zurück in den Arbeitsvorrat (Product Backlog) und kann in einer späteren Iteration umgesetzt werden.
Achtes Prinzip: «Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.»
Software-Entwicklung findet gerade vor Abgabeterminen oft am Limit körperlicher und geistiger Belastungsgrenzen der Entwickler statt. Das kann nicht nur zu gesundheitlichen Einschränkungen führen, sondern ist oft auch Fehlerursache und mangelnde Mitarbeitermotivation. Wenn das Entwicklerteam in einem gleichmäßigen Tempo arbeiten kann, hat dies nicht nur einen positiven Einfluss auf die langfristige Mitarbeiterzufriedenheit und -leistungsbereitschaft, sondern auch auf die Qualität der erstellten Produkte.
Neuntes Prinzip: «Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.»
Der Verzicht auf ausgedehntes Design vor Umsetzungsbeginn bedeutet nicht, dass kein Wert auf solides Softwaredesign und hohe Qualität gelegt werden würde. Anders als bei herkömmlichen Herangehensweisen entwickelt sich beides nur im Verlauf der Entwicklung mit den Anforderungen. Dies muss von Anfang an mitberücksichtigt werden. Nur so kann sichergestellt werden, dass es durch Beschränkungen der gewählten Software-Architektur im Verlauf des Projektes zu Sachzwängen kommt, die ein Umsetzen von Kundenfeedback erschweren oder gar verunmöglichen.
Zehntes Prinzip: «Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.»
Ziel agiler Software-Entwicklung ist nicht die Entwicklung eines möglichst großen Funktionsumfanges innerhalb geringer Zeit oder Kosten. Zentrales Ziel ist es vielmehr, mit möglichst geringem Entwicklungsaufwand und möglichst wenig entwickelter Software eine möglichst grosse Wertschöpfung für den Kunden zu erreichen. Dies ist nur dann zu erzielen, wenn eine klare Vorstellung besteht, welche Anforderungen welche Wertschöpfung für das Unternehmen ergeben. Darauf basierend werden Anforderungen priorisiert und dementsprechend umgesetzt (oder nicht).
Elftes Prinzip: «Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbst organisierte Teams.»
Wenn ein erfahrenes Team von Entwicklern zusammenkommt, kann davon ausgegangen werden, dass diese gemeinsam ein höheres Maß an Erfahrung und Kenntnissen haben als dies ein Einzelner hat. Es ist entsprechend sinnvoll, diesem Team die notwendige Freiheit zu geben für ihr Entwicklungsprojekt, d.h. eine möglichst große Freiheit in Bezug auf die Vorgehensweise und den Aufbau der Umsetzung, soweit dies den Nutzen für den Kunden unterstützt oder optimiert.
Zwölftes Prinzip: «In regelmässigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.»
Kontinuierliche Verbesserung ist zentrales Anliegen agiler Software-Entwicklung. Dies betrifft nicht nur das erstellte Produkt, sondern auch die Arbeitsweise und Zusammenarbeit des Teams. Entsprechend wichtig ist es, dass sich das Team regelmässig mit dem Entwicklungsprozess und der Kooperation im Team auseinandersetzt und gemeinsam nach Wegen sucht, sich zu verbessern. Das kommt sowohl dem Team selbst als auch den vom Team erbrachten Leistungen zugute.
