Dieser Episode beinhaltet keine Notizen

Matthias: [00:00:05.84] Hallo und herzlich willkommen zu einer neuen Folge der „Macht der Craft“. Hier ist wieder Matthias,

Alex: [00:00:11.42] Ich bin der Alex. Heute wollen wir mit dir über Agilität in der Softwareentwicklung reden,

Matthias: [00:00:17.30] Denn die agile Welt ist da, ob du das willst oder nicht. Und letztendlich muss auch du dich dafür wappnen.

Alex: [00:00:23.30] Was bedeutet das für dich als Software-Entwickler? Welche Möglichkeiten gibt es, agil zu arbeiten?

Matthias: [00:00:29.42] Du erfährst heute, welche Methoden und Frameworks in den meisten Fällen zur Anwendung kommen, um agil zu implementieren.

Alex: [00:00:35.87] Natürlich kriegst du auch ein kleiner Überblick darüber, was diese Methoden sind und wie sie sich unterscheiden.

Matthias: [00:00:42.62] Du lernst, was „Cynefin“ und die „Stacy-Matrix“ sind und warum sie eine Rolle spielen.

Alex: [00:00:47.63] Und vor allem gehen wir mit dir gemeinsam der Frage nach: Gibt es die beste agile Methode überhaupt?

off: [00:00:56.36] Die Macht der Craft arbeitet für dich.

Alex: [00:01:02.41] Was soll eigentlich die ganze Aufregung mit dieser Agile? Seit einigen Jahren hören wir dauernd: Man muss agil arbeiten, agile Softwareentwicklung und agiles Mindset. Und was soll des eigentlich alles? Wir haben jetzt viele Jahre gearbeitet. Viele, viele Jahre haben wir von agil gar nichts gewusst, gar nicht gemacht. Und wie jetzt auf einmal muss alles agil werden. Aber warum? Was erwarten wir uns von dieser in Anführungszeichen Agilität? Was denkst du, Matthias? Hast du ein paar Ideen?

Matthias: [00:01:35.95] Ich glaube, das Hauptproblem ist, dass die Art und Weise, wie man es vor der agilen Zeit gemacht hat. Also wenn wir jetzt zum Beispiel am Wasserfall und so denkt Wasserfall oder V Modell, dass die halt alle sich nicht bewährt haben. Also die Quote an Projekten, die fehlschlagen, die mit diesen Methoden gemacht werden, ist halt sehr, sehr hoch. Und die Agilität in der Softwareentwicklung ist letztendlich würde ich sagen, erst mal ein Versuch, dieses Problem irgendwie in den Griff zu bekommen, sodass Projekte weniger häufig ein Misserfolg sind.

Alex: [00:02:12.58] Okay, ich finde das Thema Agilität ja hat unterschiedliche Aspekte und wir werden es jetzt gleich sehen. Es geht einfach darum, nicht zu sagen, alles was vorher war, ist schlecht, sondern wir sind der Meinung, dass es bessere Wege gibt, irgendwas zu tun. Und die Punkte, die für mich im Fokus stehen, ist eine eine Kunden Zentrierung mehr auf die Kundenbedürfnisse zu gehen und zu fokussieren. Und natürlich auch der zweite Punkt, das für mich sehr wichtig ist, ist eine schnelle Reaktion auf Veränderung zu gewährleisten, in der Lage zu sein, wenn sich irgendwas im Projekt ändern, schnell reagieren zu können und auch schnell diese Änderungen vornehmen zu können. Ich habe ihm Projekte gearbeitet, wo der Änderungs Management dran bestand. Irgendjemand hat sich irgendwas gewünscht und dann lag sechs Monate wie seit ein paar Jahren irgendwo rum, und – ja – irgendwann, wenn man Zeit hatte oder genug Punkte für das Thema gesammelt wurden. Ja, dann würde es erst einmal angegangen. Aber die Zeitabstände waren enorm. Und auch dann, wenn es entschieden würde Okay, das machen wir jetzt. Dann war es öfters mal nicht so leicht, diese Änderung durchzuführen, weil der Code so aussah, wie es aussah. Die Anwendung so gestrickt war, wie sie gestrickt war und so weiter und so fort. Und das sind Aspekte, die noch versucht werden, damit diese agile Entwicklung entgegenzuwirken. Findest du das auch so?

Matthias: [00:03:46.23] Ja klar. Also das sind ja aber letztendlich halt eben auch Ziele, die man mit dieser klassischen Art der Softwareentwicklung, Wasserfall und ähnlichen Modellen halt eben auch nicht erreichen kann, weil du halt da eben diese diese Tatsache hast, dass du im Prinzip eigentlich vorab alles planst, festlegst „Wann soll es fertig sein?“ Und dann alles runter ackerst. Und wenn da dann irgendwelche Änderungen Changes unseres reinkommen, dann bringt es natürlich den gesamten Projektplan durcheinander. Und klar, das sind natürlich auch Ziele, die man versucht mit diesen agilen Methoden zu erreichen, dass man schnell auf Änderungswünsche reagieren kann und die auch schnell zum Kunden bringen kann. Das ist natürlich korrekte.

