NBA67: Agiles Arbeiten unabhängig von agilen Methoden

00:00:00: Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Jede Woche spreche

00:00:07: ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge habe

00:00:12: ich über Flow und Flowmessungen gesprochen. Ein Outcome, den ich da hatte, war Flow ist

00:00:16: ein fortlaufender Optimierungsprozess, kein Ziel. Wenn dich das interessiert und du auch

00:00:21: mal in die Folge reinhören willst, den Link und alle weiteren Links, die ich hier erwähne,

00:00:26: findest du in den Shownotes. Heute in Folge 67 geht es um agiles Arbeiten, unabhängig von agilen

00:00:32: Methoden wie Scrum oder Kanban. Ich bin da inspiriert worden von einem Artikel von Stefan

00:00:37: Wolpass. Sein Artikel hat den Titel Agile Primitives, Agilität jenseits von Frameworks.

00:00:43: Dieser Artikel gibt ziemlich gut meine Gedanken wider und ziemlich gut die Themen, über die ich

00:00:50: hier immer wieder im Podcast spreche. Bevor wir da einsteigen, ein bisschen Housekeeping. Ich

00:00:55: stelle in letzter Zeit fest, dass ich in neuen Folgen immer wieder Referenzen oder Querverweise

00:01:00: zu alten Folgen machen kann. Das ist eigentlich ziemlich schön, freue ich mich auch drüber. Klar,

00:01:05: 67 Folgen, so langsam, sage ich mal, habe ich viele Themen angesprochen. Ich erwähne dann ja

00:01:13: auch jedes Mal oder jeweils passend die Folgen, wenn ich eine neue Folge aufnehme. Und meine

00:01:20: Frage ist, nervt dich das? Ist das irgendwie zu viel? Klingt das zu stark nach Werbung? Weil,

00:01:26: darum geht es mir nicht. Mir geht es eben darum, wenn jemand hier eine Folge hört,

00:01:30: dass ich ihm gleich sagen kann, pass auf, hier ist noch ein Bezug zu einer anderen Folge. Das

00:01:35: würde mich wirklich interessieren, deswegen schreibt mir gerne eine Mail oder du kannst mich sonst auch

00:01:40: auf Mastodon, LinkedIn oder BlueSky erreichen und gib mir da mal Feedback. Ich werde dazu auch

00:01:45: eine kleine Umfrage auf Mastodon machen. Gut, dann würde ich sagen, wir steigen mal ein. Wie gesagt,

00:01:50: ich bin ein bisschen inspiriert worden von dem Artikel von dem Stefan und ja, ich spreche im

00:01:56: Podcast immer wieder darüber, dass agiles Arbeiten nicht an Methoden hängt. Und es macht einfach für

00:02:03: mich zumindest Sinn, unter die Oberfläche zu schauen. Was ist das Fundament? Worauf basiert

00:02:08: das alles? Eine Methode, wie kann man oder Scrum, die kommt halt oben drauf. Und man muss sich ja

00:02:15: immer wieder fragen, worauf kommt es wirklich an? Was macht uns zum Beispiel schneller oder

00:02:20: flexibler? Und muss es alles so kompliziert sein? Also ich glaube, ganz oben an der

00:02:27: Komplexitätsspitze steht wohl safe, würde ich zumindest behaupten. Muss es so kompliziert sein

00:02:32: oder gibt es nicht irgendetwas, was man macht und was einem hilft, agil, flexibel und damit im

00:02:40: Zweifelsfall auch schnell zu sein. Und durch Zufall bin ich eben über diesen Artikel gestolpert

00:02:45: und ich habe den Titel gesehen. Ich habe ein bisschen durchgescrollt und gesagt, ja, guck mal,

00:02:50: da hat es einer runtergeschrieben. Dann brauche ich es nicht machen. Deswegen, der Stefan, der

00:02:56: listet in seinem Artikel zehn Prinzipien auf und nennt sie, wie gesagt, Agile Primitives. Sehr

