Was sind die Unterschiede zwischen Projektleiter und ScrumMaster?

Jasmine: Herzlich willkommen zum Agile Growth Podcast ich freue mich heute mal wieder eine solo Folge für dich zu haben von Kai und mir und zwar diskutieren wir das Thema Projektleiter

versus Scrum Master, was sind denn da die Unterschiede? Eine Frage, die immer wieder an uns herangetragen wird und ich wünsche dir ganz viel Spaß damit.

Sprecher: Herzlich willkommen zum Agile Growth Podcast, den Podcast für alle Agile-Interessierten mit hilfreichen Ideen,

und erprobten Werkzeugen, die dich weiterbringen. Von und mit den zwei Agilists.

Kai: Herzlich willkommen zu einer neuen Folge vom Agile Growth Podcast,

das ist ja eine Weile her dass wir hinter dem Mikrofon standen in letzter Zeit waren wir relativ häufig live online auf LinkedIn und auf YouTube.

Und jetzt machen wir da eine Pause und gehen hier wieder an unserem Podcast ran wenn wir haben gemerkt.

Ja Podcasten ist schon was wo unser Herz irgendwie für schlägt das macht uns Spaß hinter dem Mikrofon zu stehen und ich muss dann auch nicht immer irgendwie mich noch rasieren vorher, also.

Nein aber es ist schon glaube ich mehr unser Format und das war jetzt total schön um Leuten zu begegnen ich will doch gar nicht sein dass wir das nicht wieder tun werden aber für den Moment sind wir jetzt wieder hier auf dem Podcast Format insofern wenn du unter Podcast schon länger hörst willkommen zurück.

Dass wir wieder hier hinter dem Mikro stehen und wenn du gerade neu im Podcast rein tunest, dann lernst du uns quasi erstmal auf der Tonspur kennen.

Und falls du möchtest gibt’s auch noch die ganzen Aufzeichnungen vom Agile Growth Cast, unsererm Videoformat auf agilegrowth.de zum Angucken viele spannende Experteninterviews rund um Agilität,

Jasmine: Und wir werden natürlich auch alle

Folgen die wir aufgenommen haben zu Podcasts verarbeiten weil da immer das Feedback von euch bekommen haben das gewisse von euch viel lieber zugucken andere hören einfach lieber weil sie beim Joggen oder Fahrradfahren oder wo auch immer den Podcast hören und

deswegen wirds auch alle Growthcast Folgen als alle Livecast folgen noch als Podcast geben

Nichtsdestotrotz freuen wir uns,

hier mal wieder eine inhaltliche Folge für dich zu machen wo es kein Interview ist sondern wo Kai

und ich uns einfach noch mal die Köpfe zusammengesteckt haben und dann Thema auf gearbeitet haben das jetzt auch schon von vielen Leuten erfragt wurde

Bevor wir Einsteigen in was ist denn eigentlich der Unterschied zwischen so einem Projektmanager

und einem Scrum Master, vielleicht noch so ein ganz kleines Update von unserer Seite wir Haltens extrem kurz es ist doch relativ viel passiert bei uns unser Buch wird diese Woche

auf Amazon verfügbar sein und da freue ich mich ganz ganz dolle drüber das war jetzt echt.

Ein Projekt das jetzt ein bisschen über ein Jahr gedauert hat und jetzt ist es da

vor einer Woche hatten haben wir das erste Exemplar in unseren Händen gehalten das heißt wenn du dich dafür interessierst wie

Scrum Trainings zu geben wie du aber auch vielleicht Trainingselemente in deine Workshops einbauen kannst um so einfach als Coach oder Scrum Master noch mal mehr Wirkung zu entfalten, dann ist das dein Buch.

Wir erklären sowohl unser Trainingskonzept wir aber auch ganz ganz viele Hintergründe zum Trainer sein und wir freuen uns da total auf Feedback,

Kai: Genau das kriegst du überall im Buchhandel ist ein ganz normales Buch überall bestellbar also bei der Quelle wo du

gerne möchtest und da kannst du dann wirklich noch ein bisschen unseren Kopf rein schauen was du hier in der Podcast Folge vielleicht auch schon mal öfters tust wie wir über Sachen im bezug auf Agilität nachdenken da ganz spezifisch im Bezug auf die Trainer Facette

