Skillbyte Podcast #53: SCRUM erfolgreich einsetzen

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Digitale Bildung in Deutschland

// Inhalt //
01:08 - Intro Hannes Ftuni, Gesellschafter der Scrumcorp
01:41 - Was bedeutet "SCRUM"?
04:58 - Der Ursprung von SCRUM
06:45 - Wettbewerbsvorteil Agilität durch SCRUM
10:25 - Welche Unternehmen sollten agil nach SCRUM arbeiten?
12:04 - Voraussetzungen für agiles Arbeiten
13:49 - Was sind (technische/organisatorische) Herausforderungen bei der Arbeit mit SCRUM?
14:57 - Wann eignet sich SCRUM nicht?
15:43 - Was hat es mit KANBAN auf sich?
18:09 - Müssen sich Entwickler umstellen um nach SCRUM zu arbeiten?
19:12 - Selbstmanagement heißt Selbstverantwortung
20:00 - SCRUM Fachvokabular: Artefakte, Rollen und Events
24:31 - Tricks für den Sprintwechsel
28:39 - Abwechslung bei der Retrospektive
31:28 - Die Bedeutung des Dailys
33:18 - Werkzeuge / Tools
35:06 - Erfolgsstory aus der Praxis
37:36 - Buchtipps
38:23 - Wo kann man sich zertifizieren lassen?

Buchtipps:

Der Scrum Guide: https://www.scrum.org/resources/scrum-guide
Was ist Scrum: https://www.amazon.de/Was-ist-Scrum-agile-Guide-ebook/dp/B08C7TPWQG
Inspired: https://www.amazon.de/INSPIRED-Create-Tech-Products-Customers/dp/1119387507

Kontakt zur Scrumcorp von Hannes Ftuni: https://scrumcorp.de/

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Was sie damals geschafft haben, ist, dass selbst manage Teams ein Produkt erstellen, indem jeder Schritt immer wieder überprüft wurde, ob der gut läuft, ob der schlecht läuft und optimiert wurde. Und das Ineinandergreifen dieser Schritte hat dazu geführt, dass die Fliessband Arbeit revolutioniert wurde und die just in time Lieferungen erfunden wurde. Das hat man dann in den 90ern adaptiert auf Software und andere Produkte. Also generell Produktentwicklung, aber hauptsächlich Software profitiert dadurch, dass Verschwendung vermieden wird.

Herzlich Willkommen zur Skillbyte Podcast Episode Nr. 53 Scrum erfolgreich einsetzen Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld, wenn er IT Entscheider oder IT Fachkraft seid. Wenn im Verlauf der Episode eine höhere Frage aufkommt, freuen uns selber Post an Podcasts Skillbyte. Auch freuen wir uns immer über Bewertungen und insbesondere über Weiterempfehlung an eure Freunde und Kollegen, für die dieses Thema ebenfalls spannend ist. Ich bin heute hier mit Hannes Stoney Hallo Hannes Maurice. Erzähl uns doch kurz mal, wie Scrum in dein Leben gekommen ist und was du machst und welchen Hintergrund du hast.

Sehr gerne. Erst einmal vielen Dank, dass ich an eurem Podcast teilnehmen darf. Ich bin ein großer Fan. Gebe ich zu. Mia WBK kommen. Also es fing alles 2009 an, als ich das erste Mal etwas entwickelt habe mit meinem aktuellen Geschäftspartner. Wir haben eine Methode gesucht, uns zu organisieren und sind dann auf Kanban gestoßen. Sehr leichte Adaptionen von agil und der Ursprung von allem. So bin ich zu Ergehe gekommen. Also es ist inzwischen 12 Jahre her.

Wahnsinn! Wahnsinn!

Seit wann gibt es Scrum?

Scrum gibt es seit 1993, da Sutherland und Strava die beiden Scrum Guide Brünner Abend damals zum ersten Mal den Begriff verwendet.

Okay, ja, dann hat es ja doch noch eine Zeit gedauert, bis es sich durchgesetzt hat.

Ja, also der offizielle ist Krankheit. Der große Boom kam erst in den Nullerjahren. Auch in den Staaten z.B. 2001 war die erste große Version des Krankheits wurde veröffentlicht.

Das heißt, du bist 2009 mit Scrum in Berührung gekommen. Und wie ist dein weiterer Werdegang? Du hast gesagt, ich finde das so klasse. Ich möchte mich unbedingt mehr damit beschäftigen.

Genau so war es. Es war so simpel und einfach zu adaptieren und es hat gut funktioniert. Man hatte die Transparenz erarbeitet, gerade woran. Man hat tatsächlich es genutzt, wie es gedacht war, ohne großes Coaching. Dann habe ich mich schauen lassen. Damals gingen die beiden Raubbaus aus aller Welt noch selbst auf Tour und haben Seminare gehalten, auch in Deutschland. Und ich war auch mit Soller Lend in einem Seminar und habe mich dort zertifizieren lassen zum Scrum Master.

Recht früh, auch 2010, meine ich, war das und damals war ich noch angestellt bei einem Ölkonzern und habe dort dann auch gleich das, was ich gelernt habe, eingesetzt und uns einfach mal organisiert und Selbstmanagement eingeführt. Danach haben die ersten Anfragen zu unserer Methode Wie machen wir das? Wissen, wie wir darauf gestoßen und ich bin dann irgendwie in diese Beratung gerutscht. Und da entwickeln eher das Steckenpferd von meinem Geschäftspartner war, hab ich mich dann in die Beratung Schiene entwickelt und ging auch recht fix.

2011 wurde ich zum ersten Mal offiziell als Berater gebucht, tatsächlich damals als eCall Coach, um Agile Vertrieb einzuführen bei einem Personaldienstleister.

Das heißt, es war auch damals der Bedarf war groß, heute ja sowieso. Und so bist du dann quasi vom Ölkonzern zum Freiberufler geworden oder Unternehmer geworden. Kann man das so sagen?

Genau, Yorkern so sagen. Es lief erstmal nebenher. Und irgendwann haben wir dann gucken ganz einfaches Gewerbe angemeldet und dann eine GmbH gegründet. Haben wir drei Firmen, die sich so ein bisschen thematisch spalten. Daraus entstand dann die Selbstständigkeit Beute. Wir sind jetzt inzwischen 24 Band und letzten Jahren ging es mit agil, insbesondere extrem steil.

Was verbirgt sich denn hinter dem Begriff Scrum? Also wo kommt das Wort her?

