Agile Manifesto: 4 Kernwerte & 12 Prinzipien erklärt

Das Bild unten stammt von der Agile Manifesto-Website und zeigt die vier Agile-Werte-Aussagen.

Agile Manifesto and the 4 Agile Values answer what agility is

Wie Sie im Vorwort zu den Werten sehen können, geben die Autoren an, dass sie bessere Wege zur Softwareentwicklung und zur Unterstützung anderer entdeckten. Alle Werte sind wichtig, aber die auf der linken Seite haben Vorrang vor denen auf der rechten Seite.

Individuen und Interaktionen über Prozesse und Werkzeuge

Wie bereits erwähnt, stellte das Agile Manifesto bei seiner Veröffentlichung herkömmliche, schwerfällige Methoden in Frage. Das Capability Maturity Model (CMM) und ITIL waren zu dieser Zeit beliebte Trends hin zu prozessorientierten Ansätzen.

Daher war es überraschend, dass diese Gedankengänger mit Menschen begannen. Sie glaubten, dass die Suche nach den richtigen Personen (Individuen) innerhalb eines Teams und die Unterstützung bei effektiver Zusammenarbeit (Interaktionen) weitaus wichtiger ist als die Einhaltung eines bestimmten Prozesses und/oder die Verwendung spezifischer Werkzeuge. Deshalb legten sie den Schwerpunkt auf die linke Seite: Individuen und Interaktionen.

Funktionsfähige Software über umfassende Dokumentation

Bei traditioneller oder Wasserfall-Softwareentwicklung würden Teams viel Zeit darauf verwenden, Anforderungen zu sammeln und Entwürfe sowie Spezifikationen zu erstellen, wobei erst am Ende des Lebenszyklus etwas Greifbares gebaut wurde. Die Autoren des Manifests glaubten, dass eine funktionierende Lösung wertvoller ist als eine große Menge an Dokumenten, die beschreiben, wie die Lösung funktioniert.

Kundenkollaboration über Vertragsverhandlungen

Der dritte Wert ist die Kundenkollaboration über Vertragsverhandlungen – wobei Vertragsverhandlungen bedeutet, über das im Umfang enthaltene zu streiten. Zum Beispiel könnte man Sätze wie „Das steht nicht in Ihrem Anforderungsdokument“ hören. Diese Gedankengänger glaubten, dass die Zusammenarbeit mit unseren Kunden, um die Lösung zu liefern, die sie wirklich brauchen, weitaus wichtiger ist.

Reagieren auf Veränderungen über das Folgen eines Plans

Der vierte und letzte Agile-Wert ist das Reagieren auf Veränderungen über das Folgen eines Plans. Die Autoren stimmen darin überein, dass Planung wichtig ist – tatsächlich machen Agile-Teams viel Planung. Doch diese Gedankengänger glaubten, dass die Fähigkeit, auf unvermeidbare Veränderungen zu reagieren, entscheidender ist als sich an einen Plan zu halten, der zu Beginn eines Projekts erstellt wurde, wenn die Informationen noch begrenzt waren.

Alle diese Werte im Manifest sind wichtig, aber die auf der linken Seite haben höhere Priorität als die auf der rechten Seite.

12 Agile-Prinzipien

Zusätzlich zu diesen 4 Agile-Werten stimmten die Autoren des Agile Manifests einer Reihe von 12 Agile-Prinzipien, die die Grundlage für agile Arbeitsweisen bilden. Obwohl sie weniger bekannt sind als die 4 Agile-Werte, finde ich die 12 Agile-Prinzipien praktischer und bieten klarere Anleitung für agile Praktiken.

12 Agile Principles behind the Agile Manifesto

