In der aktuellen Folge von No Bullshit Agile beleuchtet Thomas das Agile Manifest und seine Grundlagen in einem Gedankenspiel. Er stellt die Hypothese auf, dass das Agile Manifest primär entwickelt wurde, um Kunden einen schnelleren Zugang zum Markt zu ermöglichen, nicht unbedingt um ein besseres Arbeitsumfeld für Entwickler zu schaffen. Thomas argumentiert, dass das ursprüngliche Ziel der Agilität darin bestand, Softwareentwicklung zu verbessern und Kunden einen Wettbewerbsvorteil zu verschaffen. Er weist darauf hin, dass viele in der Praxis Agilität eher auf interne Effizienz und Arbeitskultur beziehen, was seiner Meinung nach ein Nebeneffekt und nicht das Hauptziel des Manifests ist.

Er erläutert, dass das Agile Manifest 2001 von führenden Köpfen der Softwarebranche entwickelt wurde, die die damaligen, schwerfälligen Wasserfallmethoden ablösen wollten. Die 17 Gründer, die sich in Utah zum Skiwochenende trafen, formulierten das Manifest, um leichtere und flexiblere Entwicklungsprozesse zu etablieren. Thomas schließt mit der Anregung, dass Diskussionen über Agilität und ihre Prinzipien offen geführt werden sollten, um die ursprünglichen Ziele besser zu verstehen und die Praxis weiterzuentwickeln. Er lädt dazu ein, sich an der Diskussion im Forum zu beteiligen und Feedback zu geben.

Transkript

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 auf der Praxis, daher auch der Name NoBullshit Agile.

In der letzten Folge habe ich mit Felix über Agile at Scale gesprochen. Wenn dich das interessiert, hör da gerne rein, den Link dazu findest du in den Show-Notes. Das ist die Folge 29 und heute möchte ich mit euch ein kleines Gedankexperiment machen. Es geht um das Agile Manifest. Den möchte ich ein bisschen auf den Grund gehen und habe mir dazu so einen Gedankenansatz überlegt. Je länger ich mich mit Agilität beschäftige, und das tue ich schon ein paar Jahre, desto bewusster wird mir, wie wichtig eigentlich das Agile Manifest ist und die dazugehörigen zwölf agilen Prinzipien. Ich habe dazu einzelne Folgen gemacht. Auch die Links findest du in den Show-Notes.

Ich möchte jetzt mal ein bisschen tiefer da einsteigen, was denn, ja, ich sage mal, das Fundament vom Agile Manifest ist oder was uns das Agile Manifest wirklich sagt und was es uns wirklich bringen kann. Und wie gesagt, das hier ist jetzt ein Gedankexperiment. Es mögen jetzt ein paar Punkte auftauchen, das vielleicht mal das Claimervorab, wo du dann vielleicht einmal zusammenzuckst oder sagst, was ist das für eine Interpretation? Hör gerne bis zum Ende, denn ich glaube, aus diesem Gedankexperiment entsteht eigentlich eine total gute Diskussion und ich würde dich auch wirklich bitten, mit mir in die Diskussion zu gehen. Am besten halt im Forum. Link dazu auch in den Show-Notes und ich erzähle nachher auch noch ein bisschen was zu Feedback, weil wir im Forum die Möglichkeit haben, dass mehr Leute einsteigen können in die Diskussion.

Schlussendlich glaube ich, dass das, was ich jetzt gleich erzähle, hilft, tiefer einzusteigen in, was hilft denn das Agile Manifest. Wenn ich ganz ehrlich bin, ganz am Anfang, als wir angefangen haben, uns mit Agilität zu beschäftigen bei uns im Unternehmen, habe ich das Agile Manifest natürlich gelesen und die zwölf Prinzipien, aber sie waren mir zu allgemein und sie sind mit Absicht allgemein gehalten, sehen wir auch gleich. Aber dann ist es natürlich erstmal schwer, wirklich was damit anzufangen. Sie klingen selbstverständlich, finde ich, sie klingen total logisch und total sinnvoll, aber ich finde, es steckt halt einfach noch mehr darin.

