NBA51: „Gute Software schnell liefen“ - Warum überhaupt agil arbeiten?

00:00:00: Hallo und herzlich willkommen bei No Bullshit Agile. Ich bin Thomas, ich bin Teil eines agilen

00:00:07: Teams und hier geht es jede Woche um die echten Herausforderungen in der agilen Welt. Praxisnah

00:00:12: und direkt auf den Punkt. Agilität ist kein Hype und keine Sammlung von Buzzwords. Und

00:00:17: Agilität ist auch nicht tot. Agiles Vorgehen ist für mich das einzig sinnvolle Vorgehen.

00:00:22: Leider wird zu viel Bullshit obendrauf gepackt und dem möchte ich mit diesem Podcast entgegnen.

00:00:28: In der letzten Folge habe ich mal meine Meinung zu KI und agilen Arbeiten erläutert. Wenn

00:00:33: dich das interessiert, hör da gerne rein. Den Link und alle weiteren Links findest du in den

00:00:37: Shownotes. Das hier ist die Folge 51 und heute möchte ich erläutern, wann und warum man überhaupt

00:00:43: agil arbeiten will. Ja, ich stelle mir einfach mal jemanden vor und so ist auch die Idee für diese

00:00:49: Folge entstanden, der agiles Arbeiten meiner Meinung nach noch nicht ganz verstanden hat oder den

00:00:56: Begriff eher mit Scrum oder kann man oder sowas gleich setzt. Und ja, ich stelle mir einfach mal vor, ich würde

00:01:04: diesen Menschen jetzt so ein bisschen meine Erfahrung mitteilen wollen und ein bisschen darüber erzählen,

00:01:09: was ist agiles Arbeiten aus meiner Sicht.

00:01:13: Und ich fange einfach mal an mit der Ausgangssituation und formuliere mal einen Satz, der für mich zentral und super wichtig

00:01:21: ist. Wir wollen gute Software schnell liefern. Das ist für mich mein großes Mantra und mein Leitsatz. Und es geht eben nicht darum zu sagen, ich will jetzt wissen, wie ich Scrum umsetzen muss, um erfolgreich zu sein. Sondern es gibt eben diesen einen Satz. Gute Software schnell liefern.

00:01:43: Und diese Denkweise von, ja, wie muss ich jetzt denn kann man machen oder Scrum, ist schon oft das erste Problem. Die Denkweise dahinter ist falsch. Das ist eben die Suche nach der schnellen Lösung. Was ist die Methode, die mich dahin bringt, wo ich sein will? Und die Denkweise muss aber sein, was ist der Nutzen für die Benutzer des Systems, für die ich jetzt was entwickle?

00:02:13: Natürlich immer von Softwareentwicklung. Das ist das, was wir machen. Natürlich kann man viele Prinzipien auch auf andere Dinge ummünzen. Ich hatte ja mal den Thomas Michel hier. Da ging es um Verwaltung und agile Methodiken oder Arbeiten im agilen Bereich in der Verwaltung. Das geht alles. Ich kann einfach immer nur am besten aus dem Blick der Softwareentwicklung erzählen.

00:02:35: So, wir haben also dieses Mantra oder diesen übergeordneten Satz, gute Software schnell liefern. Und den will ich jetzt einmal kurz mit euch auseinander nehmen.

00:02:46: Wir fangen mal an mit diesem Gut, was da vorne steht. Gute Software. Was heißt denn Gut? Zuallererst mal heißt Gut für mich, wir wollen eine Qualität. Und zwar, wir wollen das Richtige in einer guten Qualität.

00:03:01: Nicht perfekte Qualität. Das ist eine ganz andere Baustelle. Was heißt jetzt hier Qualität? Naja, alles das, was wir uns unter Qualität vorstellen. Da gehört dann auch sowas zu wie, ist gut wartbar, ist gut erweiterbar, erfüllt den Zweck, den der Nutzer der Software verfolgt.

00:03:21: Das alles ist für mich Qualität. Das Zweite, was sich unter gut verbirgt für mich ist, bringt einen Wert oder bringt echte Werte. Schafft einen echten Wert für das Unternehmen. So wie bei uns, wenn wir jetzt für Kunden entwickeln, muss das einen echten Wert für unseren Kunden liefern. Ein Return on Investment. Etwas Anfassbares.

