[00:00:12.600]
Harald Wild: Willkommen zum Agile Focal Point Podcast. Wir sind heute auf Reisen und sind zu Gast bei Felix Stein in Bonn. Willkommen. Schön, dass du hier bist Felix oder schön, dass ich hier sein darf, vielmehr. Du bist der geschäftsführender Gesellschafter der Agile Process GmbH und da stellt sich natürlich die Frage, was macht ihr denn so oder was ist eure Dienstleistung? Auch wenn dich natürlich viele kennen hier im Rheinland. Vielleicht geht das nicht für alle Zuhörer. Also vielleicht magst du dich und dein Unternehmen vorstellen.

[00:00:44.900]
Felix Stein: Natürlich, euer Podcast wird ja weltweit gehört. Von daher ist es sicher so, dass der der ein oder andere mich noch nicht zuordnen kann.

[00:00:52.200]
Ich und meine Firma, wir versuchen die große Welt ein kleines bisschen agiler zu machen. Das bedeutet, im weitesten Sinn sind wir eine Unternehmensberatung, die eben dabei hilft, in welcher Form auch immer, agile Frameworks, agile Praktiken oder Sonstiges einzuführen. Und wir versuchen, das auf den verschiedenen Ebenen gleichzeitig zu machen. Also nicht nur auf Team -Ebene, weil wir glauben, wenn man nicht andere Sachen mit einbezieht, wie Governance oder Budgetierung, dann wird das auf Team -Ebene nicht klappen. Das heißt, wir haben da unser Angebot versucht, auf alle Bereiche auszudehnen, die da möglich sind. 

[00:01:26.200]
Nicht immer kauft man uns alles gleichzeitig ab, aber das Angebot ist da. Das ist sehr spannend, weil... 

[00:01:34.300]
Ihr habt ja auch eine sehr große Expertise und ich meine, im Rheinland zumindest kennt man euch dafür und kennt mal auch dich dafür, da bist du glaube ich sehr bekannt, kennt man euch aber auch für Scrum. Das heißt, eure Expertise bei Scrum Teams, Einführung von Scrum, Weiterentwicklung von Scrum, auch so ein bisschen, wenn Scrum nicht so gut funktioniert im Unternehmen, was mache ich denn dann? Und auch dann holt man euch, soweit ich weiß. Und deswegen stellt sich natürlich die Frage, wenn jetzt ein Unternehmen sich überlegt, die Softwareentwicklung auf Scrum umzustellen oder sich weiterzuentwickeln in diese Richtung, was findest du denn wichtig, was man zu Beginn tun sollte oder auch vielleicht, was man sich vorher überlegen sollte? Wir versuchen ja immer hilfreich zu sein, genau in diesen Punkten für Unternehmen und die Lupe auch mal auf solche Themen zu halten, die vielleicht nicht immer im Fokus von Podcasts stehen. 

[00:02:29.400]
Also vielleicht eines vorweg, wir machen nicht nur Scrum, aber ich bin großer Fan von Scrum. Ich glaube es hat seinen Grund, dass sich das so durchgesetzt hat. Und das ist nicht nur, obwohl es mit Sicherheit ein Teil davon ist, dieser Kommerzialisierung durch Zertifizierung, sondern es funktioniert einfach an vielen Stellen, wenn es richtig umgesetzt wird, sehr gut und hilft auch. Und das bringt uns ja zu deiner Frage, was sollte man berücksichtigen bevor man das anfängt? 

[00:02:55.000]
Und ich glaube ganz wichtig ist an der Stelle, dass man sich bewusst sein muss, es braucht, damit Scrum so funktionieren kann, wie es soll, bestimmte Voraussetzungen. 

[00:03:06.300]
Und wenn die nicht da sind, kann man natürlich, während man es bereits einführt, noch daran arbeiten sie herzustellen. 

[00:03:12.800]
Aber mindestens das sollte man tun oder eben auch sagen okay, ich versuche es im voraus schon herzustellen denn das sind eben sachen die zwingend notwendig sind und dazu gehört was wirklich banales wie ist dieses team das nach scrum arbeiten soll wirklich cross funktional also kann es wirklich alle bereiche dessen abdecken die zur erzeugung des increments oder des produkts notwendig sind Und hat es auch wirklich ownership wir können vielleicht noch darauf eingehen was denn das heißt aber zumindest in einem gewissen ausmaß entscheidungsfrei raum und fungtlich nur als drittes häufig unterschätztes element ist hat es denn die notwendigen werkzeuge also das ist dann wieder zum teil sehr aktiv spezifisch und 

[00:03:58.600]
Aber auch da kann es wirklich mal es in banalste Sachen runterzubrechen ohne auf andere Leute angewiesen zu sein, selber dafür sorgen, in kürzester Zeit neu entwickelte Features zumindest auf einer produktionsnahe Umgebung, wenn nicht sogar direkt auf Produktion zu bekommen. Das ist ganz zentral. 

[00:04:18.200]
Du hast Ownership angesprochen, das ist natürlich ein sehr essenzieller Teil, denn ohne eigene Entscheidungsverwaltung wird es schwierig eigenverantwortlich zu arbeiten. Und das ist ja in Unternehmen, wie wir wissen, nicht zwangsläufig immer gegeben, gerade wenn es sich am Anfang befindet einer Scrum Implementierung oder Transformation, wie auch immer man es nennen will. Wie wichtig ist Ownership? Was heißt Ownership für dich in Scrum Teams und wie ausgeprägt muss diese sein, dass das Ganze auch wirklich zu kurz hat oder funktioniert? 

[00:04:47.400]
Also wichtig ist es auf jeden Fall, ich muss an der Stelle jetzt ein ein Geständnis ablegen. Ihr habt ja den Tim Klein im Podcast gehabt. Ich kann mich nicht mehr in Gänze an alles erinnern was er erzählt hat, selbst wenn ich die Folge natürlich gehört habe. Seid ihr da auch auf das Poem eingegangen, also auf seine oder beziehungsweise die von ihm und seinen Kollegen erstellte Variante von Ownership -Ausprägungen oder? 

[00:05:11.600]
Also tatsächlich nicht, ich glaube wir waren da ein bisschen in einer Kategorie unterwegs, aber umso besser, wenn du das... 

[00:05:17.400]
Also ohne es jetzt da ins zu tiefe Detail treiben zu wollen, kann man sich einfach Ownership als einen Punkt auf einer Skala vorstellen. Und das betrifft sowohl natürlich die Product Ownership als auch die Process Ownership als auch die Ownership über die eigenen Tools. 

[00:05:34.400]
und es ist nicht immer so, dass immer der Maximalwert, also ich darf über alles alleine bestimmen, das ausschließlich Beste ist, weil es natürlich auch da solche banalen Dinge gibt, wie sowohl Skaleneffekte als auch Kompatibilität mit anderen Teams. 

[00:05:49.900]
Aber zu schauen, dass es so weit wie möglich eben in die Richtung geht, möglichst viel selbst bestimmen zu dürfen, das ist extrem wichtig, denn wenn das nicht so ist, habe ich automatisch wieder Abhängigkeiten zu anderen Leuten, die entweder an meiner Stelle die Ownership über Prozess, Produkt, Tools oder was auch immer haben oder zumindest ein Mitspracherecht. Und selbst wenn die das gut meinen, bedeutet ja alleine der Punkt, dass ich sie immer einbeziehen muss und die nicht immer Zeit haben. Im Zweifel Verzögerungen, im Zweifel Missverständnispotenzial, im Zweifel einfache Diskussionsaufwände. Und je mehr ich davon habe, desto mehr hält mich das natürlich von der eigenen Arbeit ab, 

[00:06:31.800]
Und B sorgt es dafür, dass ich im Zweifel auch einfach warten muss, bis diese anderen Leute Zeit haben. Was dann auch wieder dafür sorgt, dass ich den Zielpunkt meiner Produktentwicklung, also das nächste Increment zum nächsten Sprintende, nicht so erreichen kann, wie ich das gerne möchte. 

[00:06:50.200]
Und da ist ownership natürlich total essentiell in dem Fall. Aber das ist ja auch das, was Unternehmen oftmals nicht so leicht fällt, es Zug zu gestehen oder vielleicht auch Führungskräften nicht so leicht fällt, dass man sich an gewissen Punkten zurückzunehmen und zu akzeptieren, dass man an gewissen Punkten in Scrum sich jetzt vielleicht nicht mehr einmischen darf und auch die Priorität nicht ändern darf. Was müssen denn aus deiner Sicht Unternehmen ändern, wenn sie sich in diese Richtung weiterentwickeln wollen oder wenn sie ihr Softwareentwicklungsteam in Richtung Scrum weiterentwickeln wollen? Was sind essenzielle Teile in Unternehmen, die sich ändern müssen, denn ein Scrum -Team ist ja nicht immer unabhängig von anderen Bereichen. 

