NBA35: Liefert echte Werte!
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile.
—
NBA34: Agil sein durch Feedback und Anpassung, nicht durch starre Prozesse
NBA09: Agilität von SpaceX
Zusammenfassung
In dieser Podcast-Folge geht es darum, was es wirklich bedeutet, "Wert" in der agilen Softwareentwicklung zu liefern. Thomas erklärt, dass der Begriff „Value“ vor allem mit dem finanziellen Aspekt verknüpft ist: Wertschöpfung kann durch Effizienzsteigerungen oder direkte Einnahmen erfolgen, sei es für interne Projekte oder Kundenprojekte.
Er betont, dass Agilität nicht nur auf Methoden wie Scrum oder Kanban beruht, sondern vielmehr darauf, den Fokus auf das kontinuierliche Liefern von wertvollen Ergebnissen zu legen. In der Praxis sollte jedes Team darauf achten, ob die Schritte, die sie unternehmen, echten Mehrwert liefern. Dabei spielt der Product Owner eine zentrale Rolle, indem er den Wert definiert, den die nächste Iteration schaffen soll.
Thomas nennt Beispiele, wie etwa SpaceX, um zu verdeutlichen, dass agile Prinzipien auch außerhalb der Softwareentwicklung erfolgreich angewendet werden können, und verweist auf das Buch "The Art of Doing Twice the Work in Half the Time" von Jeff Sutherland, das die Idee der Wertschöpfung durch agile Arbeitsweisen unterstützt.
Er fordert die Hörer auf, den Wert immer im Fokus zu behalten und diese Diskussionen auch im Team und mit Kunden zu führen, um sicherzustellen, dass alle an einem Strang ziehen.
Transkript
Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche 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 dabei immer auf der Praxis, daher auch der Name No Bullshit Agile.
In der letzten Folge habe ich darüber gesprochen, dass agil sein nicht bedeutet, sich starr an eine agile Methode zu halten. Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du in den Shownotes.
Das hier ist die Folge 35 und heute möchte ich mit euch über ein sehr wichtiges Element sprechen, wenn ihr Projekte agil umsetzen wollt. Worum geht es? Die Folge heißt ja „liefert echte Werte“ und der Wertebegriff taucht in der Agilität immer und immer wieder auf. Im Scrum Guide steht was dazu, im Agilen Manifest bzw. den zwölf Prinzipien steht was dazu, und ich habe mich tatsächlich immer wieder schwergetan damit. Was heißt denn das – „Value“ oder „Wert“?
Und wenn ich mal anfange und darüber nachdenke, dann ist so meine erste Frage: Was ist denn unsere Daseinsberechtigung, wenn wir zum Beispiel Software entwickeln? Warum entwickeln wir die Software – für uns, wenn wir es intern tun, oder für unsere Kunden, wenn wir zum Beispiel in einer Agentur arbeiten? Und schlussendlich geht es darum, dass unsere Kunden ja Geld verdienen wollen, die investieren in uns und erhoffen sich irgendeinen Return on Investment.
Und das bedeutet dieser Value-Begriff, der Wertebegriff, der ist zuallererst mal ganz fundamental und ehrlich gesagt auch ganz banal an Geld geknüpft. Geld verdienen kann übrigens auch bedeuten, Geld zu sparen, also indem ich zum Beispiel mit meiner Software Prozesse optimiere und der Kunde deswegen bestimmte Dinge schneller machen kann. Und wenn ich hier vom Kunden rede, dann spreche ich nicht von dem Verbraucher, also dem Endkunden, sondern ich spreche eben von dem Kunden, für den wir entwickeln bzw. der Kunde können wir selber sein, wenn wir für uns entwickeln.
Ja, und dann ist so das Nächste, dass ich zumindest immer rein stolpere: Warum machen wir eigentlich so ein Aufheben darum, wie wir Software entwickeln, also die Methodik oder die Prinzipien, die wir benutzen? Warum ist das so viel Primboreum, habe ich es hier genannt? Und dann nennen wir es agiles Vorgehen. Schlussendlich, für mich zumindest, läuft das alles auf eine Sache hinaus, die fundamental ist. Hatte ich gerade schon gesagt: Wir versuchen das Herangehen, wie wir Software entwickeln, zu optimieren, damit wir dem Kunden möglichst effektiv einen Wert liefern können. Und wir suchen immer und immer wieder nach dem nächsten Wert.
Das ist jetzt ziemlich platt, und der Folgentitel ist ja auch ziemlich platt, aber wenn man darüber nachdenkt, ist es wirklich der Kern des Ganzen. Und wenn du Lust hast, denk mal ein bisschen drüber nach, vielleicht hast du das ja auch schon getan. Wie immer bin ich natürlich an Feedback interessiert, aber das hat mir geholfen, diesen Wertebegriff „Value“ besser zu fassen. Es gibt auch andere Werte, das will ich hier nicht verschweigen, aber der Hauptwert ist eben, auf irgendeine Art und Weise Geld für den Kunden zu sparen.
Warum ist jetzt dieser Wert so wichtig? Wir sind halt einfach auf einem sehr umkämpften Markt unterwegs, und damit meine ich jetzt wieder unsere Kunden. Es ist wichtig, das Geld möglichst effizient zu verwenden. Der Kunde investiert in irgendeine Art von Entwicklung, sei es jetzt wirklich, um etwas Neues zu haben, oder um Prozesse zu optimieren und dann schlussendlich eben darüber Geld zu sparen. Und es geht darum, dass der Kunde auf dem Markt besteht. Und gerade in unsicheren oder unbekannten Feldern, was sehr oft Softwareentwicklung eben ist, können wir dies nur mit einem agilen Vorgehen garantieren.
Ich rede nicht von der Methode hier, ich rede nicht von Kanban oder Scrum oder so, sondern ich rede jetzt wirklich wieder mal von diesem Fundament des agilen Vorgehens. Um ein anderes Beispiel für ein agiles Vorgehen zumindest anzubringen: Ich habe eine Folge gemacht, NBA 9 ist das, die Agilität von SpaceX. Da erzähle ich, wie SpaceX neueste Technologien auf unbekannten Wegen agil entwickelt. Da ist wirklich dieses Fundament von Iterationen drin: aus Fehlern lernen und die nächste Iteration entsprechend planen. Und das Ganze in diesem Fall ja vor allen Dingen in Hardware. Da steckt auch Software dahinter, aber so ein Raumschiff, das Starship, ist doch schon eher auch ganz viel Hardware, die eben auch iterativ und agil entwickelt wird. Finde ich immer ein ganz gutes Beispiel, damit man nicht immer nur über Software redet.
Aber wie gesagt, insgesamt haben wir ein unbekanntes Umfeld, wir haben einen stark umkämpften Markt und wir suchen nach Potenzialen, wie wir jetzt effektiv für diesen Markt entwickeln können. Ein gutes Beispiel ist hier tatsächlich das Scrum-Buch „The Art of Doing Twice the Work in Half the Time“ von Jeff Sutherland. Werdet ihr höchstwahrscheinlich alle kennen, da geht es natürlich um Scrum und um, ich sage mal, die Basis von Scrum, und da steht wirklich viel Richtiges drin. Ich habe in anderen Folgen ja immer mal wieder darüber geredet, was ich gerade so von Scrum halte. Und wie gesagt, oft genug ist es tatsächlich eher so, dass Scrum falsch benutzt wird und es gar nicht an der Methode liegt.
Wir sollten uns immer und immer wieder fragen, ob das, was wir gerade tun, eben einen Wert liefert oder ob es eher Waste ist. Und wie gesagt, das nicht nur, wenn man Scrum macht. Zum Beispiel steht in den zwölf Prinzipien ziemlich oben – also ich glaube sogar das erste Element – „Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“ Also selbst da, in dieser abstrahierten Art, ist ganz oben schon erwähnt: Es geht um Wert.
Jetzt kann man sich noch fragen, wer den Wert definiert. Und in meiner Interpretation ist das in Scrum ganz klar der PO. Für mich sieht es so aus, als ob der Scrum Guide eben rund um den PO gebaut ist und sagt, der ist der oder die, der oder die den Wert definiert. Das ist meiner Erfahrung nach in der Praxis oft nicht der Fall, das muss man auch klar sagen, denn oft genug hat man den PO innerhalb des Teams, der kommt dann auch aus der Agentur. Eigentlich gehört der PO zum Kunden, nur der hat ja die Produktvision. Aber oft, wie gesagt, ist es – zumindest meiner Erfahrung nach, das muss bestimmt nicht überall so sein – so, dass der Kunden-PO (ich mache gerade Gänsefüßchen in der Luft) eben nicht so stark involviert ist, dass er zum Beispiel bestimmte Reihenfolgen aus dem Backlog definiert oder im Sprint Planning dabei ist.
Aber die Grundidee ist schon da, zu sagen, okay, da gibt es jemanden, der vertritt, ich sage mal, das Produkt, der hat all das Wissen, all das Domänenwissen, das man fürs Produkt braucht, und deswegen ist dieser Mensch auch in der Lage, den Wert zu definieren – den Wert, den die nächste Iteration schafft. Und ansonsten generell meiner Meinung nach immer der Kunde und immer gemeinsam mit dem Team. Für mich ist es jedes Mal eine Mini-Verhandlung. Stellt euch das nicht zu hart vor, es ist keine Gerichtsverhandlung hier, sondern der Kunde sagt: „Für mich ist das Nächste das, das schafft für mich als Nächstes, zum Beispiel durch den Input aus der letzten Iteration, den nächsten großen Wert.“ Und das Team sollte involviert sein, damit es frühzeitig sagt: „Ja, verstehen wir, aber aus unserer Sicht wird das und das Wert liefern.“
Es kommen eben die beiden Domänenwissen zusammen, auf der einen Seite das Domänenwissen vom Kunden und auf der anderen Seite das Domänenwissen vom Team, das ja den Tech Stack kennt. Das Team könnte in diesem Fall sagen: „Na ja, das ist eine gute Idee, das jetzt zu machen, aber wir müssten eigentlich vorher hier, hier und hier ein Refactoring machen oder ein Update oder was auch immer der Kunde nicht im Blick hat.“
Ja, vielleicht als kleine Zusammenfassung und als Fazit: Wenn ihr eine Diskussion führt oder eine Entscheidung treffen müsst, dann schaut doch schnell auch auf den Wert. Überlegt wirklich, von mir aus gerne auch gemeinsam mit dem Kunden: „Wir stehen hier vor einer Entscheidung und wir glauben, dieser Weg – rechtsrum – liefert jetzt mehr Wert als linksrum.“
Kleines Zitat vielleicht noch aus dem Buch von Jeff Sutherland zu Scrum: „Figure out where the most value can be delivered for the least effort and do that one right way.“ Ja, und ich denke, damit haben wir es kurz und knackig. Mir geht es, wie gesagt, vor allen Dingen darum, allen nochmal aufzufordern oder daran zu erinnern, diese Wertediskussion zu führen und sie wirklich auch, ja, ich sage mal, handfest und pragmatisch zu halten.
Wie immer interessiert mich eure Meinung. Was erlebt ihr so in der Praxis? Gebt mir dazu gerne Feedback und steigt mit mir und mit anderen in die Diskussion ein. Du kannst mich auf mehreren Kanälen erreichen, zum Beispiel per Mail unter nobsagile@gmail.com. Ich bin auf Mastodon aktiv, und begleitend zu dem Podcast gibt es ja ein Forum, und zu jeder einzelnen Folge gibt es auch einen Forum-Thread, den ich anlege. Auch da können wir gerne zusammen diskutieren.
Eine Bitte habe ich noch: Wenn dir die Folge gefallen hat, abonniere den Podcast in deiner Podcast-App, das hilft anderen, den Podcast zu finden und du verpasst keine Folge mehr.
Das war es für heute, vielen Dank fürs Zuhören und bis zum nächsten Mal.
