Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html
In dem Unternemen, für das ich zuletzt gearbeitet habe, wurde Scrum dafür vergewaltigt, dem mittleren Managment einen Deckmantel gegenüber der Konzernspitze zu liefern, die eigene Inkompetenz zu vertuschen und Wolkenkuckucksheime zu malen. Jeder Versuch, über mehrere Jahre, von verschiedener Seite, mit unterschiedlichen Ansätzen, daran etwas zu ändern, wurde jeweils recht schnell abgewehrt und mit stärkeren Daumenschrauben beantwortet. Nachdem ich mich dann ein Weile umgeschaut hatte, was in anderen Unternehmen und Projekten los ist, hab ich beschlossen, den Weg als Anwendungsentwickler, dem ich mittlerweile über 30 Jahre gefolgt war, zu verlassen, weil ich den Eindruck gewonnen habe, dass das Unternehmen, für das ich tätig war, kein Sonderfall ist. Der Anfang dieses Videos hier bestätigt das nochmal. Ich werde mich nun mehr in Richtung Hardware, Embedded Systems und Prototypenbau orientieren. Dazu habe ich angefangen Computer Engineering zu studieren. Und siehe da, ein paar der Väter der Kommilitonen, erzählen am Familientisch offenbar die gleichen Geschichten, die ich den Jungs in der Mensa erzähle und ein paar davon haben ihre Jobs ebenfalls an den Nagel gehängt und fangen auf ihre alten Tage an auch nochmal zu studieren. Der Vorteil an der Software/IT-Branche ist ja, dass man damit auch Rücklagen bilden konnte, die einem dann im Alter nochmal Spielräume eröffnen. Mein Fazit: Niemand sollte verzagen, sondern diesen inkompetenten Spinnern in den Management-Ebenen den Finger zeigen und nach neuen Wegen an anderer Stelle suchen. Wer Spaß an Technik und Entwicklung hat und das als Softwareentwickler inhaltlich gut auf die Reihe bekommen hat, wird auf jeden Fall Alternativen finden. Oder, um es mit Golos Worten zu sagen: Seid mutig!
Ich glaube dieses Bedürfnis nach Kontrolle bei Managern (nicht nur Geschäftsführer) liegt an ihrem Rollenverständnis. Wenn Du steuern/lenken sollst, musst Du verstehen, was passiert. Und Kontrolle der Mitarbeiter bzw. Leistungskontrolle ist in vielen Unternehmen wichtig, weil man sich tausende von Metriken geschaffen hat. Je flacher die Hierarchie im Unternehmen ist, desto weniger Manager gibt es, die sich rechtfertigen müssen und deren einzige Aufgabe das "Managen" ist. Das läuft aber unserem Instinkt zum "Bürokratisieren" und formalisieren. Das coolste, was ich von einer Geschäftsführung gehört habe, war. "Das sind alles Themen, von denen ich keine Ahnung habe. Deshalb habe ich Mitarbeiter eingestellt, die das besser können als ich. Wieso soll ich ihnen dann sagen, wie sie ihren Job besser machen?" Dieses Grundvertrauen ist nicht leicht.
Du erinnerst mich mit deinen Videos immer daran, warum ich in die IT gegangen bin und das es wirklich Spaß machen kann. Danke dafür, hoffe du hast auch selber Spaß beim erstellen der Videos :)
9:39 Gerade auf Neue sollte ein Betrieb hören. Man beginnt in einem Betrieb, und es fallen einem unzählige unsinnige Gegebenheiten auf, was viel besser laufen könnte. Mit der Zeit wird man betriebsblind und auch zu faul für Veränderungen der eingebrannten Prozesse. Veränderung bedeutet ja eine Zeit lang erhöhte Konzentration, bis sich neue Routine einstellt. Es gilt: "Haben wir immer schon so gemacht." Der Mensch ist ein Gewohnheitstier, und das ist in gewissem Maße auch gut so. Das Gehirn muß Energie haushalten und sich auf wichtige Dinge konzentrieren, Routine ist wichtig fürs Überleben. Um den Zug nicht zu verpassen, muß man von Zeit zu Zeit aber auch mal die Komfortzone verlassen.
Best Video zu dem Thema ever…… Sogar auf Meta-Ebene, wie z.B. auch die Perspektive des Managements einzunehmen, und als WIR zu denken, auch zum Thema Angst und Job und Vorbereitung….und Timing….Aktiv bleiben…..Software plus Psychologie….GENIAL Hyper DANKE
Euer Prozess wäre auf jeden Fall interessant, aber eigentlich noch mehr wie ihr dazu gekommen seid. Welche learnings und welche Gegebenheiten haben zu welcher Entscheidung geführt? Wo und wann habt ihr beschlossen, Abläufe zu formalisieren, wo habt ihr bewusst Spielräume gelassen? Wie macht ihr Planung, budgetierung, forecasts? Einfach deswegen weil ich selbst seit einem Jahr Versuche, das mittlere Management mitzunehmen und gerade die Fragen nach Planungssicherheit (eh schwierig) die Diskussionen dominieren.
Ich bin angehender DEV könntest du mir bitte erklären warum genau ? Was würdest du anders machen und würdest du nochmal deine Richtung die du eingeschlagen hast wählen oder lieber was anderes developen ^^ is ziemlich viel i know but es würde mir helfen
In einem Unternehmen, das mich dafür kündigt, dass ich versuche, konstruktive Änderungen vorzuschlagen, würde ich auch gar nicht arbeiten wollen und mir stattdessen eine Firma suchen, die sowas mehr wertschätzt. Aber ich kann auch verstehen, dass das nicht jeder so sieht, Menschen sind unterschiedlich. Großen Upvote auch für den Aspekt, dass man sachlich und mit einem Plan argumentieren soll. Ich dachte früher immer, das wäre selbstverständlich, aber diese Annahme von mir war zu naiv habe ich mittlerweile festgestellt...
Sehe ich genauso. Es ist in Deutschland echt schwierig MA zu kündigen. Gerade aus solch einem Grund. Das schlimmste was passieren könnte ist dass man als Querulant abgestempelt wird und bei der nächsten Beförderungsrunde übersprungen wird. Aber Angst ist halt etwas dem du nicht so einfach mit Fakten begegnen kannst. Niemand sollte dafür verurteilt werden Angst zu haben. Mit den Kollegen zu reden hilft in der Regel sehr.
Ja, natürlich ist eine sachliche Argumentation schön. Bei persönlichen Konflikten muss man da dann aufblättern. Ich hatte Wegbegleiter, die haben sich sehr persönlich mit ihren Aufgaben identifiziert und ihr Herzblut hing dran. Dann kann man das als Führungskraft noch anders einordnen, als wenn jemand aus rein persönlichen Beweggründen versucht alles wegzupusten, da er seine Wohlstandszone gefährdet sieht. Natürlich gibt es einige Grautöne dazwischen.
Leider gibt es FIrmen die sowas "wertschätzen" wie du es beschreibst, immer weniger in Deutschland. Ich sehe die gesamte IT-Branche in diesem Land leider krass auf dem absteigenden Ast, sorry. Und ich arbeite seit 20 Jahren in der IT.
Ein günstiger Zeitpunkt wäre eigentlich immer derjenige Moment, in dem das System an die Wand gefahren wurde. Doch in dieser Lage könnte es Kollegen im "angstvollen/verzweifelten Tunnelmodus" geben, die nun "ausgerechnet jetzt" genau gar nichts ändern, sondern nur das Problem beheben wollen. Wenn man einmal 50 (oder gar 45) ist, wechselt es sich in der IT nicht mehr so leicht.
Leider noch nicht bei vielen Firmen angekommen, dass (embedded) Software kein Nebenprodukt ist, was bei der Entwicklung von eimem Produkt entsteht, sondern entsprechend mit Sorgfallt, Wertschätzung und Resourcen angegeht werden muss.
Korrekt gelebt ist Scrum eben kein Prozess sondern ein Framework und absolut nicht mit XP zu vergleichen. Scrum erlaubt es XP einzusetzen ohne Problem, aber wo XP der Entwicklung gute Werkzeuge bietet ist Scrum der Versuch die Lücke zu Management und Planung zu schließen. Wenn man "dark agile" erleben muss ist es auch fast egal mit welchem Framework man unterdrückt wird. Agiles arbeiten ist schlussendlich keine Frage des Frameworks, der Erfolg hängt von der Führung ab. Wenn die leitenden Stellen es nicht schaffen die Kultur im Unternehmen passend aufzustellen, dann kann kein noch so agiler Prozess dies ändern. Schwer finde ich, das vor allem Entwickler in der Regel nicht das Rüstzeug haben verkrustete Kommunikation aufzubrechen, das braucht Experten auf dem Gebiet (oder Glück).
Gutes Video (wie üblich) Ich habe nur Kleinigkeiten anzumerken. Das Schätzen nach "Komplexität" führt oft über kurz oder lang dazu, dass doch nach Zeit geschätzt wird. Ich halte das für gut. "Komplexität" ist ein unscharfer Begriff. Rechnet man die Unsicherheit mit rein? Externe Abhängigkeiten? Das ist viel Code, aber es trivial... (Dinge die heute AI beschleunigt, aber vor 7 Jahren musste man das tippen). Tests müssten auch rein... Ach ja... So viele Dinge. Am Ende sind halbwegs erfahrene Entwickler vielleicht doch gar nicht so schlecht darin Zeiten abzuschätzen. Wir können das für einzelne Tasks bzw. Features die kleine genug sind eigentlich ganz gut. Das Problem liegt dann in "klein genug". Wenn ich sagen kann "Morgen hab ich da was", wozu brauche ich dann noch eine Fibonacci-Zahl, T-Shirt-Größe oder Tierklasse (Ja... Alles schon gesehen) ? Richtig, braucht man nicht. Für das Daily Doing würde ich das Schätzen weglassen und lieber die Zeit und Energie darin investieren wirklich kleinstmögliche Features zu bauen und technische Exzellenz aufzubauen, damit die Code-Base auch erweiter- und veränderbar (viele Menschen nennen das wartbar) bleibt. Zahlen lügen nicht? Oha... Ich hatte eine 90-minütige Vorlesung über "Wie man mit Statistik lügt". Zahlen lügen zwar nicht, aber Menschen lügen mit Zahlen. Ständig. Anschließen möchte ich mich an den Aufruf für Mut. Sag was stört, sag was du dagegen tun willst (ganz wichtig! beides!) und guck ob du dein Team überzeugen kannst. Wenn sich ein Team auf Experimente einlässt, ist Hopfen und Malz noch nicht verloren und man kann was bewegen. Ansonsten gilt: Gib mir die Kraft Dinge zu ändern, die ich ändern kann. Gib mir die Gelassenheit Dinge hinzunehmen, die ich nicht ändern kann. Gib mir die Weisheit das eine vom anderen zu unterscheiden. 🙂
Ganz tolles Video. Habe euch zufällig dank des Algorithmus entdeckt. Großartige Inhalte! Meine ganz persönliche Meinung: wenn man alle Meetings von Scrum, so wie sie einem von den Zertifizierenden als perfektes Setup präsentiert werden, abhält mit einem ca. 10-köpfigen Team, dann bleibt erschreckend wenig Zeit für die Umsetzung. Nicht alle sind immer voll dabei, häufig gehen Dinge unter und werden daher mehrmals besprochen. Ich denke da gibt es durchaus andere Arbeitsweisen, bei denen man mehr entwickelt und immer nur dann Meetings abhält, wenn diese auch Sinn ergeben, und nicht weil diese halt im Kalender stehen.
Die Wertschätzung in der heutigen Zeit wird sehr viel in Frage gestellt.Dem nach ist es auch was das Alter des Mitarbeiters ganz große Rolle in jetziger Gesellschaft mitspielt.Selbst die Erwartungen die man an einem gestellt sind sind zwar sicherlich in vielen Ansatzpunkten sicher wichtig.Aber wie gesagt ich habe bei einem Unternehmen gearbeitet und es hat Mega Spass gemacht.Aber dabei habe ich auch wieder was gelernt.
Ich bin nicht so firm in sozialem Geschacher, "rede" lieber mit dem Computer als mit Menschen und hab während der Scrum-Einführung mal jemandem auf den Schlips getreten und laut gesagt, dass wir viel Zeit mit Meetings "verplempert" hätten. Woanders wäre ich damit wohl auf der Abschussliste gelandet, aber hier hat sich Scrum, neben anderen agilen Entwicklungsformen, evolutionär verbessert. Heute keine exzessiven Meetings mehr. Das Daily als Reporting gibt's zwar immer noch, aber dann meist weniger als 1min pro Person. Manchmal dauert's auch wirklich 1-2 Stunden, dann gibt's aber auch was zu besprechen.Entwickler gestalten das Backlog mit, keine rein von oben diktierte Fließbandarbeit. Toxisches Arbeitsklima, wo man sich keine Blöße geben darf, Haifischbecken und Mobbinghöllen sind bei jeder Arbeitsorganisation Mist. Ich bin aus solchen Jobs schnell raus geflogen, und im Nachhinein war das auch gut so.
Mehr Menschen braucht es die aufstehen und diese ganzen Blödsinn mal hinterfragen und auch mal sich trauen den Mund aufzumachen. Solche Menschen sind sympathisch. wenn ich meine eigene Firma hätte würde ich sofort den kompletten Vorstand rausschmeißen und dafür die Mitarbeiter die am meisten konstruktiv gegen die Firma am schießen sind dafür einsetzen. Mir wäre es dann auch wichtig, dass diese sich auch trauen den Mund gegen mich als Geschäftsführer aufzumachen, da ich bei weitem nicht fehlerfrei bin.
Mut ist der erste Schritt zur Veränderung! Wenn sich Mitarbeiter trauen, ihre Bedenken offen anzusprechen, kann daraus etwas Großartiges entstehen. Es ist wie ein erster Stein, der ins Rollen kommt und eine Welle der positiven Veränderungen auslösen kann. Daher nehmen hoffentlich viele das Video zum Anlass das Gespräch zu suchen. Ein Video zum agilen Ansatz von euch würde uns auch interessieren :).
Ja, so ein Video würde mich Brennend interessieren. Ich baue gerade ein Jungunternehmen auf um was in meiner Vorherigen Tätigkeit über 6 Jahre im Bösen Management. Mit dem Unterschied, dass bei uns Scrum vom Kunden als Kontrollinstrument missbraucht wurde aber leider, war das so gewünscht…
Bitte macht ein Video zu eurem agilen Ansatz. Ich denke da kann man viel lernen draus wenn man sieht/hört, wie ein agiler Ansatz ohne Scrum aussieht. Ich kenne im praktischen Ansatz in diese Richtung nur Scrum; ein Video dazu wäre also sehr interessant.
Das wäre vermutlich ziemlich langweilig. Die beiden haben zu ähnliche Ansichten. Was wäre das für ein Gespräch? Wo wären da die spannenden Reibungspunkte?
@@christianbaer2897 Also David hat viele Stories aus den unterschiedlichsten Unternehmensformen zu Prozessen und Co, auch mit Hinblick auf das "Peoples-P" wie er es immer nennt. Golo könnte seine Meinung überprüfen und Einwände einbringen an Punkten, wo er nicht d'accord geht
Zumal David hatte doch auch in ein oder zwei videos von seinen Erfahrungen auf einer seiner Präsentationen erzählt, bei den viele Entwickler im Unternehmen fertig sind. Und jetzt mit Golos Hinblick auf Scrum, wäre mal zu erfahren, wo da die Probleme entstanden sind. Vielleicht gibt es bei einigen Betroffenen bestimmte Punkte im Prozess, die den Ansatz ändern können.
22:13 👍 😅 "Jetzt hab ich viel gesagt, aber...." Dennoch weiter so mit deinen Videos, auch wenn das hier mal nur psycho war. So...muss outlaws weiter zocken. Da bin ich mir auch noch unsicher ob Flop oder naja 😅
Ja, der Ansatz wäre interessant, da ich meine Scrum ist bei Neuentwicklungen oder größeren Feature-Entwicklungen sinnig, aber bei Bestandsprodukten mit Bugs und kleineren Anpassungen fände ich Kanban oder sowas sinnvoller. Eventuell wäre auch der Aspekt, was das Team bewirkt interessant. Irgendwie habe ich das Gefühl, dass häufig Personen im Team sind, die den agilen Ansatz eben nicht annehmen wollen.
Den Eindruck habe ich noch nie gehabt. Kaum ein Softwareentwickler (m/w/d) möchte nicht agil arbeiten. Viele wollen aber nicht nach Fake oder Dark Agile arbeiten, sind damit aber als erstes in Berührung gekommen und nun ist es das was sie damit assoziieren. Ich kann zum Beispiel keine rote Beete essen, weil ich damit immer dieses eingelegte Zeug assoziiere, dass es in der Schule gab.
Ich habe immer wieder den Eindruck, dass einem Unternehmen gerade junge Leute frisch von der Uni richtig gut tun, weil gerade diese viel verändern wollen und dadurch so etwas wie Innovation voran getrieben wird.
Ich habe diese Woche ein Poster zu Scrum in klinischen Studien auf einer wissenschaftlichen Konferenz vorgestellt. Kam sehr gut an. Gerade in der medizinischen Wissenschaft herrscht Kraut und Rüben. Un im Hinblick zu Data Sharing ist Scum oder agile unerlässlich. Wird aber nicht gemacht und nicht gelehrt im medizinischen Kontext.
Wirklich ein sehr fenisles Video!!! Habe genau diese Themen schon in cieken Firmen erlebt. Alles super durchleuchtet und sehr auf eine sehr tiefe menschliche Ebene gebracht. Vieken Dank!!
Beim Ansprechen von Themen ist sicherlich eine Sachlichkeit gut. Ggf. mag es nun auch einen Unterschied zwischen kleineren Unternehmen und Konzernen/Behörden geben. Ich überblicke in einer Konzernstruktur natürlich nur einen sehr kleinen Ausschnitt. Das Thema ZDF (Zahlen, Daten, Fakten) ist hochkomplex. Im Kern werden wir auch über Kennzahlen gesteuert. Ähnlich wie Minimal- vs. Maximalprinzip, effizient vs. effektiv oder auch Eigenkapitalquote vs. Eigenkapitalrendite. Die Kennzahlen sind gut, stehen aber auch in Konkurrenz; sprich, wenn bei mir alle zu > 80 % erfüllt werden, wäre das ein Alarmsignal, dass ich irgendwo zaubere. Ich glaube, die Hürden, Themen anzusprechen, sollten deutlich gesenkt werden. Letztlich bietet hier die Welt der systemischen Fragestellung häufig gute Ansätze. Bin ich mir bewusst, dass ich eben ein Mosaikstein bin, dann ist es ja auch gut, über den Tellerrand hinauszublicken. Also wäre ein Auftakt sicherlich: "Ich habe beobachtet, dass [Situation/Verhalten/Ablauf/Prozess]. Ich habe wahrgenommen, dass xyz das beeinflusst. Wie nehmt ihr die Situation, den Prozess etc. wahr?" Somit spricht man Dinge an und erfährt die verschiedenen Hintergründe. Das ist ggf. auch vorurteilsfreier. Denn wenn ich alle Hintergründe, ZDF etc. erforscht habe, bin ich ggf. schon stark geprägt. Außerdem kann man so immer gut Fragen stellen und in ein Gespräch kommen. Vollkommen teile ich auch, allen die Chance zu geben, sich auf diese Frage(n) in einem Meeting einzustellen. Das Haupthemmnis, Themen anzusprechen, kommt auch häufig aus dem Selbstbewusstsein der Mitarbeitenden. Häufig auch gepaart damit, dass gute sachliche Fragen/Kritik auch nicht so sehr gelehrt werden. Natürlich spielen auch Themen wie introvertierte/extrovertierte Persönlichkeiten mit hinein. Gerade auch in Konzernen und Behörden ist die Motivation vieler „Verbesserungsvorschläge" auch der Versuch, unangenehme Aufgaben an andere loszuwerden. Bei meinem letzten Arbeitgeber war negative Kritik in einer Besprechung überhaupt nicht gern gesehen. Es durfte nur Positives berichtet werden. Es entstanden dann so Beiträge wie: „Ich freue mich mitzuteilen, dass nach dem Aufwand von 100.000 € das Projekt ABC durch den Kunden 123 in eine Neuausrichtung geführt wurde. Alle vermittelten Themen, die wir in den laufenden und zukünftigen Projekten besser machen können, werden hier zu einem Benefit führen. Ich danke allen Projektbeteiligten für ihren unermüdlichen Einsatz und freue mich, die anderen 65 laufenden Projekte damit zu einem besseren Ergebnis führen zu können."
Das Problem ist, dass bei Scrum Feature und Task geschätzt werden. Das geschied in Storypoints, aber viele interpretieren es als reale Zahlen. Die geschätzten Zeitaufwände kann man leicht für Kennzahlen missbrauchen. Wenn die Schätzungen nicht stimmen wird es kritisch, und die Entwickler werden unter Druck gesetzt. Druck erzeugt Angst. Und unter permanente Druck kannst du nicht effektiv programmieren. Es werden technische Schulden aufgehäuft. Und am Schluss läuft das Projekt an die Wand. Gleichzeitig bleiben dabei ein paar Kollegen auf der Strecke. Hier w
Prinzipiell ist das nichts, was einem bei einer komplett analogen Tätigkeit auch passieren kann (also eine Summe an Verhaltensweisen befolgen, die "von oben herab" befohlen werden). In der IT ist die Verlockung, es "der Kiste zu zeigen", aber (tendenziell) grösser, wenn man orts- und zeitunabhängig arbeiten kann (mit langfristigen Folgen für die psychische und physische Gesundheit).
Weise Worte: Ich bin ebenso Geschäftsführer und Seriengründer: Ich bin völlig dagegen Regeln eigenmächtig zu übergehen, die man sich als Team gesetzt hat. Aber am Ende muss man sich vergegenwärtigen: Man hat doch das gleiche Ziel und steigende Produktivität und Qualität kommt Mitarbeitern wie dem Unternehmen zu Gute. Daher bin ich stets bereit über jede Regel und jeden Prozess zu sprechen und einen dritten möglicherweise besseren Weg zu finden, wenn Option A und B nicht funktionieren. Aus den Gesprächen weiß ich: Oftmals fehlte es an Hintergrundwissen zu anderen Abteilungen und Prozessen, warum Dinge nicht klar waren. Hier muss ich dann besser kommunizieren. Aber es gab so auch immer Dinge, die man gemeinsam auf ein besseres Fundament gestellt hat. Generell: Es hat eben auch Vorteile, wenn der Chef selbst Entwickler ist/war und das was die Mitarbeiter tun, auch selbst versteht. Die Mitarbeiter die mit konstruktiven Vorschlägen kamen, keine schwarz/weiß Denke und Verantwortungsabschiebung betrieben, sondern ernsthaft bemüht sind die Situation für alle zu verbessern, sind die besten künftigen Führungskräfte.
Ich würde sagen, dass dies eine sehr naive Sicht auf die gesamte Situation ist. Dieser Ansatz könnte vielleicht in 5 % der Unternehmen funktionieren, aber der Rest weiß genau, was er tut. Sie haben Prozesse wie Scrum aus den falschen Gründen implementiert - um Entwickler zu micromanagen, eine Illusion von Vorhersehbarkeit aufrechtzuerhalten und die Arbeit so schnell wie möglich herauszubekommen. Zu denken, dass konstruktive Argumente in solchen Situationen etwas lösen werden, ist unrealistisch, denn wie ich immer sage, gibt es zu viele Menschen in IT-Unternehmen ohne technischen Hintergrund, die weder die Entwicklung noch das agile Arbeiten verstehen. Tools wie Scrum sind das Einzige, was ihnen die Illusion gibt, das Geschehen in den Entwicklerteams zu „verstehen“, und sie werden das nicht so leicht aufgeben.
Die Organisation muß sich eben auch anpassen. Neben der notwendigen Transparenz ist das die andere saure Gurke die man schlucken muß. Nochmal zu Scrum: Scrum ist nur ein mögliches Framework, das man benutzen kann, wenn man sich in einem komplexen Umfeld befindet. Ist immer abhängig von den Anforderungen, vom jeweiligen Team usw. . Dafür gibt es ja die Möglichkeit Dinge iterativ anzupassen. Immer nur eins pro Umlauf! Sonst weiß man nicht was (nicht) funktioniert. Eine sichere Umgebung (vor allem) in der Retro ist für die Verbesserung der Zusammenarbeit inner und außerhalb des Teams ist ein wichtige Voraussetzung. Und ein guter Scrum Master. Oder ein Coach. Zum Thema Konflikte: Wie man bei konstruktiver Kritik gekündigt werden soll, erschließt sich mir allerdings nicht. Arbeitsrechtlich ist das leider kompletter Nonsens. Und mit Scrum hat das auch nichts zu tun. Das Leute emotional sind, war auch noch nie ein Problem. Und zunächst einmal ist das ja meine Realität, ob sie nun für andere stimmt oder nicht. Die Klassische Formulierung bei Feedback: Wahrnehmung, Wirkung, Wunsch!
Schade das es das Video nicht auf Englisch gibt, wäre perfekt für geeignet um meinen ausländischen Kolleginnen und Kollegen zu zeigen, was im Moment bei uns schief läuft.
Ich kann agil arbeiten - nur definiere ich, was agil ist und nicht Jemand fachfremdes, der keine Ahnung hat, was ich mache. Man sollte das ganze System komplett über Bord werfen und es in die Hände derer legen, die Ahnung haben und abliefern müssen.
Danke für das Video. Leider ist es grundsätzlich darum gegangen, wie ein Mensch dalit umgeht,vund nicht - wie schlecht der Zustand ist und was man nicht aud der individuellen Ebene, sondern grundsätzlich machen soll, damit dieser Schwachsinn aufhört. Aber. Nicht du hast diesen Zustand verursacht, und die Wirkungsgröße ist schon kaum zu handhaben. Vielen Dank und eine schöne Woche!
Meine Erfahrung: Eine Effizienzsteigerung in der Softwareindustrie ist nicht gewünscht. An der Verwaltung und Bewirtschaftung der Ineffizienz wird mehr verdient als an ihrer Beseitigung. Leider.
Klasse! Ergänzung dazu aus einem anderen Blickwinkel in meinem Podcast Folge NBA30: Warum Agilität nicht tot ist - th-cam.com/video/W9TDfk2js2Y/w-d-xo.html
Als Consulting Firma es wäre interessant zu wissen , was ist der Grund warum man Scrum hasst? 2 Wochen sind immer ausreichend um per Sprint Derivaten zu produzieren, das "Geheimnis" man muss den Handwerk für Story splitten beherrschen. Das Team muss eigentlich in der Lage sein sehr Gute Gründen geben warum man die Qualität der Software in der erster Linie zu setzen, leider viel zu viele Entwickler sind Introvertiert und können sich nicht leisten den Ärger auf sich zu ziehen , Leut Querstellen ist sehr wichtig für die Entwicklung, wer dazu nicht bereit sich erklärt, na ja leider Sie werden dann einfach irgendwann ausgetauscht.
Habt Ihr echt meinen Kommentar (ich vermute wegen Links) gelöscht? Hmm, ok... Ich dachte, da von Heise aus dem Artikel verlinkt wäre es eher eine Ergänzung zu dem Thema. Ok, weiß ich bescheid...
Nein, haben wir nicht. TH-cam macht das aber sehr gerne, ohne dass wir das überhaupt mitbekommen oder darauf Einfluss hätten. Links in Kommentaren sind von TH-cam generell nicht gerne gesehen. Wir löschen Kommentare nur, wenn sie deutlich unter die Gürtellinie gehen, oder anderweitig kritisch sind. Ich weiß ja nicht, worum es in deinem Link ging, aber bloß weil zum Beispiel jemand eine andere Meinung hat als wir, löschen wir keinen Kommentar.
@@thenativeweb Klasse! Ich wollte nur etwas aus meinem Podcast ergänzen zu Eurem Artikel / Video - gleiches Thema, aber aus anderem Blickwinkel. Bin da ähnlicher Meinung...
Die meisten Entwickler hängen in irgendwelchen agilen Wasserköpfen fest. Wenn man da seinen Job behalten will, muss man das halt mittragen. Aber keine Sorge, das Geld am Venturekapitalmarkt wird gerade dermaßen teuer, dass die agile Blase platzt. In den USA ist sie gerade dabei. Am Ende bleiben ein paar Full Stacker übrig, damit kann man sich Business Analysten, Architekten, QA Engineers, Infrastrukturspezialisten, Database Operators etc etc etc sparen. Die ganze Product Manager Ebene kann einpacken. Und es wird gut sein. Menschen sehen wieder, wie aus einer Kundenanforderung aus ihren Händen ein Produkt wird.
Es kommen gefühlt nur noch so reißerische Titel, dass ich nicht mehr klicken mag. Ich kenne Eure Begründung, aber ich mag da nicht mit gehen und das auch nicht mehr in meinen Vorschlägen sehen.
Das ist schade, aber wenn das Deine Wahrnehmung ist, können wir das leider nicht ändern. Was ich daran schade finde, ist, dass Du Dich rein nur am Titel störst und deshalb diese Entscheidung triffst - denn die Videos an sich scheinen Dir ja zu gefallen. Da wir das Ganze nicht machen, damit Videos existieren, sondern damit sich Menschen weiterbilden und informieren können, sind wir auf Aufmerksamkeit und Views angewiesen. Und das funktioniert mit den Titeln, wie wir sie aktuell machen deutlich besser als mit rein sachlichen Titeln. Und so lange die Videos den Erwartungen an uns gerecht werden, was Inhalt & Co. angeht, finde ich die Diskussion über Titel ehrlich gesagt etwas müßig.
Natürlich kann man ein Video einfach mit einem groben Stichwort abwatschen, aber dann gibt es halt auch kein Like... Wenn du wenigstens noch irgendwas konkretes zu der Forschung sagen würdest. Wer? Wann? Was? Damit man wenigstens irgendwie sinnvoll Google bemühen könnte, wäre dein Kommentar hilfreich gewesen. So nicht.
@@christianbaer2897 Es haben ja viele geforscht, vielleicht findet ihr ja etwas tolles, was ich noch nicht auf dem Schirm habe. Daher wollte ich keine Suchrichtung vorgeben. Wenn ihr doch Buzzwords wollt, dann hier: System, Mitgliedsrolle, Einfluss, Erwartung, Takt, Rang
Oder man schaut das Video wirklich und zuende, dann hätte man erlebt dass hier nicht gegen scrum gewettert wird sondern gegen die Falschanwendungen die in vielen betrieben stattfindet. Bei uns wurde scrum leider auch dazu eingesetzt damit die Führung mehr Kontrolle hat, mehr Arbeit in alle Richtungen katapultiert würde, und wir ca. 50% - 60% unserer Zeit in allen möglichen Terminen sitzen.
Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html
Ja, macht sehr gern mal bitte ein Video zu eurem agilen Ansatz.
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
@@thenativeweb sehr schön
In dem Unternemen, für das ich zuletzt gearbeitet habe, wurde Scrum dafür vergewaltigt, dem mittleren Managment einen Deckmantel gegenüber der Konzernspitze zu liefern, die eigene Inkompetenz zu vertuschen und Wolkenkuckucksheime zu malen. Jeder Versuch, über mehrere Jahre, von verschiedener Seite, mit unterschiedlichen Ansätzen, daran etwas zu ändern, wurde jeweils recht schnell abgewehrt und mit stärkeren Daumenschrauben beantwortet.
Nachdem ich mich dann ein Weile umgeschaut hatte, was in anderen Unternehmen und Projekten los ist, hab ich beschlossen, den Weg als Anwendungsentwickler, dem ich mittlerweile über 30 Jahre gefolgt war, zu verlassen, weil ich den Eindruck gewonnen habe, dass das Unternehmen, für das ich tätig war, kein Sonderfall ist. Der Anfang dieses Videos hier bestätigt das nochmal.
Ich werde mich nun mehr in Richtung Hardware, Embedded Systems und Prototypenbau orientieren. Dazu habe ich angefangen Computer Engineering zu studieren. Und siehe da, ein paar der Väter der Kommilitonen, erzählen am Familientisch offenbar die gleichen Geschichten, die ich den Jungs in der Mensa erzähle und ein paar davon haben ihre Jobs ebenfalls an den Nagel gehängt und fangen auf ihre alten Tage an auch nochmal zu studieren.
Der Vorteil an der Software/IT-Branche ist ja, dass man damit auch Rücklagen bilden konnte, die einem dann im Alter nochmal Spielräume eröffnen.
Mein Fazit: Niemand sollte verzagen, sondern diesen inkompetenten Spinnern in den Management-Ebenen den Finger zeigen und nach neuen Wegen an anderer Stelle suchen. Wer Spaß an Technik und Entwicklung hat und das als Softwareentwickler inhaltlich gut auf die Reihe bekommen hat, wird auf jeden Fall Alternativen finden.
Oder, um es mit Golos Worten zu sagen: Seid mutig!
Ich kann mit Ihnen fühlen, da ich eine ähnliche Erfahrung gemacht habe
Ich glaube dieses Bedürfnis nach Kontrolle bei Managern (nicht nur Geschäftsführer) liegt an ihrem Rollenverständnis. Wenn Du steuern/lenken sollst, musst Du verstehen, was passiert. Und Kontrolle der Mitarbeiter bzw. Leistungskontrolle ist in vielen Unternehmen wichtig, weil man sich tausende von Metriken geschaffen hat. Je flacher die Hierarchie im Unternehmen ist, desto weniger Manager gibt es, die sich rechtfertigen müssen und deren einzige Aufgabe das "Managen" ist. Das läuft aber unserem Instinkt zum "Bürokratisieren" und formalisieren.
Das coolste, was ich von einer Geschäftsführung gehört habe, war. "Das sind alles Themen, von denen ich keine Ahnung habe. Deshalb habe ich Mitarbeiter eingestellt, die das besser können als ich. Wieso soll ich ihnen dann sagen, wie sie ihren Job besser machen?" Dieses Grundvertrauen ist nicht leicht.
Du erinnerst mich mit deinen Videos immer daran, warum ich in die IT gegangen bin und das es wirklich Spaß machen kann. Danke dafür, hoffe du hast auch selber Spaß beim erstellen der Videos :)
Danke schön - und ja, den habe ich (bzw den haben wir) 😊
9:39 Gerade auf Neue sollte ein Betrieb hören. Man beginnt in einem Betrieb, und es fallen einem unzählige unsinnige Gegebenheiten auf, was viel besser laufen könnte. Mit der Zeit wird man betriebsblind und auch zu faul für Veränderungen der eingebrannten Prozesse. Veränderung bedeutet ja eine Zeit lang erhöhte Konzentration, bis sich neue Routine einstellt. Es gilt: "Haben wir immer schon so gemacht." Der Mensch ist ein Gewohnheitstier, und das ist in gewissem Maße auch gut so. Das Gehirn muß Energie haushalten und sich auf wichtige Dinge konzentrieren, Routine ist wichtig fürs Überleben. Um den Zug nicht zu verpassen, muß man von Zeit zu Zeit aber auch mal die Komfortzone verlassen.
Best Video zu dem Thema ever……
Sogar auf Meta-Ebene, wie z.B. auch die Perspektive des Managements einzunehmen, und als WIR zu denken, auch zum Thema Angst und Job und Vorbereitung….und Timing….Aktiv bleiben…..Software plus Psychologie….GENIAL
Hyper DANKE
Euer Prozess wäre auf jeden Fall interessant, aber eigentlich noch mehr wie ihr dazu gekommen seid. Welche learnings und welche Gegebenheiten haben zu welcher Entscheidung geführt? Wo und wann habt ihr beschlossen, Abläufe zu formalisieren, wo habt ihr bewusst Spielräume gelassen? Wie macht ihr Planung, budgetierung, forecasts?
Einfach deswegen weil ich selbst seit einem Jahr Versuche, das mittlere Management mitzunehmen und gerade die Fragen nach Planungssicherheit (eh schwierig) die Diskussionen dominieren.
Interessiere mich für euren Prozess! Gern ein Video dazu!
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
Scrum ist das beste Mittel, um Entwickler in den BurnOut zu treiben
Ich bin angehender DEV könntest du mir bitte erklären warum genau ?
Was würdest du anders machen und würdest du nochmal deine Richtung die du eingeschlagen hast wählen oder lieber was anderes developen ^^ is ziemlich viel i know but es würde mir helfen
Nach einer Firma kommt eine Firma. Glaub mir, es geht immer weiter
In einem Unternehmen, das mich dafür kündigt, dass ich versuche, konstruktive Änderungen vorzuschlagen, würde ich auch gar nicht arbeiten wollen und mir stattdessen eine Firma suchen, die sowas mehr wertschätzt. Aber ich kann auch verstehen, dass das nicht jeder so sieht, Menschen sind unterschiedlich.
Großen Upvote auch für den Aspekt, dass man sachlich und mit einem Plan argumentieren soll. Ich dachte früher immer, das wäre selbstverständlich, aber diese Annahme von mir war zu naiv habe ich mittlerweile festgestellt...
Sehe ich genauso. Es ist in Deutschland echt schwierig MA zu kündigen. Gerade aus solch einem Grund. Das schlimmste was passieren könnte ist dass man als Querulant abgestempelt wird und bei der nächsten Beförderungsrunde übersprungen wird.
Aber Angst ist halt etwas dem du nicht so einfach mit Fakten begegnen kannst. Niemand sollte dafür verurteilt werden Angst zu haben. Mit den Kollegen zu reden hilft in der Regel sehr.
Ja, natürlich ist eine sachliche Argumentation schön. Bei persönlichen Konflikten muss man da dann aufblättern. Ich hatte Wegbegleiter, die haben sich sehr persönlich mit ihren Aufgaben identifiziert und ihr Herzblut hing dran. Dann kann man das als Führungskraft noch anders einordnen, als wenn jemand aus rein persönlichen Beweggründen versucht alles wegzupusten, da er seine Wohlstandszone gefährdet sieht. Natürlich gibt es einige Grautöne dazwischen.
Leider gibt es FIrmen die sowas "wertschätzen" wie du es beschreibst, immer weniger in Deutschland.
Ich sehe die gesamte IT-Branche in diesem Land leider krass auf dem absteigenden Ast, sorry. Und ich arbeite seit 20 Jahren in der IT.
Ein günstiger Zeitpunkt wäre eigentlich immer derjenige Moment, in dem das System an die Wand gefahren wurde. Doch in dieser Lage könnte es Kollegen im "angstvollen/verzweifelten Tunnelmodus" geben, die nun "ausgerechnet jetzt" genau gar nichts ändern, sondern nur das Problem beheben wollen.
Wenn man einmal 50 (oder gar 45) ist, wechselt es sich in der IT nicht mehr so leicht.
Leider noch nicht bei vielen Firmen angekommen, dass (embedded) Software kein Nebenprodukt ist, was bei der Entwicklung von eimem Produkt entsteht, sondern entsprechend mit Sorgfallt, Wertschätzung und Resourcen angegeht werden muss.
Korrekt gelebt ist Scrum eben kein Prozess sondern ein Framework und absolut nicht mit XP zu vergleichen. Scrum erlaubt es XP einzusetzen ohne Problem, aber wo XP der Entwicklung gute Werkzeuge bietet ist Scrum der Versuch die Lücke zu Management und Planung zu schließen.
Wenn man "dark agile" erleben muss ist es auch fast egal mit welchem Framework man unterdrückt wird.
Agiles arbeiten ist schlussendlich keine Frage des Frameworks, der Erfolg hängt von der Führung ab. Wenn die leitenden Stellen es nicht schaffen die Kultur im Unternehmen passend aufzustellen, dann kann kein noch so agiler Prozess dies ändern.
Schwer finde ich, das vor allem Entwickler in der Regel nicht das Rüstzeug haben verkrustete Kommunikation aufzubrechen, das braucht Experten auf dem Gebiet (oder Glück).
Gutes Video (wie üblich)
Ich habe nur Kleinigkeiten anzumerken.
Das Schätzen nach "Komplexität" führt oft über kurz oder lang dazu, dass doch nach Zeit geschätzt wird. Ich halte das für gut. "Komplexität" ist ein unscharfer Begriff. Rechnet man die Unsicherheit mit rein? Externe Abhängigkeiten? Das ist viel Code, aber es trivial... (Dinge die heute AI beschleunigt, aber vor 7 Jahren musste man das tippen). Tests müssten auch rein... Ach ja... So viele Dinge.
Am Ende sind halbwegs erfahrene Entwickler vielleicht doch gar nicht so schlecht darin Zeiten abzuschätzen. Wir können das für einzelne Tasks bzw. Features die kleine genug sind eigentlich ganz gut. Das Problem liegt dann in "klein genug". Wenn ich sagen kann "Morgen hab ich da was", wozu brauche ich dann noch eine Fibonacci-Zahl, T-Shirt-Größe oder Tierklasse (Ja... Alles schon gesehen) ? Richtig, braucht man nicht. Für das Daily Doing würde ich das Schätzen weglassen und lieber die Zeit und Energie darin investieren wirklich kleinstmögliche Features zu bauen und technische Exzellenz aufzubauen, damit die Code-Base auch erweiter- und veränderbar (viele Menschen nennen das wartbar) bleibt.
Zahlen lügen nicht? Oha... Ich hatte eine 90-minütige Vorlesung über "Wie man mit Statistik lügt". Zahlen lügen zwar nicht, aber Menschen lügen mit Zahlen. Ständig.
Anschließen möchte ich mich an den Aufruf für Mut. Sag was stört, sag was du dagegen tun willst (ganz wichtig! beides!) und guck ob du dein Team überzeugen kannst. Wenn sich ein Team auf Experimente einlässt, ist Hopfen und Malz noch nicht verloren und man kann was bewegen.
Ansonsten gilt: Gib mir die Kraft Dinge zu ändern, die ich ändern kann. Gib mir die Gelassenheit Dinge hinzunehmen, die ich nicht ändern kann. Gib mir die Weisheit das eine vom anderen zu unterscheiden. 🙂
Ganz tolles Video. Habe euch zufällig dank des Algorithmus entdeckt. Großartige Inhalte!
Meine ganz persönliche Meinung: wenn man alle Meetings von Scrum, so wie sie einem von den Zertifizierenden als perfektes Setup präsentiert werden, abhält mit einem ca. 10-köpfigen Team, dann bleibt erschreckend wenig Zeit für die Umsetzung.
Nicht alle sind immer voll dabei, häufig gehen Dinge unter und werden daher mehrmals besprochen.
Ich denke da gibt es durchaus andere Arbeitsweisen, bei denen man mehr entwickelt und immer nur dann Meetings abhält, wenn diese auch Sinn ergeben, und nicht weil diese halt im Kalender stehen.
Die Wertschätzung in der heutigen Zeit wird sehr viel in Frage gestellt.Dem nach ist es auch was das Alter des Mitarbeiters ganz große Rolle in jetziger Gesellschaft mitspielt.Selbst die Erwartungen die man an einem gestellt sind sind zwar sicherlich in vielen Ansatzpunkten sicher wichtig.Aber wie gesagt ich habe bei einem Unternehmen gearbeitet und es hat Mega Spass gemacht.Aber dabei habe ich auch wieder was gelernt.
Ich bin nicht so firm in sozialem Geschacher, "rede" lieber mit dem Computer als mit Menschen und hab während der Scrum-Einführung mal jemandem auf den Schlips getreten und laut gesagt, dass wir viel Zeit mit Meetings "verplempert" hätten. Woanders wäre ich damit wohl auf der Abschussliste gelandet, aber hier hat sich Scrum, neben anderen agilen Entwicklungsformen, evolutionär verbessert. Heute keine exzessiven Meetings mehr. Das Daily als Reporting gibt's zwar immer noch, aber dann meist weniger als 1min pro Person. Manchmal dauert's auch wirklich 1-2 Stunden, dann gibt's aber auch was zu besprechen.Entwickler gestalten das Backlog mit, keine rein von oben diktierte Fließbandarbeit. Toxisches Arbeitsklima, wo man sich keine Blöße geben darf, Haifischbecken und Mobbinghöllen sind bei jeder Arbeitsorganisation Mist. Ich bin aus solchen Jobs schnell raus geflogen, und im Nachhinein war das auch gut so.
Mehr Menschen braucht es die aufstehen und diese ganzen Blödsinn mal hinterfragen und auch mal sich trauen den Mund aufzumachen. Solche Menschen sind sympathisch. wenn ich meine eigene Firma hätte würde ich sofort den kompletten Vorstand rausschmeißen und dafür die Mitarbeiter die am meisten konstruktiv gegen die Firma am schießen sind dafür einsetzen. Mir wäre es dann auch wichtig, dass diese sich auch trauen den Mund gegen mich als Geschäftsführer aufzumachen, da ich bei weitem nicht fehlerfrei bin.
Mut ist der erste Schritt zur Veränderung! Wenn sich Mitarbeiter trauen, ihre Bedenken offen anzusprechen, kann daraus etwas Großartiges entstehen. Es ist wie ein erster Stein, der ins Rollen kommt und eine Welle der positiven Veränderungen auslösen kann. Daher nehmen hoffentlich viele das Video zum Anlass das Gespräch zu suchen. Ein Video zum agilen Ansatz von euch würde uns auch interessieren :).
Ja, so ein Video würde mich Brennend interessieren.
Ich baue gerade ein Jungunternehmen auf um was in meiner Vorherigen Tätigkeit über 6 Jahre im Bösen Management.
Mit dem Unterschied, dass bei uns Scrum vom Kunden als Kontrollinstrument missbraucht wurde aber leider, war das so gewünscht…
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
11:06 so true, ich kringel mich vor lachen und weine dabei gleichzeitig
Bitte macht ein Video zu eurem agilen Ansatz. Ich denke da kann man viel lernen draus wenn man sieht/hört, wie ein agiler Ansatz ohne Scrum aussieht. Ich kenne im praktischen Ansatz in diese Richtung nur Scrum; ein Video dazu wäre also sehr interessant.
Zu dem Thema könntest du auch ein Interview mit David Tielke machen.
Das wäre vermutlich ziemlich langweilig. Die beiden haben zu ähnliche Ansichten. Was wäre das für ein Gespräch? Wo wären da die spannenden Reibungspunkte?
@@christianbaer2897 Also David hat viele Stories aus den unterschiedlichsten Unternehmensformen zu Prozessen und Co, auch mit Hinblick auf das "Peoples-P" wie er es immer nennt. Golo könnte seine Meinung überprüfen und Einwände einbringen an Punkten, wo er nicht d'accord geht
Zumal David hatte doch auch in ein oder zwei videos von seinen Erfahrungen auf einer seiner Präsentationen erzählt, bei den viele Entwickler im Unternehmen fertig sind. Und jetzt mit Golos Hinblick auf Scrum, wäre mal zu erfahren, wo da die Probleme entstanden sind. Vielleicht gibt es bei einigen Betroffenen bestimmte Punkte im Prozess, die den Ansatz ändern können.
@@DJone4one @kryob1 Hm... Vielleicht könnte es doch interessanter werden als ich es mir vorstelle.
Ich bin dankbar das es euren Kanal gibt , sehr Objektiv, thx !
Sehr schön, ich kann deinen Frust sehr gut verstehen. Da rennst du offene Türen ein.
22:13 👍 😅 "Jetzt hab ich viel gesagt, aber...." Dennoch weiter so mit deinen Videos, auch wenn das hier mal nur psycho war. So...muss outlaws weiter zocken. Da bin ich mir auch noch unsicher ob Flop oder naja 😅
Bei 2:11 geht es los.
Hi, ich möchte eher in die scrum Hölle rein. Wir finde ich einen Job als PO? 😅🤣
Ein Video für Greator, ehemals GedankenTanken (ähnlich wie TEDx Talks). 🙏🙏🙏
Ja, der Ansatz wäre interessant, da ich meine Scrum ist bei Neuentwicklungen oder größeren Feature-Entwicklungen sinnig, aber bei Bestandsprodukten mit Bugs und kleineren Anpassungen fände ich Kanban oder sowas sinnvoller. Eventuell wäre auch der Aspekt, was das Team bewirkt interessant. Irgendwie habe ich das Gefühl, dass häufig Personen im Team sind, die den agilen Ansatz eben nicht annehmen wollen.
Den Eindruck habe ich noch nie gehabt. Kaum ein Softwareentwickler (m/w/d) möchte nicht agil arbeiten. Viele wollen aber nicht nach Fake oder Dark Agile arbeiten, sind damit aber als erstes in Berührung gekommen und nun ist es das was sie damit assoziieren. Ich kann zum Beispiel keine rote Beete essen, weil ich damit immer dieses eingelegte Zeug assoziiere, dass es in der Schule gab.
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
du bist top - weiter so!
Ich habe immer wieder den Eindruck, dass einem Unternehmen gerade junge Leute frisch von der Uni richtig gut tun, weil gerade diese viel verändern wollen und dadurch so etwas wie Innovation voran getrieben wird.
Als ich mich dagegen gewehrt habe, begann mein Chef mit Bossing.
Ich habe diese Woche ein Poster zu Scrum in klinischen Studien auf einer wissenschaftlichen Konferenz vorgestellt. Kam sehr gut an. Gerade in der medizinischen Wissenschaft herrscht Kraut und Rüben. Un im Hinblick zu Data Sharing ist Scum oder agile unerlässlich. Wird aber nicht gemacht und nicht gelehrt im medizinischen Kontext.
Wirklich ein sehr fenisles Video!!! Habe genau diese Themen schon in cieken Firmen erlebt. Alles super durchleuchtet und sehr auf eine sehr tiefe menschliche Ebene gebracht. Vieken Dank!!
Beim Ansprechen von Themen ist sicherlich eine Sachlichkeit gut. Ggf. mag es nun auch einen Unterschied zwischen kleineren Unternehmen und Konzernen/Behörden geben. Ich überblicke in einer Konzernstruktur natürlich nur einen sehr kleinen Ausschnitt. Das Thema ZDF (Zahlen, Daten, Fakten) ist hochkomplex. Im Kern werden wir auch über Kennzahlen gesteuert. Ähnlich wie Minimal- vs. Maximalprinzip, effizient vs. effektiv oder auch Eigenkapitalquote vs. Eigenkapitalrendite. Die Kennzahlen sind gut, stehen aber auch in Konkurrenz; sprich, wenn bei mir alle zu > 80 % erfüllt werden, wäre das ein Alarmsignal, dass ich irgendwo zaubere. Ich glaube, die Hürden, Themen anzusprechen, sollten deutlich gesenkt werden. Letztlich bietet hier die Welt der systemischen Fragestellung häufig gute Ansätze. Bin ich mir bewusst, dass ich eben ein Mosaikstein bin, dann ist es ja auch gut, über den Tellerrand hinauszublicken. Also wäre ein Auftakt sicherlich:
"Ich habe beobachtet, dass [Situation/Verhalten/Ablauf/Prozess]. Ich habe wahrgenommen, dass xyz das beeinflusst. Wie nehmt ihr die Situation, den Prozess etc. wahr?" Somit spricht man Dinge an und erfährt die verschiedenen Hintergründe. Das ist ggf. auch vorurteilsfreier. Denn wenn ich alle Hintergründe, ZDF etc. erforscht habe, bin ich ggf. schon stark geprägt. Außerdem kann man so immer gut Fragen stellen und in ein Gespräch kommen. Vollkommen teile ich auch, allen die Chance zu geben, sich auf diese Frage(n) in einem Meeting einzustellen. Das Haupthemmnis, Themen anzusprechen, kommt auch häufig aus dem Selbstbewusstsein der Mitarbeitenden. Häufig auch gepaart damit, dass gute sachliche Fragen/Kritik auch nicht so sehr gelehrt werden. Natürlich spielen auch Themen wie introvertierte/extrovertierte Persönlichkeiten mit hinein. Gerade auch in Konzernen und Behörden ist die Motivation vieler „Verbesserungsvorschläge" auch der Versuch, unangenehme Aufgaben an andere loszuwerden. Bei meinem letzten Arbeitgeber war negative Kritik in einer Besprechung überhaupt nicht gern gesehen. Es durfte nur Positives berichtet werden. Es entstanden dann so Beiträge wie: „Ich freue mich mitzuteilen, dass nach dem Aufwand von 100.000 € das Projekt ABC durch den Kunden 123 in eine Neuausrichtung geführt wurde. Alle vermittelten Themen, die wir in den laufenden und zukünftigen Projekten besser machen können, werden hier zu einem Benefit führen. Ich danke allen Projektbeteiligten für ihren unermüdlichen Einsatz und freue mich, die anderen 65 laufenden Projekte damit zu einem besseren Ergebnis führen zu können."
Das Problem ist, dass bei Scrum Feature und Task geschätzt werden. Das geschied in Storypoints, aber viele interpretieren es als reale Zahlen.
Die geschätzten Zeitaufwände kann man leicht für Kennzahlen missbrauchen. Wenn die Schätzungen nicht stimmen wird es kritisch, und die Entwickler werden unter Druck gesetzt.
Druck erzeugt Angst. Und unter permanente Druck kannst du nicht effektiv programmieren. Es werden technische Schulden aufgehäuft. Und am Schluss läuft das Projekt an die Wand. Gleichzeitig bleiben dabei ein paar Kollegen auf der Strecke.
Hier w
Prinzipiell ist das nichts, was einem bei einer komplett analogen Tätigkeit auch passieren kann (also eine Summe an Verhaltensweisen befolgen, die "von oben herab" befohlen werden). In der IT ist die Verlockung, es "der Kiste zu zeigen", aber (tendenziell) grösser, wenn man orts- und zeitunabhängig arbeiten kann (mit langfristigen Folgen für die psychische und physische Gesundheit).
Weise Worte: Ich bin ebenso Geschäftsführer und Seriengründer: Ich bin völlig dagegen Regeln eigenmächtig zu übergehen, die man sich als Team gesetzt hat. Aber am Ende muss man sich vergegenwärtigen: Man hat doch das gleiche Ziel und steigende Produktivität und Qualität kommt Mitarbeitern wie dem Unternehmen zu Gute. Daher bin ich stets bereit über jede Regel und jeden Prozess zu sprechen und einen dritten möglicherweise besseren Weg zu finden, wenn Option A und B nicht funktionieren. Aus den Gesprächen weiß ich: Oftmals fehlte es an Hintergrundwissen zu anderen Abteilungen und Prozessen, warum Dinge nicht klar waren. Hier muss ich dann besser kommunizieren. Aber es gab so auch immer Dinge, die man gemeinsam auf ein besseres Fundament gestellt hat. Generell: Es hat eben auch Vorteile, wenn der Chef selbst Entwickler ist/war und das was die Mitarbeiter tun, auch selbst versteht. Die Mitarbeiter die mit konstruktiven Vorschlägen kamen, keine schwarz/weiß Denke und Verantwortungsabschiebung betrieben, sondern ernsthaft bemüht sind die Situation für alle zu verbessern, sind die besten künftigen Führungskräfte.
Ich würde sagen, dass dies eine sehr naive Sicht auf die gesamte Situation ist. Dieser Ansatz könnte vielleicht in 5 % der Unternehmen funktionieren, aber der Rest weiß genau, was er tut. Sie haben Prozesse wie Scrum aus den falschen Gründen implementiert - um Entwickler zu micromanagen, eine Illusion von Vorhersehbarkeit aufrechtzuerhalten und die Arbeit so schnell wie möglich herauszubekommen. Zu denken, dass konstruktive Argumente in solchen Situationen etwas lösen werden, ist unrealistisch, denn wie ich immer sage, gibt es zu viele Menschen in IT-Unternehmen ohne technischen Hintergrund, die weder die Entwicklung noch das agile Arbeiten verstehen. Tools wie Scrum sind das Einzige, was ihnen die Illusion gibt, das Geschehen in den Entwicklerteams zu „verstehen“, und sie werden das nicht so leicht aufgeben.
Wie sieht euer agile Prozess bei the Native Web aus?
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
Die Organisation muß sich eben auch anpassen. Neben der notwendigen Transparenz ist das die andere saure Gurke die man schlucken muß. Nochmal zu Scrum: Scrum ist nur ein mögliches Framework, das man benutzen kann, wenn man sich in einem komplexen Umfeld befindet. Ist immer abhängig von den Anforderungen, vom jeweiligen Team usw. . Dafür gibt es ja die Möglichkeit Dinge iterativ anzupassen. Immer nur eins pro Umlauf! Sonst weiß man nicht was (nicht) funktioniert. Eine sichere Umgebung (vor allem) in der Retro ist für die Verbesserung der Zusammenarbeit inner und außerhalb des Teams ist ein wichtige Voraussetzung. Und ein guter Scrum Master. Oder ein Coach. Zum Thema Konflikte: Wie man bei konstruktiver Kritik gekündigt werden soll, erschließt sich mir allerdings nicht. Arbeitsrechtlich ist das leider kompletter Nonsens. Und mit Scrum hat das auch nichts zu tun. Das Leute emotional sind, war auch noch nie ein Problem. Und zunächst einmal ist das ja meine Realität, ob sie nun für andere stimmt oder nicht. Die Klassische Formulierung bei Feedback: Wahrnehmung, Wirkung, Wunsch!
Schade das es das Video nicht auf Englisch gibt, wäre perfekt für geeignet um meinen ausländischen Kolleginnen und Kollegen zu zeigen, was im Moment bei uns schief läuft.
Ich kann agil arbeiten - nur definiere ich, was agil ist und nicht Jemand fachfremdes, der keine Ahnung hat, was ich mache. Man sollte das ganze System komplett über Bord werfen und es in die Hände derer legen, die Ahnung haben und abliefern müssen.
Bitte zeigt mal euren Prozess. Bin neugier geworden.
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
Gab es da nicht ein Video? 12 Methoden um Scrum zu unterwandern und agil, subtil Scrum zu torpedieren und das Management in den Wahnsinn zu treiben?
Abgesehen vom Inhalt - es ist bemerkenswert, wie flüssig und prägnant du frei sprechen kannst! Das ist bereits ein Skill für sich.
Danke für das Video. Leider ist es grundsätzlich darum gegangen, wie ein Mensch dalit umgeht,vund nicht - wie schlecht der Zustand ist und was man nicht aud der individuellen Ebene, sondern grundsätzlich machen soll, damit dieser Schwachsinn aufhört. Aber. Nicht du hast diesen Zustand verursacht, und die Wirkungsgröße ist schon kaum zu handhaben. Vielen Dank und eine schöne Woche!
Meine Erfahrung:
Eine Effizienzsteigerung in der Softwareindustrie ist nicht gewünscht.
An der Verwaltung und Bewirtschaftung der Ineffizienz wird mehr verdient als an ihrer Beseitigung.
Leider.
Da wundert man sich wie die methode gruppendruck und maximales monitoring missbraucht wird. Das ist die grundidee von scrum.
Klasse! Ergänzung dazu aus einem anderen Blickwinkel in meinem Podcast Folge NBA30: Warum Agilität nicht tot ist - th-cam.com/video/W9TDfk2js2Y/w-d-xo.html
Jo...mach fertich!
Als Consulting Firma es wäre interessant zu wissen , was ist der Grund warum man Scrum hasst?
2 Wochen sind immer ausreichend um per Sprint Derivaten zu produzieren, das "Geheimnis" man muss den Handwerk für Story splitten beherrschen. Das Team muss eigentlich in der Lage sein sehr Gute Gründen geben warum man die Qualität der Software in der erster Linie zu setzen, leider viel zu viele Entwickler sind Introvertiert und können sich nicht leisten den Ärger auf sich zu ziehen , Leut Querstellen ist sehr wichtig für die Entwicklung, wer dazu nicht bereit sich erklärt, na ja leider Sie werden dann einfach irgendwann ausgetauscht.
Habt Ihr echt meinen Kommentar (ich vermute wegen Links) gelöscht? Hmm, ok... Ich dachte, da von Heise aus dem Artikel verlinkt wäre es eher eine Ergänzung zu dem Thema. Ok, weiß ich bescheid...
Nein, haben wir nicht. TH-cam macht das aber sehr gerne, ohne dass wir das überhaupt mitbekommen oder darauf Einfluss hätten. Links in Kommentaren sind von TH-cam generell nicht gerne gesehen.
Wir löschen Kommentare nur, wenn sie deutlich unter die Gürtellinie gehen, oder anderweitig kritisch sind. Ich weiß ja nicht, worum es in deinem Link ging, aber bloß weil zum Beispiel jemand eine andere Meinung hat als wir, löschen wir keinen Kommentar.
@@thenativeweb Klasse! Ich wollte nur etwas aus meinem Podcast ergänzen zu Eurem Artikel / Video - gleiches Thema, aber aus anderem Blickwinkel. Bin da ähnlicher Meinung...
Die meisten Entwickler hängen in irgendwelchen agilen Wasserköpfen fest. Wenn man da seinen Job behalten will, muss man das halt mittragen.
Aber keine Sorge, das Geld am Venturekapitalmarkt wird gerade dermaßen teuer, dass die agile Blase platzt. In den USA ist sie gerade dabei. Am Ende bleiben ein paar Full Stacker übrig, damit kann man sich Business Analysten, Architekten, QA Engineers, Infrastrukturspezialisten, Database Operators etc etc etc sparen. Die ganze Product Manager Ebene kann einpacken.
Und es wird gut sein. Menschen sehen wieder, wie aus einer Kundenanforderung aus ihren Händen ein Produkt wird.
Was soll man dazu sagen? Willkommen in Deutschland.
Es kommen gefühlt nur noch so reißerische Titel, dass ich nicht mehr klicken mag. Ich kenne Eure Begründung, aber ich mag da nicht mit gehen und das auch nicht mehr in meinen Vorschlägen sehen.
Das ist schade, aber wenn das Deine Wahrnehmung ist, können wir das leider nicht ändern. Was ich daran schade finde, ist, dass Du Dich rein nur am Titel störst und deshalb diese Entscheidung triffst - denn die Videos an sich scheinen Dir ja zu gefallen.
Da wir das Ganze nicht machen, damit Videos existieren, sondern damit sich Menschen weiterbilden und informieren können, sind wir auf Aufmerksamkeit und Views angewiesen. Und das funktioniert mit den Titeln, wie wir sie aktuell machen deutlich besser als mit rein sachlichen Titeln.
Und so lange die Videos den Erwartungen an uns gerecht werden, was Inhalt & Co. angeht, finde ich die Diskussion über Titel ehrlich gesagt etwas müßig.
Natürlich kann man Jahrzehnte Organisationsforschung ignorieren und stattdessen etwas von "Angst" erzhählen, aber dann gibt es halt auch kein Like...
Natürlich kann man ein Video einfach mit einem groben Stichwort abwatschen, aber dann gibt es halt auch kein Like...
Wenn du wenigstens noch irgendwas konkretes zu der Forschung sagen würdest. Wer? Wann? Was? Damit man wenigstens irgendwie sinnvoll Google bemühen könnte, wäre dein Kommentar hilfreich gewesen. So nicht.
Du darfst gerne ein paar Buzzwords da lassen, dass man wenigstens weiterlesen kann. Danke! 🙂
Soll heißen?
@@christianbaer2897 Es haben ja viele geforscht, vielleicht findet ihr ja etwas tolles, was ich noch nicht auf dem Schirm habe. Daher wollte ich keine Suchrichtung vorgeben.
Wenn ihr doch Buzzwords wollt, dann hier: System, Mitgliedsrolle, Einfluss, Erwartung, Takt, Rang
Oder man schaut das Video wirklich und zuende, dann hätte man erlebt dass hier nicht gegen scrum gewettert wird sondern gegen die Falschanwendungen die in vielen betrieben stattfindet.
Bei uns wurde scrum leider auch dazu eingesetzt damit die Führung mehr Kontrolle hat, mehr Arbeit in alle Richtungen katapultiert würde, und wir ca. 50% - 60% unserer Zeit in allen möglichen Terminen sitzen.