00:03:02: passender Name. Und ich würde die gerne mal durchgehen. Ich gehe die nicht im Einzelnen durch

00:03:07: oder nicht im Detail, weil, wie gesagt, vieles habe ich ja auch schon besprochen. Doch ich denke,

00:03:11: eben der Kontext, sich das alles im Zusammenhang nochmal anzugucken, diese zehn Punkte, ist wieder

00:03:18: so ein schöner Gedankenanschubser. Ja, ich würde sagen, wir gehen die Punkte einfach mal durch und

00:03:23: er fängt an mit das erste Fundament, sein erstes Primitive ist iterative Entwicklung. Kennen wir

00:03:32: alle und ich glaube, es gibt keinen, der hier zuhört und sagt, also iterative Entwicklung

00:03:39: bringt nichts. Es ist, glaube ich, jedem klar, was Iteration bedeutet, dass eben alles Planung,

00:03:45: Design, Entwicklung, Test, Release im Zweifelsfall sogar eine Iteration ausmacht und wir versuchen,

00:03:54: durch planvolles Vorgehen eben so eine Iteration auch sinnvoll zu gestalten. Großer Vorteil von

00:04:01: iterativen Arbeiten ist eben, man kommt sehr schnell auch in einen Feedback-Zyklus. Funktioniert

00:04:06: das wirklich so, wie wir gedacht haben? Oder gibt es Anpassungen, die wir in einer nächsten

00:04:12: Iteration einfließen lassen sollten? Das steigert die Qualität, das steigert die

00:04:17: Geschwindigkeit, das bringt Dinge früher in Produktion und das ist auch sicherlich im

00:04:23: Risikomanagement eine wichtige Sache. Zu diesem ganzen Thema iteratives Vorgehen und auch

00:04:29: Schwierigkeiten, die darin stecken, habe ich tatsächlich in der Folge MB42 mal gesprochen.

00:04:35: Der nächste Punkt von Stefan ist inkrementelle Lieferung. Hat mir beim iterativen Arbeiten eben

00:04:41: schon kurz angerissen. Ich glaube, sein Fokus ist hier wirklich auf diese Lieferung von Inkrementen.

00:04:45: Wir sind, glaube ich, nah an Continuous Delivery hier. Test-Driven Development wäre noch so ein

00:04:52: Schlagwort und ich glaube, es ist einfach wichtig, Code, der funktional ist, so früh wie möglich

00:05:02: auch zu releasen. Übrigens, meiner Meinung nach, unabhängig auch von dem Sprintende. Also wenn ihr

00:05:11: Scrum macht, warum sollte man funktionierenden Code nicht während eines Sprints releasen? Das

00:05:17: verstehe ich nicht. Worauf wartet dieser Code? Warum sollte der jetzt noch anderthalb Wochen

00:05:23: warten, wenn er denn schon einen Wert schafft? Ich bin unsicher, wieso die durchschnittlichen Teams

00:05:31: das mittlerweile handhaben. Unsere Scrumzeit ist ja schon länger her. Bei uns war es tatsächlich so,

00:05:38: dass wir am Sprintende geliefert haben. Ehrlich gesagt, ich habe da auch nie drüber nachgedacht,

00:05:42: dass es Sinn machen kann, während eines Sprints schon zu liefern. Und warum das wertvoll ist,

00:05:48: da habe ich tatsächlich auch in NBL 35 drüber gesprochen. Da ging es mir so um liefert echte

00:05:54: Werte. Der dritte Punkt ist kontinuierliche Verbesserung. Also das, was wir oft unter

00:05:59: Kaizen verstehen. Also wir wollen permanent drauf schauen, ob wir unsere Produkte oder

00:06:07: Dienstleistung und auch unsere Prozesse verbessern können. Wir alle kennen einen

00:06:12: ganz elementaren Punkt in diesem Prozess, nämlich unsere Retrospektiven. Die sind

