NBA23: Heuristics for Effective Software Development
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile.
Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/39-nba23-heuristics-for-effective-software-development
Zusammenfassung
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.
Links
Letzte Folge NBA22: Wer treibt Agilität im Unternehmen voran?
Heuristics for Effective Software Development
Agile & Scrum Don't Work
NBA15: Warum so viele scheitern: Agilität ist ein Mindset!
NBA21: Fehlerkultur
Transkript anzeigen
Hallo und herzlich willkommen bei NoBullshit 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 die großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt dabei auf der Praxis, da er auch der Name NoBullshit Agile. Inletzten Folge habe ich darüber gesprochen, wer meiner Meinung nach die Agilität in Unternehmen vorantreibt. Wenn ich das interessiert, hör da gerne rein. Den Link dazu findest du in den Show-Nutz. Das hier ist die Folge 23. Auf die freue ich mich schon ziemlich lange. Ich wollte aber vorher ein paar andere Themen bearbeiten hier im Podcast. Heute soll es um eine Liste gehen von Ellen Holop. Er nennt sie Horistics for Effortive Software Development. Ja, 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 Ellen. Über die bin ich gesteupert, über ein YouTube Video. Da komme ich gleich auch noch mal drauf. Der ist Software Architekt. Eigentlich hat er mal mit Hardware Architektur angefangen, aber schlussendlich dann in Software Architektur gelandet. Heute ist er tatsächlich eher Konsultant und Trainer und sein Fokus liegt tatsächlich auf Agilität von Unternehmen. Er bringt halt super viel Erfahrung mit. Ich weiß gar nicht, wie alt er ist. Ich denke mal, der wird 60 plus sein. Ich finde ihn super sympathisch. Ich finde 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 den YouTube-Kanal. Da geht es rund um Continuous Integration, Continuous Delivery, Test-Driven Development. Er ist eher so Software-Entwickler-Fokus. Sie unterhalten sich da über Agilität und Scrum. Schaut da gerne mal rein. Auch den Link gibt es in den Show-Notes. Wie gesagt, Ellen finde ich halt sehr sympathisch. Was ich super an ihm schätze und warum ich mich so sehr auf diese Folge gefreut habe, ist, er ist super pragmatisch, wie ihr vielleicht schon mitbekommen habt. Ich versuche ja auch immer einen Pragmatismus in Agilität zu sehen. Ich versuche ja immer, das Anfassbare da drin 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 da meine, die hat er mal aufgestellt. Den Link gibt es natürlich auch in den Show-Notes übrigens und gesagt, okay, er nimmt sich mal das Agile-Manifest und die 12 Agilen-Prinzipien, denkt mal drauf rum und versucht jetzt mit dieser Liste so einen anderen Blickwinkel darauf zu bekommen. Die hat er wohl Stück für Stück erweitert. Die ist ein bisschen älter. Das macht sie aber jetzt nicht schlechter in meinen Augen. Und schlussendlich sind es dann jetzt 27 Punkte. Ich weiß auch nicht, ob er da weiter dran arbeitet. Wenn ihr mir auf Mastodon folgt, dann habt ihr tatsächlich schon diese Liste einmal kennengelernt, weil ich meine Zeit lang so jeden Tag einen Punkt aus dieser Liste gepostet habe. Ich greif das gerade übrigens auf Mastodon wieder auf, habe das ein bisschen bebildert und ja, 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, sondern das fängt viel, viel früher an. Und diese Liste, wie gesagt, die manifestiert das ganze nochmal. Sie gibt, finde ich, schöne Denkan setze zu, was heißt es denn wirklich, Agil zu sein? Warum will man denn Agil sein? Und 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 sollen wirklich als Inspirationsquelle für euch dienen. Als ein Staat fangen wir mal mit dem ersten Punkt, den ich rausgepickt habe an. Ohne psychologische Sicherheit, Respekt und Vertrauen ist nichts von dem möglich, was folgt. Damit wird sie sich dann 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, einen Fundament in der Agilität. Und diese Punkte, psychologische Sicherheit, Respekt und auch Vertrauen sind ja 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 herum bastelt. Ja, ist halt einfach auch wieder so super treffend. Wenn ihr an der Agilität arbeitet, bedenkt, systemisch gedacht tatsächlich auch, dass ihr da nicht auf einer Insel lebt, 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. Und 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 ja, das soll einfach 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 um unter anderem auch die Selbstorganisation. Wenn ein Team zum Beispiel ein 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 ab. Ich kann natürlich sagen, und das ist unser Prozess und manchmal muss ich das ja auch vorgeben. Und das ist der Prozess, der Kunde hat vielleicht ein Eitelprozess 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? Und 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 zum Beispiel, nicht andersrum. Der nächste Punkt zeigt so ein bisschen die Bandbreite dieser Liste. Ja, vollkommen richtig. Agil, sage ich immer wieder, heißt nicht schnell, sondern Agil heißt halt beweglich oder flexibel. Und deswegen, es gehört dazu, es ist so, unsere Welt verändert sich. 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, der 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, und proaktive Verbesserung vorzunehmen. Hier geht es natürlich klar, um die Feedback-Zyklen. Und diese Feedback-Zyklen haben wir halt an vielen Stellen. Und wir wollen auch so viele Feedback-Zyklen, wie nur irgend möglich haben. Wir haben Feedback-Zyklen zum Beispiel durch eine Iteration. Und wir bekommen dann einen Kundenfeedback. Wir haben Feedback-Zyklen durch eine Retro, wo wir uns selber angucken. Und wir wollen das wirklich institutionalisieren. Und dieser Punkt, dass man auch, wenn etwas schiefgeht, innehalten soll, den 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, wer hier halt das Stichwort dazu hatte, ich auch mal eine Folge gemacht, auch das werde ich gerne in den Schonhuts verlinken. Der vorletzte Punkt, den ich rausgepickt habe, der superprä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 das gilt 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, der 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 weitergreifen. Also 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 edukaten. 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 überlegen, kann ich das besser erklären, warum das gut ist. 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, finde ich die besten Punkte aus der Liste, sondern ich habe relativ viel kürlich jetzt 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 denn 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, an dem agilen Manifest, den 12 Prinzipien. Sie sind weit weg von Frameworks wie Scrum oder Kannman und das finde ich ist an dieser Stelle einfach was Gutes. Bespricht sie vielleicht sogar mit eurem Team, bespricht sie vielleicht sogar mit Leuten außerhalb eures Teams, damit alle mal so ein Eindruck davon bekommen. Was heißt denn Agilität und was ist so, ja, ich sage mal die Grundlage, die Basis dazu. Wie immer freue ich mich über Feedback. Wenn du eine Meinung dazu hast, wenn dir Dinge vielleicht nicht gefallen an dieser Liste, vielleicht an dem Podcast insgesamt oder an Meinungen von mir, dann lass mich das auch gerne wissen. Ich selber möchte eben gerne Feedback haben. Du erreist mich dazu auf verschiedenen Kanälen. Du kannst mir zum Beispiel in der Mail schreiben an nobsgileagmail.com. Du findest mich auf Mastzodon und begleitend zum Podcast gibt es auch ein Forum. Da gibt es zum Beispiel 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. * eurem Klavierことen * * Musik * [Musik] [MUSIK]
Neuer Kommentar