00:03:45: Wenn ihr Inhouse entwickelt, wollt ihr einen echten Wert für euer Unternehmen schaffen. Was ist das nächste Untergut? Das soll genau den Zweck erfüllen, der zu dem Zeitpunkt benötigt wird. Keine Featureitis. Nicht, das könnte man sicherlich auch mal gebrauchen. Es geht wirklich darum, gut bedeutet, die Software erfüllt genau den Zweck.

00:04:10: Das nächste Untergut, was ich unter gut sehe ist, es ermöglicht die Benutzung durch den Endbenutzer und damit bekommen wir sein Feedback. Und nur damit finden wir heraus, was fehlt denn jetzt noch?

00:04:24: All das sind Kriterien zu gut. Es geht nicht um vollständig. Das heißt nicht gut. Was ist schon vollständig? Auch das Thema habe ich hier immer wieder erläutert. Kein Mensch kann vollständig zu Start eines Projekts definieren.

00:04:43: Zumindest nicht, wenn es nicht eine repetitive Tätigkeit ist.

00:04:48: Okay. Und das soll es mal, wir sind immer noch bei dem Satz, gute Software schnell liefern, zu diesem Wort gut in diesem Satz sein.

00:04:57: Dann kommen wir mal zu schnell. Ich möchte in möglichst kurzer Zeit dieses Gute liefern. Das ist sicherlich nicht Monate. Je kürzer, je besser. Tage wären toll.

00:05:12: Das ist nicht immer möglich.

00:05:14: Und das ist sicherlich auch, ja, erfordert viel, viel mehr, als man erst mal denkt, um gute Software schnell zu liefern. Aber wir wollen so dicht wie möglich an dieses schnell drankommen.

00:05:30: Warum wollen wir das? Wir wollen das schnelle Feedback von dem Benutzer, damit das Einfluss hat auf das, was wir als nächstes tun. Denn wir können nicht raten und wir finden die Zukunft nicht durch Raten heraus, sondern nur durch Doing, Feedbackzyklus, Anpassung, Doing.

00:05:48: Gut. Und dann steckt in diesem Satz, gute Software schnell liefern, noch liefern drin. Liefern heißt für mich, es muss in Produktion. Nicht auf einem Staging System, nicht auf einem User Acceptance Test System, nicht lokal oder sowas in der Art, sondern das, was ich da liefere, muss in Produktion. Erst dann kann dieser Feedbackzyklus ja überhaupt starten.

00:06:14: Gut. Wir haben also unseren Leitsatz, unser Mantra, gute Software schnell liefern. Und wir sind jetzt mal durchgegangen, was heißen die einzelnen Worte? Was dir aufgefallen ist, hoffe ich zumindest, ich habe noch kein einziges Wort aus der agilen Wortwelt benutzt.

00:06:33: Und das ist mir halt wichtig, dass wir nicht da einsteigen, sondern eben an den Nutzen denken, an das Outcome denken und nicht an eine Methode oder eben Wort, sage ich jetzt erstmal, aus dieser agilen Wortwolke.

00:06:51: Geht das alles, was ich da gerade gesagt habe, auch ohne irgendeine agile Methode? Klar. Warum auch nicht? Wenn komplett klar ist, in der Anfangsphase von einem Projekt, was hinten rauskommt und es ehrlich gesagt da auch keine Diskussion drum geben kann,

00:07:11: Warum sollte ich dann irgendeine Methodik jetzt noch anwenden, wenn ich diesen Satz erfüllen kann, gute Software schnell liefern und ich das einfach direkt tun kann?

00:07:21: Es gibt das ganze agile Thema einfach. Warum wollt ihr dann noch, ich sage jetzt mal, den Ballast mitschleppen? Das macht ja gar keinen Sinn.

00:07:30: Das ist oft der Fall bei repetitiven Tätigkeiten. Also ich bringe das Beispiel ja immer gerne und ich weiß, dass das auch hinkt, aber in den 70er Jahren, sagen wir es mal einfach so, damit mal die Softwarekomponente raus ist, war für VW ziemlich klar, wie ein Golf aussieht.

00:07:49: Die haben das einmal konzipiert, das ist ein Golf und dann haben die ihr Fließband entsprechend gebaut und jeder weitere Golf aus dieser Produktionsreihe war nur eine Repetition des ersten Golfs.

00:08:03: Das ist verkürzt, ist mir schon klar, aber ich glaube, ihr kriegt mit, was ich mit dem Beispiel meine. Und dann brauche ich keinen Schnickschnack, sage ich jetzt einfach mal drumherum, sondern ich tue das einfach.

