Whiz-zarD

Die "Standard-Azubi-Aufgaben" stehen in der Ausbildungsordnung und nirgends anders. Klar, ein Azubi kann auch mal die Kaffeemaschine sauber machen oder die Werkshalle ausfegen, etc. aber auch nur, wenn alle anderen Angestellte dies auch mal machen. Dann kann dies ein Teil der Ausbildung sein, weil es auch um Teamarbeit, Sauberkeit des Arbeitsplatzes und ggf. auch um Müllvermeidung geht. Putzt der Azubi aber immer als einziger die Kaffeemaschine, so kann der Azubi dies auch verweigern, weil er dadurch nichts lernt.
Und ich denke, hier liegt der Knochen begraben. Die meisten Azubis kommen gerade frisch von der Schule. Da wird denen quasi noch alles hinterhergetragen und Lehrende haben einen Plan, den sie schon seit 20 Jahren in ihrem Mikrokosmos rauf- und runter kaspern. In Betrieben, ist es aber schwierig, so ein Plan zu erstellen und auch einzuhalten, weil man ja auch gar nicht so richtig weiß, was in den nächsten 6 - 12 Monaten in der Firma für Aufgaben/Projekte anstehen und viele Dinge müssen auch ineinandergreifen.
Darüber hinaus sind die Azubis noch schüchtern und trauen sich nicht zu sagen, dass sie gerne Arbeit hätten und zu guter Letzt hat der Ausbilder evtl. auch gerade keine Zeit, da er ja auch nicht rund um die Uhr nur die Azubis betreuen kann.
Ich kann mir also schon denken, dass viele Azubis sich sowas wie ein Stunden- oder Wochenplan vorgestellt haben, weil sie es so von der Schule halt kennen.
Ich als FIAE-Ausbilder handhabe es so, dass ich die ersten 6 Monate den Azubi erstmal mit kleinen Übungsaufgaben versorge und somit Schritt-für-Schritt die Softwareentwicklung näherbringe. Je nach Wissenslage (einige brauchen länger, andere kürzer) verlängere ich entweder die Zeit oder schaue in den aktuellen Projekten, welche Aufgabe wir uns gemeinsam anschauen können oder der Azubi mal alleine versuchen könnte.
Im Zuge des Home Office (wir machen seit der Pandemie 100% Home Office) habe ich aber das Gefühl, dass die Betreuung zu kurz kommt, da man halt nicht mehr zusammen in einem Raum sitzt. Ich bin für jedes Feedback dankbar, das ich von Azubis bekomme, denn ich möchte auch den Job so gut, wie möglich machen aber leider kommt da auch oft zu wenig rüber. Vielleicht aus Angst, was falsches zu sagen oder weil die Azubis selber keine Gedanken gemacht haben, wie es aus deren Sicht besser laufen könnte.
Aber dies ist meine Sicht als Ausbilder. Vielleicht schreibt der eine oder andere Azubi mal was dazu.

