Ich kann mich noch gut erinnern – Ich habe letztes Jahr in einer Diskussion mit einem meiner Studenten von der Beuth-Hochschule in Berlin, bei der ich eine Lehrveranstaltung betreue, folgendes Statement gehört:

“Scrum wurde doch nur vom Management entwickelt, damit die Teams stärker unter Druck gesetzt werden können.” Der Student, der das gesagt hat, arbeitet neben seinem Studium als Entwickler in einer Firma. Obwohl das agile Manifest doch schon so alt ist und eigentlich bekannt sein sollte, scheint diese Firma sich bisher nicht darum gekümmert zu haben. Schade für den Studenten, ich bin sicher und hoffe natürlich, dass er in seinen weiteren Jobs bei Firmen arbeiten kann, die ein agileres Mindset an den Tag legen…und er damit den Frust, den das Thema “agil” bei ihm ausgelöst hat, wieder abbauen kann.

Ich nehme das mal zum Anlass um eine Folge über das agile Manifest zu machen – obwohl ich auch hier denke, dass Dir das höchstwahrscheinlich bereits bestens bekannt ist. Trotzdem ist bekanntlich Wiederholung die Mutter des Studierens und ich lade Dich ein einfach nochmal ein,  ganz entspannt zuzuhören. Falls Dir das agile Manifest noch nichts sagt, wird es hoffentlich um so spannender:

Am 11.-13. Februar 2001 also fast vor 20 Jahren,  trafen sich in der Cliff-Lodge im Snowbird-Skigebiet in Utah, USA, siebzehn Menschen –  Vertreter verschiedener damals existierender agiler Strömungen, wie „XP-Extreme Programming“, SCRUM, DSDM (Driving Strategy Delivering More), Adaptive Software Entwicklung, Crystal, Feature-Driven Development, Pragmatic Programming und andere. Sie waren sich einig eine Alternative zu den vorherrschenden dokumentationsgetriebenen, schwergewichtigen Software-Entwicklungsprozessen zu finden. Was entstand, war das Agile ‚Software Development‘ Manifest mit folgendem gemeinsam unterzeichneten Wortlaut:

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.

Das agile Manifest besteht nur aus 4 Sätzen und die besagen also folgendes:

  1. Wir wollen lieber miteinander sprechen und interagieren als stur den vorgegebenen Prozessen zu folgen und alte Werkzeuge zu benutzen, weil wir das schon immer so gemacht haben.
  2. Wir wollen uns lieber darum kümmern die Software fehlerfrei auszuliefern als eine umfassende Dokumentation anzulegen, die erstens sowieso niemand vollständig liest und die zweitens ab dem nächsten Release schon wieder veraltet sein wird.
  3. Wir wollen lieber mit dem Kunden zusammenarbeiten und auf seine Wünsche eingehen, als misstrauisch alles in einem von Rechtsanwälten verfassten Vertragsdokument festzuhalten und später vor Gericht über unterschiedliche Auslegungen zu streiten.
  4. Wir wollen lieber aus den erreichten Zwischenständen lernen und neue Erkenntnisse und Erfahrungen in die Produktentwicklung einfließen lassen als am Anfang alles Festzuschrieben und dann den Plan ohne Rücksicht auf unsere sich verändernde Umwelt umzusetzen.

Wichtig ist aber noch der letzte Satz, denn das relativiert das Ganze wieder: Nicht alles, was wir bisher gemacht haben, ist schlecht. Jede Organisation, die den Stand eines 2 Leute Garagenstartups verlassen hat und wächst, braucht Prozesse und Tools. Ohne gewisse Ablaufregeln der Arbeit – nichts anderes stellen Prozesse dar – können größere Gruppen von Leuten nicht zusammenarbeiten. Wir müssen nur aufpassen, dass wir die Prozesse nicht zu wichtig nehmen und dass wir nicht Gefahr laufen, unser Hirn an Eingang in die Firma auszuschalten. Wir müssen immer hinterfragen, ob das, was wir hier machen sinnvoll und notwendig ist – und dies müssen wir gemeinsam, also interaktiv tun…