Alex: [00:04:33.42] Okay, und wie ist diese agile Geschichte so entstanden? Da haben sich ein paar Leute getroffen, nun war es auf einmal da. Da gibt es eine Geschichte dahinter könnt ihr gerne mal im Netz nachschlagen. Im Großen und Ganzen war es so, dass über eine gewisse Zeit über unterschiedliche Kanäle einige Menschen, die in der Software-Entwicklung involviert waren, sich über eine längere Zeit darüber ausgetauscht haben. Wie können wir das besser machen? Und nach all diese Sessions und Kommunikation untereinander und Diskussionen ist irgendetwas entstanden, die man das Agile Manifesto nennt. Das ist eigentlich eine ziemlich einfache, – so eine Art zu sagen: „Was ist für die Softwareentwicklung für eine agile Softwareentwicklung wichtig?“ Das Agile Manifest besteht auf vier Punkte. Und dann gibt es halt irgendwelche Prinzipien, die davon abgeleitet werden, die dazu helfen sollen, tatsächlich diese Ziele zu erreichen. Ganz schnell, der Manifest agile Entwicklung besagt „Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“. Dass „funktionierende Software wichtiger ist als eine umfassende Dokumentation“. Dass die „Zusammenarbeit mit dem Kunden wichtiger ist als die Vertragsverhandlungen“ und das „Reagieren auf Veränderungen wichtiger ist als das Befolgen eines bestimmten Planes“. Die schreiben auch. Es ist nicht so, dass die Themen, die auf die rechte Seite der Aussage waren, Prozesse, Dokumentation, Vertrag nicht wichtig wären. Die sind auch wichtig, die haben auch ein Berechtigung da sein. Aber die anderen Themen wie Individuen, Interaktionen, funktionierende Software, Zusammenarbeit mit dem Kunden Reagieren auf Veränderungen einen höheren Wert haben.

Alex: [00:06:34.68] Und das ist im Großen und Ganzen, was die da sagen. Und dann gibt es halt diese Prinzipien. Die zwölf agile Prinzipien der Softwareentwicklung werden Sie genannt. Das könnt ihr gerne im Netz nachschlagen. Aber um agil zu arbeiten, haben sich im Laufe der Zeit unterschiedliche Methoden Frameworks etabliert und wir wollen jetzt ein bisschen darüber sprechen. Als erstes möchte ich Extreme Programming von Kent Beck den 90er Jahren glaube ich, wenn ich mich jetzt eine falsche erinnere, als eine Software-Entwicklungs-Methode mit dem Ziel, die Qualität der Software und die Möglichkeit auf Veränderung zu reagieren, besser einzuschätzen und besser machen zu können. Da fallen Themen wie Pair Programming, Unit-Testing, Code Reviews oder Continuous Code Reviewing in Form von eben, wie gesagt, Pair Programming. Features nur zu implementieren, wenn wir sie auch brauchen und nicht auf Vorrat zu programmieren. Flache Management Strukturen zu schaffen, Clean Code einfaches Code zu schreiben, das alles mit dem Ziel, eben besseren Code zu schreiben, klarerer Code zu schreiben, so dass wir leichter auf Änderung reagieren können, besser unsere Programme erweitern können und so weiter und so fort. Extreme Programming ist kein Framework an sich, sondern bietet einen Blumenstrauß an Möglichkeiten und Methoden, wie man entwickeln kann. Also da geht’s tatsächlich um die Entwicklungsarbeit. Aber okay, welche Frameworks oder Methoden der agile Entwicklung wollen wir uns jetzt anschauen, Matthias?

Matthias: [00:08:20.51] Da fangen wir doch mal mit der bekanntesten Methode an. Das wäre zumindest in meinen Augen erst mal Scrum. Und Scrum ist halt letztendlich ein Framework, mit dem man eben versucht, diesen agilen Entwicklungsprozess abzubilden, meistens in Form von Sprints, die meistens zwischen zwei bis vier Wochen oder so was dauern. Es gibt fixe Rollen im Scrum, die man wahrscheinlich jetzt nicht im Detail anschauen kann, aber jetzt vielleicht mal nennen kann. Also da gäbe es zum Beispiel den Scrum Master, der letztlich dafür verantwortlich ist, dass die Scrum Prozesse innerhalb des Scrum Teams auch eingehalten werden. Da gibt es dann den Product Owner, der letztendlich dafür verantwortlich ist, die Anforderungen in sogenannte Stories zu gießen, die dann wiederum von dem letzten Teil des Scrum Teams, nämlich dem Team, also dem Entwicklungsteam, in den meisten Fällen dann letztlich umgesetzt werden soll. Und da gehören dann noch so ein paar andere Geschichten dazu, wie das Die Working Items pro Sprint sind meistens begrenzt. Man versucht eben in einem Sprint vorher über Schätzmechanismen die Story so einteilen zu können, dass man anhand von der Entwicklung auch wie Story Points umgesetzt werden, dann ein gewisses Monitoring draus bekommt. Wie entwickelt sich das Team? Es wird nicht von Anfang an gut laufen, wenn man Scrum macht, aber über eine Zeit hinweg, wenn das Team sich an diesen Arbeitsmodus gewöhnt, dann wird man häufig feststellen, dass solche Schätzungen auch ganz gut funktionieren können. Es ist kommt halt immer ein bisschen drauf an. Es gibt Teams, die kommen damit besser klar als andere. Ja, letztendlich glaube ich werde das mal so der Schnelldurchlauf zu Scrum. Würdest du sagen, ich habe irgendwas vergessen?