Lustigerweise kommt der Begriff aus dem Rugby. Es ist eine Standardsituation. Was die Situation mit vor Fehlentwicklungen zu tun hat, ist folgende Das ist eine Situation, in der acht Spieler vom gegnerische Team von Mein Team sich quasi kabbeln. Übersetzt heißt das Gedränge. Das eine tief versucht, den Ball aus diesem Gedrängel herauszuholen in ihre Richtung und das andere in die andere Richtung dementsprechen.

Der Hauptfokus liegt auf dem Ball und das Ziel dieses Gedrängel ist, den Ball auszuliefern.

Das heißt, aus diesem Gedränge rauszuholen und mit dem Ball einen Angriff zu starten.

Weißt du auch so ein bisschen zu den Hintergründen, wie Scrum entwickelt wurde? Also ich denke mal die meisten zu erkennen, dass Wasserfall Modell, was in den 70er 80er Jahren verwendet wurde, wo man einfach die Software geplant hat, anschließend die Implementierung begonnen hat und als man mit der Implementierung Jahre später fertig war, hat man festgestellt Na ja, das passt so gar nicht. Wir haben das nicht gut geplant.

Der Ursprung von Scrum ist Kanban. Kanban hat begonnen bei Toyota in den 30er Jahren. Die haben sich zum Ziel gesetzt, Überlastungen, Abweichung und Verschwendung zu vermeiden. Die japanischen Begriffe dafür sind allgemein geläufig. Einhergehen Weltmodell, Mura und Muri. Und was sie damals geschafft haben, ist, dass selbst manage Teams ein Produkt erstellen, indem jeder Schritt immer wieder überprüft wurde, ob der gut läuft, ob der schlecht läuft und optimiert wurde. Und das Ineinandergreifen dieser Schritte hat dazu geführt, dass die Fliessband Arbeit revolutioniert wurde und die justitiabel.

Lieferung erfunden wurde, das hat man dann in den Neunzigern adaptiert auf Software und andere Produkte. Also generell Produktentwicklung, aber hauptsächlich Software profitiert dadurch, dass Verschwendung vermieden wird. Du kennst sicherlich das allseits beliebte Programm Excel Maurice und einer Studie zufolge, die schon etwas älter werden. Nur 15 prozent der Features von Excel Benutzer, das heißt 85 prozent sind redundant, was soviel heißt wie würden 80 prozent der Arbeit hätte vermieden werden können. Das ist Verschwendung und Scrum greift genau da ein.

Du entwickelst nur Dinge, die tatsächlich benutzt werden. Du entwickelst nur Dinge, die der Markt braucht. Der Kunde braucht und überleg's sie nicht. Eine riesen Software wie Excel, wo es am Ende dann 85 prozent Verschwendung gab und nur 15 prozent werden tatsächlich benutzt.

Bei Excel was sind Standardprogramm ist, kann man das ja vielleicht noch rechtfertigen und sagen irgendjemand benutzt diese Funktion schon, aber bei Individuals Software und ich denke, da wird Scrum am meisten eingesetzt. Da sollte man schon genau den Nagel auf den Kopf treffen, weil Softwareentwicklung einfach sehr teuer ist.

Genau, und durch Fachkräftemangel. Es ist nicht nur teuer, sondern auch rar.

Es ist sehr schwierig, an gute Leute ranzukommen, wie du weißt.

Was sind denn noch weitere Vorteile oder warum ist das Thema skrupelloses Eingangs schon erwähnt, aktueller denn je? Der Bedarf größer denn je?

Es wäre ja naiv zu behaupten, dass die Menschen in 30 Jahren nicht darüber lachen, wie unmodern wir aktuell sind. So wie wir, wenn wir an die Neunziger denken. Da gab's nicht mehr das Internet und digital. Wir sind gerade in der pre digitalen Phase, sind noch lange nicht so weit. Entwicklung ist inzwischen überall zu finden. Selbst mein Rasenmäher ist digital und kommuniziert mit dem Internet. Und die Nachfrage nach guten Produkten, nach Menschen, die diese gute Produkte entwickeln, ist derartig groß, dass man alle Methode braucht, in der man Verschwendung vermeidet.

Man braucht eine Methode, in der man gute Produkte macht, glückliche Kunden hat, weil der Wettbewerb ist agil und produziert Produkte, die Reaktionsfähigkeit sind und kontinuierlich verbessert werden. Dementsprechend muss ich auch folgen und auch diese Produkte liefern, sonst bin ich auch nicht mehr fähig. Wettbewerbsfähig.

Du sagst, es gibt mehr Software heute denn je. Es wird auch mehr Software denn je entwickelt. Die Anforderungen ändern sich laufend und es kommen immer neue Entwicklungen dazu. Und da muss man drauf reagieren, weil die Konkurrenz schläft nicht. Und wenn ich das so Wasserfall mäßig durchplanen, dann völlig einfach sehr viel Zeit in der Planungs und Implementierung Phase, wo ich im Grunde nicht reagieren kann.

Ja, du verschwendest sehr viel Zeit in der Planung, aber dann auch mehr Zeit und Geld in der Entwicklung. Und du hast halt keine ächt Daten, mit denen du arbeiten kannst beim agilen Vorgehen. Generell ist nicht nur Scrum was für eine schnelle Time to market, wie man es so schön nennt. Es heißt Du bist schnell auf Markt und hast direkt schon Erkenntnisse. Alles was mit agil zu tun hat, basiert auf Empirie und Empirie. Heißt Ich habe gelernt, gesehen, gehört.

Bevor du ein Produkt nicht angetastet hast oder auf den Markt geworfen hast, ist alles nur eine Ratespiele. Und das verkürzt Scrum dadurch, dass wir nur einen kurzen Iteration Zyklus Plan von eins bis vier Wochen haben wir auch dementsprechend einen viel schnelleren Start bekommen. Theoretisch. Wenn wir beide erst eine Idee haben, könnten wir morgen damit anfangen, die umzusetzen. Mit agilen Methoden, weil wir planen das Minimal Produkt und sagen Okay, User müssen sich registrieren bei unserer Idee.

Wir machen erst mal das auch Modul oder? Und das geht nur mit agilen Methoden. Wenn wir ein Wasserfall Modell wählen, dann planen wir jetzt erst einmal die nächsten drei Monate. Ein anderer ist schneller, hat das minimale Produkt auf dem Markt, hat echte Erkenntnisse, hat das Produkt auch dementsprechend weiterentwickelt. Dann brauchen wir gar nicht erst einen Startgebühr. So weit sind.

