Mir wurde einmal ein Erfolgsmoment gegen eine Terminüberschreitung (welche zudem außerhalb meiner Verantwortung lag) im Appraisal ohne jegliche Kommunikation dazu gegeneinander "verrechnet". Das legt dann schon mal den Schalter um. Der im Englischen vorhandene Begriff _"You've lost me there."_ beschreibt meine anschließende Stimmungslage ziemlich treffend.
Wichtiges Video! Ich finde das der Arbeitsalltag, also z.B u.a die Wertschätzung von Chef und Kollegen enorm wichtig ist. Wer sich wohlfühlt neigt eher dazu gute Arbeit hervorzurufen als jemand der sichnicht wohlfühlt mMn.
Jene leisten auch in der Regel mehr, schreiben weniger Zeit auf als gearbeitet wird, sind gegenüber der Firma loyaler, bringen sich mehr in die Firma ein, suchen erkennen & verwirklichen Optimierungsmöglichkeiten innerhalb der Firma... etc.
@@easypy Hast recht. Im Verkauf ist es noch schlimmer. Stelle eine junge Dame oder Herren an, welche kaum die Pupertät verlassen hat, als Fillialleitung ein und du bekommst ein sehr toxisches Arbeitsklima. Im Grgenzug zum Verkauf und anderen Berufen mit minderer Ausbildung geht es in unserem Beruf eigentlich noch recht gesittet zu und her. Bitte nicht falsch verstehen, ich schätze die Leistungen vom Personal in den Einkaufsgeschäften sehr, zumal noch viele sehr offen für einen Small-Talk sind, aber eine Filiale zu führen bedarf der Grundkenntisse von Führungskompetenz Konfliktmanagement & Sozialkompetenz. Und jenen, die erst gerade die Ausbildung abgeschlossen haben, verfügen sehr oft eben nicht über die aufgezählten Kompetenzen. Viele die ich kennenlernen durft sind so von sich selbst überzeugt und extreme egoisten. Und das ist für ein Unternehmen sehr toxisch.
@@dolcegusto4106 wieviel Prozent bringen denn motivierte Mitarbeiter mehr Leistung und auch Firmenzugehörigkeit (Loyalität) mit, deiner Meinung nach? Ich würde sagen 30% Bin gespannt wie du das siehst
Год назад+10
Mich demotiviert mit Scrum zu arbeiten. Es fühlt sich für mich wie ein Gefängnis an, was mir keine Luft zum atmen gibt. #HateScrum
@@jimpanse3089 "T"oll "E"in "A"anderer "M"acht's - TEAM wird inflationär genutzt. Wird vom Fußball übernommen. Das pass hat nicht auf alle Berufszweige,,,,
Bin selbst erst (hoffentlich bald) angehender Informatiker mit nur geringen Erfahrungen in der IT Arbeitswelt. Hatte bisher ca 15 Jahre in der Produktion als Drucker gearbeitet mit ähnlichen Erfahrungen was Führungskräfte und Motivation der Mitarbeiter an geht. Was du als selbstverständliche Verhaltensregeln beschreibst findet in der echten Welt kaum statt und kostet viele Unternehmen einen haufen Geld und gutes Personal.
Hey, dann willkommen bei den Informatikern :) Ja, das ist natürlich ein Problem was es nicht nur bei uns gibt. Aber es immer wieder erstaunlich, das die kritisierende Seite das überhaupt nicht merkt! Gruß David
Ich hab auch mal in so einer Firma gearbeitet, da war es aber nicht das unfreundliche Feedback der Vorgesetzten, sondern schlechte Anforderungen, permanenter Zeitdruck, dumme Entscheidungen der Vorgesetzten, furchtbarer Projekt-Zustand, etc. Eine Feedback-Kultur gab's gar nicht, aber die Jobs waren sicher, solange man halbwegs seine Arbeit erledigt, war eigentlich egal, wie man sie macht. Die Kollegen waren super demotiviert und ich auch, in der Zeit war ich fast ständig mies gelaunt - zum Glück nur ein Jahr. Ich verstehe nicht, warum manche Vorgesetzten das nicht bemerken/verstehen, dass die Mitarbeiter und auch deren Zufriedenheit mit das höchste Gut einer Firma ist.
Hey, das Thema ist in der Tat sehr vielschichtig und ich habe auch schon viele unterschiedliche Ursachen gesehen, nur diese hier eben noch nicht in der krassen Ausprägung :) Gruß David
Sehr gutes Video! People und Mindset sind so wichtig und eine Basis für alles weitere. Erstmal ist es genau richtig, direkte Gespräche mit den Leuten zu führen als Scrum Master. Manche Kritik und Unmut wird in der Retro oftmals verschwiegen. Damit die Leute sich proaktiv einbringen und offen Feedback äußern, braucht es Vertrauen und eine gute Fehlerkultur, denn diese gibt den Menschen Wertschätzung und trägt zur Lösung der tatsächlichen Probleme bei. Ich habe auch den Eindruck, dass oftmals die Komplexität der IT unterschätzt wird oder schlichtweg kein Verständnis da ist, weshalb Deadlines nicht immer so einfach eingehalten werden können.
Und das ist genau die Aufgabe des Scrum Masters. Verständnis, Klarheit und Vertraue4n schaffen. Leicht ist es nicht und Mut gehört dazu. Aber dieser Job ist so wichtig in agilen Projekten die oft Veränderung benötigen
Hey David, erst mal ein dickes Lob für das professionell produzierte Video. Dynamisches, von der Seite in den Fokus laufen, gut geschnittene voice-overs. Macht richtig spaß beim zuschauen. Ich bin selbst extrem demotiviert. Ich habe mein Unternehmen schon abgeschrieben und suche mich nach etwas neuem um. Wenn man seine Vorgesetzten und Kollegen auf Sicherheitslücken und offensichtliche Anfängerfehler wie if(isActive == true), das verschlucken von Exceptions, das nicht schließen von Resourcen usw. hinweißt und man zu hören bekommt "ist mir doch egal, mach's doch selber!", hat man auf lange Sicht keine Lust mehr überhaupt Verbesserungsvorschläge zu geben. Ich hätte nie gedacht, dass man aus einer Leidenschaft so viel Leiden schaffen kann. Ich dachte immer meine Passion, gute Software zu schreiben, auf die man Stolz sein kann, wäre nicht zu zerstören ... naja so täuscht man sich. PS: Viele Grüße von der Klobrillenverwaltung.
"if(isActive == true)" ist nur in unkompilierten Sprachen eine kleine Performancebremse. Ein guter Compiler würde es im Zuge der Optimierung mit "if(isActive())" (ist jetzt kein Quelltext sondern ein Syntaxbaum, aber egal) ersetzen. Wenn du also eine kompilierte Sprache nutzt, kann die ausführliche Schreibweise durchaus Sinn machen, z.B. für die Lesbarkeit o.Ä.
@@MCRuCr > Ein guter Compiler würde es im Zuge der Optimierung mit "if(isActive())" [...] ersetzen dann könnten wir alle ja in Brainfuck programmieren. Hier geht es um die Lesbarkeit und die allgemeine Integrität von Quellcode. Wer soetwas schreibt: bool IsActive = false; if (IsActive == false) ... würde auch sowas, rein logisch, zulassen müssen: if ((((IsActive == true) == true) == true) == true) Was ich damit sagen möchte ist, wer nicht versteht, dass eine If-Verzweigung booleans evaluiert und stattdessen explizit den boolean mit einem boolean vergleicht, damit ein boolean raus kommt, hat einiges nicht verstanden. > Wenn du also eine kompilierte Sprache nutzt, kann die ausführliche Schreibweise durchaus Sinn machen, z.B. für die Lesbarkeit o.Ä. Auch hier würde ich dir wiedersprechen. Wenn du selbstsprechende Namen verwendest, brauchst du nicht IsActive auf true überprüfen. Die Lesbarkeit leidet eher unter der unnötigen validierung!
@@MCRuCr Bin auch drüber gestolpert, was da wohl gemeint sein könnte, abgesehen von der umständlichen Schreibweise, die ich natürlich auch nicht verwenden würde. ;)
Das vorherige Wiederholen der Feedback-Regeln habe ich zum Glück noch nie erlebt, und empfinde das als sehr merkwürdig, fast schon bis hin zu bevormundend/bemutternd, also das explizit nochmal vorher zu erwähnen wirkt so, als müsste man es tun, da sich die Leute sonst nicht anständig benehmen würden, was ich bislang nur so kenne, ganz ohne explizites Hinweisen darauf.
Sehe das ähnlich wie Du, genau diese Assoziationen habe ich auch immer. Ich habe aber immer wieder Situationen, wo ich merke das sie eben doch nicht bei allen angekommen sind und dann sorgen die auf lange Zeit schon für einige Probleme! Gruß David
Der wichtigste Punkt war der, den du am Ende gesagt hast. Wenn die Führungskraft oder Scrum Master etc. es schafft, ein Gespräch so aufzubauen, dass die "kritisierte" Person sich wertgeschätzt fühlt in ihrer Arbeit, aber intrinsisch auf einmal motiviert ist, sich weiter zu verbessern (sei es für Kollegen oder ein besseres Miteinander), weiß man dass man eine gute Führungskraft vor sich hat. Irgendwie hat man der Person gesagt, dass sie sich in diesen und jenen Bereichen verbessern kann, hat ihr aber auch ihren aktuellen Wert aufgezeigt. Die Leute, die sowas rüberbringen können, sind aber sehr selten und lassen sich natürlich ihre Fähigkeiten gut bezahlen ;)
Ich wäre ja schon froh, wenn es denn mal ehrlich gemeintes Feedback geben würde. Ich höre nur die US typischen Standardfloskeln. Mein direkter Line Manager sitzt in den USA und hat mich in den 2,5 Jahren, die er im Unternehmen ist, noch kein einziges Mal life getroffen. Die Geschäftsleitung lobt und spricht nur über die Hardware (Medizinbereich), nicht aber über meine (bin Einzelkämpfer) Software, die die Hardware überhaupt erst funktionsfähig macht. Die Meeting Regeln sind mir vertraut, aber inzwischen reduziere ich Anmerkungen auf das Nötigste, von anderen kommt größtenteils gar nichts. Aber alles wird im L10 Verfahren durchgeführt.
Dasselbe gilt, wenn Du Führungskraft bist und „nach oben“ zu berichten hast. Erst muss komme, was alles erreicht wurde. Erst dann die Defizite und ihre Gründe. Du fühlst Dich als und stellst Dein Team als underperformer dar, wenn Du das nicht beachtest. Folge: Motivationsverlust.
Dieses Thema intern anzusprechen ist fast nie möglich. Entweder wird nur der positive Teil der Argumentaton beachtet, oder man wird als Miesmacher ausgegrenzt. Als lernfähige Person adaptiere ich. Zum Thema Termintreue: Wer hat diese verbindlichen Termine entschieden? Meist habe ich den ungekehrten Scotty-Effekt erlebt: Wieviel brauchst Du mindestens um die Minimalanforderungen umzusetzen? OK, du bekommst die Hälfte der Zeit für die Maximalanforderung. Am Ende wird der "vereinbarte" Termin überschritten und die geschätzte Zeit benötigt. Der Entwickler wird für seine Unzuverlässigkeit gescholten. Dies ist auf Dauer sehr motivierend.
Ja, realistische Schätzungen mit einem gewissen Puffer für noch nicht eingeplante Verzögerungen, die praktisch immer auftreten bei neuen Projekten, will man in der Regel nicht hören. Die Aufgabe erscheint viel kleiner, als sie tatsächlich ist, wofür würde man da solange brauchen? Zumal mit mit einer Aufwandsschätzung auch als gestandener Entwickler mal satt daneben liegen kann. Insbesondere wenn dann noch unscheinbare, kleine "Ergänzungen" oder Klarstellungen bei den Anforderungen während der Entwicklung dazu kommen.
hmm.. Was mir in dem Video etwas fehlt: Es hört sich in dem Video immer so an, als wenn der Softwareentwickler immer Schuld ist und der "Tipp" darin liegt ihn positiv anzusprechen, damit er motiviert weiterarbeitet. Könnte es nicht sein, dass die Ziele vielleicht gar nicht realistisch waren und Zeiten vollkommen aus dem Bauch heraus genannt wurden ohne sich vorher klar zu machen, was dafür alles erforderlich ist? Sollte der "Tipp" nicht evtl. sein zu lernen wie man realistischere Ziele setzen kann und sich auch gedanken sazu macht, was benötigt wird um diese Ziele zu erreichen (neben der Zeit)?
Diese Führungskräfte schienen aber besonders gut darin gewesen zu sein, die Leute bei der Stange zu halten. Normalerweise bleiben Entwickler nicht all zu lange in so einem Saftladen...
Doch es ist eine relativ ungewöhnliche Situation, dass das jahrelang andauert. Normalerweise verschwinden die Entwickler oder die Firma geht pleite....
Das kommt auf die Branche und die Tätigkeitsbereiche des Unternehmen an. Wenn zum Beispiel eine Abteilung maßgeblich das große Geld ranschafft, kann die Firma die Mehrkosten, die durch Demotivation und daraus resultierender Unproduktivität entstehen, gut ausgleichen. Dann kann es natürlich dazu kommen, dass einfach mehr Geld und Personal draufgeworfen wird, ohne dass sich mit den Ursachen auseinandergesetzt wird. Das Unternehmen macht weiterhin schwarze Zahlen, auch wenn viele Projekte die Segel Richtung Abgrund gesetzt haben.
Sofern die Anwendung annähernd monolithisch ist, und sich auf der Einnahmeseite alles im grünen Bereich befindet lässt sich sowas im Großunternehmen recht lange aussitzen… Die Rechte weiß nicht mehr was die Linke tut? Läuft!
Ja kenne ich, aber ganz klare Aufgabe des SCRUM MASTER. Ein Team zum reden bringen. Wenn Ihr nicht redet, kann ich als SM nichts Ändern..... Und Änderungen müssen dann auch passieren! Ganz wichtig, Aufgabe des SM! Und ja wenn Entscheider nicht mitspielen... Schütze ich mein Team als SM! Ich habe deswegen schon einen Job verloren, wo ich auch nicht traurig drüber bin. Aber es zeigt sich wie wichtig ein guter SM ist. Die Frage ist, wieviel Prozent Leistung verliere ich von einem unmotivierten Team? 30 - 50%? Liebe Grüße aus Bremen
Viel Wahres wurde gesagt. Feedback üben ist wichtig, aber das reicht oft nicht. Wir Menschen merken oft sehr schnell, wenn Wertschätzung antrainiert und nicht authentisch ist. Das Ganze ist am Ende ein Glaubwürdigkeits- und Vertrauensthema. Auf der anderen Seite muss man auch akzeptieren, dass Missstände mal angesprochen werden. Manche Leute sind auch übersensibel, was Kritik angeht. Man muss auch das Einstecken mal üben. Gute Scrum Master haben die emotionale Intelligenz, im Team dafür den richtigen Ton zu treffen. Um wertschätzende Kommunikation sollten wir aber alle grundsätzlich bemüht sein, immer und in allen Lebensbereichen.
Forming, Storming, Norming, Performing und Adjourning. Ich glaube das ist wirklich so. Nicht wie nach dem Lehrbuch. Aber jede Veränderung kann ein Team verändern. Sei es in der Wortwahl, wie kommt ein neues Teammitglied ins Team und auch wie wurde das neue Teammitglied ausgewählt .....
Das ist natürlich nur eine Seite der Geschichte. Irgendwann verliert man auch die Geduld mit den Feedbackregeln, wenn sich nichts ändert. Letztes Jahr musste ich 2 Monate lang um einen Entwickler herum tanzen mit Feedback Sandwich etc. und trotzdem hat er es nicht geschafft, nach 2 Monaten auch nur einen commit zu machen, der nicht gegen absolute basis Java code conventions verstieß (geschweige denn kompiliert oder gar fachliche das tat, was er sollte). Gerade in Zeiten leergefegter Arbeitsmärkte kombiniert mit Scrum Mastern (wannabe Projekt Manager) frisch von der Uni und dem 3 Tage Scrum Kurs sind etliche Teams entstanden, die wirklich keine akzeptable Arbeit leisten, aber gleichzeitig beratungsresistent darauf pochen, dass das schon alles so richtig ist mit dem Spaghetticode weil Scrum! Da hilft ein Polter-Feedback dann natürlich auch nicht, aber ich kann auch Manager verstehen, die irgendwann keine Geduld mehr haben, wenn das konstruktive Feedback einfach nichts ändert über Monate hinweg, man aber wegen anderer Einflüsse auch nichts grundlegendes ändern kann.
Nur weil Dinge freundlich formuliert werden, ändern sich die Dinge dadurch nicht. Ob der Manager sagt "Du Depp bist zu langsam" oder "Wir können an der Termintreue optimieren" kommt genau gleich an. Nur hat man keine Erlaubnis mehr, auf den Manager sauer zu sein, weil er ja freundlich formuliert hat. Also schuld sind immer die Indianer, nie der Häuptling. Motivation kommt nicht durch Laberrhetorik, sondern dadurch dass man im täglichen Leben selbst Einfluss hat.
Ich kenne inzwischen beide Extreme. Einmal das in dem Video aber auch genau das Gegenteil. Das die Entwickler so mit Samthandschuhen angefasst wurden, dass sie gar nicht wussten, dass die Deadlines ernst gemeint sind. Da hat sich keiner Mühe gegeben die Deadlines zu halten, sondern hat einfach seinen Stiefel durchgezogen.
Wenn man mehrere Jahre gegen festgefahrene Ansichten prallt und konstruktive Kritik verhallt und zum teil aktiv mundtot gemacht wird, zieht man oft die Karte Dienst nach Vorschrift. Personalführung ist oft nicht ausreichend qualifiziert. Sage ich dazu mal freundlichen ausgedrückt. 😅
Aber begibt man sich hier nicht in die gefahr um den heißen brei herumzureden und alles positiv auszuschmücken?! Mich erinnert das ein bisschen an das Kompliment Sandwich. David ich mag deine Brille 👓 David das video fand ich etwas kurz für das Thema, Aber hey David, coole Bilder aus Winterberg 😊 Hier nochmal humoristisch in family guy aufgearbeitet: ruclips.net/video/ewIT_KAQQlU/видео.html
Hey, es geht ja nicht darum, das negative nicht anzusprechen sondern bei aller Kritik auch dem anderen hin und wieder Wertschätzung zukommen zu lassen. Wenn du von einer vorgesetzten Rolle immer nur Kritik bekommst und selten Lob, sinkt die Arbeitsmoral schnell ab. Gruß David
@@DavidTielke das stimmt. Ein Vorgesetztenverhalten ist nochmal anders zu bewerten. Ich hatte bisher in Retros die Erfahrung gehabt, dass sehr viele Menschen mit Kritik nicht wirklich gut umgehen konnten und man hier immer sehr viel positives "mitsenden" musste - deshalb die Sache mit dem Komplimente Sandwich^^ Ich persönlich bin immer ein Freund davon -gerade raus zu sagen, was gut lief und was nicht so gut lief. Egal von welcher Rolle das kam. Natürlich entsprechend wertschätzend forumuliert. Ich denke da ist schon viel gewonnen
Manche finden sie sind doch sehr bemüht positive Dinge anzusprechen. Dann haben aber die Untergebenen irgendwann gelernt, dass so jemand eigentlich nur dann was positives sagt, wenn danach ein Hammer kommt.
Mir ist bewusst, dass dieses Kommentar gerade nicht ganz passt und nur am Thema anstreift, aber... Wie kann man bessere Deadlines machen bzw. Deadlines überhaupt verhindern? Der Grund wieso ich das anspreche ist, dass man es seeehr oft nicht einhalten kann. Nur wenn es um bereits Bestehendes in abgeänderter Form geht, kann man gute Deadlines erstellen. Doch wenn es um etwas wirklich neues geht, wie kann man dabei "Vorhersagen"/Schätzungen erstellen? Mir wäre ein "Update" Datum in den Sinn gekommen, oder eine fehlerhafte Deadline.
das beantwortet die Frage jetzt leider noch nicht, aber ich habe mal in einem Buch gelesen, dass diese Formulierung wesentlich freundlicher wäre: "LIFELINE", immerhin soll hier ja etwas Neues ins Leben gebracht und nichts begraben werden ;o)
@@drchaotika ist aber trotzdem sehr hilfreich! Lifeline sagt gleich viel mehr aus als Deadline! Somit kann man sich auch gleich viel spezifischer äußern und mit anderen verwandten Mustern agieren! Sehr nice! Danke!
Hey, Lifeline klingt gut :) Mache in einigen Wochen Videos zum Thema Projektmanagement in der SE, da wird das u.a. das Thema sein :) Pauschal beantworten kann ich das hier leider nicht, weil es von sehr vielen Faktoren abhängig ist. Gruß David
Das du die Kommunikation von Verbesserungsmöglichkeiten als TRICK bezeichnest finde ich nicht gut. Wenn man nicht gerade als Stein geboren wurde, merkt man doch, ob etwas ernst und ehrlich gemeint ist, oder ob es nur Mittel zum Zweck ist. Ansonsten ist das Phänomen weit verbreitet in unserer Arbeitswelt, und nicht wenige Führungskräfte sind stolz auf ihre "Überlegenheit". Danke, dass du das hier einmal thematisiert hast.
Ich durfte bereits einmal erleben, wie ein Geschäftsführer, selbst noch Entwickler, ein kommplettes Team gesprengt hat. Fazit: Am Ende stand er nur noch mit seinen Azubis da. Alle anderen sind innerhalb von 4 Mt. davon gelaufen...
Habe ich tatsächlich bei einer Firma im Oberbergischer Kreis auch erlebt. Da haben die Söhne des Geschäftsführers das Softwareteam auch auseinandergenommen… Manche sind halt gleicher als andere.
@@tangsun4797 Und wer war am Ende schuld? In meinem Fall waren auschliesslich die Mitarbeiter aus der Sicht des Geschäftsführers. Somit waren aich die Mitarbeiter schuld, dass so viel Know-How abgeflossen ist und viel Geld verlohren ging. Tja. Plug & Play funzt halt nicht überall...
Hey, ja genau so etwas erlebe ich auch hin und wieder, mache ja immer wieder Videos zum Thema "People in der Softwareentwicklung" - das zahlt da auch mit ein. Am Ende endet das fast immer in einem Desaster! Gruß David
Es kann auch Chefs geben, die nie zufrieden sind. Sonst müssten sie ihre "Abhängigen" besser bezahlen. Die Chefs glauben, mit Unzufriedenheit mehr Leistung herauszuholen, was aber nur begrenzt funktioniert und auch mal umkippen kann.
Ich glaube eher, die meisten Vorgesetzten haben von dem Produkt keine Ahnung. Es ist schwer ruhig und gelassen zu sein, wenn du nicht abschätzen kannst, was deine Entwickler machen. Das gilt selbst für Entwickler, die in der Führungsspitze sitzen. Wenn du den benötigten Stack nicht hast, weißt du häufig nicht was die Entwickler gerade machen. Das ganze Projekt ist eine Blackbox. Und die wenigsten Entscheidungsträger vertrauen ihre Entwickler. Also müssen sie kontrolliert werden. Die permanente Kontrolle macht alles nur noch schlimmer. Ich habe selten eine Führungskraft erlebt, die gefragt hat, was das Team braucht.
Bin grade erst in den ersten Minuten des Videos, aber irgendwie ist der Bass in der ersten Minute kaum vorhanden oder ich täusche mich, dann ab 0:51 ist der Sound crystal-clear und perfekt, wie man ihn kennt.
Verwendet im ersten und den restlichen Shots zwei unterschiedliche Mikrofone - das im ersten ist in der Tat sehr "hell" und das restliche ist basslastiger. Leider habe ich das beim ersten nicht gemerkt und den Equalizer vergessen, demnächst achte ich darauf! Danke!
Ich kann aus eigener Erfahrung als PO und Scrum Master, allgemein als Projektverantwortlicher berichten, dass oft auch ganz simpel die Disziplin einzelner Entwickler erheblich zu wünschen übrig lässt, was oft aussieht wie fehlende Motivation. Ich kenne die eingangs beschriebenen Situationen perfekt, es gibt eine Retrospektive und keine Sau gibt bis zum Termin Feedback ab, Leute kommen zum Daily grundsätzlich 5-10 Minuten zu spät, etc. Man beißt sich echt die Zähne aus. Ein großer Punkt ist auch oft, dass vor allem junge Entwickler ein Maß an Überheblichkeit mitbringen, das mir völlig fremd ist. Viele Entwickler halten jedes Meeting für überflüssig, tun sich mit Kommunikation so schwer dass sie jegliche Art von Abstimmung aus tiefen Unmut heraus ablehnen.. etc. Ich finde, dass Motivation durchaus auch im Verantworungsbereich des Einzelnen liegt. Hochqualifizierte Leute mit sechsstellingen Gehältern können sich einfach nicht alleine hinter ihrer fachlichen Kompetenz verstecken. Man muss schlicht ein Mindestmaß an Lust und Kommunikation mitbringen. Den Vorwurf mit dem Missmanagement kenne ich auch, aber dazu muss ich ganz klar sagen, dass dies zwar richtig ist aber zwei dazu gehören. Es gibt die unangenehmen Punkte, es gibt auch die Choleriker und Stresser. Es gibt aber auch die Entwickler, denen man erst im Daily, im Weekly, oder zum Abgabetermin die Infos aus der Nase ziehen muss wie es jetzt eigentlich um den Stand ihrer Arbeit bestellt ist. Für mich ist das Problem einfach oft, dass Entwickler eine eigenartige Spezies sind. Viele halten sich gegenüber den anderen Kollegen für etwas besseres, sie haben oft fehlende Kommunikationsskills und meistens fehlt ihnen der betriebswirtschaftliche Blick auf interne Prozesse und das Verständnis vom Miteinander zwischen Unternehmen und Kunden. Sie haben oft jeglichen Anspruch an Form und Floskeln verloren, wollen selten an sozialen Events teilnehmen und wollen generell kaum vor Ort sein. Ich finde, dass IT-Fachkräfte oft grundlos überbezahlt sind, man sich gar oft vor ihrer Qualifikation und Arbeit fürchtet, und dadurch genau die Situation entsteht die ich beschrieben habe. Wären Entwickler im Tagesgeschäft auf Augenhöhe mit anderen ausgebildeten und studierten Kollegen, wären sie viel mehr gezwungen sich vernünftig zu integrieren.
Das klingt so als ob da etwas grundsätzlich in der Arbeitsatmosphäre schief läuft und das Bemühen um Besserung eher in Ermahnung als in konstruktiver Verbesserung (Schulung oder konstruktive Gesprächsrunden) steckt oder man beim Recruiting komplett gepennt hat und sich den nächstbesten von der Straße gekratzt hat... Oft liegt das Problem generell in der Firmenkultur bzw. in Ermangelung dieser begründet. Das wird gern ausgeblendet, weil sich oft trotzdem viele Leute damit arrangieren können.
Miteinander, und wirklich miteinander, Spielregeln ausmachen, den Wert und Vorteile der Spielregeln nochmals verdeutlichen. Danach auf die Einhaltung der Spielregeln pochen und selbst integer vorleben. Falls die Regeln nicht eingehalten werden, erinnern, dass man sich auf diese Regeln miteinander geeinigt hat. Und falls das nicht wirkt, muss es auch Konsequenzen geben.
@@Tunkali - _"und sich den nächstbesten von der Straße gekratzt hat..."_ … gemäß dieser Facharbeitskräftemangelsituation wird dann nach folgendem Motto rekrutiert… _"Unter den Blinden ist der Einäugige König"_ …was dann in Konsequenz so aussieht: ein Scrum Master hantiert ein Rudel (grenzautistisch) vermeintlicher Könige - nahezu deckungsgleich in der Rolle eines Hofnarren - der seine Durchlauchtigkeiten bei Stimmung halten muß. Priceless
Hey David, heute kann ich Dir leider nur bedingt zustimmen. Permanent Kritik anbringen und nie das Positive hervorheben, das wird auf Dauer schief gehen. Ich bin aber der Meinung das wir als Gesellschaft und jeder einzelne einfach auch lernen müssen/sollten, Kritik anzunehmen und an sich selber zu arbeiten, keiner ist schließlich perfekt. Es kann nicht sein das man ständig nur mit Samthandschuhen angefasst werden muss. Wenn ich was verbockt habe, dann habe ich es nun einmal verbockt, da kann man auch nichts schönreden. Aber und das finde ich wichtig, man sollte es nicht dabei belassen sondern mich dann abholen und nachfragen woran es lag bzw. anbieten an dem Umstand der dazu geführt hat zu arbeiten. Aber wie immer gilt, komplexes Thema das nach 10 Minuten Video und wenigen Zeilen Kommentar unendlich erweiterbar wäre.
Aber der Ton macht die Musik! Ich habe auch schon in Teams gearbeitet, bei denen oft unfreundliche Kritik geübt wurde, das ist auf Dauer sehr demotivierend. Inzwischen habe ich das Glück in einem Unternehmen mit sehr guter Arbeitsatmosphäre zu arbeiten, da kommt ab und an ein angemessenes Lob, und das motiviert sehr! Und falls mal Kritik kommt, dann mit Respekt und auf Augenhöhe, und vor allem konstruktiv um das Problem gemeinsam zu lösen, da fällt das Annehmen schon wesentlich leichter.
Hey, so ehr widersprichst Du mir gar nicht - sehe das ähnlich wie Du, ABER: (ich zitiere @drchaotika6203): der Ton und die Menge macht die Musik. Klar müssen Missstände klar und offen kommuniziert werden, um besser zu werden. ALLERDINGS sollte man auch positiv erreichte Dinge würdigen (von denen gab es einige) und nicht immer nur "auftauchen" wenn etwas schlecht war und dann in einem rein negativen Ton diese Kritik rüberbrngen. Das bringt nichts. Aber wie @thomaseichinger1717 schon sagte, das Thema ist sehr komplex - hier ging es nur um diese einzelne Geschichte, nicht um den gesamten Sachverhalt! Gruß David
Entwickler sind in der Regel ihre eigenen schärfsten Kritiker, wenn die Stimmung gut und die Umgebung stimmig ist. Selbstorganisation ist nicht ohne Grund eines der wichtigsten agilen Prinzipien: Die Entwickler sind die Experten, nicht der PO, HR oder irgendein GF. In einer vertrauensvollen Umgebung wird das zu guten Ergebnissen führen. In eher negativ eingestellten Umgebungen wird's schwieriger, erfordert außerordentlich starke Entwicklerpersönlichkeiten, die sich beständig entgegen stellen - trotzdem nutzt es einen auf Dauer ab.
Mir wurde einmal ein Erfolgsmoment gegen eine Terminüberschreitung (welche zudem außerhalb meiner Verantwortung lag) im Appraisal ohne jegliche Kommunikation dazu gegeneinander "verrechnet".
Das legt dann schon mal den Schalter um. Der im Englischen vorhandene Begriff _"You've lost me there."_ beschreibt meine anschließende Stimmungslage ziemlich treffend.
Wichtiges Video!
Ich finde das der Arbeitsalltag, also z.B u.a die Wertschätzung von Chef und Kollegen enorm wichtig ist.
Wer sich wohlfühlt neigt eher dazu gute Arbeit hervorzurufen als jemand der sichnicht wohlfühlt mMn.
Jene leisten auch in der Regel mehr, schreiben weniger Zeit auf als gearbeitet wird, sind gegenüber der Firma loyaler, bringen sich mehr in die Firma ein, suchen erkennen & verwirklichen Optimierungsmöglichkeiten innerhalb der Firma... etc.
Hey, bin komplett bei Euch - aber die Leute erkennen das zu wenig, das ist leider das Problem
Gruß David
Ist nicht nur in unserem Beruf ein Problem :D Zieht sich durch die komplette Gesellschaft
Beste Grüße
@@easypy
Hast recht. Im Verkauf ist es noch schlimmer. Stelle eine junge Dame oder Herren an, welche kaum die Pupertät verlassen hat, als Fillialleitung ein und du bekommst ein sehr toxisches Arbeitsklima. Im Grgenzug zum Verkauf und anderen Berufen mit minderer Ausbildung geht es in unserem Beruf eigentlich noch recht gesittet zu und her.
Bitte nicht falsch verstehen, ich schätze die Leistungen vom Personal in den Einkaufsgeschäften sehr, zumal noch viele sehr offen für einen Small-Talk sind, aber eine Filiale zu führen bedarf der Grundkenntisse von Führungskompetenz Konfliktmanagement & Sozialkompetenz. Und jenen, die erst gerade die Ausbildung abgeschlossen haben, verfügen sehr oft eben nicht über die aufgezählten Kompetenzen. Viele die ich kennenlernen durft sind so von sich selbst überzeugt und extreme egoisten. Und das ist für ein Unternehmen sehr toxisch.
@@dolcegusto4106 wieviel Prozent bringen denn motivierte Mitarbeiter mehr Leistung und auch Firmenzugehörigkeit (Loyalität) mit, deiner Meinung nach?
Ich würde sagen 30% Bin gespannt wie du das siehst
Mich demotiviert mit Scrum zu arbeiten. Es fühlt sich für mich wie ein Gefängnis an, was mir keine Luft zum atmen gibt. #HateScrum
Es kann schön und effektiv sein, wenn man die richtigen Leute im Team (ich hasse dieses Wort) hat.
@@markusrankl973Team ist doch ein normales gutes Wort?
@@jimpanse3089 "T"oll "E"in "A"anderer "M"acht's - TEAM wird inflationär genutzt. Wird vom Fußball übernommen. Das pass hat nicht auf alle Berufszweige,,,,
Bin selbst erst (hoffentlich bald) angehender Informatiker mit nur geringen Erfahrungen in der IT Arbeitswelt. Hatte bisher ca 15 Jahre in der Produktion als Drucker gearbeitet mit ähnlichen Erfahrungen was Führungskräfte und Motivation der Mitarbeiter an geht. Was du als selbstverständliche Verhaltensregeln beschreibst findet in der echten Welt kaum statt und kostet viele Unternehmen einen haufen Geld und gutes Personal.
Hey, dann willkommen bei den Informatikern :) Ja, das ist natürlich ein Problem was es nicht nur bei uns gibt. Aber es immer wieder erstaunlich, das die kritisierende Seite das überhaupt nicht merkt!
Gruß David
Ich hab auch mal in so einer Firma gearbeitet, da war es aber nicht das unfreundliche Feedback der Vorgesetzten, sondern schlechte Anforderungen, permanenter Zeitdruck, dumme Entscheidungen der Vorgesetzten, furchtbarer Projekt-Zustand, etc. Eine Feedback-Kultur gab's gar nicht, aber die Jobs waren sicher, solange man halbwegs seine Arbeit erledigt, war eigentlich egal, wie man sie macht.
Die Kollegen waren super demotiviert und ich auch, in der Zeit war ich fast ständig mies gelaunt - zum Glück nur ein Jahr.
Ich verstehe nicht, warum manche Vorgesetzten das nicht bemerken/verstehen, dass die Mitarbeiter und auch deren Zufriedenheit mit das höchste Gut einer Firma ist.
Hey,
das Thema ist in der Tat sehr vielschichtig und ich habe auch schon viele unterschiedliche Ursachen gesehen, nur diese hier eben noch nicht in der krassen Ausprägung :)
Gruß David
Boah dieses Video spiegelt meine Situation so krass, ich danke dir für das Video!
Sehr gutes Video!
People und Mindset sind so wichtig und eine Basis für alles weitere.
Erstmal ist es genau richtig, direkte Gespräche mit den Leuten zu führen als Scrum Master. Manche Kritik und Unmut wird in der Retro oftmals verschwiegen.
Damit die Leute sich proaktiv einbringen und offen Feedback äußern, braucht es Vertrauen und eine gute Fehlerkultur, denn diese gibt den Menschen Wertschätzung und trägt zur Lösung der tatsächlichen Probleme bei.
Ich habe auch den Eindruck, dass oftmals die Komplexität der IT unterschätzt wird oder schlichtweg kein Verständnis da ist, weshalb Deadlines nicht immer so einfach eingehalten werden können.
Und das ist genau die Aufgabe des Scrum Masters. Verständnis, Klarheit und Vertraue4n schaffen.
Leicht ist es nicht und Mut gehört dazu. Aber dieser Job ist so wichtig in agilen Projekten die oft Veränderung benötigen
Hey David, erst mal ein dickes Lob für das professionell produzierte Video. Dynamisches, von der Seite in den Fokus laufen, gut geschnittene voice-overs. Macht richtig spaß beim zuschauen.
Ich bin selbst extrem demotiviert. Ich habe mein Unternehmen schon abgeschrieben und suche mich nach etwas neuem um. Wenn man seine Vorgesetzten und Kollegen auf Sicherheitslücken und offensichtliche Anfängerfehler wie if(isActive == true), das verschlucken von Exceptions, das nicht schließen von Resourcen usw. hinweißt und man zu hören bekommt "ist mir doch egal, mach's doch selber!", hat man auf lange Sicht keine Lust mehr überhaupt Verbesserungsvorschläge zu geben. Ich hätte nie gedacht, dass man aus einer Leidenschaft so viel Leiden schaffen kann. Ich dachte immer meine Passion, gute Software zu schreiben, auf die man Stolz sein kann, wäre nicht zu zerstören ... naja so täuscht man sich.
PS: Viele Grüße von der Klobrillenverwaltung.
"if(isActive == true)" ist nur in unkompilierten Sprachen eine kleine Performancebremse. Ein guter Compiler würde es im Zuge der Optimierung mit "if(isActive())" (ist jetzt kein Quelltext sondern ein Syntaxbaum, aber egal) ersetzen.
Wenn du also eine kompilierte Sprache nutzt, kann die ausführliche Schreibweise durchaus Sinn machen, z.B. für die Lesbarkeit o.Ä.
@@MCRuCr
> Ein guter Compiler würde es im Zuge der Optimierung mit "if(isActive())" [...] ersetzen
dann könnten wir alle ja in Brainfuck programmieren.
Hier geht es um die Lesbarkeit und die allgemeine Integrität von Quellcode.
Wer soetwas schreibt:
bool IsActive = false;
if (IsActive == false) ...
würde auch sowas, rein logisch, zulassen müssen:
if ((((IsActive == true) == true) == true) == true)
Was ich damit sagen möchte ist, wer nicht versteht, dass eine If-Verzweigung booleans evaluiert und stattdessen explizit den boolean mit einem boolean vergleicht, damit ein boolean raus kommt, hat einiges nicht verstanden.
> Wenn du also eine kompilierte Sprache nutzt, kann die ausführliche Schreibweise durchaus Sinn machen, z.B. für die Lesbarkeit o.Ä.
Auch hier würde ich dir wiedersprechen.
Wenn du selbstsprechende Namen verwendest, brauchst du nicht IsActive auf true überprüfen.
Die Lesbarkeit leidet eher unter der unnötigen validierung!
@@MCRuCr Bin auch drüber gestolpert, was da wohl gemeint sein könnte, abgesehen von der umständlichen Schreibweise, die ich natürlich auch nicht verwenden würde. ;)
verrückt, dass sich das Management so überhaupt halten kann. Entwickler machen einfach viel zu viel einfach mit.
Moin David!
Danke dir für dieses Video!
Wir haben ähnliche Herausforderungen :-)
Hey Tobias,
sehr gerne - schön das es Dir gefällt, dann leite es mal an die entsprechenden Stellen weiter... :D
Gruß David
Das vorherige Wiederholen der Feedback-Regeln habe ich zum Glück noch nie erlebt, und empfinde das als sehr merkwürdig, fast schon bis hin zu bevormundend/bemutternd, also das explizit nochmal vorher zu erwähnen wirkt so, als müsste man es tun, da sich die Leute sonst nicht anständig benehmen würden, was ich bislang nur so kenne, ganz ohne explizites Hinweisen darauf.
Sehe das ähnlich wie Du, genau diese Assoziationen habe ich auch immer. Ich habe aber immer wieder Situationen, wo ich merke das sie eben doch nicht bei allen angekommen sind und dann sorgen die auf lange Zeit schon für einige Probleme!
Gruß David
Der wichtigste Punkt war der, den du am Ende gesagt hast. Wenn die Führungskraft oder Scrum Master etc. es schafft, ein Gespräch so aufzubauen, dass die "kritisierte" Person sich wertgeschätzt fühlt in ihrer Arbeit, aber intrinsisch auf einmal motiviert ist, sich weiter zu verbessern (sei es für Kollegen oder ein besseres Miteinander), weiß man dass man eine gute Führungskraft vor sich hat.
Irgendwie hat man der Person gesagt, dass sie sich in diesen und jenen Bereichen verbessern kann, hat ihr aber auch ihren aktuellen Wert aufgezeigt. Die Leute, die sowas rüberbringen können, sind aber sehr selten und lassen sich natürlich ihre Fähigkeiten gut bezahlen ;)
Ich wäre ja schon froh, wenn es denn mal ehrlich gemeintes Feedback geben würde. Ich höre nur die US typischen Standardfloskeln. Mein direkter Line Manager sitzt in den USA und hat mich in den 2,5 Jahren, die er im Unternehmen ist, noch kein einziges Mal life getroffen. Die Geschäftsleitung lobt und spricht nur über die Hardware (Medizinbereich), nicht aber über meine (bin Einzelkämpfer) Software, die die Hardware überhaupt erst funktionsfähig macht.
Die Meeting Regeln sind mir vertraut, aber inzwischen reduziere ich Anmerkungen auf das Nötigste, von anderen kommt größtenteils gar nichts. Aber alles wird im L10 Verfahren durchgeführt.
Tolles Video.
Wie man in einen Wald hineinruft, so schallt es heraus.
Dasselbe gilt, wenn Du Führungskraft bist und „nach oben“ zu berichten hast. Erst muss komme, was alles erreicht wurde. Erst dann die Defizite und ihre Gründe. Du fühlst Dich als und stellst Dein Team als underperformer dar, wenn Du das nicht beachtest. Folge: Motivationsverlust.
Dieses Thema intern anzusprechen ist fast nie möglich. Entweder wird nur der positive Teil der Argumentaton beachtet, oder man wird als Miesmacher ausgegrenzt. Als lernfähige Person adaptiere ich. Zum Thema Termintreue: Wer hat diese verbindlichen Termine entschieden? Meist habe ich den ungekehrten Scotty-Effekt erlebt: Wieviel brauchst Du mindestens um die Minimalanforderungen umzusetzen? OK, du bekommst die Hälfte der Zeit für die Maximalanforderung. Am Ende wird der "vereinbarte" Termin überschritten und die geschätzte Zeit benötigt. Der Entwickler wird für seine Unzuverlässigkeit gescholten. Dies ist auf Dauer sehr motivierend.
Ja, realistische Schätzungen mit einem gewissen Puffer für noch nicht eingeplante Verzögerungen, die praktisch immer auftreten bei neuen Projekten, will man in der Regel nicht hören. Die Aufgabe erscheint viel kleiner, als sie tatsächlich ist, wofür würde man da solange brauchen? Zumal mit mit einer Aufwandsschätzung auch als gestandener Entwickler mal satt daneben liegen kann. Insbesondere wenn dann noch unscheinbare, kleine "Ergänzungen" oder Klarstellungen bei den Anforderungen während der Entwicklung dazu kommen.
hmm.. Was mir in dem Video etwas fehlt: Es hört sich in dem Video immer so an, als wenn der Softwareentwickler immer Schuld ist und der "Tipp" darin liegt ihn positiv anzusprechen, damit er motiviert weiterarbeitet.
Könnte es nicht sein, dass die Ziele vielleicht gar nicht realistisch waren und Zeiten vollkommen aus dem Bauch heraus genannt wurden ohne sich vorher klar zu machen, was dafür alles erforderlich ist? Sollte der "Tipp" nicht evtl. sein zu lernen wie man realistischere Ziele setzen kann und sich auch gedanken sazu macht, was benötigt wird um diese Ziele zu erreichen (neben der Zeit)?
Diese Führungskräfte schienen aber besonders gut darin gewesen zu sein, die Leute bei der Stange zu halten. Normalerweise bleiben Entwickler nicht all zu lange in so einem Saftladen...
Interessant wäre jetzt aber mal zu wissen, ob das Analyseergebnis tatsächlich zu einem Umdenken bei der Führungsebene geführt hat.
Doch es ist eine relativ ungewöhnliche Situation, dass das jahrelang andauert. Normalerweise verschwinden die Entwickler oder die Firma geht pleite....
Das kommt auf die Branche und die Tätigkeitsbereiche des Unternehmen an. Wenn zum Beispiel eine Abteilung maßgeblich das große Geld ranschafft, kann die Firma die Mehrkosten, die durch Demotivation und daraus resultierender Unproduktivität entstehen, gut ausgleichen. Dann kann es natürlich dazu kommen, dass einfach mehr Geld und Personal draufgeworfen wird, ohne dass sich mit den Ursachen auseinandergesetzt wird. Das Unternehmen macht weiterhin schwarze Zahlen, auch wenn viele Projekte die Segel Richtung Abgrund gesetzt haben.
Sofern die Anwendung annähernd monolithisch ist, und sich auf der Einnahmeseite alles im grünen Bereich befindet lässt sich sowas im Großunternehmen recht lange aussitzen…
Die Rechte weiß nicht mehr was die Linke tut? Läuft!
27 Jahre arbeite ich in dieser Branche. Ich gebe dir recht.
Ja kenne ich, aber ganz klare Aufgabe des SCRUM MASTER.
Ein Team zum reden bringen. Wenn Ihr nicht redet, kann ich als SM nichts Ändern.....
Und Änderungen müssen dann auch passieren! Ganz wichtig, Aufgabe des SM!
Und ja wenn Entscheider nicht mitspielen... Schütze ich mein Team als SM!
Ich habe deswegen schon einen Job verloren, wo ich auch nicht traurig drüber bin.
Aber es zeigt sich wie wichtig ein guter SM ist.
Die Frage ist, wieviel Prozent Leistung verliere ich von einem unmotivierten Team? 30 - 50%?
Liebe Grüße aus Bremen
Oh Hilfe, Scrum gibt's immer noch?
@@StefanReich Was wäre denn die bessere Wahl?
Ich freue mich wenn es etwas einfacheres gibt...
SM? Ist das jetzt nur Zufall das hier ausgerechnet Marquis de Sade…?
Viel Wahres wurde gesagt. Feedback üben ist wichtig, aber das reicht oft nicht. Wir Menschen merken oft sehr schnell, wenn Wertschätzung antrainiert und nicht authentisch ist. Das Ganze ist am Ende ein Glaubwürdigkeits- und Vertrauensthema. Auf der anderen Seite muss man auch akzeptieren, dass Missstände mal angesprochen werden. Manche Leute sind auch übersensibel, was Kritik angeht. Man muss auch das Einstecken mal üben. Gute Scrum Master haben die emotionale Intelligenz, im Team dafür den richtigen Ton zu treffen. Um wertschätzende Kommunikation sollten wir aber alle grundsätzlich bemüht sein, immer und in allen Lebensbereichen.
Forming, Storming, Norming, Performing und Adjourning. Ich glaube das ist wirklich so. Nicht wie nach dem Lehrbuch.
Aber jede Veränderung kann ein Team verändern. Sei es in der Wortwahl, wie kommt ein neues Teammitglied ins Team und auch wie wurde das neue Teammitglied ausgewählt .....
Das ist natürlich nur eine Seite der Geschichte. Irgendwann verliert man auch die Geduld mit den Feedbackregeln, wenn sich nichts ändert. Letztes Jahr musste ich 2 Monate lang um einen Entwickler herum tanzen mit Feedback Sandwich etc. und trotzdem hat er es nicht geschafft, nach 2 Monaten auch nur einen commit zu machen, der nicht gegen absolute basis Java code conventions verstieß (geschweige denn kompiliert oder gar fachliche das tat, was er sollte).
Gerade in Zeiten leergefegter Arbeitsmärkte kombiniert mit Scrum Mastern (wannabe Projekt Manager) frisch von der Uni und dem 3 Tage Scrum Kurs sind etliche Teams entstanden, die wirklich keine akzeptable Arbeit leisten, aber gleichzeitig beratungsresistent darauf pochen, dass das schon alles so richtig ist mit dem Spaghetticode weil Scrum! Da hilft ein Polter-Feedback dann natürlich auch nicht, aber ich kann auch Manager verstehen, die irgendwann keine Geduld mehr haben, wenn das konstruktive Feedback einfach nichts ändert über Monate hinweg, man aber wegen anderer Einflüsse auch nichts grundlegendes ändern kann.
Nur weil Dinge freundlich formuliert werden, ändern sich die Dinge dadurch nicht. Ob der Manager sagt "Du Depp bist zu langsam" oder "Wir können an der Termintreue optimieren" kommt genau gleich an. Nur hat man keine Erlaubnis mehr, auf den Manager sauer zu sein, weil er ja freundlich formuliert hat. Also schuld sind immer die Indianer, nie der Häuptling. Motivation kommt nicht durch Laberrhetorik, sondern dadurch dass man im täglichen Leben selbst Einfluss hat.
Ich kenne inzwischen beide Extreme.
Einmal das in dem Video aber auch genau das Gegenteil.
Das die Entwickler so mit Samthandschuhen angefasst wurden, dass sie gar nicht wussten, dass die Deadlines ernst gemeint sind.
Da hat sich keiner Mühe gegeben die Deadlines zu halten, sondern hat einfach seinen Stiefel durchgezogen.
Wenn man mehrere Jahre gegen festgefahrene Ansichten prallt und konstruktive Kritik verhallt und zum teil aktiv mundtot gemacht wird, zieht man oft die Karte Dienst nach Vorschrift. Personalführung ist oft nicht ausreichend qualifiziert. Sage ich dazu mal freundlichen ausgedrückt. 😅
Das Problem an dem Feedback ist auch wenn man die neue Leute darauf nicht antworten lässt
Aber begibt man sich hier nicht in die gefahr um den heißen brei herumzureden und alles positiv auszuschmücken?!
Mich erinnert das ein bisschen an das Kompliment Sandwich.
David ich mag deine Brille 👓
David das video fand ich etwas kurz für das Thema,
Aber hey David, coole Bilder aus Winterberg 😊
Hier nochmal humoristisch in family guy aufgearbeitet:
ruclips.net/video/ewIT_KAQQlU/видео.html
Hey,
es geht ja nicht darum, das negative nicht anzusprechen sondern bei aller Kritik auch dem anderen hin und wieder Wertschätzung zukommen zu lassen. Wenn du von einer vorgesetzten Rolle immer nur Kritik bekommst und selten Lob, sinkt die Arbeitsmoral schnell ab.
Gruß David
@@DavidTielke das stimmt. Ein Vorgesetztenverhalten ist nochmal anders zu bewerten. Ich hatte bisher in Retros die Erfahrung gehabt, dass sehr viele Menschen mit Kritik nicht wirklich gut umgehen konnten und man hier immer sehr viel positives "mitsenden" musste - deshalb die Sache mit dem Komplimente Sandwich^^
Ich persönlich bin immer ein Freund davon -gerade raus zu sagen, was gut lief und was nicht so gut lief. Egal von welcher Rolle das kam. Natürlich entsprechend wertschätzend forumuliert. Ich denke da ist schon viel gewonnen
Manche finden sie sind doch sehr bemüht positive Dinge anzusprechen. Dann haben aber die Untergebenen irgendwann gelernt, dass so jemand eigentlich nur dann was positives sagt, wenn danach ein Hammer kommt.
Mir ist bewusst, dass dieses Kommentar gerade nicht ganz passt und nur am Thema anstreift, aber...
Wie kann man bessere Deadlines machen bzw. Deadlines überhaupt verhindern?
Der Grund wieso ich das anspreche ist, dass man es seeehr oft nicht einhalten kann. Nur wenn es um bereits Bestehendes in abgeänderter Form geht, kann man gute Deadlines erstellen. Doch wenn es um etwas wirklich neues geht, wie kann man dabei "Vorhersagen"/Schätzungen erstellen?
Mir wäre ein "Update" Datum in den Sinn gekommen, oder eine fehlerhafte Deadline.
das beantwortet die Frage jetzt leider noch nicht, aber ich habe mal in einem Buch gelesen, dass diese Formulierung wesentlich freundlicher wäre: "LIFELINE", immerhin soll hier ja etwas Neues ins Leben gebracht und nichts begraben werden ;o)
@@drchaotika ist aber trotzdem sehr hilfreich! Lifeline sagt gleich viel mehr aus als Deadline! Somit kann man sich auch gleich viel spezifischer äußern und mit anderen verwandten Mustern agieren! Sehr nice! Danke!
Hey,
Lifeline klingt gut :) Mache in einigen Wochen Videos zum Thema Projektmanagement in der SE, da wird das u.a. das Thema sein :) Pauschal beantworten kann ich das hier leider nicht, weil es von sehr vielen Faktoren abhängig ist.
Gruß David
Mal von mir eine Frage: Was benötigt / wünscht ihr euch um euch im Unternehmen / Team wohl zu fühlen?
Einen Obstkorb
Das du die Kommunikation von Verbesserungsmöglichkeiten als TRICK bezeichnest finde ich nicht gut. Wenn man nicht gerade als Stein geboren wurde, merkt man doch, ob etwas ernst und ehrlich gemeint ist, oder ob es nur Mittel zum Zweck ist.
Ansonsten ist das Phänomen weit verbreitet in unserer Arbeitswelt, und nicht wenige Führungskräfte sind stolz auf ihre "Überlegenheit".
Danke, dass du das hier einmal thematisiert hast.
Ich durfte bereits einmal erleben, wie ein Geschäftsführer, selbst noch Entwickler, ein kommplettes Team gesprengt hat.
Fazit:
Am Ende stand er nur noch mit seinen Azubis da. Alle anderen sind innerhalb von 4 Mt. davon gelaufen...
Habe ich tatsächlich bei einer Firma im Oberbergischer Kreis auch erlebt. Da haben die Söhne des Geschäftsführers das Softwareteam auch auseinandergenommen… Manche sind halt gleicher als andere.
@@tangsun4797
Und wer war am Ende schuld?
In meinem Fall waren auschliesslich die Mitarbeiter aus der Sicht des Geschäftsführers. Somit waren aich die Mitarbeiter schuld, dass so viel Know-How abgeflossen ist und viel Geld verlohren ging.
Tja. Plug & Play funzt halt nicht überall...
Hey,
ja genau so etwas erlebe ich auch hin und wieder, mache ja immer wieder Videos zum Thema "People in der Softwareentwicklung" - das zahlt da auch mit ein. Am Ende endet das fast immer in einem Desaster!
Gruß David
Wem bringt den dieses was?
Deine Entwickler sind die besten, oder der Recruiting Prozess erfüllt nicht die Anforderungen des Teams
Es kann auch Chefs geben, die nie zufrieden sind. Sonst müssten sie ihre "Abhängigen" besser bezahlen. Die Chefs glauben, mit Unzufriedenheit mehr Leistung herauszuholen, was aber nur begrenzt funktioniert und auch mal umkippen kann.
Vielleicht ist das Hauptproblem das die Entwickler nicht ihre Vorgesetzten feuern koennen, wenn die offensichtlich voellig unfaehig in ihrem Job sind.
Ich glaube eher, die meisten Vorgesetzten haben von dem Produkt keine Ahnung.
Es ist schwer ruhig und gelassen zu sein, wenn du nicht abschätzen kannst, was deine Entwickler machen.
Das gilt selbst für Entwickler, die in der Führungsspitze sitzen. Wenn du den benötigten Stack nicht hast, weißt du häufig nicht was die Entwickler gerade machen.
Das ganze Projekt ist eine Blackbox. Und die wenigsten Entscheidungsträger vertrauen ihre Entwickler. Also müssen sie kontrolliert werden. Die permanente Kontrolle macht alles nur noch schlimmer.
Ich habe selten eine Führungskraft erlebt, die gefragt hat, was das Team braucht.
Bin grade erst in den ersten Minuten des Videos, aber irgendwie ist der Bass in der ersten Minute kaum vorhanden oder ich täusche mich, dann ab 0:51 ist der Sound crystal-clear und perfekt, wie man ihn kennt.
Verwendet im ersten und den restlichen Shots zwei unterschiedliche Mikrofone - das im ersten ist in der Tat sehr "hell" und das restliche ist basslastiger. Leider habe ich das beim ersten nicht gemerkt und den Equalizer vergessen, demnächst achte ich darauf! Danke!
Ich kann aus eigener Erfahrung als PO und Scrum Master, allgemein als Projektverantwortlicher berichten, dass oft auch ganz simpel die Disziplin einzelner Entwickler erheblich zu wünschen übrig lässt, was oft aussieht wie fehlende Motivation. Ich kenne die eingangs beschriebenen Situationen perfekt, es gibt eine Retrospektive und keine Sau gibt bis zum Termin Feedback ab, Leute kommen zum Daily grundsätzlich 5-10 Minuten zu spät, etc. Man beißt sich echt die Zähne aus. Ein großer Punkt ist auch oft, dass vor allem junge Entwickler ein Maß an Überheblichkeit mitbringen, das mir völlig fremd ist. Viele Entwickler halten jedes Meeting für überflüssig, tun sich mit Kommunikation so schwer dass sie jegliche Art von Abstimmung aus tiefen Unmut heraus ablehnen.. etc.
Ich finde, dass Motivation durchaus auch im Verantworungsbereich des Einzelnen liegt. Hochqualifizierte Leute mit sechsstellingen Gehältern können sich einfach nicht alleine hinter ihrer fachlichen Kompetenz verstecken. Man muss schlicht ein Mindestmaß an Lust und Kommunikation mitbringen.
Den Vorwurf mit dem Missmanagement kenne ich auch, aber dazu muss ich ganz klar sagen, dass dies zwar richtig ist aber zwei dazu gehören. Es gibt die unangenehmen Punkte, es gibt auch die Choleriker und Stresser. Es gibt aber auch die Entwickler, denen man erst im Daily, im Weekly, oder zum Abgabetermin die Infos aus der Nase ziehen muss wie es jetzt eigentlich um den Stand ihrer Arbeit bestellt ist.
Für mich ist das Problem einfach oft, dass Entwickler eine eigenartige Spezies sind. Viele halten sich gegenüber den anderen Kollegen für etwas besseres, sie haben oft fehlende Kommunikationsskills und meistens fehlt ihnen der betriebswirtschaftliche Blick auf interne Prozesse und das Verständnis vom Miteinander zwischen Unternehmen und Kunden. Sie haben oft jeglichen Anspruch an Form und Floskeln verloren, wollen selten an sozialen Events teilnehmen und wollen generell kaum vor Ort sein. Ich finde, dass IT-Fachkräfte oft grundlos überbezahlt sind, man sich gar oft vor ihrer Qualifikation und Arbeit fürchtet, und dadurch genau die Situation entsteht die ich beschrieben habe. Wären Entwickler im Tagesgeschäft auf Augenhöhe mit anderen ausgebildeten und studierten Kollegen, wären sie viel mehr gezwungen sich vernünftig zu integrieren.
"Ich finde, dass IT-Fachkräfte oft grundlos überbezahlt sind" - lol :)))))))))))
Das klingt so als ob da etwas grundsätzlich in der Arbeitsatmosphäre schief läuft und das Bemühen um Besserung eher in Ermahnung als in konstruktiver Verbesserung (Schulung oder konstruktive Gesprächsrunden) steckt oder man beim Recruiting komplett gepennt hat und sich den nächstbesten von der Straße gekratzt hat... Oft liegt das Problem generell in der Firmenkultur bzw. in Ermangelung dieser begründet. Das wird gern ausgeblendet, weil sich oft trotzdem viele Leute damit arrangieren können.
Miteinander, und wirklich miteinander, Spielregeln ausmachen, den Wert und Vorteile der Spielregeln nochmals verdeutlichen. Danach auf die Einhaltung der Spielregeln pochen und selbst integer vorleben. Falls die Regeln nicht eingehalten werden, erinnern, dass man sich auf diese Regeln miteinander geeinigt hat. Und falls das nicht wirkt, muss es auch Konsequenzen geben.
@@Tunkali - _"und sich den nächstbesten von der Straße gekratzt hat..."_ …
gemäß dieser Facharbeitskräftemangelsituation wird dann nach folgendem Motto rekrutiert… _"Unter den Blinden ist der Einäugige König"_
…was dann in Konsequenz so aussieht: ein Scrum Master hantiert ein Rudel (grenzautistisch) vermeintlicher Könige - nahezu deckungsgleich in der Rolle eines Hofnarren - der seine Durchlauchtigkeiten bei Stimmung halten muß.
Priceless
Hey David, heute kann ich Dir leider nur bedingt zustimmen. Permanent Kritik anbringen und nie das Positive hervorheben, das wird auf Dauer schief gehen.
Ich bin aber der Meinung das wir als Gesellschaft und jeder einzelne einfach auch lernen müssen/sollten, Kritik anzunehmen und an sich selber zu arbeiten, keiner ist schließlich perfekt.
Es kann nicht sein das man ständig nur mit Samthandschuhen angefasst werden muss. Wenn ich was verbockt habe, dann habe ich es nun einmal verbockt, da kann man auch nichts schönreden. Aber und das finde ich wichtig, man sollte es nicht dabei belassen sondern mich dann abholen und nachfragen woran es lag bzw. anbieten an dem Umstand der dazu geführt hat zu arbeiten.
Aber wie immer gilt, komplexes Thema das nach 10 Minuten Video und wenigen Zeilen Kommentar unendlich erweiterbar wäre.
Das Thema ist soo schön komplex.
Aber der Ton macht die Musik! Ich habe auch schon in Teams gearbeitet, bei denen oft unfreundliche Kritik geübt wurde, das ist auf Dauer sehr demotivierend. Inzwischen habe ich das Glück in einem Unternehmen mit sehr guter Arbeitsatmosphäre zu arbeiten, da kommt ab und an ein angemessenes Lob, und das motiviert sehr! Und falls mal Kritik kommt, dann mit Respekt und auf Augenhöhe, und vor allem konstruktiv um das Problem gemeinsam zu lösen, da fällt das Annehmen schon wesentlich leichter.
Hey,
so ehr widersprichst Du mir gar nicht - sehe das ähnlich wie Du, ABER: (ich zitiere @drchaotika6203): der Ton und die Menge macht die Musik. Klar müssen Missstände klar und offen kommuniziert werden, um besser zu werden. ALLERDINGS sollte man auch positiv erreichte Dinge würdigen (von denen gab es einige) und nicht immer nur "auftauchen" wenn etwas schlecht war und dann in einem rein negativen Ton diese Kritik rüberbrngen. Das bringt nichts. Aber wie @thomaseichinger1717 schon sagte, das Thema ist sehr komplex - hier ging es nur um diese einzelne Geschichte, nicht um den gesamten Sachverhalt!
Gruß David
Entwickler sind in der Regel ihre eigenen schärfsten Kritiker, wenn die Stimmung gut und die Umgebung stimmig ist. Selbstorganisation ist nicht ohne Grund eines der wichtigsten agilen Prinzipien: Die Entwickler sind die Experten, nicht der PO, HR oder irgendein GF. In einer vertrauensvollen Umgebung wird das zu guten Ergebnissen führen. In eher negativ eingestellten Umgebungen wird's schwieriger, erfordert außerordentlich starke Entwicklerpersönlichkeiten, die sich beständig entgegen stellen - trotzdem nutzt es einen auf Dauer ab.
Der Fisch stinkt vom Kopf