Alex: [00:10:21.00] Ja, würde ich. Also über die Rollen hinweg. Das war ja schon recht gut, erklärt PO, Scrum-Master Team. Der Scrum Framework bietet einen Rahmen, in dem wir die Entwicklung einbetten und die nutzt bestimmte fixe Termine und Besprechungen, um das zu erreichen. Es gibt ein Daily, in dem man sich jeden Tag kurz trifft, und über den Stand der Sachen redet. Es gibt Planning Meetings, wo man plant, was man in den nächsten Sprint machen soll. Es gibt ein Review Meeting, in dem man den Stakeholder, also den Nutzer oder den Auftraggeber zeigt. Was ist in einem bestimmten Sprint passiert? Und es gibt ein ganz wichtiges Thema in Scrum. Es ist die Reflexion, über wie funktioniert unser Entwicklungs Vorgehen? Wie arbeiten wir als Team? Das machen wir in Form von möglicherweise Retrospektiven und es sind auch wichtige Aspekte, finde ich.

Matthias: [00:11:24.09] Da hast du vollkommen recht. Die habe ich mal schamlos vergessen.

Alex: [00:11:30.57] Aber sie sind auch Thema. Also Scrum ist auch mit einem gewissen Overhead verbunden, Termine, die man einhalten soll und so weiter. Nichtsdestotrotz ist ein System, die in vielen Unternehmen bei vielen Teams gut funktioniert, bei viele Projekte gut funktioniert. Von daher, warum nicht?

Matthias: [00:11:49.44] Weils auch populär ist,

Alex: [00:11:50.73] Warum nicht? Aber es ist die beste Methode, die wir wählen können.

Matthias: [00:11:55.35] Schauen wir mal, wenn du das rausfinden. Genau. Sollen wir dann zum nächsten übergehen oder

Alex: [00:12:01.44] Können wir gerne machen? Wir sind jetzt nicht jede ganz tief im Detail machen, das kann man vielleicht in eine andere Folge machen.

Matthias: [00:12:07.92] Genau. Unser nächster Anwärter für den Titel der besten agilen Methode, wenn es sie denn gibt wäre, dann Kanban und Kanban versucht im Gegensatz zu Scrum sich nicht in so einen Rhythmus zu begeben, also irgendwie Sprints oder sonstiges, sondern das ist im Prinzip ein fortlaufender Prozess, wo ein stetig gefülltes Backlog regelmäßig von den Softwareentwicklern und Entwicklerinnen abgearbeitet wird. Und anstatt jetzt, weil es eben keine Iterationen benutzt, die gleichzeitigen Work Items, die bearbeitet werden können, in Iterationen zu begrenzen, macht Kanban das eher auf der Ebene, was gleichzeitig bearbeitet werden darf. Und das ist letztendlich auch ein bisschen flexibel. Also da gibt es keine feste Regel. Aber im Team sollte man sich halt einig sein, wie viele Items gleichzeitig in Bearbeitung sein dürfen und was man macht, wenn diese Zahl überschritten wird. Und wie gesagt, es gibt auch keine fixen Rollen groß in Kanban, also es gibt jetzt niemanden, der irgendwelche Kanban Regeln versucht zu durchzusetzen, sondern das ist letztendlich ein Prozess, der vom gesamten Team einfach gelebt werden muss und hat deutlich weniger Regeln, sage ich mal als Scrum.

Alex: [00:13:38.31] Ja, ich würde sagen, so ein bisschen zu resümieren, dass die Aufgabe von Kanban um diese Kanban Board, die man dazu verwendet, ist, erst einmal die Arbeit transparent zu machen, die es zu tun gibt, die wir schon gemacht haben und der, die gerade in die Bearbeitung ist. Festzulegen, welche Grenzen wir setzen, sind sogenannte WIP, also WIP-Limit wird auch da festgehalten, transparent gemacht, damit wir diese „work in progress“ Limit nicht überschreiten. Also all diese Informationen und diese Arbeitsweise ist Kanban. Wie unterscheiden sich was sind für dich die wichtige Unterschiede zwischen Scrum und Kanban?