Die "Standard-Azubi-Aufgaben" stehen in der Ausbildungsordnung und nirgends anders. Klar, ein Azubi kann auch mal die Kaffeemaschine sauber machen oder die Werkshalle ausfegen, etc. aber auch nur, wenn alle anderen Angestellte dies auch mal machen. Dann kann dies ein Teil der Ausbildung sein, weil es auch um Teamarbeit, Sauberkeit des Arbeitsplatzes und ggf. auch um Müllvermeidung geht. Putzt der Azubi aber immer als einziger die Kaffeemaschine, so kann der Azubi dies auch verweigern, weil er dadurch nichts lernt.
Und ich denke, hier liegt der Knochen begraben. Die meisten Azubis kommen gerade frisch von der Schule. Da wird denen quasi noch alles hinterhergetragen und Lehrende haben einen Plan, den sie schon seit 20 Jahren in ihrem Mikrokosmos rauf- und runter kaspern. In Betrieben, ist es aber schwierig, so ein Plan zu erstellen und auch einzuhalten, weil man ja auch gar nicht so richtig weiß, was in den nächsten 6 - 12 Monaten in der Firma für Aufgaben/Projekte anstehen und viele Dinge müssen auch ineinandergreifen.
Darüber hinaus sind die Azubis noch schüchtern und trauen sich nicht zu sagen, dass sie gerne Arbeit hätten und zu guter Letzt hat der Ausbilder evtl. auch gerade keine Zeit, da er ja auch nicht rund um die Uhr nur die Azubis betreuen kann.
Ich kann mir also schon denken, dass viele Azubis sich sowas wie ein Stunden- oder Wochenplan vorgestellt haben, weil sie es so von der Schule halt kennen.
Ich als FIAE-Ausbilder handhabe es so, dass ich die ersten 6 Monate den Azubi erstmal mit kleinen Übungsaufgaben versorge und somit Schritt-für-Schritt die Softwareentwicklung näherbringe. Je nach Wissenslage (einige brauchen länger, andere kürzer) verlängere ich entweder die Zeit oder schaue in den aktuellen Projekten, welche Aufgabe wir uns gemeinsam anschauen können oder der Azubi mal alleine versuchen könnte.
Im Zuge des Home Office (wir machen seit der Pandemie 100% Home Office) habe ich aber das Gefühl, dass die Betreuung zu kurz kommt, da man halt nicht mehr zusammen in einem Raum sitzt. Ich bin für jedes Feedback dankbar, das ich von Azubis bekomme, denn ich möchte auch den Job so gut, wie möglich machen aber leider kommt da auch oft zu wenig rüber. Vielleicht aus Angst, was falsches zu sagen oder weil die Azubis selber keine Gedanken gemacht haben, wie es aus deren Sicht besser laufen könnte.
Aber dies ist meine Sicht als Ausbilder. Vielleicht schreibt der eine oder andere Azubi mal was dazu.

@Maniska ich glaube du stellst hier eine sehr schwere Frage und es wäre ein Wunder, wenn du hier auch wirklich eine zufriedenstellende Antwort der Azubis bekommst. Immerhin musst du bedenken, dass ein Großteil der neuen Azubis frisch aus der Schule kommt und vermutlich abseits von kurzen Pflichtpraktika kaum Erfahrungen mit dem Arbeitsleben habt. Hinzu kommt, dass es normal ist, dass man zwar sagen kann "Das gefällt mir nicht" oder "So habe ich es mir nicht vorgestellt", aber eigentlich gar keine konkrete Vorstellung davon hat, was man denn eigentlich erwartet hat. Natürlich macht es das dann für alle Seiten schwer, etwas daran zu ändern. Aber auch dieses "So nicht" zu kennen, kann schon helfen. Sowohl demjenigen, der es empfindet/äußert, denn er lernt dadurch ja, (durch Ausschluss) seine Vorstellungen zu konkretisieren, als auch demjenigen, der davon betroffen ist, denn er kann es bei zukünftigen Situationen besser machen oder zumindest Alternativen ausprobieren.

Ein großes Problem ist, dass es die "perfekte" Ausbildung gar nicht gibt. Mein Arbeitgeber investiert viel Geld in externe Schulungen zu allen möglichen Inhalten der Ausbildungen. Da gibt es beinahe von Anfang an direkt eine "Dröhnung" und die paar Wochen, welche die Azubis in der Firma sind, werden oft geringere Aufgaben weitergegeben, die wir selbst auch machen müssen, beispielsweise
Kabel ziehen, Patchen, Testen, Beschriften und ähnliche Dinge, davon bleibt aber niemand verschont. 
In den ersten Wochen (nicht Monate!) sollte niemand erwarten wirklich sinnvolle (tiefgründigere) Tätigkeiten durchzuführen, denn da wird normalerweise das Umfeld gezeigt, die Leute kennengelernt und geringfügig unter die Arme gegriffen. Im besten Fall hat man einen Ausbilder/Betreuer der wirklich Interesse hat dir etwas beizubringen, selbst dann wird er dir aber nicht alles vorkauen und sagen "mach dich mal schlau" oder "komm mal her und schau mir über die Schulter". 
In den ersten Wochen heißt es oft miteinander "warm werden", da erwarte ich vom Azubi durchaus, dass er nach Arbeit fragt, wenn er sich langweilt, dazu zählt auch das Nachfragen zu einem Themengebiet, dass ihn interessiert. Zu lernen, dass man sich selbstständig Beschäftigungen holt, dauert durchaus seine Zeit. Welche Themengebiete interessieren dich am Meisten? Gehe dort hin und sage, dass du interesse hast und gerne helfen und einen tieferen Einblick haben möchtest.
Das unterscheidet sich von Arbeitgeber zu Arbeitgeber extrem, bei mir was es absolut kein Problem dieses "Hopping" zu betreiben. Wir haben als Azubis untereinander Präsentationen über bestimmte Themen halten müssen. 
Was ist SNMP, wie funktioniert das? Fisi, mach dich schlau und halte eine 10 minütige Präsentation, damit der FIAE das auch versteht. 
"Einfach" ist es schon mal gar nicht. Wie Maniska schon gesagt hat, ist das nicht die Antwort auf die Frage. In der Regel existiert kein Stundenplan wie in der Schule
Erwartest du einen Plan à la?
- Woche 1 Subnetting
- Woche 2 Virtualisierung
- Woche 3 Monitoring
- Woche 4 Netzwerk
- Woche 5 Programmierung