Okay, ich verstehe. Das ist natürlich so ein bisschen gegen die deutsche und auch gegen die österreichische Schweizer Seele. Dass man im Prinzip mit nein, im nicht perfekten Produkt direkt an den Markt geht und im Prinzip mit der Evaluation dieses Produktes am echten Kunden startet. Aber dieses Lernen ist ganz essentiell. Was du sagst. Das heißt, echte Kunden benutzen das Produkt oder die Kernfunktion und sagen dann Das brauche ich so, das brauche ich so, das brauche ich so. Man kann sich schnell etablieren auf Basis von echtem Wissen oder echtem Feedback und nicht von Planungen, die im stillen Kämmerlein durchgeführt werden.

Ganz genau. Außerdem können wir auch viel schneller Fehler erkennen. Und wenn wir jetzt erst einmal das komplette Exel Tool bauen und dann auf den Markt werfen, was du so viele Fehler das ausspuckt.

Ja okay, also man geht kleinschrittig vor und wählt einen iterativen Ansatz. Das ist wahrscheinlich auch einer der Hauptvorteil von Scrum, oder?

Richtig. Das ist quasi die Essenz.

Interaktives Vorgehen und Selbstmanagement.

Selbstmanagement finde ich auch ganz wichtig. Also kann ich aus der persönlichen Erfahrung sagen, weil man dem Team oder den einzelnen Mitgliedern ja auch Verantwortung überträgt. Und jeder, der in Großprojekten schon mal dieses manchmal vorherrschende Verantwortungs Vakuum kennengelernt hat, der weiß, dass es dann sehr sehr schwer wird. Gibt es denn Unternehmen, die sich ganz besonders mit Scrum beschäftigen sollten oder mit agilen Vorgehen? Also kann man. Differenzieren oder würdest du sagen, das betrifft im Grunde alle Unternehmen, die Software erstellen?

Also ich kann dir keine Unternehmenden, was sich nicht durch agilen Methoden verbessern könnte in der Software. Ich kann jetzt nicht für alle Unternehmen der Welt sprechen. Schwierig wird es, wenn man nicht diese Kontrolle abgeben möchte. Das ist der einzige Punkt, wo es manchmal scheitert, weil bei Agil geht es um Transparenz und nicht um Kontrolle. Es heißt, Führungskräfte haben ein anderes Vorgehen, eine andere Aufgabe und diese Unternehmen, die diese Kontrolle nicht abgeben können. Dem würde ich raten, das nicht zu machen.

Aber es hat nichts mit dem Produkt zu tun. Also überall, wo etwas entwickelt wird, ein Produkt, kann agil gearbeitet werden, auch das sagenumwobene Atomkraftwerk. Würdest du Agile entwickeln oder die Steuerungs Software dafür?

Ja, das natürlich der Klassiker, aber nur eine Autobahnbrücke baust, dann hast du ein klares Ziel und du kannst selbstverständlich keine Veränderung mitten im Projekt vornehmen. Allerdings hier musst du etwas raus zoomen und wenn du 10 Autobahnbrücken boss leister aus jedem mal etwas für das nächste Mal. Das heißt du Zooms einfach nur etwas raus. Selbstverständlich veränderst du die Autobahnbrücke nicht bei 70 prozent. Das sollte man definitiv nicht. Du weißt aber beim nächsten Mal dann Iteration zu bis es halt etwas länger.

Das ist der komplette Ort der Autobahnbrücke.

Das wäre so, als wenn man mitten im Sprint das nochmal aufbrechen würde. Okay, und die Autobahnbrücke ist hat ein Sprint. Aber ich glaube, jeder kann sich in die Situation hineinversetzen, dass man nach Fertigstellung einer Aufgabe sagt Oh, hätte ich das und das mal vorher gewusst, wenn ich es jetzt nochmal machen müsste, dann wär ich viel schlauer. Und genau das kommt dann hier auch zum Tragen. Gibt es denn Voraussetzungen, die Unternehmen erfüllen sollten, die nach Scrum arbeiten möchten?

Also du sagst, der Führungsstil ist ein anderer. Ich muss quasi dem Team vertrauen und muss dieser Transparenz vertrauen.

Richtig. Die Voraussetzung ist tatsächlich Kopfsache. Akzeptieren, dass du im Team die Verantwortung überlässt. Du musst akzeptieren, dass das Team über das Wie entscheidet und selbst als Führungskraft über das, was entscheidet. Und das Was sollte aber auch eine Markt Erkenntnis sein und nicht einfach nur eine Theorie. Das ist vielmehr Kopfsache. Ob ich agil einführen kann oder nicht. Vorbedingung ist tatsächlich wahrscheinlich Wissen schaffen, zu Schulungen gehen. Agil heißt nicht, dass es über Nacht funktioniert. Es ist kein Schalter, den man drückt.

Es ist ein Kulturwandel. Damit muss man sich erst anfreunden, dass es ein Kulturwandel ist. Und man muss auch den gesamten Weg gehen. Ich sehe oft, dass Unternehmen nach kurzer Zeit aufgeben, weil sie ein Dadie machen und dann meinen, sie sind agil und sich wundern, dass nichts anderes passiert.

Da gehört schon etwas mehr dazu.

Das kann ich aus meiner Praxis sagen. Ich habe alle möglichen Formen Hydras seltsame Gebilde von Prozessen erkannt, die agil genannt wurden. Und ich will jetzt nicht sagen, dass all das schlecht war oder nur in Reinform nach Scrum arbeiten kann. Aber man kommt irgendwie an den Punkt, wo agil gearbeitet wird und dann trotzdem gefragt wird Wann ist es denn fertig? Oder also ich jetzt nicht im Sprint, sondern wirklich dann langfristige Ziele. Es wär so, wie wenn man sagen würde, ich mache ein Forschungsprojekt, um eine schlimme Krankheit zu heilen.

Und dann will wer die erste Frage Ja, wann sie wählen. Wann haben wir denn das Gegenmittel so ungefähr? Oder das Medikament? Ganz genau. Sind legitime Fragen, ist aber ein bisschen Glaskugel bei wenn du Firmen begleitest, die ihre Prozesse umstellen auf Agilität. Gibt es dort besondere technische und organisatorische Herausforderungen, wo du dann erst einmal Weichen stellen musst?

Tatsächlich ist mir das noch nicht begegnet, dass es an der Technik hapert. Im großen Ganzen ist der Staat sehr leichtfüßig, das heißt, im Großen und Ganzen brauchst du lediglich ein Ticketsystem. Dann kannst du schon starten und das Ticketsystem kann aus Post-its ein haptisches Board sein oder anderen Klebezettel in selbstverständlich. Es kann aber auch digital sein. Also das ist die Voraussetzung, dass so eine Art Ticketsystem hast und dann kannst du eigentlich schon starten. Weitere technische Hürden sind mir noch nicht begegnet.