Matthias: [00:14:28.05] Also wie man vielleicht auch gerade schon aus der Beschreibung der beiden Methoden herausgehört hat, hat die eine eben diese diese zeitliche Komponente, so dass du im regelmäßigen Rhythmus immer wieder die gleichen Meetings und Austausch-Termine und Reviews und sowas hast, was halt für mich schon mal in die Richtung zeigt. Es ist eher geeignet, um ein Projekt umzusetzen, im Gegensatz zu Tagesgeschäft mit Bugfixing und Wartung im Allgemeinen. Weil ich halt letztendlich, wenn ich Features entwickel, kann ich mit Scrum das ganz gut steuern, dass zum Beispiel alle zwei Wochen alle Features, die entwickelt worden sind, veröffentlicht werden. Aber Bugs zum Beispiel kann ich halt ganz schwer einplanen, weil die kommen halt, wenn es auftauchen. Und die sind tatsächlich in einem klassischen Scrum-Prozess nur sehr schwer zu integrieren. Im Gegensatz dazu ist so halt in Kanban problemlos möglich. Deswegen für mich auch da wieder der Hauptunterschied: Dadurch, dass sich diese zeitliche Begrenzung nicht habt und eigentlich jederzeit durch Continuous Integration oder ähnliche Mechanismen direkt alles releasen kann, kann ich halt einen Bug oder Hotfix, der unmittelbar umgesetzt werden muss, auch unmittelbar releasen, was jetzt bei Scrum auch nicht unbedingt möglich sein wird. Und das wäre jetzt mal so der Hauptunterschied. Für mich jetzt zumindest. Und man hat halt in Kanban deutlich wenige Rollen, die man jetzt noch zusätzlich bräuchte. Also was, was ich zum Beispiel auch schon mal häufig gesehen habe, ist, dass sich ja vor allem kleinere Firmen, die Scrum machen, gerne mal den Scrum Master sparen. Und das macht halt dann irgendwie ein Entwickler oder sowas mit. Ganz schlechte Erfahrungen damit gemacht. Also das funktioniert überhaupt nicht gut in meinen Augen. Und wenn man Scrum machen will, dann muss man glaube ich wirklich den ganzen Weg gehen.

Alex: [00:16:44.69] Ich bin im Großen und Ganzen bei dir. Wie gesagt, Kanban hat viel weniger Personalien als Scrum in viel weniger Zeremonie als Scrum, in dem Sinne auch Rollen und Termine und so weiter. Ist in Kanban weniger ausgeprägt oder zumindest gibt es keine Pflicht-Termine sozusagen. In Anführungszeichen natürlich. Aber was für mich auch ein Unterschied ist, ist, dass Scrum ist ein Framework, ein Prozess, um die Entwicklung agiler zu gestalten. Und Kanban verfolgt für mich ein ganz anderes Ziel, nämlich das Prozesse, die jetzt schon da ist, zu verbessern. Also wir ersetzen nicht der Prozess, so wie wir es jetzt gemacht haben mit Scrum, – in Scrum Fall nehmen wir die Prozess, die wir hatten, machen wir weg und arbeiten wir jetzt mit Scrum, mit allen Prozessen und Definitionen und Paraphernalien, die Scrum vorschreibt oder vorstellt. Und in Kanban machen wir das nicht, sondern wir nehmen den Prozess so wie es jetzt ist, so wie wir gerade arbeiten. Und durch Transparenz, WIP Limit und all diese Themen versuchen wir diese Prozess zu optimieren, indem wir Bottlenecks feststellen usw. Da spielt auch sehr viel von der Theory of Constraints mit rein. Findest du das auch so?

Matthias: [00:18:15.35] Ja, also grundsätzlich ja, wie ich mir das halt wirklich so vorstell. Also angenommen, ich fange jetzt halt ein neues Projekt an mit einem mit einem Team, das gut eingespielt ist. Dann glaube ich, dann kann halt diese Projekt Umsetzung im Scrum Modus sehr gut funktionieren. Aber sobald das Produkt dann Feature komplett ist und das ganze im Prinzip in den Wartungs Modus übergeht, da würde ich halt im Prinzip so einen Shift hinzu Kanban eigentlich sehen, weil du halt dann ganz andere Anforderungen an dein Tagesgeschäft hast sozusagen. Dein Tagesgeschäft ist halt dann nicht mehr Feature Entwicklung oder zumindest nicht mehr voll, sondern du hast dann halt auch Teile irgendwie Bugfixes und Ähnliches wie vorhin erwähnt. Aber ja, grundsätzlich gebe ich dir scho recht. Also Kanban, kann man natürlich sehr gut nutzen, um einen bestehenden Prozess woanders hin zu entwickeln. Aber das kann halt eben zum Beispiel auch ein Scrum Prozess sein. Also ich kann auch eher von Scrum zu Kanban irgendwie migrieren, sozusagen. Oder vielleicht auch einfach von jetzt auf gleich umstellen. Das wird auf den Use Case ankommen. Aber ja, ich glaube so wirklich ein Software Projekt, das regelmäßig mit Kunden Feedback und sowas von 0 auf 100 prozent Feature Komplettheit entwickelt werden soll, ist Scrum eigentlich echt eine gut funktionierende Methode.

Alex: [00:19:43.28] Also du kannst nicht sagen, Scrum wäre immer besser als Kanban oder Kanban, wäre immer besser als Scrum.

Matthias: [00:19:48.95] Das würde ich überhaupt nicht sagen, tatsächlich.

Alex: [00:19:51.83] Des ist nicht gut für unsere: „Was ist die beste Methode?“

Matthias: [00:19:55.88] Ja mei, aber wir haben ja auch noch einen dritten Contender, sozusagen.