Okay, dann versuche ich mal das Gedankexperiment zu erklären. Also, das Agile Manifest ist entstanden, 2001. Ich erzähle gleich auch noch mal ein bisschen was genauer zu der Historie, weil Software, die auf dem klassischen Weg, also vor allen Dingen im Wasserfall entwickelt wird, nicht so gut funktioniert, wie man erhofft hat. Oft, also nicht immer, wird heute Agilität aber auch so verstanden, dass es für die Menschen eine gute Sache ist. Und natürlich ist das auch so, mit den Menschen meine ich jetzt vor allen Dingen die Devs, die Teams, die in dieser Umgebung leben. Natürlich auch die Kunden, auch auf die Kunden gehe ich gleich nochmal ein. Aber ich habe festgestellt, oft genug ist Agilität von Leuten verstanden als, na ja, Agilität hilft mir, mir als Dev in einem guten Arbeitsumfeld zu leben.

Ich behaupte jetzt einfach mal, und das ist das Gedankexperiment, das ist aber gar nicht das, was die Leute wollten, als sie das Agile Manifest geschrieben haben. Was die Leute wollten, war, wir wollen unseren Kunden schnell ein gutes Produkt liefern. Man sieht das auch in den agilen Prinzipien, erstes Zitat mal da draus, da steht ganz am Anfang: „Wir erschließen bessere Wege, Software zu entwickeln.“ Also es geht um die Software, es geht nicht darum, wir erschließen bessere Wege, dass wir bessere Arbeitsbedingungen haben oder uns das Arbeiten leichter fällt. Sprich, und das ist jetzt mal so das Gedankexperiment und die Hypothese im Agile Manifest und damit grundsätzlich in der Agilität erst mal, geht es darum, Software besser zu entwickeln und der Mensch, der in einem agilen Umfeld lebt, der ist ziemlich egal. Das ist natürlich jetzt eine supersteile These, aber wie gesagt, es soll erstmal jetzt ein Gedankexperiment sein und ja, so eine Diskussion starten. Also nimm das mal hin, nimm das mal mit, denk mal drüber nach und hoffentlich hörst du mir noch ein bisschen länger zu.

Ich habe als Vorbereitung zu dieser Folge eine kleine Umfrage gestartet, auf LinkedIn und auf Mastodon. Auf LinkedIn hat leider keiner geantwortet, auf Mastodon haben sieben Leute mitgemacht, das ist überhaupt nicht repräsentativ, das ist mir schon klar. Die Frage, die ich da gestellt habe, war ein bisschen anders. Man hat ja relativ wenig Platz so auf Mastodon, deswegen habe ich versucht, die Frage ein bisschen anders zu formulieren. Und zwar habe ich gefragt: Stell dir mal vor, du arbeitest in einer Agentur, die Software für verschiedene Kunden entwickelt, und die Frage ist dann: Warum willst du agil sein? Ich habe zwei Antwortmöglichkeiten geboten, also drei eigentlich. Erste Antwortmöglichkeit: Du willst agil sein für deinen Kunden, denn agile Methoden bieten Kunden einen Mehrwert, flexiblere und schnellere Anpassungen und so weiter und so fort. Antwortmöglichkeit B: Für dich als Agentur. Agile Methoden verbessern Effizienz und Arbeitskultur innerhalb der Agentur und helfen, Projekte effektiver zu steuern. Das dritte war „Andere“ und dann habe ich gebeten, doch gerne einen Kommentar zu hinterlassen, was jemand mit „Andere“ meint. Aber es geht vor allen Dingen eben um diese beiden grundsätzlichen Fragen. Stell dir vor, du bist in einer Agentur und entwickelst also nicht hausintern Software, sondern du entwickelst im Auftrag anderer oder für andere, also für Kunden Software.