00:06:19: sehr explizit natürlich auf unsere Prozesse gemünzt. Aber es gibt halt die Möglichkeit,

00:06:24: viel, viel mehr zu tun, um zu gucken, können wir etwas verbessern. Wenn zum Beispiel Slack-Zeit

00:06:30: entsteht durch ein VIP-Limit, dann könnte es eine gute Idee sein, zu sagen, passt auf,

00:06:34: immer wenn das bei euch auftritt, nehmt euch diese Zeit und schaut, was können wir vielleicht

00:06:40: an unseren Prozessen verbessern. Deswegen, ja, ich glaube auch kontinuierliche Verbesserung

00:06:45: gehört einfach zu den Fundamenten, zu einem Kern der agilen Arbeit. Der nächste Punkt heißt

00:06:51: Zusammenarbeit mit dem Kunden, Kollaboration würde ich es nennen. Und das taucht auch wirklich,

00:06:57: ja, so gut wie überall auf, in so gut wie allen Frameworks. Und denke ich,

00:07:04: ist einfach unheimlich wichtig, mit dem Kunden gemeinsam etwas zu schaffen. Und das gilt für

00:07:11: das Produkt, das gilt für die Prozesse, das gilt für, wann wollen wir was releasen,

00:07:17: was macht da Sinn und was soll da wirklich released werden. Das gilt beim Storyschreiben. Ihr seht,

00:07:23: natürlich ist es eine riesen Bandbreite. Wir wollen über die Zeit ein Verständnis aufbauen

00:07:29: für das, was der Kunde schafft. Denn wir wollen, ja, immer besser werden darin, die Domäne des

00:07:36: Kunden zu verstehen. Wenn man so einen neuen Kunden hat, ist das am Anfang sicherlich nicht

00:07:39: so einfach. Aber über die Zeit hinweg ist die Beratungsleistung, die wir dadurch diese

00:07:45: Kommunikation haben, glaube ich, immer größer. Auch dazu habe ich mal eine Folge gemacht,

00:07:50: nämlich NBE 18, den Kunden mitnehmen. Da denke ich eben, es ist einfach wichtig,

00:07:56: den Kunden da zu verstehen. Und auch da kann ich Stefan nur voll zustimmen in seinem Artikel.

00:08:01: In Punkt 5 greift Stefan tatsächlich auch das Thema Selbstorganisation auf. Wenn ihr die letzten

00:08:07: Folgen gehört habt, habt ihr festgestellt, das war jetzt auch die letzten Wochen so ein bisschen

00:08:12: mein Fokus. Ich will hier gar nicht so tief drauf eingehen. Wenn euch das interessiert,

00:08:18: was bedeuten autonome Teams? Welche Stufen gibt es da? Kann ich euch nur empfehlen,

00:08:22: NBA 62 einmal zu hören. Da bin ich da ziemlich tief eingestiegen. In Punkt 6 geht es, Stefan,

00:08:29: um Anpassungsfähigkeit und Reaktion auf Veränderungen. Und meiner Meinung nach ist

00:08:36: das eines der fundamentalsten Dinge, warum wir agil arbeiten. Wir leben in einer schnellen Welt.

00:08:43: Unsere Kunden leben in einer schnellen Welt. Wir wissen, Dinge und Anforderungen verändern sich.

00:08:49: Wir wissen auch, wir können gar nicht am Anfang von einem Projekt wirklich wissen,

00:08:54: was denn, wenn es abgeschlossen ist oder wenn eine Phase abgeschlossen ist, wirklich benötigt wird,

00:09:01: ob das, was wir gedacht haben, wirklich richtig ist. Und deswegen ist es so unheimlich wichtig,

00:09:06: anpassungsfähig zu bleiben. Im Kundensinne oder im Produktsinne. Es nützt überhaupt nichts,

