NBA49: Der agile Eisberg

Der agile Eisberg: Warum die Oberfläche nicht reicht.

Zusammenfassung

Agilität wird oft auf Methoden wie Scrum oder Kanban reduziert – die Spitze des Eisbergs. Doch was liegt darunter? In dieser Folge von No Bullshit Agile tauchen wir tief ein und sprechen über die unsichtbaren, aber entscheidenden Grundlagen agiler Arbeitsweisen. Denkweisen, Prinzipien, technische Fähigkeiten und echte Zusammenarbeit: Diese Elemente sind das Fundament, auf dem Agilität aufbaut. Ohne sie bleiben Methoden wie Scrum oft wirkungslos. Erfahre, warum der Fokus auf die „unsichtbaren“ Aspekte entscheidend ist, welche kulturellen und strukturellen Veränderungen notwendig sind und wie dein Team von kleinen, iterativen Schritten profitieren kann, um nachhaltig agil zu arbeiten.

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile. Ich bin Thomas, ich bin Teil eines agilen Teams und hier geht es jede Woche um die echten Herausforderungen in der agilen Welt. Praxisnah und direkt auf den Punkt. Agilität ist meiner Meinung nach kein Hype und ist auch keine Sammlung von Buzzwords. Und Agilität ist auch nicht tot, auch wenn man das immer wieder liest. Agiles Vorgehen ist für mich das einzig sinnvolle Vorgehen. Leider wird zu viel Bullshit obendrauf aufgepackt und dem möchte ich mit diesem Podcast entgegnen. In der letzten Folge habe ich ein bisschen tiefer in WiP-Limits reingeschaut. Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du in den Shownotes. Das hier ist die Folge 49 und heute geht es darum, was Menschen oft denken, was agiles Arbeiten wohl ist und was meiner Meinung nach noch alles dazu gehört. Es soll heute um den agilen Eisberg gehen. Bevor wir in das Thema einsteigen, habe ich eine Frage an dich. Ich hatte ein Feedback bekommen, dass die Audioqualität von dem Podcast nicht so gut ist. Ja, war so ein bisschen das Feedback. Klingt komisch dumpf manchmal und ich habe jetzt tatsächlich ein bisschen was umgestellt. Ich freue mich über solches Feedback ja immer. Und meine Bitte wäre, hörst du einen Unterschied? Also wenn du einen Unterschied überhaupt hörst, würde ich ganz gerne wissen, ist es jetzt besser oder schlechter. Da freue ich mich auf ein Feedback. Wie du mich erreichen kannst, dazu findest du alle Infos in den Shownotes. Vielen Dank an dieser Stelle schon mal. Ja und dann würde ich ganz gerne in den agilen Eisberg einsteigen. Ich habe dazu eine kleine Grafik gemalt, die habe ich auch veröffentlicht. Auch dazu habe ich Feedback bekommen. Auch hier nochmal vielen Dank. Unter anderem gab es das Feedback, ob der Eisberg wirklich so schwimmen würde, wie ich ihn gemalt habe. Und da gibt es ja auch so Simulationen zu. Meiner schwimmt ganz bestimmt. Da bin ich ganz, ganz sicher. Schöne Grüße gehen raus. Ich fange mal mit einer Geschichte an. Als wir mit Scrum angefangen haben, das ist schon sehr lange her, habe ich halt mir ganz fest vorgenommen, wir arbeiten ganz genau nach dem Scrum Guide. Wirklich nach Playbook. Genauso wie es da steht. Keine Abweichung, kein Verwischen von Dingen, keine Abkürzung gehen. Und ich war mir eigentlich sicher, dass wir dann wirklich agil arbeiten. Das war eine gute Idee, sich daran zu halten, aber es war tatsächlich auch naiv im Nachhinein. Warum war es naiv? Naja, also wir kommen ja gleich auf diesen Eisberg und dann werdet ihr ganz schnell feststellen, wenn ihr es eh nicht schon kennt, was es eigentlich unterhalb einer Methode, also in unserem Fall dann Scrum, braucht, um wirklich agil zu arbeiten. Um wirklich das Ziel des agilen Arbeitens zu erreichen, nämlich sehr gute Software schnell zu liefern. Und ja, ich wusste es damals halt nicht besser. Und deswegen würde ich ganz gerne heute ein bisschen über diesen agilen Eisberg reden. Das Bild übrigens, habe ich gar nicht gesagt, das sollte eigentlich bei dem Podcast-Payern, wo es funktioniert, auch in den Chapter Marks auftauchen. Und natürlich findest du es in den Shownotes, beziehungsweise auf der Webseite zu genau dieser Folge 49. Agiles Arbeiten wird oft, siehe auch mein Beispiel von eben gerade, verstanden als man braucht eine Methode, also vielleicht Scrum und dann braucht man Daily und es gibt ein PO und es gibt einen Scrum Master und es gibt den Scrum Guide von mir aus in diesem Fall. Und dann ist das agiles Arbeiten. Das ist das, was man so an der Spitze des Eisbergs sieht. Aber wie ein Eisberg halt so ist, der größere Teil dessen liegt unterhalb der Wasseroberfläche. Und das würde ich ganz gerne mal durchgehen. Es ist halt unheimlich wichtig, sich mit diesen Dingen unterhalb der Oberfläche zu beschäftigen. Erst dann kann man dieses Potenzial von agilen Arbeiten ausschöpfen. Tut man das nicht, kommt man natürlich genau in diese Situation, dass man feststellt, eine Methode funktioniert bei uns nicht. Bei anderen scheint sie zu funktionieren. Und ja, dann ist ziemlich schnell dahingesagt, Scrum funktioniert bei uns nicht. Oder eben auch Agilität ist tot. Das liegt oft oder sehr, sehr oft gar nicht wirklich daran, sondern es liegt daran, und ich nehme mich da ja nicht raus, hier mal ein Beispiel von oben, dass der Blick nur auf diese Spitze von diesem Eisberg geht. Schauen wir mal unter die Oberfläche. Ich habe hier vier Bereiche und die würde ich ganz gerne mal durchgehen. Du findest dann, ich beschreibe das Bild jetzt gerade nochmal ein bisschen von dem Eisberg, unterhalb der Oberfläche auch viele Wortgruppen und die habe ich hier nochmal ein bisschen kategorisiert und ich fange mal an mit Denkweisen und Prinzipien. Das erste, was wahrscheinlich ins Auge fällt, uns allen einfällt und ich hier in den Folgen, in dem Podcast ja auch immer wieder behandle, ist das agile Manifest und die zwölf agilen Prinzipien. Die solltest du kennen, die solltest du auch versuchen immer wieder anzuwenden. Dazu gibt es zwei Folgen, die ich mal gemacht habe, NBA 05 und NBA 06, auch die sind in den Show Notes verlinkt. Aber dazu gehört mehr als nur diese Prinzipien. Es gibt weitere Denkweisen, weitere Methodiken, die wichtig sind, zum Beispiel Servant Leadership, aber auch Vertrauen, Vertrauen geben, eine vertrauensvolle Umgebung schaffen. Nur da drin können andere Elemente, die jetzt gleich auch noch kommen, überhaupt leben. Es gehört dazu Transparenz, es gehört dazu Empowerment. Diese Einstellungen bereiten das Umfeld, in dem Menschen ihr Potenzial überhaupt entfalten können und in dem überhaupt gelernt und verändert werden kann. Und wir wollen selbstorganisierte Teams. Überhaupt Dinge funktionieren und die muss ich in Strukturen vorbereiten und die müssen, die muss vorhanden sein. Ich brauche eine offene und ehrliche und permanente Kommunikation mit allen beteiligt, mit den Stakeholdern, mit den Teammitgliedern, mit, ja ich nehme ja jetzt Scrum ruhig, dem PO. Das ist unheimlich wichtig. Und Unternehmen, die die Kultur dieser Veränderung nicht haben, die werden einfach ganz große Probleme bekommen, wirklich agil zu arbeiten. Die dritte Säule sind die technischen Skills. Natürlich, ich sag mal, wir gehen mal davon aus, wir sind ein Unternehmen, das agile Software entwickeln will, dann müssen die Leute programmieren können. Aber es gibt weitere technische Skills. Inkrementelle Entwicklung ist wichtig, um überhaupt in diesen Modus zu kommen, das schnellen Feedbacks. Und nur durch schnelles Feedback kann ich gute Software entwickeln. Die Iteration ist das, was uns schnell macht. Wenn wir lange brauchen, um etwas auf die Straße zu kriegen, kriegen wir sehr spät Feedback. Und das bedeutet, unsere Softwarequalität ist nicht gut. Je schneller wir ein Inkrement liefern können und je kleiner das Inkrement ist, desto schneller kommen wir ins Feedback, desto besser wird die Qualität. Und nur so schaffen wir es, Software schnell und in guter Qualität zu liefern. Als Sicherheitsnetz für dieses schnelle Entwickeln brauche ich dann automatisierte Tests. Also Unit-Tests, Acceptance-Tests, Functional-Tests, Security-Tests, Barrierefreiheitstests. Das kann man länger auflisten, aber die Tests haben deswegen eine so große Bedeutung, weil sie mir Sicherheit geben in meinem schnellen Entwickeln. Es kann beim schnellen Entwickeln nichts schief gehen, wenn ich denn die Tests habe. Also brauche ich die Skills im Bereich TDD Test-Driven Development. Damit ich jetzt auch den Prozess des Releasens schnell machen kann, brauche ich eine automatisierte Release-Pipeline. Da reden wir also über Continuous Delivery, Continuous Integrations. Da gehören die Tests mit rein. Ich muss aber auch die Möglichkeit haben, so oft wie es geht, möglichst kontinuierlich Code in Produktion zu bringen. Auch das, das Ziel davon ist es, schnell in diesen Feedback-Zyklus zu kommen. Das ist also alles überhaupt kein Selbstzweck oder Funky-Stuff, sondern eine notwendige Basis, um schnell und in guter Qualität zu liefern, um in Feedback-Zyklen zu kommen. Und die vierte Säule, die ich habe, die ist Kollaboration. Es braucht die Möglichkeit, dass Leute gemeinsam arbeiten können. Und dazu brauche ich Skills wie Pair- oder Mob-Programming und auch eine Umgebung, die das unterstützt. Ich brauche die permanente Kundenbeteiligung im Bereich der Anforderungserhebung. Also das Schreiben von Anforderungen, von Storys in der Regel, das Schreiben von Acceptance-Criterias, aber eben auch hinten, nämlich in den Feedback-Zyklen. Auch da muss ich eine kollaborative Umgebung haben, um eben diese Elemente auch zu verbinden. Und das sind erstmal so, wie ich sie mir jetzt überlegt habe, wir Säulen mit den jeweiligen methodischen Ansätzen innerhalb dieser Säulen. Es gibt sicherlich jeweils viel weitere Punkte, die man noch erwähnen kann. In dem agilen Eisbergbild stehen auch sicherlich ein paar mehr Begriffe drin. Aber ich denke, ihr seht schon ungefähr, wo das Ganze drauf hinausläuft. Als Fazit kann ich sagen, agiles Arbeiten kann nur gut funktionieren, wenn auch die angesprochenen Themen unter der Oberfläche stimmen und angewendet werden. Ihr seht das jetzt schon. Wenn ich mit meinem Beispiel von vorhin komme, als wir angefangen haben mit Scrum und dieses, ich nehme mir vor, wir arbeiten strikt nach dem Scrum-Guide und dann sind wir agil. Das war naiv und das, also es hat bei uns funktioniert, aber eben, da ist so viel Luft drin gewesen, weil ich eben den Teil unter dem Eisberg nicht gesehen habe. Und ja, das ist wichtig, sich das einfach vor Augen zu führen, damit Methoden überhaupt funktionieren. Solche Methoden wie Scrum, um jetzt noch ein anderes Bild reinzubringen, das ist im Prinzip das Sahnehäubchen obendrauf. Es braucht eigentlich gar nicht die Methode, sondern es braucht viel eher die Dinge unter der Oberfläche. Eine Methode, Scrum oder Kannwarn, die hilft nur, dann die Sachen, ich sag mal, in einem organisierten Rahmen umzusetzen. Aber es ist eher wichtig, den unteren Teil des Eisbergs zu beackern, als den oberen. Sauber eingeführte Scrum macht noch lange nicht agil. Habe ich die unteren Prinzipien verstanden und kann ich die in meinem Unternehmen anwenden, bin ich deutlich schneller agil. Und dann kann ich eine Methode natürlich obendrauf setzen. Es ist halt, und das ist ein bisschen das Verlockende daran, sehr leicht, diesen oberen Teil zu machen, also eine Methode umzusetzen. Die Dinge unterhalb der Oberfläche sind deutlich schwerer. Also kulturelle Veränderungen, lernende Organisationen, das ist super schwer, weil es eben nicht so anfassbar und so konkret ist. Aber deswegen sind die unteren Dinge nicht optional, ganz im Gegenteil. Sie sind das Fundament, die Basis und die große Masse, um wieder zurück zum Eisbergbild zu kommen, um agil zu arbeiten. Aus der Praxis kann ich halt tatsächlich Folgendes sagen, also unsere Scrum-Zeit ist schon lange her. Wir machen ja Kannwarn, aber wir haben viel an diesem unteren Teil gearbeitet. Und ja, Kannwarn hilft uns dann, aber der untere Teil ist eben der wichtige. Es hilft, diesen Eisberg im Blick zu haben. Es hilft einfach, dieses Bild vor Augen zu haben, um sich bewusst zu machen, welche Themen denn überhaupt angegangen werden müssen. Und vor allen Dingen hilft der Blick dahin, wenn ihr das Gefühl habt, es läuft nicht so rund. Ich hatte ja vorhin gesagt, liest man ja auch immer wieder gerne auf Mastodon zum Beispiel oder in anderen Artikeln auf LinkedIn zum Beispiel. Ja, Scrum funktioniert für uns nicht. Und vielleicht ist das so ein Ansatzpunkt zu sagen, na, vielleicht funktioniert Scrum schon. Lasst mal auf den unteren Teil vom Eisberg gucken. Diese Themen im unteren Teil des Eisbergs, hatte ich ja schon gesagt, sind sicherlich schwieriger als die oberen Themen. Ich kann da nur den Tipp geben, auch hier kann man iterativ vorgehen. Immer schön kleine Baby-Steps. Und jede positive Entwicklung, die wird euch in großen Schritten helfen, agiler und agiler zu werden. Kontinuierliches Lernen und Verbessern, das ist mein Tipp hier. Stück für Stück diese Dinge abarbeiten. Ja, und ich denke, damit sind wir durch. Ich hoffe, das hat dir hier gefallen. Ich hoffe, das hat dir vielleicht sogar was gebracht. Wie sind deine Erfahrungen? Wie immer, ich freue mich über Feedback. Denk daran, Audioqualität, das, was ich vorhin im Housekeeping hatte. Wenn du dazu ein Feedback hast, schreib mir eben auch ganz gerne. Alle Kontaktinformationen sind in den Shownotes. Eine Bitte habe ich da noch. Wenn dir das hier gefallen hat, dann teil das gerne mit deinen Kolleginnen. Teil es gerne auf Social Media. Je mehr Leute wir hier mit dem Podcast erreichen, je größer, je breiter wird die Diskussion rund um agiles Vorgehen. Und genau darum geht es mir mit diesem Podcast. Vielen, vielen Dank dafür. Habt noch eine ganz tolle Woche. Und bis zur nächsten Folge bei No Bullshit Agile.