So, und die Antworten waren ganz interessant. Wie gesagt, das sind nur sieben Leute, die mitgemacht haben, aber trotzdem. 29 Prozent, also ungefähr 30 Prozent, sagen wir einfach mal, ok, agile Methoden sind vor allen Dingen dafür da, um für den Kunden einen Mehrwert zu bieten. Und 57, also knappe 60 Prozent, sagen, agile Methoden sind dafür da, dass die Agentur effizient arbeitet, eine gute Arbeitskultur hat. Und ich finde das deswegen so interessant, weil ich momentan ja hier in meinem ganzen Gedankenexperiment behaupte, Agilität ist mal erfunden worden, das mache ich jetzt mal am Agile Manifest eben fest, für Kunden. Kunden sollen die Möglichkeit haben, schnell am Markt zu sein. Und die Mehrheit der Leute, die jetzt mitgemacht haben, sehen es eher im Sinne von innerhalb der Agentur, Effizienz und Arbeitskultur, also nach innen gerichtet. Die eine Sicht ist nach außen gerichtet für den Kunden. Ich als jemand, der Dev ist, will agil sein, um meinem Kunden schnell was zu liefern, also was Gutes zu liefern, nicht irgendwas. Und 60 Prozent sagen, nee, es geht mir darum, ich möchte ganz gerne, dass ich ein gutes Arbeitsumfeld habe. Das ist ein bisschen überspitzt, ich interpretiere jetzt wieder was in so eine Umfrage rein. Das ist mir vollkommen klar. Aber das wär mal so der Stand.

Also nochmal vielleicht ganz kurz zusammengefasst: Gedankenexperiment. Leute haben sich zusammengesetzt und gesagt, nee, wir müssen mal definieren, wie eine andere Arbeitsweise aussehen kann. Und daraus entstanden ist das Agile Manifest und die 12 agilen Prinzipien. Und sie haben das getan, weil sie gesagt haben, wir müssen für unsere Kunden besser sein. Nicht, wir wollen ein besseres Arbeitsumfeld. So, mit diesem Experiment, mit dieser Hypothese, steigen wir jetzt mal ein. Und das erste, was ich gemacht habe, ich habe mir mal angeguckt, in welcher Situation und mit welchen Leuten das Agile Manifest wirklich entstanden ist. Und dazu gibt es unter anderem die Historie des Agile Manifests. Also auf der Webseite des Agile Manifests gibt es unter anderem die Historie. Und es gibt auch zwei Interviews, die ich gefunden habe auf YouTube von Ken Schwaber und Jeff Sutherland, wo sie auch nochmal die Situation beschreiben. Und wir gehen das einfach mal durch.

Entstanden ist das Agile Manifest 2001. Wir sind also in der Situation, wo es schon agile Ansätze gab. So, erstes Paper zu Scrum ist 95 entstanden, Extreme Programming ist so 99. Und wir sind also in der Situation Anfang 2000, das Internet hat sich manifestiert und durchgesetzt. Also das Internet an sich ist erwachsen geworden, sage ich mal. So circa zehn Jahre gibt es das schon. Und jetzt treffen sich Leute, 17 Leute in diesem Fall, die sich so untereinander schon kennen, weil sie alle in der Software-Entwicklungsbranche sind und die meisten auch irgendwie im Coaching oder im Entwicklungssinn. Das sind Vertreter von Extreme Programming dabei, von Scrum, von DSDM, von Adaptive Software Development, von Crystal, so Feature Driven Development, Pragmatic Programming. Also Leute haben sich schon Gedanken gemacht und festgestellt, die alten Entwicklungsprozesse funktionieren irgendwie nicht. Was sind die alten Entwicklungsprozesse? Wo stehen wir denn da? Na ja, grundsätzlich mal kommen wir aus einer Welt 70er, 80er, 90er. Alle arbeiten eigentlich noch im Wasserfall oder sehr viele arbeiten noch im Wasserfall. Also es gibt ganz klar abgegrenzte Phasen. Es gibt so eine Anforderungserhebungsphase, die muss abgeschlossen sein, bevor man in eine Konzeptionsphase gehen kann und die muss abgeschlossen sein, bevor man in eine Designphase gehen kann und die muss abgeschlossen sein, bevor man in eine Entwicklungsphase gehen kann und dann kommt eine Testphase und so weiter und so fort. Klassisches Wasserfall, ihr könnt euch das glaube ich vorstellen.

