NBA05: Ist das Agile Manifest noch relevant?

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt dabei auf der Praxis, daher auch der Name NoBullshit Agile. In der letzten Folge habe ich über das Thema Scrum und warum es Zeit ist ein anderes agiles Vorgehen zu erwähgen gesprochen. Dies hier ist die Folge 5 und es geht heute um das agile Manifest. Bevor wir anfangen, ein wenig Housekeeping. Ich habe jetzt ein Subreddit gegründet, den Link dazu findest du in den Show Notes. Der heißt NoBullshit Agile wie auch sonst und die Idee ist halt ein Austauschpunkt zu haben. Ich leg dort jeweils einen neuen Thread an für eine neue Folge, sodass wir da zu einzelnen Folgen sprechen können. Ich werde das nutzen, um Bildmaterial, was ich habe, dort zu veröffentlichen. Das ist im Prinzip der Ersatz für eine Webseite, weil ich ehrlich gesagt keine Lust habe, gerade eine Webseite für dieses Projekt anzulegen, die dann pflegen zu müssen und alles was dazugehört. Deswegen habe ich mir gedacht, ich probiere das jetzt einfach mal auf Reddit. Ich weiß, es ist nicht so super optimal, das aus den Händen zu geben und ich weiß auch, dass nicht jeder von euch ein Reddit Account hat, aber ich mache das hier mal ganz hemmensärmlich und erhoffe mir halt, dass ich da ziemlich hässelfrei die Möglichkeit habe, Informationen zu einzelnen Folgen oder Informationen zu anderen Sachen rund um die agile Welt zu veröffentlichen und wie gesagt vor allen Dingen erhoffe ich mir, dass ihr Lust habt, dort zu bestimmten Themen und zu bestimmten Folgen zu diskutieren, euch auszutauschen. Ihr dürft und ihr sollt natürlich dort selber auch Themen und Fragen posten. Wenn ihr Vorschläge für Folgen habt, ist Reddit sicherlich auch gut. Ansonsten gibt es ja die üblichen Möglichkeiten, mich zu erreichen über Mail oder auch über Mastodon. Das erzähle ich ja auch immer am Ende von der Folge. Gut, heute soll es tatsächlich mal um das agile Manifest gehen. Ich vermute ihr kennt das alle. Ich kenne das auch, aber mir ist aufgefallen, ich gucke es mir nicht oft genug an. Bevor wir jetzt in eine Diskussion einsteigen, vielleicht noch mal einen kleinen Refresh für uns alle. Was ist das agile Manifest? Da haben sich mal 17 Leute getroffen, 2001 war das tatsächlich und sich mal einen Wochenende eingeschlossen und ein bisschen darüber gesprochen, was eigentlich die damals so üblichen Software-Entwicklungsmethodiken gemeinsam haben und ob man das nicht auf ein gemeinsames Fundament stellen kann. Also diese Methodiken NERSGRAM Extreme Programming, Crystal Clear, die sind alle so in dieser Zeit entstanden bzw. haben angefangen dort populär zu werden und sie haben festgestellt, ja man müsste irgendwie mal so ein Fundament formulieren, was wir denn wohl alle gemeinsam haben und daraus entstanden ist eben das agile Manifest. Ich gehe das einfach mal durch und versuche mal so ein bisschen zu jedem der vier Punkte meine Meinung, meine Erfahrung zu äußern. Also schlussendlich haben sie sich darauf geeinigt, dass es darum geht, bessere Wege zu finden, um Software zu entwickeln und haben das runterkondensiert auf so einen Vergleich. Vier Punkte, der erste Punkt ist, Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Also natürlich sind Prozesse wichtig und auch Werkzeuge sind wichtig. Die Idee ist hier sich dahinter nicht zu verstecken und zu sagen, lass uns lieber gemeinsam über etwas reden, wenn wir in einer Situation sind, als zu sagen, ich halte mich jetzt einfach im stillen Kämmerlein zum Beispiel an meinen Prozess und das, was mir ein Werkzeug vorgibt, die Interaktion ist wichtiger, um gute Software zu schreiben als der Prozess oder auch das Werkzeug. Das zweite ist funktionierende Software mehr als umfassende Dokumentation. Hier geht es darum zu sagen, die funktionierende Software ist das, was den Wert schafft. Das ist das Fundament dessen im Zweifel im Prinzip auch die Existenzberechtigung für Softwareentwicklung und nicht die Dokumentation. Auch hier vielleicht nochmal ganz wichtig die Betonung dazu. Es heißt nicht keine Dokumentation, sondern es heißt funktionierende Software ist wichtiger als Dokumentation und das kann ich in der Praxis auch bestätigen. Die funktionierende Software ist auch Teil der Dokumentation und natürlich gehört Dokumentation zu dem Prozess der Entwicklung dazu, aber es ist wichtiger, ein funktionierendes Software zu haben und auszuliefern, als eine Dokumentation zu haben. Natürlich wünscht sich ein Management zum Beispiel eine Dokumentation, aber schlussendlich ist der Gewinn eben in funktionierender Software. Der dritte Punkt ist Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Da kann ich aus der Praxis super viel zu erzählen, gerade wenn man mit größeren Unternehmen zusammenarbeitet, haben die einen Einkauf und die haben ihre Prozesse und es ist auch richtig so, dass sie das alles haben. Ich verstehe das schon aus deren Sicht, aber es macht überhaupt keinen Sinn, sich an Vereinbarungen wie Definitionen in einem Pflichten und einem Lastenhef zu halten und nicht mit dem Kunden zusammenzuarbeiten. Denn auch der Kunde erlebt, dass ja je länger wir ein Projekt machen, je tiefer wir einsteigen, desto mehr stellt der Kunde eben auf fest, dass was vielleicht mal eine gute Idee war, ist heute keine gute Idee mehr und in dem Fall muss man eben mit dem Kunden zusammenarbeiten. Es ist viel viel besser zum Telefonhörer zu greifen und mit dem Kunden Situation zu besprechen, als eben auf bestimmte Teile des Vertrages einfach zu bauen. Der nächste Punkt heißt reagieren auf Veränderungen ist wichtiger als befolgen eines Plans. Das hängt sicherlich mit dem Punkt davor ein bisschen zusammen. Was ist denn ein Plan? Ich sage ja immer, der Plan an sich ist ehrlich gesagt ohne Wert. Das heißt aber nicht planlos arbeiten, sondern was wir wollen, ist permanentes Plan. Wir wollen das immer tun. Wir wollen den Umwelteinfluss einfließen lassen. Und deswegen planen wir eigentlich immer. Wir wissen aber, dass der Plan, der irgendwann mal definiert wurde, höchstwahrscheinlich in zwei Monaten so nicht mehr richtig ist. Und wir wollen auf Veränderungen reagieren. Wir wollen ja Alleronings einfließen lassen und deswegen macht es überhaupt keinen Sinn, sich an einem Plan zu halten, der wie gesagt vielleicht vor drei Monaten mal erstellt wurde, wenn denn alle Beteiligten sich einig sind, dass eine Veränderung stattgefunden hat, auf die reagiert werden muss. Und das ist halt in meinen Augen ein ganz, ganz wichtiger Punkt in Projekten. Nicht daran festhalten, sondern gemeinsam mit dem Kunden zu gucken, okay, was müssen wir denn jetzt tun? Wie reagieren wir denn auf eine Veränderung? Vielleicht noch mal abschließend dazu. Ganz wichtig ist diese Vergleiche, die da in dem Agilemannifest stehen. Es heißt nicht, dass die rechte Seite nicht wichtig ist. Die linke Seite ist aber wichtiger. Das ist so das große Fundament und die große Meinung dazu. Was ich für mich insgesamt feststellen kann, ich benutze das Agilemannifest auch nicht jeden Tag und ich habe das wirklich auch länger vergessen, sage ich mal. Die Frage, die ich mir gestellt habe, ist, ist das Agilemannifest heute noch relevant? Das ist über 20 Jahre alt. Macht das heute überhaupt noch Sinn? Und in der Reflexion für mich, ja, definitiv ganz klar, das ist das Fundament der Arbeit, das ist das Fundament von Agilität, das ist die Definition schlussendlich der Agilensoftwerentwicklung. Das Problem ist, dass es einfach in meinen Augen auch verdeckt ist durch zum Beispiel Software Vigira oder Trello oder was auch immer für ein Tool hier nutzt. Schlussendlich soll die Software eigentlich das Agile Prinzip in Software gießen, aber die Firmen wie Atlassian bauen natürlich immer weitere Features ein, damit sie ihre Software weiterhin verkaufen und damit verwässern diese Fundamente einfach ganz stark. Das Zweite ist, alle Unternehmen, die Coaching rund um Agile Prinzipien, Scrum oder Kannmann Coaching zum Beispiel anbieten und Zertifikate zum Beispiel dazu ausstellen, bringen immer mehr Komponenten rein, damit sie immer weitere Zertifikate verkaufen können. Und auch das verdeckt eigentlich das Fundament. Also wenn man heute sich mal anguckt, was Unternehmen anbieten rund um Qualifikation oder Zertifizierung im agilen Bereich, da wird man ja wahnsinnig von. Also man kann ja keine Ahnung, fünf, sechs verschiedene Kurse machen, die alle aufeinander aufbauen und mein Eindruck ist, man wird immer nur verwirrt da. Das wird immer komplizierter, dabei ist es eigentlich gar nicht so kompliziert, wenn man denn zum Beispiel einfach mal auf das Agile Manifest guckt. Das Agile Manifest ist meiner Meinung nach etwas, was man echt sich ausdrucken muss und ich habe es auch nicht gemacht, aber ich überlege wirklich, es zu tun. Und bei jeder Entscheidung sich noch mal vor Augen führt, auf welcher Basis treffe ich ja eine Entscheidung, wie zum Beispiel wir den nächsten Schritt in ein Projekt gestalten oder wie wir den Flow managen wollen. Ich denke, das Agile Manifest ist total relevant und in meinen Augen wird es auch immer relevant sein. Denn wie gesagt, also die Gefahr der Verwässerung ist einfach riesen, riesen groß. Hier wird mich wirklich mal dein Feedback interessieren. Also nutzt du das Agile Manifest und wenn ja, wie, vielleicht sogar die Frage, kanntest du das oder kennst du das Agile Manifest? Wie gesagt, auf Reddit gibt es einen eigenen Thread zu dieser Folge. Das wäre super, wenn du da mal einen Kommentar hinterlässt, wenn du es nicht auf Reddit machen möchtest, gern sonst auch per Mail. Was es auch noch gibt, ist eine Konkretisierung des Agile Manifests. Die Kollegen haben sich damals halt hingesetzt und auch noch zwölf Agile Prinzipien beschrieben, die das Manifest eben konkretisieren. Dazu werde ich eine eigene Folge machen. Ich vermute tatsächlich, das wird sogar die nächste Folge sein. Das fand ich auch sehr hilfreich. Ich arbeite übrigens auch daran, die vier Punkte des Agile Manifests nochmal ein bisschen besser mit konkreten Beispielen in so Schaubildern festzuhalten. Da habe ich erste Entwürfe auch im Reddit schon mal gepostet, auch auf Mastodon. Ich bin damit noch nicht ganz zufrieden, deswegen würde ich die jetzt noch nicht so ganz als offiziell sehen. Aber dieses Visualisieren dessen und das anfassbar machen, dass man es zum Beispiel auch mit dem Team mal besprechen kann und auch fürs Team im Prinzip so ein bisschen so ein Handout hat. Das wäre so für mich eine ganz gute Sache und da würde ich halt versuchen, gute Beispiele zu finden und gute Schaubild zu bauen und so einen kleinen Sneak Peek gibt es wie gesagt auf Mastodon und auch in Reddit. Ja und ich denke damit haben wir es heute eigentlich auch schon. Wie ich schon gesagt habe, wenn du Feedback hast, dann gerne als Mail zum Beispiel an nobs@gmail.com oder eben auf Mastodon unter nobushet@podcast.social. Und jetzt ganz neu habe ich diese Folge sicherlich dreimal schon angeteasert. Im Subreddit, den Link zum Subreddit lese ich nicht vor, den findest du in den Show-Notes. Habt eine ganz tolle Woche und bis zum nächsten Mal!