Organisatorisch wäre dann da der Main Shift, der muss da mitspielen und man muss halt die Rückendeckung vom Vorstand haben, gerade in der stürmischen Phase, wenn man etwas umstellt.

Der Rückhalt vom Management ist enorm wichtig für das Funktionieren von Agil und Scrum, weil die Masiar entscheidend waren. Abgebrochen wird. Mit der Einführung von Agil Hundi haben die Manager einen langen Atem. Funktioniert das? Sind sie ungeduldig? Was gleichzusetzen ist mit Sie glauben nicht dran, dann funktioniert das nicht.

Was ist kurz angerissen? Aber gibt es auch Projekte oder Konstellationen, in denen du Scrum nicht empfiehlst?

Ich würde niemanden Scrum empfehlen, der nicht die Kontrolle abgeben kann. Wer Kontrolle nicht durch Transparenz ersetzen kann, der sollte das nicht machen. Man kennt sich ja selbst am besten. Und es ist völlig legitim, dass du auch mit Kontrolle erfolgreich bist. Allerdings wirst du mit agile Methoden nicht glücklich, wenn du ein Kontrollzwang hast, sondern es ist mehr dieses Abgeben und ich kümmere mich nicht mehr darum, sondern ich habe andere Aufgaben als Manager. Und für jedes Umsetzung sind der Welt.

Kann ich nur sagen Es gibt nichts Schöneres als echtes, selbstgefälliges Arbeit.

Man muss Verantwortung abgeben können, das kann man ja sagen, dass das eine Voraussetzung für das Management ist. Was hat es denn mit Kanban Aufsicht? Also kannst du sagen, was der Unterschied zwischen Kanban und Scrum ist, wie die sich ergänzen und welche Unterschiede es gibt?

Ja, durchaus. Also ich erkläre kann man immer ganz gerne mit einem Beispiel, dass jeder Mensch im Westen versteht. Wenn du zu Star Wars glees und ein Kaffee bestellst, dann wird dein Auftrag auf den Kaffeebecher geschrieben. Was die meisten nicht wissen ist, dass dieser Kaffeebecher die Kanban Karte ist. Da steht dein Name drauf, da steht drauf was du möchtest im Detail. Also welche Schritte zur Produktion gehören dieser Becher? Die Karlmann Karte mit weitergegeben in die Produktion.

Da wird dein Kaffee hergestellt. Der Barista stellt ein Café her, macht ein Sirup rein, macht den Deckel drauf und im dritten Step ist die Auslieferung. Da wird er ausgeliefert und du als Kunde nimmst den Becher entgegen, probierst den Kaffee und nimmst das Produkt ab. Das heißt ausgeliefert. Kunde ist zufrieden und die Produktionskette läuft in derzeit weiter. Das ist Kanban. Kann man ist Japanisch für Karte heißt nichts anderes als Ich schreibe auf eine Karte, was zu tun ist in unterschiedlichen Schritten und diese Schritte werden von unterschiedlichen Stationen abgearbeitet und am Ende wird ausgeliefert.

Selbst im Management. Gemeinsamkeit ist die Selbstorganisation und die Reaktionsfähigkeit. Und zu jedem Zeitpunkt kann man Veränderungen machen. Ich kann. Während ich bestelle, kann ich den Barista zurufen Bitte, machte sie doch nicht rein.

Er wird das schaffen. Kann man es wie die Rezept Karte, wo genau draufsteht, welche Arbeitsschritte für das Produkt erforderlich sind? Sozusagen.

Genau. Was ist dann Scrum im Gegensatz, wenn ich das dagegen halte?

Ja, bei Scrum sind nicht aufeinander folgende Schritte, sondern es geschieht alles gleichzeitig. Es wird entwickelt, es wird getestet, es wird designt und am Ende wird ausgeliefert. Also die Schritte beim Scrum passieren gleichzeitig. Der Unterschied ist auch, dass bei Kanban eine Sache man arbeitet an einer Sache und nicht an mehreren. Also lass den Fokus auf den aktuellen Step by Scammer, seinen Fokus auf das ganzheitliche Bild, das Instrument, was am Ende herauskommt. Scrum nutzt man in komplexen Umfeldern, wo Teamwork gefragt ist.

Und Kanban kannst du in einfachen Produktions Umfeldern oder z.B. ganz klassisch das Arti Services Service Deeds. Oder ganz klassisch ATIS Service Desk ist ja auch immer klassisches Kanalsystem.

Okay, wo deine Anfrage reinkommt.

Ich schreib ein Ticket, also ich schreib einen Becher und auf dem Becher steht dann, was gemacht werden muss. Okay, das verstehe ich. Du wirst in deiner täglichen Tätigkeit ja auch viel mit Software, Entwicklern und Testern usw. zu tun haben. Müssen die sich auch umstellen, wenn die nach Scrum arbeiten oder ist das im Grunde schon, entspricht das sehr stark der natürlicher Arbeitsweise?

Ich glaube, das kannst du auch gut beurteilen.

Maurice wolltest dich sagen lassen, weil du mit mehr Entwicklern sicher zusammengearbeitet hast. Ich würde sagen, das kommt den Entwicklern entgegen. Wenn man eine Funktion entwickelt hat oder einen Bug einen Fehler behoben hat, dann ist man ja sozusagen geistig noch frisch in dem Thema drin. Und wenn das dann sofort abgenommen wird und sofort in das Produkt integriert und ausgeliefert wird, ist das natürlich ein Riesenvorteil für den Endkunden, wenn er im Prinzip heute morgen ist der Fehler aufgetreten und abends ist der Fehler schon behoben.

Die Software ist aktualisiert worden und alle nachfolgenden Kunden profitieren von der Fehler Lösung. Das finde ich eine sehr natürliche Arbeitseinstellung. Also zumindest für mich. Und ich würde auch sagen, wenn ich so an andere Entwickler denke, kommt denen das auch eher entgegen.

Ich kann dir nur zustimmen. Ich habe gute Erfahrungen machen Menschen, die sich darauf eingelassen haben. Es gibt allerdings auch tatsächlich Entwickler, die dieses Selbstmanagement ablehnen, weil das ja auch Verantwortung heißt. Das heißt, du verantwortet es. Manche möchten diese Entscheidung gar nicht treffen. Die fangen die alte Welt, in der die komplette Verantwortung bei der Führung liegt, gar nicht so schlecht. Die fanden auch die Linie gut. Diese Einstellung hat nicht mal was mit dem Alter zu tun.

Es gibt junge Menschen, die das so sehen, genauso wie Menschen älteren Semester.

Das wahrscheinlich einfach eine Frage der Arbeitseinstellung oder der Frage Möchte ich Verantwortung übernehmen? Möchte ich eigenverantwortlich arbeiten?