[00:07:28.500]
Nur weil ich jetzt als einen Bereich mich weiterentwickle, bedeutet das ja nicht, dass automatisch das andere auch tun. Was ist im Unternehmen wichtig, um Scrum vernünftig in einen Wertestrom generieren zu lassen? 

[00:07:43.500]
Also vielleicht steckt da schon die Antwort mit drin, nämlich das Team, soweit es geht, von anderen unabhängig zu machen. Denn es ist ganz klar, je weniger das der Fall ist, desto mehr ist es ja zwangsweise nötig, dass ich diese Koordination habe, die dann auch zwangsweise übergreifend sein muss. Und umgekehrt, wenn ich es schaffe, diese Unabhängigkeit herzustellen, dann bin ich auf einmal in der Lage, ganz viel zu machen, was die anderen auch gar nicht beunruhigen muss. Und an der Stelle wird es dann natürlich wieder viel deutlich, weil es ja verschiedene Möglichkeiten gibt, für diese Unabhängigkeit zu sorgen. 

[00:08:16.900]
Also ich kann sagen, um mal banale und einfache Beispiele zu nehmen, ich mache wirklich mich sowohl technisch als auch fachlich von anderen Leuten vollkommen unabhängig. Also was ja häufig dann propagiert wird, ist was wie Microservices, wo ich dann sage, okay, das betrifft nur mich, das hat sogar eine eigene Datenbank, das ist separat entwickelbar, theoretisch sogar mit einer eigenen Programmiersprache und so weiter und so weiter, mit allem was da auch an Problemen möglicherweise dran hängen kann. 

[00:08:42.800]
Eine andere Möglichkeit, die aber genauso gut funktionieren kann, ist zu sagen, okay, es können gerne mehrere Teams auf demselben Code arbeiten, aber dann bitte so, dass es möglichst weniger Auswirkungen auf die anderen hat. 

[00:08:55.200]
Also im besten Fall kein Branch, der einen Tag überlebt, wenn dann überhaupt gebranched wird, im besten Fall durch eine hohe Testabdeckung, durch die ich sofort merke, ich habe da aus Versehen etwas anderes beeinflusst oder im schlimmsten Fall kaputt gemacht, was andere Leute 

[00:09:09.100]
mit gutem Grunde aufgebaut haben. Auch das ist hier eine Möglichkeit zu sagen, so können verschiedene Teams unabhängig von einer Arbeit. Und da gibt es auch nicht den einen Königsweg, aber das Ziel zu sagen, ich mache die Teams so unabhängig wie möglich voneinander, ist mit Sicherheit für Scrum eben eine ganz wesentliche Voraussetzung. 

[00:09:27.500]
Jetzt hast du schon so ein paar technische Dinge erwähnt und jetzt abgesehen von Autonomie ist vielleicht auch ein Unterschied, wenn es um Scrum geht, der Exzellenzanspruch, der dahinter steckt. Also das heißt, technische Exzellenz zu erreichen, der vielleicht in linearen Projekten nicht immer so im Vordergrund steht. Zumindest habe ich den Eindruck, wie wichtig ist technische Exzellenz in Scrum Teams oder in der Scrum Welt? 

[00:09:53.100]
Das ist jetzt der goldene Moment, wo ich endlich drauf ansagen kann, denn grundsätzlich ja, allerdings gibt es auch Rahmenbedingungen, in denen es anders ist. Ein Beispiel, das ich immer gerne nenne, einer der Autor des eigenen Manifests, Kent Beck, ist ja irgendwann zu Facebook gewechselt und hat mehr oder weniger gesagt, das hat ihn total beruflich verändert, denn er hat da herausgefunden, dass es Sinn machen kann, total Schrottigen Kohl zu produzieren, um schnell beim Endkunden zu sein, schnell Ergebnisse zu erzielen, schnell Annahmen zu validieren, um das dann nachher, wenn es validiert ist, zum Refekt dann richtig zu machen oder wenn es nicht validierbar ist, direkt wegzuschmeißen und nicht viel Zeit verschwendet zu haben. Das ist dann aber auch der ganz zentrale Punkt. Ich muss eben ein Unternehmen sein und eine Kultur haben, in der dieses, ich mache etwas erstmal schnell und irgendwie schmutzig ist. 

[00:10:48.800]
Und in der das zwangsweise dazu führt, dass das dann nachher auch wirklich sauber und nachträglich richtig gezogen wird Wenn ich das nicht habe und aus guten und schlechten gründen ist das ja in ganz vielen unternehmen so Das wenn einmal irgendwas auf produktion ist man nachher sagt ja näher stecken wir jetzt nicht noch mehr arbeit haben wir haben ganz viele Andere sachen jetzt viel drängender und wichtiger sind Dann würde ich sagen ist exzellenz möglichst früh möglichst wichtig Weil das hier ein punkt ist den ganz viele Entwicklungsteams oder nicht dann auf die harte tour lernen müssen wenn sie es nicht früh richtig machen bekommen sie nicht die chance Erspärtig richtig zu ziehen und dann tut denen das was sie so schnell und schmutzig auf produktion gebracht haben immer wieder ununterbrochen weh 

[00:11:34.300]
und führt auch dazu, dass ganz vieles hinten raus schwieriger, unverständlicher, komplizierter, langwieriger und fehleranfälliger wird, was dann ja wieder ganz viele Probleme nach sich zieht. 

[00:11:45.300]
Also im Sinne von entweder die Qualität von vornherein drauf zu haben und in den Vordergrund zu stellen oder sich der technischen Schuld bewusst zu sein, die man aufbaut, um sie nicht unter den Teppich zu kehren, wie das so häufig passiert. Weil manchmal fragt man sich ja, wie unbequem muss es sein permanent über diese Beule unter dem Teppich zu laufen, anstatt sie einfach mal zu beseitigen. Aber das ist tatsächlich, glaube ich, in Unternehmen eine Problematik, wenn es mal produktiv läuft, dann ist die Wartbarkeit und die technische Schuld, die man aufgebaut hat, irgendwo im Hintergrund, weil dann ist ja schon das nächste Feature, das wir wieder rausbringen und... 

[00:12:20.600]
Deliveren muss. 

[00:12:22.100]
Ja und so tragisch das ist, also um bei diesem Bild zu bleiben, in ganz vielen Kontexten, die ich gesehen habe, wurde auch erst angefangen an diese Beule unter den Teppich dran zu gehen, wenn sie so groß war, dass man nicht mehr durch die Wohnzimmertür kommen konnte. Und dann ist es ja definitiv zu spät. 

[00:12:38.200]
Dann ist es definitiv zu spät. Wenn man das jetzt mal noch ein bisschen genauer betrachtet, dann haben wir jetzt schon so ein bisschen die die Linie gestreift. Was gibt es denn so an Do's and Don'ts, wenn man jetzt Scrum einführt oder auch einfach nach Scrum entwickelt? Du hast ja ganz viel Erfahrung in dem Bereich. Du hast ganz viele Unternehmen gesehen, noch mehr Scrum -Teams gesehen. Du warst in Konzernen, du warst im Mittelstand, du warst bei kleinen Unternehmen und hast damit eine riesige Expertise, wenn es um Do's and Don'ts geht. 

[00:13:08.400]
Und das ja auch mal auf dem Zeitstrahl gelegt bei Unternehmen, die gerade starten, bei Unternehmen, die schon lange dabei sind und definitiv auch bei Unternehmen, die schon lange dabei sind und gemerkt haben, dass sie ihr Scrum irgendwie kaputt gemacht haben. Was sind die Do's und Don'ts, die du erlebt hast, und wo würdest du sagen, das ist wichtig oder das sollte man besser lassen? 

[00:13:30.300]
Also ein bisschen anschließend an das, was wir gerade gesagt haben, ein Du wäre definitiv bei der Frage der Softwarequalität oder des Aufwands, die in diese Qualität reinfließt, sehr stark auf die Entwickler zu hören. Denn in den meisten Fällen haben die es ja im eigenen Interesse, dass der Code, an dem sie arbeiten, in einem vernünftigen Zustand ist und einfach und sicher erweiterbar und veränderbar ist, 