Wenn man sich jetzt mal diese Interviews anguckt, also die Leute treffen sich, wie gesagt, die kennen sich schon, sie sind so von sich selber behauptet, ich muss mal ganz kurz nachgucken. Ich glaube, das war Jeff Sutherland in dem Interview, der dann so unter anderem sagt, okay, eigentlich sind das so die Thought-Leader in der Industrie, in der Software-Entwicklungsindustrie, die sich da getroffen haben, diese 17 Leute. Und die treffen sich in Utah für so ein Ski-Wochenende, um zu versuchen, mal gemeinsam zu formulieren, wie sieht denn die neue Welt aus? Ken Schwaber in seinem Interview, also die beiden Links zu den Interviews, YouTube-Videos sind das, die findest du natürlich in den Show-Notes. Ken Schwaber sagt in seinem Interview, das ist ziemlich kurz, ich habe leider nichts längeres gefunden. Erst einmal haben sie sich darauf geeinigt, eigentlich wollen wir Guidelines formulieren und keine festen Regeln. Wir wollen nicht noch mehr Regeln, sondern wir wollen eigentlich Guidelines, wo sich Leute dran orientieren können. Und das Manifest, was dann entstanden ist, hat deswegen auch eher so, ja, Recommendations eher, also mehr Empfehlungen in der Formulierung, die wir alle kennen: lieber dies oder mehr dies als das. Jeff Sutherland, das Interview ist ein bisschen länger, der sagt, na ja, also wie gesagt, das sind alles so Software-Entwickler, die sich da getroffen haben, Consultants, teilweise aus dem Projektmanagement, und es galt eben diesen großen, schweren, monolithischen Software-Entwicklungsprozess, also wie gesagt, vor allen Dingen im Wasserfall, abzulösen. Und das war die Situation, und sie suchen eben nach etwas, was leichtgewichtiger ist. Sie nutzen auch tatsächlich erst mal dieses Wort Lightweight, und das wird sich später eben dann ändern in das Wort Agil. Das Wort Agil gibt es länger schon, schon länger geprägt auch, und sie einigen sich später auch darauf, dass sie es Agil nennen wollen und nicht nur Lightweight. Einige der Teilnehmer haben tatsächlich so ein bisschen Angst, dass man sich nicht einigen kann. Sprich, es ist nicht so, dass sie sich getroffen haben und gesagt haben, ja, genau, lass uns das mal runter formulieren, fertig, genau so ist es. Sondern es gab schon sehr verschiedene Blickwinkel darauf. Und sie haben dann angefangen darüber zu diskutieren, also die Geschichte geht wohl so, dass sie am ersten Tag überhaupt sich ein bisschen zusammengerauft haben, zusammengefunden haben, was haben wir hier wirklich vor, und am zweiten Tag die eine Hälfte wohl Skifahren gegangen ist und die andere Hälfte dann sich vom Whiteboard oder Flipchart gestellt hat und eben dann schlussendlich das Agile Manifest so wirklich in der Viertelstunde wohl formuliert hat. Die anderen vom Skifahren zurück haben gesagt: Ja, geil, genau das ist es. Und sie sind schlussendlich so dann dazu gekommen und haben dann hinten drauf die zwölf Prinzipien formuliert, um, ja, ich sage mal, Butter bei die Fische zu haben, das Ganze ein bisschen zu untermauern. Aber sie sind halt in so einem Schritt-für-Schritt-Prozess dazu gekommen. Also eine Aussage war wohl: „Great Teams Make Great Software.“ Also da stand das Team tatsächlich das erste Mal im Vordergrund und es ging dann eben genau um dies, wie arbeiten wir zusammen und so entstand dies „Individuals and Interactions“.