Genau. Weil selbstorganisiert zu arbeiten heißt auch, selbstorganisiert zu arbeiten. Ich muss mich selbst motivieren. Ich ernte die Früchte, wenn es gut läuft. Und wenn es schlecht läuft, heißt es, dass ich nachbessern muss.

Welche Begriffe tauchen in häufig im Zusammenhang mit Scrum auf? Also man hört ja oftmals von Sprint Backlog, Product Owner. Was gibt es da von Kosmos? Vielleicht gibt's von Stars und kurzen Ablauf, dass man, wenn man die Begriffe hört, weiß, was gemeint ist.

Ja, sehr gerne. Es würde den Rahmen sprengen, wenn ich jetzt auf alles eingehe. In Scrum gibt es Feste, Rollen, Feste, Events und feste Artefakte.

In Zahlen ausgedrückt sind das vier Rollen, fünf Events und drei Artefakte, von denen man immer spricht. Bei den Artefakten ist es das Produkt Backlog, das Sprint, Backlog und. Das inkrementelle, das Produkt Backlog ist eine Liste von Anforderungen, die priorisiert ist. Das heißt, was oben ist, sollte zuerst erledigt werden und dann wird die Priorisierung. Je weiter unten das Ticket ist, desto niedriger ist es priorisiert. Das Feedback Lock umfasst die Anforderung Liste für den aktuellen Iteration Zyklus.

Also, wenn wir jetzt ein, zwei Wochen Sprint wählen, machen wir in diesen zwei Wochen eine Anforderung Liste, die wie es von Backlog nennen. Und da innerhalb dieses von Backdoors gibt's keine Priorisierung. Alles, was im Sprint Backlog ist, sollte erledigt werden und das Instrument ist das Ergebnis des mit Black-Box. Am Ende des Winters haben wir Instrumente, die heraus purzeln und Plural ist hier bewusst gewählt. Also normalerweise hat man mehr als eingecremt prozent. Die vier Rollen sind der Prolog oder das Entwicklerteam bzw.

Dev Team und der Scrum Master. Und als vierte Rolle ist es so, dass dies der Kola sind quasi die Sponsoren aller Interessensgruppe, die großes Interesse an dem Produkt hat. Der Product Owner ist sozusagen der Mini CEO für dieses Produkt. Es heißt, ihm gehört das Produkt rein fachlich und er entscheidet darüber, was als nächstes entwickelt wird, was Parodist wird und was nicht, welcher Bug behoben wird und welcher nicht. Das Umsetzung Steam Entwicklerteam sind die, die über das Wie entscheiden und das dann auch tatsächlich umsetzen.

Das beinhaltet aber auch so etwas wie ein Designer oder einen Tester als Entwicklerteam. Es besteht nicht nur aus Entwicklern und der Scrum Master.

Ich nenne auch gerne Scrum Polizist. Also Aufgaben ist es nämlich, auf die Einhaltung der Scrum Regel zu achten. Allerdings diente auch als Moderator und löst im Pferdmenges auch sogenannte Hindernisse. Und die Events. Die Ereignisse sind des Daily das Alltägliche. 15 Minuten steinbocks wir jeden Tag zur selben Zeit an selben Ort, in der sich das Entwicklerteam austauscht und nach Hilfe fragt oder Hilfe anbietet. Das Bild an sich ist auch eines dieser Events. Das ist der Iteration Zyklus, die alle anderen Events umfasst.

Am Ende des Prints gibt's als Print Review. In dieser Review werden die Instrumente des vergangenen Sprints, des der Cooldown vorgeführt. Und nach der Review gibt es eine Retrospektive eines Scrum Team, ein ernst quanti internes Event mit Scrum Master und Pura Bruna. Und dort wird nun mal reflektiert, was gut oder bzw. was schlecht gelaufen ist im letzten Iteration Zyklus und jeder Schritt schadet mit dem Spel Planning.

Dort wird der nächste Iteration Zyklus geplant. Das heißt der Schnelldurchlauf.

Okay. Aber das ist ja schon eine ganze menge an informationen. Hast du eine lieblings komponente im scrum prozess? Also was machst du am liebsten? z.B. Planning Poker? Hab ich dich erlebt, dass du das als Scrum Master gerne moderiere?

Ist meine Superkraft. Ist tatsächlich eher so die Scrum Einführung agil isierung. Also nicht nur Scrum, sondern agile Methoden einführen. Die richtige Methode beim richtigen Team und agile Skalierung. Es wäre ja blauäugig zu sagen, dass so ein Scrum Guide, der für ein Lied Startup geschrieben ist, auch in einem Konzern funktioniert. Aber bei Kosen ist es ja oft so, dass tatsächlich nur die Vorstände eine Kreditkarte haben, z.B. wenn man nur z.B. irgendwie schnell eine Datenbank braucht, dann braucht man meist eine Kreditkarte und kann der Product Owner dann schon nicht machen.

Das ist halt das, was ich auch am liebsten mache Agile einführen in Umfeldern, die gar nicht mal so agil sind, die schwierig haben, Selbstmanagement einzuführen, die Schilcher am agile Methoden zu integrieren, weil es einfach viel zu groß ist und viel zu komplex ist, um einfach nur.

Also hab ich dich auch erlebt, dass du gerne Widerstände aus dem Weg räumst und die adressiert ist. Also unser impertinent Board, wo man dann genau guckt, was haben wir das letzte Mal identifiziert an Problemen und welche Probleme haben sich gelöst? Im Gegensatz zum letzten Sprint oder welche sind natürlich auch neu hinzugekommen. Das muss man ja auch sagen. Das geschieht leider auch ab und an, also ist der Hauptjob. Ich mache das nicht am liebsten, gebe ich zu.

Aber in Permanenz aus dem Weg räumen ist der Hauptjob.

Jetzt ist es ja so, dass die meisten Sprints bei Unternehmen, die agil arbeiten oder so jedenfalls meine Erfahrung dauern wirklich immer zwei Wochen. Und dann kommt ein Tag alle zwei Wochen, wo der Sprint gewechselt wird, also der alte Sprint endet, der neue Sprint wird aufgesetzt und an diesem Tag zeigt man auch, was man gemacht hat in den letzten zwei Wochen. Das ist ein sehr kommunikativer Tag. Also es wird viel gesprochen, diskutiert, neu geplant. Das ist meiner Beobachtung nach ein ziemlich anstrengender Tag, obwohl gar nicht so viel, also Software entwickelt wird quasi nicht, sondern man guckt einfach Was haben wir geschafft und was ist jetzt der nächste oder der logische nächste Schritt?