[00:13:57.700]
Und in den seltensten Fällen habe ich welche erlebt, die von sich aus gesagt haben, wir machen da jetzt unnötig komplizierte Prozesse drauf. In dem Moment, wo ich außerdem noch sage, okay, ich bringe einen Arbeitsmodus darein, indem sie untereinander auch gegenseitig auf ihre Arbeitsergebnisse schauen, sei es durch Code Reviews, Pair Programming oder was auch immer, kann man sogar noch einigermaßen sicher sein, dass dann die legendäre Doktorarbeit in Code vermieden wird. Das bedeutet auch da hat man ganz gute Korrektive drin und der einzige Punkt, der dann eben aus Unternehmenssicht so einen kleinen Sprung in den Glauben erfordert, ist zu sagen, okay, ich lasse die das machen und vertraue darauf, dass da was Vernünftiges rauskommen wird. 

[00:14:38.800]
Was ebenfalls hier gerade schon angesprochen worden ist, dieses Zulassen der Ownership und vor allem das Schaffen von Voraussetzungen für Ownership. Ja, also tatsächlich gucken kriege ich. 

[00:14:49.400]
nicht nur meine Technologie, sondern auch meine Fachlichkeit so voneinander entkoppelt, dass ich wirklich einen Product Owner draufsetzen kann, der für ein Team oder, was den Scrum ja durchaus möglich ist, für zwei oder drei Teams mit einem Product Backlog einen Endkunden Mehrwert alleine verantwortet. Und damit würden wir zum nächsten Punkt kommen, nämlich gucken, wen setze ich da drauf. Und ich glaube, vermutlich in der nachhaltigen Auswirkung dürfte das dann sogar einer der wirklich schwerwiegenden Punkte sein, eine etwas, wie soll man das nennen, unbedachte Rollenbesetzung. Also ganz häufig werden ja Scrum Teams auf der untersten Erarchie verortet und in dem Moment, wo ich die Leute in diesem Team, also den Product Owner, auch den Scrum Master, ebenfalls auf dieser unteren Ebene verorte. 

[00:15:36.600]
und sie dann mit verhältnismäßig junioren Leuten besetze, dann würde ich sagen, wäre es auch unfair von denen, die Leistungserwarten, die ich sonst von einem Senior erwarten würde, den ich aber eigentlich für diese Position brauche. Zu sagen, okay, als nächster Punkt, ich setze da wirklich Leute drauf, die bestimmte Erfahrungen haben, die nicht zwingenderweise in diesen Rollen einen ruflichen Hintergrund haben. Das kann ja auch ein anderer sein. Also jemand, der jahrelang ein guter Projektmanager gewesen ist, kann guter Scrum Master sein, jemand, der jahrelang gutes, klassisches Produktmanagement gemacht hat, kann ein guter Product Owner sein. Aber das, was man leider immer wieder sieht, dass das so als Einstiegsposition gesehen wird, im schlimmsten Fall sogar noch als Teilzeitstelle. 

[00:16:20.400]
Das ist mit Sicherheit einer der größeren Fehler, die man machen kann, umgesetzt zu sagen, ich sehe das als Schlüsselposition meines Unternehmens und setze da Leute drauf, denen ich auch glaube, Schlüsselposition anvertrauen zu können. Das wäre dann wieder ein Do, also etwas, was auf jeden Fall jedem Unternehmen anzuraten wäre. 

[00:16:40.600]
Was ich sehr spannend finde, ist deine Aussage zu den Scrum Master und Product Donan, denn das ist ja tatsächlich so, dass die oftmals sehr unigotik besetzt werden. Vielleicht ja auch aus dem Grund, weil die Verfügbarkeit endlich ist. Man kriegt ja nicht unendlich viele Scrum Master, die jahrelange Erfahrungen haben und die man sich vielleicht dann noch leisten kann oder will, genauso ist es bei Product Donan. Auf der anderen Seite ist es natürlich ganz klar, ein Product Owner, der wirklich Ownership haben soll, ist einer, der Entscheidungen über das Produkt trifft. Und damit sind wir wieder bei einem strategischen Asset des Unternehmens, 

[00:17:13.400]
Das Produkt, das ich da entwickle, ist ja am Ende mein Lebenspfad als Unternehmen, mein Produkt, das ich verkaufe, mit dem ich meinen Umsatz generiere. Und deshalb ist es ja umso wichtiger, dass man genau diese Positionen auch mit Menschen besetzt, die entsprechend agieren können. 

[00:17:32.500]
Denn es erfordert ja Mut, auch Menschen zu sagen, das Feature bekommst du jetzt nicht. Oder diesen Teil der Software sollten wir vielleicht eher einstellen als weiterentwickeln. 

[00:17:44.500]
Und diesen Mut oder auch dieses Standing zu haben im Unternehmen, das ist ja auch nicht so ganz einfach, weil das muss ja auch zugelassen werden. Es muss zugelassen werden und es muss sich auch über die Zeit entwickeln. 

[00:17:56.500]
Und da kommen wir an einen Punkt, den wir kurz in unserem Vorgespräch auch angesprochen haben, der auch wunderbar in diese Do's und Don'ts reinpasst, nämlich dafür zu sorgen, dass ich den Leuten in diesen Positionen, und da würde ich jetzt auch alle drei Rollen in einem Scrum -Team nehmen, dass ich denen eine Entwicklungsperspektive gebe. Denn das, was ich immer wieder gesehen habe, ist, dass diese Rollen entweder überhaupt keine nächste Karriere -Stufe haben oder nur eine einzige. 

[00:18:24.400]
Die eine einzige ist dann hoffentlich Scrum Master zum Agile Coach oder Product Owner zum Safe -artigen Product Manager. 

[00:18:32.400]
Und wenn man danach weitermachen will, muss man da raus und zum Senior Project Manager oder zum Portfolio Manager oder was auch immer werden. 

[00:18:40.600]
Und da muss ich mich ja nicht wundern, wenn die Leute weg sind und ich mit Neuen von vorne anfangen muss, die wieder Junior sind. Wenn ich auf der anderen Seite sage, okay, ich biete da eben eine Karriere innerhalb dieser Rolle, wie auch immer die aussehen mag. Horizontal, also ich werde zu einem immer besseren Scrum Master, Product Owner oder Scrum Entwickler oder auch vertikal im Rahmen von den an Scrum angelehnten Skalierungs -Frameworks, also Nexus, LESS oder Scrum at Scale, dann kann ich ja über die Zeit dafür sorgen, dass ich selbst, wenn ich auf dem Markt gerade keine Leute bekomme, denn der Fachkräftemangel ist ja real, sie trotzdem aus den eigenen Leuten daraus entwickeln kann. Und damit tue ich mir eigentlich selber einen Gefallen. 

[00:19:20.600]
Das finde ich auch sehr spannend, weil oftmals muss man ja auch diesen Unterschied auflösen, dass Menschen sich im Unternehmen bewerben, eigentlich in einem agilen Umfeld arbeiten wollen, aber trotzdem eine Führungsposition. Und das geht ja manchmal nicht so richtig aus, wenn man sich in so einem Umfeld befindet. Deswegen finde ich den Ansatz sehr spannend zu sagen, naja, da muss ich halt... 

[00:19:38.900]
in der linearen Entwicklung dafür sorgen, dass Menschen eine Entwicklungsperspektive haben, die ähnlich viel Sinn stiftet oder die ähnlich Weiterentwicklung bietet, wie sie im klassischen Sinne die Hierarchie geboten hat. Wenn jemand gut ist, Führung zu vermitteln oder auch Leadership zu machen im Unternehmen, dann ist das ja durchaus auch etwas, was man in einer linearen Welt oder Weiterentwicklung bieten kann, ohne dass man vertikal in der Hierarchie weiterskalieren muss oder weitergehen muss. Deswegen finde ich das einen sehr interessanten Ansatz und ich glaube auch, dass man gut daran tut, Leute da zu halten, weil was passiert, wenn man diese Perspektiven nicht bietet und damit ja auch oftmals keine finanzielle Weiterentwicklung ermöglicht. Die Leute sind irgendwann weg und man hat die mühsam ausgebildeten oder rekrutierten Menschen im Unternehmen verloren. 

[00:20:29.200]
sowohl auf einer finanziellen Ebene als auch auf einer Wissensebene bereist das die Löcher, die man eigentlich gar nicht brauchen kann und deswegen finde ich das eine sehr interessante Geschichte. Was wären denn klassische Weiterentwicklungsrollen, die jemand ohne jetzt in eine lineare Welt wechseln zu müssen oder in eine Hierarchie wechseln zu müssen? Was wären denn so die nächsten Schritte für jemanden, der jetzt irgendwo als Scrum Master angefangen hat oder als Product Owner? 

