In Folge 23 von „No Bullshit Agile“ taucht Thomas in die „Heuristics for Effective Software Development“ von Allen Holub ein. Holub, ein erfahrener Software-Architekt und agiler Consultant, hat diese Liste erstellt, um einen pragmatischen Blick auf die Prinzipien der effektiven Software-Entwicklung zu werfen, inspiriert durch das Agile Manifest und die 12 agilen Prinzipien.

Die Kernaussagen der Folge umfassen:

Psychologische Sicherheit und Vertrauen: Der Grundstein für agile Praktiken ist ein Umfeld, das psychologische Sicherheit, Respekt und Vertrauen bietet.
Systemisches Denken: Veränderungen sollten systemisch angegangen werden, da man nicht einzelne Teile isoliert verbessern kann, ohne das gesamte System zu berücksichtigen.
Prozesse dienen den Menschen: Prozesse sollten von den Menschen entwickelt werden, die sie nutzen, um effektiver zu sein und den Menschen zu dienen, nicht umgekehrt.
Veränderungen als Vorteil: Die Fähigkeit, sich an Veränderungen anzupassen, ist der einzige nachhaltige Wettbewerbsvorteil.
Kontinuierliche Verbesserung: Verbesserung ist ein fortlaufender Prozess, der regelmäßige Reflexion und Anpassung erfordert.
Unverhandelbare Qualität: Qualität ist in allen Aspekten der Arbeit unerlässlich und nicht verhandelbar.
Transparenz im Management: Transparenz reduziert Angst und Widerstand, indem sie Klarheit über Prozesse und Entscheidungen schafft.

Thomas empfiehlt, die Liste von Holub gründlich zu prüfen und die Punkte als Inspirationsquelle zu nutzen, um das agile Mindset im täglichen Arbeitsumfeld zu verfestigen. Diskutiert die Punkte mit eurem Team und reflektiert, wie sie eure Praxis verbessern können.

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier 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 auf der Praxis, daher auch der Name No Bullshit Agile.

In der letzten Folge habe ich darüber gesprochen, wer meiner Meinung nach die Agilität in Unternehmen vorantreibt. Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du in den Shownotes. Das hier ist die Folge 23. Auf die freue ich mich schon ziemlich lange. Ich wollte aber vorher ein paar andere Themen hier im Podcast bearbeiten. Heute soll es um eine Liste von Allen Holub gehen. Er nennt sie "Heuristics for Effective Software Development".

Bevor wir in die Liste einsteigen, vielleicht vorab mal: Warum finde ich sie so gut und warum habe ich mich auf diese Folge gefreut? Vielleicht erst mal kurz ein paar Worte über Allen. Über ihn bin ich gestolpert durch ein YouTube-Video. Dazu komme ich gleich auch nochmal. Er ist Software-Architekt. Eigentlich hat er mal mit Hardware-Architektur angefangen, aber ist schließlich in der Software-Architektur gelandet. Heute ist er tatsächlich eher Consultant und Trainer, und sein Fokus liegt auf der Agilität von Unternehmen. Er bringt halt super viel Erfahrung mit. Ich weiß gar nicht, wie alt er ist. Ich denke mal, er wird 60 plus sein. Ich finde ihn super sympathisch. Er hat einen super pragmatischen Ansatz und einen super pragmatischen Touch, was Agilität anbelangt.

Wenn ihr mal einen Eindruck von ihm gewinnen wollt: Er hat super viele Vorträge auf YouTube. Ich finde ein Gespräch mit Dave Farley eigentlich ganz interessant. Dave Farley hat einen YouTube-Kanal, da geht es rund um Continuous Integration, Continuous Delivery, Test-Driven Development. Er ist eher so auf Software-Entwickler fokussiert. Sie unterhalten sich da über Agilität und Scrum. Schaut da gerne mal rein. Auch den Link gibt es in den Shownotes. Wie gesagt, Allen finde ich halt sehr sympathisch. Was ich super an ihm schätze und warum ich mich so sehr auf diese Folge gefreut habe, ist, dass er super pragmatisch ist, wie ihr vielleicht schon mitbekommen habt. Ich versuche ja auch immer, Pragmatismus in der Agilität zu sehen. Ich versuche ja immer, das Anfassbare darin zu finden. Es gibt so viele Artikel, die super theoretisch sind. Und ehrlich gesagt, ich habe einfach große Schwierigkeiten mit so theoretischen Artikeln, weil ich immer denke: "Ja, okay, verstehe schon irgendwie, was du meinst, aber was heißt das jetzt für mich in der Praxis?"