Was müssen wir jetzt berücksichtigen? Welche Aufgaben gibt es? Was können wir machen? Wer ist in Urlaub, wie sie Ressourcen, LÃge usw.. Hast du da irgendwie Tricks, wie man diesen Tag flüssiger gestalten kann aus deinem breiten Wissen? Also du. Ich nehme mal an, du hast es ja schon mal sehr vielen Unternehmen gesehen. Da gibt's bestimmt den einen oder anderen Kniff, den du vielleicht verraten magst.

Ja. Also das Beste am. Wechsel Tag ist meist das Planning, wenn man die Krankheit liest, dann empfehlen die so etwas wie 2 Stunden pro Sprint Woche für das Planning, aber in 4 Stunden Planning und Trivia zusammenarbeitet. Maurice Unsere Paintings dauern ja nicht länger als 15 Minuten. Eine Stunde anderthalb. Aber wie schafft man das mit Refill? Das ist kein offizielles Event. Allerdings ist das sozusagen ein vorgelegt gelegtes Planning, indem man Anforderungen für den kommenden Iteration Zyklus breit macht, für die Umsetzung.

Es heißt, man bereitet schon mal Stories vor, sodass man im Planning im besten Fall nur über den Umfang des Bilds entscheidet und sagt Wir ziehen diese Menge rein. So kann man zum Beispiel das Planning auflösen. Auch C ist eine Retrospektive. Die Retrospektive ist ok, wenn der Scrum Master keine Abwechslung bietet. Wenn man jedesmal das Gleiche macht, dann hat irgendwann mal keiner der Beteiligten mehr Lust drauf. Ist dir das schon mal begegnet?

Maurice Ja, das ist mir begegnet. Das Planning ist die größte Herausforderung, sagst du. Also ich habe das ist aber allerdings schon einige Jahre her, da gab es einen Pred Check für Tickets jetzt bei dem Unternehmen, an das ich jetzt denke. Und das war eine Rolle, die habe ich damals ausgefüllt und das war bestimmt die Hälfte meiner Arbeitszeit. Wenn ich länger da bin ich einfach nur von Fachabteilung A zu B zu C gelaufen und hab die Anforderungen eingesammelt und hab quasi so eine Art technische Lösung Skizze runter geschrieben.

Also wie kann man das lösen? Was ist der Soll-Zustand? Was ist der aktuelle Ist-Zustand? Was wie kann man das machen? Wie kann man das technisch integrieren? Diese Tickets hab ich dann sozusagen runter geschrieben und das war eine mega Arbeit. Aber natürlich. Also ich war dann immer der Flaschenhals, weil es schon so viel vor geplant war, dass die Entwickler konnten das Ticket quasi so vom Board nehmen und direkt mit der Implementierung loslegen. Und du weißt es selber.

Wenn man so fachlich arbeitet, dann ist der nicht da und hier gibt's eine Verzögerung und da kommt man nicht weiter. Also ja, das habe ich ein halbes Jahr gemacht, das war super anstrengend und ich denke, für das Entwicklungsteam war es sehr angenehm, wenn man sauber für geprüfte Tickets hingelegt bekommt.

Ja, das wahrscheinlich in der Umsetzung auch deutlich leichter.

Es gab weniger Kommunikation, weil ich ja viel Kommunikation vorher selber schon gemacht habe. Die Tickets waren alle sehr genau geschätzt und es stand technisch alles drin, was drinstehen musste, sodass man das wirklich einfach so runternehmen konnte. Das war jetzt also ich war eine Person, hab das an 3 4 Tagen die Woche gemacht und das Entwicklungsteam bestand aus 12 Entwicklern. Wenn ich mich recht entsinne, war schon eine Herausforderung, die immer versorgt zu haben, so dass ich quasi aufgeopfert für das Delikt.

Ich weiß nicht, ob ich den Finger gehoben hab und das gemacht hab, dass es irgendwie so gekommen. Und ein halbes Jahr wurde nach diesem Modell gearbeitet und danach wurde es glaube ich restrukturiert. Nicht weil es nicht funktioniert hätte, sondern weil zwei Abteilungen zusammengelegt wurden. Genau. Es gab dann zwei Entwicklungsteams. Vorher gab es ein großes Team, dann gab's zwei Teams. Ein Team hat die Fehler gefixt, also es Bugfix Team und das andere Team hat die Features gemacht.

So, und dann haben die zwischen den Teams immer wieder gewechselt, damit jeder mal alles macht. Und so ist das gekommen.

Und er hat auch schon mal ein Projekt, wo die Retrospektive nicht abwechslungsreich war.

Was heißt abwechselnd? Implizit wissen, dass alle die Probleme, aber es wird nochmal sichtbar gemacht und gesammelt und priorisiert. Da sehe ich den Wert drin, dass man halt sagt, wenn du die dritte bis zur Retrospektive machst und dann wird das gleiche Problem, was du davor und davor schon mal gesehen hast, nochmal angesprochen, dann hat man wirklich eine Thema damit und dann ist es auch hinreichend wichtig und es lohnt sich, das zu lösen. Manchmal hat man Themen, die sich dann einfach in Luft auflösen oder die mit einem Release gegessen sind oder so, aber man muss halt nur regelmäßig draufschauen.

Also meiner Erfahrung nach ist es irgendwann mal eine Qual, wenn wir jetzt sagen wir mal 1,8, da haste jedes Mal eine Maßnahme Retro Mac, dann kommt es ja gar nicht mehr hinterher mit den Maßnahmen. Irgendwann erfinden die Teilnehmer einfach irgendwas, weil die irgendwas sagen möchten. Deswegen rate ich jedem Coach und Scrum Master maximal jedes dritte Mal eine klassische Maßnamen retro zu machen. Warum? Aus dem Grund, dass die Maßnahmen ernster genommen werden. Auch weil eine Maßnahme nicht immer ein 1 Sprint passt.

Der Scrum Master des imParlament Board läuft parallel zum Sprint. Es ist schwierig, jede Maßnahme innerhalb eines Sprints zu lösen. Deswegen habe ich mein eigenes Board. Und wenn das Board leer ist, eine neue Maßnahme Retro oder alle drei Sprints, eine Maßnahme Retro, so ist die Retro auch meistens auch sehr beliebt bei Teilnehmern. Und ich prüfe dauert halt so lange, wie sie dauert. Was ist an dem Termin für Stakeholder? Manchmal mehr, manchmal weniger. Ich finde das ist noch das Angenehmste.

Einen Sprint Wechsel oder?