[00:20:54.100]
Auch da wieder, es kommt natürlich drauf an, aber Möglichkeiten, wenn ich eher Richtung horizontaler Karriere gehen will, könnten einfach sein, dass ich in verschiedenen Bereichen nacheinander die Chance bekomme, mich da zu beweisen. Relativ schlichtes Beispiel, ich habe in den letzten Jahren viel in den Schnittstellenbereichen Hardware Software gearbeitet und einfach mal zu sagen, ok, du warst jetzt, ich weiß es nicht, von mir aus 5 Jahre lang in einem Software -Temps Scrum Master, jetzt beweise dich gerne mal die nächsten Jahre in einem Hardware -Temps Scrum Master, denn auch das gibt es hier. 

[00:21:27.400]
Ja, ähnlich kann ich natürlich sagen, okay, ich habe möglicherweise Embedded Software oder Cloud Software. Ich habe irgendwelche großen Enterprise Anwendungen oder vielleicht irgendwo, was ja nochmal eine ganz andere Geschichte ist, Mobile App Anwendung, wo ich ja völlig andere Dinge tun kann, viel näher am Kunden bin, A -B -Test machen kann und so weiter. Und auf diese Art und Weise kann ich dann immer mehr Expertise bei die Zeit gewinnen. Ich kann natürlich aber auch sagen, okay, geh mal in bestimmte Spezialisierung ran und da ist Skalierung eine von vielen möglichen. 

[00:21:59.200]
Da kann aber natürlich auch der gesamte Bereich kommen, der zur Scrum Master Rolle ja wirklich dazu gehört, aber ganz häufig ignoriert wird, nämlich alles, was mit Unternehmensentwicklung zu tun hat. 

[00:22:10.600]
Das heißt, was auch immer das im Einzelfall bedeutet, das kann bedeuten Großgruppenmoderation, das kann bedeuten, ich baue Expertise im Bereich Business Agility auf. 

[00:22:19.200]
Das kann bedeuten, ich kümmere mich überhaupt mal darum, was bedeutet denn Agilität für eine Nicht -IT -Abteilung? Brauchen wir das überhaupt? 

[00:22:26.600]
Wenn ja, wo? Kann ich denen dann dabei helfen? Denn natürlich gibt es immer wieder Fälle, wo das auch da Sinn machen kann. 

[00:22:34.100]
Ich kann mich beispielsweise an Versuche erinnern, Scrum -artige Konstruktionen im Kunden -Service oder im Change -Management einzusetzen, was dort, wo ich das gesehen habe, tatsächlich viel geholfen hat. Und auch dazu sagen, ich entwickle mich in die Richtung, kann ja durchaus etwas sagen, wo ich sage, das ist ein Schritt über das hinaus, was ich bisher in einem reinen Software -Entwicklungsteam gemacht habe und was ich auch durchaus als Karriere -Stufe sehen würde. 

[00:22:59.900]
Und das kann ja auch bedeuten, wenn man die angreizenden Bereiche mit Agilität beglückt, das kann ja auch bedeuten, dass das durchaus positive Auswirkungen für das Scrum Team hat, weil das Verständnis besser wird, weil die Zusammenarbeit vielleicht auch besser wird, weil nicht das Scrum Team immer diejenigen sind, die sich in die Schnittstelle einfügen müssen, weil sie die Flexibleren sind augenscheinlich. Das kann ja durchaus ein Punkt sein. Was glaube ich auch noch eine Möglichkeit wäre, und da wird mich deine Meinung dazu interessieren, ist ja auch, wenn man es von einer Unternehmenssicht betrachtet, gibt es ja durchaus Produktteile oder auch Teile einer Software, die viel mehr Umsatz machen, die viel mehr Gewinn generieren, die für das Unternehmen viel wichtiger sind. Und die würde ich ja jetzt vordergründig auch mit Menschen besetzen, wo ich sage, das ist jemand, der 

[00:23:44.200]
diese Verantwortung tragen kann und diese Verantwortung auch entsprechend den Unternehmen umsetzen kann und das wäre auch eine Weiterentwicklungsmöglichkeit, dass man sagt, warum soll nicht jemand da rein wachsen in so eine Rolle, wo er einfach in der Wichtigkeit für auch den Umsatz des Unternehmens andere Produkte übernimmt. 

[00:24:03.200]
Genau das. Also zum Beispiel der Hauptumsatzbringer, den ja ganz viele Unternehmen haben, aber zum Beispiel auch so die große Wette auf die Zukunft, denn man sagt ja beispielsweise, dass, ich weiß nicht ob man das Produkt nennen kann, aber dass IT -Produkte wie Android oder der Facebook -Messenger am Anfang von einem einzigen Team in der Größe eines Prometeams entwickelt worden sind. 

[00:24:26.600]
Und beides war ja eine derartige Wette auf die Zukunft, dass ich mal unterstelle, dass die dahinterstehenden Unternehmen schon jemanden drauf gesetzt haben werden, von dem sie gesagt haben, okay, der hat schon einiges geleistet und dem vertrauen wird, dass er auch da vieles leisten wird. 

[00:24:41.500]
Das finde ich eine sehr spannende Diskussion, weil ich glaube, dass sie zu selten geführt wird. Diese Weiterentwicklungsmöglichkeiten und die Perspektive, weil das hat ja auch damit zu tun, inwieweit schaffe ich es nachhaltig, das Wissen im Unternehmen zu halten. Denn wir hatten das ja auch schon mal in einer Folge für, dass so eine Veränderung irgendwie, also die Veränderung selbst irgendwann das strategische Asset im Unternehmen wird, weil sie so relevant wird für die weitere Lieferung des Unternehmens, für die Dienstleistung des Unternehmens, dass es wichtig ist. 

[00:25:12.700]
das Wissen, das man aufgebaut hat, nachhaltig zu fahren kann und gerade auch die Personen, die in der Lage sind, meine wichtigsten Produkte und meine wichtigsten Dienstleistungen so umzusetzen, dass sie genau den Wertestrom erzeugen, den ich mir wünsche, auch wirklich im Unternehmen zu halten und entsprechend so weiterzuentwickeln. Und das ist, glaube ich, eine sehr wichtige Geschichte. Jetzt gibt es aber noch mehr Herausforderungen bei Unternehmen. Also das heißt, nicht nur das, dass ich Leute habe, die mir helfen, bei Scrum weiterzukommen oder Scrum entsprechend auch wertvoll einzusetzen, da gibt es ja noch die Herausforderung der Kundenzentrierung. 

[00:25:52.100]
Und die ist ja mal nicht faltig. Also entweder ich habe ein Problem, dran zu kommen oder ich habe ein Problem, entsprechend die zu integrieren. 

[00:25:59.200]
Aber ich muss ja als Unternehmen auch erst mal in der Lage sein, so flexibel auf diese Rückmeldung, die ich von Kunden bekomme, zu reagieren, um diesen Wert, den ich da bekomme, überhaupt mal zu integrieren in meinen eigenen Prozess und so dann umzubringen. 

[00:26:12.700]
dass das auch wirklich was ergibt, was der Kunde dann zu schätzen weiß und dann auch so schnell zu sein, dass es schnell genug am Markt ist, um damit auch effektiv zu sein in meinem Umsatz und in meinem Produkt. Wie siehst du das, wie essenziell ist die Kundenzentrierung und welche Probleme oder Herausforderungen haben Unternehmen damit? 

[00:26:35.800]
Also essenziell ist sie auf jeden Fall und ich glaube vom Anspruch her war das ja nie anders. Also ich kann mich kaum entsinnen, dass irgendjemand mal gesagt hat Kunden sind mir alle total egal. Also es gibt mit Sicherheit irgendwelche Leute, die mal Sachzwänge genannt haben, wie Henry Ford der seinerzeit mal gesagt hat, ok meine Autos sind halt alle schwarz, weil alles andere wäre geradezu aufwendig. 