und wir sind ja nicht unbedingt gut in die Liste an Podcasts die wir so haben dann auch abzuarbeiten

bzw uns fallen immer wieder neue Themen ein und dann geraten andere ins Hintertreffen aber werden bestimmt noch mal einen Podcast zum zu der Trainer Facette machen und auch zu dem Buch an und für sich bzw einfach ein bisschen inhaltlich da einsteigen.

Kai: Genau das haben wir also vor regelmäßig wieder Podcasten und dazu haben uns auch ein bisschen Hilfe geholt denn wir haben unseren ersten Mitarbeiter eingestellt, yaay, Michael der das gerade auch hört und hier auch schneiden wird, herzlich willkommen bei uns im Team auch noch mal an dieser Stelle,  insofern freuen wir uns

da auch Unterstützung zu haben damit du als unser Hörer regelmäßig erstmal mitbekommst dass wir neue Podcasts haben und auch,

entsprechen Schnitt genießen kannst dass wir die ganzen Outtakes und Versprecher ja rausnehmen dass wäre mittlerweile wahrscheinlich auch schon ne  ganze Folge die wir dazu veröffentlichen könnten.

Ja ansonsten sind wir ganz ganz viel unterwegs eher im Leadership Coaching im Moment das macht unglaublich viel Spaß wir.

Dürfen eine ganze Abteilung dabei begleiten agiler zu werden von einem sehr sehr klassischen Unternehmen das macht unglaublich viel Spaß und wir geben ganz viele Trainings im Moment vor allem Inhouse Trainings

weniger öffentliche Trainings

das ist auch cool und daher kommt auch die Frage vom heutigen Podcast

Kai: Genau, da sitzen nämlich ganz häufig unter den ganzen anderen Teilnehmern Projektleiter drin.

In den Seminaren und stellen die Frage ja also A, was ist überhaupt anders mit diesem Scrum ist das einfach so ein Projektleitungs-Ansatz und B, was heißt das denn für mich jetzt eigentlich.

Jasmine: Und manchmal sind wir ja auch in so Trainings unterwegs wenn die inhouse sind die irgendwie.

Anführungszeichen falsche Titel tragen wie sowas die Projektmanagement-Methode Scrum.

Da setzen wir dann schon direkt an: Scrum ist keine P rojektmanagementmethode.

Es ist nicht dafür gedacht und das ist so der große Dreher im Kopf der bei mir auch

ehrlich gesagt relativ lange gebraucht hat bis ich das für mich so hingekriegt habe was ist denn der Unterschied zwischen dem Projekt und einem Produkt, weil Scrum ist

designed um Produkte zu entwickeln Produkte in einer komplexen Domäne

also das heißt wenn ich nicht in einer komplexen Domäne unterwegs bin sondern in der einfachen und komplizierten, dann ist Scrum vielleicht nicht ganz so geil oder fühlt sich nicht so geil an und wenn ich

ein reines Projektgeschäft habe auch da werde ich Scrum, wenn ich’s denn anwenden möchte verbiegen müssen

oder meine eigenen Lösungen finden müssen weil es ist ein Framework zur Produktentwicklung.

Kai: Ja n Projekt ist jetzt erstmal was, was zeitlich limitiert ist und einmalig.

Also da gibt’s ne gewisse Grenze zu dem soll n Meilenstein erreicht werden vielleicht eine Auslieferung.

Und das ist so einzigartig dass man das jetzt auch nicht ständig wiederholt und ein Produkt ist ja eigentlich so dass das

Naja die Produktentwicklung endet im Idealfall nie wenn es ein erfolgreiches Produkt ist

das Produkt muss ja auch mal wieder gewartet werden und angepasst an die Rahmenbedingungen im Markt, die sich ändern oder ein Kundenfeedback und eigentlich willst du dass dein Product Backlog also die Liste der Dinge die  im Produkt drin sind gar nicht leer werden.

Das ist eher auf Dauer angelegt

Wenn du das nicht einstampfen willst, das Produkt und so unterscheiden sich ja schon ein bisschen die Herangehensweisen während du bei einem Projekt dann eher denkst ok das gibt jetzt irgendwie für anderthalb Jahre und da sind die und die Leute daran beteiligt eine ersten Phase und dann später brauchen wir in die und dann kann man das halt in die ausrollen und das ist fertig.