Kommt drauf an ich ob man Probleme hat was zu präsentieren oder nicht. Ich finde das total wichtig. Ich bereite mich da auch drauf vor, weil im Review also für die zu Hörer, die vielleicht nicht so firm sind mit Scrum. Da geht's ja darum, dass man das zeigt, was man in den letzten 2 Wochen bearbeitet hat und auch fertiggestellt hat. Also man zeigt die Arbeitsergebnisse des letzten Sprints. Und da finde ich es super wichtig, dass man sich da vorbereitet, um da einen guten Eindruck zu machen.

Auch da sitzen halt die Leute, die die Stakeholder, die letztlich die Projekte bezahlen. Und da glaube ich, ist es sehr, sehr wichtig, dass man zeigt, dass man auf einem guten Weg ist, dass man das Projekt ordentlich voran treibt und auch Probleme dann anspricht. Natürlich, ja, dass man dafür ein gutes Ergebnis zeigen kann, damit die Leute, die die Projekte finanzieren, sich auch gut fühlen und auch sehen, dass das ein sinnvolles Projekt ist.

Weil man will ja nur sinnvolle Projekte machen, sonst macht das ja alles keinen Sinn. Es gibt da drei wichtige Feedback Schleifen im Scrum das Daily, die Feedback Schleife unter dem Entwicklungsteam. Dann gibt es die Review, die Feedback Schleife von Mark bzw. der Kola und die retrospektive Feedback Schleife. Man reflektiert den vergangenen Sprint und sowohl in fachlicher als auch in zwischenmenschlicher Betrachtung. Die drei Feedback Schleifen machen agil auch so stark.

Wenn du nur eine Sache aus Scrum neben könntest, was würdest du tun? Was ist das aller Allerwichtigste? Ich hab was, das zeig ich dir gleich. Aber ich möchte erst. Ich möchte erst deine Meinung dazu hören.

Ja, also ich will mein Geld nicht wert. Wenn ich jetzt nicht folgenden Satz sagen würde Es funktioniert nur als Ganzes, wenn jemand sagt Ich will auf diesen Trend aufspringen, aber ich will das eigentlich gar nicht. Aber irgendwie sagen alle Ich muss das machen. Und jetzt eine Sache picke ich mir aus diesem Strauße heraus Was ist es? Ich glaube, was total wichtig ist, ist das Daily, also dass man morgens sagt, was man gestern getan hat und was man heute tun wird, weil das erzwingt noch ein bisschen mehr diese Selbstorganisation, dass man sich Gedanken macht, was ist was bei gestern wichtig oder Was hab ich gestern gemacht?

Was ist heute wichtig? Was wird heute wichtig? Welche Besprechung habe ich und das verbalisiert und dadurch in den Austausch mit dem Team geht. Und dann weißt du, jeder vom Team ach Key, der macht heute, dass der macht heute, dass der Macht sollte das und man hat so einen Überblick. Man glaubt manchmal, es ist eine Spielerei, aber ich halte das für absolut wichtig.

Es ist ein guter Punkt. Maurice Klar, wie du sagst, es Teddy ist wichtig. Warum ist das Teddy denn so gut? Ihr habt folgendes im Daily Ich hab das Artefakt Sprint Backlog. Ich schau drauf und spreche darüber, was geschehen ist. Ihr habt Scrum Master dabei, der im Pferdmenges aufnimmt, der moderiert, der dafür sorgt, dass die Zeit eingehalten wird. Am Ohr des Printing gäbe es dieses Sprint Backlog auch gar nicht. Was Ihr Produkt Owner, der der Frage und Antwort steht, also das Dadie alleine zu nutzen ist nicht agil sein.

Das Taja alleine zu nutzen ist ein Team Meeting. Ein tägliches und meiner Erfahrung nach ein Davie ohne Scrum Master ohne echtes agiles Arbeiten artet aus und es dauert länger als 15 Minuten.

Da ist die Scrum Polizei auf jeden Fall gefragt um den Raeder Anteil zu begrenzen.

Ich zeige da auch gerne mit dem Finger auf mich selber. Gibt es denn Werkzeuge, die man benötigt für den Umgang mit Scrum? Nur eben schon mal gesagt ok, so ein Ticket Board braucht man. Ob das jetzt virtuell ist, also in Form von Software um mal zwei Produkte zu nennen. Da gibt es Gira oder JIRA Masiar DevOps dieses Board, da gibt's auch 100 andere Tools, Redmayne und wie sie alle heißen. Das benötigt man sicher. Ich würde auch sagen Digitales am muss ich jetzt sagen.

Ich bin Softwareentwickler. Eine ruhig digitales Werkzeug. Was? Auch mit der KOD Versionierung verknüpft ist, also wenn man in Wien kom mitmach, dass es dann automatisch auch auf dem Board ankommt, finde ich super wichtig. Gibt's da noch weitere Softwarelösung oder Hardware Lösung?

Ich kann nur empfehlen, dass man ein digitales Board nimmt, welches das muss jeder für sich selbst entscheiden. Der Vorteil von digital ist Du kannst verteilt arbeiten. Das Nachhalten ist sehr leicht, was überall Transparenz von überall auf der Welt. Und du kannst sehr schnell reagieren. Ein Ticket ist digital auch schneller getippt als auf einen Klebezettel geschrieben. Und für welches Board du dich entscheidest, ist dir überlassen. Also Kira und Escher Delvaux Bots teilen sich den Markt aktuell, wobei Gira der Branchen Gigant ist.

Ich persönlich bin umgestiegen auf Aguirre DevOps Boards, aber nur Home Abdou dazubleiben und auszukurieren finde ich richtig gut. Adis Kannst du auch etwas nehmen wie Trello? Das ist was ganz Leichtfüßige, wo du einfach nur ein Board machen kannst und Tickets hin und her schieben kannst.

Ideal z.B. für Kanban und es gibt zahlreiche kostenlose Tools. Ich sage es nochmal Ich glaube ein digitales Board ist ganz wichtig, weil du kannst Attachments dran machen. Du kannst da wild rum schieben und im Pfanne BIFIE kann jeder darauf zugreifen und muss nicht ins Büro fahren. Also es ist ja auch ein Punkt, der in den letzten anderthalb Jahren deutlich an Gewicht gewonnen hat. Hast du eine besonders positive oder negative Erfahrungen gemacht in deiner beruflichen Laufbahn? Beim Thema Scrum hast du Firmen gesehen, die das wirklich besonders toll gemacht haben, besonders guten Effekt erzielt haben oder die auch einen sehr großen Turnaround geschafft haben, also die sehr klassisch da entwickelt haben und dann sehr schnell das Scrum Modell adaptieren konnten oder auch Beispiele, wo es nicht geklappt hat.