[00:26:59.500]
Aber vom Anspruch her, glaube ich, ist die Konzentrierung immer da. Das Problem ist natürlich, je größer und je langfristiger in den Planungen und sonstigen Vorgängen ich bin, desto schwieriger ist es mir auf Änderungen der Kundenwünsche einzugehen. Und da hat natürlich ein Ansatz wie Scrum ganz massive Vorteile, wenn ich eben den jeweiligen Einheiten, also den Scrum Teams, es zulasse A, überhaupt mal den Kontakt zu den Kunden zu haben und B dann darauf einzugehen. Wie das dann aussieht, ist im Einzelfall natürlich extrem unterschiedlich. Also am allerbesten ist es sicherlich, wenn ich eine, sagen wir es mal, überschaubare Größe von Kunden habe, mit denen ich wirklich interagieren kann. 

[00:27:42.200]
Also in vielen großen Unternehmen gibt es ja interne Anwendungsentwicklung und das ist mit Sicherheit ideal. 

[00:27:48.200]
Ja, da komme ich dann in so Konzepte rein, wie wir den On -Site -Customer, mit dem man auch noch Extreme Programming kennt, der auch wirklich zeitweise beim Team sitzen kann. 

[00:27:57.300]
Aber es geht natürlich auch anders, denn wenn ich Produkte habe, die nur einen sehr mittelbaren Kundenkontakt haben, also irgendeine Web -Anwendung, wo ich ja nicht genau mit den Menschen reden kann, der irgendwo sich die App runterlädt oder das beim Browser aufruft, da kann ich das über den Umweg machen, zum Beispiel über AB -Tests, zum Beispiel über Absprungraten, die ich messen kann. Das heißt, ich spreche da nicht mehr direkt mit dem Kunden, aber ich sehe natürlich, wie er sich auf meiner Website verhält und kann dieses Verhalten zum Anlass nehmen, mein Angebot für ihn anzupassen. Und an der Stelle kommt dann ja die Product Honor -Rolle auch so ein bisschen in diese Idee rein, dass er derjenige sein kann, der stellvertretend für den Kunden spricht, der eben aus ganz vielen verschiedenen Gründen möglicherweise gerade nicht greifbar ist. 

[00:28:48.900]
Und das im besten Fall dann, wie gerade genannt, mit irgendeinem datengetriebenen Hintergrund extrem wichtig. 

[00:28:56.200]
Umgekehrt ist es aber natürlich auch so und auch da kommen wir wieder zu den spannenden Aspekten, der der Product Honor Rolle, dass eben das Nein sagen auch ganz stark dazugehört, denn wenn ich auf alle wünsche aller Kunden eingehe, habe ich natürlich auch ein Problem. Also ich habe das mal bei mittelständischen Kunden von uns gesehen, der im B2B -Bereich glaube fünf oder sechs große Kunden hatte und jeder von denen durfte sich alles wünschen, was er wollte. Das bedeutet, die hatten am Ende Anzahl der Kunden ist gleich Anzahl der Entwicklungsbranches, die untereinander nur noch schwer kompatibel waren, was sie natürlich in irrsinnige Entwicklungsaufwändereien gestürzt hat. 

[00:29:31.500]
Das heißt, 

[00:29:32.700]
Das ist dann in diesem Extrem auch wieder schlecht. Um diese Balance zu finden, zu sagen, auf der einen Seite möglichst viel, den Kunden von dem zu geben, was sie haben wollen, idealerweise für sie auch Bereitsinn zu bezahlen, aber umgekehrt zu gucken, dass das eben nicht auf Kosten der internen Weiterentwickelbarkeit geht. Das ist für die Integratwahl eine ganz wichtiges. 

[00:29:55.000]
Und es kommt ja auch viel darauf an, wie wird Scrum denn im Unternehmen integriert oder in die vorhandenen Prozesse integriert. Und jetzt sind ja im Scrum Guide viele Regeln dazu aufgeführt bzw. auch mittlerweile in wahrscheinlich hunderten Büchern beschrieben. 

[00:30:14.300]
Wie strikt siehst du denn die Einhaltung dieser Regeln? Bist du eher ein Verfechter davon, dass du sagst, es ist wichtig, dass es im Unternehmen funktioniert und deswegen sind die harten Regeln, die es vielleicht gibt oder die auch Leute beschreiben, wichtig oder sind sie nicht so wichtig? Bist du bei deiner Scrum Weiterentwicklung eher so, dass du sagst, man passt es an das Unternehmen an, dass es passt oder man sollte sich tatsächlich an die Scrum -Regeln halten, denn sonst ist es kein Scrum mehr und dann funktioniert es auch nicht? 

[00:30:48.500]
Ich würde sagen beides. Also auf der einen Seite macht es natürlich keinen Sinn, dramatisch halt irgendwas festzuhalten, was nicht den Bedürfnissen im Unternehmen entspricht. Und da haben wir schon alles mögliche gesehen, von zu kleinen Teams über zu große Teams über Teams mit mehr als einem Product Owner, weiß weiß ich alles. Wenn das hilft, 

[00:31:09.200]
Und das eben als voraussetzung wenn es wirklich hilft und beweisbar ist dass es hilft was man durch verschiedene experimenten überprüfen kann Dann sage ich klar sollte man machen Der einzige punkt ist der und dann bin ich beim beim Scrum Guide dann sollte man es halt irgendwann nicht mehr Scrum nennen Das muss man ja auch nicht Denn der begriff der beschreibt nun mal ein ganz bestimmtes set an Regeln rollen meetings und so weiter ich vergleiche das immer mit schach Genauso wie Scrum ist ja schach kein geschützter begriff jeder kann das so verwenden wie er möchte Das heißt ich kann auch hingehen und sagen ich nehme mein schachspiel und ersetze die dame durch einen bauern und alle bauern durchsprengen Und behaupte dann dass das immer noch schach ist wird dich keiner daran hindern Aber alle werden dich angucken und sagen du bist schon sehr sehr merkwürdig Und so ähnlich sehe ich das bei Scrum auch also Man kann und darf und aus meiner meinung nach sollte auch jedes team das dürfen den ansatz anpassen 

[00:32:07.700]
Aber ab einem bestimmten Ausmaß der Anpassung, kann es dann halt nicht mehr das bringen, was Scrum bringen soll. Und der Grund, warum ich dann auch davon abrate, ist, dass ja die Erwartungshaltung verfälscht werden, denn ist mal ganz schlicht, wenn ich vielleicht sogar aus guten Gründen, welche auch immer das sein mögen, dafür sorge, dass ein Scrum -Team nicht mehr einmal pro Sprint ein Increment erzeugen kann. Und mich dann hinstelle und sage, ja aber Scrum hat mir doch Mehrwert einmal pro 30 Tagen versprochen, wie dieses Buch da sagt. 

[00:32:39.800]
Dann kann ich sagen, ja, wäre auch so, wenn es nicht geändert hätte ist. 

[00:32:43.800]
Von daher also, kurz zusammengefasst, ändern, gerne, aber ab einem bestimmten Punkt bitte unter einem anderen Namen, weil ansonsten fühlt es nur zu Missverständnissen. 

[00:32:54.400]
beziehungsweise auch zu Dysfunktionen. Also auch das ist ja möglich, umso mehr man verändert, vielleicht in dem Glauben, dass man, dass die eigene Expertise gerade ausreicht, umso verschwobbelter, um es mal sozusagen mag ja dann auch das gesamte Ding werden. Wie wichtig siehst du denn Wissen im Unternehmen? Also es gibt ja oft die Situation, ein Unternehmen denkt sich, ich will meine Softwareentwicklung weiterentwickeln, holt sich dann Coaches von außen und hat aber zu dem Zeitpunkt ja eigentlich kaum internes Wissen über das eigene Vorgehen, über Frameworks, über Agilität im Allgemeinen. Wie wichtig findest du den Aufbau von Wissen und Können im Unternehmen, wenn es um Scrum geht und wenn es um agile Vorgehensmodelle geht? 

[00:33:40.800]
Ich glaube, wenn es initial nicht da ist, kann man das keinem zum Vorwurf machen. Jeder fängt irgendwo an und es gibt immer wieder Firmen, die das noch nie getan haben. Wo soll es dann noch herkommen? Und dann ist es mehr als fair zu sagen, okay, ich hole mir externe Unterstützung von wem auch immer, von dem Freelance -Gram -Master, von irgendeiner großen IT -Beratung oder von ich weiß nicht wem. Es macht aber natürlich Sinn, diese Expertise dann über die Zeit bei sich aufzubauen, alleine, um auch dafür zu sorgen, dass eine gewisse Konsistenz über die Zeit entsteht. Denn wenn ich die nicht habe, bin ich irgendwann ja in der Situation, dass möglicherweise der nächste und der übernächste externe Scrum -Master oder Agile -Coach, den ich reinhole, völlig andere Ideen hat und man dann dieses Hü und Hot hat. 