00:08:15: Leider ist es gerade im Bereich Softwareentwicklung aber so, dass wir keinen Golf bauen. Und sehr, sehr oft erlebe ich halt auch, ja, jeden Tag will ich nicht sagen, aber immer, immer wieder, wenn ich mit meinen Ansprechpartnern über neue Projekte spreche, dass die eigentlich sich sehr sicher sind, dass sie wissen, was sie wollen.

00:08:34: Es stellt sich aber wirklich in 80 oder 90 Prozent der Fälle heraus, sobald sie das erste Mal eine erste Lieferung anfassen, sich intensiver mit dem Projekt beschäftigen, stellen sie eben fest, ah, ich hätte das gerne doch noch und das hätte ich doch gerne anders und das ist vollkommen okay.

00:08:52: Es ist dann aber keine Repetition mehr. Und in dem Moment brauchen wir agile Methodiken und das sind auch die einzigen Methodiken, die uns wirklich helfen, sinnvolle Software zu schreiben und eben gute Software schnell zu liefern.

00:09:06: Ja, und dann sind wir eben an dem Punkt, dass wir von diesem Satz hin zu, ja, was bedeutet das denn und was müssen wir denn alles tun, um dieses Ziel zu erreichen, ja, dass wir da angekommen sind.

00:09:18: So, also wenn es ohne agil nicht geht, was dann, agiles Arbeiten ist jetzt im Prinzip eine Sammlung von Praktiken und Methodiken und Leitlinien, die uns helfen in diesem unbekannten Umfeld, das sich schnell verändert, eben schnell zu sein und durch iteratives Arbeiten und Feedbackzyklen das Richtige zu tun und am User zu agieren, also am Benutzer des Systems.

00:09:44: Und dabei wollen wir dann auch noch effektiv und effizient sein und sinnvoll mit dem Geld umgehen, was da investiert wird.

00:09:52: So, das heißt also, jetzt erst sind wir an dem Punkt, dass wir darüber reden, was heißt agiles Arbeiten.

00:10:01: Ich bin ja gestartet mit, ich möchte mal jemanden erklären, der vielleicht nicht ganz drinsteckt oder einfach Denkweisen, ja, zu abstrahiert benutzt, der ziemlich schnell im Bereich, ja, Scrum oder kann man oder so im Bereich Methoden ist.

00:10:18: Was die unterliegenden Methoden jetzt überhaupt bedeuten, warum komme ich jetzt mit so vielen Methoden über den Hof und warum reicht es nicht, nach Scrum Guide zu arbeiten.

00:10:30: Ich habe dazu ja mal diesen agilen Eisberg gemalt und ich habe dazu ja auch eine Folge gemacht, das ist die Folge NBA 49.

00:10:38: In der Folge, in den Show Notes gibt es auch ein Schaubild von diesem agilen Eisberg.

00:10:42: Schaut da gerne rein.

00:10:44: Ich will nur Teile davon jetzt gerade aufgreifen, aber das ist eben jetzt der Schulterschluss.

00:10:50: Warum brauchen wir so viel Kram, sage ich jetzt einfach mal, um dieses große Ziel zu erreichen?

00:10:57: Für mich ist es unheimlich wichtig, diesen ersten Satz ganz vorne zu halten und ja, den permanent im Blick zu behalten.

00:11:05: Gute Software schnell liefern.

00:11:08: Es reicht eben nicht, nach Scrum Guide arbeiten.

00:11:12: Den Fehler habe ich auch schon gemacht, ganz am Anfang, schon ein bisschen her, als wir mit Scrum angefangen haben, hatte ich auch schon mal erzählt.

00:11:19: war ich der festen Überzeugung, wir machen Hardcore Scrum, wir halten uns ganz strikt an den Scrum Guide und dann wird alles gut.

00:11:26: Heute ist mir vollkommen klar, nee, das kann so nicht funktionieren.

00:11:30: Also, wir gehen einfach mal ein paar Punkte noch durch und ich orientiere mich jetzt tatsächlich an diesem Schaubild Agile Eisberg.

00:11:37: Es gibt viel mehr Punkte.

00:11:38: Ich will jetzt nur als Abschluss und Abrundung von der Folge das nochmal aufgreifen.

00:11:43: Also, unter anderem gibt es den Punkt Vertrauen.