Worauf ich sehr stolz bin. Maurice ist die Arbeit bei der Deutschen Bahn und wir haben damals was der DB Navigator der Alte, der wurde auf agil umgestellt. Die Bewertung im AppStore und Playstore waren grausam und dort hat es tatsächlich jemand geschafft agil einzuführen bei der ALD gestandenen Bahn. Es wurde tatsächlich auch echte Agilität erreicht. Es hat lange gedauert zu sagen, es hat zwei bis drei Jahre gedauert, bis man sagen konnte, es ist ein gutes Produkt und innerhalb dieser Zeit wurde aus einem Entwicklerteam sechs Entwicklerteams.

Es wurde vernünftig skaliert. Es wurde You Xie sein eingeführt. Es wurden die Rollen wurden besetzt. Man hatte echte Entscheidungsmacht, als fordert einer der Scrum Master war ein ausgebildeter Scrum Master, der echte Agilität gefördert. Die Entwicklungsteams hatten Handlungsfreiheit, die konnten sich sogar selbst einfach mal eine Couch kaufen und ins Büro stellen. Und die Deutsche Bahn hat aus dem alten DB Navigator ein unglaublich gute App gemacht mit agilen Methoden. Man mag es kaum glauben, aber in manche Stationen von dem Konzern, wo ich war, ist die Bahn die mit Abstand agile Software Manufaktur geworden.

Bei anderen Unternehmen. Ich war viel bei Energieversorgern, bei Energieversorgern, was recht schwierig bis zum aktuellen Projekt aktuell trägt, bin ich wieder eher beim Energieversorger. Und dort läuft es recht gut, weil man da auch die richtigen Leute auf den Führungspositionen hat. Die scheiden, ob es erfolgreich wird oder nicht. Hast du nicht die richtigen Leute in der Führung? Dann wird es funktionieren. Bei anderen Energieversorgern war es in der Führung eher so ein Experiment, was Geld kostet und weniger eine Befreiung für unsere Services.

Und da kommen wir wieder darauf zurück, was wir den Mythen des Podcasts gedacht haben. Das Management muss daran glauben, sonst funktioniert das nicht. Ich hab auch mal ein Blog-Beitrag schrieben neue Gründe, warum Scrum in Führung scheitern. Drei Punkte oder vier Punkte wiederholen sich da und die besagen so etwas wie Unterschätzung der Veränderung der Filmkultur mit was nicht perfekte Mann den Markt geben, das Proben und dann iterativ weiterzugehen, das ist. Dem Amerikaner liegt das wesentlich mehr glaube ich, als dem Europäer.

Aber gut, man kann es erlernen und uns da verbessern, wenn man sich mit dem Thema Scrum beschäftigen möchte. Ein Buchtipp für unsere Zuhörer oder auch mehrere.

Wichtig wäre es, den Scrum Guide zu kennen. Kostenloses Buch, was man mit Konga in Suchmaschinen Eingabe sofort findet. Gut ist auch mein Buch, das heißt was Scrum. Dort hab ich mit Bildern und wenig Text geschildert, was Scrum ist und wie Scrum funktionieren kann. Allerdings ich persönlich lese weniger was Scrum, sondern ich lese aktuell viel mehr über Produktentwicklung. z.B. Kann ich inspired empfehlen von Marty Kerrigan eine Product Bibel, wie man vernünftige Produkte, gute Produkte entwickelt, wenn man das Buch gelesen hat.

Da geht es sehr viel um iterativ inkrementelle Vorgehen und um agil und wie man gute Produkte macht.

Okay, super.

Das packe ich dann in die Shownotes zu dieser Episode rein. Wenn ich mich als Scrum Coach oder Scrum Master ausbilden lassen möchte. Wo würde ich dann idealerweise hingehen?

Was ich empfehlen würde, ist eine der offiziellen Zertifizierung zu machen. Sei es ist Scrum Alliance oder Scrum org. Ich habe beides. Dort kann man auch unterschiedliche Stufen durchlaufen. Einfach auf eine der Seiten gehen, unter Schulungs Angebot durchsuchen. Es gibt sehr viele Schulungen, auch deutschlandweit. Das ist dann die klassische PSM Professional Scrum Master Zertifizierung. Oder bei Scrum alleine heißt es die Faiz Scrum Master. Eine dieser beiden Stationen die übrigen. Die gehört dem Sutherland, die andere dem Schwager, sollte man besuchen.

Eine dieser beiden Zertifikate sollte man dann haben, bei agil zu kommen, sagt man, es ist leicht zu verstehen und schwierig zu meistern. Eine Schulung zu besuchen heißt Ich habe es verstanden. Vielleicht. Es muss sich alles noch beweisen. Es basiert auf Empirie, sammeln, Erfahrung. Am besten sucht sie ein Umfeld, in dem du Erfahrungen sammeln darfst. Indem man Fehler machen darf. Indem man wachsen kann. Und wenn du dich interessierst und in agil verliebt, dann bleib dran.

Die Nachfrage ist gigantisch. Und als Grom Masiar Pollard Oona hat man sehr gute Chancen im Software Markt.

Okay, dann ich als Entwickler, sondern als Scrum Master. Aber du sagst lass dich bei den quasi offiziellen Scrum Erfindern zertifizieren. Das erhöht wahrscheinlich die Glaubwürdigkeit und das ist wahrscheinlich auch eine gute Ausbildung. Könnte ich mir vorstellen. Die haben das ja auch schon hunderttausendmal iterativ durchgezogen.

Ganz genau. Und die Zertifizierung sind akzeptiert. Das ist halt das Wichtigste.

Ok, super.

Gerne erzähle ich nochmal kurz was zu uns. Wir bieten zwar keine Schulung an, allerdings sind wir deutschlandweit als Berater unterwegs. Wir organisieren große und kleine Unternehmen und begleitet Teams als Scrum Master. Einfach auf Scrum, Corpus, GTE und Kontakt klicken und schon kann man uns auch anfragen.

Super! Ich verlinke euch bzw. eure Website auch in den Shownotes Vienna. Wenn unsere Zuhörer Fragen haben oder Feedback zur aktuellen Episode, sendet uns gerne eine E-Mail an Podcasts skillbyte. Wir freuen uns immer über Bewertungen und natürlich, wenn ihr unseren Podcast abonniert an Freunde und Kollegen weiter empfehlt, schaut auch auf Skillbyte Slash Blog vorbei für weitere spannende Technologie Themen Hannes. Ich möchte mich ganz herzlich bei dir bedanken und wünsche dir noch einen schönen Abend, die auch als Armory soll.

Vielen Dank nochmal, dass ihr mich eingeladen habt.