Ist die Produkt denke dann vielmehr es gibt etwas was einen konkreten Wert liefert

für einen Stamm von Anwendern also ich glaube Produkte die kennen wir ja alle aus dem täglichen Leben ne du kaufst du irgendwie ein Smartphone oder du fährst ein Auto das sind ja alles Produkte die.

Gewisse Bedürfnisse befriedigen auf verschiedenen Ebenen und ein Projekt hat dass er so diesen.

Charakter wie man etwas organisiert nämlich in so einem gewissen Rahmen von Zeit und Geld und Umfang der daran stattfinden soll insofern ist das oft eine erste Veränderungen,

die durch agiles Arbeiten anfängt nehme ich wegzugehen vom Projektbegriff wo du eigentlich ja eher Menschen.

Zu Projekten bringst hin zur Produktentwicklung wo du naja, man könnte fast sagen Projekte oder Anforderungen zu festen Teams bringst.

Also Produktentwicklung Teams die dann da existieren das ist erstmal ein ganz anderes Paradigma.

Wo natürlich in Unternehmen die eher klassisch unterwegs und dann auch auf die Frage kommt naja wir haben jetzt aber so Multiprojektmanagement also ich bin irgendwie zu 10% da drin und 30% da drin und so weiter wie geht denn das überhaupt mit Scrum.

Wo dann die bittere Pille erstmal ist, oh.

Da müssten wir uns ja anders strukturell aufstellen wenn jetzt wirklich feste Team von Menschen die ganze Zeit zusammenarbeiten sollen und wir nicht mehr die Leute auf verschiedene Projekte verteilen,

sondern die Projekte einsammeln und die Arbeiten im Strom zusammenfassen auf ein festes bestehendes Team,

und  das ist erst so der erste Paradigmen shift der dahinter steht deswegen man naja Projektmanagement und Produktentwicklung ist ein bisschen wie Äpfel mit Birnen vergleichen finde ich aus der Perspektive heraus.

Und das wirkt sich natürlich auch aus auf die Rolle des Projekt Leiters und des Scrum Masters.

Jasmine: Und das ist vielleicht auch an der Stelle oder eine der Stelle wo viele kommen und sagen jetzt ist erstmal Mindset, weil das was wir im Kopf uns umdrehen ist es geht nicht mehr darum dass jeder Mensch zu jeder Zeit.

Fleißig und beschäftigt ist was wir ja machen wenn wir.

Menschen auf Projekte aufteilen wir gucken dass wir eine optimale Auslastung haben sondern wir drehen uns um und sagen ja eigentlich ist mir egal ob alle beschäftigt sind ich will halt einfach das geile Produkte hinten rauskommen,

und diese Verantwortung dass geile Produkte hinten rauskommen die hat der Product Owner, das heißt.

Der Product Owner ist verantwortlich Sascha Gessler ein Co-Trainer von mir sagt immer davor der Product Owner hat

Arsch in der Hose und Geld in der Tasche, der ist dafür verantwortlich dass diese Anforderungen auch.

So strukturiert sind damit sie den Markt entsprechendend, dem Stakeholder entsprechend dem Kunden entsprechend gewisse Risiken abdecken etc da ist ganz ganz viel drin.

Aber vor allem dass sie am Ende ein gutes und wirtschaftliches Produkt hinten abwerfen.

Kai: Aha, da ist also noch eine weitere Rolle dabei also der Scrum Master

Und ein Product Owner und das teilt sich auch noch auf also der Product Owner mit dieser fachlichen Entscheidung und fachlichen Perspektive da drin und der Scrum Master, der managed der auch noch dann irgendwie was und was dieses.

Was ist was der Manager ich glaub da haben wir schon in einer Podcast Folge bisschen tiefer drüber gesprochen aber er ist anscheinend der auch schon so eine von Scheideweg als wenn ich es als Projektleiter in so einem Scrum Umfeld bin dann müsste ich mir irgendwie die Frage stellen hm.

Bin ich jetzt eher so fachlich zugewandt also liebe so dieses Scope  Management und mit den Stakeholdern arbeiten daran dass das richtige entsteht oder mache ich hier den IT Sozialarbeiter sagt man ja manchmal dazu.