Den wirst du in den seltensten Fällen erhalten, selbst eine Testumgebung für Azubis ist maximaler Luxus. 
Wenn ein Azubi bei mir ist, erzähle ich ihm meine Tätigkeiten und Systeme und dann erwarte ich auch eine Antwort auf die Fragen: "was möchtest du besser kennenlernen?" und "Welche Erwartungshaltung hast du?". Die Frage der Erwartungshaltung kommt im Berufsleben noch sehr häufig, also ist es nicht "unfair" diese Frage einem Azubi zu stellen.

Die "Standard-Azubi-Aufgaben" stehen in der Ausbildungsordnung und nirgends anders. Klar, ein Azubi kann auch mal die Kaffeemaschine sauber machen oder die Werkshalle ausfegen, etc. aber auch nur, wenn alle anderen Angestellte dies auch mal machen. Dann kann dies ein Teil der Ausbildung sein, weil es auch um Teamarbeit, Sauberkeit des Arbeitsplatzes und ggf. auch um Müllvermeidung geht. Putzt der Azubi aber immer als einziger die Kaffeemaschine, so kann der Azubi dies auch verweigern, weil er dadurch nichts lernt.
Und ich denke, hier liegt der Knochen begraben. Die meisten Azubis kommen gerade frisch von der Schule. Da wird denen quasi noch alles hinterhergetragen und Lehrende haben einen Plan, den sie schon seit 20 Jahren in ihrem Mikrokosmos rauf- und runter kaspern. In Betrieben, ist es aber schwierig, so ein Plan zu erstellen und auch einzuhalten, weil man ja auch gar nicht so richtig weiß, was in den nächsten 6 - 12 Monaten in der Firma für Aufgaben/Projekte anstehen und viele Dinge müssen auch ineinandergreifen.
Darüber hinaus sind die Azubis noch schüchtern und trauen sich nicht zu sagen, dass sie gerne Arbeit hätten und zu guter Letzt hat der Ausbilder evtl. auch gerade keine Zeit, da er ja auch nicht rund um die Uhr nur die Azubis betreuen kann.
Ich kann mir also schon denken, dass viele Azubis sich sowas wie ein Stunden- oder Wochenplan vorgestellt haben, weil sie es so von der Schule halt kennen.
Ich als FIAE-Ausbilder handhabe es so, dass ich die ersten 6 Monate den Azubi erstmal mit kleinen Übungsaufgaben versorge und somit Schritt-für-Schritt die Softwareentwicklung näherbringe. Je nach Wissenslage (einige brauchen länger, andere kürzer) verlängere ich entweder die Zeit oder schaue in den aktuellen Projekten, welche Aufgabe wir uns gemeinsam anschauen können oder der Azubi mal alleine versuchen könnte.
Im Zuge des Home Office (wir machen seit der Pandemie 100% Home Office) habe ich aber das Gefühl, dass die Betreuung zu kurz kommt, da man halt nicht mehr zusammen in einem Raum sitzt. Ich bin für jedes Feedback dankbar, das ich von Azubis bekomme, denn ich möchte auch den Job so gut, wie möglich machen aber leider kommt da auch oft zu wenig rüber. Vielleicht aus Angst, was falsches zu sagen oder weil die Azubis selber keine Gedanken gemacht haben, wie es aus deren Sicht besser laufen könnte.
Aber dies ist meine Sicht als Ausbilder. Vielleicht schreibt der eine oder andere Azubi mal was dazu.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.
Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.
Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.
Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.
Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.
Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.
Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.
Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.
Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.
Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.
Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.
Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.
Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.
Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.
Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.
Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.
Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.
Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.
Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.
Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.
Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.
Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.
Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.
Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.
Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

