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.
Peter A. schrieb: > Wer sich diesen SCRUM Rotz als selbstständiger freiwillig antut ist echt > nicht zu retten. Gehst doch zur Schule? Oder Kindergarten? Oder bist sonst nur ein Rotz-junge?
Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst verloren
Kindergärtner schrieb: > > … Oder bist sonst nur ein > Rotz-junge? Du machst deinem Nick alle „Ehre“. Hoffe für die Kinder, dass du kein Kindergärtner im realen Leben bist.
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.
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 "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" 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.