Viele Grüße an Andy Schlief von dem ich das Wort mal geklaut hab und kümmere mich drum dass das menschliche System eben gut zusammen arbeitet.

Das ist dann auch schon so eine Frage die Richtung Karriereschritt und Entwicklung geht die dann auch ganz übeles Spannungsfeld manchmal enthält, wenn ich selber z.b.

Vom Kunden her als Projektleiter wahrgenommen werde und das auch unter meiner E-Mail Signatur steht aber ich dann irgendwie angesprochen werde wie sieht’s denn aus

mit eurem Projekt also Produkt im Scrum Sinne und da muss ich erst mal überlegen ja antworte ich bin jetzt in Scrum Master und antworte in bezug auf hey dann wende dich doch an den Product Owner oder bin ich jetzt der Product Owner der die Frage direkt beantworten kann

Jasmine: Und so als ganz klassischer Projektleiter und an der Stelle noch ein großer disclaimer in unserer Erfahrung mit vielen Kunden

es gibt nicht den einen Projektleiter oder einen Projektmanager

das ist in ganz vielen Firmen ganz unterschiedlich gelebt von daher wenn da die eine oder andere Sache dabei ist die wir jetzt ansprechen die du sagst ne tue ich doch gar nicht oder tut ein Projektleiter bei uns nicht ich kann.

Es gibt so ganz verschiedene Facetten davon aber was die meisten so.

Innehaben ist dass die Verantwortung ist ein Projekt in Zeit.

In scope und in Budget fertig zu bekommen das heißt ich habe eine fixe Zeit wo irgendwas raus muss und das muss im Budget bleiben und das kontrolliere ich als Projektleiter, dafür stehe ich was wäre natürlich bei Scrum,

umgedreht haben Der Scope der ist grundsätzlich ja variabel aber da ist der Product Owner verantwortlich für.

Und der Scrum Master hat eine gewisse Mitverantwortung weil als Scrum Master bin ich ja verantwortlich für die Produktivitätssteigerung des Teams,

das heißt ich kann das nicht unbedingt alleine machen aber ich kann mit training kommunikationsverbesserung Teamentwicklung Methoden.

Lernen etcetera dazu beitragen oder auch einfach Hindernisse aus dem Weg räumen in meinem Team.

Dazu beitragen dass das Team schneller wird.

Und mehr amscope abarbeiten das heißt da habe ich eine gewisse Mitverantwortung aber nicht Mitverantwortung an dem Scope an und für sich sondern einfach nur damit wir den abgearbeitet bekommen

Als Team. jetzt das Budget,

dazu sagt der Scrum Guide herzlich wenig aber dadurch dass wir ja fixe Iterationen haben und auch versuchen die Teams möglichst fix zu behalten.

Ist das Budget relativ gut planbar,

wir können planen wie viel Geld wir pro Iteration ausgeben und dadurch hat sich das mit dem in Budget auch irgendwie relativ schnell ergeben

Kai: Ja mit Scrum liefern wir  immer pünktlich die Frage ist nur was.

Das ist immer der Kahlhauer im Training sozusagen und es hat sich ein bisschen provokant und erstelle aber die Mechanismen sind da wirklich ein bisschen andere und ich höre öfter.

Gerade erfahrene Projektleiter, dass sie am Anfang zum ersten Drittel von der Schulung meistens sagen so, ja das sind doch Dinge die haben wir immer schon gemacht.

Und auch wie ich die Leute einspanne im Selbstmanagements zum Beispiel die aktualisieren bei mir im Projektfortschritt planen die Sachen selber.

Also ich frage die Leute ne, wie weit bist du und dann tragen wir es selber ein also ich meine das gar nicht irgendwie so von außen so dann lassen mir dann immer die aktuellen Sachen rein tun und kann das dann nach außen irgendwie vertreten und habe ein Gefühl dafür oder

bemühe ganz viel die Intelligenz des Teams, das sind alles

Super gute Sachen und ich glaube auch in der komplexen Umfeld kann auch Projektleitung nicht um solche Dinge auskommen das Ding ist einfach dass ich das hier halt bisschen aufteilt auf verschiedene.

