Ashley: Willkommen zur nächsten Ausgabe der Taktsoft Campus Podcast. Der Podcast ist Software Professionals. Mein Name ist Ashley Steele. Heute habe ich Nils Brettschneider bei mir. Nils ist Geschäftsführer der Taktsoft GmbH. Taktsoft entwickelt kundenspezifische Softwarelösung und die setzen ein sehr, sehr starken Fokus auf das Thema Agilität. Das Thema wollen wir heute mal diskutieren Scrum AS Framework und wie sich Scrum weiterentwickelt hat. Hi, Nils. Schön, wieder mit dir sprechen zu können. Wir haben beide, ich sag mal so, eine Vergangenheit mit Scrum. Wir kennen das ursprüngliche Scrum Guide 2010, kennen Schwabe und Jeff Sutherland und ich. Ich denke, ich sag mal so in unser beruflicher Leben, dass wir uns wirklich damit viel beschäftigt haben, auch mit deinen Unternehmen und die die Technologie, die Softwareentwicklung, die er gemacht haben. Jetzt kommt die spannende Punkt. Es gibt eine neue Scrum Guide 2020 Version. Ähm, ja. Lasst uns uns dazu ein bisschen ein bisschen drüber unterhalten. Ich sag mal so Was sind die wesentliche Veränderung und wo sind die Hauptmerkmale, wo, wo man so ein bisschen tiefer reinschauen? 
Nils: Sehr gern. 
Ashley: Oder? Ähm, ja. Was sind für dich dann die wesentliche Änderungen? 
Nils: Also die Änderung kann man ablesen. Alle im Einzelnen, auch die Änderung, die ich benennen würde, ist so ein bisschen der Punkt. Ein Scrum Team ist jetzt ein Team mit Betonung auf ein Es gibt nicht mehr die Unterscheidung in Es gibt das Scrum Team mit dem Scrum Master und dem Product Owner und dann als Teil noch mal als Supp Team, wenn man so will das Development Team, sondern es ist ein Scrum Team, das wird sehr betont. 
Ashley: Dann das ist so, das ist dann mehr das Wirgefühl. Ich denke, wir kommen auch in den anderen Themen zurück dazu. Das ist wirklich ein Einheit ist ein wir sind ein Team. 
Nils: Ja, und auch ganz praktische Dinge, die sich bei uns in Projekten oder in Konstellationen immer wieder ergeben haben. Wenn man schon dieses eine subteams hat vielleicht gibt es ja auch noch mehr subteams, vielleicht gibt es das Backend Team und das Frontend Team oder das Design Team. Und zu Fragen stellen sich hoffentlich weniger. Wenn man eben gesagt bekommt, es ist ein Scrum Team. Darin gibt es drei Rollen oder drei Verantwortlichkeiten Product Owner, Scrum, Master und Developers. So ist er definiert und mehr gibt es nicht. Es gibt nicht zwei Teams Sub Teams, Team A, B oder so, sondern es gibt ein Team. 
Ashley: Und letzten Endes müssen diese Themen zusammenarbeiten, um ein Produkt zu bauen. Egal ob das 20 % Backend, 80 % Frontend ist oder 10 % UX/UI.. Und genau dieses Thema Product Product Goal, das taucht auch in der neue Version des Guides auf. 
Nils: Genau das ist neu. Dieses Artefakt des Product Goals, das gab es bisher noch nicht. Und das finde ich auch eine ganz schöne Struktur reingekommen, indem man eben sagt Jedes dieser Artefakte Product Backlog, Sprint, Backlog. Und das Inkrement, das hat eine Entsprechung auf der Ebene des Commitments, nämlich das Produkt Backlog hat das Produkt Goal, das eben neu ist, das Sprint Backlog schon, das bekannte Sprint Goal und das Inkrement die Definition auf dann. Und diesen Dreiklang, dass der so hervorgehoben wurde und herausgearbeitet wurde, finde ich auch eine positive Änderung. 
Ashley: Und gibt es dann irgendwelche Änderungen im Sinne von Ich sage jetzt Verantwortung? Wir haben in der Vergangenheit immer über Self Organizing in Teams, selbstorganisierten Teams gesprochen. Gab es dazu Änderungen in der 20 20 Version? 
Nils: Ja die vielleicht gar nicht so sehr die Philosophie dahinter, aber auf jeden Fall die Formulierung. Statt von dem Self Organizing Team spricht man jetzt im Scrum Guide explizit vom Self Managing Team. Wie schon gesagt, ich glaube nicht, dass man damit was völlig anderes meint, aber man betont vielleicht noch mal, wie man es immer gemeint hat mit Self Organizing, nämlich dass man als Team Verantwortung übernimmt und ganzheitlicher Verantwortung übernimmt. Das ist auch ganz spannend, dass während der Scrum Guide an sich kürzer geworden ist, was ja ganz erstaunlich ist für ein Dokument, auf dem so. 
Ashley: Viele 19 auf 13 Seiten exakt. 
Nils: Sagen Ja. Also für etwas, worauf so viele Projekte beruhen und was so wichtig ist für viele Leute, dass man das kürzer machen kann und jetzt nichts an Bedeutung verliert. Das ist ja schon mal eine gute Sache. Aber ein Abschnitt ist länger geworden, nämlich der, der das Scrum Team beschreibt. Und da heißt es jetzt also explizit The Scrum Team. In der englischen Version ist Responsible for all product related activities from stakeholder collaboration, verifikation maintenance, operation experimental research and development and anything else that might be required. Also da kann man jetzt auch sagen, vielleicht ist ja das Scrum Team auch für das Recruitment von neuen Teammitgliedern verantwortlich. Das ist schon sehr ganzheitlich gedacht und ich glaube, das hat man jetzt betont und herausgearbeitet. 
Ashley: Das für mich ist eine der wesentliche Punkte, weil ich habe oft gemerkt in der Vergangenheit, dass der Fokus mehr auf das Thema Development war. Aber genau wie du sagst, du hast das Thema Deployment, du hast das Thema Operations. Man muss das wirklich als Produkt und ich sag mal so in die Prozesse, die dahinter sind, gesamtheitlich betrachten. Aber ohne das hat man nicht diesen Erfolg als als Produkt. Und das für mich ist auch eine wesentliche Veränderung, dass genau so thinking out of the box. Ich muss nicht nur etwas entwickeln, sondern ich muss auch die andere Komponenten, die dazu gehören, um wirklich ein Produkt auf den Markt zu zu bringen, berücksichtigen. Es ist, wie gesagt, für mich ein wirklichen, wesentliche Punkt. Ja. 
Nils: Absolut. Und da gibt es ja auch noch eine andere Seite dazu. Nämlich ich muss natürlich auch in die Lage versetzt werden. Es wird ja auch tatsächlich im Nehmen nicht impliziert, sondern explizit von Empowerment gesprochen. Also das Scrum Team muss eben von der Organisation auch in die Lage versetzt werden, die eigene Arbeit zu managen. Und dass das so explizit da hineingekommen ist, finde ich. Positiv aber ist natürlich auch ein eine starke Aussage. Das heißt, wenn man sich als Organisation jetzt an Scrum orientiert oder darauf beruft, dann wird man sich das natürlich auch entgegenhalten lassen müssen. 
Ashley: Und das geht auch so ein Punkt, etwas, was wir vorhin kurz besprochen hatten, das Thema Self Organizing, Self Management Management, Verantwortung auch durch ist immer so, die zwei Sachen passen für mich zusammen das mehr Gesamtverantwortung beim Team. Genau wie du sagt das nicht Development Team oder Design Team oder Back in Team aber mehr Verantwortung beim Team vorhanden sein muss. Wenn ich das so ausdrücken darf, ja, ich sage mal so, den ganzen Zyklus mal abzudecken. Es gibt auch Änderungen im Theme zum Thema Daily. Auch in den in den neuen Scrum Guide, die wir vorhin mal kurz uns drüber unterhalten hatten. Ja, wozu dazu? Ein bisschen was erzählen? 
Nils: Gern. Das erst mal vielleicht Auffälligste und Bemerkenswerteste ist, worüber sich auch viele Menschen freuen werden. Der Scrum Guide hatte immer drei Fragen beinhaltet, die man im Daily stellen kann, aber nicht muss und die laut eben Scrum Guide helfen können, so das Daily zu strukturieren. Das ist Was habe ich gestern getan? Was werde ich heute tun und welche Limits sehe ich? Und diese drei Fragen, die sind schlicht und einfach weggefallen und das wird sicherlich dem einen oder anderen gefallen, weil immer die Frage Warum muss ich denn diese drei Fragen stellen und beantworten? Und müssen daily so aussehen? Und die Antwort war eigentlich schon immer Nein, müssen sie nicht, weil es steht oder stand explizit vorher da. Hier ist ein Beispiel, wie man das Daily strukturieren kann. Also die drei Fragen waren immer nur ein Beispiel, wurden aber dann ganz gerne explizit aufgegriffen und manchmal etwas zu sklavisch vielleicht gesehen. Und dass das weggefallen ist, ist eine gute Sache. Stattdessen ist man da ein bisschen abstrakter geworden, und daran lässt sich auch so die allgemeine Philosophie ablesen, die hinter diesen Änderungen steckt, nämlich weniger deskriptiv zu sein, weniger explizite Vorgaben zu machen und mehr aus dem jeweiligen anwendungs kontext zu überlassen, wie man das konkret lebt. Was ich auch wieder eine gute sache. 
Ashley: Finde und das ist auch meine Erfahrung gewesen, weil ich wie gesagt nur diese drei, drei Fragen zu fragen und dann die Beantwortung, die die für die Die Antworten auf die drei Fragen zu bekommen hilft manchmal nicht, weil es gibt dann halt andere Themen, die man besprechen muss und und mehr einer ich sage mal so eine eine Art Diskussion zu fördern, indem daily ja, wann müssen wir diplo en gibt es irgendwelche Abhängigkeiten? Und nicht nur das habe ich getan, das werde ich tun und das in meinem Parlament. Und das passt dann auch wieder wiederum, wie ich das jetzt und dieses Thema Self Managing Ja, mein Management, Verantwortung, mehr Verantwortung, um mehr über das gesamte Produkt zu denken. Und das begrüße ich wirklich, weil ich habe das in manchen Projekten gesehen, wo ich sage mal so, Leute sagen nee, im Daily, du darfst nur die folgende drei Fragen stellen okay, das ist ja, das ist ja, es gibt eine Sprachverständnis, es gab bestimmten, ja, es gibt, es gab Teams, die das so Ja, nee, das kannst du nicht machen, das Scrum Master, du darfst nur die drei fragen und genau wie du sagst, er diese ein bisschen Lockerung oder dass das, dass man mehr Freiheit in Anführungsstrichen hat, so in daily Ma zu einem zu gestalten, in dem in dem Form, was gesund und gut ist für das Gesamtprojekt bzw das das das gesamte Produkt und andere Theme, was in dem neuen Guide angesprochen worden ist, dass das Thema Automation Requirements Requirements welche Veränderungen gab es da. 
Nils: Für ganz subtile erst mal wurde. Also es gibt viele Änderungen, die jetzt auf den ersten Blick nicht so erkenntlich sind wie dieses neue Product Goal oder das Wegfallen von solchen Abschnitten. Und einer davon ist, wie eben das Thema Raffinement aufgebaut und definiert wurde. Erst mal früher hieß es Product Backlog Raffinement ist The Act of Edding, Teil and order to items and the product backlog. Jetzt wird stattdessen gesagt Product backlog Revirement ist the act of breaking down and further defined product back into small more practice items. Und das ist schon ein Unterschied. Genau. Es ist einmal dieses Wort Limits weggefallen und das Herunterbrechen in eben kleinere Items mit. Präzision hervorgehoben worden. Und das wird noch ein bisschen konsequenter in dem weiteren Abschnitt an anderer Stelle angewendet. Früher hieß es da The Development team is responsible for all ask. Und jetzt heißt es The developers. Es gibt ja nicht mehr das Development Team. Deswegen The developers who will by doing the work responsible for the size, also für diesen Zuschnitt der Items. Und ich glaube, das ist auch wieder ganz intelligent, dass man an der Stelle das Gewicht ein bisschen weggenommen hat von von diesem Schätzen von solchen Items mehr fokussiert hat, dass es eben darum geht, diese Backlog items herunterzubrechen auf kleinere, handhabbare Einheiten. Und ich denke, da lässt sich ganz gut daran ablesen, dass die Idee von Flow da mehr im Vordergrund steht. Also nicht so sehr, wie man das schon eigentlich immer irgendwie gemacht hat oder wie man das erst mal intuitiv vielleicht macht. Ich habe eine große Aufgabe, also versuche ich irgendwie zu schätzen, wie viel Zeit brauche ich für diese große Aufgabe? Und dann erledige ich sie nur, um nachher festzustellen Das war jetzt zu wenig Zeit oder zu viel Zeit. Eher selten. Aber ich habe mich verschätzt. Und das Gegenmodell dazu Ich habe einfach einen kontinuierlichen Fluss, einen Flow, ein Wert Strom, den ich erzeuge und möglichst kleine Einheiten, die ich dadurch schicke. Und dann muss ich natürlich aus den großen Brocken diese kleinen Einheiten machen. Und dieses Produkt Backlog Raffinement ist da einfach ein sehr wichtiger Schritt. Merke ich auch immer wieder in der Praxis und in der Beratung und im Coaching von Teams. Ganz häufig sind Probleme deswegen da, weil man nicht kennt, genug Product Backlog Raffinement macht, das heißt vielleicht, sich zu wenig Zeit dafür nimmt oder es auch nicht genau genug macht, es eben zu oberflächlich macht. Und das wird hier auch noch mal betont. Aus meiner Sicht auch tatsächlich eine gute Sache. Eine Verbesserung. Besserer Fokus. 
Ashley: Und auch ja meine Erfahrung auch da, dass je mehr Zeit man im Impact Load Reformen reinsteckt, man gewinnt vielmehr hinterher, weil halt die Sachen dann wirklich klarer definiert oder beschrieben sind. Früher und dann, man spart Zeit hinterher, da gibt es keine böse Überraschung. Und für mich ist auch der eine wichtige Satz. The developers who will be doing, the the work. Das sind die Leute, die das genau die, die diese Arbeit dann machen. Und nicht jeder Entwickler in Team muss sich zu jedem Punkt, ich sag mal so seine Meinung bilden. Und es gibt dann natürlich die Leute, die haben mehr Fokus auf Front, die haben oder haben mehr Fokus auf iOS Entwicklung oder ein Android Entwicklung und andere Entwickler die mehr mehr Fokus auf Backend haben. Und man soll wirklich so die subject matter experts wirklich die Leute, die die diese tiefgehende Kenntnisse, die Expertise haben, das sollen die Leute, die diese, die diese Arbeit, dieses Switching machen, weil letzten Endes, das sind die Experten, die das dann hinterher umsetzen. Und ich glaube, das trägt auch eine Menge dazu bei, dass man so transparenter wird und so mehr Planungssicherheit da reinkommen kann. Ähm, das waren ich sag mal so, wir haben gesagt, von 19 auf 13 Seiten, das ist auch eine Leistung, dass das so ein Guide wirklich kleiner geworden ist. Wir haben wahrscheinlich aber nur den Spitze von Eisberg uns mal angeschaut und ich denke, wir könnten uns nochmal nochmal ne Stunde über diese Veränderungen machen. Aber würdest du dann sagen für dich gibt es irgendwelche andere Punkte, wo du sagst ja, wow, das war. Das war eine Überraschung, dass es diese diese Änderung gab. Oder sind das dann die Sachen, die die Themen, die wir angesprochen haben, mit dem GAU, mit dem One Team Daily so weiter. Sind das dann aber für dich dann wirklich die wesentliche Sachen, die die Veränderung, die wir in neuen Scrum Guide sehen? 
Nils: Wer also auf jeden Fall Überraschungen in dem Sinne nicht. Höchstens positiv überrascht, wie gut es gelungen ist, die Qualitäten, die der Scrum Guide schon immer hatte, irgendwie weiter zu verbessern und zu halten, nämlich dass er auf so wenig Raum so viel Weisheit kondensiert. Ich finde nicht, dass oder bzw. Gruppenarbeit ist ja schon so angelegt, dass man eben in auch anwenden muss, dass man die Aufgabe hat, eben die Lücken zu füllen, die er ganz bewusst lässt. Aber es ist häufig eine gute Idee, doch sehr genau zu überlegen, warum steht das da so? Und machen wir das tatsächlich schon so, wie es da steht? Und häufig ist das eine sehr gute Idee und das ist ja bei vielen Dokumenten oder Büchern so, die eine sehr hohe haben. Da kann man auch nach dem zweiten oder dritten Mal Lesen immer noch was rausziehen. Und so finde ich, geht es mir mit dem Scrum Guide eigentlich auch immer. Wenn man drin liest, dann wird man immer wieder angeregt und ja, man man kennt ihn jetzt meistens nicht auswendig oder kann zumindest beim Lesen immer wieder was Neues entdecken. Vielleicht noch so ein Detail, wieder beim beim Daily. Da wurde vorher gesagt, also nach diesen drei Sätzen oder nach den drei Fragen, die man beispielhaft nehmen könnte, die wir vorhin schon besprochen haben, stand früher im Scrum Guide The Development Team or Team members of Meteomedia after the day for die Teil Diskussions Auto adept are plan the rest of this sprints work. Und das wurde ersetzt durch The Daily Scrum is not the only time developers allow to adjust their plan they often mead through out the day vom teil diskussions about adaptive or re planning the rest of the sprints work. Und das ist ein wunderbares Beispiel für mich. Wieder gar nicht so offenkundig. Vielleicht erstmal subtil, würde man vielleicht auch tatsächlich sogar überlesen, weil es grob das Gleiche bedeutet, aber hier haben wir wieder dieses Es war vorher sehr etwas preisgibt. Nämlich wenn wir nach dem Daily noch Fragen geblieben sind, dann macht doch direkt ein Meeting nach dem Daily, weil das passiert oft. Das ist ja so die Formulierung ein bisschen. Und das könnte ja zu dem Umkehrschluss führen, dass ich das entweder sofort nach dem Daily mache oder gar nicht mehr. Und das habe ich eben schon gesehen, dass sozusagen auch das wieder missverstanden wurde. Und hier ist es dann noch mal eine Klarstellung Guck mal, im Daily kann man nicht alles klären, deswegen hat es auch eine 15 Minuten Time Box. Also das ist ja so eine, so eine Krankheit in Anführungszeichen, die manchmal Teams befällt. Ich habe plötzlich 45 Minuten Daily ist auch spannend, da Teams zu helfen, da so ein bisschen wieder rauszufinden. Und die 15 Minuten sind eben ganz bewusst aber auch deswegen unproblematisch, weil ich mich eben ja auch darüber hinaus zusammensetzen kann. Dann aber nicht unbedingt mit dem gesamten Team. Das ist das Spannende daran, sondern vielleicht in kleineren Runden und das noch so ein wenig klarer zu sagen Ich muss mich nicht direkt danach treffen, sondern es kann irgendwann am Tag passieren. Und im Grunde sage ich ja nur Ja, mach es doch so, wie es für dich passt. Also treffe ich dann und wie es notwendig ist in der Konstellation, wie es notwendig ist. Und das ist eigentlich genau das, was man erreichen will. Fast schon erstaunlich, dass man das erwachsenen Menschen sagen muss. Aber ja, das war vielleicht eine Verbesserung, die so ein bisschen subtiler ist. Hat mich positiv überrascht, weil ich über diese kleinen Formulierungen Unterschiede in solchen Coaching Situationen manchmal sehr detailliert sprechen musste. Deswegen hat mich das sehr gefreut. 
Ashley: Und das ist auch wiederum für mich. Ich wiederhole mich jetzt zum Thema Self Managing, dass wirklich ein Team sagt Okay, wie, wie packen wir das jetzt? Auf jeden Fall. Ja, und das ist ja, das ist wirklich und nicht so, ich sage mal so, mein ich habe mal meine Handschellen an, ich darf das nur so machen, aber genau so dieses dieses Freiheit ein bisschen zu forcieren, so ein Raum zu geben, dass das das ein Team dann sich wirklich so organisieren bzw managen kann um um die Sachen mal zu zu zu entwickeln und um das Produkt mal zu entwickeln. 
Nils: Freiheit geht halt nicht ohne Verantwortung. Das ist so der Punkt. Freiheit ohne Verantwortung funktioniert nicht und funktioniert nicht. Das betont es glaube ich in die richtige Richtung hier. 
Ashley: Nein, es war schön, ein bisschen reflektieren zu können. Ich sag mal so Wir sind beide mehrere Jahre in diesem Umfeld unterwegs und ich begrüße auch die, die die Veränderung und wie du auch sagt, es nicht. Also ein bisschen subtil, teilweise an bemerkenswerte Leistung. Dass das Gramm gut 13 Seiten lang ist, aber so viele Information beinhaltet. Das ist wirklich bemerkenswert. Ich denke, man, man kann, man kann nur empfehlen, es nicht einmal zu lesen, nicht zweimal zu lesen, sondern drei oder vier oder fünfmal zu lesen und dann wirklich zu reflektieren. Wie funktioniert das dann, wenn ich wirklich in so einem Projekt bin? 
Nils: Es lässt sich auch sehr schön mit Erfahrung kombinieren. Ich habe eine neue Situation und dann denke ich vielleicht, ich habe schon alles über Scrum gelernt, schaue in den Scrum Guide und nimm doch noch wieder etwas Neues mit. Das ist eine schöne Sache. Beantwortet nicht alles und hilft mir nicht immer. Aber es ist auf jeden Fall immer einen Blick wert. 
Ashley: Genau. Super, Nils. Vielen herzlichen Dank. Lass uns mal abwarten und gucken, wann die nächste Version des großen Gehalts rauskommt. Und ich denke genau, spätestens dann. Aber ich denke, wir können wirklich nur den Leuten empfehlen, dann die 20 20 Version mal anzuschauen und auch dann genau dieses Vergleich zu machen zwischen den alten und den neuen Versionen, um wirklich zu schauen, was, was hat sich da geändert? Nils Wen? Herzlichen Dank. Und ich sag dann bis zum nächsten Mal. 
Nils: Bis bald. 
Ashley: Jau, Taktsoft Campus Podcast. Der Podcast für Software und IT Professionals Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis Fragen zu Technologie, aber genauso Fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass ihr dabei wart. Euer Taktsoft Campus Podcast Team.