NBAK01: Gute Software schnell liefern

Agiles Arbeiten in einem Satz: Gute Software schnell liefern. In der ersten Folge von NBA Kompakt zerlege ich diesen Leitsatz in seine drei Bestandteile und erkläre, warum am Ende nur zwei Wörter übrig bleiben: Work und Feedback.

Überblick

Was bedeutet „gut", was heißt „schnell", und warum ist „liefern" so entscheidend? In dieser Folge nehme ich den zentralen Leitsatz agilen Arbeitens auseinander. Ich zeige, warum das agile Dreieck den Umfang flexibel macht statt die Qualität, und warum 80% der Scrum-Nutzer nicht wissen, warum sie Scrum machen. Am Ende bleiben zwei Wörter: Work und Feedback.

Shownotes

• Work-Feedback Loop
• Buch "Agiles Arbeiten in der Praxis"

Zusammenfassung

Agiles Arbeiten lässt sich auf einen Leitsatz reduzieren: Gute Software schnell liefern. „Gut" bedeutet wertvoll für den Nutzer und technisch solide. „Schnell" meint kurze Feedbackzyklen statt langer Planungsphasen. „Liefern" heißt: tatsächlich in Produktion bringen - halbfertige Features zählen nicht. Das agile Dreieck dreht die klassische Logik um: Statt den Umfang festzuschreiben und Qualität zu opfern, wird der Umfang flexibel gehalten und der Fokus auf maximalen Wert gelegt. Am Ende ist agiles Arbeiten nichts anderes als Work und Feedback. Kein Framework, kein Buzzword sondern Handwerk. Und ehrlich gesagt: Agiles Arbeiten ist Overhead, der sich nur lohnt, wenn die Arbeit komplex genug ist.

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile Kompakt. Mein Name ist Thomas. Zuerst einmal eine kleine Einleitung. Einige von euch kennen den Podcast vielleicht. Ich habe mal 87 Folgen gemacht, No Bullshit Agile. Die Folgen waren alle, ja, ich sage mal unsortiert. Da habe ich mir jede Woche einfach ein Thema überlegt, was für mich gerade ein bisschen aktuell war und habe so 20 Minuten zu einem Thema gesprochen. Dann habe ich eine Pause gemacht, weil ich das Gefühl hatte, ich hatte irgendwie alles schon erzählt und jetzt so langsam hat sich eine Idee entwickelt, nämlich ich nehme alles das, was ich bisher so rund um das Agile Arbeiten gelernt habe, bringe das mal in eine sinnvolle Reihenfolge und mache so fünf Minuten kompakt zu einem ganz speziellen Thema eine Folge. Und deswegen heißt dieser Podcast oder diese Season, sagt man ja manchmal auch, No Bullshit Agile Compact. Stand jetzt werden das 66 Folgen sein. Es gibt dazu tatsächlich auch schon eine Übersichtsseite, die ist in den Shownotes verlinkt, wo ihr seht, was ich so vorhabe, was die nächsten Folgen sind. Der Unterschied zu dem alten Podcast ist halt tatsächlich, dass ich einen kompletten Plan habe und die Folgen aufeinander aufbauen. Man kann auch einzelne Folgen hören. Ich glaube, das wird kein Problem sein, weil die Themen abgeschlossen sind. Aber es gibt schon eine gewisse logische Reihenfolge. Und mein Ziel ist, diese Folge hier wird wahrscheinlich ein bisschen länger werden, tatsächlich zu sagen, okay, ich versuche mal so kompakt wie es geht, fünf Minuten circa, mich mit einem Thema zu beschäftigen. Ich möchte anfangen mit, ja, ich sag mal wirklich dem Fundament. Ihr habt schon gesehen, die Folge heißt Gute Software schnell liefern. Das ist für mich einer der fundamentalen Sätze, wenn es darum geht zu verstehen, worum geht es überhaupt bei agiler Entwicklung oder wenn wir darüber sprechen, dass wir agil arbeiten wollen oder müssen. Bevor wir da anfangen, ist es für mich noch fundamentaler zu sagen, agiles Arbeiten besteht im Grundsatz aus einer Schleife, die besteht aus Arbeit, Work und Feedback, das ich zu diesem Teil der Arbeit bekomme und dieses Feedback soll bitte in die nächste Iteration der Arbeit einfließen. Und so gibt sich so einen Kreislauf, Work und Feedback und das ist mir sehr wichtig. Ich glaube, das ist eins der Kernfundamente, dass wir feststellen, wir arbeiten in so einer Loop und Feedback, das wir bekommen, soll in den nächsten Schritt der Arbeit einfließen. Das ist vielleicht dann zum allerersten ein bisschen zu abstrakt und deswegen habe ich mir diesen Satz überlegt. Worum geht es überhaupt? Es geht darum, gute Software schnell zu liefern. Und jedes dieser drei Worte, gut, schnell, liefern, hat eine ganz wichtige Bedeutung. Wir fangen mal bei dem Gut an. Da geht es nicht um perfekte Software. Es geht darum, Gute zu liefern, wertvolle. Und Gut heißt, wir haben eine gute Qualität, wir liefern einen guten Benutzerwert. Das Ganze ist technisch solide. Es muss auch nicht 100% sein. Es geht nicht darum, akademisch gute Software zu schreiben, sondern es geht darum, um solide Software zu schreiben. und wir wollen auch nur das Richtige und das Notwendige für diesen ersten Schritt oder für diesen einen Schritt bauen. Wir wollen auch nicht alles, was potenziell möglich wäre, bauen. Das soll dieses Wort gut in gute Software schnell liefern ausdrücken. Das nächste ist schnell. Es geht uns darum, dass wir möglichst kurze Zyklen haben. Es geht nicht darum, hektisch schnell zu sein. Wir wollen nicht fuschen, wir wollen nicht irgendwie etwas schnell hinbekommen, sondern wir wollen schnell liefern, damit wir schnell Feedback bekommen. Wenn wir drei Monate lang an etwas bauen, bevor das überhaupt irgendjemand sieht oder benutzt, dann haben wir im Prinzip drei Monate Annahmen aufeinander gestapelt. Wir wissen doch gar nicht, ob das funktioniert. Und deswegen ist das schnell schon wichtig, aber bitte nicht verwechseln mit husch husch, sage ich mal. Und das letzte Wort in diesem Satz ist liefern. Da geht es mir darum, wir müssen das auf die Straße bringen. Leute müssen es benutzen können. Wir müssen herausfinden können, funktioniert das, um diese Work Feedback Loop zu schließen. Erst wenn es wirklich benutzt wird, haben wir überhaupt eine Chance, Feedback zu bekommen und diesen Kreis zu starten, damit das Feedback in unseren nächsten Schritt der Arbeit einfließen kann. Also das sieht man auch an den agilen Prinzipien. die werden natürlich auch eine Folge werden. Das agile Prinzip 7 sagt, funktionierende Software ist das wichtigste Fortschrittmaß. Das heißt, gute Software schnell liefern. Diese Worte sind schon bewusst gewählt. Und ich glaube, dieser Satz hilft, wenn man zum Beispiel im Team diskutiert. Warum arbeiten wir agil? Was heißt das überhaupt? Da hilft dieser Satz, naja, es geht darum, gute Software schnell zu liefern. Wenn wir dann diese Work-Feedback-Loop noch im Hinterkopf behalten, sind wir meiner Meinung nach einen großen Schritt weiter. Wir haben im Gegensatz zum klassischen Projektmanagement eigentlich ein umgedrehtes Dreieck. Im klassischen Projektmanagement ist der Umfang fix und Zeit und Budget sind variabel. Da wird einfach gesagt, ich brauche all dieses und wir müssen mithilfe von Zeit und Budget versuchen, das zu erreichen. Agilität dreht das auf den Kopf. Da ist es so, dass Zeit und Budget fix sind und der Umfangvariable. Wir wollen mithilfe des zur Verfügung stehenden Budgets und der zur Verfügung stehenden Zeit den maximalen Wert, den Umfang, den maximalen Wert schaffen. Und wir fragen uns nicht, wie lange brauchen wir für alle Features, sondern wir fragen uns, was ist das Wertvollste, das wir in der Zeit schaffen können und in dem Budget schaffen können, das uns vorgegeben ist. Das ist tatsächlich, wenn man es wirklich durchdenkt, eher eine Befreiung als eine Einschränkung. Wichtig ist mir noch, und dann haben wir es auch schon fast geschafft, agiles Arbeiten ist nicht Scrum oder Kannmann oder Save oder Less oder wie auch immer ihr Methoden benutzt. Es geht um Work und Feedback. Es gab mal von Scrum Show eine Umfrage auf Mastodon, die war sehr interessant. Das war rausgekommen, 80% der Befragten wissen nicht, warum sie Scrum machen. Es gab letztens eine ähnliche Umfrage mit einem ähnlichen Ergebnis. Ja, da ist natürlich kein Wunder, dass dieses Wort agil verbrannt ist, wenn die Leute einfach keine Chance mehr haben zu lernen. Ja, was bedeutet agil denn wirklich? Eine Methode, die implementiert dann nur irgendetwas von diesem agilen Arbeiten. Und wo man auch ehrlich sein muss, wenn ihr einfach stark repetitive Tätigkeiten habt, eure Workfeedback-Luke einfach lang sein kann, weil klar ist, was hinten rauskommt, dann schleppt ihr ein Overhead mit. Agiles Arbeiten ist erstmal ein Overhead. Das muss ausgeglichen werden dadurch, dass ihr relativ schnell auf dem Markt sein müsst oder in einem sehr bekannten Umfeld arbeitet oder beides. und wenn du eben voraussagen kannst, was hinten rauskommt, dann brauchst du ehrlicherweise gar nicht agil sein. Begreifen dieses Basisthema natürlich in vielen Folgen auf. Wir werden in der Folge 4 zum Beispiel darüber sprechen, dass es wichtig ist, dass Mindset vor Methode gilt und in Folge 8 sprechen wir nochmal ein bisschen dedizierter, warum dieses Label agil denn verbrannt ist. Und ja, das soll es tatsächlich auch schon gewesen sein. Wie gesagt, gute Software schnell liefern, das ist für mich der Kern. Darunter steckt diese Work-Feedback-Loop und eigentlich leitet sich alles davon ab. In der nächsten Folge werden wir uns dann tatsächlich das Agile Manifest vornehmen. Ich hoffe, das hat dir hier gefallen. Ich freue mich natürlich wie immer über Feedback. Wie du mich erreichst, findest du in den Shownotes. Und ich sage, habt noch eine ganz tolle Woche und wir haben uns beim nächsten Mal. Ciao, ciao.