NBA06: Die 12 Agilen Prinzipien

Ich bespreche die 12 Agilen Prinzipien und deren Bedeutung für die Praxis.

Shownotes

Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile. 

Fragen oder Anregungen zu der Folge? Dann gerne hier: https://forum.no-bullshit-agile.de/d/8-nba06-die-12-agilen-prinzipien

—

Letzte Folge „NBA05: Ist das Agile Manifest noch relevant?“ - https://no-bullshit-agile.podigee.io/5-agile-manifest

Die 12 Agilen Prinzipien - https://agilemanifesto.org/iso/de/principles.html

NBA03: Open Space - https://no-bullshit-agile.podigee.io/3-open-space

Zusammenfassung

In Folge 6 von No Bullshit Agile beleuchtet Thomas die 12 agilen Prinzipien aus dem Agile Manifest und deren praktische Relevanz. Er geht auf jedes Prinzip ein und erklärt, wie es in der Praxis umgesetzt werden kann:

1. Frühe und kontinuierliche Auslieferung: Kunden sollen frühzeitig und regelmäßig wertvolle Software erhalten, um Feedback zu integrieren und kontinuierlich Mehrwert zu schaffen.

2. Anforderungsänderungen willkommen heißen: Veränderungen, auch spät im Projekt, sollen genutzt werden, um dem Kunden einen Wettbewerbsvorteil zu verschaffen.

3. Regelmäßige Lieferung funktionierender Software: Kurze Lieferzyklen fördern schnelles Feedback und ermöglichen es, die Software regelmäßig anzupassen und zu verbessern.

4. Tägliche Zusammenarbeit von Fachleuten und Entwicklern: Idealerweise sollten Fachleute und Entwickler regelmäßig, auch täglich, zusammenarbeiten, um direktes Feedback und schnelle Anpassungen zu ermöglichen.

5. Motivierte Individuen: Projekte sollten um motivierte Personen herum aufgebaut werden, die das nötige Umfeld und Vertrauen erhalten, um ihre Aufgaben erfolgreich zu erledigen.

6. Gespräch von Angesicht zu Angesicht: Die effektivste Kommunikationsmethode ist der direkte persönliche Austausch, um Missverständnisse zu vermeiden und schnelle Entscheidungen zu treffen.

7. Funktionierende Software als Fortschrittsmaß: Der Fortschritt wird an der Funktionsfähigkeit der Software gemessen, nicht an abstrakten Kennzahlen wie Velocity.

8. Nachhaltige Entwicklung: Ein gleichmäßiges und nachhaltiges Arbeitstempo ist wichtiger als kurzfristige Schnelligkeit.

9. Technische Exzellenz und gutes Design: Höchste technische Qualität und gutes Design fördern die Agilität und Anpassungsfähigkeit.

10. Einfachheit: Die Kunst, möglichst wenig Arbeit zu erledigen, um Verschwendung zu minimieren, ist entscheidend für den Erfolg.

11. Selbstorganisierte Teams: Die besten Ergebnisse entstehen durch selbstorganisierte Teams, die Verantwortung übernehmen und eigenständig arbeiten.

12. Regelmäßige Reflexion und Anpassung: Teams sollten regelmäßig reflektieren, wie sie effektiver werden können, und ihr Verhalten entsprechend anpassen.

Thomas betont, dass diese Prinzipien oft in der Praxis zu wenig beachtet werden, obwohl sie essenziell für erfolgreiche agile Projekte sind.

Transkript

Hallo und herzlich willkommen bei No Bullshit 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 eben auch der Name No Bullshit Agile.

In der letzten Folge habe ich über das Agile Manifest und dessen Relevanz gesprochen. Dies ist die Folge 6, und heute geht es um die 12 Agilen Prinzipien und deren Bedeutung für den Alltag. Wie schon gesagt, habe ich in der letzten Folge über das Agile Manifest gesprochen. Heute soll es um die Prinzipien hinter dem Agilen Manifest gehen. Die Kollegen haben sich nämlich auch damals 2001 zusammengesetzt und das Agile Manifest mit 12 Prinzipien konkretisiert. Ich würde gerne einmal durchgehen und zu jedem dieser Prinzipien ein bisschen aus meiner Sicht aus der Praxis heraus erzählen.

Wir fangen mal an:

Das erste Prinzip lautet: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ Was steckt wohl dahinter? Es steckt auf jeden Fall der Treiber dahinter, dass ich gerne dem Kunden früh etwas liefern möchte. Das bedeutet auch, ich möchte meine Stories so klein wie möglich halten und dafür sorgen, dass diese Versionen, die ich liefern kann, in sich einen Wert haben und abgeschlossen sind.