00:09:13: an etwas festzuhalten. Ich erzähle euch jetzt sicherlich nichts Neues, aber wenn man in einen

00:09:19: Change-Prozess kommt, in so einen klassischen, ja, dann ist eine gute Gelegenheit, darüber nachzudenken,

00:09:26: wie hätte man das Projekt anders starten können, um anpassungsfähig zu sein. Im siebten Punkt

00:09:34: erwähnt er kontinuierliche Integration. Das hängt ein bisschen mit Continuous Delivery,

00:09:40: dem Punkt, den ich vorhin hatte, zusammen. In der Integration geht es ja darum, möglichst oft den Code,

00:09:47: an dem ich arbeite, in die Hauptcode-Basis zu integrieren. Also ich möchte ganz gerne,

00:09:52: dass mein Code-Stand immer in einem Zustand ist, dass ich ihn releasen kann. Immer, ja,

00:10:00: dieser Zyklus sollte so kurz wie möglich sein. Das geht nicht immer, dass man das,

00:10:05: sage ich mal, tagesweise macht. Aber wenn es monatsweise ist, würde ich zumindest sagen,

00:10:10: ja, da ist irgendein Problem. Es mag Umfelde geben, in denen es gar nicht anders geht,

00:10:16: weil äußere Einflüsse, keine Ahnung, Sicherheitsregeln oder so, das gar nicht anders

00:10:21: zulassen. Aber der Versuch, da immer ein Stückchen besser zu werden, hilft uns insgesamt beim agilen

00:10:27: Arbeiten. Der nächste Punkt lautet Transparenz. Und das ist auch wieder so ein fundamentales

00:10:33: Prinzip. Wir wollen offen und ehrlich miteinander umgehen. Wir wollen auch offen in dem umgehen,

00:10:39: was wir gerade schaffen, an was wir gerade arbeiten. Also ein Daily sollte offen sein.

00:10:45: Ein Board sollte man sehen können. Wir wollen gemeinsam mit dem Kunden unsere Dokumentationen

00:10:51: teilen und unseren Codefortschritt. Transparenz gilt auch für Transparenz untereinander. Wir

00:10:58: wollen damit Vertrauen auch aufbauen und Vertrauen erhalten. Deswegen, ja, Transparenz sicherlich eine

00:11:05: ganz wichtige Sache. Der neunte Punkt, Feedback schleifen, der ist im Prinzip das andere Ende

00:11:12: der Entwicklung. Was will ich damit sagen? Wir versuchen auf der linken Seite, nenne ich es mal,

00:11:20: die Entwicklung iterativ zu gestalten. Wir wollen viel releasen. Wir wollen schnell releasen,

00:11:25: damit wir, und das ist eben die rechte Seite, in Feedback schleifen kommen. Das gilt für das

00:11:31: Produkt. Aber ehrlich gesagt, es gilt genauso für uns als Team. Auch da wollen wir möglichst viel

00:11:39: Feedback nutzen. Feedback hilft uns zu lernen. Da gehört sicherlich auch Fehlerkultur zu. Ich

00:11:47: habe mal in der Folge NBA 14 über eine Methode gesprochen, die wir meiner Meinung nach recht

00:11:54: erfolgreich benutzen, nämlich Peerfeedback, jedem die Chance zu geben, regelmäßig Feedback von seinen

00:12:01: Peers zu bekommen. Den zehnten Punkt nennt Stefan Einfachheit. Und auch das ist etwas super

00:12:09: Fundamentales. Wir wollen versuchen, die nicht geleistete Arbeit zu maximieren. Wir kennen

00:12:17: sicherlich alle das Pareto-Prinzip 80-20. Es ist, zumindest in meiner Praxis, auch immer wieder so,

00:12:25: dass die letzten x Prozent von dem, was sich zum Beispiel ein Kunde mal wünscht, später gar nicht

00:12:31: mehr benötigt werden. Oder auf eine ganz, ganz andere Art. Und deswegen so Scope Creep und so