Verantwortlichkeiten im Scrum Umfeld.

Das heißt da ist nicht mehr eine Person für verantwortlich die Dinge zu managen sollen wir Jasmin gerade richtig gesagt hat das verteilt sich dann halt eben auf Product Owner und auch noch aufs Entwicklungsteam weil die sollen ja selbst gemanagt sein.

Das heißt so die Zuweisung von Arbeit.

Die eigener Fortschrittskontrolle könnte man sagen die da auf täglicher Basis passiert machen die Leute für sich selbst und auch die Ergebnisverantwortung an dieser Stelle.

Liegt da nicht beim Scrum Master sondern er unterstützt eben dabei dass die anderen.

Gut miteinander diese Ergebnisse erbringen die sie einbringen wollen hat das mit Zukunft Division Produkt auch noch entsprechend dann auch geliefert wird.

Und geliefert werden möchte vor allen Dingen durch die Rahmenbedingungen dass man Bock drauf hat und das kann man ihn unterstützen durch ein besseren Kontakt z.b. zur Vision und so weiter.

Jasmine: Und warum ist diese Ergebniserwartung auch.

Z.b. bei dem Entwicklungsteam also dass der der Report wenn man denn überhaupt ein Fortschritt reportet aber

die Aufzeichnung des Fortschritts im Hinblick auf

den Sprint und das Sprint Zie warum machen das die Entwickler selber und nicht irgendjemand für Sie oder warum ist da nicht irgendjemand für sie verantwortlich weil wir die Verantwortung dahin bringen wo auch die Expertise liegt.

Es ist ein völlig anderes Gefühl von

ja ich trage da meine Sachen selber rein aber der Projektleiter ist ja schon verantwortlich, dass er das überall hin kommuniziert zu ich trage die Sachen da selber rein.

Weil das für mich selber Sinn macht.

Weil wir im Daily drüber reden wo wir stehen und wenn wir da keine Transparenz haben können wir uns nicht die richtigen Fragen in Hinblick auf der Sprint Ziel und unsere Hindernisse stellen können die auch nicht aus dem Weg räumen und deswegen erreichen wir vielleicht unsere Sprint Ziel nicht das heißt

wir machen die Dinge die Sinn machen und wir schieben die Verantwortung dahin wo auch wirklich die Expertise liegt.

Kai: Damit wollen wir jetzt nicht sagen dass du keine Expertise hast als Projektleiter wenn du grad zuhörst, das ist dir ja selber klar du hast wahrscheinlich ganz viele Skills du hast Fähigkeit mit Menschen in Kontakt zu treten du kannst vielleicht auch die Fachdomäne total in und auswendig.

Vielleicht hast du auch mal selber entwickelt das ist alles fein das verteilt sich einfach eben auf mehrere Schultern in diesem Rahmenwerk und macht jetz aus unserer Erfahrung eben bisschen robuster.

Aber stell Dich eben vor diese Fragestellungen was machst du gerne denn.

Ja man kann diese Rollen sehr schlechten mischen die haben halt eben verschiedene Spannung, das ist eigentlich so ein Spannungsfeld.

In verschiedene Richtungen und wenn man da eine Doppelrolle einnimmt, Zebra sind dass unser Trainer Kollege Björn Jensen ganz gerne diese Mischwesen die haben halt ein paar Implikation die sind nicht so richtig günstig. Mit dem gesagt verteilt sich natürlich auch das Risikomanagement.

Jasmine: Das heißt um dieses Thema Fortschritt ganz kurz abzuschließen – wer ist verantwortlich

für das Berichten des Fortschritts? Alles was im Sprint passiert im Hinblick auf das Sprint Ziel ist das Entwicklungsteam selber insbesondere für sich selber weil sie haben ja eine intrinsische Motivation ihr Sprint Ziel zu erreichen

und alles was in Hinblick auf das Produkt ist liegt beim Product Owner meistens machen wir das im review

jeder der sehen will kann zum Review kommen und dann ergibt sich da auch irgendwie dass ich noch irgendwohin rapportiere , vielleicht braucht das meine Firma trotzdem dann macht das klassischerweise der Product Owner. Der Scrum Master würde das nicht unbedingt machen als Scrum Master bin ich eher dafür verantwortlich dass ich den anderen Methoden und Tools an die Hand gebe wo sie das einfach machen können ohne dass es für sie zu viel Overhead  bedeutet.