Was ich aus der Praxis sagen kann, ist: Diesen Schritt gehen wir noch nicht so lange, und ich kann einfach sagen, dass es dort, wo es funktioniert, super ist, dem Kunden wirklich früh etwas zu liefern, um Feedback zu bekommen. Feedback vom Kunden, Feedback vielleicht sogar aus Analytics-Daten, um zu sehen, ob das funktioniert, wie wir uns das vorgestellt haben, und das in die nächsten Versionen eines Projekts einfließen zu lassen. Das macht die Software schließlich wertvoll. Sie wird auch Stück für Stück wertvoller, insofern ist dieses Prinzip für mich total wichtig.

Das nächste Prinzip lautet: „Anforderungsänderungen selbst spät in der Entwicklung willkommen heißen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“ Was ich daran schön finde, ist, dass der Kunde hier im Mittelpunkt steht und dass es darum geht, dass wir kein Eigenzweck haben und keine Software für uns im luftleeren Raum entwickeln, sondern der Nutzen des Kunden im Vordergrund steht. Es ist manchmal ein bisschen aus dem Auge verloren gegangen, aber die Betonung des Nutzen des Kunden hier konkret zum Wettbewerbsvorteil zu nutzen, halte ich für ganz wichtig. Änderungen entstehen durch unser Wachstum im Projekt und müssen einfließen.

Ich weiß, je nach Vertragsgestaltung mit dem Kunden sind Änderungen nicht immer beliebt, das geht mir nicht anders. Aber man muss überlegen, wie man andere Vertragsgestaltungen finden kann. Das wird garantiert auch Thema einer dedizierten Folge werden.

Das nächste Prinzip lautet: „Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzeren Zeitspannen.“ Auch hier ist klar: Wir wollen einen hohen Durchsatz haben, früh Feedback bekommen und früh feststellen, ob die Idee, die wir mit der Software haben, wirklich funktioniert. Man kann darüber nachdenken, dass das der MVP-Gedanke ist, und das stimmt, aber der MVP-Gedanke ist mir hier zu kurz. Wie ich schon vorhin gesagt habe, mir geht es darum, über das gesamte Projekt hinweg kleine Versionen zu haben.

Ich bin mir sicher, dass man zum Beispiel feststellt, wenn man so vorgeht, dass man gar nicht alles entwickelt, was der Kunde sich vorgestellt hat. Nach vielleicht den berühmten 80% sagt man, dass man alles zusammen hat, was man braucht, und der Rest war mal eine gute Idee, aber mit dem Wissen von heute ist es keine gute Idee mehr. Diesen Effekt bekommt man nur, wenn man regelmäßig in sehr kurzen Zeiträumen Software liefert.

Der nächste Punkt lautet: „Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.“ Hier steht tatsächlich täglich, und die Fachexperten sind in der Regel auch die Kunden. Fachexperten können auch aus anderen Teams kommen, beispielsweise aus dem Bereich Design. In der Praxis spreche ich nicht jeden Tag mit dem Kunden, weil der Kunde auch nicht jeden Tag Zeit hat. Das ist tatsächlich so. Es wäre jedoch ideal, regelmäßig mit dem Kunden in Kontakt zu bleiben und im Zweifel das Team so zu unterstützen, dass ein direkter Draht zum Kunden besteht.

Das klappt tatsächlich ziemlich gut, und wenn der Kunde Zeit hat, ist dieser regelmäßige Austausch super. Der Punkt „Frequenz des Austauschs“ hat großes Potenzial.

Der nächste Punkt lautet: „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie ihre Aufgaben erledigen.“ Hier sehe ich oft in der Praxis, dass der letzte Punkt – Vertrauen darauf, dass Aufgaben erledigt werden – nicht immer gegeben ist. Es ist leider immer wieder so, dass ich feststelle, dass diejenigen, die das Vertrauen geben müssen, dies nicht tun und sich dann fragen, warum es nicht weitergeht oder warum es nicht so geworden ist, wie sie es sich vorgestellt haben.

Ich gehe immer davon aus, dass Leute, die an einem Projekt arbeiten, motiviert sind. Wenn sie das nicht sind, dann sind es die falschen Leute. Natürlich gibt es auch Zeiten, in denen einzelne Personen eine schlechte Phase haben. Das meine ich damit nicht. Auch in einer schlechten Phase kann man motiviert sein oder zumindest sagen, dass es einem nicht so gut geht. Das kann man alles abfangen. Wenn man motivierte Leute hat, muss das Umfeld so sein, dass sie das Vertrauen auch haben, ihre Motivation einzubringen. Leider sehe ich immer wieder Teams daran scheitern.