In diesem Zusammenhang kann ich nur den Youtuber Jayme Edwards aka Healthy Software Developer empfehlen, der genau über diese Themen spricht.
Die meisten haben agile Softwareentwicklung nämlich nicht verstanden und das ist ein sehr großes Problem. Bei uns versucht man auch diese New Work bzw. die agile Softwareentwicklung einzuführen aber es ist im Grunde krachend gescheitert aber es will keiner so richtig wahr haben. Man dachte, man könnte schneller releasen, wenn die Entwickler nach Scrum arbeiten aber das zyklische Releasen ist ja kein Mittel, um den Kunden zu beweisen, dass man schnell releasen kann, sondern dient dazu, um schnell Feedback zu sammeln. Gibt es kein Feedback und plant Änderungen (auf Basis des Feedbacks und der Retro) auch nicht in sein Regelprozess ein, ist es einfach Wasserfall. Wer agile Softwareentwicklung einführen möchte aber beim Wasserfall bleibt, der verursacht Chaos. Ich denke, die meisten Firmen können überhaupt keine agile Softwareentwicklung einführen und sollten dies auch so anerkennen. Dave Thomas, einer der das Agile Manifesto mitgeschrieben hat, berichtete auf einer Konferenz, dass z.B. das Beschätzen von Zeiten bei der agilen Softwareentwicklung nicht vorgesehen ist. Was soll man denn auch beschätzen, wenn die Software im nächsten Zyklus evtl. ganz anders aussehen muss? Wenn der Kunde oder das Management weiterhin darauf pocht, ist es Wasserfall, weil dann eine Deadline bestimmt wird.
Es bedarf ein komplett anderes Mindset, wenn man sowas einführen möchte. Nicht nur bei den Entwicklern, sondern in der gesamten Firma und auch bei den Kunden. Es müssen Mittel und Wege gefunden werden, wie man Kunden aktiv in den Entwicklungsprozess einbindet. Sei es durch Umfragen, Betatester, direkter Ansprechpartner bei fachlichen Fragen oder weiß der Geier noch was. Außerdem müssen ggf. sogar die Kundenverträge umgeschrieben werden. Diese Mühen machen aber gefühlt nur sehr wenige bis gar keiner. Gefühlt versucht man, wie hier schon angedeutet, die Entscheidungen nach unten zu drücken und daher kommen auch die ganzen Meetings, weil man als Entwickler plötzlich zusätzlich das Projekt managen muss.
Das Daily Meeting ist auch nicht dafür gedacht, dem Product Owner oder anderen Managern einen Bericht zu erstatten, wie weit man gerade ist, sondern dient einzig für das Team, um sich zu koordinieren und Probleme anzusprechen und sowas wie Burn-Down-Charts halte ich auch für kontraproduktiv, weil es ein Druck auf die Entwickler ausübt und Druck ist für die Softwarequalität immer schlecht.
Ich bin mir sicher, dass man in vielen Firmen den Scrum-Kram in die Tonne treten könnte und es würde niemanden auffallen.

