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
Ich habe 7 Jahre im Konzern gehen fake agile und SAFe gekämpft. Da die scrum master und Manager alle 3 Monate wechseln fängt man jedes mal von vorne an. Dann heißt es meist: Du hast unseren Prozess scheinbar noch nicht verstanden wir haben dir ein Meeting mit einem zertifizierten agile coach angesetzt. Dieser verweist bei jedem Punkt auf einen Paragraphen im zertifizierten scrum Prozess (TM). Gegen organisierte Kriminalität lässt sich als einzelner nur schwer ankämpfen.
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.
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.
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
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 :)
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. 🙂
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.
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.
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.
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.
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.
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 :).
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).
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.
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.
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…
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.
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 😅
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.
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 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 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.
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!
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.
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
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!
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!!
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.
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
Ich habe 7 Jahre im Konzern gehen fake agile und SAFe gekämpft. Da die scrum master und Manager alle 3 Monate wechseln fängt man jedes mal von vorne an. Dann heißt es meist: Du hast unseren Prozess scheinbar noch nicht verstanden wir haben dir ein Meeting mit einem zertifizierten agile coach angesetzt. Dieser verweist bei jedem Punkt auf einen Paragraphen im zertifizierten scrum Prozess (TM).
Gegen organisierte Kriminalität lässt sich als einzelner nur schwer ankämpfen.
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.
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
Interessiere mich für euren Prozess! Gern ein Video dazu!
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
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.
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
Nach einer Firma kommt eine Firma. Glaub mir, es geht immer weiter
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) 😊
Scrum ist das beste Mittel, um Entwickler in den BurnOut zu treiben
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. 🙂
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.
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.
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.
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.
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.
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 :).
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).
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.
Bei 2:11 geht es los.
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.
Sehr schön, ich kann deinen Frust sehr gut verstehen. Da rennst du offene Türen ein.
Ich bin dankbar das es euren Kanal gibt , sehr Objektiv, thx !
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
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
Ein Video für Greator, ehemals GedankenTanken (ähnlich wie TEDx Talks). 🙏🙏🙏
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 😅
Wie sieht euer agile Prozess bei the Native Web aus?
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
Bitte zeigt mal euren Prozess. Bin neugier geworden.
Am 25. September ist es soweit: th-cam.com/users/livesORcUbCOnBw
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.
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 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 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.
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!
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).
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?
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.
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
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!
Da wundert man sich wie die methode gruppendruck und maximales monitoring missbraucht wird. Das ist die grundidee von scrum.
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!!
Jo...mach fertich!
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.
Was soll man dazu sagen? Willkommen in Deutschland.
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.