Alex: [00:20:01.79] Ja, na gut, wir. Na, da bin ich gespannt, was du da zu erzählen hast. Aber wie gesagt, also für mich ist die Philosophie, die ich hinter Scrum und hinter Kanban sind, einfach unterschiedlich. Und natürlich, du hast völlig recht, ich kann in die Lebensdauer eines Projekts unterschiedliche Methoden verwenden, mit Scrum anfangen für den Features und nach und nach eher in Richtung Kanban zu gehen. Es ist durchaus vorstellbar, wie du ganz gut gesagt hast. Die Anforderungen an wie ich arbeite, sind unterschiedlich in unterschiedliche Phasen. Ja genau. Aber gut, du wolltest noch einen dritten Spieler ins Feld bringen.

Matthias: [00:20:41.93] Ja, weil es gibt ja auch noch die Mischform, das sogenannte Scrumban und – Also ich habe tatsächlich bis vor kurzem gar nicht gewusst, dass es tatsächlich eine offizielle Form ist, sondern ich dachte, das wäre einfach nur, dass man das sagt, wenn jemand zwar Scrum macht, aber doch irgendwie Kanban Elemente verwendet. Aber es gibt tatsächlich diese Mischform. Die versucht eben das Beste aus beiden Welten ein bisschen zu vereinen. Also im Prinzip ist es ein Scrum Prozess, der um Kanban Methodiken erweitert wird, also zum Beispiel, dass eben zusätzlich zu der Workitem Beschränkung pro Sprint dann auch noch eine von gleichzeitiger Bearbeitung hinzukommt. So was halt eben Standard-Scrum Prozess jetzt net so vorgesehen ist, aber eben dann bei einem Scrumban problemlos möglich ist. Also ich habe auch in meiner – in meinem Leben schon so einige – Ja wie soll man sagen – Sonderformen gesehen. Weil wie ich ja gerade eben erzählt habe, finde ich das zum Beispiel jetzt für Bugs und Hotfix ist halt natürlich Kanban besser geeignet ist. Aber was machst du, wenn du halt eben nur ein Team hast, das in einem Projekt sowohl Features entwickelt als in einem anderen Projekt auch Hotfixes und Bugfixes machen muss? Wie geht man damit um? Und da habe ich schon die, also die kuriosesten Experimente mitgemacht, wo dann auf dem Sprint Board noch zusätzlich eine eine Fast Lane und sowas dann eingerichtet worden ist, wo dann unabhängig von irgendwelchen Sprint Planning noch Sachen reingezogen werden konnten. Und ja, aber das sind halt alles so verzweifelte Versuche und so was unter einen Hut zu bringen, die aber natürlich auch nur bedingt gut funktionieren. Das muss man natürlich ganz ehrlich zugeben. Aber das geht jetzt ein bisschen von Scrumban weg, weil Scrumban an sich es tatsächlich ein wirklich offizielles Framework System, wie man eben auch agil entwickeln kann.

Alex: [00:22:48.00] Und ist deiner Meinung nach besser als Scrum für sich alleine oder für sich allein?

Matthias: [00:22:52.89] Also wie gesagt, ich habe erst von dem offiziellen Modell vor paar Wochen erfahren und habe dann ein bisschen recherchiert. Und es scheint tatsächlich so zu sein, dass die meisten Teams, die Scrum machen, eigentlich sogar tatsächlich Scrumban betreiben, weil es einfach ein bisschen ist, es halt auch häufig Scrumban ist auch ein bisschen flexibler als Scrum letztendlich. Also das sind glaube ich ein paar Sachen mehr, mehr optional und also es ist gar nicht so unvorbereitet. Und letztendlich würde ich schon sagen, dass es auf jeden Fall Sinn macht, die zum Beispiel eben die WIPs, die man also die Arbeits teile, die man gleichzeitig bearbeitet, die auf jeden Fall zu begrenzen. Es macht total Sinn, egal ob man jetzt in Sprints arbeitet oder nicht.

Alex: [00:23:44.17] Okay, man muss auch dazu sagen, Scrum war sehr viele Jahre lang sehr kann man das nett formulieren

Matthias: [00:23:54.72] In aller Munde.

Alex: [00:23:56.17] Ja, na also Scrum hatte ganz bestimmte Regeln. Das war sehr streng in Bezug auf diese Regeln. Ja, das hat die Scrum Leute und Erfinder haben auch gesagt „Das alles musst du machen, ums Scrum zu machen“. Wenn du eine der Artefakte oder die diese Pflichttermine weglässt, dann machst du kein Scrum mehr, machst irgendwas anders. Das kann auch funktionieren. Aber dann ist es kein Scrum und das muss man sagen, das hat sich auch ein bisschen relativiert. Ok, es gab eine neue Auflage von Scrum, in den sie auch ein bisschen die Sachen anders behandeln.