Und diese Liste, die ich meine, hat er mal aufgestellt. Den Link gibt es natürlich auch in den Shownotes. Er hat gesagt: "Okay, er nimmt sich mal das Agile Manifest und die 12 agilen Prinzipien, denkt mal darüber nach und versucht jetzt mit dieser Liste so einen anderen Blickwinkel darauf zu bekommen." Die hat er wohl Stück für Stück erweitert. Sie ist ein bisschen älter. Das macht sie aber jetzt nicht schlechter in meinen Augen. Schlussendlich sind es jetzt 27 Punkte. Ich weiß auch nicht, ob er da weiter daran arbeitet. Wenn ihr mir auf Mastodon folgt, dann habt ihr diese Liste schon einmal kennengelernt, weil ich eine Zeit lang jeden Tag einen Punkt aus dieser Liste gepostet habe. Ich greife das gerade übrigens auf Mastodon wieder auf, habe das ein bisschen bebildert und picke mir immer mal passende Dinge aus dieser Liste raus.

Die Liste ist für mich deswegen so handhabbar und pragmatisch, weil sie mir hilft, in dieses Thema einzusteigen oder das Thema zu verfestigen. Agilität ist ja eigentlich ein Mindset. Dazu habe ich übrigens auch eine explizite Folge gemacht. Das ist NBA 15, wo ich darüber spreche, dass Agilität nichts mit Regeln zu tun hat und nichts mit dem Framework. Also nur, weil man Scrum macht, ist man nicht agil, oder nur, weil man Kanban macht. Das fängt viel, viel früher an. Und diese Liste, wie gesagt, manifestiert das Ganze nochmal. Sie gibt, finde ich, schöne Denkanstöße dazu, was es wirklich heißt, agil zu sein. Warum will man denn agil sein?

Ich habe mir jetzt mal ein paar Punkte rausgepickt. Ich lese jetzt nicht die ganze Liste vor. Ich habe die mal auf Deutsch übersetzt und würde die einfach mal durchgehen. Das soll wirklich als Inspirationsquelle für euch dienen. Als Einstieg fangen wir mal mit dem ersten Punkt an, den ich rausgepickt habe: "Ohne psychologische Sicherheit, Respekt und Vertrauen ist nichts von dem möglich, was folgt." Damit bezieht sich Allen auf den Rest der Liste. Das ist der erste Punkt. Und das ist natürlich eigentlich sogar eine Selbstverständlichkeit. Aber wenn ihr eine Kultur in der Firma habt, wo Punkte davon nicht gut gegeben sind, wäre tatsächlich mein erster Tipp schon: Setzt mal, bevor ihr euch mit Agilität beschäftigt, an diesem Punkt an. Wir brauchen eine gewisse Basis, ein Fundament in der Agilität. Und diese Punkte, psychologische Sicherheit, Respekt und auch Vertrauen, sind fundamentale Punkte dazu.

Der nächste Punkt: "Die Art und Weise, wie wir arbeiten, die Arbeit, die wir tun und die Organisationen, in denen wir arbeiten, sind alle Teil eines zusammenhängenden Systems. Man kann nichts ändern, ohne alles zu ändern. Man kann ein System nicht verbessern, indem man an den einzelnen Teilen herumbastelt." Ja, das ist einfach auch wieder super treffend. Wenn ihr an der Agilität arbeitet, bedenkt, dass ihr systemisch denken solltet. Ihr lebt nicht auf einer Insel, sondern ihr habt ein Umfeld. Und selbst wenn man auf einer Insel leben würde, hätte man ja auch ein Umfeld. Also, wenn man auf einer Insel lebt und Feuer machen will und es regnet, wird das super schwer. Das ist natürlich in unserem echten Leben immer so. Es gibt Kunden, es gibt Vorgesetzte, es gibt andere Teammitglieder, es gibt andere Teams. Ihr habt einfach einen Einfluss, es gibt Technologien, die sich ändern. Und das soll euch sehr bewusst sein, weil dann erkennt man auch ziemlich schnell: "Ah, ich müsste vielleicht erst da hinten an der Schraube drehen, bevor ich an meiner Schraube drehen kann."