[00:34:27.100]
Wohingegen, wenn ich zumindest in der Führungsebene intern Leute habe, die sagen, okay, ich verstehe, wo das hingeht, ich dafür sorgen kann, dass das zumindest in sich konsistent ist. 

[00:34:38.300]
Also ein banales Beispiel, man kann ja mit unterschiedlichen Leuten, die reinkommen, abwechselnd Story Point Estimation und New Estimates einführen und wieder abschaffen und dadurch alle wahnsinnig machen. 

[00:34:51.700]
Und stattdessen zu sagen, okay, ich verstehe, beides hat sein Für und Wider, aber das ist jetzt unser Weg und bei dem bleiben wir bitte, kann viel wert sein. Ob das dann dabei bleibt und man dann irgendwann sagt, okay, jetzt können wir aus uns heraus diese Expertise anbieten oder ob man sagt, ich möchte immer wieder externe Leute rein haben, um neue Impulse rein zu bekommen. Beides hat sein Für und Wider, da habe ich jetzt keine Präferenz. 

[00:35:18.800]
Man sollte sich einfach nur bewusst sein, dass beides mögliche Optionen sind, die man gegeneinander abwägen kann. Vielen Dank. 

[00:35:25.000]
Sehr interessant, ein anderes wichtiges Thema ist ja, jeder Change kostet Geld. Und man kennt ja die Change Kurve. 

[00:35:32.600]
Manchmal ist es ja so oder häufig ist es so, man ändert ein stabiles System, wie gut oder schlecht es jetzt auch immer war. Es war stabil und wenn sich ein Unternehmen einen Change wie die Einführung von Scrum leisten kann, war es jetzt zumindest in gewisser Weise erfolgreich vorher. Jetzt führt vielleicht dann die Auflösung dieses stabilen Zustands dazu, dass die Dinge erstmal schlechter werden in der Wahrnehmung. Also das heißt, man verändert Dinge, die Stabilität ist nicht mehr gewährleistet und um auf ein nächstes Plateau der noch besseren Leistung zu kommen, geht man durch das Teil der Veränderung. Wie meisterst du in Unternehmen, wenn du berätst, 

[00:36:12.200]
diesen Zustand, dass Dinge vielleicht auch erst mal schlechter werden oder in der klassischen Einführung von agilen Methoden ist es ja auch oft so, dass sich Leute denken, ich habe jetzt gedacht, das löst meine Probleme, aber oh Gott, das schafft Transparenz und jetzt wird erst mal alles schlimmer und ich sehe erst mal, dass ich ganz viele Probleme habe. Das muss man ja irgendwie auflösen, weil Unternehmen investieren Geld in eine Veränderung und erst mal wird es schlechter. Erst mal merken die, sie haben sehr viele Probleme und es dauert dann doch eine Zeit lang, bis man auf ein neues stabiles Plateau kommt, wo das ganze dann deutlich besser ist als vorher. Wie meisterst du diese Diskrepanz zwischen den Zuständen? 

[00:36:50.100]
Also ich weiß gar nicht, ob ich da die eine Antwort drauf habe, denn 

[00:36:54.200]
Ich habe auch Unternehmen erlebt, die dieses Entdecken von Problemen als positiv empfunden haben und gesagt haben, endlich wissen wir, warum es hier an bestimmten Stellen nicht vorangeht. 

[00:37:03.000]
Was wir vorher zwar irgendwie gefühlt haben, wo wir aber nie den Finger drauf legen konnten. 

[00:37:07.900]
Und so gesehen ist ja sogar die scheinbare Verschlechterung, dass da auf einmal irgendetwas ganz schwierig auf der Agenda steht, wovon vorher keiner was geahnt hat. Etwas, was man ja sehr positiv sehen kann. Was ich auf der anderen Seite immer wieder sehe, dort wo es eben zu diesem schlagartigen schlechter Werden kommt, da hat das ganz häufig damit zu tun, dass man zu viel zu schnell möchte. Und da kommt man dann wieder so hin. 

[00:37:37.000]
Funktionen oder Dysfunktionen von klassischem Veränderungsmanagement rein, wo dann versucht wird zu sagen, okay wir machen hier das Veränderungsprogramm, das innerhalb von, ich weiß es nicht, zwei Jahren alles auf, bleiben wir beim Beispiel, Scrum umstellt, ohne auch nur zu gucken, sind denn wie vorhin gesagt die Voraussetzungen dafür da oder noch banaler macht das denn überall Sinn. Und dass das natürlich dazu führt, dass für ganz viele der beteiligten Leute sich das dann sinnlos anfühlt und die da nicht mitmachen wollen und der bewusste oder unbewusste Widerstand dann dazu führt, dass es eben zu diesen ständigen Reibereien kommt, die ja Teil dieses gefühlten Niedergangs sind. Also ich muss mich dann ja in solchen Fällen auch nicht wundern. 

[00:38:19.000]
Und vielleicht noch als weiterer Aspekt, diese Grundidee, die ist ja im klassischen Change -Management tatsächlich drin. Ich habe einen stabilen Ausgangszustand und einen stabilen Endzustand und einen dazwischen liegenden Zustand der Unruhe, den ich aber versuche, so kurz wie möglich zu halten. Da kann man sich ja auch fragen, je nachdem, in welchem geschäftlichen Umfeld ich unterwegs bin, ist das wirklich ein zielführendes Vorgehen. Denn unterstellen wir einfach mal, ich bin ein, wie auch immer, gearteter Mittelständler, der auf einmal in einem Markt sich wiederfindet, wo verschiedene Start -ups sehr ähnliche Dinge tun. Ist es dann nicht sinnvoller zu sagen, ok, selbst wenn mir das nicht gefällt, akzeptiere ich das, der 

[00:39:02.800]
stabile Zielzustand vielleicht eher hinderlich ist als nützlich und ich lasse mich auf eine permanente aber dafür irgendwie kontrollierbare Unruhe ein und kontrollierbar nicht dadurch, dass ich das Ergebnis vorhersagen kann, sondern dass ich Mechanismen habe, mit denen ich auf ständig neue Veränderungen reagieren kann, ohne dass mich überwältigen. Auch für sowas ist ja es kaum eigentlich gedacht. Und von solchen Blickpunkten ausgedacht, komme ich natürlich auch auf ganz andere Schlüsse wie, warum, auf welche Weise und mit welchem Zeitrahmen ich denn so etwas wie eine Scrum Einführung und Weiterentwicklung machen möchte. 

[00:39:40.400]
Das ist sehr spannend diese Aussage, dass ein kontrolliertes, ich will es nicht Chaos nennen, aber ein kontrollierter Zustand der permanenten Veränderung ja genau das ist, was man ja eigentlich anstrebt. Also 

[00:39:51.800]
zwar ein kontinuierlicher Verbesserungsprozess oder sich kontinuierlich verbessern des System, das aber genügend Instabilität bietet, um wieder Flexibilität hervorzurufen und Anpassungsfähigkeit hervorzurufen. Das ist ein sehr interessanter Ansatz, wobei das ja auch wieder ein stabiler Zustand ist am Ende. Das heißt, wenn ich ein System habe, das es schafft, diesen Zustand der kontinuierlichen Veränderungen und Anpassungen zu kontrollieren und entsprechend nutzbar zu machen, dann ist das, glaube ich, wahrscheinlich die flexibelste Variante. 

[00:40:21.000]
Würde ich auch sehen. Es ist aber vermutlich in vielen Fällen nicht das, was sich Leute intuitiv unter Stabilität vorstellen. Das erfordert, um das dann auch überall in einem Unternehmen so zu sehen, mit Sicherheit einiges an Kommunikationsaufwand. 

[00:40:37.400]
Aber trotzdem eine sehr, sehr interessante Aussage. 

[00:40:41.700]
Wenn du dich mal mit der Besetzung von Rollen und von Scrum Master und Product Ownern, wir hatten es ja vorhin schon mal kurz angerissen, beschäftigst und ich mache jetzt mal das Fass der Zertifizierungen auf und der Weiterbildungen auf, wie beurteilst du die Weiterbildungsmöglichkeiten für Scrum Master und Product Owner jetzt mal angefangen natürlich bei einer Zertifizierung, die vielleicht erstmal so den Blick durch den Spalt in der Tür in die bunte Welt bietet. Wo geht es dann weiter? Wo sind die Möglichkeiten, wo du sagst, die sind wirklich sinnvoll, sich in so einer Richtung weiterzuentwickeln? Wo sind Weiterbildungsmöglichkeiten? 