Kai: Wenn man jetzt auf den Risiko Aspekt drauf schaut.

Dann hat man ja bei so einer Produktentwicklung zum Beispiel ein geschäftliches Risiko also ich baue nicht das was der Markt braucht ich habe einen Termin, ein Kostenrisiko dass mir das einfach, ja, von den Ressourcen her zerfließt ich habe ein soziales Risiko, also ob die Leute das zusammen bauen können und ich habe Machbarkeit Risiko ob das überhaupt technisch geht.

Und wenn man sich mal anschaut wie diese Risiken verteilt sind also das Risikomanagement dann haben wir auch da schon wieder ja die Axt angesetzt denn das haben wir auch zerlegt denn das Geschäftliche Risiko und auch das.

Zeit und Kostenrisiko, das liegt in Scrum beim Product Owner und das soziale Risiko.

Klar beim IT Sozialarbeiter also beim  Scrum Master und das Machbarkeits Risiko beim Entwicklungsteam selber und damit teilt sich eben auch,

das Risikomanagement in so nem Scrum Rahmenwerk auf auf verschiedene Facetten und liegt jetzt nicht bei einer Einzelperson.

Jasmine: In unserer Erfahrung wird das dadurch auch robuster weil es dann nicht nur an einer Person hängt sondern weil alle Kollektiv ihre Intelligenz da reinbringen.

Nicht desto trotz ist das manchmal relativ schwierig weil man muss ja die verschiedenen Aspekte zusammenbringen das heißt es braucht ein hohes Maß an Kommunikation und auch an Transparenz

Dafür ist wiederum der Scrummaster verantwortlich. Also wie du siehst –

Viele Dinge die jetzt so in klassischem  Projektmanagement beim klassischen Projektleiter liegen wurden einfach zerteilt das heißt das Rad wird nicht unbedingt neu erfunden sondern es wurden nur die Dinge genommen.

Die immer schon gut funktioniert haben

und auf die Expertisen verteilt wo die Information auch liegt damit wir nicht unbedingt Overhead oder Rapportierrungs-Geschichten oder, Command und Control Zyklen irgendwo rein bauen wo sie nicht sein müssen. Und der Product Owner

ist verantwortlich für die Wirtschaftlichkeit, dadurch auch für das ganze Stakeholdermanagement

et cetera und ganz oft auch fürs Budget weil die Wirtschaftlichkeit ist natürlich im Budget drin wenn ich für ein Produkt,

ewig lange brauche und das am Markt sowieso nicht gut ankommt bzw das ganz geringen return und Invest hat dann sollte das bitte der Product Owner möglichst früh merken oder möglichst schnell merken damit wir auch abbrechen können.

Wenn es keinen Sinn macht oder wenn der Product Owner merkt, hm, das Produkt ist eigentlich jetzt schon relativ reif.

Geplant haben wir eigentlich noch weiter zu machen aber das braucht hier niemand mehr –  dann sollte der Product Owner auch merken okay.

Dann wenden wir uns einem neuen Produkt zu einem anderen Produkt zu weil hier ist die Wertschöpfung erreicht die wir bringen wollen.

Das Entwicklungsteam ist für die ganze Technik verantwortlich, für die Machbarkeit verantwortlich und auch für.

Die effektive Arbeit am Backlog dann verantwortlich also dass die Backlog Einträge in Features gegossen werden

Und als Scrum Master guck ich eher auf die menschliche Seite auf die Zusammenarbeit auf die Kommunikation, damit dass wir schneller werden dass wir Hindernisse aus dem Weg räumen aber auch um.

Auf unsere Umwelt drumherum

also vielleicht muss die sich auch anpassen, ganz viele Teams die anfangen mit Scrum zu entwickeln aber auch mit Kanban, die anfangen agil zu entwickeln

die brauchen andere Dinge von ihrer Umwelt , die brauchen andere Kommunikation und vielleicht auch andere Freiheitsgrade auch darum kümmert sich das Scrum Master.

Und zudem bringe ich dem Team