00:11:47: Es ist unheimlich wichtig, dass ihr Vertrauen gebt, damit zum Beispiel kein Micromanagement entsteht.

00:11:54: Das hilft euch Zeit zu sparen.

00:11:57: Ihr nutzt das Potenzial aller.

00:11:58: Es gibt nicht den Mechanismus von, Leute verstecken sich auf einmal hinter.

00:12:04: Ja, das haben die da oben so entschieden und deswegen machen wir das.

00:12:08: Der nächste Punkt Servant Leadership.

00:12:09: Ihr sollt, ihr müsst das Team an einen Stellen unterstützen und trotzdem Leitlinien geben.

00:12:16: Das ist mein Servant Leadership.

00:12:18: Ihr braucht ein Umfeld, in dem sich Leute schnell und gut entwickeln können.

00:12:22: Ihr braucht eine Learning Organization.

00:12:25: Ihr müsst Methodiken und euer Wissen permanent erweitern und anpassen an die aktuelle Situation.

00:12:33: Ihr braucht sowas wie Team- und oder Mob Programming.

00:12:36: Ihr braucht den Wissensaustausch im Team.

00:12:39: Ihr braucht die Wissensverbreiterung für Neues, das ihr lernt.

00:12:43: Es ist ein permanentes Lernen, um dieses Ziel zu erreichen, das ich da oben vorgegeben habe.

00:12:50: Ihr braucht diese Feedback-Zyklen auf allen, allen Ebenen.

00:12:55: Je mehr Feedback unternehmensintern mit den Usern, mit den Kunden, je öfter ihr das auch wieder einfließen lassen könnt, desto besser.

00:13:04: Ihr braucht in der Entwicklung technische Methoden.

00:13:08: Das ganze Thema Continuous Delivery, das ganze große Thema DevOps, all das zielt darauf hinaus, dass ihr schnell Software liefern könnt, dass ihr schnelle Releases habt, dass ihr gute Inkremente entwickelt und diese liefern könnt.

00:13:23: Ihr braucht Code, der einfach zu refactoren ist, der modular ist.

00:13:27: Ihr müsst schnell Teile austauschen können in dieser Software aufgrund des Feedbacks.

00:13:35: Und es gibt so viel mehr zu erzählen.

00:13:38: Selbst der Agile Eisberg reißt ja auch nur Stichworte an.

00:13:42: Aber all das ist das Fundament dazu, um gute Software schnell zu liefern.

00:13:48: Ich möchte euch zum Abschluss noch ein kleines Beispiel geben.

00:13:52: Nehmen wir mal an, ihr baut ein Haus.

00:13:55: Wenn man so ein Haus baut und das soll jetzt einfach mal die Situation sein, dann habt ihr für den Hausbau einen Festpreis und unter anderem sind in dem Vertrag vorgesehen, sagen wir mal, ihr habt 30 Steckdosen, die ihr jetzt dann irgendwann beliebig in diesem Haus im Rahmen dieses Festpreises installieren lassen könnt.

00:14:16: Und jetzt habt ihr zwei Möglichkeiten.

00:14:17: Es ist soweit, der Elektriker sagt zu euch, okay, du musst mir jetzt mal sagen, wohin sollen diese 30 Steckdosen.

00:14:24: Ihr habt jetzt zwei Möglichkeiten.

00:14:26: Die erste Möglichkeit, ihr überlegt euch ganz genau, wo steht der Fernseher, wo steht die Waschmaschine, wo will ich einen Staubsauger anschließen und so weiter und so fort.

00:14:37: Ihr plant also wirklich ganz intensiv, wo in welchem Raum welche Steckdose hin soll und achtet darauf, dass ihr bei diesen 30 Steckdosen bleibt.

00:14:46: Ihr macht also eine riesengroße Planung, um zu definieren, wo wohl welche Steckdose später benötigt wird.

00:14:55: Die andere Alternative ist, das bietet euch der Elektriker auch an, ihr könnt auch mehr als 30 Steckdosen verbauen.

00:15:02: Und jede weitere Steckdose kostet, sagen wir mal, keine Ahnung, 80 Euro.

00:15:06: Dann habt ihr jetzt eine zweite Möglichkeit.

00:15:09: Ihr sagt ganz einfach, pass auf, in jedem Raum will ich an jeder Ecke eine Doppelsteckdose.