[00:41:20.600]
Also vielleicht mit den Zertifizierungen anzufangen, die auch wirklich das offensichtlichste und am häufigsten zuerst genommene Dinge sind. 

[00:41:28.100]
Sie bieten zumindest erstmal die Möglichkeit, ein gemeinsames Verständnis, gemeinsame Begrifflichkeiten, gemeinsame Sprache zu erzeugen und sind damit grundlegend okay. 

[00:41:37.500]
Ich persönlich glaube, das wird ein kleines bisschen in der falschen Reihenfolge gemacht. Also die Leute, die neu ins Scrum Masterjob starten, bei denen ist es häufig so, dass sie zuerst zertifiziert werden und dann Berufserfahrung sammeln. Ich persönlich würde es umgekehrt für sinnvoller halten, erstmal erste Erfahrungen natürlich auch mit Hilfe und Unterstützung und dann durch eine Zertifizierung sich bestätigen lassen, dass man es auch wirklich richtig gemacht hat. Das kann helfen, denn ganz vieles von dem, was eben ins Scrum angedacht ist, ergibt mehr Sinn, wenn man es schon mal in der Praxis erlebt hat, als wenn man es nur aus der Theorie kennt und danach erst die Praxis erleben soll. 

[00:42:16.800]
Aber ich glaube, dass das eben relativ früh in einer, wie soll man es nennen, Lernreise eines Scrummasters drin ist. Ab einer bestimmten Stelle weiß ich nicht mehr, ob ich dann diese ständigen Weiterzertifizierungen empfehlen würde. Also ob ich unbedingt den PSM3 brauche oder den CSPSM oder was es doch immer an Fortsetzungen gibt, ist jetzt mal eine persönliche Meinung. Ich habe Zweifel selbst, wenn ich einige Leute kenne, die solche Weiterzertifizierungen anbieten und denen ich auch glaube, dass sie da sinnvolle Sachen reinpacken. Ich persönlich würde eher sagen, wenn ich dieses Grundset an Wissen und Techniken und Praktiken und Fähigkeiten habe, macht es eben Sinn, eher über den Tellerrand rauszugucken, in andere Bereiche rein. 

[00:43:05.400]
Und da gibt es ja ganz viele verschiedene, also ich kann in den technischen Bereich reingehen und wenn ich einen Entwickler hinterherhund habe oder mich da rein entwickeln möchte, mir zu Sachen beschäftigen wie zum Beispiel DevOps, zum Beispiel Extreme Programming, zum Beispiel Chaos Engineering oder was es da sonst noch alles gibt, ich kann mich in betriebswirtschaftliche Themen rein entwickeln, das heißt ich kann mich mal interessieren, was ist denn Cloud FinOps und warum hilft es mir bei Agilität, was ist denn Beyond Budgeting und ich kann natürlich, was naheliegend ist, in größeren Organisationen auch hingehen und sagen okay, was sind denn die Skalierungsoptionen und welche davon lassen von dem, wenn wir jetzt mal unterstellen, dass Crum immer noch das Ziel ist, welche davon lassen von dem, was Crum eigentlich will, noch möglichst viel übrig. 

[00:43:52.300]
Und ohne jetzt zu sagen, es muss immer Scrum sein, ist es ja beispielsweise so, dass ein Ansatz wie Nexus oder LESS mehr vom ursprünglichen Scrum Intact lässt, als jetzt ein Ansatz wie Disciplined Agile oder Safe, wo vieles von dem, was eigentlich in Scrum angedacht ist, bewusst oder unbewusst beschnitten wird, gerade im Sinn von Team Autonomie und Ownership. 

[00:44:17.700]
Wie wichtig findest du den Austausch außerhalb des eigenen Kontextes und des eigenen Unternehmens? Das heißt, dass man auch regelmäßig mal den Austausch sucht mit Scrum Masters aus anderen Unternehmen oder aus anderen Sparten, vielleicht auch aus ganz anderen Industriezweigen. 

[00:44:36.200]
Also mit Sicherheit wichtig und auch da mit Abstufungen, also ich glaube extrem wichtig ist es für Leute aus kleinen Unternehmen, wo es vielleicht nur ein oder zwei Scrammas, da bei irgendeinem Mittelständler gibt, die einfach im Normalfall auch so viel zu tun haben und auf der anderen Seite ganz häufig auch einen so engen Tätigkeitsbereich haben, dass sie irgendwann in eine sehr große Gefahr reingeraten, eine gewisse Betriebsblindheit zu entwickeln. Wenn ich auf der anderen Seite in einem großen Unternehmen drin bin, wir hatten vorhin das Beispiel Hardware und Software, kann ich allein dadurch, dass ich möglicherweise zwischen denen wechseln kann, auch innerhalb einen ganz anderen Horizont über die Zeit entwickeln. Selbst da ist es aber so, dass sicherlich der Kontakt nach außen hilfreich sein kann, denn große Unternehmen haben auf der anderen Seite dann häufig das Phänomen, dass sie halt ohne es zu merken, eigene Varianten, agiler Frameworks zu entwickeln, die sie dann für normal halten. 

[00:45:32.400]
Und dann haben wir dieses Phänomen, dass wir auf den agilen Mietabs der Region immer wieder sehen, dass irgendjemand kommt und erst mal aus gutem Willen und mit Begeisterung erzählt, wie in seinem Unternehmen Scrum gelebt wird, und dann irgendjemand mehr oder weniger undiplomatisch sagt, das hat aber mit Scrum, wie es gedacht ist, nichts zu tun. Kann man das vielleicht auch höflich sagen, aber es ist zumindest für ganz viele erst mal eine hoch interessante Erkenntnis, die er dann auch weiteres nach sich ziehen kann. 

[00:45:59.900]
Du hast das Stichwort gerade gesagt, nämlich die agilen Events dieser Region. Jetzt bist du ja Mitorganisator eines sehr wichtigen Teilbereiches davon, nämlich des Scrum -Tisches in Bonn. 

[00:46:13.200]
Und ihr habt ja ein Jubiläum demnächst, nämlich das 100. Genau. Tatsächlich den 100. Event. Und der Scrumtish in Bonn ist ja als Open Space organisiert. Und ich weiß nicht, ob jeder das Format kennt. Ich glaube, es ist sehr bekannt mittlerweile. Aber vielleicht kannst du mal ganz kurz erklären, was ist in Open Space und wieso ist der Scrumtish in Bonn so organisiert? 

[00:46:34.100]
Vielleicht für alle, die sich gerade wundern, dass wir jetzt beim 100. Mal sind, liegt daran, dass der monatlich stattfindet. Das heißt, wir sind noch nicht 100 Jahre dabei. Das wäre mit Sicherheit übertrieben. Aber der Open Space Ansatz als solcher, finde ich, passt sehr gut grundlegend zu einem Umfeld, in dem Selbstorganisation gewollt ist, weil er eben für solche Veranstaltungen genau das in den Mittelpunkt stellt. Das heißt, wir haben keine feststehende Agenda, keine Redner, keine Referenten oder Sonstiges. 

[00:47:03.400]
sondern jeder, der möchte, und wir hoffen natürlich immer auf möglichst viel, kann kommen und sein Thema mitbringen, was eine Frage sein kann, ein kleiner Vortrag, den er mitgebracht hat, einen Anstoß, aus dem sich hoffentlich eine wilde Debatte entwickelt oder vielleicht auch ein selbstentwickeltes Spiel, das mit anderen Leuten mal spielen möchte im Sinne von Serious Play. Und all das kann man am Anfang vorstellen. Wir stellen daraus eine gemeinsame Agenda zusammen, ordnen das auf einer großen Wand mit Zetteln an, dass dann normalerweise, sagen wir es mal, drei oder vier Sessions parallel sind und drei oder vier Insights los untereinander und man dann als Teilnehmer die Möglichkeit hat zu sagen, okay, das klingt interessant, da gehe ich hin, das klingt interessant, da gehe ich hin und gegebenenfalls auch zwischen den einzelnen Sessions zu wechseln. 

[00:47:49.600]
Der Erfahrungswert ist, dass es sehr schnell dazu kommt, dass Leuchte damit sehr gut klarkommen. 