Der nächste Punkt lautet: „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“ Ja, das Agile Manifest stammt aus dem Jahr 2001, da gab es Corona noch nicht. Und ja, auch über Kommunikation werde ich garantiert mindestens eine Folge machen. Wir haben uns einen Kommunikationsstil angewöhnt, der stark von Video geprägt ist. Vor Corona war es auch nicht immer möglich, vor Ort Meetings zu machen, aber vor Ort Meetings fanden viel öfter statt. Das vermisse ich sehr.

Es geht viel im Bereich Kommunikation verloren, wenn man über eine Kamera hinweg spricht, statt zusammen in einem Raum zu sitzen. Die Ermunterung zum direkten Dialog und das Treffen in Räumen, um Dinge gemeinsam an einem Whiteboard zu diskutieren, sind für mich zentrale Komponenten in der Führung. Diejenigen, die diesen Schritt gehen und die Vorteile des direkten Gesprächs sehen, haben immer das Feedback, dass dies viel besser ist. Ich vermute, dass in der Zeit des Agile Manifest, also um 2001 herum, der direkte Kontakt gewünscht war und nicht Telefon, E-Mail oder andere Dokumente. Das gilt heute noch genauso.

Der nächste Punkt lautet: „Funktionierende Software ist das wichtigste Fortschrittsmaß.“ Das muss erst einmal einsinken. Es geht nicht um Velocity oder Projektfortschrittskalkulationen. Das Fundament der Software-Entwicklung ist der Teil der Software, der funktioniert. Halbfertige Software nützt nichts. Jegliche Software, die ich bereitstelle, muss funktionieren. Damit habe ich ein verlässliches Fortschrittsmaß.

Der nächste Punkt lautet: „Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.“ Wenn man sich mit Leuten unterhält, die nicht so tief im Agilen Bereich sind, stelle ich oft fest, dass sie Agile mit Schnelligkeit assoziieren. Aber Agile bedeutet Beweglichkeit und die Fähigkeit, auf das Umfeld zu reagieren. Daher ist es wichtig, dass ein gleichmäßiges Tempo eingehalten wird, das unbegrenzt aufrechterhalten werden kann. Es geht nicht um Sprinten, sondern um einen Dauerlauf oder Spaziergang. Nachhaltige Entwicklung bedeutet nicht Hetzen, sondern ein gleichmäßiges Tempo.

Der nächste Punkt lautet: „Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“ Auch das unterstütze ich voll und ganz. Wenn ich darauf achte, meine technologischen Änderungen und die Architektur der Software zu bewerten und einfließen zu lassen, fördert das die Agilität. Man kann schnell auf Umweltveränderungen reagieren.

Der nächste Punkt lautet: „Einfachheit. Die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essentiell.“ Genau das ist es. Der Erfolg einer Firma steckt darin, so wenig wie möglich zu tun. Es ist eine hohe Kunst, aber daran kann man arbeiten. Man kann regelmäßig reflektieren, was gut funktioniert hat und wo Waste produziert wurde, um kontinuierlich an dieser Schraube zu drehen.

Der vorletzte Punkt lautet: „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“ Selbstorganisierte Teams sind super, aber die Schritte, die nötig sind, um dorthin zu gelangen, erfordern harte Arbeit von allen Beteiligten. Dazu werde ich sicherlich mindestens eine Folge machen. Das hat technische, organisatorische und menschliche Komponenten. Selbstorganisierte Teams sind das große Ziel.

Der zwölfte und letzte Punkt lautet: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“ Dafür gibt es viele Mechanismen. Die bekannte Retro ist ein Beispiel, aber es sollten auch andere Schritte wie Lessons Learned auf technischer und menschlicher Ebene gemacht werden. Reflexion gehört zum Entwickeln dazu, sei es beim TDD (Test-Driven Development) oder in einem Open Space. Die Reflexion ermöglicht es, sich zu verändern und anzupassen.

Das war ein schöner Überblick über die 12 Agilen Prinzipien. Ich denke, sie sind super bedeutend und werden, ähnlich wie das Agile Manifest in Folge 5, in der Praxis oft zu wenig beachtet. Vielleicht werde ich ein bisschen Schaubildmaterial bereitstellen, um das besser präsent zu halten, insbesondere bei Entscheidungen.

Das soll es für heute gewesen sein. Wenn du Feedback hast, dann gerne per E-Mail an nobsagile@gmail.com. Alternativ findest du mich auch auf Mastodon.

Hab eine ganz tolle Woche und bis zum nächsten Mal!