Wie setze ich das Agile Manifest um?

Hallo! Einer meiner Coachees fragte mich vor einigen Tagen, wie er mit seinem Team das agile Manifest umsetzen könne. Aus meiner Sicht ist das eine gute und spannende Frage - gerade auch weil es keine glasklare Antwort gibt. Ein paar Gedanken und Hinweise möchte ich dennoch mit dir teilen.

Worum geht es im agilen Manifest? Es geht um 8 Werte und die Priorisierung dieser Werte, d.h. was ist wichtiger oder was wird mehr geschätzt:

• 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

Wie kannst du das jetzt umsetzen? Nun, Werte sind etwas anderes als Prozesse oder Arbeitsweisen. Die Arbeitsweise nach Scrum mit Sprints, Reviews und so weiter kannst du einfach so umsetzen - du etablierst die entsprechenden Meetings, füllst dein initiales Backlog und schon kann’s losgehen. Fertig! An dieser Stelle kommt der Spoiler: Wenn wir über Werte sprechen, sind wir nie fertig. Das hat aber auch etwas Positives: Du kannst dich entspannen. Es geht nicht darum, ein Ziel zu erreichen. Der Weg ist das Ziel.

Aus meiner Sicht ist der Schlüssel zum Erfolg die regelmäßige Reflektion. Jedes Teammitglied für sich und auch gemeinsam. Entspricht meine oder unsere Arbeitsweise den Werten des agilen Manifests? Was kann ich anders machen? Retrospektiven sind ein wunderbarer Anlass für diese Reflektion, aber auch ein Spaziergang oder die Dusche. Es gibt natürlich so ein paar Klassiker, die immer wieder auftauchen - die folgenden Punkte sollen insofern als Gedankenanstöße dienen.

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Für mich heißt das: Menschen, Gespräche und gesunder Menschenverstand sind wichtiger als Prozesse und Tools. Wenn ihr als Team also über eure Arbeitsweise der letzten 2 Wochen reflektiert, könntet ihr beispielsweise über die folgenden Punkte nachdenken:

• Habt ihr „Unterhaltungen“ über Email, Jira-Kommentare oder Teams-Chat geführt? Unterhaltung im Sinne eines mehrmaligen Hin-und-Her. Wenn ja - warum habt ihr nicht direkt gesprochen oder telefoniert oder videokonferiert?
• Hat sich euer Arbeitsprozess vom klassischen Dreiklang (to do, doing, done) so weit entfernt, dass ihr inzwischen 12 Stufen habt? Warum? Welchen Mehrwert generiert ihr mit diesem Arbeitsprozess?
• Benutzt ihr die Argumentation „ja, aber in Scrum macht man das so“? Welchen Teil des Prozesses würdet ihr gerne ändern? Was wäre dann besser?
• Wieviele Gespräche habt ihr mit Menschen außerhalb eures Teams geführt? War die Anzahl genau richtig, zu viel, zu wenig?
• Welcher Unternehmensprozess hat euch den letzten Nerv geraubt? Warum? Was ist Sinn und Zweck dieses Prozesses? Wer ist der Process Owner? Wie könnte man Sinn und Zweck leichter erreichen?

Vielleicht stolpert ihr ja über Punkte, die ihr verändern wollt. Vielleicht ist auch alles genau so richtig, wie ihr arbeitet. Es geht im Wesentlichen darum, die richtige Balance zwischen Individuen, Interaktionen, Prozessen und Tools zu finden. Das gilt natürlich auch für die weiteren Elemente. Wichtig: Es gibt hier kein richtig oder falsch, nur die passende Balance.

Funktionierende Software mehr als umfassende Dokumentation

Ah… einer meiner Lieblingspunkte. Ich muss komischerweise immer erwähnen, dass hier lediglich steht, dass Software wichtiger als Doku ist - aber nicht, dass auf gar keinen Fall dokumentiert werden darf. Auch hier kommt es auf die Balance an, insofern ein paar Gedankenanstöße:

• Welche Dokumentation habt ihr für einen bestimmten Zweck erstellt und im Anschluss doch nicht benötigt?
• Welche Dokumentation habt ihr erstellt, weil ein bestimmter Prozess es verlangt? Warum?
• Welche Dokumentation habt ihr für Menschen außerhalb eures Teams erstellt? Warum brauchen diese die Doku? Welche anderen Möglichkeiten gibt es, die notwendigen Informationen zu teilen?
• Wieviel Zeit benötigt ihr, um alten Code zu verstehen?
• Wie oft stimmt die Dokumentation mit der Realität überein?
• Wie hoch ist der Zeitaufwand, einem neuen Teammitglied die Anwendung und den Code zu erklären?
• Wie aufwändig ist es, die Aufgaben innerhalb des Team zu rotieren?
• Wie oft klingelt das Betriebsteam in der Entwicklung durch, um Probleme zu lösen?