Ich bin jetzt kein großartiger Koch und außerdem hasse ich es zu kochen aber ich finde, es ist schon ein bisschen bedenklich, wenn mein Arbeitgeber mich noch bei einer gesunden Ernährung unterstützen soll/muss/möchte. Eigentlich sollte dies schon ein Teil der Erziehung sein. Es müsste darauf schon viel mehr im Kindes-/Jugendalter darauf gezielt werden, sich gesund zu ernähren. Ergo: Schulen sollten viel mehr sowas lehren, als z.B. die binomischen Formeln (die ja nur ein Rechentrick sind) oder die Französische Revolution.
Mit irgendwelchen Essensgutscheinen wird der Arbeitgeber nicht erreichen, dass ich mich gesund ernähre, wenn ich mit diesen Gutscheinen weiterhin meine Burger und Pizza kaufen kann. Wenn, dann muss es auf eine andere Weise geschehen, wie z.B. gemeinsames Kochen unter der Anleitung eines Kochs. Dafür müsste man aber wohl in eine Küche investieren. Essensgutscheine oder ein Obstkorb ist nur eine billige Art, so zu tun, als würde man die Gesundheit der Mitarbeiter denken.

Naja, aber gerade bei Rabattierung von Essen sehe ich da einfach keinen Benefit. Genauso kann er auch nur das Gehalt um 50 € die Woche erhöhen. Hat den gleichen Effekt, denn letztendlich muss ich essen, sonst verhungere ich. Also muss ich sowieso Essen kaufen und ob ich jetzt die Pizza mit einer Rabattierung über einer App oder durch mehr Gehalt bezahle, spielt nun auch keine Rolle. Der Arbeitgeber stellt sich damit nur künstlich besser, indem er dies als Benefit anpreist.

Ich bin jetzt kein großartiger Koch und außerdem hasse ich es zu kochen aber ich finde, es ist schon ein bisschen bedenklich, wenn mein Arbeitgeber mich noch bei einer gesunden Ernährung unterstützen soll/muss/möchte. Eigentlich sollte dies schon ein Teil der Erziehung sein. Es müsste darauf schon viel mehr im Kindes-/Jugendalter darauf gezielt werden, sich gesund zu ernähren. Ergo: Schulen sollten viel mehr sowas lehren, als z.B. die binomischen Formeln (die ja nur ein Rechentrick sind) oder die Französische Revolution.
Mit irgendwelchen Essensgutscheinen wird der Arbeitgeber nicht erreichen, dass ich mich gesund ernähre, wenn ich mit diesen Gutscheinen weiterhin meine Burger und Pizza kaufen kann. Wenn, dann muss es auf eine andere Weise geschehen, wie z.B. gemeinsames Kochen unter der Anleitung eines Kochs. Dafür müsste man aber wohl in eine Küche investieren. Essensgutscheine oder ein Obstkorb ist nur eine billige Art, so zu tun, als würde man die Gesundheit der Mitarbeiter denken.

Aus eigener Erfahrung sollte man sowas ernst nehmen, sonst entsteht daraus ein Burnout oder schlimmer, eine Depression. Ein Burnout entsteht nämlich nicht durch Überarbeitung, wie immer behauptet, sondern durch Konflikte mit sich selbst und seiner Umwelt. Man führt ein Leben, welches man nicht will. Ich kenne sowas gut, wenn man Magenschmerzen bekommt, wenn man die Arbeitsstätte von weiten sieht. Auch wenn der Schritt vielleicht schwer fällt, such dir einen anderen Arbeitsplatz.
An deiner Stelle würde ich nach Junior Stellen stellen und so schnell, wie möglich das weite suchen. Allerdings würde ich auch erst kündigen, wenn du was neues hast. Wenn die Kündigung nämlich von dir aus geht, hast du erstmal keinen Anspruch auf Arbeitslosengeld.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.

Werden auch gerne als Urlaubsvertreter eingesetzt. In meinen damaligen 3 Jahren (2004 - 2007) als Zeitarbeiter hatte ich kaum bis gar keinen Urlaub, da ich eben überall als Urlaubsvertretung eingesetzt wurde. Berufsanfänger dürften wohl kaum über den Mindestlohn hinauskommen. Ich konnte damals mit dem Gehalt der Zeitarbeitsfirma nicht mal eine Wohnung bezahlen.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.

Amadeus Fire ist ein Personalvermittler. Die nehmen halt jeden, der nicht bei Drei auf den Bäumen ist.