Ferner braucht jede Software eine Dokumentation oder eine Userhilfe. Auch wenn es ein großes Ziel ist, eine Software für den Anwender selbsterklärend zu designen, es wird immer Fälle geben, wo man mal schnell eine “how to?-Frage” nachschlagen will – eine Software ohne eine Hilfe wäre also nicht Nutzerfreundlich. Genauso ist eine Dokumentation für die Wartbarkeit der Software unabdinglich: wie sollen Kollegen, die nach ein paar Monaten oder Jahren Fehler suchen oder die Software weiterentwickeln, sich schnell zurecht finden? (Mit einer Doku kann man also wertvolle Zeit zur Einarbeit sparen).

Dann kommen wir noch zu der Vertragsfrage: Auch hier werden wir wahrscheinlich nicht ohne eine kleine schriftliche Vereinbarung auskommen – entscheidend ist aber doch das gegenseitige Vertrauen, welches sich in der Zusammenarbeit aufbauen sollte. Daher ist es extrem wichtig das Ziel und die Probleme des Kunden zu verstehen und letztlich gemeinsam an einer Lösung zu arbeiten. Alles andere ergibt sich dann von selbst.

Planung ist essentiell, der Plan selbst danach aber wertlos, das sagte schon General Eisenhower. Natürlich müssen wir planen – wir haben in scrum ja auch die 5 Planungshorizonte, über die ich ja schon mal gesprochen. Aber wir müssen flexibel bleiben und in der Lage sein den Plan stets anzupassen. Änderung ist nichts Schlechtes, sondern es ist eine notwendige Justierung auf dem Weg zum richtigen Ergebnis. Du fährst ja auch nicht Auto ohne das Lenkrad zu bedienen und Du hast hoffentlich auch kein schlechtes Gefühl dabei…

Das agile Manifest besteht aber nicht nur aus diesen 4 Kernsätzen, es stehen auch 12 Prinzipien dahinter, die Dir bei der Umsetzung helfen und die die Bedeutung des Manifests unterstreichen. 

Ich lese diese jetzt einfach mal vor, so wie Du sie auch im Internet finden kannst (und wahrscheinlich auch kennst):

Prinzipien hinter dem Agilen Manifest

Prinzip Nr. 1: Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.  – Dahinter steckt die Idee der Iteration und der Entwicklung von funktionierenden kleinen Einheiten, die dem Kunden schnell nutzen bringen.

Prinzip Nr. 2: Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen.  Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Das bedeutet: Änderungen sind nie schlecht – bleib flexibel und siehe Änderungen als notwendige Aktionen um der Lösung des Problem noch näher zu kommen. Der Kunde hat also etwas davon, wenn wir schnell auf Änderungen reagieren – es ist für ihn von Vorteil! – Umgekehrt sind festgeschriebenen Anforderungen und starre Change-Request-Verfahren ein Nachteil für den Kunden! -> Und damit letztlich auch für uns…

Kommen wir zum

Prinzip Nr. 3: Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Schneller ist besser – denke daran, wenn Du dir überlegst, wie lange zum Beispiel ein Sprint sein soll…in 2-Wochensprints beispielsweise hast du doppelt so viele Feedback und Anpassungsmöglichkeiten, wie in einem 4-Wochen-Sprint. Die Lernkurve ist viel steiler.

Prinzip Nr. 4: Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Jeder muss sich in die Lage des Anderen versetzen können um eine bestmögliche Lösung für Probleme oder Wünsche finden zu können. Es macht also wenig Sinn sich abzugrenzen und gegenseitig nur Aufgaben und Lösungen über den Zaun zu werfen…

Prinzip Nr. 5: 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. Motivation entsteht durch Sinnstiftung und Handlungsfreiheit und das Streben nach Meisterschaft…wie heißt es so schön: Wenn du ein Schiff bauen willst, dann trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre sie die Sehnsucht nach dem weiten, endlosen Meer. (bitte das Zitat von Antoine de Saint Exupéry hier jetzt nicht zu wörtlich nehmen, nur die Sehnsucht alleine wird einen auch nicht weiterbringen…). Also, falls du Product Owner oder Manager bist – lass los und vertrau dem Team. – das gilt natürlich auch für Scrum-Master!

Prinzip Nr. 6: Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. vergiss Mails, setz dich zusammen mit den Leuten und unterhalte Dich. Finde aber Möglichkeiten mitzuteilen, wenn Du nicht gestört werden möchtest (z.B. setz einen Kopfhörer auf oder denkt Euch im Team entsprechende Signale aus, damit auch vermieden wird, dass man sich nicht mehr konzentrieren kann vor lauter Unterhaltung…)