Dokumentation ist aus meiner Sicht kein Selbstzweck. Sie dient zur Kommunikation von Informationen, zur Verstetigung von Informationen und zur Skalierung von Informationen - wobei die letzten beiden Punkte die entscheidenden sind. Lass uns das noch einmal durchgehen: 1) Ich kann Informationen aufschreiben und dann über den Zaun werfen. Ich kommuniziere also. Schlecht. Sprich lieber direkt mit den betroffenen Menschen. 2) Ich kann Informationen aufschreiben, weil ich oder jemand anderes später diese Infos benötigt. Wieso funktioniert der Algorithmus genau so? Was muss ich im Falle von X ändern? Das kann sinnvoll sein - es ist eine Wahrscheinlichkeitsabschätzung. Ich muss jetzt 15 Minuten dokumentieren. Wie wahrscheinlich ist es, dass jemand diese Infos später braucht? Wie aufwändig ist es, die Infos ohne Doku zu beschaffen? 3) Ich kann Informationen aufschreiben, um mich nicht ständig zu wiederholen. Der siebte neue Kollege steht auf der Matte und will wissen, wie der Code zu lesen ist. Du würdest ihm am liebsten sagen „read the f… manual“ - blöd, wenn es kein manual gibt.

Lange Rede, um zu sagen: Wenn ihr ein Problem habt oder antizipiert, welches mit Dokumentation gelöst werden kann - dann dokumentiert. Wenn nicht, dann nicht.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Diesen Punkt sehe ich üblicherweise gemeinsam mit dem nächsten: Reagieren auf Veränderung mehr als das Befolgen eines Plans. In meinen Worten: Erstens kommt es anders und zweitens als man denkt. Niemand kann mit hundertprozentiger Sicherheit vorher sagen, was er genau braucht, wie lange es dauert, wie teuer es wird, welche Anpassungen zwischendurch noch notwendig werden. Insofern müssen wir mit dieser Unsicherheit umgehen. Wie? Gemeinsam mit dem Kunden.

• Wie oft hast du laut oder in Gedanken gesagt „das muss der Kunde doch wissen!“ oder „der Anwender weiß ja gar nicht, was er will“. Muss er nicht - ihr könnt es gemeinsam erarbeiten.
• Wie oft hast du dich darüber geärgert, dass du eine Maske überarbeiten musstest? Ärgere dich nicht - freue dich über das Feedback und die Möglichkeit, gemeinsam eine bessere Anwendung zu entwickeln.
• Wie oft wart ihr „eigentlich“ fertig - und dann fielen dem Anwender noch drei superwichtige Funktionen ein? Hätte er das nicht vorher sagen können? Nee - er wusste es ja selber nicht und hat es erst gemerkt, als er den Prototyp in den Händen hatte.

Zwei wichtige Hinweise möchte ich an dieser Stelle noch geben: Kein Plan ist auch keine Lösung. Ein Ziel, eine Problembeschreibung, eine Beschreibung des Soll-Zustands ist extrem hilfreich, sonst irrlichtert ihr nur durch die Gegend. Und zweitens funktioniert diese Art der Arbeitsweise nur, wenn sich auch der Kunde darauf einlässt. Der Klassiker ist ja immer „ich weiß nicht, was ich will, aber sag mir bitte genau, was es kostet und wie lange es dauert“ - das hat früher nicht funktioniert und funktioniert auch mit agiler Softwareentwicklung nicht.

Das agile Manifest ist überschrieben mit „wir erschließen bessere Wege, Software zu entwickeln,…“ - es geht aber m.E. gerade nicht nur um den kleinen Teil der eigentlichen Entwicklung, sondern insbesondere um die Frage, wie wir die relevanten Probleme der Anwender möglichst schnell auf angemessene Weise lösen. Der größte Nutznießer dieser Arbeitsweise ist insofern der Anwender, das eigene Unternehmen, der Auftraggeber. Und ja, es gibt Anwender, Unternehmen und Auftraggeber, die den Nutzen nicht erkennen. Aber das ist eine völlig andere Diskussion.

Fazit

Was machen wir jetzt aus dem Gesagten? Lass es mich mal so zusammenfassen: Das Agile Manifest beschreibt Werte, die für eine Softwareentwicklung hilfreich sind. Wenn ihr als Team und Unternehmen diese Werte für richtig haltet, dann solltet ihr euch kontinuierlich hinterfragen, ob eure tatsächliche Arbeitsweise im Einklang mit diesen Werten steht. Ihr könntet dies beispielsweise in Retrospektiven machen. Wenn ja - alles in Butter. Wenn nein, dann ändert ihr halt einen Aspekt eurer Arbeitsweise. Es geht nicht darum, diese Werte irgendwann „eingeführt“ zu haben, sondern die eigene Arbeitsweise Schritt für Schritt daran auszurichten. Oder? Wie sieht du das?