NBA06: Die 12 Agilen Prinzipien

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 eben auch der Name NoBullshit 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, in der letzten Folge habe ich über das Agile Manifest gesprochen und 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 nochmal konkretisiert und ich würde gerne einmal durchgehen und zu jedem dieser Prinzipien ein bisschen was aus meiner Sicht aus der Praxis heraus erzählen. Wir fangen mal an. Das erste Prinzip, 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 eben dieser Treiber dahinter, dass ich gerne dem Kunden früh etwas liefern möchte. Das bedeutet auch, ich möchte eigentlich meine Stories so klein, wie es irgendwie geht halten und ich möchte dafür sorgen, dass diese Versionen, den ich sie malen, die ich da liefern kann, in sich eben einen Wert haben, in sich abgeschlossen sind. Was ich für mich aus der Praxis sagen kann, ist diesen Schritt, den gehen wir noch nicht so lange und ich kann einfach sagen, da wo es funktioniert, da ist es einfach auch super, dem Kunden wirklich früh was zu liefern, um auch Feedback zu bekommen. Feedback von dessen Kunden, Feedback vom Kunden selber, Feedback vielleicht sogar aus Analytics Daten um zu sehen funktioniert das so wie wir uns das vorgestellt haben und das eben einfließen lassen in die nächsten Versionen eines Projekts. Das macht die Software Schluss endlich wertvoll. Sie wird auch Stück für Stück wertvoller, insofern ist dieses Prinzip für mich total wichtig. Das nächste schließt im Prinzip daran an, das heißt heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. 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 eben darum geht, dass wir kein Eigenzweck haben und wir keine Software für uns im Luftleeren Raum entwickeln, sondern da steckt der Nutzen des Kunden natürlich dahinter und ich habe das Gefühl, dass es manchmal ein bisschen aus dem Auge verloren wird und diese Betonung des Nutzen des Kunden hier ganz konkret sogar zum Wettbewerbsvorteil des Kunden nutzen, halte ich für ganz wichtig und eben auch wir wollen Änderungen bekommen heißen. Änderungen entstehen eben dadurch, dass wir im Projekt immer schlauer werden und das muss einfließen. Ich weiß, je nach Vertragsgestaltung mit dem Kunden sind Änderungen nicht so beliebt, das geht mir ja nicht anders, aber da muss man an der Stelle gucken, 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 Zeit spannen. Auch da ganz klar, wir wollen eben einen hohen Durchsatz haben, wir wollen früh ein Feedback bekommen, wir wollen früh feststellen, ob die Idee, die wir mit der Software haben, wirklich funktioniert. Man kann darüber nachdenken, dass das ja 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 Version zu haben. Ich bin mir auch sicher, dass man zum Beispiel feststellt, wenn man so vorgeht, dass man gar nicht alles entwickelt, was der Kunde sich mal vorgestellt hat, sondern nach vielleicht den berühmt berüchtigten 80% sagt, wir haben eigentlich alles zusammen, was wir brauchen und der Rest war mal eine gute Idee, aber mit dem Wissen, was wir heute haben, ist es gar keine gute Idee mehr. Und den Effekt bekommt man halt auch nur, wenn man regelmäßig in sehr kurzen Zeiträumen Software liefert in Version. In der nächste Punkt ist, lieblich von mir, Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten. Hier steht jetzt tatsächlich täglich und die Fachexperten sind in der Regel ja die Kunden. Fachexperten können auch, sag ich mal, aus anderen Teams kommen, also vielleicht sogar aus dem Bereich Design, aber hier sind auch Kunden mitgemeint. Und ich kann in der Praxis sagen, ich spreche nicht jeden Tag mit dem Kunden, weil der Kunde auch nicht jeden Tag Zeit hat. Das ist tatsächlich so, aber es wäre schon ideal und ich versuche halt so viel wie möglich da eine Verbindung zum Kunden zu haben und im Zweifel zwar auch das Team eben zu enable, mir fällt das deutsche Wort gerade nicht ein, dem Team das Team dazu zu bringen, zu enable. Ich bleibe jetzt einfach mal dabei, den direkten Draht zum Kunden auch zu haben. Das klappt tatsächlich ziemlich gut und wenn der Kunde Zeit hat, ist dieser regelmäßige Austausch einfach super. Das ist no-brainer eigentlich und trotzdem ist die Frequenz wie oft, spreche ich denn mit dem Kunden, mit dem Fachexperten über den Stand, hat großes, großes Potenzial. Der nächste Punkt ist auch super. Das werde ich jetzt wahrscheinlich bei jedem Punkt sagen, weil diese zwölf Prinzipien einfach wirklich für die Praxis relevant und sehr gut sind. Es lautet errichteprojekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue da drauf, dass sie ihre Aufgaben erledigen. Und das ist etwas, wo ich oft in der Praxisleute scheitern sehe. Muss man einfach so sagen, dieser letzte Punkt vertraue da drauf, dass sie ihre Aufgaben erledigen. Es ist leider immer wieder so, dass ich feststelle, dass diejenigen, die das Vertrauen geben müssen, das Vertrauen nicht geben und sich dann später fragen, warum geht es nicht weiter oder warum ist es nicht so geworden, wie ich mir das gedacht habe. 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. Das ist tatsächlich so, aber da muss man sich überlegen, ob man sich zum Beispiel von diesen Leuten trennen muss. Erst einmal gehe ich immer davon aus, dass Leute motiviert sind, Interesse daran haben, was sie da tun. Und es mag Zeiten geben, wo einzelne Leute mal eine schlechte Phase haben. Das meine ich damit nicht. Auch in einer schlechten Phase kann man motiviert sein oder kann zumindest sagen, mir geht es gerade nicht so gut oder so. Das kann man alles abfangen. Und wenn man diese motivierten Leute hat, dann muss das Umfeld ebenso sein, dass sie eben das Vertrauen auch haben, diese Motivation auch einzubringen. Und ja, wie schon gesagt, da sehe ich immer wieder Teams dranscheitern. Der nächste Punkt. Die effizienteste und effektivste Methode Information an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Ja, das Gile manifest ist von 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 tatsächlich stark geprägt ist von Video. Es ist auch vor Corona nicht möglich gewesen, immer vor Ort Meetings zu machen, also mit dem Kunden zum Beispiel. Aber vor Ort Meetings fanden viel öfter statt. Und das ist etwas, was ich stark vermisse. Das ist etwas, wo ich denke, wo viel verloren gegangen ist und tatsächlich auch innerhalb von Teams viel verloren gegangen ist, weil viele Teams einfach immer noch im Homeoffice sitzen. Ich weiß, dass viele Leute Homeoffice mögen. Das ist natürlich auch komfortabler. Aber ich sage halt einfach, da geht super viel im Bereich Kommunikation verloren. Es ist was anderes, wenn man über eine Kamera hinweg miteinander spricht, als wenn man zusammen in einem Raum sitzt. Und die Ermunterung des direkten Dialogs wirklich, sich auch wieder in Räumen zu treffen, auch Dinge wirklich mal gemeinsam an einem Whiteboard zum Beispiel zu diskutieren und zu besprechen. Also das ist für mich eine zentrale Komponente in der Führung auch, die Leute wieder zusammenzubringen und sie auch da wieder zu motivieren, hin dazu, was ich feststelle, diejenigen, die diesen Schritt gehen und sagen, ja, ich möchte aber eigentlich auch wieder, ich sehe die Vorteile, ich möchte wieder direkt mit Leuten sprechen. Die haben auch immer das Feedback, dass das schon was ist, was einfach viel besser ist. Und ja, ich vermute mal, dass in dieser Zeit des Agil Manifest, also 2001 rum eher das war, dass man versuchen soll, nicht über Telefon-Dinge zu klären oder Mail oder andere Dokumente, sondern eben da, den direkten Kontakt suchen soll. Und ich finde, das gilt heute noch genauso. Ja, kommen wir zum nächsten Punkt. Funktionierende Software ist das wichtigste Fortschrittsmaß. Das muss man als mal einsinken lassen. Es geht nicht um Velocity, es geht nicht um irgendwelche Projektfortschrittskalkulation. Das ist alles nicht das Fundament für Software-Entwicklung, sondern vollkommen richtig. Der Teil der Software, der funktioniert, das ist das Maß, wie weit sind wir. Und es nützt dann eben nichts halbfertiges Software zu haben, sondern jegliche Software, die ich, die Pleue, die ich bereit stelle, muss funktionieren. Und damit habe ich ein superverlässliches Fortschrittsmaß. Der nächste Punkt lautet, Agile-Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzern sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Superding. Wenn man sich mal mit Leuten unterhält, die nicht so tief im Agilen-Bereich sind, dann stelle ich oft fest, dass die eine Assoziation mit dem Wort Agile haben, die er in die Richtung schnell geht. Aber das ist ja überhaupt nicht gemeint mit Agile. Agile heißt ja beweglich, wir wollen auf das Umfeld reagieren. Das ist doch die Idee hinter Agile. Und deswegen finde ich so wichtig, dass hier nochmal drin steht, dass ein gleichmäßiges Tempo von allen Beteiligten eingehalten werden soll, das auf unbegrenzte Zeit halten kann. Es geht hier nicht und deswegen sind wir wieder bei "Warum ich Scrum nicht so mag", es geht hier nicht um einen Sprint. Wir wollen nicht jede Iteration sprinten, alle zwei Wochen oder alle vier Wochen, was auch immer eine Iteration ist, sondern wir machen einen Dauerlauf oder einen Dauerspaziergang. Wir wollen nachhaltig entwickeln und das bedeutet eben nicht Hetzen, sondern ein gleichmäßiges Tempo, das man unbegrenzt aufrecht erhalten kann. Find ich einfach super. Als nächstes steht hier ständiges Augenmerk auf technische Exzellenz und gutes Design, fördert Agilität. Und auch das, da stehe ich voll dahinter. Denn wenn ich darauf achte, dass ich meinen Change, also was ändert sich zum Beispiel in meinem technologischen Umfeld und das interpretiere ich hinter technischer Exzellenz, wenn ich darauf achte, das immer wieder zu bewerten und auch einfließen zu lassen, dann fördert das die Agilität in dem Sinne, dass ich eben auf die Umweltveränderung auch entsprechend schnell reagieren kann. Und das gleiche trifft Design, in zwar Design in dem Sinne, wie es hier gemeint ist, nämlich Architektur. Wie baue ich Software? Ja, der nächste Punkt lautet Einfachheit. Die Kunst, die Menge nicht getarener Arbeit zu maximieren, ist essentiell. Und genau das ist es. Das Potenzial der Erfolg einer Firma steckt da drin, so wenig wie möglich zu tun. Und das ist natürlich eine ganz, ganz hohe Kunst. Aber daran kann man arbeiten. Es gibt genug Stationen, in denen ich überlegen und reflektieren kann und eigentlich auch muss, was hat gut funktioniert, was hat nicht gut funktioniert. Wo haben wir Waste produziert, um Stück für Stück an dieser Schraube zu drehen? Der vorletzte Punkt lautet, die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Und hier steht natürlich selbstorganisierte Teams im Mittelpunkt. Und ja, selbstorganisierte Teams sind super. Was ich aber sagen kann, zu selbstorganisierten Teams kommen. Diese Schritte, die dafür nötig sind, ist beinharte Arbeit von allen Beteiligten. Auch da werde ich garantiert mindestens eine Folge zu machen. Das hat eine technische Komponente, eine organisatorische. Das hat natürlich eine menschliche Komponente. Wir sind super schnell bei dem Thema Verantwortung. Dann kommen wir ganz schnell in den Bereich vieler Kultur, was man da als Unternehmen machen muss. Aber schlussendlich, ja, definitiv ist es so, selbstorganisierte Teams sind das große Ziel. Und 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. Da gibt es natürlich viele Mechanismen für. Eins ist die ganz bekannte Retro. In meinen Augen muss es viel mehr Steps als nur eine Retro geben. Also, man muss regelmäßig lessons learned auch machen. Auf einer technischen Ebene, auf einer menschlichen Ebene, die Reflexion gehört für mich ganz klar zum entwickeln dazu. Das ist im Kleinen schon die Reflexion, wenn ich TDD Test-Refin-Development mache. Wenn mein Test fehlt, da habe ich schon wieder einen Punkt für eine mögliche Reflexion. Ich hatte mal eine Folge gemacht zum Open Space. Das ist auch ein Supermittel für eine Reflexion. Was hat gut funktioniert, welche technischen Trends gibt es und wie können wir die bei uns einfließen lassen? Und natürlich ist es so, wenn man reflektiert, hat man große, große Möglichkeiten, sich zu verändern, sich anzupassen. Da haben wir einen schönen Überblick nochmal über die 12 Agilentprinzipien bekommen. Ich denke, sie sind super bedeutend. Ich denke, sie werden auch ähnlich zu dem, was ich in Folge 5 gesagt habe, dem Agilentmanifest in der Praxis auch zu wenig benutzt. Auch das ist was, wo man sich überlegen kann, auf welche Art und Weise kann man die Präsent halten. Auch da bin ich überlegen, ob ich ein bisschen Schaubildmaterial mal bereit stelle, um auch das für mich und für mein Team besser präsent zu halten, vor allen Dingen an dem Punkt, wo man zum Beispiel Entscheidungen trifft. Und wie ich schon gesagt habe, das soll es eigentlich für heute schon gewesen sein. Wenn du Feedback hast, dann gerne als zum Beispiel Mail an nobsagile@gmail.com. Alternativ findest du mich auch auf Masst oder unter nobile@podcast.social. Zur Diskussion habe ich einen Subreddit angelegt. Die Adresse zu dem Subreddit findest du in den Show Notes. Hab eine ganz tolle Woche und bis zum nächsten Mal! SWR 2017