Matthias: [00:24:39.71] Also letztendlich die das ist tatsächlich sehr nahe an Scrum auch dran, wie es in meinen Augen einfach ein bisschen entspannter alles, also nicht ganz so streng. Also es gibt die gleichen Rollen, es gibt letztendlich die gleichen Meetings, aber wie gesagt, man kann halt auch. Also in den klassischen Prozess kannst du jetzt auch nicht einfach neue Regeln einführen, also kannst du schon, aber dann machst du halt kein Scrum mehr und es ist ja auch okay. Das kann ja jeder machen wie er will. Da kommen wir glaube ich dann nachher auch noch dann zu, weil letztendlich braucht man eventuell keine der reinen Lehren. Es kann ja auch nur eine Option sein.

Alex: [00:25:21.39] Hm, ja. Wir werden uns jetzt mal kurz von diese unterschiedlichen Methoden verabschieden und uns auf das Thema Komplexität mal ein bisschen einschießen. Es gibt eine Theorie oder eine Framework, eine Katalogisierung, die uns hilft zu entscheiden oder die uns helfen kann zu entscheiden, welche Methode vielleicht besser passt. Abhängig davon, in welchem Stadium von einem Projekt ich bin oder so. Oder wie die Komplexität der Aufgaben, die ich zu erledigen habe, gerade ist. Eine von diese Frameworks ist „Ceynefin“ oder „Cynefin“, der sagt die Komplexität einer Aufgabe teilt sich in vier Komplexität-Graden sozusagen und – Eigentlich meinen die Macher von diesen Framework, dass die einfachste Aufgaben sind, sozusagen „obviously“. Es ist was einfach klar ist. Es ist eine sehr einfache Aufgabe. Es ist irgendwas, wo es gibt gewisse Standards, die wir verwenden können, um das zu lösen. Das heißt, wir müssen uns nicht groß den Kopf zerbrechen, wie ich das Problem zu lösen, sondern es gibt sogenannte Best Practices zum Beispiel. Dann gibt es eine zweite Kategorie von Aufgaben, die sind kompliziert. Kompliziert bedeutet, es ist nicht mehr trivial. Da gibt es schon gewisse Abhängigkeiten und Constraints, die wir berücksichtigen müssen. Es gibt keine vorgefertigte Lösung für das Problem, sondern muss man ein bisschen analysieren, wie das Problem ist, um die richtige Antwort, die richtige Implementierung mal herauszufinden. Die dritte Variante fällt im Bereich der sogenannten komplex. Aufgaben, die komplex sind. Sie ist eine Stufe über kompliziert und die Definition wäre, wenn eine Aufgabe komplex ist, kann ich nicht anhand von einer Analyse die richtige Antwort rausfinden, so dass die einzige Möglichkeit, die mir bleibt, ist, auszuprobieren, ob das, was ich mache, tatsächlich die Ergebnisse bringt, die ich erwarte.

Alex: [00:27:30.80] Ein bisschen try and error sozusagen, um es mal unschön auszudrücken. Aber einfach experimentieren. Ja, ich muss experimentieren, um herauszufinden, ob das, was ich mache, tatsächlich zu den Ergebnisse führt, die ich brauche. Und die vierte und letzte Variante wäre das Chaos. Der ist nichts mit lange darüber überlegen. Ich muss schnell reagieren, sonst ist meine Anwendung in ein chaotischen Zustand, die ich nicht haben will. Und deswegen ist hier – Ich muss einfach reagieren auf das, was gerade passiert. Meiner Meinung nach und auch der Meinung von viele andere Menschen bewegen wir uns in der Softwareentwicklung sehr oft im Bereich Komplex. Ja, die Aufgaben, die wir lösen wollen, sind komplex. Natürlich gibt es auch Aufgaben, die kompliziert sehen, auch sehr viele Aufgaben, die einfach ja, wofür wir Best Practices haben, wo es Patterns gibt, wo es schon alles geklärt ist, wie man so was machen kann. Aber größten Teil der Aufgaben ist meiner Meinung nach im komplexen Bereich und deswegen ja, es ist eher dieses emergente Praktiken, die uns beschäftigen, das ausprobieren, ob wir auf den richtigen Weg sind. Wir können bei manchen Bereichen wie gesagt auf Best Practices oder auf bewährte Methoden zugreifen, aber in vielen Fällen gibt es so etwas nicht und dann muss man es ausprobieren. Das ist ein ganz grobe, ganz, ganz grobe Übersicht, was diese „Cynefin“ Framework besagt. Und du könntest uns jetzt mal ein bisschen weiter erzählen und diese Stacey Matrix oder

Matthias: [00:29:10.83] Stacey Matrix

Alex: [00:29:13.46] Stacey Matrix erzählen.

