Announcement: there is an English version of this forum on Wer sich mit der Vorgehensweise bei SCRUM auskennt, der weis, wie das so ungefähr läuft, mit den Aufgabenplanungen und Verteilungen - insbesondere dann, wenn einer nicht weiter kommt und Tasks umverteilt werden. Es ist nun die Frage aufgetaucht, wie das mit der Arbeitsweise von Selbständigen zusammenpasst, weil diesen - soweit sie in das System eingebunden sind - ebenfalls ständig und ad hoc Aufgaben zugewiesen werden. Ist das schon eine weisungsgebundene Tätigkeit? Widerspricht die Nutzung von SCRUM generell dem Involvieren von externen Mitarbeitern, oder gfs dann, wenn es in bestimmter Weise genutzt wird? 1) Nehmen wir an, es gibt TÄGLICHE(!) Meetings, in denen abgeprüft wird, welche Aufgaben erledigt sind und eine Art "Berichterstattung" läuft. 2) Nehmen wir weiter an, dass aufgrund der Berichterstattung, Tasks neu definiert, neu verteilt werden, um einen "aligned sprint" zu erzielen. 3) Nehmen wir weiter an, dass es WÖCHENTLICHE Sprints mit festem Zeitrahmen gibt, in denen der Projektleiter die Zeitvorgaben macht und anhand der kommunizierten Einzeltasks, die man zusichert, abarbeiten zu können, dann Tasks aus dem Tableau nimmt, diese anderen Teammitgliedern zuteilt oder in nächste Sprints verschiebt, also damit eine Zeitplanung für den Externen vornimmt. 4) Nehmen wir weiter an, daß man Tasks zugeschoben bekommt, die "brennen" weil ein anderer nicht weiter kommt, oder die Resourcen nicht reichen und deshalb der eigentliche Task, an dem man arbeitet und der Vertragsgegenstand ist, unterbrochen wird, obwohl nie die Rede von diesem neuen Task war und er auch nicht Vertragsgegenstand ist? Wäre - als Frage formuliert - schon das Mitglied sein in einem SCRUM-Team ein Problem? Wäre es gfs sicherer, man trennt die Teams in Externe und Interne? Die Arbeitsplätze werden oft genug ja auch getrennt, d.h die Externen dürften nicht zuwischen den Internen sitzen.
Deine Einführung liest sich wie ein Hybrid-SCRUM. SCRUM stellt die Verantwortung des Einzelnen heraus, das Team entscheidet - es gibt aber Ausnahmen. Der Product Owner wäre ein Kandidat für „Chef Allüren“ im Sinne eines Juristen… Zielt die Frage auf „Scheinselbständigkeit“ ab?
Uwe D. schrieb: > Zielt die Frage auf „Scheinselbständigkeit“ ab? unter anderem, JA. Uwe D. schrieb: > das Team entscheidet Wäre für mich ein Hinweis auf "eingebunden in Organisationsstruktur" Uwe D. schrieb: > Der Product Owner wäre ein Kandidat für „Chef Allüren“ Wäre für mich ein Hinweis aus "weisungsgebunden".
Beitrag #7320118 wurde von einem Moderator gelöscht.
Beitrag #7320136 wurde von einem Moderator gelöscht.
Olli Polli schrieb: > Ist das schon eine weisungsgebundene Tätigkeit? Nein. Schau Dir die Rollen im SCRUM an. Gibt es da einen "Einweiser"?! Nein, es gibt lediglich einen Moderator der durch die daily scrumms führt und darauf achtet, das die SCRUM-Teammitglieder ihr Commitment zum daily sprint abgeben. > Widerspricht die Nutzung von SCRUM generell dem Involvieren von externen > Mitarbeitern, oder gfs dann, wenn es in bestimmter Weise genutzt wird? nein. Höchstens als höfliche Notlüge wenn es eigenlich andere Gründe gibt, diesen konkreten Freiberufler in dieses Projekt zu holen.
Olli Polli schrieb: > Ist das schon eine weisungsgebundene Tätigkeit? Rechtsthemen in einem Mikrocontroller-Forum diskutieren ist nicht zielführend. Notfalls entscheidet das am Ende ein Richter. Der wird sich in keinster Weise davon beeinflussen lassen was der als besonders vertrauenswürdig erscheinende "testdödel 32" irgendwo im Internet in einem Forum behauptet hat. Falls du es nicht verstanden hast, die Antworten die du hier bekommst kannst du dir in die Haare schmieren, von der Backe putzen, knicken. Such dir eine zuverlässige Quelle von der du belastbare Informationen bekommst.
Olli Polli schrieb: > Wäre - als Frage formuliert - schon das Mitglied sein in einem > SCRUM-Team ein Problem? Ja. Problem in der Art, als dass der Selbständige der in Scrum eingebunden ist definitiv ein Scheinselbständiger ist und der ihn Beauftragende dann Sozialversicherung nachzahlen muss. > Wäre es gfs sicherer, man trennt die Teams in Externe und Interne? Nein. Selbständige arbeiten gar nicht als Rädchen im Scrum. Man gibt ihnen einen Auftrag, als Werkvertrag oder Stundenlohn, und rechnet ab nach Erledigung des Auftrags. Zwischendrin lässt man ihn in Ruhe selbständig arbeiten. WIE kleinteilig die Aufgabe ist, kann sich der Arbeitgeber ja aussuchen, viele Selbständige setzen ihre Einkünfte auf 5min oder 15min kurzen Arbeitseinsätzen zusammen. Wenn aber alle 250 dieser kurzen Abrechnungen vom selben Auftraggeber stammen, ist das wieder Scheinselbständigkeit.
:
Bearbeitet durch User
Beitrag #7320234 wurde von einem Moderator gelöscht.
Beitrag #7320488 wurde von einem Moderator gelöscht.
Beitrag #7320509 wurde von einem Moderator gelöscht.
Lebensberatung schrieb im Beitrag #7320509: > Opferanode für Teamstimmung schrieb: >> Ich Kenne einige Freelancer in scrum-Teams, > Weil du jetzt ein paar Vollpfosten kennst die sich freiwillig dem > Verdacht der Scheinselbstständig aussetzen soll das jetzt autmatisch die > Regel/problemlos sein? Mumpotz, Mitarbeit im Scrum-Team alleine ist kein Kriterium für Scheinselbstständigkeit. Kannste gerne nachlesen: https://www.ihk-muenchen.de/de/Service/Recht-und-Steuern/Arbeitsrecht/Einstellung-von-Arbeitnehmern/Scheinselbst%C3%A4ndigkeit/ Und es gibt klare Anzeichen für Nicht-Scheinselbstständigkeit wie -Angestellte haben -Rechtsform GmbH -mehrere Auftraggeber -aktive Akquise -Werkvertrag Vielleicht solltest du mal an daran arbeiten. > Nenn mal den Namen der Firma damit wir die Behörden informieren können, > dann wirste schon sehen wie legal das ganze Konstrukt ist. Mach, mal: Rohde & Schwarz München, ESG Fürstenfeldbruck, ... welche Bude macht den heutzutage nicht aus SCRUM ?! >> also es ist wohl eher die >> 'Lebensberatung' die ein problem mit adequater Wiedergabe der Umwelt hat >> ... > Red doch nicht so saudumm daher, so blöd bist du doch selber nicht, dass > das angeblich die Regel und unproblematisch ist. Nein danke, behalt mal deine dissoziativen Störung für Dich.
Lebensberatung schrieb im Beitrag #7320509:
> Nenn mal den Namen der Firma damit wir die Behörden informieren können
Unsinn.
Der Weg geht andersrum: man arbeitet still und leise und voll
eingebunden in dem Scrum Team der Firma, und wenn die nach 2 Jahren der
Meinung sind, sie können einem keine Verlängerung des Auftrags geben,
der Job hat also ein Ende, dann klagt man vor dem Arbeitsgericht:
Scheinselbständig ist bei Scrum offensichtlich, die nicht-Verlängerung
ist unwirksam weil sie einem ordentlich hätten
kündigen müssen wie einem Arbeitnehmer , weil aber das Urteil aber Jahre
nach dem Rauswurf kommt muss die Firma Gehalt nachzahlen, zudem darf sie
zum damaligen Stundensatz noch die Sozialversicherung oben drauf legen.
Es sind die Firmen die ein Risiko eingehen, nicht der Auftragnehmer.
Und man selbst hat so die Kohle von der Firma mit der man sowieso nicht
zusammenarbeiten will weil sie einem die Kohle vorenthalten wollte.
:
Bearbeitet durch User
Michael B. schrieb: > Problem in der Art, als dass der Selbständige der in Scrum > eingebunden ist definitiv ein Scheinselbständiger ist Michael B. schrieb: > Scheinselbständig ist bei Scrum offensichtlich Das mag in Deiner Welt so eindeutig sein, Richter sehen das nicht unbedingt so: https://www.gulp.de/freelancing/wissen/scheinselbststaendigkeit/urteil-scrum-projekte-kein-indiz-scheinselbststaendigkeit
Lebensberatung schrieb im Beitrag #7320509: > Opferanode für Teamstimmung schrieb im Beitrag #7320488: >> Ich Kenne einige Freelancer in scrum-Teams, > Weil du jetzt ein paar Vollpfosten kennst die sich freiwillig dem > Verdacht der Scheinselbstständig aussetzen soll das jetzt autmatisch die > Regel/problemlos sein? > > Nenn mal den Namen der Firma damit wir die Behörden informieren können, > dann wirste schon sehen wie legal das ganze Konstrukt ist. DB, Commerzbank, Airbus, Thales, Lufthansa, TÜV Nord/Süd, … Es gibt massenhaft freiberufliche Spezialisten, die haben alle Deine Befürchtungen nicht. Und verrückt: Sogar der formale Projektleiter ist ein Freiberufler….
Wer sich diesen SCRUM Rotz als selbstständiger freiwillig antut ist echt nicht zu retten.
Beitrag #7321783 wurde von einem Moderator gelöscht.
Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst verloren
Beitrag #7322131 wurde von einem Moderator gelöscht.
Ich danke Gott, dass ich nicht mehr als Informatiker arbeiten muss.
Da Baby schrieb: > Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst > verloren Das Bashing ist ein Spiegel der eigenen Wahrnehmung und macht offenbar, dass keine (internationale) Großprojekterfahrung vorhanden ist oder die menschliche Reife, andere Denkmodelle zuzulassen. Und nein, dass ist keine Aufforderung zu einer Antwort auf meine Zeilen.
Uwe D. schrieb: > Da Baby schrieb: >> Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst >> verloren > > Das Bashing ist ein Spiegel der eigenen Wahrnehmung und macht offenbar, > dass keine (internationale) Großprojekterfahrung vorhanden ist oder die > menschliche Reife, andere Denkmodelle zuzulassen. > Und nein, dass ist keine Aufforderung zu einer Antwort auf meine Zeilen. Internationale Großprojekte und SCRUM? Hat man dir das in deiner Dorf Hinterhof klitsche erzählt? Geh mal in die Welt denn viel Erfahrung scheint du nicht zu haben.
Beitrag #7323278 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
SAFe.png
420 KB
Peter A. schrieb: >>> Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst >>> verloren >> >> Das Bashing ist ein Spiegel der eigenen Wahrnehmung und macht offenbar, >> dass keine (internationale) Großprojekterfahrung vorhanden ist oder die >> menschliche Reife, andere Denkmodelle zuzulassen. > > Internationale Großprojekte und SCRUM? Hat man dir das in deiner Dorf > Hinterhof klitsche erzählt? Wahrscheinlich bist es eher du, dessen Kopf nur in Dorf-Kategorien denken kann. SCRUM wurde für Grossprojekte hockskaliert, beispielsweise als SAFe: Scaled agile framework Anhang nach: https://isapm.org/safe-solutions/ Siehe auch: https://de.wikipedia.org/wiki/Scaled_Agile_Framework
Dieses Diagramm zeigt die perversen Auswüchse der Generation Powerpoint. Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen? Kein Wunder, dass nichts voran geht weil alle nur noch mit der Einhaltung von SCRUM und Konsorten beschäftigt sind.
Peter A. schrieb: > Dieses Diagramm zeigt die perversen Auswüchse der Generation > Powerpoint. > Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen? > Kein Wunder, dass nichts voran geht weil alle nur noch mit der > Einhaltung von SCRUM und Konsorten beschäftigt sind. Ich verweise an die unbeantworteten Fragen: Beitrag "SCRUM und die Arbeitsweise von Selbständigen"
Kindergärtner schrieb: > Peter A. schrieb: >> Dieses Diagramm zeigt die perversen Auswüchse der Generation >> Powerpoint. >> Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen? >> Kein Wunder, dass nichts voran geht weil alle nur noch mit der >> Einhaltung von SCRUM und Konsorten beschäftigt sind. > > Ich verweise an die unbeantworteten Fragen: Beitrag "Re: SCRUM und die > Arbeitsweise von Selbständigen" Kindergärtner schrieb: > Peter A. schrieb: >> Dieses Diagramm zeigt die perversen Auswüchse der Generation >> Powerpoint. >> Wer soll denn diesen Quatsch in so einem furchtbaren Diagramm verstehen? >> Kein Wunder, dass nichts voran geht weil alle nur noch mit der >> Einhaltung von SCRUM und Konsorten beschäftigt sind. > > Ich verweise an die unbeantworteten Fragen: Beitrag "Re: SCRUM und die > Arbeitsweise von Selbständigen" Vielleicht bist du in deinem Kindergarten besser aufgehoben. Unter erwachsenen scheint du recht unsicher zu sein.
SCRUM Training Schmitz schrieb im Beitrag #7323278:
> solange die externen Mitarbeiter in das Team integriert werden
So von der Seite eingeworfen, scheint mir das aber sehr verdächtig zu
sein, denn "eingebunden ins Team" ist eben nicht selbständig. Denn:
Wieso sollte jemand täglich von seiner Arbeit berichten, wenn andere das
gar nicht verwerten können, weil sie an anderen Dingen arbeiten? Und
wieso sollte der Selbständige täglich 1:1 mitbekommen, woran die anderen
arbeiten, wenn er das ebenfalls nicht auswerten kann, weil er ein
eigenes Projekt hat?
Wozu? Ich habe schon mehrere solcher Projekte gemacht und beobachte in
vielen Abteilungen wie nutzlos das SCRUM ist - gerade für uns Externe.
Aus meiner Sicht kann und muss das tägliche meeting völlig getrennt
laufen. Der Projektleiter fragt den Selbständigen, wo er steht und
koordiniert das mit dem Team und fragt das Team parallel. Genau so, wie
er die internen Teams parallel abfragt, die nicht an derselben SW
arbeiten. So sehr viel sollte es da auch nicht zu synchronisieren geben,
weil es eine abgetrennte Aufgabe sein muss, die der Externe erledigt.
Wenn es nötig oder möglich ist, dass der Externe im Team mitwirkt und
mitdiskutiert, dann beeinflusst er die anderen Festangestellten und wird
von diesen beeinflusst. Die Mitwirkung in einem SCRUM-Team ist aus
meiner Sicht ein klares Indiz für das Eingebunden sein in einer Gruppe
und damit für unselbständiges Arbeiten, weil die Aufgaben dann hin- und
her fließen, da diese ja vom Team verteilt werden. Eine solche Rolle ist
höchst kritisch. Einzig der Scrum Master kann ein Selbständiger Externer
sein, der die gesamte Ausarbeitung macht, weil er ja gar nicht so über
die Inhalte Bescheid wissen muss, sondern nur die formale Abwicklung
macht.
Wenn diese enge Abstimmerei aber nicht passiert und der Externe nur
nebenher mitläuft, dann braucht er die anderen und deren Reports auch
nicht und kann seinen Status dem PL direkt melden. Eine Mitwirkung IM
Team ist also unsinnig.
Der Punkt ist nämlich der:
An wen berichtet ein Externer? Normalerweise ist der Auftraggeber des
Externen die Geschäftsleitung, die entweder den Abteilungsleiter oder
den Projektleiter benennt, der als Kommunikator dient. Der
Geschäftspartner des Externen ist der Einkäufer der Firma. Die Senior
Entwickler oder andere, haben ihm demgemäß gar nichts zu sagen und er
muss sich auch nicht mit diesen abstimmen. Die haben nichts mit dem
Projekt des Externen zu tun. Genau wie der Teamleiter der SW nichts mit
den Abläufen im HW-Team zu tun hat. Die Berichtskette ist ja schon dort
aufgetrennt und läuft parallel.
Daher läuft die Kommunikation eines Externen normalerweise immer über
den PL, der die technischen Zusammenhänge kennt und die Termine macht.
In einem SCRUM-Team ist der technisch bestimmende Part der Product
Owner. Der wäre auch derjenige, der bestimmt, was der Externe überhaupt
macht. Der muss den Auftrag an den Einkäufer geben und die spätere
Abnahme machen. Der Scrum-Master oder das Team haben damit genau
genommen, gar nichts zu tun, weil es ein paralleles System ist. Das
Problem entsteht natürlich dann, wenn das ein und dieselbe Person ist.
Der muss das dann von sich aus trennen.
Aus meiner Sicht gibt es keinen Grund für ein tägliches meeting mit
Externen. Das ist weder formell noch inhaltlich nötig. Was die Sprints
angeht, sollte sich der Projektleiter einfach vom Team die Sprintplanung
geben lassen oder erarbeiten und sie mit den Tasks der Externen
synchronisieren. Das reicht völlig, im 2-3-Wochen-Rhythmus.
Tägliche Arbeitskontrolle mit typischen Sprintplanungen von Einzeltasks
und Abhaken der TODOs hat nämlich noch einen weiteren Negativpunkt: Die
Tasks sind auf wenige Stunden zeitlich geplant und werden getrackt. Das
entspricht einer Zeiterfassung! und die ist nach neuester Rechtsprechung
ein weiteres Indiz für Scheinselbständigkeit -> siehe die
Plattformdiskussion.
Der saubere Weg wäre also, die Tasks zu größeren Blöcken
zusammenzufassen und nur Endtermine zu definieren. Das geht z.B. in JIRA
sehr elegant, indem die Internen täglich ihre Subtasks abhaken, die
Externen aber nur im 3W-Rhytmus vor deren Sprint-Review dabei sind und
den Status vermelden. Die haben nur 3-4 große Main-Tasks, die zu eben
jenem Termin abgehakt werden.
Hier läuft das aktuell so, dass es z.B. einen Werkvertrag gibt für
"Testsoftware" zu 3 Monaten. Liefertermin von 31.3.2013. Dann gibt es 4
große Module, die ausgeliefert werden. Der Werkvertragler liefert die 4
Module genau zum Zeitpunkt 1+2 am 28.Feb und 3+4 am 31.3 und kriegt die
vereinbarten Zahlungen. Dazwischen passiert nichts. Er soll sich nur
melden, wenn er droht die Termine zu verletzen.
Wir Dienstvertragler stückeln unsere Module in ähnlicher Weise,
kommunizieren unterwegs einmal die Woche die Prozente und ob wir im Plan
sind. Da wir im Plan sein sollen, verarbeiten wir so viele Stunden, wie
nötig. Daher werden dann einmal 35h, einmal 42h und einmal 47h die Woche
abgerechnet. Klappt was nicht, muss man eben Termine verschieben, was
der Kunde zu akzeptieren hat. Wir tragen die beanspruchten Zeiten einmal
die Woche in eine Zeiterfassung ein und melden es verbal. Dann geht
einmal im Monat die formelle Stundenmeldung raus. Der PL hakt es dann
ab.
Daraufhin gibt es einmal im Monat eine Rechnung mit wechselnden Stunden.
Ich rechne noch Anfahrten und Extra-Sätze ab, wenn ich hingefahren bin.
Die Werkvertragler kriegen in der Regel Tranchen: 20% bei Auftragsbeginn
und die anteiligen Prozente je Termin, hier also z.B. 40% + 40% nach 2
Lieferterminen. Also Festsumme.
Vorzugsweise sollte man Werkvertrag machen, um sich vor all zu viel
Aufwand und TammTamm zu schützen. Das ist für beide Seiten das Beste.
Nur muss man bei den weichen Definitionen des Kunden immer soviel Zusatz
einplanen, dass es enorm teuer wird. Ich persönlich mache daher gerne
Dienstverträge als Berater, erarbeite durchaus Pläne für andere, mache
dies und das, habe aber im Vertrag nur ein-zwei wenige Hinweise stehen,
was ich überhaupt mache und lasse mich nicht auf Anwesenheit oder
Liefertermine festnageln. Der PL bekommt von mir einen Arbeitsplan, in
dem alles verzeichnet ist, was aus meiner Sicht anfällt. Dann lässt sich
schön aufzeigen, was sie immer so alles vergessen haben und ihnen noch
einfällt.
Wenn die Firma mit SCRUM arbeitet, soll sie es machen: Ich schalte mich
drauf, trinke meinen Kaffe und lasse mir die Zeit bezahlen. Der PL
kriegt von mir 3-4 Stichworte, was ich in den nächsten Wochen tun werde
und das ist so allgemein und konservativ, dass ich nicht dagegen
verstoße oder es überziehe. Momentan mache ich gerade "Einarbeitung neue
Requirements" in den Code. Da die sich täglich ändern, ist das eine
neverending Story.
Meine Meinung (und inzwischen auch die meines derzeitigen Auftraggebers, nachdem er einen professionellen Scrum-Manager beschäftigt) ist die: SCRUM soll bekanntlich ein Instrument sein, um Teamwork zu organisieren, um sich kontinuierlich abzustimmen, was so anliegt, was sich neu ergibt und wer Teilaufgaben in der Gruppe aufgrund seiner Erfahrung und der verfügbaren Zeit am Besten übernehmen kann, um Leerlauf zu vermeiden und sich an ändernde Ziele anzupassen. SCRUM soll ferner ein Instrument sein, die sich daraus ergebenden Aufgaben in aller Gänze zu erfassen, zu verwalten und auf diese Weise sicherzustellen, dass nichts vergessen wird und nichts über wichtige Termine geht, wodurch es zu Problemen kommen könnte. Als Folge der Existenz und Nutzung von SCRUM, wie auch als Voraussetzung für dessen Sinnhaftigkeit leitet sich daraus zwangsläufig ab: 1) Es braucht / gibt ein Team, das als Gruppe an einer Aufgabe arbeitet 2) Die Aufgabenstellung und das Ergebnis sind nicht genau definiert und können sich während des Bearbeitens ändern 3) Die Art der Umsetzung wird von der Gruppe bestimmt 3) Teilaufgaben, die es schon gibt, können wegfallen. 4) Teilaufgaben, die es noch nicht gibt, können neu entstehen 5) Teilaufgaben werden unter den Teammitgliedern kurzfristig ausgetauscht Aus Sicht eines Projektleiters eine hübsche und ansehnliche Sache. Abgesehen davon, das das so in der Praxis kaum richtig funktioniert, ergeben sich aus Sicht eines Selbständigen folgende kontraindizierende Schlussfolgerungen: Punkt 1 verstößt gegen die Forderung, als Selbständiger nicht in ein Team eingebunden zu sein. Selbständige arbeiten maximal in Projektteams. Punkt 2 verstößt gegen die Forderung, dass das Ergebnis genau definiert ist und abnahmefähig ist. Es liegt keine klar abgegrenzte Tätigkeit vor. Punkt 3 verstößt gegen die Forderung, dass es eine vertragliche Regelung über die Leistung und deren Lieferung gibt, die vor Aufnahme der Tätigkeit vorliegt Punkt 4 verstößt ebenso gegen die Forderung, dass es eine vertragliche Regelung über die Leistung gibt, zudem verstößt es auch wieder gegen eine abgegrenzte nachprüfbare Beauftragung Punkt 5 verstößt gegen die Forderung, dass Teammitglieder keine Weisungen oder Aufträge an externe Unternehmer erteilen und schon gar nicht nach Lust und Laune als Ergebnis täglicher Absprachen. Man könnte sogar noch Punkt 0 definieren und darlegen, dass schon das Teilnehmen in einem SCRUM-Team ein Verstoß gegen die Selbständigkeit darstellt. Das sehen Gerichte auch so, zumindest dann, wenn die regelmäßige Teilnahme von der Firma verordnet wurde und eine so engmaschige Abstimmung durch die Notwendigkeiten im Projekt nicht begründbar ist. Eigentlich ist es im Grunde die gleiche Diskussion wie bei der Zeiterfassung und Überwachung: Der Selbständige soll permanent anwesend sein, um die Nachprüfbarkeit der Leistung zu gewährleisten. SCRUM macht es eigentlich noch schlechter und kritischer, weil neben der zeitlichen Kontrolle auch noch Änderungen am Auftrag erfolgen können sollen oder zumindest möglich sind, besonders, wenn sich die Ziele mittendrin ändern können. Meine Lösung: Ich mache in Absprache mit dem beauftragenden Projektleiter oder Abteilungsleiter über den Einkäufer einen Vertrag mit einem geplanten maximalen Stundenkontingent, das dann für diese Aufgabe abgearbeitet wird. Zudem gibt es einen Liefertermin. 1) Der Auftrag wird grosszügig bemessen. Nicht benötigte Stunden verfallen. Ich rechne es deshalb so, daß es in jedem Fall unterschritten wird. Der Termin wird auch so bemessen, daß er immer gehalten werden kann. 2) Aufwände für Reisen und Gerätchen, die ich erwerben muss, werden vorher gemeldet und kommen in den Voranschlag - später auf die Rechnung. 3) Unvorhergesehenes von meiner Seite lasse ich mir vom Projektleiter beauftragen. Will er das nicht, soll / darf er es sein Team machen lassen. Umgekehrt wird alles Zeug und Vorschläge aus seinem Team, das er an mich verteilen möchte, in einen neuen Auftrag, als Arbeitspaket geschoben - mit Angebot an die Firma. 4) Geld und Kosten werden ausschließlich mit dem Einkauf abgestimmt 5) Termine und Arbeitspaketinhalte ausschließlich mit dem Auftraggeber (PL, AL). 5) Abstimmungen und Telefonate gehen nur über den PL, im technisch begründeten Einzelfall auch gerne mal mit einem internen Spezialisten. Beides unregelmäßig alle 2-5 Tage mal, wenn etwas anliegt. 6) Am Ort des Kunden bin ich nur, wenn es nötig ist. Dann solange, wie ich brauche. Mal nur 3 Tagen dann auch 3 Wochen am Stück. Dann auch wieder 2 Monate gar nicht. Regeltermine gibt es keine. 7) Aufträge oder Vorgaben von Mitarbeitern gehen nur über den PL. Mitarbeiter erteilen direkt keine Aufträge - dürfen mir den Kaffe holen und die Türe aufhalten :-) --------------------------------------------------------- In Sachen SCRUM habe ich keine Probleme damit, wenn sich eine Firma das antun möchte und es gut findet. Der Pl bekommt von mir alle paar Tage einen Stand oder dann wenn er es einfordert. Er kann dann nach freien Stücken entscheiden, was er dem SCRUM-Team davon mitteilt und wie er es terminlich einbaut oder was er ändert. Zu machen gibt es diesbezüglich kaum etwas, weil die Planung schon vorher vorlag. Interessant wird es nur, wenn ich mit etwas nicht fertig werden würde, was aber nicht passiert, weil meine Planung konservativ vorauseilend läuft. Ich habe immer 1-2 Wochen Puffer vor mir. Daher beschränkt sich die Arbeit des PL darauf, im täglichen SCRUM-Meeting seinen Leuten stellvertretend mitzuteilen, dass ich noch on track bin. Er kann sich also voll drauf konzentrieren, sein Team in der Spur zu halten, wenn sie wieder mal "neue Ideen" für die Funktion der SW haben, die ihnen mittendrin einfallen, während 70% vom Zeug schon im Bau ist ;.) Ich bin daher zu Bürozeiten in Bereitschaft und kann angerufen werden, wenn eine Sache hochkommt, die sofortige Klärung erfordert. Wir haben ja Telefon :-) Real passiert das vielleicht 3-4 mal im Projekt. Gerade wieder: Beitrag "Universell programmierbare Datenerfassungskarte"
Tja @Selbständiger, was hat Dein Vertrag mit der Methode zu tun? Genau, nichts. Du vermischst juristische Themen mit Begriffen aus der Projektmethodik. Wenn Du einen Dienstleistungsvertrag hast, dann bist Du im agilen Team gut aufgehoben, weil Du das machst, was Dein Auftraggeber will. Im SCRUM Team gibt es keine direkte Weisung. Das Team gibt ein Commitment zum Sprint. Das Ziel legt der Product Owner fest, i.d.R. mit dem Auftraggeber. Die Behauptung, Zitat: „… Teilnehmen in einem SCRUM-Team ein Verstoß gegen die Selbständigkeit darstellt…“ - ist schlicht falsch. In meinem Betrieb werden Hunderte Freiberufler beschäftigt - in SCRUM Teams zur SW-Entwicklung. Und wir werden regelmäßig finanztechnisch geprüft, ohne Beanstandungen.
Uwe D. schrieb: > In meinem > Betrieb werden Hunderte Freiberufler beschäftigt was kein Beweis dafür ist, dass es rechtlich sauber war, wie die Prozesse bei EADS, Bosch und Siemens in der Vergangenheit bewiesen haben. Das Modell "Freiberufler" das viele Firmen fahren, ist oft keines und so ist auch die Art, wie diese Personen eingesetzt werden, nicht korrekt. Das gilt auch und umsomehr für die, welche über Drittanbieter eintreten, welche diese Dienstverhältnisse verschleiern sollen. Beitrag "Re: SOLCOM seriös?"
A. B. schrieb: > und was hat das mit SCRUM zu tun? Genau. Nix! Es geht ja nicht um scrum. Sondern um dessen Auswirkung auf Selbstständige bzw. sog. Selbstständige.
Wer als Freelancer diesen Scrumdreck mitmachen muss hat die Kontrolle über seinen Job verloren.
Martin K. schrieb: > Uwe D. schrieb: >> In meinem >> Betrieb werden Hunderte Freiberufler beschäftigt > was kein Beweis dafür ist, dass es rechtlich sauber war, wie die > Prozesse bei EADS, Bosch und Siemens in der Vergangenheit bewiesen https://www.gulp.de/freelancing/wissen/scheinselbststaendigkeit/urteil-scrum-projekte-kein-indiz-scheinselbststaendigkeit Der Vertrag muss diese Aspekte der RV berücksichtigen. Herbert B. schrieb: > Wer als Freelancer diesen Scrumdreck mitmachen muss hat die > Kontrolle > über seinen Job verloren. Was für ein Quark. Jede Menge Spezialisten kommen so zu Großaufträgen, ohne dass sie sich Gedanken machen müssen. Wer als Freiberufler „nur 0815-Sachen“ macht, verdient nie richtig Kohle. Und gerade bei SCRUM kann ich einen (vertraglich) entspannten Job machen, es geht ja um das Arbeitsergebnis…
Uwe D. schrieb: > Was für ein Quark. Jede Menge Spezialisten kommen so zu Großaufträgen, > ohne dass sie sich Gedanken machen müssen. Wer als Freiberufler „nur > 0815-Sachen“ macht, verdient nie richtig Kohle. Wer sagt denn dass man ohne den Scrumdreck nur 0815-Sachen macht? ME ist es genau andersrum. Die Affen müssen ins Scrumteam, die Profis dürfen separat arbeiten wie sie wollen, die haben alle Freiheiten und werden nicht mit dem Scrumdreck belästigt und behindert. > Und gerade bei SCRUM kann ich einen (vertraglich) entspannten Job > machen, es geht ja um das Arbeitsergebnis… Irgendwie hast du keinen blassen Schimmer wovon ich rede. Du kennst wohl nix anderes als nur mit dieser Scrumscheisse zu arbeiten. Mein Beileid.
Was soll das Gezerre. Wenn man's als Freiberufler abgegolten bekommt macht man's sonst eben nicht.
Herbert B. schrieb: > Uwe D. schrieb: >> Und gerade bei SCRUM kann ich einen (vertraglich) entspannten Job >> machen, es geht ja um das Arbeitsergebnis… > Irgendwie hast du keinen blassen Schimmer wovon ich rede. Du kennst wohl > nix anderes als nur mit dieser Scrumscheisse zu arbeiten. Mein Beileid. Dein Ton ist ein Spiegel Deiner Denke. Niemand hält Dich davon ab, das noch weitere 50 Jahre weiter zu verfolgen. Das ändert nichts daran, dass alle schnellen und großen Projekte NICHT mit Wasserfall gemacht werden. Und ich kenne vor allem die Wasserfall-Scheiße und Leute mit Ausreden, keiner Vorstellung was Veränderung & Komplexität & Geschwindigkeit angeht - und die immer tolle Sprüche auf den Lippen, die alles besser wissen, aber selten besser machen.
Uwe D. schrieb: > Tja @Selbständiger, was hat Dein Vertrag mit der Methode zu tun? Genau, > nichts. Du vermischst juristische Themen mit Begriffen aus der > Projektmethodik. > In meinem Betrieb werden Hunderte Freiberufler beschäftigt > wir werden regelmäßig finanztechnisch geprüft Das bedeutet nicht, dass es korrekt ist. Eine große Zahl von Freiberuflern arbeitet in einem Modus des Aufgabenerledigens auf Zuruf und sind damit und aus anderen Gründen praktisch Scheinselbständig. Das trittt nur oft nicht zutage, weil es keiner anzeigt oder es einfach nicht nachprüfbar ist. Eine "finanztechnische" Prüfung ist dafür auch überhaupt nicht geeignet, weil dort niemand die Inhalte von Werkverträgen prüft. Da kommt es einzig darauf an, ob Buchungen eine Gegenbuchung haben und z.B. einvernommene UST aus Rechnungen von Freiberuflern nicht erfunden, sondern eine Gegenbuchung haben, die UST durch den FB auch an dessen FA abgeführt wurde. Was wirklich interessiert, sind Betriebsprüfungen in arbeitsrechtlicher Hinsicht, bei denen dann ein großer Schwung von Ausgaben für externe Personen hochpoppen und es dann zu einem Tipp an die GRV kommt. Die sind auch durchaus sehr behende in der Zustellung von Bescheiden und besonders "große" Firmen haben das auch schon zu spüren bekommen, weil die RV da gerne gräbt. Ja es hat mit der Projektmethode Srum zunächst nichts zu tun. Sobald diese oder andere Formen der Projektzusammenarbeit aber dazu führen, dass wesentliche Kriterien der Selbständigkeit verletzt werden, gibt es ein Problem und SCRUM hat ganz eindeutig das Potenzial, die Problematik zu verschärfen. Auch wenn es sich um einen Dienstvertrag handelt, müssen Inhalte benannt werden und abgrenzbar sein, bei einem regelmäßigen Zusammenarbeiten mit den Angestellten des Kunden noch um so mehr. Das Schlechtestes was man machen kann, ist sich mit den Angestellten zusammen ins SCRUM-Meeting zu setzen - es sei denn man ist der extern beauftragte SCRUM Master und hat einen Auftrag, z.B. mehrere Teams zu monitoren und zu reporten.
Uwe D. schrieb: > Der Vertrag muss diese Aspekte der RV berücksichtigen. Der Vertrag aber auch nachher das was getan wird. Rechnungen müssen bekanntlich Leistungszeitraum und Liefergegenstand beinhalten und das sollte schon auch passen. Herbert B. schrieb: > Wer sagt denn dass man ohne den Scrumdreck nur 0815-Sachen macht? > ME ist es genau andersrum. Die Affen müssen ins Scrumteam, die Profis > dürfen separat arbeiten wie sie wollen, die haben alle Freiheiten und > werden nicht mit dem Scrumdreck belästigt und behindert. Auch wenn das sehr plakativ klingt, kann man das so durchaus unterschreiben. Die Geschichte fängt ja schon damit an, dass die Firma überhaupt die Vorgabe macht, nach welcher Methode gearbeitet wird und hier SRCUM oder etwas anders vorgibt. Selbständigen ist es aber nicht nur zeitlich, sondern auch inhaltlich völlig selbst überlassen, wie sie arbeiten, weil eben nur das Ergebnis zählt. Einzige formelle Anforderungen sind hier zu beachten, wie z.B. Art und Umfang der sog. Qualitätsdokumente. Auch ein Audit kann vorgeschrieben und durchgeführt werden. Nicht aber terminierte Treffs mit Angestellten.
Uwe D. schrieb: > Und ich kenne vor allem die Wasserfall-Scheiße und Leute mit Ausreden, > keiner Vorstellung was Veränderung & Komplexität & Geschwindigkeit > angeht Dies abwehrende Haltung kenne ich wiederum von Leuten, die unkritisch alles fressen, was ihnen vorgegeben wird, SCRUM als heilige Kuh behandeln und in den Himmel loben und sich dessen abwertende Argumentation zu eigen machen, SCRUM sei "agil" und alle, die es kritisieren seien unflexibel. Tatsache ist, dass SCRUM funktioniert wie ein Autopilot, um unkoordiniert arbeitende Programmierhorden zu synchronisieren, die sich ansonsten selber nicht organisieren könnten, was auch so falsch nicht ist, wenn man sich die Arbeitsweise in bestimmten Ländern ansieht, wo die Horden sitzen und zuzdem sich in Erinnerung ruft, WO das SCRUM erfunden wurde, nämlich im Land der bachelor, wo alle eine kurze Schnellausbildung ohne Tiefgang haben und jeder hemdsärmleig an alles dranstürmt, weil es weder Meisterprüfung noch sonst welche Qualitätsansprüche gibt. Trainierte und gut eingearbeitete Ingenieure (und gerne auch Informatiker) haben aber schon gute und der Sitation angepasste Methoden drauf und sind selber in der Lage, sich zu jeder Zeit einer Projektsituation anzupassen, rasch Informationen zu beschaffen, an Angestellte heranzutreten um mit diesen zu kommunizieren und dies in sehr viel agilerer und flexiblerer Weise, als das in dem in 3-Wochen getakteten SCRUM-System mit täglichen ineffektiven Zwischentakten möglich ist. Das SCRUM ist das Polling, das selbständige dynamische Arbeiten, wie wir das seit Dekaden praktizieren, ist die Echtzeitbearbeitung und die ist allemal überlagen. Das hat auch mit Wasserfall direkt nichts zu tun, bzw. ist kein Gegensatz: Auch im SCRUM gibt es ja Vorgaben, Umsetzung und Prüfung ob stimmig und erledigt oder nicht, um dann weiterzugehen oder umzudisponieren. Das sind ebenfalls kleine Wasserfall- oder V-Modelle. Nichts anderes. Der Punkt ist nur der, dass Viele erfahrungsgemäß sich darauf verlassen, SCRUM werde es schon richten und man bräuchte keine saubere Planung mehr und werden schlampig und oberflächlich. Bei der Umsetzung von Software in der Programmierhorde mag das so gehen, aber Elektronikentwicklungen haben eine größere Bandbreite. Da müssen manchmal Entscheidungen binnen Stunden getroffen werden, weil es um Hardware geht, die sich nicht ändern oder korrigieren lässt und umgekehrt müssen Planungen über 12 Wochen aufgezogen werden, damit Bauteilbeschaffung , Layout und Inbetriebnahme koordiniert werden können. Pauschale 3W-Prozesse passen da in keinster Weise hinein. Die Arbeit und die Leistung vieler Selbständiger ist aber eben, genau diese Planungen mitzuerledigen und zu beürcksichtigen, also ihre Komponenten mit denen anderer zu verknüpfen und zu koordinieren. Nimmt man das weg und schiebt die Verwaltung des Projektes nach Innen ins Team oder gar die Definition der Ziele an einen Produktowner, dann bleibt keinerlei Verantwortlichkeit mehr über. Das ist dann keine Tätigkeit mehr, die einen Freiberufler erfordert, der "durch überdurchschnittliche Befähigung und eigenverantwortliches Handeln" gekennzeichnet ist, wie es wörtlich heißt. Bleiben also nur Durchschnittstätigkeiten bei deren Erledigung man sehr gut aufpassen muss, dass diese völlig abgegrenzt definiert und durchgeführt werden.
A. F. schrieb: > Dies abwehrende Haltung kenne ich wiederum von Leuten, die unkritisch > alles fressen, was ihnen vorgegeben wird, SCRUM als heilige Kuh > behandeln und in den Himmel loben und sich dessen abwertende > Argumentation zu eigen machen, SCRUM sei "agil" und alle, die es > kritisieren seien unflexibel. Aber bewege dich heute mal in einem Team, das Scrum verinnerlicht hat und erlaube es dir, zu kritisieren, was so alles nicht funktioniert. Dann bist du schnell aussen vor, weil du derjenige bist, der das alles nicht verstanden hat.
A. F. schrieb: > Uwe D. schrieb: >> Und ich kenne vor allem die Wasserfall-Scheiße und Leute mit Ausreden, >> keiner Vorstellung was Veränderung & Komplexität & Geschwindigkeit >> angeht > Dies abwehrende Haltung kenne ich wiederum von Leuten, die unkritisch > alles fressen, was ihnen vorgegeben wird, SCRUM als heilige Kuh Also ich finde jetzt keine Stelle, an der ich geschrieben hätte, dass ich kritiklos alles mache. Nur verballere ich nicht meine Zeit damit Anderen zu erklären, warum etwas nicht gehen kann. > Tatsache ist, dass SCRUM funktioniert wie ein Autopilot, um > unkoordiniert arbeitende Programmierhorden zu synchronisieren, die sich > ansonsten selber nicht organisieren könnten, was auch so falsch nicht > ist, wenn man sich die Arbeitsweise in bestimmten Ländern ansieht, wo > die Horden sitzen und zuzdem sich in Erinnerung ruft, WO das SCRUM > erfunden wurde, nämlich im Land der bachelor, Es ist keine Tatsache. Du verallgemeinerst populistisch. Und Deine Haltung „Horden“ sagt mehr über Dich als über die Amerikaner, die Du belächelst. > Schnellausbildung ohne Tiefgang haben und jeder hemdsärmleig an alles > dranstürmt, weil es weder Meisterprüfung noch sonst welche > Qualitätsansprüche gibt. Deshalb kommen die meisten Innovationen auch aus dem strukturierten Besserwisserland, oder…. HaHaHa. > …Projektsituation anzupassen, rasch Informationen zu beschaffen, an > Angestellte heranzutreten um mit diesen zu kommunizieren und dies in > sehr viel agilerer und flexiblerer Weise, als das in dem in 3-Wochen > getakteten SCRUM-System mit täglichen ineffektiven Zwischentakten > möglich ist. Was erzählst Du? In jeder Projektmethodik gilt der Grundsatz: Anpassung an das Projekt(umfeld). Und Sprints sind nicht auf 3 Wochen festgelegt. > Das hat auch mit Wasserfall direkt nichts zu tun, bzw. ist kein > Gegensatz: Auch im SCRUM gibt es ja Vorgaben, Umsetzung und Prüfung ob > stimmig und erledigt oder nicht, um dann weiterzugehen oder > umzudisponieren. Das sind ebenfalls kleine Wasserfall- oder V-Modelle. > Nichts anderes. Nö, es gibt Regeln wie miteinander gearbeitet wird. Der Fokus liegt auf dem sich immer weiter entwickelnden und nutzstiftenden Produkt - aber auf keinem Plan. > Bei der Umsetzung von Software in der Programmierhorde mag das so gehen, > aber Elektronikentwicklungen haben eine größere Bandbreite. Da müssen > manchmal Entscheidungen binnen Stunden getroffen werden, weil es um > Hardware geht, die sich nicht ändern oder korrigieren lässt und Ach was. Warum sollten agile Projekte und Teams das nicht können? > umgekehrt müssen Planungen über 12 Wochen aufgezogen werden, damit > Bauteilbeschaffung , Layout und Inbetriebnahme koordiniert werden > können. Pauschale 3W-Prozesse passen da in keinster Weise hinein. Du meinst, die SCRUM-Deppen (mal in Deine Sprache übersetzt) können nicht weiter als bis zum Sprintende gucken? > Bleiben also nur Durchschnittstätigkeiten bei deren Erledigung man sehr > gut aufpassen muss, dass diese völlig abgegrenzt definiert und > durchgeführt werden. Keine Ahnung was Du für Erfahrungen hast, es gibt immer bescheidene Projekte - auch im agilen Umfeld. Auch da muss ein Team lernen und den Mist im Kopf beseitigen, den die „Oberplaner“ über Jahre hinterlassen haben. Und jeder erfahrene Projektleiter der Wasserfall-Erfahrung hat weiß, dass Null-Komma-kein Projekt ein belastbares Lastenheft mitbringt. Und jetzt gucke mal auf Deine eigenen Projekte und sei mal selbstkritisch. Dann wird die Abweichung nicht nur inhaltlich, sondern vor allem zeitlich und monetär sicher einen mittleren 2-Stellungen Prozentwert haben. Nachtrag: Du bist herzlich nach Dresden zum Forentreffen eingeladen, da können wir direkt Bezug auf Deine oder meine (realen) Projekte nehmen.
:
Bearbeitet durch User
Uwe D. schrieb: > achtrag: Du bist herzlich nach Dresden zum Forentreffen eingeladen, da > können wir direkt Bezug auf Deine oder meine (realen) Projekte nehmen. Da ich das gerade lese: Das Forum trifft sich in Dresden? Warum gerade da?
Heiko E. schrieb: > Uwe D. schrieb: >> achtrag: Du bist herzlich nach Dresden zum Forentreffen eingeladen, da >> können wir direkt Bezug auf Deine oder meine (realen) Projekte nehmen. > > Da ich das gerade lese: Das Forum trifft sich in Dresden? Warum gerade > da? Da steht nicht das WARUM im Beitrag, aber die Frage ist sicher erlaubt :-) Vermutlich, weil „jemand“ einen Vorschlag gemacht. Beitrag "Fährgarten Johannstadt ab 17 Uhr (Biergartentreff Dresden 2023)"
Aha! Gibt es auch Treffen, die mehr in der Mitte Deutschlands liegen und nicht an der polnischen Grenze?
Heiko E. schrieb: > Aha! Gibt es auch Treffen, die mehr in der Mitte Deutschlands liegen und > nicht an der polnischen Grenze? Dräsdn liegt näher an Tschechien als an Polen.
Heiko E. schrieb: > Aha! Gibt es auch Treffen, die mehr in der Mitte Deutschlands liegen und > nicht an der polnischen Grenze? Ja, Du musst es einfach nur organisieren. Oder sich zusammenschließen. Die Quintessenz des Dresdner Treffens: Auch konträre Standpunkte können besprochen werden und die fehlende virtuelle Maske des Internet sorgt für freundlicheren Ton. Es war durchweg freundlich. Und überraschend. Nachtrag: Wertschätzend trifft es noch besser.
:
Bearbeitet durch User
Wie wäre es mit Ruhrgebiet? Z.B. ein Biergarten fußläufig von einem der großen Bahnhöfe Duisburg, Essen, Bochum, Dortmund.
Achim H. schrieb: > (-1 von mir wg. Off-Topic in diesem Thread) Uups, sorry, natürlich völlig zurecht
Uwe D. schrieb: > Und jeder erfahrene Projektleiter der Wasserfall-Erfahrung hat weiß, > dass Null-Komma-kein Projekt ein belastbares Lastenheft mitbringt. Kommt auf die Inhalte an. Wenn sehr forschungslastig im Probiermodus gearbeitet wird, dann rennt die Physik immer der Elektronik voraus und man ist stetig am ändern. Wenn aber die funktionellen Ziele klar sind, z.B. für einen technischen Milestone, dann sollte ein erfahrener Entwickler Zeiten und Kosten kommunizieren können, damit eine Entscheidung ergeht, was wann von wem erzeugt wird. Eventuell muss man es etwas kleinteiliger anlegen und in Teilprojekte splitten. Warin ich keinen Sinn sehe, sind open end definitions, wo das Ändern schon eingeplant ist und das Arbeiten ein ständiges Nachlaufen und Planen aus der Hostentasche ist. Die Einführung von SCRUM hat allerdings exakt das gefördert. Läuft das Projekt schief und kr..umm, so nennt es einfach "Scr ..umm"!
Naja, bei klassischen Wasserfallprojekten bekommt man im günstigsten Fall genau das, was man mal geplant hatte. Im agilen Projekt bekomme ich das was ich brauche.
Uwe D. schrieb: > Naja, bei klassischen Wasserfallprojekten bekommt man im günstigsten > Fall genau das, was man mal geplant hatte. Im agilen Projekt bekomme ich > das was ich brauche. Welch ein platter Unfug! Die organisierte Indoktrination durch die Scrum-Jünger zeigt auffällig Wirkung. Brav plappert man blind das nach, was die Propagandisten behaupten.
Beitrag #7480641 wurde von einem Moderator gelöscht.
Uwe D. schrieb: > Naja, bei klassischen Wasserfallprojekten bekommt man im günstigsten > Fall genau das, was man mal geplant hatte. Im agilen Projekt bekomme ich > das was ich brauche. Dann war der Plan aber schlecht. Und ob du den nun im agilen oder Wasserfall-Projekt anpasst ist ja auch egal.
Manni T. schrieb: > Warin ich keinen Sinn sehe, sind open end definitions, wo das Ändern > schon eingeplant ist und das Arbeiten ein ständiges Nachlaufen und > Planen aus der Hostentasche ist. Die Einführung von SCRUM hat allerdings > exakt das gefördert. Das ist aber genau dass, was die meisten Kunden (in meinem Umfeld) wollen. Die Anforderungen kommen erst während der Entwicklung. Wenn wir uns nicht darauf einlassen würden, wären wir arbeitslos.
:
Bearbeitet durch User
Stefan F. schrieb: > Das ist aber genau dass, was die meisten Kunden (in meinem Umfeld) > wollen. Die Anforderungen kommen erst während der Entwicklung. Wenn wir > uns nicht darauf einlassen würden, wären wir arbeitslos. Dann sucht ihr euch die falschen Kunden raus. Sowas schickt man gleich in die Wüste, bei der heutigen Auftragslage kann man sich das leisten und ehrlich gesagt hat das heute auch jeder Kunde begriffen, dass er da nicht mehr mit den Entwicklern wie mit Hampelmännern umspringen kann. Wir sind nicht mehr in den 90ern.
Herbert B. schrieb: > Dann sucht ihr euch die falschen Kunden raus. Keineswegs. Wir füllen diese Marktlücke und werden dafür gut bezahlt.
Stefan F. schrieb: > Keineswegs. Wir füllen diese Marktlücke und werden dafür gut bezahlt. Das liest sich oben aber anders. Ihr müsst dieses Kropzeuchs an Kunden nehmen, weil ihr keine anderen akquirieren könnt. Das "gut bezahlt" ist wohl eher Schmerzensgeld wenn man sich sowas antun muss, wenn der Kunde dauernd antanzt und ne neue fixe Idee hat. Marktlücke nennt man das jetzt, ah ja.
Herbert B. schrieb: > Das "gut bezahlt" ist wohl eher Schmerzensgeld Nicht jede Firma besteht aus Weicheiern.
Herbert B. schrieb: > Ihr müsst dieses Kropzeuchs an Kunden > nehmen, weil ihr keine anderen akquirieren könnt. Das "gut bezahlt" ist > wohl eher Schmerzensgeld wenn man sich sowas antun muss, wenn der Kunde > dauernd antanzt und ne neue fixe Idee hat. Marktlücke nennt man das > jetzt, ah ja. So etwas kann man nur einer sagen, der noch nie so gearbeitet hat und quasi als Blinder von der Farbe redet. Es ist so viel effizienter, inspirierender, spannender und besser, gemeinsam mit einem Kunden ein Projekt voranzutreiben, von dem beide Seiten noch gar nicht genau wissen, wo das Ziel ist. Bis dein Behörden-ich-kenne-nur-Wasserfall-Kunde sein Lastenheft so weit durch endlose Iterationen verfeinert hat, bis es der designierte AN mit einer Kostenkalkulation und Angebot erwidert hat und Du endlich damit stumpf das Lastenheft in ein Produkt umsetzt, habe ich in einem agilen Team bereits den zweiten Prototyp in der Mache und dabei zigmal mehr gelernt, als Du es je wirst.
:
Bearbeitet durch User
Klaus schrieb: > Es ist so viel effizienter, inspirierender, spannender und besser, > gemeinsam mit einem Kunden ein Projekt voranzutreiben, von dem beide > Seiten noch gar nicht genau wissen, wo das Ziel ist. Klingt, als ob ihr Aufträge bekommt, bei denen der Kunde gar nicht weiß, was er eigentlich braucht und ob er es braucht? Ich kenne das als ineffizienter, weil man am Anfang bei den Tätigkeiten von Sachen ausgegangen ist, die dann plötzlich nicht mehr zutreffen, und man dann gerne seine bisherige Arbeit beerdigen und nochmal von vorne anfangen darf. Gerade bei praktischer Arbeit treibt sowas die Kosten in enorme Höhen. Klaus schrieb: > habe ich in einem agilen > Team bereits den zweiten Prototyp in der Mache und dabei zigmal mehr > gelernt, als Du es je wirst. Von dem, deiner Aussage nach, du und der Kunde aber immer noch nicht wissen, ob er das darstellt, was der Kunde will.
:
Bearbeitet durch User
Reinhard S. schrieb: > Gerade bei praktischer Arbeit treibt sowas die Kosten in enorme Höhen. Solange der Kunde genau so vorgehen will und dafür bezahlt ist doch alles in Ordnung.
Reinhard S. schrieb: > Von dem, deiner Aussage nach, du und der Kunde aber immer noch nicht > wissen, ob er das darstellt, was der Kunde will. Richtig. Aber beide Seiten lernen anhand der Prototypen und Proof-of-Concepts laufend, was technologisch umsetzbar ist und ob das Projekt überhaupt noch in die richtige Richtung geht. Im Wasserfallmodell hat der Kunde zum Zeitpunkt X ein fix und fertiges Produkt, das im besten Fall alle Wünsche und Anforderungen erfüllt. Wahrscheinlicher ist, dass sich entweder Anforderungen in der Zwischenzeit geändert haben, oder neuere Technologie inzwischen viel geeignetere oder günstigere Lösungen ermöglicht hätte. Wenn du privat was basteln willst: setzt du dich dann hin und schreibst erstmal ein detalliertes Lastenheft an dich selbst, oder legst du nicht vielmehr los, sobald du ein grobes Konzept im Kopf hast?
Stefan F. schrieb: > Reinhard S. schrieb: >> Gerade bei praktischer Arbeit treibt sowas die Kosten in enorme Höhen. > > Solange der Kunde genau so vorgehen will und dafür bezahlt ist doch > alles in Ordnung. Es ist aber für einen selbst durchaus unbefriedigend und wir haben auch schon Leute im Konzern, die aus solchen Gründen nicht mehr für diesen Kunden/Auftraggeber arbeiten wollen. Klaus schrieb: > Reinhard S. schrieb: >> Von dem, deiner Aussage nach, du und der Kunde aber immer noch nicht >> wissen, ob er das darstellt, was der Kunde will. > > Richtig. Aber beide Seiten lernen anhand der Prototypen und > Proof-of-Concepts laufend, was technologisch umsetzbar ist Das sollte man doch aber schon bei der Planung des Projektes wissen? > und ob das Projekt überhaupt noch in die richtige Richtung geht. Dafür gibts die Projektleitung. > Im Wasserfallmodell hat der Kunde zum Zeitpunkt X ein fix und fertiges > Produkt, das im besten Fall alle Wünsche und Anforderungen erfüllt. > Wahrscheinlicher ist, dass sich entweder Anforderungen in der > Zwischenzeit geändert haben, oder neuere Technologie inzwischen viel > geeignetere oder günstigere Lösungen ermöglicht hätte. Dann dauern deine Projekte zu lange und/oder es gibt zuviel "Fortschritt". (Neue Dinge sind ja nicht gleich Fortschritt). Geänderte Anforderungen gibts davon ab ja wie gesagt auch bei Wasserfallprojekten, manchmal mit den von mir oben geschilderten Effekten. > Wenn du privat was basteln willst: setzt du dich dann hin und schreibst > erstmal ein detalliertes Lastenheft an dich selbst, oder legst du nicht > vielmehr los, sobald du ein grobes Konzept im Kopf hast? Ich lege los, sobald ich ein halbwegs detailliertes Konzept habe. Wie soll ich auch loslegen, wenn ich gar nicht weiß, was ich will/brauche und mit welchen Materialien/Formen ich dahin komme?
Reinhard S. schrieb: > Dann dauern deine Projekte zu lange Sorry, hab den Thread-Titel nicht beachtet. Bin nicht selbständig, unsere Projekte dauern Minimum 2 Jahre mit ein bis drei Scrum-Teams.
Manni T. schrieb: > Uwe D. schrieb: >> Naja, bei klassischen Wasserfallprojekten bekommt man im günstigsten >> Fall genau das, was man mal geplant hatte. Im agilen Projekt bekomme ich >> das was ich brauche. > Welch ein platter Unfug! Beantworte einfach folgende Frage: Warum sind Großprojekte wie Hamburger Philharmonie, Stuttgart 21, Flughafen BER so viel teurer geworden? Und bitte nenne nachprüfbare Fakten und Argumente.
Reinhard S. schrieb: > Es ist aber für einen selbst durchaus unbefriedigend Nein, warum sollte es? Ich habe einen ziemlich bequemen Job, wo ich zu Fuß hin gehen kann und nur selten Stress habe. Überstunden kommen nur selten vor, und sind dann meistens von mir selbst beschlossen worden. Ich produziere sinnvolle Dinge die mindestens zufriedenstellend, meistens gut funktionieren. Was will man mehr? > Wie soll ich auch loslegen, wenn ich > gar nicht weiß, was ich will/brauche > und mit welchen Materialien/Formen > ich dahin komme? Gar nichts zu wissen ist übertrieben. Natürlich legt man erst los, wenn man zumindest grob weiss, was zu tun ist. Dass man manche Details während der Entwicklung nichmal ändert, ist doch keine Schande. Software ist nicht in Stein gemeißelt.
:
Bearbeitet durch User
Klaus schrieb: > Reinhard S. schrieb: >> Von dem, deiner Aussage nach, du und der Kunde aber immer noch nicht >> wissen, ob er das darstellt, was der Kunde will. > > Richtig. Aber beide Seiten lernen anhand der Prototypen und > Proof-of-Concepts laufend, was technologisch umsetzbar ist und ob das > Projekt überhaupt noch in die richtige Richtung geht. Genauso ist das. Produkte, die es in der Form noch nicht gibt oder auch einem neuen Design folgen, um Schwächen oder Stärken anderer Lösungen zu umgehen bzw. verstärken. > Im Wasserfallmodell hat der Kunde zum Zeitpunkt X ein fix und fertiges > Produkt, das im besten Fall alle Wünsche und Anforderungen erfüllt. > Wahrscheinlicher ist, dass sich entweder Anforderungen in der > Zwischenzeit geändert haben, oder neuere Technologie inzwischen viel > geeignetere oder günstigere Lösungen ermöglicht hätte. Genau das passiert nicht nur im öffentlichen Umfeld staatlicher Ausschreibungen oder großer Mittelständler. Der Markt ist starken Veränderungen ausgesetzt. Bevor alle Pflichtenhefte fertig sind, stehen die nächsten CR‘s an. Der Kunde bezahlt die ganze Zeit für die Planerei und Konteptionen, ohne etwas - außer Papier - produktiv einsetzen zu können. Das Einzige was er weiß: Es wird teurer. > Wenn du privat was basteln willst: setzt du dich dann hin und schreibst > erstmal ein detalliertes Lastenheft an dich selbst, oder legst du nicht > vielmehr los, sobald du ein grobes Konzept im Kopf hast? Genau so sehe ich das auch: Eine Gruppe von Nutzern hat einen Bedarf, eine Vision - und genau das wird auch gemacht: Der Kunde ist direkt beteiligt und sieht was entsteht, kann sofort das Produkt einsetzen - ein evolutionäres Wachsen. Und ja, wenn die „SCRUM-Hasser“ so viel besser wären wie sie behaupten zu sein, dann gäbe es nur glückliche Kunden und massenhaft Produkte die alle möglichen Anwendungsfälle abdecken.
Reinhard S. schrieb: > Ich lege los, sobald ich ein halbwegs detailliertes Konzept habe. Wie > soll ich auch loslegen, wenn ich gar nicht weiß, was ich will/brauche > und mit welchen Materialien/Formen ich dahin komme? Ich kann schon los legen, sobald genug Infos da sind, dass ich bis zum nächsten Zusammentreffen mit dem Kunden beschäftigt bin. Ob das die effizienteste Vorgehensweise ist, ist mir ziemlich egal. Das muss der Kunde für sich entscheiden. Den Tagessatz kennt er. Ich werde nicht fürs Planen und Labern bezahlt (das tun andere), sondern für's Machen. Während ich mit "meinem" Team programmiere, dokumentiere und teste, planen andere Leute die nächsten Schritte.
He. schrieb: > A. F. schrieb: >> Dies abwehrende Haltung kenne ich wiederum von Leuten, die unkritisch >> alles fressen, was ihnen vorgegeben wird, SCRUM als heilige Kuh >> behandeln und in den Himmel loben und sich dessen abwertende >> Argumentation zu eigen machen, SCRUM sei "agil" und alle, die es >> kritisieren seien unflexibel. Was willst Du eigentlich damit ausdrücken? Warum soll in SCRUM an Argumentation abwertend sein - ist agil ein Schimpfwort? Weißt Du was agil heißt? > Aber bewege dich heute mal in einem Team, das Scrum verinnerlicht hat > und erlaube es dir, zu kritisieren, was so alles nicht funktioniert. Natürlich gibt es in SCRUM Raum für Kritik. Nur hat keiner Bock in einem guten Team - egal ob agil oder klassisch, sich von einem Besserwisser anmachen zu lassen. Der Ton macht die Musik. > Dann bist du schnell aussen vor, weil du derjenige bist, der das alles > nicht verstanden hat. Die Zeilen transportieren persönliche Bewertungen, mehr nicht. Und ich bezweifle, dass Du jemals in einem erfahrenen SCRUM Team gearbeitet hast. Du kannst gerne Deinem Stiefel weiter folgen. Nur erzähle mir nicht, dass Dein Weg der einzig Wahre wäre.
Uwe D. schrieb: > Manni T. schrieb: >> Uwe D. schrieb: >>> Naja, bei klassischen Wasserfallprojekten bekommt man im günstigsten >>> Fall genau das, was man mal geplant hatte. Im agilen Projekt bekomme ich >>> das was ich brauche. >> Welch ein platter Unfug! > > Beantworte einfach folgende Frage: Warum sind Großprojekte wie Hamburger > Philharmonie, Stuttgart 21, Flughafen BER so viel teurer geworden? War man, zumindest beim BER, nicht dermaßen agil, das die Ausführung schneller als die Planung war? Stefan F. schrieb: > Reinhard S. schrieb: >> Es ist aber für einen selbst durchaus unbefriedigend > > Nein, warum sollte es? > > Ich habe einen ziemlich bequemen Job, wo ich zu Fuß hin gehen kann und > nur selten Stress habe. Überstunden kommen nur selten vor, und sind dann > meistens von mir selbst beschlossen worden. Ich produziere sinnvolle > Dinge die mindestens zufriedenstellend, meistens gut funktionieren. Das hat aber nichts mit obenstehendem Problem zu tun. Wenn man Dinge baut, die dann aber wegen Agilität/schlechter Planung wieder abreißen/umbauen muss (natürlich inkl. seperater Anfahrt/Abfahrt) ist das nur bedingt erfüllend, selbst wenns bezahlt wird. Man hätte so viel sinnvolleres in der Zeit tun können... >> Wie soll ich auch loslegen, wenn ich >> gar nicht weiß, was ich will/brauche >> und mit welchen Materialien/Formen >> ich dahin komme? > > Gar nichts zu wissen ist übertrieben. Natürlich legt man erst los, wenn > man zumindest grob weiss, was zu tun ist. Dass man manche Details > während der Entwicklung nichmal ändert, ist doch keine Schande. Software > ist nicht in Stein gemeißelt. Das ist auch bei Hardware/Mechanik nicht unbedingt in Stein gemeißelt (es braucht ja Argumente für eine Version 2), aber halt ärgerlich, wenn man das hätte eher sehen können und man sonstwas für Umwege dafür gehen muss.
:
Bearbeitet durch User
Reinhard S. schrieb: > Wenn man Dinge > baut, die dann aber wegen Agilität/schlechter Planung wieder > abreißen/umbauen muss (natürlich inkl. seperater Anfahrt/Abfahrt) ist > das nur bedingt erfüllend, selbst wenns bezahlt wird. Als ich jung war ging es mir oft so. Inzwischen sehe ich es anders: Ich arbeite wegen dem Geld. Solange meine Arbeitszeit gut bezahlt wird, ist alles gut. Ich tue mir keinen Gefallen damit, mich über die Fehler anderer zu ärgern, die andere ausbaden müssen. Es ist nicht mein Geld, das dabei verprasst wird. Bisher hat mich noch niemand dafür kritisiert den bestellten Misst gebaut zu haben. Ganz im Gegenteil schätzen meine Kunden, dass ich zusammen mit ihnen Experimente wage und nicht an meinem "Baby" hänge, wie ein Künstler. Was weg soll kommt weg. Wenn ich in eine Kneipe gehe um mich zu besaufen und draußen alles wieder aus zu kotzen, ist das dem Wirt auch egal.
Klaus schrieb: > Im Wasserfallmodell hat der Kunde zum Zeitpunkt X ein fix und fertiges > Produkt, das im besten Fall alle Wünsche und Anforderungen erfüllt. Wenn er weis was er will ist das definitiv die beste Vorgehensweise. Weis er es nicht, weil sich zwischendrin was ändern könnte, muss er eben Zwischenschritte definieren. In jedem Fall muss er einem Auftragnehmer eine klare Vorgabe machen, was als Nächstes gebaut werden soll. Das wird mit SCRUM nicht anders. > Wahrscheinlicher ist, dass sich entweder Anforderungen in der > Zwischenzeit geändert haben, oder neuere Technologie inzwischen viel > geeignetere oder günstigere Lösungen ermöglicht hätte. Das kann der Auftraggeber in allen Arbeitsmodellen jederzeit eintreiben und einfordern. Es geht doch hier um etwas gänzlich anderes, nämlich, wie die Anforderungen jeweils umgesetzt werden: SCRUM gibt vor, dass ein Team die Entscheidungen trifft. Das ist der Punkt, an dem sich der thread aufhängt: Wenn ein Selbständiger im Team integriert ist, das entscheidet, könnte das den rechtlichen Bedingungen widersprechen. Das gilt dann wiederum für alle Arten der Vertragsgestaltung. Wir lösen das ganz elegant, indem wir kleine Pakete von 2-3 Monaten vergeben, die ein klares Ziel haben. In der Zeit ändert sich weder die Technologie, noch die Ziele des Projektes. Weder von intern noch von extern. > Wenn du privat was basteln willst: setzt du dich dann hin und schreibst > erstmal ein detalliertes Lastenheft Entschuldigung das ist doppelter Blödsinn! Wenn du ALLEINE etwas baust, bist du keine Team und brauchst auch keine Organisation. Hat also mit SCRUM nichts zu tun. Es hat auch mit Lastenheften nichts zu tun, weil die nicht rechtsverbindlich sein müssen. Ferner ist es so, dass Bastelprojekte zu klein sind, um sie grossarttig zu managen. Das muss ein Teamleiter in seiner Abteilung auch nicht tun. Er sagt einfach: Bau die Platine und such die Bauteile. Demzufolge ist zu überlegen, welche Aufträge man überhaupt nach extern vergibt. Es gibt Dinge, die man besser intern mit festen Mitarbeitern macht und das tägliche Neuausrichten (egal ob SCRUM oder nicht) geht eben nicht mit Externen. Und das macht auch keinen Sinn sich das offenzuhalten: Wenn ich einen Routingauftrag herausgebe, dann ist die Schaltung fix, hat das review hinter sich und wir befinden uns post design freeze! D.h. des KANN nach Prozess gar nichts mehr geändert werden. Alles, was noch jemand haben will, kommt in die nächste Version. Du kommst sonst aus dem Ändern und Zicktacklaufen nicht mehr heraus.
Manni T. schrieb: > Klaus schrieb: >> Im Wasserfallmodell hat der Kunde zum Zeitpunkt X ein fix und fertiges >> Produkt, das im besten Fall alle Wünsche und Anforderungen erfüllt. > Wenn er weis was er will ist das definitiv die beste Vorgehensweise. > > Weis er es nicht, weil sich zwischendrin was ändern könnte, muss er eben > Zwischenschritte definieren. Kannst Du nicht, weil Du noch nicht weißt, dass Du da da nicht weiterkommst oder als AG erkennst, das dieser Weg eine Sackgasse ist. > Das wird mit SCRUM nicht anders. Aber ja: Der AG sagt, was ihm wichtig ist. Nur er kennt den Einsatzzweck und die Prozesse am Besten. >> Wahrscheinlicher ist, dass sich entweder Anforderungen in der >> Zwischenzeit geändert haben, oder neuere Technologie inzwischen viel > Das kann der Auftraggeber in allen Arbeitsmodellen jederzeit eintreiben > und einfordern. Der AG kann einfordern, was er vorher im Lastenheft formuliert hat. Das gilt noch härter bei Ausschreibungen mit Gelder aus dem Euro-/Staatstopf. Eine nicht vollständige und sich erschöpfende Leistungsbeschreibung gilt als schwerer Vergabefehler. > Es geht doch hier um etwas gänzlich anderes, nämlich, wie die > Anforderungen jeweils umgesetzt werden: > > SCRUM gibt vor, dass ein Team die Entscheidungen trifft. Das ist der > Punkt, an dem sich der thread aufhängt: Wenn ein Selbständiger im Team > integriert ist, das entscheidet, könnte das den rechtlichen Bedingungen > widersprechen. Wie kommst Du darauf? Der Freiberufler unterliegt ja keinem Weisungsrecht des AG. Und im SCRUM Team gibt es auch keine Weisung. Der AG sagt Was er braucht und das SCRUM Team entscheidet Wie es das Problem löst. > Das gilt dann wiederum für alle Arten der Vertragsgestaltung. Wir lösen > das ganz elegant, indem wir kleine Pakete von 2-3 Monaten vergeben, die > ein klares Ziel haben. In der Zeit ändert sich weder die Technologie, > noch die Ziele des Projektes. Weder von intern noch von extern. Seit wann werden öffentliche Ausschreibungen in Einzelpaketen für ein SW-Projekt vergeben? Den Vertrag will ich sehen. >> Wenn du privat was basteln willst: setzt du dich dann hin und schreibst >> erstmal ein detalliertes Lastenheft > Entschuldigung das ist doppelter Blödsinn! Wenn du ALLEINE etwas baust, > bist du keine Team und brauchst auch keine Organisation. Es ging darum, dass Du nicht erst einen Plan aufstellst und bis zur letzten Schraube des Gehäuses (inkl. Kühlkonzept o.ä.) in der Theorie Dein „Was-auch-immer-für-Elektronikschaltung“ entwirfst… Vermutlich baust Du los, mit einer groben Idee, ohne alle Details zu kennen. Und vermutlich stößt Du auf ungeplante Schwierigkeiten, die Dich dann ins Forum hier führen („Team“). Also lass das Krümelkacken und mach‘ bessere Vorschläge. > Es hat auch mit Lastenheften nichts zu tun, weil > die nicht rechtsverbindlich sein müssen. Lastenhefte müssen nicht rechtsverbindlich sein, aber ihr Inhalt wird vertragsrechtlich relevant - insbesondere wenn das Projekt bescheiden läuft. > Es gibt Dinge, die man besser intern mit festen Mitarbeitern macht und > das tägliche Neuausrichten (egal ob SCRUM oder nicht) geht eben nicht > mit Externen. Am Besten werden „Dinge“ an Leute vergeben, die es können. Und das kann durchaus extern und SCRUM bedeuten. > Du kommst sonst aus dem Ändern und Zicktacklaufen nicht mehr heraus. SCRUM heißt weder unverbindlich, beliebig oder gewürfelt. Agil heißt einfach, mit hoher Geschwindigkeit die Richtung ändern zu können. Und klassische Planprojekte können das eben nicht.
Beitrag #7481963 wurde von einem Moderator gelöscht.
Beitrag #7482162 wurde von einem Moderator gelöscht.
Beitrag #7482281 wurde von einem Moderator gelöscht.
Uwe D. schrieb: > Und > klassische Planprojekte können das eben nicht. Die haben sich auch weiterentwickelt aber die SCRUM-Honks haben das noch nicht mitbekomemn, weil sie ausser SCRUM noch nie was anderes gesehen haben und mit ihrem veralteten Halbwissen sich bei jeder Gelegenheit blamieren.
Herbert B. schrieb: > Uwe D. schrieb: >> Und >> klassische Planprojekte können das eben nicht. > Die haben sich auch weiterentwickelt aber die SCRUM-Honks haben das noch > nicht mitbekomemn, weil sie ausser SCRUM noch nie was anderes gesehen > haben und mit ihrem veralteten Halbwissen sich bei jeder Gelegenheit > blamieren. Werde doch mal konkret Herbert und honke mich nicht voll. Was hat sich denn geändert und verändert? Also ich kann in den Schulungsunterlagen meiner jungen Kollegen keinen Unterschied bei PMI oder Prince2 ggü. den Vorjahren sehen. Erhelle mich!
Herbert B. schrieb: > Die haben sich auch weiterentwickelt aber die SCRUM-Honks haben das noch > nicht mitbekommen :D Natürlich, jeder favorisiert seine Arbeitstechnik als die Beste. SCRUM hat sich ausgebreitet, passt aber bei Weitem nicht überall, wo es angewendet wird. Dort wo es funktioniert, gab es meistens zuvor schon einen guten Prozesse und dort wo es gewaltige Verbesserungen gab, war einfach nichts Gescheites, bzw das was es gab, wurde auch nicht korrekt verfolgt. Das ist ja der Hauptgrund, warum Prozesse nicht funktionieren. Es sperren sich welche dagegen oder können es einfach nicht. Leider löst sich dieses Grundproblem durch SCRUM nicht. Manche kriegen einfach ihre Gedanken nicht vernünftig aufs Papier. Es fehlen die Inhalte und Festlegungen. Da hilft der Wechsel zu einem anderen System rein gar nichts. Uwe D. schrieb: > Also ich kann in den Schulungsunterlagen meiner jungen Kollegen keinen > Unterschied bei PMI oder Prince2 Naja, dass etwas bei euch nicht angepasst wurde, sagt nichts über andere Firmen, oder? ;-)
J. S. schrieb: > Natürlich, jeder favorisiert seine Arbeitstechnik als die Beste. SCRUM > hat sich ausgebreitet, passt aber bei Weitem nicht überall, wo es > angewendet wird. Hat irgendwer behauptet, dass SCRUM der einzige Weg zum Projekterfolg ist? > Dort wo es funktioniert, gab es meistens zuvor schon > einen guten Prozesse und dort wo es gewaltige Verbesserungen gab, war > einfach nichts Gescheites, bzw das was es gab, wurde auch nicht korrekt Was erzählst Du von Prozessen? Was hat das mit Software-Projekten zu tun? > sich dieses Grundproblem durch SCRUM nicht. Manche kriegen einfach ihre > Gedanken nicht vernünftig aufs Papier. Es fehlen die Inhalte und > Festlegungen. Da hilft der Wechsel zu einem anderen System rein gar > nichts. Meinst Du Anforderungen an das Projekt - oder an das Produkt - oder an Prozesse? Vielleicht mal klarstellen - Danke. So viel zum Thema „Gedanken nicht vernünftig aufs Papier kriegen“ > > Uwe D. schrieb: >> Also ich kann in den Schulungsunterlagen meiner jungen Kollegen keinen >> Unterschied bei PMI oder Prince2 > Naja, dass etwas bei euch nicht angepasst wurde, sagt nichts über andere > Firmen, oder? ;-) Schön das Du Dich als unwissend outest. Nicht schlimm. Der überwiegende Teil (>90%) der Prüfungen für die Projektmanagement Methoden PMI oder Prince2 wird von akkreditierten Firmen erledigt, inklusive der Schulungen, Qualifizierungen und Schulungsunterlagen. Die sind international weitgehend einheitlich.
Uwe D. schrieb: > J. S. schrieb: >> Natürlich, jeder favorisiert seine Arbeitstechnik als die Beste. SCRUM >> hat sich ausgebreitet, passt aber bei Weitem nicht überall, wo es >> angewendet wird. > Hat irgendwer behauptet, dass SCRUM der einzige Weg zum Projekterfolg > ist? Hat niemand behauptet, auch ich nicht. Hast du das in meine Aussage hineingelesen? Die Aussage war, dass SCRUM leider von vielen kritiklos als Allheilmittel angesehen wird, sich aber in vielen Firmen als Bachblüte entpuppt. > Was erzählst Du von Prozessen? Was hat das mit Software-Projekten zu > tun? ??? Du solltest schon wissen, dass Entwicklungen - gerade in regulierten Bereichen und bei umfangreichen Projekten mit strukturieren Abläufen, Entscheidungssequenzen, Dokumenten- und Unterschriftsketten getrieben werden, was allgemein als "Prozess" deklariert wird.
Bruno V. schrieb: > A. B. schrieb: >> und was hat das mit SCRUM zu tun? Genau. Nix! > > Es geht ja nicht um scrum. Sondern um dessen Auswirkung auf > Selbstständige bzw. sog. Selbstständige. Richtig eingeworfen! Danke. Um es zu erklären, tun Firmen bei der Besetzung von Projektstellen nämlich das, was eingangs herausgestellt und kritisiert wird. Dabei machen sie keinen Unterschied, sondern behandeln die Selbstständigen wie Angestellte. Uwe D. schrieb: > Wie kommst Du darauf? Der Freiberufler unterliegt ja keinem > Weisungsrecht des AG. Und im SCRUM Team gibt es auch keine Weisung. Das ist die Theorie. Die Realität ist, dass Selbständigen sehr wohl oft Weisungen erteilt werden und dies genau von dem Projekt- oder Teamleiter, der das auch im SCRUM tut. Bei genauer Betrachtung ist aber Scrum ein Arbeitsmittel das ausschließlich für Teams geeignet und gedacht ist und bei dem externe Dienstleister selbverständlich nicht mitwirken. Um also die Frage: >Re: SCRUM und die Arbeitsweise von Selbständigen abschließend zu beantworten: Es gibt bei SCRUM keinerlei selbständige Arbeit, weil Selbständige niemals Teil eines Teams sein können und die Arbeit eben nicht selbständig erledigt werden kann. Scrum kann also schon aus logischer Sicht nur dann angewendet werden, wenn eine Aufgabe von einer Gruppe bearbeitet werden muss, wobei nicht alles, was eine Gruppentätigkeit erfordert mit Scrum abgewickelt werden muss. Nur Tätigkeiten, die eine Person alleine, ohne die Gruppe abarbeiten kann, darf an Selbständige vergeben werden. Und ohne Gruppe entfällt jede Frage ob man Scrum, oder ein anderes Teamorganisationswerkzeug anzuwenden hat.
Martin K. schrieb: > Nur Tätigkeiten, die eine Person alleine, ohne die Gruppe abarbeiten > kann, darf an Selbständige vergeben werden. Das sehe ich anders. Ich habe zeitweise Freelancer im Team, und zwar mit Erfolg.
J. S. schrieb: > Uwe D. schrieb: > Die Aussage war, dass SCRUM leider von vielen kritiklos > als Allheilmittel angesehen wird, sich aber in vielen Firmen als > Bachblüte entpuppt. Bleib doch mal hier im Kontext. Wer ist „…viele Firmen..“? Wie ist denn Deine persönliche Erfahrung? >> Was erzählst Du von Prozessen? Was hat das mit Software-Projekten zu >> tun? > ??? Du solltest schon wissen, dass Entwicklungen - gerade in regulierten > Bereichen und bei umfangreichen Projekten mit strukturieren Abläufen, > Entscheidungssequenzen, Dokumenten- und Unterschriftsketten getrieben > werden, was allgemein als "Prozess" deklariert wird. Ja und? Wenn wir über SIL-4 Software sprechen oder SIL-0 Software mit Pflicht zur Anwendung von DIN EN 50126/7/8 - oder was auch immer: Du sprichst gerade davon, dass SCRUM nicht das Allheilmittel ist. Lies mal das agile Manifest. Martin K. schrieb: > Bruno V. schrieb: >> A. B. schrieb: >>> und was hat das mit SCRUM zu tun? Genau. Nix! >> >> Es geht ja nicht um scrum. Sondern um dessen Auswirkung auf >> Selbstständige bzw. sog. Selbstständige. > > Richtig eingeworfen! Danke. Um es zu erklären, tun Firmen bei der > Besetzung von Projektstellen nämlich das, was eingangs herausgestellt > und kritisiert wird. Dabei machen sie keinen Unterschied, sondern > behandeln die Selbstständigen wie Angestellte. Du verallgemeinerst. Das macht genau die Mehrzahl der erfolgreichen Firmen nicht. Wenn ich Freiberufler brauche, dann akzeptiere ich die besonderen Bedingungen. > Uwe D. schrieb: >> Wie kommst Du darauf? Der Freiberufler unterliegt ja keinem >> Weisungsrecht des AG. Und im SCRUM Team gibt es auch keine Weisung. > Das ist die Theorie. Die Realität ist, dass Selbständigen sehr wohl oft > Weisungen erteilt werden und dies genau von dem Projekt- oder > Teamleiter, der das auch im SCRUM tut. Nö. Ich weise externe Berater nicht an. Zudem sind die User Stories/Tasks/Subtasks so geschnitten, dass diese ohne Abhängigkeiten innerhalb eines Tages - manchmal auch innerhalb kurzer Sprints - geschafft werden können. Das Management, auch nicht der Lenkungsausschuss, hat Mitspracherechte. > Bei genauer Betrachtung ist aber Scrum ein Arbeitsmittel das > ausschließlich für Teams geeignet und gedacht ist und bei dem externe > Dienstleister selbverständlich nicht mitwirken. Hast Du das Wesen von SCRUM verstanden? Für eine One-Man-Show ist SCRUM nicht gemacht. > Um also die Frage: >>Re: SCRUM und die Arbeitsweise von Selbständigen > abschließend zu beantworten: > Es gibt bei SCRUM keinerlei selbständige Arbeit, weil Selbständige > niemals Teil eines Teams sein können und die Arbeit eben nicht > selbständig erledigt werden kann. Falsch. > > Nur Tätigkeiten, die eine Person alleine, ohne die Gruppe abarbeiten > kann, darf an Selbständige vergeben werden. Und ohne Gruppe entfällt > jede Frage ob man Scrum, oder ein anderes Teamorganisationswerkzeug > anzuwenden hat. Falsch. https://www.gulp.de/freelancing/wissen/scheinselbststaendigkeit/urteil-scrum-projekte-kein-indiz-scheinselbststaendigkeit Es ist die gestrige Denkweise von Fachfremden und Beamten. Das sich etwas ändert oder bei unseren Nachbarn anders funktioniert, kann man z.B. hier lesen https://germany.representation.ec.europa.eu/news/kartellrecht-leitlinien-zu-tarifvertragen-fur-selbststandige-verabschiedet-2022-09-29_de oder einfach die Suchmaschine seines Misstrauens fragen.
Stefan F. schrieb: > Das sehe ich anders. Ich habe zeitweise Freelancer im Team, und zwar mit > Erfolg. Der steht damit schon mit einem Bein in der Scheinselbstständigkeit.
Herbert B. schrieb: > Stefan F. schrieb: >> Das sehe ich anders. Ich habe zeitweise Freelancer im Team, und zwar mit >> Erfolg. Dass der erfolgreich arbeitet, bedeutet nicht, dass es rechtlich korrekt ist. > Der steht damit schon mit einem Bein in der Scheinselbstständigkeit. So sieht es aus. Oft genug ist es wahrscheinlich einfach nur nicht nachweisbar, weil kein Ankläger.
Herbert B. schrieb: > Die haben sich auch weiterentwickelt aber die SCRUM-Honks haben das noch > nicht mitbekomemn, Bei SCRUM geht es sehr wesentlich um Kommunikation. Wenn ich lese, wie Du hier kommunizierst, wundert es mich nicht, warum das nichts für Dich ist.
Uwe D. schrieb: > Nö. Ich weise externe Berater nicht an. Zudem sind die User > Stories/Tasks/Subtasks so geschnitten, dass diese ohne Abhängigkeiten > innerhalb eines Tages geschafft werden können. Also tageweise Steuerung! Genau das was im Team passiert und als Weisung gesehen wird. Deine "Selbständigen" erstatten wahrscheinlich auch täglich Rapport. Uwe D. schrieb: > Hast Du das Wesen von SCRUM verstanden? Nein, du hast nicht richtig gelesen. >Für eine One-Man-Show ist SCRUM nicht gemacht. Das war meine Aussage und daher haben Selbständige mit SCRUM nichts zu tun und sollten auch nicht in so ein Team berufen werden. Alles das was du hier so schreibst, zeigt mir das du sehr wenig Interesse und Wissen für das Thema hast. Solange du oder deine Firma denkt, dass alles fein ist, ist dann für dich alles gut. Na prima. Liese mal das:
Manni T. schrieb: >> Der steht damit schon mit einem Bein in der Scheinselbstständigkeit. > So sieht es aus. Oft genug ist es wahrscheinlich einfach nur nicht > nachweisbar, weil kein Ankläger. Es gibt aber immer wieder Fälle, in denen Betriebsprüfer beim Kunden eine Einschätzung zu den Verträgen und Tätigkeiten angeblich Selbständiger vornehmen und daraufhin Bescheide ergehen. Das geht recht flink wie die gängige Praxis zeigt und dann hat der Selbständige erst einmal den Rechtsfall an der Backe kleben. Oft bleibt er dann auf dem Problem sitzen, wenn er als rentenversicherungspflichtiger Selbständiger eingestuft wird. Darauf wurde vor einiger Zeit vom Verband der Selbständigen hingewiesen. In anderen Ländern ist das z.b. völlig anders: Den Selbständigen, wie er in DE bekannt ist, gibt es in z.B. Frankreich so nicht. Auch in der Schweiz ist das anders gehandhabt. Da lohnt ein Blick über die Grenze.
Wieso denkt ihr, dass ein Freelancer nicht selbstständig ist, wenn er in einem agilen Team bei einem seiner Kunden arbeitet? Das schließt doch nicht aus, für mehrere Kunden tätig zu sein.
Martin K. schrieb: > Also tageweise Steuerung! Genau das was im Team passiert und als Weisung > gesehen wird. Deine "Selbständigen" erstatten wahrscheinlich auch > täglich Rapport. "Steuerung", "Weisungen", "Rapporte"... Pardon, aber so ein Arbeitsumfeld möchte ich nicht haben, weder als Angestellter, noch als Vorgesetzter, und schon gar nicht als Selbständiger. In allen diesen Rollen habe ich sowohl agile als auch nicht-agile Projekte erlebt, und im Rückblick haben meine agilen Projekte in der Regel schnellere und bessere Ergebnisse erzielt, obwohl das Arbeiten meistens entspannter und kollegialer war. Vor allem den direkten Kontakt mit Kunden, Fachlichkeit und Kollegen habe ich dabei ganz besonders zu schätzen gelernt. Dann bekommen die Kunden und ihre Fachleute nämlich mit, wie aufwändig Software entwickelt, betrieben und gepflegt wird, und umgekehrt verstehen die Entwickler und Betreiber besser, was der Kunde will und braucht. Und gerade was "Steuerung", "Weisungen" und "Rapporte" angeht, hatte ich besonders in meinen agilen Projekten als Selbständiger beinahe immer die große Freude, das solche Dinge gar nicht nötig waren. Denn die Mitarbeiter des Kunden sind schon durch die enge Zusammenarbeit immer im Bilde gewesen, was ich tat, weswegen "Rapporte" überflüssig waren -- während ich durch dieselbe enge Zusammenarbeit selbst wußte, was zu tun war, und deswegen auch die "Steuerung" und "Weisungen" fast immer unnötig waren. Naja, das sind nur meine Erfahrungen, und eine Stichprobengröße von 1 hat natürlich keine Aussagekraft. Zudem hatte ich die große Freude, meistens mit kommunikativen und freundlichen Menschen arbeiten zu dürfen. Yay! :-)
Stefan F. schrieb: > Das schließt doch nicht aus, für mehrere Kunden tätig zu sein. Es gibt auch Angestellte mit mehreren Arbeitgebern. Entscheidend ist, ob Du Deine Arbeitskraft verkaufst oder Dein Produkt. Wenn Scrum z.B. jeden Montag die Zeiten synchronisiert (Feature X ist bis Mittwoch implementiert, dann kann der Auftraggeber testen), mag es ein Freelancer sein. Wenn tägliche Sprints seine Aufgabe beeinflusst, ist es eher ein Angestellter.
Martin K. schrieb: > Uwe D. schrieb: >> User Stories/Tasks/Subtasks so geschnitten, dass diese ohne Abhängigkeiten >> innerhalb eines Tages geschafft werden können. > Also tageweise Steuerung! Genau das was im Team passiert und als Weisung > gesehen wird. Deine "Selbständigen" erstatten wahrscheinlich auch > täglich Rapport. Danke, dass Du klarstellst - Du hast weder das Framework verstanden noch Erfahrung. > Uwe D. schrieb: >> Hast Du das Wesen von SCRUM verstanden? > Nein, du hast nicht richtig gelesen. Du hast vollkommen recht, es macht keinen Sinn darüber zu sprechen. >>Für eine One-Man-Show ist SCRUM nicht gemacht. > Alles das was du hier so schreibst, zeigt mir das du sehr wenig > Interesse und Wissen für das Thema hast. Es beweist nur, dass Du halt nur das System Igel-Hase kennst und verstehst. Nicht schlimm.
:
Bearbeitet durch User
Bruno V. schrieb: > Stefan F. schrieb: >> Das schließt doch nicht aus, für mehrere Kunden tätig zu sein. > Wenn Scrum z.B. jeden Montag die Zeiten synchronisiert (Feature X ist > bis Mittwoch implementiert, dann kann der Auftraggeber testen), mag es > ein Freelancer sein. Der Kunde legt fest, was ihm wichtig ist (in der Regel auch zugleich der Product Owner). Deshalb gibt es im SCRUM keinen Releaseplan. Und wer das dennoch macht, nähert sich wieder dem nicht-agilen Vorgehen an. Kann man machen… > Wenn tägliche Sprints seine Aufgabe beeinflusst, ist es eher ein > Angestellter. Es gibt keine täglichen Sprints.
Martin K. schrieb: > Manni T. schrieb: >>> Der steht damit schon mit einem Bein in der Scheinselbstständigkeit. >> So sieht es aus. Oft genug ist es wahrscheinlich einfach nur nicht >> nachweisbar, weil kein Ankläger. > In anderen Ländern ist das z.b. völlig anders: Den Selbständigen, wie er > in DE bekannt ist, gibt es in z.B. Frankreich so nicht. Auch in der > Schweiz ist das anders gehandhabt. Da lohnt ein Blick über die Grenze. Aha. Dann erhelle mich Mal. Was macht Dich da so sicher? Gerne bekommst Du von mir Kontakte von erfolgreichen Selbständigen IT-Spezialisten: von Skandinavien bis Israel - in jedem Land Europas. Apropos Frankreich: https://www.relocation-toulouse.com/freelancer-in-frankreich/
Uwe D. schrieb: > Gerne bekommst Du von mir Kontakte von erfolgreichen Selbständigen > IT-Spezialisten: von Skandinavien bis Israel - in jedem Land Europas. Her damit, ich kann immer gute Leute gebrauchen! > Apropos Frankreich: Was willst du uns damit sagen? Im ersten Satz auf dieser Seite steht: ************************************************************ In Frankreich muss jeder, der selbständig arbeiten möchte, ein Gewerbe anmelden. Dies gilt auch für Berufe, die in Deutschland als Freiberufler nicht unter die Gewerbetreibenden fallen würden, wie z. B. Anwälte, Coachs, Grafiker oder Sprachlehrer. Ein deutscher Freiberufler meldet sich beim Finanzamt an, versteuert alljährlich seine Einkünfte und ist selber für Krankenversicherung und Altersvorsorge verantwortlich. Meldet man dagegen in Frankreich ein Gewerbe als Profession libérale an, wird man automatisch Mitglied im französischen Sozialversicherungssystem und zahlt Sozialabgaben ab dem 1. Euro Umsatz. *************************************************************
Manni T. schrieb: > Uwe D. schrieb: >> Apropos Frankreich: > Was willst du uns damit sagen? Im ersten Satz auf dieser Seite steht: > ************************************************************ > In Frankreich muss jeder, der selbständig arbeiten möchte, ein Gewerbe > anmelden. Dies gilt auch für Berufe, die in Deutschland als Freiberufler Wo ist denn Dein Problem? Freelancer <> „Freier Beruf“ Schon im Eröffnungspost steht in der Überschrift „Selbständigen“. Dementsprechend könnte unter Bedingungen ein Freiberufler in Frage kommen, meist aber ein One-Man-Gewerbe. Du hast doch behauptet: > In anderen Ländern ist das z.b. völlig anders: Den Selbständigen, wie er > in DE bekannt ist, gibt es in z.B. Frankreich so nicht. Auch in der > Schweiz ist das anders gehandhabt. Da lohnt ein Blick über die Grenze. Was ist denn völlig anders?
Uwe D. schrieb: > Was ist denn völlig anders? Du solltest einfach den Text lesen: Den Selbständigen (wie hier in Deutschland) gibt es so (als Freiberufler) in Frankreich nicht. Es gibt dort keine freien Berufe wie hier, sondern sie werden einem Gewerbe zugeordnet. Heißt: Selbständiger Einzelunternehmer ohne Verkauf oder Gewerbe bei ausreichender Qualifikation ... in DE -> FREIBERBUFLER ohne IHK, ohne Gewerbesteuer, ohne Bilanzierung in FR -> GEWERBE mit Instituionszwang, kleine Bilanzierung, (trotz gleicher Quali) Das Dumme in FR: Pauschalversteuerung und Pauschalabgaben. Du kannst nicht wie in DE das Auto abschreiben, oder das Büro. In der Schweiz wiederum gibt es Freiberufler, die werden aber auch meisten Sozialbesteuert und müssen Abgaben leisten, weil ihre Projekte nicht als Selbständige durchgewunken werden.
Manni T. schrieb: > Den Selbständigen (wie hier in Deutschland) gibt es so (als > Freiberufler) in Frankreich nicht. Also was meinst Du denn? Selbstständige oder Freiberufler? Dazwischen gibt es einen großen Unterschied! Es gibt z.B. gewerbetreibende Selbstständige, und angestellte Freiberufler.
Einfach lesen was ich schreibe! (?) Klappt das nicht? Den Selbständigen so wie hier in Deutschland gibt es als Freiberufler in Frankreich nicht. Es gibt dort keine freien Berufe wie hier. Was ist an den Satz nicht zu versehen?
Manni T. schrieb: > Einfach lesen was ich schreibe! Ruhe bewahren... > Den Selbständigen so wie hier in Deutschland gibt es als > Freiberufler in Frankreich nicht. Ich glaube, hier liegt ein Kommunikationsproblem vor, weil Du "Selbständiger" mit "Freiberufler" gleichsetzt, und wenn ich mit meinem eingerosteten (und nie besonders guten) Schulfranzösisch die französischsprachige Wikipediaseite [1] aufrufe, kommt mir das, was ich auch mit Hilfe von Google Translate lese, jedenfalls nicht vollkommen fremd, sondern nur ein bisschen anders vor. Insbesondere bei den dort namentlich genannten Berufen wie RechtsanwältInnen, ApothekerInnen und ähnlichen, die dort als "Professions réglementées" geführt werden, gibt es auch hier bei uns berufsspezifische Regularien. Bei anderen wie WebdesignerInnen, ÜbersetzerInnen oder InnenarchitektInnen hingegen haben Frankreich und Deutschland solche Regularien anscheinend nicht. Bitte mach' Dich einmal von der Gleichsetzung "Selbständiger == Freiberufler" frei, die es in Deutschland nicht gibt, und erkläre uns bitte noch einmal, worin Deiner Ansicht nach der große Unterschied besteht. Danke. [1] https://fr.wikipedia.org/wiki/Profession_lib%C3%A9rale
Sheeva P. schrieb: > Ich glaube, hier liegt ein Kommunikationsproblem vor, weil Du > "Selbständiger" mit "Freiberufler" gleichsetzt, Nein genau das tut ich nicht. Im Gegenteil ich habe schon zweimal deutlich den Unterschied aufgezeigt - einfach mal Texte lesen. :-)
Manni T. schrieb: > Nein genau das tut ich nicht. Im Gegenteil ich habe schon zweimal > deutlich den Unterschied aufgezeigt - einfach mal Texte lesen. :-) Du meinst das hier? Manni T. schrieb: > Den Selbständigen so wie hier in Deutschland gibt es als > Freiberufler in Frankreich nicht. Doch, da vergleichst Du Selbstständige (im Sinne einer eigen-unternehmerischen, nicht-abhängigen Tätigkeit) in Deutschland mit Freiberuflern (im Sinne der freien Berufe) in Frankreich, was einfach sinnlos ist, da komplett unterschiedliche Aspekte Es wäre höchstens sinnvoll, die Stellung der Selbstständigen in Deutschland mit derjenigen der Selbstständigen in Frankreich vergleichen, ODER die Stellung der Freiberufler in Deutschland mit derjenigen der Freiberufler in Frankreich. Der Vergleich, auf den Du aber vermutlich hinauswillst, ist der Vergleich von "Selbstständigen Freiberuflern" in Deutschland mit den "Selbstständigen Freiberuflern" in Frankreich.
Achim H. schrieb: > Selbstständigen Freiberuflern Es gibt keine nicht selbständigen Freiberufler. Und für Profis heißt es selbständig.
Ein deutliches Beispiel für Freiberufler sind Rechtsanwälte. In Deutschland gibt es die "Bundesrechtsanwaltsordnung (BRAO)". Im Paragraph 46 geht es um: "Angestellte Rechtsanwälte und Syndikusrechtsanwälte". Damit gibt es also angestellte = nicht-selbstständige (https://www.duden.de/suchen/dudenonline/selbst%C3%A4ndig) Rechtanwälte. Ebenso finden sich angestellte Apotheker. Allein aus der Natur der Tätigkeit kann also nicht geschlossen werden, ob jemand selbstständig oder aber angestellt ist. Und das Thema dieses Threads sind ja gerade schein-selbstständige Verhältnisse bei (meist) freiberuflicher Tätigkeit.
Reinhard S. schrieb: > Klingt, als ob ihr Aufträge bekommt, bei denen der Kunde gar nicht weiß, > was er eigentlich braucht und ob er es braucht? Geschätzt hatten etwa 90% der Kunden, mit denen ich in den letzten zwanzig Jahren gearbeitet habe, nur keinerlei Vorstellung davon, was möglich oder unmöglich war, und nur eine sehr rudimentäre davon, was sie wollten. Wenn sie das nämlich alles gewußt hätten, dann hätten sie das alles auch selbst machen können und unsere Expertise nicht gebraucht. Deren Problem ist kein Mangel an Manpower, sondern eines an Fachwissen und Erfahrung.
Achim H. schrieb: > In Deutschland gibt es die "Bundesrechtsanwaltsordnung (BRAO)". Im > Paragraph 46 geht es um: "Angestellte Rechtsanwälte und > Syndikusrechtsanwälte". Da hast du einen Logikfehler. Nur weil es Angestellte Anwälte gibt und weil Anwaltstätigkeit zu den Katalogberufen zählt, heißt das nicht, dass der angestellte Anwalt ein Freiberufler ist. Was ein Freiberufler ist, regelt §18 EStG.
Uwe D. schrieb: > Und ja, wenn die „SCRUM-Hasser“ so viel besser wären wie sie behaupten > zu sein, dann gäbe es nur glückliche Kunden und massenhaft Produkte die > alle möglichen Anwendungsfälle abdecken. Wenn diese Menschen auch nur ein Zehntel dessen könnten, was sie gerne so vollmundig behaupten. Denn Scrum und andere agile Methoden wurden ja nur entwickelt, weil (je nach Untersuchung) zwei Drittel bis drei Viertel der Softwareprojekte ihre Zeit- und oder Budgetgrenzen gesprengt haben.
Reinhard S. schrieb: > Das hat aber nichts mit obenstehendem Problem zu tun. Wenn man Dinge > baut, die dann aber wegen Agilität/schlechter Planung wieder > abreißen/umbauen muss (natürlich inkl. seperater Anfahrt/Abfahrt) ist > das nur bedingt erfüllend, selbst wenns bezahlt wird. Man hätte so viel > sinnvolleres in der Zeit tun können... Oh, solche Kollegen kenne ich leider allzu gut. Wenn sie feststellen, daß irgendein Teil ihrer Software unglücklich implementiert ist, arbeiten sie lieber um ihren Designfehler herum, anstatt zu refaktorieren, und im Lauf der Zeit pflanzt sich das Problem dann langsam in alle Bereiche fort, die mit dieser Komponente zu tun haben... bis die Probleme dann so verbreitet sind, daß sie nicht mehr mit vertretbarem Aufwand zu korrigieren sind. Ehrlicherweise muß man aber sagen, daß es solche Kollegen überall gibt, in agilen wie in nicht-agilen Projekten. In agilen fallen sie allerdings oft schnell genug auf, um noch gegensteuern zu können.
J. S. schrieb: > Natürlich, jeder favorisiert seine Arbeitstechnik als die Beste. SCRUM > hat sich ausgebreitet, passt aber bei Weitem nicht überall, wo es > angewendet wird. Vielleicht sollten wir an dieser Stelle auch nicht vergessen, daß agile Methoden häufig nur halbherzig umgesetzt werden, oft weil die alten Hasen dieselben Vorurteile haben, wie sie hier im Thread geäußert werden. Sowas endet dann gerne in einem Mischmasch aus Agil und Wasserfall, und am Ende wird die Schuld am Scheitern nie bei der Umsetzung, sondern natürlich bei diesem blöden neumodischen Schietkrom gesehen.
Achim H. schrieb: > Doch, da vergleichst Du Selbstständige (im Sinne einer > eigen-unternehmerischen, nicht-abhängigen Tätigkeit) in Deutschland mit > Freiberuflern (im Sinne der freien Berufe) in Frankreich, was einfach > sinnlos ist, da komplett unterschiedliche Aspekte EBEN DAS WAR DIE AUSSAGE! ES IST ETWAS ANDERES. LIES EINFACH MAL WAS ICH WO GESCHRIEBEN HABE!
M. T. schrieb: > Dies gilt auch für Berufe, die in Deutschland als Freiberufler > nicht unter die Gewerbetreibenden fallen würden, wie z. B. Anwälte, > Coachs, Grafiker oder Sprachlehrer. In der Liste auf besagter Seite sind bei den Selbständigen, die "in Deutschland als Freiberufler gelten" und in Frankreich ein Gewerbe anmelden müssen, sind aber keine Ingenieure oder Informatiker eingetragen und um die geht es ja hier. Weiß jemand, was mit denen ist?
Ein T. schrieb: > daß agile Methoden häufig nur halbherzig umgesetzt werden, oft weil > die alten Hasen dieselben Vorurteile haben, Dieses Scheinargument hört man an jeder Ecke, dass irgendjemand den Scrum-Prozess blockiert und das es angeblich die Erfahrenen sind. In dieser Behauptung stecken 2 Fehler: 1) Nach meiner Erfahrung war es bisher ausnahmslos so, dass der Scrum-Prozess von den Initatoren selbst nicht richtig verstanden und umgesetzt wurde, was denn eben bei "den alten Hasen" (oder sagen wir lieber bei den denkbefähigten Hasen" und damit durchaus auch den Jungen) zu Irritationen geführt hat. 2) Man setzt Erfahrung / Alter mit Starrsinn gleich. Die Realität ist aber die, dass gerade die Älteren schon seit gefühlt 2 Dekaden mit dem Thema Scum und darüber hinaus anderen Systemem zu tun haben, diese kennen und mehrere Formen der Umsetzung und Interpretation mitansehen durften und die Prozesse sehr oft besser verstanden haben, als die welche sie erst vor Kurzem vorgesetzt bekommen haben. > Vielleicht sollten wir an dieser Stelle auch nicht vergessen, Vor allem sollte man nicht vergessen, dass die "alten" Hasen oft sogar älter und erfahrener sind, also so mancher Jung-Scrum-Hase, der durch ein paar Schulungen zum Scrum-Master wurde, selber erst einige Jahre mit dem Thema zu tun hatte und erst noch dabei ist, den Prozess zu etablieren und so die Alten sehr genau sehen, wo die Defizite beim Scrum der Junghasen sind. Was man vor allem nicht vergessen darf, ist der Umstand, dass die Grundzüge von Scrum vor rund 30 Jahren entwickelt wurden, zu einer Zeit, als völlig andere Umstände in der Softwarelandschaft herrschten, die ja Strukturgeber dafür war. Vieles davon war und ist in der Zwischenzeit längst umgesetzt und/oder auch überholt. Ich habe seit etwa 2007 mit Scum zu tun und sehe, dass es praktisch in jeder Firma anders gehandhabt und interpretiert wird. Das Meiste was aus Scrum real umgesetzt ist, gab es vorher schon und ist vielfach nur alter Wein in neuen Schläuchen. Das gilt insbesondere für die deutsche Ingenieurslandschaft, die von je her erheblich aufgeräumter war, als z.B. die USA, wo sich Scrum am Stärksten verbreitet hat. Der für mich eklatanteste Knackpunkt ist die Übernahme der Vorgehensweisen aus der Software in völlig andere Bereiche, wo es einfach hinten und vorne nicht passt - schon deshalb, weil gewisse Dinge dort nicht von einer Gruppe von Personen erledigt werden (können) und es folglich egal ist, nach welcher Methode diese arbeiten würde. Bei der SW-Entwicklung geht es darum, eine qualitativ engbegrenzte Arbeit, die aber einen großen Umfang hat, geschickt zu strukturieren und zu verteilen. Die meisten Dinge außerhalb von SW, sind bereits früh im Projekt sehr dediziert strukturiert und qualitativ breit gefächert. Das wieder wie einen großen amorphen Kuchen zu behandeln, den es durch die Gruppe spontan zu strukturieren gilt, ist für Viele daher zu recht nicht nachvollziehbar. Der Scrum-Prozess ist da einfach nur ein downgrade. Weitere Dinge sind die Annahmen, die getroffen worden, um Scrum zu rechtfertigen, wie die angebliche Unmöglichkeit, einen festen Entwicklungsprozess vorauszusehen. Was für die Erstellung von Software gilt, weil man auf sich ändernde Hardware, andere Funktionen und Methoden sowie Betriebssystemupdates Rücksicht nehmen muss und zugleich durch die Weichheit der SW auch kann - gilt für Mechanik und Elektronik in keinster Weise: Bei Herstellung eines ASICs z.B. gelten ganz spezifische Vorgaben und Reihenfolgen, die man nicht änder kann und den Rahmen klar vorgeben. Auch für die Entwicklungsschritte gibt es indirekte Vorgaben durch die tools. Diese sind heute viel mächtiger und dediziert, führen oft genug durch das design und legen Schritte sehr genau fest. Für Software ist das grundsätzlich anders, da man Strukturen beliebig vorgeben und wieder zerlegen kann, weil es jeweils ein und dasselbe Material ist. Auch die Bearbeiter machen alle dasselbe und sind austauschbar. Damit kann eine Entwicklung durch dynamisches Umdenken und Umsteuern mit Neuverteilung der Aufgaben während des Prozesses durchaus profitieren. Außerhalb der SW mit heterogenen Entwicklern geht da nicht viel. Kaum einer kann dem anderen bei Problemen helfen, ihm Arbeit abnehmen oder Entscheidungen treffen, weil er in einer ganz anderen Ecke steckt. Damit macht es auch keinen Sinn, dass ein Team zusammenkommt, das das grundsätzlich dürfte. Es geht nicht. In solchen Fällen stehen alle zusammen, jeder berichtet aus seiner Ecke und alle hören artig zu. Wenn es dann zu spontanen Entscheidungen kommt, stammen die praktisch immer vom PO und nicht aus der Gruppe. Ein Team (Srum oder nicht) macht nur Sinn, wenn da wirklich mehrere mit ähnlichem Knowhow sich eine Aufgabe teilen, z.B. 5 FPGA-Entwickler an einem Design sitzen und dann schlagen auch wieder andere Effekte auf, die mit Scrum nicht zu lösen sind. Gleichwohl würde es hier noch passen, weil es praktisch zu einem großen Teil Softwareentwicklung ist. Nun gibt es aber bei der SW-Entwicklung auch neuere Entwicklungen: Durch die ständig wachsende Regulierung in sicherheitskritischen Bereichen, sind auch da die Prozessschritte und Rollen inzwischen klar definiert, bis hinunter zu Dokumentenstrukturen und Vorgaben, wie diese anzulegen sind. Hier sind es dann die Scrum-Teams, die nach meiner Erfahrung große Probleme haben, sich da hineinzufinden. Das hat damit zu tun, dass es nicht gut umgesetzt wurde und soweit es umgesetzt ist, löst es die Kernprobleme der Aufgabenstellung nicht. Scum ist in erster Linie geeignet, um ein Bündel konkreter Aufgaben auf eine Gruppe zu verteilen, so als sei es eine einzige leistungsfähige Person und dafür ein Planungssystem zu liefern und Strukturen zu schaffen. Durch die modernen Tools wie Code-Managementsysteme, Planungshilfen, Datenbank-gestützte Informations- und Projektverwaltung sind diese Strukturen aber auch inzwischen da und müssen nicht ad hoc organisiert werden. Zudem sind viele strukturelle Themen in der Softwareentwicklung gelöst und Umsetzungen durch Bibliotheken und eben CodeGeneratoren sehr linear geworden, sodass es keines intensiven "wie-Managements" bei der SW-Entwicklung im Team mehr Bedarf. Da noch einen Scrum-Prozess drüberzuziehen ist oftmals auch mehr störend und kommt nicht selten einer Behinderung gleich. Ich darf an der Stelle bemerken, dass ich mehrere Firmen kenne, die Scrum schon wieder abgeschafft haben, weil Aufgabenstruktur und Teamorganisation da überhaupt dazu passen.
Sheeva P. schrieb: > Vor allem den direkten Kontakt mit Kunden, Fachlichkeit und Kollegen > habe ich dabei ganz besonders zu schätzen gelernt. Dann bekommen die > Kunden und ihre Fachleute nämlich mit, wie aufwändig Software > entwickelt, betrieben und gepflegt wird, und umgekehrt verstehen die > Entwickler und Betreiber besser, was der Kunde will und braucht. Klingt prima und sinn - nur was ist die Aussage dahinter? Wieso sollte das (nur) unter Nutzung eines Scrum-Prozesses funktionieren?? Mit dem Kunden = Abnehmer eines Produktes zu sprechen, ihm die Komplexität der Aufgabe und damit die notwendigen Schritte und Bedarfe klarzumachen, war und ist schon immer Gegenstand eines Entwicklungsprozesses und wird gerade von Selbständigen genau so betrieben, weil sie gesamte Palette von Angebot, Projektorganisation und Umsetzung alleine abdecken. Die offene Frage ist nur, wer konkret jeweils der Kunde ist. In der Regel ist das der Projektleiter, im Einzelfall auch mal der Endkunde. In der Angestelltenthematik stellt sich das meistens so dar, dass der Endkunde auf den Produktmanager trifft, dazwischen dann die Abteilungsleitung, die Teamleitung und dann das Team stecken, dessen Kunde der Product Owner ist. Dies gewaltige Hierarchie ist aber eine Frage der Projekt Firmen Aufgabengröße und nicht Folge oder Begleitaspekt eines bestimmten Prozesses. Eine gut strukturierte Kommunikation braucht es auf jeder der genannten Ebenen. Daher müsste Scum auf jeder dieser Ebenen zwischen den Beteiligten stattfinden. Kann man machen - nur: Das gute Funktionieren einer solchen Kommunikation ausgerechnet Scrum zuzuschreiben oder neudeutsch "agil" zu nennen, so, als habe es das vorher nie gegeben und hätte erst erfunden werden müssen, oder sei erst damit aufgekommen, ist eine willkürliche Aneignung. Das sehe ich aber durchaus öfters: Was gut funktioniert, wird dem Scrum-Prozess gutschrieben. Praktisch sieht die Sache aber anders aus: Eine gute Kommunikation, die Fehler und Falschentscheidungen vermeidet und unnötiges Umentscheiden verhindert, erfordert eine gut durchdachte Planung im Vorhinein und eine genau Zieldefinition. Dank Scrum denken aber viele, sie könnten sich alles offenhalten, verlernen das Planen und manövrieren sich so agil in die Sackgasse.
J. S. schrieb: > Ein T. schrieb: >> daß agile Methoden häufig nur halbherzig umgesetzt werden, oft weil >> die alten Hasen dieselben Vorurteile haben, > > Dieses Scheinargument hört man an jeder Ecke, dass irgendjemand den > Scrum-Prozess blockiert und das es angeblich die Erfahrenen sind. In > dieser Behauptung stecken 2 Fehler: Bitte beachte die Feinheiten: ich habe extra das Wort "oft" benutzt. Nach meiner Erfahrung ist es also nicht immer so, aber recht häufig. > 1) Nach meiner Erfahrung war es bisher ausnahmslos so, dass der > Scrum-Prozess von den Initatoren selbst nicht richtig verstanden und > umgesetzt wurde, was denn eben bei "den alten Hasen" (oder sagen wir > lieber bei den denkbefähigten Hasen" und damit durchaus auch den Jungen) > zu Irritationen geführt hat. Auch das habe ich natürlich schon erlebt. > 2) Man setzt Erfahrung / Alter mit Starrsinn gleich. Die Realität ist > aber die, dass gerade die Älteren schon seit gefühlt 2 Dekaden mit dem > Thema Scum und darüber hinaus anderen Systemem zu tun haben, Das würde mir nie einfallen, ich bin ja selbst mittlerweile 52 Jahre alt und mache dieses Softwarezeugs seit über dreißig Jahren, würde mich also durchaus auch selbst zu den "alten Hasen" zählen. > Was man vor allem nicht vergessen darf, ist der Umstand, dass die > Grundzüge von Scrum vor rund 30 Jahren entwickelt wurden, zu einer Zeit, > als völlig andere Umstände in der Softwarelandschaft herrschten, die ja > Strukturgeber dafür war. Vieles davon war und ist in der Zwischenzeit > längst umgesetzt und/oder auch überholt. Die Gründe, aus denen agile Methoden entwickelt worden sind, haben sich meines Erachtens sogar verschärft. Softwareprojekte sind heute wesentlich komplexer und komplizierter als früher, was es noch schwieriger macht, in Lasten- und Pflichtenheften allen Nötige korrekt zu berücksichtigen. > Ich habe seit etwa 2007 mit Scum zu tun und sehe, dass es praktisch in > jeder Firma anders gehandhabt und interpretiert wird. Wie gesagt, meistens wird es eher halbherzig umgesetzt. > Weitere Dinge sind die Annahmen, die getroffen worden, um Scrum zu > rechtfertigen, wie die angebliche Unmöglichkeit, einen festen > Entwicklungsprozess vorauszusehen. Was für die Erstellung von Software > gilt, weil man auf sich ändernde Hardware, Naja, Du sprichst -- in einem Mikrocontroller-Forum sicherlich nicht ganz ungewöhnlich -- vom hardwarebezogenen Aspekt der Softwareentwicklung, ich dagegen sehe das allgemeiner. > Nun gibt es aber bei der SW-Entwicklung auch neuere Entwicklungen: Durch > die ständig wachsende Regulierung in sicherheitskritischen Bereichen, > sind auch da die Prozessschritte und Rollen inzwischen klar definiert, > bis hinunter zu Dokumentenstrukturen und Vorgaben, wie diese anzulegen > sind. Hier sind es dann die Scrum-Teams, die nach meiner Erfahrung große > Probleme haben, sich da hineinzufinden. Nunja, ich bin seit einigen Jahren in einem regulierten Umfeld tätig, wo von ISO27000 über die Vorgaben von BSI und BaFin auch Themen wie PCI-DSS, HIPAA und ähnliche Regularien eine Rolle spielen. Nichtsdestotrotz sind agile Methoden in diesem Bereich nützlich, wenn sie denn richtig gemacht werden. In jeder unserer Entwicklungen gibt es erhebliche Unwägbarkeiten, und mit agilen Methoden lassen sie sich besser beherrschen. > Das hat damit zu tun, dass es > nicht gut umgesetzt wurde und soweit es umgesetzt ist, löst es die > Kernprobleme der Aufgabenstellung nicht. Das soll es ja auch gar nicht, es soll nur die Lösungen und jene, die sie liefern, besser koordinieren. Nicht mehr, aber auch nicht weniger. Wenn diese Methoden nicht gut umgesetzt werden, wie Du ja selbst sagst, ist das nicht der Methode anzulasten, sondern der mangelhaften Umsetzung. > Scum ist in erster Linie geeignet, um ein Bündel konkreter Aufgaben auf > eine Gruppe zu verteilen, ...in zweiter Linie, besser auf Veränderungen reagieren zu können, und in dritter Linie, die Abstimmung mit Kunden und Nutzern zu verbessern. > Durch die modernen Tools wie Code-Managementsysteme, > Planungshilfen, Datenbank-gestützte Informations- und Projektverwaltung > sind diese Strukturen aber auch inzwischen da und müssen nicht ad hoc > organisiert werden. Viele dieser Dinge sind ja auch keine neuen Erfindungen -- vieles ist zwar im Laufe der Jahre besser, ausgereifter und ausgefeilter geworden. Aber andererseits sind Software und deren Entwicklung heute deutlich komplexer und komplizierter geworden, und agile Methoden (nicht nur SCRUM, übrigens) helfen uns, damit umzugehen.
J. S. schrieb: > Sheeva P. schrieb: >> Vor allem den direkten Kontakt mit Kunden, Fachlichkeit und Kollegen >> habe ich dabei ganz besonders zu schätzen gelernt. Dann bekommen die >> Kunden und ihre Fachleute nämlich mit, wie aufwändig Software >> entwickelt, betrieben und gepflegt wird, und umgekehrt verstehen die >> Entwickler und Betreiber besser, was der Kunde will und braucht. > > Klingt prima und sinn - nur was ist die Aussage dahinter? > > Wieso sollte das (nur) unter Nutzung eines Scrum-Prozesses > funktionieren?? Ich habe nirgendwo gesagt, daß das NUR mit agilen Prozessen geht. Meiner Erfahrung nach funktioniert es damit aber besser. Könnten wir uns bitte darauf einigen, daß Du versuchst, auch die feinen Nuancen meiner Aussagen wahrzunehmen und nicht immer schwarzweiß zu malen? Danke. > Mit dem Kunden = Abnehmer eines Produktes zu sprechen, ihm die > Komplexität der Aufgabe und damit die notwendigen Schritte und Bedarfe > klarzumachen, war und ist schon immer Gegenstand eines > Entwicklungsprozesses und wird gerade von Selbständigen genau so > betrieben, weil sie gesamte Palette von Angebot, Projektorganisation und > Umsetzung alleine abdecken. Die offene Frage ist nur, wer konkret > jeweils der Kunde ist. In der Regel ist das der Projektleiter, im > Einzelfall auch mal der Endkunde. Ja, genau, der Projektleiter... Wenn er wirklich kompetent ist, wird er auch in nicht-agilen Prozessen auf Prototypen bestehen und sie mit jenen besprechen, die am Ende mit der Software arbeiten müssen. Das führt dann meistens zu einer besseren und einfacher benutzbareren Software -- das funktioniert leider nur begrenzt mit fachfremden UX-Spezialisten. Leider begegnen mir in klassischen Wasserfall-Unternehmen allerdings mitunter, nunja... genau jene gottgleichen Alleskönner, deren Einstellungen wir in diesem Thread mitunter beobachten mußten. Die, die sowieso alles wissen, natürlich immer besser, kennst Du die nicht? Am Ende ist das Produkt dann fertig und wird vom Gottgleichen abgesegnet, und scheitert dann an den Widerständen der Leute, die damit arbeiten müssen... oder die Software macht am Ende zwar das, was im Lasten- und Pflichtenheft des Gottgleichen steht, ist aber in der Praxis trotzdem unbrauchbar. Da helfen ein paar Prototypen und die direkte Kommunikation mit der Fachlichkeit außerordentlich, und na klar, das geht natürlich auch in nichtagilen Projekten, wird dort aber wesentlich seltener gemacht. In agilen Projekten gehört das zum Prozeß, und deswegen fühlen sich die Fachleute dabei auch eher mitgenommen. Naja, weißt Du, mir ist das grundsätzlich egal, wie Du das hälst, was Du wann und wie machst, und ob Du agile Methoden magst oder nicht. Ich habe lediglich darauf hingewiesen, daß meine agilen Projekte bislang in jeder Hinsicht meistens die besseren Ergebnisse erzielt haben. Und wie gesagt: ich mach das ja nicht erst seit gestern.
Schon spannend, wie einige hier die Planwirtschaft verteidigen, obwohl klar ist, das die an einer bestimmten Größe scheitert.
Es antworten vor allem Diejenigen mit DER einzig möglichen Antwort, welche so von sich selber so überzeugt sind und alles im Griff haben. Dabei wissen sie weder dass SCRUM keine Methode ist, noch das der Projektleiter i.d.R. nichts, aber auch gar nichts mit Fachlichkeit zu tun hat - außer in pseudo-Ramsch-Wald-und-Wiesen-Projeken - nicht mal einen richtigen Plan, mit Rollen und einer (mit dem Kunden) vereinbarten Vorgehensweise. PS: Natürlich kann in hybriden oder schlanken Projekten auch der PL als Entwickler mitarbeiten, aber nicht in einem 500k oder 5Mio € Projekt. Was hat „Alter Hase“ mit Veränderungsfähigkeit zu tun? Sorry, nichts. Und wenn ein Auftragnehmer ein agiles Vorgehen nicht auf die Reihe bekommt - was hat das mit SCRUM zu tun? Genau, auch nichts. Das ist in traditionellen Wasserfallmodell-Projekten auch nicht anders. Warum gehen denn so viele große Projekte schief? Die Antwort ist ziemlich einfach, nur wer gibt schon gerne zu, dass das genaue Ziel meistens gar nicht klar ist und der Markt einfach weiter rennt - und sich die Anforderungen schneller ändern als Projekte mal die 50% Marke erreichen…
Scrum gehört zu einer typischen festen oder temporären Mitarbeiterstelle - mit dem freien Unternehmer hat diese Rolle doch gar nichts zu tun, außer man ist der Moderator bzw. baut im Unternehmen Scrum auf. Sind die Moderatoren nicht auch in die Task eingebunden? Dann sehe ich das eher kritisch für einen Freiberufler. Ich habe Scrum in einem Unternehemn erlebt und kann dazu nur beitragen, dass alle beteiligten am Kotzen waren. Es gab die Ausnahme der Moderatoren, hier hat der GF vermutlich was versprochen. Vom praktischen Nutzen her, hat man im täglichen Betrieb gar nichts gemerkt. Es war sogar eine Blockade, kam eine Aufgabe vom Scrum-Team hineingeflattert war diese überwichtig und alles hatte stillzustehen. Das will doch was heißen, wenn alle Bereiche vom Engineering bis Logistik, also unterschiedlichste Bereiche, Personentypen und Herausforderungen, davon nicht überzeugt werden konnten. Dann muss man plötzlich so viel Kapa jede Woche wegsperren, dass es laufen soll? Arbeiten im Team, Aufgaben verteilen, täglich stand-ups und reporten -> natürlich gerne. Scrum -> Nein danke Gibt übrigens auch relativ wenig Scrum Projektausschreibungen.
:
Bearbeitet durch User
Michael S. schrieb: > Scrum gehört zu einer typischen festen oder temporären Mitarbeiterstelle > - mit dem freien Unternehmer hat diese Rolle doch gar nichts zu tun, Du bringst es auf den Punkt. SCRUM -> Team Freelancer : Nix Team! Ein T. schrieb: > Die Gründe, aus denen agile Methoden entwickelt worden sind, haben sich > meines Erachtens sogar verschärft. Softwareprojekte sind heute > wesentlich komplexer und komplizierter als früher, Das liegt aber auch daran, daß früher mehr allrounder am Werk waren während heute nur noch schmal ausgebildete eingesetzt werden. Deswegen braucht es eine größere Zahl von Personen. Dazu kommen sie noch aus aller Herren Länder. Die wollen organisiert sein. Auch nicht zu verachten ist die Auslagerungswelle: Vor 20 Jahren hatte noch jede Firma eine eigene Entwicklungsabteilung mit Software und Hardware. So nach und nach wurde das abgeschafft. Die Arbeit machen die Zulieferer und die sind straff organisiert. Wenn der Projektverantwortliche noch etwas braucht, hat er einfach runtertelefoniert. Wir haben es dann hineinprogrammiert. Heute ist derjenige der Kunde eines Zulieferbetriebes und muss seine Ideen dort hineinwerfen. Diese machen dann continous delivery. Auch das will schon organisiert sein. Wenn die Software dann auch noch von unterschiedlichen Standorten kommen, weil Indien so schön billig ist, wird eine Verteilung induziert, die es ansonsten gar nicht gegeben hätte. Das vor allem macht Software komplexer.
Michael S. schrieb: > Ich habe Scrum in einem Unternehemn erlebt und kann dazu nur beitragen, > dass alle beteiligten am Kotzen waren. Es gab die Ausnahme der > Moderatoren, hier hat der GF vermutlich was versprochen. > Vom praktischen Nutzen her, hat man im täglichen Betrieb gar nichts > gemerkt. Es war sogar eine Blockade, kam eine Aufgabe vom Scrum-Team > hineingeflattert war diese überwichtig und alles hatte stillzustehen. Das ist dann aber ein Fall von "nicht richtig umgesetzt", fürchte ich.
M. T. schrieb: > Ein T. schrieb: >> Die Gründe, aus denen agile Methoden entwickelt worden sind, haben sich >> meines Erachtens sogar verschärft. Softwareprojekte sind heute >> wesentlich komplexer und komplizierter als früher, > > Das liegt aber auch daran, daß früher mehr allrounder am Werk waren > während heute nur noch schmal ausgebildete eingesetzt werden. Andersherum wird ein Schuh daraus: die Spezialisierung ist eine Folge der gestiegenen Anforderungen und der dadurch gestiegenen Komplexität. Und im Endeffekt stehen die gottgleichen Allrounder, die alles zu wissen und zu können glauben, den gottgleichen Projektleitern in wenig nach. Das nennt sich Arbeitsteilung, und die muß dann irgendwie koordiniert werden. Team versus Einzelkämpfer, wenn man es darauf herunter brechen will.
Ein T. schrieb: > Das ist dann aber ein Fall von "nicht richtig umgesetzt", fürchte ich. Das kennt man ja vom Kommunismus. Der hat auch nur nicht funktioniert, weil er bisher nie richtig umgesetzt war... SCNR ;-)
Martin M. schrieb: > Ein T. schrieb: >> Das ist dann aber ein Fall von "nicht richtig umgesetzt", fürchte ich. > > Das kennt man ja vom Kommunismus. Der hat auch nur nicht funktioniert, > weil er bisher nie richtig umgesetzt war... Sorry, aber das ist ja nicht ganz richtig. In manchen Gesellschaften und auf einer freiwilligen Basis hat der Kommunismus funktioniert und tut es bis heute, zum Beispiel in den israelischen Kibbuzen. Nur die Umsetzungen auf staatlicher Ebene sind in Armut, Blut, oder beidem geendet oder auf einem traurigen Weg dorthin, wo Kollektivismus nun einmal endet. Selber SCNR! :-) /Offtopic
Ein T. schrieb: > Andersherum wird ein Schuh daraus: die Spezialisierung ist eine Folge > der gestiegenen Anforderungen und der dadurch gestiegenen Komplexität. Wo sind denn diese "gestiegenen Anforderungen"? Hat sich die Mathematik geändert? Hat sich die Elektronik geändert? 90% der Ingenieure machen ein tägliche Arbeit, bauen ganz normale Schaltungen, die Softwareentwickler stecken ihre LIB-Module zusammen. Gerade letzteres ist heute deutlich einfacher, als noch vor 20 Jahren, wo jeder Compiler seine Macken hatte, man noch tief auf die HW musste. Nach Aussagen von Fachleuten ist heute das Arbeitsfeld viel begrenzter, weil die Ausbildungen sich verkürzt haben. Es ist ein gewollter Prozess, aus Ingenieuren, die mitdenken, im Wesentlichen Arbeiter zu machen, die wie in einer gleichgeschalteten Fabrik im Akkord die Eier legen.
Mann Fred T. schrieb: > Nach Aussagen von Fachleuten ist heute das Arbeitsfeld viel begrenzter, > weil die Ausbildungen sich verkürzt haben. Es ist ein gewollter Prozess, > aus Ingenieuren, die mitdenken, im Wesentlichen Arbeiter zu machen, die > wie in einer gleichgeschalteten Fabrik im Akkord die Eier legen. Laber, laber, laber. Dr alle Alkrounder ist doch heute schon überfordert, wenn er selbst im Word einen Brief schreiben muss. Ohne Diktiergerät und Abteilungssekretärin wird das nix!
Re D. schrieb: > wenn er selbst im Word einen Brief schreiben muss. Ohne > Diktiergerät und Abteilungssekretärin wird das nix! Im Gegenteil: Lies dir mal ein komplettes Lastenheft von einem Vollingenieur und dann das von einem bachlor durch. Sprachliche Offenbarung. Schon die Einleitung ihre "Thesis" und anderen Publikationen zeigt, wer da angerollt kommt.
Alsoooo uns (lokale IT mit 6 MA in einer Großen Firma mit weltweiten Standorten) wurde vor rund 2 Jahren Scrum/Agile aufgezwungen und mit einer lokalen IT (7 MA) an einem nahe gelegenen Standort zu einem Team verheiratet. Aktuell verbrät jeder ca. 20h/Monat mit Meeting zu diesem Thema. Keiner der MA hat exakt die gleichen Aufgabengebiete. Ein paar der MA finden das geil (logisch ist besser als arbeiten), ein paar haben resigniert, ein paar sind immer noch dagegen. Meine Meinung ist und war: Ja das mag bei z.B. einer Gruppe von Programmierern oder Entwicklern eine tolle Sache sein, aber bei Leuten, die die Hardware (PC, Drucker, Spezialdrucker, 3D-Drucker, Maschinenanbindungen, Scanner, Handhelds, Terminals, u.v.m.) in einer Firma betreuen, lokale Lösungen entwickeln, fürs Netzwerk und Telefonie zuständig sind, Bestellungen erledigen, im AD arbeiten und supporten ..... IST DAS DER LETZTE SCHEISS. MAN WIRD KAUM MIT DER ARBEIT FERTIG, ES HÄUFEN SICH ÜBERSTUNDEN BEI DEN KOLLEGEN AN (ich könnte sofort 8 Wochen Gleitzeit nehmen), DIE UNZUFRIEDENHEIT STEIGT STETIG UND DIE LEITUNG/VERBRECHER DIESES ZUSTANDES SIND 110%IG BERATUNGSRESISTENT!!! Sorry aber das mußte mal raus und hoffentlich liest das mal jemand, der Entscheidungsgewalt hat und denkt darüber nach, ob alles wirklich überall anwendbar ist. Gruss Harry
Crazy H. schrieb: > Aktuell verbrät jeder ca. 20h/Monat mit Meeting zu diesem > Thema. Also eine Stunde pro Arbeitstag? Das ist zweifellos viel zu viel für ein Daily Standup. > Keiner der MA hat exakt die gleichen Aufgabengebiete. Sofern es Überschneidungen gibt, ist eine Abstimmung nötig. > Meine Meinung ist und war: Ja das mag bei z.B. einer Gruppe von > Programmierern oder Entwicklern eine tolle Sache sein, aber bei Leuten, > die die Hardware (PC, Drucker, Spezialdrucker, 3D-Drucker, > Maschinenanbindungen, Scanner, Handhelds, Terminals, u.v.m.) in einer > Firma betreuen, lokale Lösungen entwickeln, fürs Netzwerk und Telefonie > zuständig sind, Bestellungen erledigen, im AD arbeiten und supporten > ..... IST DAS DER LETZTE SCHEISS. Also nach Deinen Schilderungen habe ich eher den Eindruck, daß Ihr da etwas macht, das wenig bis nichts mit agilen Methoden zu tun hat.
Ein T. schrieb: > Crazy H. schrieb: >> Aktuell verbrät jeder ca. 20h/Monat mit Meeting zu diesem >> Thema. >> zuständig sind, Bestellungen erledigen, im AD arbeiten und supporten >> ..... IST DAS DER LETZTE SCHEISS. > > Also nach Deinen Schilderungen habe ich eher den Eindruck, daß Ihr da > etwas macht, das wenig bis nichts mit agilen Methoden zu tun hat. Das denke ich auch was Du schreibst. Ein Haufen Buzzwords und keine Ahnung. „Übergeholfen“ ist immer Mist, egal um was es geht. Es macht nur keinen Sinn über etwas zu reden, wenn jemand selber Null Erfahrungen und/oder Null verstanden hat. Agile Ansätze lassen sich überall einsetzen, funktionieren aber nicht in (typischen) hierarchischen Organisationen - weil die Prinzipien meist meilenweit auseinander liegen. Beispiel: Der Kunde als Product Owner arbeitet fleißig mit dem Entwicklerteam, dass schon einen MVP fast fertig hat. Alle sind zufrieden, denn der Kunde bekommt das was er braucht. Dann kommt der Technikvorstand um die Ecke und verlangt einen Releaseplan… Der PL auf Kundenseite gibt den Druck weiter und dann wird es nur noch Scheiße. WTF: Es gibt keinen Releaseplan, wozu auch. Was bei Wasserfallprojekten und lahmarschigen Entscheidungen heraus kommt kann jeder bei öffentlichen Projekten sehen - I.d.R. gigantische Mehrkosten. Und es ist scheißegal ob eine Brücke gebaut, ein Flughafen verlegt oder eine Software geschrieben werden muss. Wer da grundlegende Unterschiede sieht, hat von Projekten - mit Verlaub - keine Ahnung.
:
Bearbeitet durch User
Crazy H. schrieb: > Meine Meinung ist und war: Ja das mag bei z.B. einer Gruppe von > Programmierern oder Entwicklern eine tolle Sache sein, aber bei Leuten, > die die Hardware .. entwickeln, > ..... IST DAS DER LETZTE SCHEISS. Sehe ich absolut so. Ich kenne niemanden aus der Hardwareecke, der SCRUM befürwortet. Das ist etwas für Software mit all ihrer Dynamik und Gruppenarbeit. Wo aber keine Gruppe mit gemeinsamer Arbeit, da kein SCRUM. Zum Thema "flache Hierarchien": Bei der Nationalmannschaft, wo es absolut um die Gruppenleistung geht, wird das gerade wieder abgeschafft. Von wegen "das Team denkt als Ganzes und so" ...
Uwe D. schrieb: > Was bei Wasserfallprojekten und lahmarschigen Entscheidungen heraus > kommt kann jeder bei öffentlichen Projekten sehen Nein Uwe, da liegst du quer: Diese Entscheidungsprozesse sind eben gerade NICHT so durchgeführt worden, dass sie adäqat gewesen wären und sind kein Gegenbeispiel. Das Problem der von dir angeführten ... > Mehrkosten. Brücke ein Flughafen ... entstehen dadurch , dass kein richtiger Entscheider da ist, weil zu viele sich das Bällchen zuschieben und die Verantwortung wegdrücken. Soweit ein Entscheider da ist, ist es ein Politiker, der sich schmücken möchte, aber keine Kompetenz hat und folglich von den Zulieferern ausgenommen wird: Es war Wowereit, der für den BER verantwortlich war und der von Tuten und Blasen keine Ahnung hatte. Es war Mappus, der hier in BW den Verkauf der Grundstücke um das Bahngelände angetriggert hat und den Bahnhof unter die Erde wollte, obwohl der Chefplaner immer die Hand gehoben hatte. > eine Software geschrieben werden muss. Gleiches Problem: Der Entscheider ist die Bundesagentur und dort sitzen nur inkompetente, die den Billigsten nehmen. Es gewinnt dann der das Projekt der am besten betrügt, belügt und mit den Preisen trickst, Polen beschäftigt und sonst wie Kosten drückt oder verschweigt. Wenn man mit einem realistischen Angebot kommt, fliegt man raus. Platzeck-Effekt heisst das in der Hauptstadt. Ansonsten kommen nur die durch, die ein überteuertes Angebot machen, es aber trotzdem machen dürfen, weil sie den Entscheider kennen. > Wer da grundlegende Unterschiede sieht, hat von Projekten - mit > Verlaub keine Ahnung. Wer hier Gemeinsamkeiten zu einem von einem Ingenieur geführten Entwicklungsprojekt sieht, hat - Verlaub - einen extremen Hinkevergleich gezogen.
Manni T. schrieb: > Uwe D. schrieb:+ >> Mehrkosten. Brücke ein Flughafen > ... entstehen dadurch , dass kein richtiger Entscheider da ist, [...] > > Es war Wowereit, der für den BER verantwortlich war [...] Du könntest Dir wenigstens mal mit Dir selbst einig werden, ob es nun keinen Entscheider gab oder ob Wowereit der Entscheider war. > Es war Mappus, der hier in BW den Verkauf der Grundstücke um das > Bahngelände angetriggert hat und den Bahnhof unter die Erde wollte, > obwohl der Chefplaner immer die Hand gehoben hatte. Erste Pläne, den Sackbahnhof in Stuttgart durch einen Durchgangsbahnhof zu ersetzen, gab es schon 1901, dann noch einmal 1965. Da war Herr Mappus noch nicht einmal geboren. Als dann 1994 ein weiterer Plan -- übrigens mit der ausdrücklichen Unterstützung der Grünen -- öffentlich gemacht wurde, war Herr Mappus gerade 28 Jahre als und Mitglied des Gemeinderats Mühlacker sowie Kreisrat im Enzkreis.
Ach @manni, Du schreibst selbst, dass immer „jemand“ schlechte Entscheidungen getroffen hat. Der typische Reflex von Anhängern von Hierarchien. Das zweitwichtigste sind dann Abschlüsse und Zertifikate… Und dann muss ein Schuldiger her. Tja, in einer Teamentscheidung wäre das vielleicht doch anders gelaufen. PS: Die öffentlichen Besteller nehmen nicht den Billigsten, sondern den Wirtschaftlichsten (Anbieter). PPS: Und damit das dann klappt, muss man ganz genau wissen was man braucht.
Manni T. schrieb: > Wer hier Gemeinsamkeiten zu einem von einem Ingenieur geführten > Entwicklungsprojekt sieht, hat - Verlaub - einen extremen Hinkevergleich > gezogen. Danke für den Tipp: Was meinst Du wohl, was der Neubau einer Brücke oder einer Eisenbahnstrecke darstellt? Da gelten von A-Z die gängigen Vorschriften für Ingenieure (HOAI), einschließlich BGB-, Handels- und Steuerrecht. Da ist V-Modell, Safety usw. der Normalzustand - Planung ganz groß, inklusive Lastenheft und allem „Nicht-Agilen“.
Ein T. schrieb: > Du könntest Dir wenigstens mal mit Dir selbst einig werden, ob es nun > keinen Entscheider gab oder ob Wowereit der Entscheider war. Das ist faktisch gleichbedeutend. In Sachen Projektleitung oder gar Technik hat der Herr keinerlei Wissen. Dem kann man alles unterjubeln und wie wir wissen ist das ja auch passiert.
Ein T. schrieb: > Also eine Stunde pro Arbeitstag? Das ist zweifellos viel zu viel für ein > Daily Standup. Es gibt neben den Dailys auch noch Sprintwechsel, Refinements, Teaminfos, System Demos, Retros, PI-Planings, ..... da kommt was zusammen. Ich nehme ja schon jetzt nicht an allem teil (vor allem wenn es dann mal europäisches oder weltweites Blahblah ist) ..... die 20h/Monat lassen sich locker noch nach oben korrigieren. Früher (ja da war alles besser :-D) hatten wir einmal pro Woche 1h eine Besprechung (organisatorisches) und evtl. in kleinerem, fachlichen Kreis noch das eine oder andere Meeting. Da wurde man mit der Arbeit besser fertig und hatte deutlich weniger Überstunden. Ja ok Überstunden sind was feines, damit kann man 30 Tage Urlaub mit zusätzlich 30-40 Tage Gleitzeit aufstocken.
Manni schrieb: > Ein T. schrieb: >> Du könntest Dir wenigstens mal mit Dir selbst einig werden, ob es nun >> keinen Entscheider gab oder ob Wowereit der Entscheider war. > > Das ist faktisch gleichbedeutend. In Sachen Projektleitung oder gar > Technik hat der Herr keinerlei Wissen. Dem kann man alles unterjubeln > und wie wir wissen ist das ja auch passiert. Selbst das Wasserfallmodell mit den verschiedenen Rollen hast Du falsch dargestellt: Wowereit hat politisch Einfluss genommen um seine Ziele zu verfolgen. Aber von Technik muss der nix verstehen. Wowereit war kein Projektleiter, er saß im Vorstand der Geldgeber (=Lenkungsausschuss). Genau wie ein Projektleiter das nicht muss. Dafür gibt es ja die Rollen. Die Arroganz von politischen und wirtschaftlichen Akteuren und deren Wirken sagt nur etwas über unser Rechtssystem, dass die Bestrafung von derartigen Auswüchsen nicht vorsieht. Derartiges Versagen gab es schon oft in der Geschichte und haben das (vorzeitige) Ende der Regentschaft einiger Machtinhaber eingeleitet. https://www.morgenpost.de/berlin/article207605825/Wowereit-hat-Schuld-am-BER-Debakel.html Und auch hier wieder die immer gleichen Muster: - Hierarchiedenken - Klugscheißen - Änderungen bis sonstwo Und aus meiner Sicht sind Punkt 1+3 gut zu ändern. Nur halt von den ewig Gestrigen nicht.
:
Bearbeitet durch User
Crazy H. schrieb: > s gibt neben den Dailys auch noch ... einiges, wie ich lese und auch aus eigener Anschauung bestätigen kann: > Sprintwechsel 1h wöchentlich, um Änderungen in den Inhalten zu erörtern - meistens eine Art Vorschlagsammlung ohne Wert > Refinements, 2h alle 2 Wochen, um Änderungen am Prozess zu besprechen - nutzloses Gelaber, weil aus Zeitgründen eh nichtt umsetzbar - die Macher sind von den Terminen gedränkgt und können den aktuellen Prozess schon nicht durchhalten > Teaminfos 15min tägliche Besprechung, was sich so ergeben hat und "von oben" neues gibt, außer Freitags. >System Demos keine Ahnung was das ist >Retros Ebenfalls 2h Retro alle 2 Wochen, zur Nachbetrachtung der Inhalte - um nutzvoll zu sein, zu grob getaktet >PI-Planings, 1-2h pro Woche mit einigen Mitarbeitern, Viele nicht dabei. und dann: > täglicher Report in Jira 10-20min täglich um Aufgaben zu planen, zu veralten und abzuhaken > täglicher Synch 15-30 min täglich um die Probleme zu umgehen, die durch SCRUM entstanden sind Insgesamt 9h die Woche zur Befriedung von SCRUM! Der Zeiteinsatz ist einfach zu hoch. Was dabei rumkommt, wähe auch in der Hälfte der Zeit zu schaffen, denn die technischen Absprachen mit den Kollegen bleiben ja trotzdem. SCRUM hat mir nur den Terminkalender vollgestopft und die Zeit zum eigentlichen Arbeiten genommen. Ab 1.10. geht es in eine normale Firma, in der SCRUM schon wieder abgeschafft wurde und geradlinig gearbeitet wird.
Manni schrieb: >>System Demos > keine Ahnung was das ist Da klopfen sich die Gruppen selber auf die Schulter und erörtern wie gut sie sind. Manni schrieb: >>PI-Planings, > 1-2h pro Woche mit einigen Mitarbeitern, Viele nicht dabei. Alle 3 Monate 2-3 Tage. Da wird geplant, was man in den nächsten 3 Monaten machen möchte. Manni schrieb: >> Sprintwechsel > 1h wöchentlich Alle 2 Wochen anfangs 6h, jetzt noch 3h.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.