Der nächste Punkt: "Prozesse stehen im Dienste der Menschen. Die Menschen stehen an erster Stelle. Prozesse, die nicht von den Menschen entwickelt werden, die sie anwenden, funktionieren selten gut, wenn überhaupt." Der Punkt sagt ganz klar, es geht hier unter anderem auch um die Selbstorganisation. Wenn ein Team zum Beispiel einen Prozess bekommt, den das Team nicht versteht, dann wird das Team einfach große Schwierigkeiten haben, diesen Prozess wirklich zu leben. Ich top-down-button-up. Ich kann natürlich sagen, und das ist unser Prozess, und manchmal muss ich das ja auch vorgeben. Der Kunde hat vielleicht ein ITIL-Prozess oder so. Das kommt natürlich dann nicht vom Team, aber dann ist es super wichtig, dem Team zu erklären: Warum ist das so? Was ist der grundsätzliche Anlass, dass es diesen Prozess gibt? Es ist so, dass es super schwer ist, für Leute Prozesse zu verstehen, die nicht von ihnen kommen. Wenn der Prozess vom Team selber oder von Einzelnen kommt, dann haben die den Prozess entwickelt, weil sie bestimmte Dinge machen oder verhindern wollen. Das macht es natürlich viel transparenter. Kommt der Prozess von außen, wird es super schwer. Wichtig in dem Punkt ist auch noch: Prozesse stehen im Dienste der Menschen. Also wir wollen unsere Arbeit erleichtern oder sicherer machen, nicht andersrum.

Der nächste Punkt zeigt so ein bisschen die Bandbreite dieser Liste: "Veränderungen sind unvermeidlich und gut. In der Tat ist unser einziger nachhaltiger Wettbewerbsvorteil die Fähigkeit, uns an Veränderungen anzupassen." Ja, vollkommen richtig. Agil, sage ich immer wieder, heißt nicht schnell, sondern Agil heißt beweglich oder flexibel. Deswegen gehört es dazu, dass unsere Welt sich verändert. Wir müssen Veränderungen begrüßen, und zwar an jeder Stelle in Organisationen, in Prozessen, in Produkten und in Plänen. Es nützt überhaupt nichts zu sagen: "Wieso, das war doch mal der Plan", denn der Plan ändert sich halt immer und immer wieder.

Der nächste Punkt, den ich rausgepickt habe, lautet: "Wir verbessern uns ständig, indem wir beobachten, wie wir arbeiten und alle Probleme, auf die wir stoßen, beheben. Verbesserung ist eine fortlaufende, nicht eine periodische Tätigkeit. Wenn etwas schiefgeht, halten wir inne und überlegen uns, wie wir unseren Prozess verbessern können, damit das Problem nicht wieder auftritt. Wir konzentrieren uns auf das System, nicht auf die Menschen. Gelegentlich halten wir inne und denken über unsere Arbeit nach, um proaktive Verbesserungen vorzunehmen." Hier geht es natürlich klar um die Feedback-Zyklen. Diese Feedback-Zyklen haben wir halt an vielen Stellen. Wir wollen auch so viele Feedback-Zyklen wie nur möglich haben. Wir haben Feedback-Zyklen zum Beispiel durch eine Iteration, und wir bekommen dann ein Kundenfeedback. Wir haben Feedback-Zyklen durch eine Retro, wo wir uns selber angucken. Wir wollen das wirklich institutionalisieren. Und dieser Punkt, dass man auch, wenn etwas schiefgeht, innehalten soll, halte ich auch für ganz wichtig. Innehalten heißt ja auch nicht, dass man jetzt irgendwie alles unterbricht und stundenlang innehält, aber jeder Einzelne und die Organisation und das Team sollte, wirklich, wenn etwas nicht so funktioniert hat wie erwartet, sich die kurze Zeit nehmen, innezuhalten und zu analysieren: Warum ist da etwas schiefgegangen? Wenn wir das nicht tun, kommen wir nicht weiter. Fehlerkultur ist hier das Stichwort. Dazu hatte ich auch mal eine Folge gemacht, auch das werde ich gerne in den Shownotes verlinken.