00:15:15: Ist mir egal, die 80 Euro je Steckdose bei dem, was das ganze Haus kostet, soll es halt so sein.

00:15:22: Und ihr gebt einfach viel, viel mehr Geld aus.

00:15:24: Also so viel mehr Geld ist es dann wahrscheinlich gar nicht im Vergleich zu den Kosten von dem Haus.

00:15:28: Und habt dann im Prinzip die Sicherheit, ihr habt wirklich überall eine Steckdose.

00:15:34: Wenn dann mal das Haus fertig ist und ihr jetzt eure Steckdosen benutzt, hängt jetzt ein bisschen eure Experience, sage ich mal, davon ab, welche Variante ihr da oben gewählt habt.

00:15:46: Also habt ihr Variante 1 gewählt, ihr habt wirklich nur diese 30 Steckdosen verteilt und das wirklich gut durchgeplant.

00:15:52: Ja.

00:15:52: Dann stellt ihr 100% fest, Mist, da hinten fehlt eine Steckdose.

00:15:58: Das wird so sein.

00:15:59: Das liegt einfach daran, dass ihr das noch nie gemacht habt.

00:16:02: Und ihr gar nicht so weit um die Ecke denken könnt, dass der Fernseher auf einmal doch auf die andere Seite soll oder ihr Schlafzimmer und Kinderzimmer tauscht.

00:16:11: Und deswegen fehlen jetzt auf einmal Steckdosen.

00:16:13: Das wird garantiert so sein.

00:16:14: In dem anderen Fall habt ihr zwar überall Steckdosen, aber ihr stellt fest, die Steckdose da hinten, die verschandelt jetzt meine Wand.

00:16:21: Ich hätte sie nie gebraucht.

00:16:22: Der Fernseher wandert nie in die Ecke.

00:16:25: Ihr habt gedacht, na, vielleicht könnte der da hinkommen, aber das wird nie der Fall sein.

00:16:29: Jetzt nehmen wir einfach mal an, so eine weitere Steckdose kostet nicht 80, sondern 5000 Euro.

00:16:36: Dann überlegt ihr schon viel, viel länger und höchstwahrscheinlich wählt ihr Variante 1.

00:16:42: Was wir jetzt machen in der agilen Softwareentwicklung ist folgendes.

00:16:46: Wir sagen, pass mal auf, mach dir nicht zu viele Gedanken darum, wo jetzt wirklich später der Fernseher steht,

00:16:54: sondern wir machen erstmal eine Grundausstattung.

00:16:56: Du sagst uns, da steht der Fernseher und da bauen wir jetzt eine Steckdose hin.

00:16:59: Und wenn das Haus fertig ist und du das Haus benutzt, dann können wir für ganz, ganz schmales Geld jederzeit neue Steckdosen bauen,

00:17:08: Steckdosen rausnehmen, wieder verblenden.

00:17:11: Du hast alle Freiheiten, benutze doch erstmal dein Haus und dann findest du sehr schnell raus,

00:17:18: welche Steckdosen weg können und wo neue Steckdosen hin können.

00:17:21: Und das bauen wir auch sehr schnell und sehr kostengünstig.

00:17:25: Und das ist eigentlich dieses gute Software schnell liefern.

00:17:30: Ich finde dieses Beispiel ganz gut.

00:17:31: Ich finde, es macht nochmal ganz gut klar, was iteratives Arbeiten wirklich bedeutet.

00:17:38: Und ich bin gespannt, was du so sagst.

00:17:41: Ich denke, wir sind für heute durch.

00:17:43: Ja, sag mir gerne, was du denkst.

00:17:46: Gib mir gerne Feedback.

00:17:47: Dazu gibt es verschiedene Kanäle.

00:17:49: Auch die Links findest du in den Shownotes.

00:17:52: Und zum Abschluss habe ich noch eine große Bitte.

00:17:55: Wenn dir das hier gefallen hat, teil das gerne mit Leuten.

00:17:58: Teil das mit Kolleginnen.

00:18:00: Teil das auf Social Media.

00:18:02: Je mehr Leute hier von diesem Podcast erfahren, desto mehr Leute können in so eine Diskussion einsteigen,

00:18:08: desto mehr Themen kann ich hier aufnehmen.

00:18:10: Und das kommt auch dir wieder zugute.

00:18:12: Vielen, vielen Dank schon mal dafür.

00:18:14: Habt eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.

00:18:19: Bis zum nächsten Mal.