öfters auch dem Product Owner Methoden und Tools bei wie sie ihre Arbeit einfacher gestalten, das heißt wenn ich ganz ganz lange

Projektleiter war und viele Methoden und Tools an der Hand habe und eigentlich gerne diese weitergebe statt sie zu betreiben ist die Scrum Master Rollen ne unglaublich gute Rolle für mich.

Kai: Also wenn du jetzt klassisches Projektmanagement gewöhnt bist dann gibt es sicherlich einen ganzen Blumenstrauß von Dingen die kannst du mitnehmen entweder in die Product Owner oder in die Scrum Master Rolle, die Entwickler Rolle für ich es nicht explizit noch mal auf weil das meistens nicht so der Pfad dann ist den die meisten Projektleiter gehen.

Mit dem gesagt , es gibt aber auch Sachen die sind anders also oft.

Habe ich jetzt erlebt in den Workshops dass Leute am Anfang sagen ja das machen wir alles seit 20 Jahren irgendwie so und ein erfahrener Projektleiter das immer so gemacht und am Ende nach 2-3 Tagen Seminar dann sagen oh,

Das ist ja doch ein bisschen anders und das hat meistens was damit zu tun dass das agile Manifest dahinter steht und sich darum mittlerweile einfach einen Berg an Wissen geschart hat und.

Arten und Weisen wie man Dinge tut.

Die ja doch recht umfangreich sind und eben agiles Product Management und agile Produktentwicklung optimal unterstützen.

Und da gibt’s dann schon eine ganze Menge zu lernen nicht erschrecken falls es neu für dich ist das Thema

das hat hat uns alle irgendwie ein paar Jahre beschäftigt sich dadurch zu fräsen Mann kommt aber am Start ganz gut weg mit ein paar Einstiegs Werken an Literatur und der ein oder anderen Podcast Empfehlung kommt man da schon erstmal durch.

Ich glaube was das radikalste ist für die meisten Teilnehmer ist diese Umdenke von es geht nicht mehr darum alle Wünsche zu erfüllen und das möglichst schnell,

sondern es geht darum

das zu tun was am sinnvollsten und am wirtschaftlichsten ist was heißt dass wir ganz ganz viel anfangen nein zu sagen und das ist für viele die in den Kursen sind extrem radikal.

Weil wir gewöhnt sind ja zu sagen und es möglichst hinzukriegen und das versuchen wir nicht mehr wenn wir Scrum machen sondern wir gucken,

ja was macht denn Sinn was will denn der User da draußen und wer zahlt für was was.

Und wir haben auch schon bei Kunden gesehen dass man Prototypen geplant hat und eigentlich nur so einen Durchstich machen wollte durchs System und das dann seinen Kunden gezeigt hat und der so begeistert war das was direkt in Produktion genommen hat im Sinne von so ey das ist eigentlich total wertvoll schon, können wir das nicht haben,

und das ist natürlich tol für die Motivation der Menschen wenn die auf einmal merken wow, das wird auch direkt gebraucht und ich muss jetzt nicht anderthalb Jahre warten bis der Rollout geplant ist sondern man hat direkt diesen Connect zwischen Entwicklern und Kunden an der Stelle und auch ein Unternehmer freut sich wenn er dann sein eingesetztes Kapital ein bisschen früher zu einer Leistung entsprechend bewegen kann und der Kunde,

ja das Prordukt nutzen kann.

Jasmine: Und damit sind wir auch am Ende mit unserem Rundumschlag was ist denn der Unterschied zwischen einem Projektleiter und einem Scrum-Master das ist wahrscheinlich nicht vollständig aber für uns so die Hauptaspekte

die wir da drin sehen und wir hoffen wir haben dir dadurch ein bisschen Orientierung geben können.

Genau, und wir diskutieren das auch super gerne mit Dir mal so einen mehrtägigen Workshop, ja haben ja verschiedene Angebote hier wenn möchtest oder.

In einer Kurzberatung 15 Minuten, kannst du gern kostenfrei bei uns einbuchen, dann.

Können wir gerne mal über deine Situation sprechen wie das da aussieht und ob so was wie Scrum oder Agilität da Sinn machen könnte,

Freuen uns sehr drauf und ansonsten wünschen wir dir eine sehr sehr gute Woche und bis bald.