00:12:38: Sachen, da hilft wirklich das Prinzip der Einfachheit. Was ich auch weiß, und da sind wir

00:12:45: wieder beim Kunden, also unsere Situation ist ja, wir entwickeln Software für Kunden, dass ein Kunde

00:12:52: mit Einfachheit ein großes Problem hat. Ich verstehe das auch. Was bedeutet das denn für den

00:12:57: Kunden? Der verzichtet jetzt erstmal. Wenn wir dem Kunden raten, pass auf, ich verstehe dein

00:13:04: Gesamtbild, aber lass uns doch erstmal nur das und das machen. Das wäre doch im Handling einfacher

00:13:09: oder wäre eine erste Version. Dann wirkt das vielleicht für den Kunden zuerst so, A, na gut,

00:13:18: dann weiß ich ja gar nicht, was ich kriege und welche weiteren Kosten auf mich zukommen. Und B,

00:13:24: ich bin mir eigentlich sicher, dass das so nicht reichen wird. Und das ist dann mit Einfachheit in

00:13:30: meiner Definition auch nicht gemeint. Mit Einfachheit können wir super viel erreichen. Okay,

00:13:36: und ja, das sind die zehn Punkte von Stefans Artikel. Grüße gehen raus. Vielen Dank nochmal.

00:13:42: Wie gesagt, ist eine super Inspiration, passt genau in das, wie ich denke. Ich will diese zehn Punkte

00:13:48: einmal wiederholen. Also, was hatten wir jetzt? Wir hatten iterative Entwicklung, wir hatten

00:13:53: inkrementelle Lieferung, wir hatten kontinuierliche Verbesserung, wir hatten die Zusammenarbeit mit dem

00:13:58: Kunden, wir hatten die Selbstorganisation von Teams, die Anpassungsfähigkeit und Reaktion auf

00:14:05: Veränderung, kontinuierliche Integration, Transparenz, Feedback schleifen und die

00:14:10: Einfachheit. Mein Tipp wäre, prüft mal, wie ernst ihr diese Punkte nehmt. Wenn es so ist,

00:14:17: dass ihr vielleicht eher steht an dem Punkt, wo ihr sagt, naja, wir machen Scrum und nicht euch

00:14:25: in diesen zehn Punkten oder in allen zehn Punkten wiederfindet, vielleicht seid ihr dann so ein

00:14:32: bisschen im Karko-Kult. Und auch dazu habe ich eine Folge gemacht, nämlich NBA 65. Ja,

00:14:39: und damit würde ich sagen, sind wir durch. Gebt mir gerne Feedback. Natürlich zu dem,

00:14:45: was ich erzählt habe. Gerne auch zu dem Thema, ob das irgendwie zu cheesy ist,

00:14:50: wenn ich hier auf altere Folgen hinweise. Heute war ziemlich extrem, finde ich zumindest. Oder

00:14:57: ob ihr sagt, nee, das ist eigentlich gut. Dann weiß ich nämlich, ah, da könnte ich vielleicht

00:15:00: auch nochmal reinhören. Ansonsten habe ich wie immer eine ganz große Bitte. Wenn dir die Folge

00:15:05: hier gefallen hat, wenn dir vielleicht sogar der ganze Podcast gefällt, dann teil diese Info gerne

00:15:11: mit Kolleginnen und Kollegen und natürlich gerne auch auf Social Media. Je mehr Leute hier von

00:15:16: dem Podcast erfahren, desto größer wird die Diskussion. Das meine ich wirklich positiv.

00:15:20: Desto mehr Feedback bekomme ich, desto mehr kann ich wieder aufgreifen und daraus neue

00:15:25: Folgen machen. Ja, und das kommt, wenn es gut läuft, dir natürlich auch wieder zugute.

00:15:29: Ansonsten sage ich, habe noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.

00:15:41: Untertitel von Stephanie Geiges