Dann gab es so eine Phase von, naja, Prozesse und Tools, die machen uns langsam, und so sind sie dazu gekommen zu sagen, okay, Interaktionen zwischen Menschen über Prozesse und Tools. Und dann haben sie halt gesagt, okay, dieses oft und regelmäßig Software liefern bringt dem Kunden viel mehr Wert als Dokumentation, und so ist dieser Punkt entstanden. Und dann gab es wohl tatsächlich eine längere Diskussion zu dem Punkt, naja, eigentlich ist es oft so, dass wir mit unserem Kunden über Verträge, Support und den Projektverlauf diskutieren, anstatt zu entwickeln. So sind sie tatsächlich auf diesen Punkt gekommen, dass der Kunde eigentlich von Anfang an involviert sein muss; er muss Teil des Projekts werden. Und so ist dieser Punkt entstanden. Ja, und die Leute, die Extreme Programming (XP) kannten, haben wohl noch so beigetragen, dass wir auf Veränderung und äußere Einflüsse reagieren wollen, weil das wichtig ist, um eine gute Software zu schreiben, anstatt stumpf einem Plan zu folgen. Das ist ein wichtiges Element.

So, und wie gesagt, die zwölf Prinzipien sind dann noch dazu gekommen, um am zweiten Tag, beziehungsweise am dritten Tag, Butter bei die Fische zu haben, um das Ganze noch ein bisschen weiter auszufüllen, die vier Prinzipien mit Leben zu füllen. Wenn man sich jetzt das Agile Manifest und die zwölf Prinzipien anguckt, dann finde ich, und jetzt komme ich wieder ein bisschen zu diesem Gedankenexperiment, tatsächlich, dass da ziemlich klar formuliert ist, dass der Kunde da im Vordergrund und im Mittelpunkt steht. Es geht nicht darum, dass das Team eine gute Umgebung hat, sondern es geht an vielen Stellen meiner Meinung nach darum, dass der Kunde durch Agilität eine Chance auf den Markt hat. Wir wollen schnell auf dem Markt sein.

Warum ist es so ein zentraler Aspekt damals gewesen? Naja, ich habe es vorhin schon mal kurz gesagt, wo stehen wir? Wir sind Anfang der 2000er. Das Internet ist erwachsen geworden, also sagen wir mal so, 90er Jahre, Anfang 90er Jahre, Ende 80er Jahre, wenn wir so World Wide Web jetzt gucken, nicht E-Mail und so weiter und so fort, sondern wirklich dieses Internet-Ding. Das gab es jetzt so circa 10 Jahre. Und das bedeutete eben für alle Kunden, es gab einen Riesenwechsel von, ja, wir können so unser Ding machen. Der Markt ist ja relativ klein und wir haben andere Kanäle, um zu kommunizieren, dass wir auf dem Markt sind und ein Produkt haben. Hinzu, der Markt ist auf einmal ein Punkt. Durch das Internet ist ja Folgendes passiert: Jeder hat Zugang zum Markt und der Markt ist total transparent. Denn jeder kann in diesem Internet ja Informationen holen beziehungsweise bereitstellen. Und das erhöht den Druck auf einmal enorm für Kunden und Firmen. Ich muss meine Dienstleistungen oder mein Produkt in diesem Internet präsentieren, und ich brauche eine Software, die das repräsentiert. Andere schießen wie Pilze aus dem Boden und deswegen muss ich schnell auf mein Umfeld reagieren, viel, viel schneller, als ich das vor dem Internet gewohnt war.