Matthias: [00:29:15.32] Genau, weil die basiert letztendlich jetzt auf dem von dir vorgestellten Framework und versucht das jetzt noch ein bisschen noch ein bisschen auszubauen. Also man kann sich das wie eine vier Felder Matrix vorstellen und auf der x-Achse von diesen Graphen wird letztendlich die Technologie dargestellt. Von ist bekannt ganz links bis ist überhaupt nicht bekannt ganz rechts und die Requirements an das Projekt von ist bekannt bis ist noch überhaupt nichts klar ganz oben. Und die Teile, die du gerade eben beschrieben hast mit dem einfach kompliziert, komplex und chaotisch, die befinden sich letztendlich in diese vier Felder Matrix von links unten nach rechts oben mit, sind also einfach ganz links unten und chaotisch ganz rechts oben also. Soll heißen, wenn ich ein Projekt habe, wo von der Technologie her noch überhaupt nichts klar ist und auch die Requirements an das System noch überhaupt nicht klar sind, dann befinde ich mich definitiv im chaotischen Bereich für so ein Software Projekt – also da kann ich wirklich eigentlich noch gar nichts sagen. Habe ich im Gegensatz dazu jetzt aber ein Projekt vor mir, wo die Technologie, die ich einsetzen soll, mir vollkommen bekannt ist und die Requirements auch komplett klar sind. Es gibt überhaupt keine Fragen, dann befinde ich mich eben im einfachen Bereich und da dazwischen, da bewegen wir uns dann irgendwo in der Realität. Und da befinden sich dann eben der komplizierte und der komplexe Teil.

Matthias: [00:30:57.05] Und diese Stacey Matrix versucht eben Software Projekte kategorisierbar zu machen, dadurch. Und wenn man das auf sein Projekt anwendet und – ja – sich in diesem Graphen irgendwo platziert, dann soll eben, – soll man eben ganz gut sagen können, in welchem Fall man zu Kanban greifen soll bzw. zu Scrum. Und da ist es dann eben so, dass die Projekte, die dann eher im komplizierten Bereich sind, also trotzdem eher weit links und in dem Graphen angesiedelt, eher zu Kanban tendieren sollten und die Sachen, die weiter oben angesiedelt sind, also im komplexen Bereich, dann eher zu Scrum tendieren. Das ganze finde ich. Naja, ist halt schwer zu verallgemeinern, würde ich mal sagen. Also ich glaube nicht, dass diese Matrix zu 100 prozent immer die korrekte Antwort liefern wird, weil ich glaube, dass da noch ganz viele andere Bedingungen reinspielen werden. Und das alleine glaube ich, wird kaum reichen, um das einzuordnen. Aber ich find’s durchaus interessant, diese Darstellung sich tatsächlich mal vielleicht für ein Projekt, vor dem man steht, einfach mal zu machen und zu gucken, wo man da landet. Also so von der Selbsteinschätzung, weil man da vielleicht auch einfach so ein Gefühl dafür bekommt: Mit was habe ich es denn eigentlich da grade zu tun? Also mit was für nen Umfang Komplexitätsgrad?

Alex: [00:32:25.44] Okay, also anhand von wo wir unser Projekt oder unsere Aufgabe einsiedeln können in diese Stacey wMatrix können wir ja zumindest im Groben tendieren zu der ein oder andere Methode. Verstanden? Natürlich hast du recht, es ist nicht die einzige Wahrheit, das sind viele andere Faktoren. Also nicht nur welche Technologie und welche Anforderungen, sondern auch wie das Team ist. Wie ist die Arbeitspolitik im Unternehmen? Wie das Team zusammenarbeitet, wie sie miteinander umgehen können und so weiter. So, das fällt mit Sicherheit auch damit rein und ist für eine Entscheidung auch nicht irrelevant. Aber dies liefert zumindest ein erste Richtungswahl, in welche Richtung man sich bewegen könnte. Ja, finde ich gut. Finde ich interessant. Eine coole Sache.

Matthias: [00:33:19.60] Genau das war ja jetzt quasi die Theorie, wie man darauf kommen sollte, was man nutzen soll.

Alex: [00:33:25.93] Nichtsdestotrotz ich komme immer mehr mit dem Gefühl raus, es gibt keine beste.

Matthias: [00:33:31.39] Ja, das kann durchaus sein. Kann durchaus sein.

Alex: [00:33:37.30] Wir reden über die unterschiedliche Themen, um die wir uns entscheiden können, wenn wir eins oder der andere verwenden. Und nur das sagt mir schon. Es gibt nicht die Lösung. Es gibt nicht die beste Methode, um um agil zu arbeiten, sondern es ist wie immer als Consultant man so gerne sagt „it depends“. Es hängt davon ab, welche Art von Projekt wie schwierig oder einfach ist zu implementieren. Es hängt auch davon ab, wie gesagt, andere Faktoren, menschliche Faktoren, welche Thema ich oder welche Methode ich anwenden soll oder nicht soll. Also ein der Beste gibt es in meinen Augen gar nicht, kann es gar nicht geben.

Matthias: [00:34:16.69] Da gebe ich dir absolut recht. Also ich bin tatsächlich auch der Meinung, das Wichtigste an der ganzen agilen Softwareentwicklung ist eigentlich, dass das Team an einem Strang zieht, also agil arbeiten möchte und sich im Team auf einen gemeinsamen Ansatz einigt und dann allerdings eben regelmäßig schaut, ob man diesen Ansatz in irgendeiner Weise verbessern kann. Und da wird einem, glaube ich, am Ende des Tages kein Lehrbuch helfen, sondern es können tatsächlich eigentlich nur wirklich von der Iteration zu Iteration des Team für sich selbst entscheiden. Was könnte sich verändern, damit es in der nächsten Iteration besser läuft?