Zur Bequemlichkeit habe ich die 12 Prinzipien nummeriert, obwohl sie auf der offiziellen Website.

  1. Das erste Prinzip ist die höchste Prioritätist es, den Kunden durch frühe und kontinuierliche Lieferung wertvoller Software zu befriedigen. Der Ausdruck „wertvolle Software“ verwirrt manche. Denken Sie daran, dass diese Gedankengänger im Jahr 2001 die Agile-Werte und -Prinzipien vorstellten und sich ausschließlich auf die Softwareentwicklung konzentrierten. Seitdem wurde Agile in nahezu allen Branchen übernommen – Architektur, Automobilproduktion, sogar die Herstellung von Kampfflugzeugen. Wenn es für Sie sinnvoller ist, ersetzen Sie „wertvolle Software“ durch „wertvolle Lösung“.
  2. Das zweite Prinzip ist es, willkommen Änderungen der Anforderungen, selbst am Ende der Entwicklung. Während die meisten Menschen heute darauf fokussiert sind, Veränderungen zu kontrollieren oder das „Scope Creep“ zu managen, ist die Realität, dass Veränderungen unvermeidlich sind. Agile Prozesse verschieben Entscheidungen, verkürzen Entwicklungszyklen und unterstützen eine zeitnahe Analyse von Anfragen. Dadurch können agile Teams schnell und kostengünstig anpassen. Dies bietet einen Wettbewerbsvorteil und ist eine der zentralen Säulen des agilen Arbeitens.
  3. Das dritte Prinzip ist es, regelmäßig funktionierende Software zu liefern, von einigen Wochen bis zu einigen Monaten, vorzugsweise mit kürzeren Zeitrahmen. Ein Hauptvorteil der häufigen Lieferung ist die Gewinnung von Feedback, um sicherzustellen, dass man auf dem richtigen Weg ist und tatsächlich das baut, was der Kunde braucht.
  4. Das vierte agile Prinzip handelt von Geschäftspersonen und Entwickler, die täglich zusammenarbeiten während des gesamten Projekts. Heute erstellen Geschäftspartner oft Anforderungsdokumente und „werfen sie über die Mauer“ an die Entwickler. Monate oder sogar Jahre später liefern die Entwickler die Lösung an den Anforderer zur endgültigen Prüfung – nur um festzustellen, dass die Lösung missverstanden wurde, falsch gebaut wurde oder gar nicht mehr benötigt wird. Der Fokus dieses Prinzips liegt auf der Zusammenarbeit zwischen denjenigen, die die Lösung bauen, und denjenigen, die sie nutzen, um solche Ergebnisse zu vermeiden.
  5. Das fünfte agile Prinzip ist es, Projekte um motivierte Personen aufzubauen, indem man ihnen die notwendige Umgebung und Unterstützung bietet und ihnen vertraut, die Aufgabe zu erledigen. Dies ist im Wesentlichen ein dreiteiliger Ansatz: Menschen zu befähigen, ihnen Autonomie zu geben und ihnen zu vertrauen.
  6. Das sechste agile Prinzip fördert nachhaltige Entwicklung. Sponsoren, Entwickler und Nutzer sollten in der Lage sein, einen konstanten Tempo unbegrenzt aufrechtzuerhalten. Als ich erstmals an Technikprojekten arbeitete, dauerten diese oft sechs Monate, zwölf Monate oder länger. Es war üblich, in den ersten zwei Monaten wenig zu erreichen. Dementsprechend führte dies zu massiven Stressphasen am Ende, bei denen riesige Arbeitsmengen abgeschlossen werden mussten. Teammitglieder wurden erwartet, Abende oder Wochenenden zu arbeiten, um feste Termine und feste Umfänge einzuhalten. Dies wird als „Todesmarsch“-Projekt bezeichnet. Agile sagt nicht, dass man nie abends oder am Wochenende arbeiten wird – aber es betont, dass jeder auf einer nachhaltigen Arbeitsgeschwindigkeit arbeiten sollte.
  7. Das siebte Prinzip ist, dass funktionierende Software die primäre Maßgröße für Fortschritt ist. Traditionell wurde der Prozentsatz der Fertigstellung verwendet, um den Projektfortschritt zu verfolgen. Der Prozentsatz der Fertigstellung ist äußerst unzuverlässig, da er schwer zu beurteilen ist, besonders wenn er 80 % oder 90 % erreicht. Eine 90 %ige Fertigstellung bedeutet oft nur noch 10 % der Arbeit oder Zeit. Agile-Teams vermeiden den Prozentsatz der Fertigstellung, indem sie die Arbeit in Funktionen oder Funktionalitäten aufteilen, diese in kleine Teile zerlegen und verfolgen, ob diese Teile abgeschlossen sind. Dieser Ansatz vermeidet irreführende Fortschrittskennzahlen.
  8. Das achte Prinzip besagt, dass die effektivste und effizienteste Art, Informationen an das Entwicklungsteam und innerhalb des Teams zu übermitteln, über Gespräch im persönlichen Kontakt. Heute könnte das beliebteste Kommunikationsmittel E-Mail sein. Es ist für den Absender effizient – schließlich kann man Nachrichten gleichzeitig an Hunderte oder Tausende senden. Aber es ist keine echte Kommunikation. Forschung zeigt, dass das Lesen von Texten anderer erheblichen Raum für Missverständnisse lässt. Agile-Befürworter haben gelernt, dass ein echtes gemeinsames Verständnis die Zusammenbringung von Menschen erfordert. Wenn persönlicher Kontakt nicht möglich ist, sollte man das Kommunikationsmittel mit der höchsten Bandbreite nutzen – das könnte ein Video- oder Telefonanruf sein. Das ist weitaus besser als das Hochladen von Dokumenten auf SharePoint! Die Schlussfolgerung hier ist, das Kommunikationsmittel mit der höchsten Bandbreite zu nutzen. Ein Nebeneffekt der Präferenz persönlicher Interaktion ist, dass es sinnvoll ist, Teammitglieder derselben agilen Gruppe zusammenzustellen. Heute ignorieren viele Organisationen diesen scheinbar offensichtlichen Punkt.
  9. Das neunte Prinzip ist die kontinuierliche Fokussierung auf technische Exzellenz und gute Gestaltung um Agilität zu steigern. Der Fokus liegt darauf, Abkürzungen oder technische Schulden zu vermeiden. Mach nichts, das kurzfristig schneller macht, aber langfristig mehr kostet. Wenn du technische Schulden weiterhin anhäufst, wirst du an Agilität verlieren. Das ist bei Wasserfallprojekten mit festen Zeitplänen üblich. Um versprochene Termine einzuhalten, werden Kompromisse eingegangen. Testzyklen können reduziert oder ganz gestrichen werden, um Zeit zu sparen, was zu mehr Problemen in der Produktion nach dem Launch führt. Dies führt zu Feuerwehrarbeit und Code, der schwer zu pflegen ist.
  10. Das zehnte Prinzip handelt von der Vereinfachung und der Beseitigung unnötiger Arbeit. Einfachheit – die Kunst, die Menge der nicht erledigten Arbeit zu maximieren – ist entscheidend.Das heißt, wir sollten unsere Prozesse überprüfen und alles beseitigen, was dem Kunden keinen Wert bringt, wodurch die Menge der noch nicht abgeschlossenen Arbeit maximiert wird, ohne dabei das zu liefern, was benötigt wird.
  11. Das zehnte Prinzip bezieht sich auch auf selbstorganisierte Teams. Die besten Architekturen, Anforderungen und Designs entstehen aus selbstorganisierten Teams. Wir sollten denjenigen, die am nächsten an der Arbeit sind, erlauben, selbst zu entscheiden, wie sie sie am besten erledigen – das ist die Essenz dieses Prinzips.
  12. Das letzte Prinzip, Nummer 12, handelt von Retrospektiven. Teams reflektieren regelmäßig darüber, wie sie effektiver werden können, und dann anpassen und anpassenihres Verhaltens entsprechend.

Agile-Werte und -Prinzipien erscheinen heute möglicherweise nicht radikal, aber als sie 2001 bekanntgegeben wurden, waren sie durchaus revolutionär. Daher der Begriff „Manifest“. Sie skizzierten eine Arbeitsweise, die völlig anders war als die, wie Organisationen im vorherigen Jahrhundert operiert hatten. Davor spiegelte die Softwareentwicklung weitgehend die Arbeitspraktiken der Industrieära wider. Das Verständnis dieses historischen Kontexts ist entscheidend, wie im Folgenden erläutert wird.

 

 

Kommentar hinterlassen