Und aus diesem Blickwinkel, wenn man sich das mal anguckt, das gilt ja heute auch noch. Das Internet ist ja nicht weg, ganz im Gegenteil. Die Geschwindigkeit ist ja noch viel größer geworden. Die Märkte sind noch weiter internationalisiert. Da haben halt die Leute gesagt, nur so können wir Software entwickeln. Nur mit dem Agile Manifest, nur mit Agilität, mit all dem, was wir darunter verstehen, habe ich eine Chance. Das Wasserfallmodell ist tot. Ich werde mit diesem Wasserfallmodell nicht erfolgreich am Markt sein.

Deswegen denke ich, und wenn ihr mal wirklich das Agile Manifest lest und die zwölf Prinzipien, kommt man da auch ziemlich schnell drauf: Das Produkt und der Kunde und die Lieferung des Produkts in guter Qualität, die marktfähig ist. Das ist der Kern des Agile Manifests. Das ist die Kernaussage: Wir liefern Software für unsere Kunden und die Kunden, die in dem Sinne sind eben genau die Kunden, die ein Produkt oder eine Dienstleistung haben, und wir tun das zum Wettbewerbsvorteil des Kunden.

So, das ist also die Sicht. Und wenn man diese Sicht mal einnimmt, hängt da echt ein Rattenschwanz dran. Es ist so, dass nach meiner Erfahrung das Agile Manifest, agiles Arbeiten, eine super positive Auswirkung natürlich auch auf das Arbeitsumfeld der Agenturen oder derjenigen, die Software entwickeln, also des Dev-Teams, wenn ihr das so wollt, hat. Das ist toll. Ich will damit nicht sagen, ich will jetzt ein tolles Arbeitsumfeld abschaffen, ganz im Gegenteil. Auch das hilft natürlich, gute Software zu entwickeln. Natürlich ist es so, nur Leute, die eine Sinnhaftigkeit sehen in der Methodik, in der sie arbeiten, werden gute Arbeit leisten und werden gute Software erstellen, um jetzt mal wirklich nur bei Software zu bleiben.

Aber, und das ist ein Teil dieses Gedankenexperiments heute, das ist nur ein Nebeneffekt aus dem Agile Manifest. Man kann nicht direkt aus dem Agile Manifest ableiten, dass es eine gute Arbeitsumgebung braucht. Der Hauptanlass im Agile Manifest ist, Kunden in die Lage zu versetzen, schnell am Markt zu agieren. Man kann jetzt in diesem Gedankenexperiment noch ein, zwei Schritte weitergehen. Wie gesagt, da hängt für mich noch ein gewisser Rattenschwanz dran, nämlich wie wirkt sich das alles jetzt auf unsere Entscheidungen aus, die wir in der Agilität bei der Softwareentwicklung treffen? Agilität ist kein Selbstzweck; da steckt ein ökonomischer Gedanke dahinter.

Also, man kann sich mal dieses Experiment hier nehmen und sich die Frage stellen: Kann ich das als Basis nehmen, um mir genauer zu überlegen, warum machen wir eine Retro? Machen wir eine Retro, damit wir Potenziale finden, wie wir als Menschen miteinander agieren, oder machen wir eine Retro, um schlussendlich auf dieses Ziel einzuzahlen? Wir wollen unseren Kunden helfen, gut und schnell am Markt zu sein. Das eine bedingt vielleicht das andere, aber der Blickwinkel wäre ein bisschen ein anderer. Das gleiche können wir uns fragen bei einem Refinement: Wann und wie und wo, mit welchem Ziel machen wir ein Refinement? Oder auch bei der Frage, wie detailliert soll eine Storybeschreibung sein? Oder auch bei der Frage, was ist ein gutes Inkrement? Was ist eine kleine Version, die in sich geschlossen ist und einen Wert schafft, den wir liefern wollen? Übrigens auch die Frage rund um, was ist denn wert? Habe ich mich früher auch super schwer mitgetan, mittlerweile eigentlich nicht mehr. Aber wenn ich mich an meine agile Anfangszeit erinnere, war die Diskussion zu, was ist denn jetzt ein Wert? Das, was wir hier erstellen, liefert es einen Wert? Was für ein Wert liefert ein Bugfix? Was für ein Wert liefert eine Dokumentation? Diese Diskussion kann man jetzt viel klarer führen. Ich glaube zuallererst mal ist Wert, und das ist auch wieder eine These, Euro-Wert. Es geht wirklich darum: Beobachte mal, wenn du eine Story schreibst, zum Beispiel, oder ein Inkrement definierst oder ein Sprintziel formulierst, wie viel Wert in Euro steckt denn da wirklich drin in dem, was du lieferst? Und kannst du das maximieren, indem du eine andere Version lieferst oder eine Änderung an deiner Version vornimmst?