Alex: [00:35:01.48] Da bin ich auch total bei dir. Also ich finde Scrum oder Kanban oder diese Frameworks, die es gibt und die man verwenden kann, sind super. Sachen, die man auch verwenden kann, vor allem wenn man anfängt sich damit zu beschäftigen, sind diese Frameworks finde ich eine super Sache, weil die geben sehr viel Führung in dem Bereich dazu. Wie kann man die Sachen gut machen und ordentlich machen? Aber ich denke mit mit der Zeit und die Zeit sind nicht zwei Monate oder sechs Monate, sondern öfters mal mehrere Jahren. Funktionieren diese Systeme weiterhin verwendet sie weiter. Wenn du der Meinung bist, dass für dein Team oder für deine Arbeitsweise Änderungen helfen könnten, dann versuch’s einfach. Ich meine, man muss sich jetzt nicht darauf versteifen. Ich mach Scrum und fertig und mehr gibt es nicht. Man kann auch andere Sachen ausprobieren, wenn man es für richtig hält und dann kann man bewerten, da hat uns das geholfen. Hat uns das nicht geholfen? Wollen wir das weitermachen? Wollen wir das nicht weitermachen? Innerhalb des Teams, so dass sich die Geschichte entwickelt, der Prozess oder die Art und Weise oder das Framework, die wir verwenden, um zu entwickeln, sich mit der Zeit einfach verändern. Und wie ich gesagt habe, aber das ist nicht eine Sache, die man innerhalb von ein paar Monate beherrscht und schon anfangen kann, auszuprobieren, was man will, sondern es bedarf reichlich an Erfahrung, um dieses agiles Mindset, diese agile Arbeitsweise, sei es Kanban, sei es Scrum oder sei irgendwas anders, mal zu verinnerlichen. Der agile Methode, an sich rauszukommen und einen agilen, sogenannten agilen Mindset zu haben. Wenn du diese agile Vorgehensweise verinnerlicht hast, dann kannst du Sachen ausprobieren. Ich finde, das ist auch das Schöne an unserer, unser Job. Wir können so viel ausprobieren. Wir müssen immer was Neues lernen. Wir können immer was ausprobieren. Und wenn es besser passt als das, was wir haben, dann machen wir es weiter. Wo ich aber auch kein Freund bin, ist diese Aktionismus: Jaa, jetzt ist der neue Framework da. Jetzt muss man das auch unbedingt ausprobieren. So auch nicht.

Matthias: [00:37:16.06] Also es ist also der ganze agile Prozess, steht und fällt in meinen Augen eh mit dem Team. Also selbst wenn eine Organisation entscheidet irgendwie: Dieses Framework wird jetzt eingeführt. Wenn das für das Team nicht funktioniert, weil eben jetzt zum Beispiel das Modell nicht zu ihrer Arbeitsweise oder ihren Aufgaben passt, dann ist es zum Scheitern verurteilt und wenn man dann verhindert, dass sich so ein Prozess in die richtige Richtung entwickeln kann, nur weil es dann nicht mehr zum Beispiel Scrum heißt oder so. Dann finde ich, ist das halt wirklich falsch, weil das muss halt fürs Team einfach passen. Das Team muss in der Lage sein, gut arbeiten und gut abliefern zu können. Und welche Arbeitsweise, die das machen, sollte eigentlich egal sein. Aber was man halt aussagen muss, ist also wirklich Scrum und Kanban und auch Scrumban und auch Extreme Programming. Das sind alles Sachen, die deswegen nicht schlecht sind, sondern die haben alle ihre Daseinsberechtigung und können zumindest einen Einstieg sehr gut erleichtern.

Alex: [00:38:24.57] Zum Ende in zwei Sätze Matthias gibt es die beste agile Methode.

Matthias: [00:38:32.16] Also wenn, dann hat sie keinen Namen für mich. Also ich ordne mich tatsächlich in meiner täglichen Arbeitsweise in keine dieser Methoden ein und würde es tatsächlich eher als den evolutionären Ansatz beschreiben.

Alex: [00:38:48.72] Ich würde sagen, die beste agile Methode gibt es und es ist die Methode. Egal wie es heißt, egal ob ein Name hat oder nicht, die euch hilft, bessere Software zu liefern. Das ist für mich die beste agile Methode. Egal wie du sie nennen willst,

Matthias: [00:39:07.41] Ja, könn wir uns darauf einigen. Ja, und das war dann unser Abstecher in die agile Welt.

Alex: [00:39:14.43] Du hast heute einiges über Methoden wie Scrum, Kanban, XP erfahren

Matthias: [00:39:19.56] Und wenn dir die Folge gefallen hat und du es noch nicht getan hast, dann ist jetzt genau die richtige Gelegenheit, den Podcast zu abonnieren

Alex: [00:39:26.58] Und empfehle diese Folge deinen Teamkollegen, wenn du glaubst, dass ich euch helfen kann.

Matthias: [00:39:31.32] Und dann bis zum nächsten Mal bei der Macht der Craft.

Alex: [00:39:34.41] Ciao.

off: [00:39:37.32] Die Macht der Craft arbeitet für dich.