[00:47:54.600]
Und es ist auch insofern spannend, wir machen das nicht irgendwo an einem festen Ort, sondern rotieren damit durch verschiedene Gastgeber, also hier in Bonn, durch verschiedene Firmen, die intern auch mehr oder weniger agil oder nascrum arbeiten und für ganz viele von denen ist das auch ein spannendes Erlebnis, weil intern solche Formate nicht existieren mitunter auch aus Sorge, dass es nicht funktionieren würde und sei es auch nur oder kommt keiner mehr Themen. Und dort auch mal zu zeigen, dass es geht, hat bei dem einen oder anderen auch schon zu den Impulsen geführt, das dann selber auszuprobieren. Das bedeutet, auf der einen Seite sagen wir natürlich, wir bilden die Community, wir lernen voneinander, wir inspirieren uns gegenseitig. 

[00:48:36.900]
Aber wir versuchen, durch so etwas auch eben etwas zurückzugeben und den jeweiligen Gastgebern oder auch Teilnehmern zu zeigen, was eben durch Selbstorganisation möglich ist. Und dieses Geben und Nehmen, finde ich, ist ein schöner Punkt, um zu beschreiben, was wir mit diesem Format und diesem Scrumtisch machen wollen. 

[00:48:55.700]
Also ich war ja selber öfter da und das war immer ein sehr bereicherter Austausch und das Witzige ist ja auch, es heißt zwar Scrumtisch, aber es ist ja ein beliebiges Thema. Ich kann ja mit jedem Thema kommen, ob ich mich darüber austauschen will oder ob ich etwas darüber erfahren will, ob ich Expertise der anderen nutzen will oder ich Expertise abgeben will. Diese Flexibilität ist sehr mächtig und deswegen finde ich auch den Impuls, sehr gut zu sagen, das ist auch was Mächtiges, was Unternehmen nutzen können für einen internen Event oder sogar regelmäßige interne Events. 

[00:49:26.600]
Ich habe das auch öfter mit erlebt innerhalb des Unternehmens, dass immer die Angst bestand, so eher dann kommt keiner und dann sagt keiner was, das ist aber gar nicht die Intention dahinter, sondern die Leute, die da sind, sind genau die richtigen, die Themen, die besprochen werden, sind genau die richtigen und es dauert so lange wie es dauert. 

[00:49:43.400]
Und der eine Open Space ist, wenn man in internem Unternehmen irgendwann mal so ein bisschen etabliert hat, mal kürzer, mal länger und es ist vollkommen okay. 

[00:49:51.600]
Also das heißt, man kann sich als Unternehmen durchaus diesen Druck nehmen, dass dieses Format im klassischen Sinne insofern erfolgreich sein muss, dass es immer bis zur maximalen Zeit geht. Es geht um den Austausch und es geht vor allem auch um den Wissenstransfer, der dabei stattfindet und das Lernen, das dabei stattfindet. Deswegen finde ich den Scrumtish in Bonn wirklich sehr interessant und Respekt dafür, dass ihr den 100. demnächst habt. Wann ist er denn, an welchem Datum? Der müsste der 12. 

[00:50:21.400]
September sein. Also es ist immer der zweite Dienst am Monat. 

[00:50:24.600]
Und ich glaube, wir haben ihn niemals auf einen anderen Tag gelegt. Von daher, das ist immer sehr gut, berechenbar immer 19 bis 22 Uhr in ungefähr. Je nachdem, was für Rahmenbedingungen das dann sind, kann es natürlich sein, dass man pünktlich raus muss, weil natürlich die Gastgeber auch Feierabend machen wollen oder dass man lange bleiben kann, aber der Zeitraum ist immer ungefähr der. Wir werden jetzt beim nächsten Mal etwas früher anfangen, weil der Gastgeber die Aktion Mensch angeboten hat, dass wir bei denen vorher etwas grillen können. Und das nehmen wir natürlich gerne an. 

[00:51:00.200]
Wow, das ist ja nicht selbstverständlich, dass das geht. Das geht nicht immer. Ja, Felix, das ist ja vielleicht auch ein schöner Roundup für die Postcast -Folge jetzt. Also ich kann mir jedem raten, da mal vorbeizuschauen. Sehr schöner Austausch. 

[00:51:15.400]
wo man immer was mitnimmt und immer was mitbringen kann und das ist glaube ich die Kombination draus, das ist toll. Aber Felix, was ist denn das, was bei dir als nächstes auf dem Programm steht? 

[00:51:26.900]
Das ist eine spannende Frage. Also hätte ich die Sicherheit haben wollen, im Voraus zu wissen, was ich bald mache, hätte ich einen anderen Beruf ergriffen. 

[00:51:37.500]
Ja, macht total Sinn. 

[00:51:40.100]
Aber tatsächlich würde ich sagen, ich bin gerade an der Schnittstelle zwischen zwei Projekten. Das heißt, ich blicke da voller Spannung und neugier auf das, was jetzt kommt. Ich weiß nicht, ob ich jetzt den kompletten Ruf, den ich mir im Rahmen der Folge hier aufgebaut habe, ruinieren werde. Aber ich habe auch vor, mich ein kleines bisschen mit dem Thema Safe zu beschäftigen, einfach weil es etwas ist, was bei ganz vielen unserer Kunden mittlerweile 

[00:52:03.800]
mehr oder weniger originalgetreu im Einsatz ist und ohne, dass ich jetzt sage, ich finde das alles gut, glaube ich, wenn man nicht weiß, worüber man da redet, kann man eben schlecht mitreden. Von daher ist das so eins der Themen, wo ich jetzt in nächster Zeit die Zeit, die ich nutzen werde, daran investieren werde, um mich da ein bisschen schlau zu machen. 

[00:52:24.500]
Das Respekt dafür und mit meinem Co -House Mike Leber, der ja gerade im Urlaub ist, deswegen führen wir das Gespräch auf zu zweit. Hättest du natürlich einen glühenden Partner der Diskussion, wenn es um self geht, denn ich glaube er ist sehr davon überzeugt, dass das nicht der richtige Weg ist. Aber das können wir ja vielleicht mal in einer weiteren Folge vertiefen, wenn du dann sagen kannst, was deine Erfahrungswerte da drin sind und was die Weiterentwicklung oder was die Weiterbildung in die Richtung gebracht hat. 

[00:52:54.500]
Können wir gerne machen. Also ich glaube jetzt schon sagen zu können, ich sehe vieles kritisch, ich sehe aber nicht alles kritisch. Vielen Dank für's Zuschauen. 

[00:53:03.300]
Und ich wage mich mal weit vor und sage, diese Meinung wird sich auch nicht völlig ändern. 

[00:53:09.800]
Lieber Felix, vielen Dank für deine Expertise. Vielen Dank für die Einblicke in die vielen Themen von Scrum. Es ist ja wie bei vielen Themen, aber in diesem im Speziellen. Man könnte sich auch eine Woche drüber unterhalten. Denn Scrum ist ja mittlerweile schon fast 30 Jahre alt. Trotzdem wird es als neu und innovativ in vielen Unternehmen betrachtet. Ich glaube, wir sind da noch lange nicht am Ende angekommen, sondern wahrscheinlich stehen wir auch nach 30 Jahren oder über 20 Jahren Agile Manifesto immer noch ein bisschen am Anfang und es gibt noch genug zu tun. Insofern meine ich mir keine Sorgen, dass du nicht genug zu tun haben wirst in Zukunft. Und insofern vielen Dank für die Einblicke und deine Expertise. 

[00:53:51.100]
Ja, vielen Dank, dass ich hier teilnehmen durfte. Und vielleicht als Schlusswort einfach mal umzuzeigen, wie wenig wir schon bei der großen Marktdurchdrehung von Scrum sind. 

[00:53:59.900]
Ich habe vor kurzem einen Artikel auf der McKinsey -Website gelesen, wo als Rolle der Scrum -Leader anstelle des Scrummasters stand. Das heißt, Nachholbedarf ist selbst da noch vorhanden, wo man es eigentlich nicht denken sollte. Es gibt noch viel zu tun. 

[00:54:15.900]
Vor allem, wenn da steht, dass er die Scrum -Teams leitet. 

[00:54:20.200]
Ich habe es nicht mehr genau in Erinnerung, aber da stand einiges, wo ich nicht mit einverstanden war. 

[00:54:25.900]
Das zeigt vielleicht, dass die Urexpertise nicht von jedem Unternehmen auf der agilen Wiese stattfindet und man vielleicht auch bei seinen Leistungen bleiben sollte, wenn man die Weiterentwicklung in die Richtung nicht schafft. Ich danke dir vielmals, Felix, und ich freue mich darauf, beim nächsten Scrumtisch dabei zu sein. Bis bald!