Wie gesagt, das Ganze ist schwer zu beschreiben. Ich habe viel Zeit investiert in die Vorbereitung auf diese Folge, viel mehr als ich das manchmal bei anderen Folgen tue. Ich finde es schwer zu erklären, was ich hier im Kopf habe. Ich habe ein bisschen Schiss, wenn ich ganz ehrlich bin, dass du das komplett falsch verstehst, was ich hier sagen will. Meine ganz, ganz große Bitte, die Bitte habe ich immer bei Folgen, ich weiß, aber meine ganz, ganz große Bitte in dieser Folge ist: Gib mir wirklich gerne Feedback, lass uns wirklich in die Diskussion gehen, weil ich glaube wirklich, dass hier ganz, ganz viel Wert in dieser Diskussion steckt. Und wenn es irgendwie geht, versuch die Diskussion öffentlich zu halten. Also auf Mastodon, am liebsten, wär mir wirklich im Forum. Ich weiß, dann musst du dich im Forum registrieren und so weiter und so fort. Es geht mir nicht darum, Content im Forum zu schaffen. Es geht mir wirklich darum, dass ich ganz gerne diese Diskussion offen haben würde und sie mit so vielen Leuten wie möglich führen würde und daraus das Ergebnis mal auch gerne zusammenführen würde.

Jetzt ist mein Reich weiter einfach nicht so groß, um schnell so viele Leute zu erreichen. Deswegen hier einfach auch nochmal die Bitte: Wenn dir das gefällt, wenn du die Diskussion interessant findest und wenn du das Gefühl hast, ich bin eine andere Meinung, aber ich würde die Diskussion gerne öffnen, gib Leuten einen Tipp, von denen du das Gefühl hast, die würden das auch interessant finden, auf diese Folge. Teile das gerne, wenn du Social Media Kanäle hast. Ich bitte da nicht so oft drum, aber es wäre mir wirklich eine Herzensangelegenheit, in dieser Diskussion einen Schritt weiterzukommen und einfach wirklich viele Leute mit dieser Diskussion zu erreichen.

Ansonsten erreichst du mich auf anderen Kanälen. Also du kannst mir eine Mail schreiben unter nobiasagilegimel.com. Wie gesagt, ich bin auf Mastodon und noch ein Hinweis: Es gibt das Forum. Du findest das in den Show Notes. Ich eröffne einen Thread in dem Forum zu dieser Folge. Das heißt, das werde ich in den Show Notes verlinken, genau zu dieser Folge. Und nochmal vielleicht denk daran, dass hier ein Gedankenexperiment ist und es soll ein bisschen schwarz-weiß auch sein, es soll ein bisschen zur Diskussion anstiften, weil ich eben wirklich glaube, dass uns allen Diskussion hilft und ich es gerne zusammenfassen möchte und gerne so eine Formulierung daraus versuchen würde, die uns allen in der Agilität meiner Meinung nach nur helfen kann.

Ja, und das soll es für heute eigentlich auch gewesen sein. Hab ganz, ganz vielen Dank fürs Teilen, fürs Zuhören und eine ganz tolle Woche. Bis zum nächsten Mal.

NBA29: Gedankenexperiment: Agiles Manifest

Shownotes

Zusammenfassung

Transkript

Featured

Subscribe

Tags