Prinzip Nr. 7: Funktionierende Software ist das wichtigste Fortschrittsmaß. Outcome über Output. Es ist nicht wichtig, wieviel Du arbeitest, sondern was dabei rauskommt. Das Maß ist dabei nicht die eingesetzte Arbeitszeit, sondern das Ergebnis.

Prinzip Nr. 8: Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Auch wenn ein Sprint “Sprint” heißt und diese Bezeichnung ist in diesem Zusammenhang auch etwas unglücklich: Wir laufen hier eigentlich einen Marathon, d.h. wir müssen unsere Arbeitsleistungen auf lange Zeit durchhalten können. Ein Sprintplanungsmeeting hat also nicht das Ziel dem Team noch ein paar zusätzliche Userstories aufzudrücken oder ständig im Notfallmodus einer unrealistischen Planung hinterherzuhecheln. Wenn Du Product Owner bist, beachte das, wenn Du Scrum-Master bist, sorge dafür. Und—das Prinzip gilt natürlich auch, wenn Du nicht “Scrum” machst!

Prinzip Nr. 9: Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Kaizen – die ständige Verbesserung – greift nicht nur in der Retrospektive und im Team. Durch schnelle Zyklen ergeben sich mehr Möglichkeiten Dinge zu verbessern. Mehr Feedback bringt zugleich bessere Ideen.

Prinzip Nr. 10: Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell. Da muss man erstmal drüber nachdenken…das hat nichts mit Faulheit zu tun, sondern mit Vermeidung von Waste – also Verschwendung. Wir wollen keine Arbeit verschwenden, indem wir sinnlose Dinge umsetzen, die niemand braucht oder verwenden kann.

Prinzip Nr. 11: Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. 

Nur in selbstorganisieren Teams kann sich die Kreativität eines jeden Einzelnen voll entfalten. Jeder hat seine Stärken und die Menschen haben verschiedene Charaktere. Von alleine sind wir relativ einfach in der Lage uns in einem Team zurechtzufinden und uns einzuordnen. Wenn das von aussen passiert, geht es meist schief.

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

Dieses Prinzip wird beispielsweise in den Scrum-Retrospektiven direkt umgesetzt. Aber auch in Kanban oder anderen agilen Methoden ist es sinnvoll und teilweise verankert die Teamarbeit stets zu überprüfen und Wege zu einer ständigen Verbesserung zu suchen.

Letztlich finden wir all diese Prinzipien also in den agilen Methoden, wie Scrum oder auch Kanban wieder. (wobei Kanban in der heute oft verwendeten Form des “Lean-Kanban” für Software oder IT-Vorhaben durchaus etwas jünger als Scrum ist).

Die Unterzeichner des Manifests waren:

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

Einige der 17 Namen der Unterzeichner und auch die meisten der agilen Methoden, die ich vorhin genannt hatte,  sind aktuell vielleicht ein wenig in Vergessenheit geraten.

Andere, wie Alistair Cockburn, Ken Schwaber oder Jeff Sutherland sind wiederum durch die inzwischen herausragende Stellung von Scrum noch sehr präsent.

Soviel zum agilen Manifest – eine der Grundlagen des agilen Arbeitens und natürlich auch nicht nur im Softwarebereich gültig. Inzwischen sind  20 Jahre vergangen und agile Arbeitsweisen haben sich in vielen Bereichen durchgesetzt oder sind gerade dabei, in Bereiche wie Industrie oder in Schulen vorzudringen. Es ist also nicht heute nicht mehr gerechtfertigt, das agile Manifest nur auf die Softwareherstellung zu beziehen, auch wenn es ursprünglich im IT-Umfeld entstanden ist.

So – das wars für heute – Vielen Dank fürs Zuhören…Wenn Dir der Podcast gefallen hat, bitte ich Dich ihn zu abonnieren und mir eine Bewertung zu geben. Falls Du Kritik oder Anregungen hast, gerne auch über das Kontaktformular auf meiner Webseite oder als PN in Linked-IN oder Xing.

Tschüß

Dein Frank

Agilophil-Daily Podcast Episode 06: Das agile Manifest
Markiert in:         

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.