Der vorletzte Punkt, den ich rausgepickt habe, ist super prägnant: "Qualität ist nicht verhandelbar. Diese Regel gilt für alle Aspekte der Qualität, nicht nur für das Testen." Wir wollen einen Anspruch gegen uns haben. Wir wollen gucken, dass wir in allem, was wir tun, die Qualität hochhalten. Er sagt ja selber, das gilt nicht nur für das Testen, sondern eben für alles. Also zum Beispiel auch, wie wir arbeiten, wie unsere Prozesse sind, wie wir uns auf ein Daily vorbereiten, wie wir ein Daily durchführen. Qualität ist nicht verhandelbar.

Der letzte Punkt, den ich rausgepickt habe, hat so den Fokus ein bisschen auf unser Umfeld: "Ein Großteil der Dysfunktionalität im Management ist auf Angst zurückzuführen, die wiederum aus einem Mangel an Transparenz resultiert. Unsere Prozesse müssen so transparent wie möglich sein." Klar, natürlich ist es so, unser Umfeld, er sagt jetzt hier Management, das kann man vielleicht sogar noch ein bisschen weiter greifen. Vielleicht meint er mit Management auch Kunden, weil ich würde es da auch drauf beziehen. Wir müssen aufklären, wir müssen transparent sein. Wir müssen die Leute edukieren. Jetzt bin ich wieder bei dem Wort. Das hatte ich in einer Folge auch schon mal, wo mir eine gute Übersetzung fehlt. Ich denke aber, ihr wisst, was ich meine. Solange wir nicht transparent sind und nicht aufklären, können ganz natürlich Ängste entstehen. Wenn jemand nicht weiß, was mit ihm passiert, wird er höchstwahrscheinlich eine gewisse Art von Angst entwickeln und das bedeutet in der Konsequenz auch sofort, dass so ein Widerstand entsteht. Und gerade wenn man zum Beispiel mit Kunden anfängt, neue Prozesse einzuführen, kann die Reaktion eben Angst sein und dann solltet ihr auch wieder mal kurz innehalten und überlegen: Kann ich das besser erklären? Warum ist das gut? Wir machen ja Dinge, weil wir daran glauben, dass sie besser sind, und deswegen können wir in der Regel oder eigentlich immer das auch gut erklären.

Ja, und das sind so meine rausgepickten Punkte. Ich habe jetzt nicht lange geguckt, um die besten Punkte aus der Liste zu finden, sondern ich habe relativ willkürlich welche rausgepickt. Mein Tipp wäre: Geht die Liste wirklich mal durch. Wie gesagt, ich finde sie super inspirierend. Ich finde es gut, sich die Liste anzugucken und sich selber mal die Zeit zu nehmen, zu jedem Punkt zu überlegen: Was sagt mir das für meine tägliche Arbeit? Denn ich finde, die Punkte sind wirklich sehr konkret. Sie sind eben super dicht auch an diesem agilen Mindset, am agilen Manifest und den 12 Prinzipien. Sie sind weit weg von Frameworks wie Scrum oder Kanban und das finde ich an dieser Stelle einfach gut. Besprecht sie vielleicht sogar mit eurem Team, bespricht sie vielleicht sogar mit Leuten außerhalb eures Teams, damit alle mal so einen Eindruck davon bekommen, was Agilität heißt und was die Grundlage, die Basis dazu ist.

Wie immer freue ich mich über Feedback. Wenn du eine Meinung dazu hast, wenn dir Dinge vielleicht nicht gefallen an dieser Liste, am Podcast insgesamt oder an meinen Meinungen, dann lass mich das gerne wissen. Ich selber möchte eben gerne Feedback haben. Du erreichst mich auf verschiedenen Kanälen. Du kannst mir zum Beispiel eine Mail schreiben an nobsagile@gmail.com. Du findest mich auf Mastodon und begleitend zum Podcast gibt es auch ein Forum. Da gibt es zu jeder Folge einen eigenen Thread. Da freue ich mich auch immer über Feedback. Ja, lass uns gerne ins Gespräch kommen. Das soll es für heute gewesen sein. Ich wünsche dir noch eine ganz tolle Woche und bis zum nächsten Mal.

NBA23: Heuristics for Effective Software Development

Shownotes

Zusammenfassung

Transkript

Featured

Subscribe

Tags