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.
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.
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.
Uwe D. schrieb: > aber auch gar nichts mit Fachlichkeit zu > tun hat - außer in pseudo-Ramsch-Wald-und-Wiesen-Projeken das ist aber die Realität, wie SCRUM interpretiert und gelebt wird
Crazy H. schrieb: > Da klopfen sich die Gruppen selber auf die Schulter und erörtern wie gut > sie sind. Oh ja. War selber vor Kurzem in einer solchen Gruppe. Der Scrum-Master hat in dem review sofort nach Problemen gefragt und weil keiner sofort geantwortet hatte, "alles gut gelaufen" eingetragen. Da ich da anderer Meinung war und Kritik am Vorgehen äußerte und an vergessenen und nichterledigten Dingen, die ausdrücklich vom Vormeeting noch als Tasks benannt wurden, gab es Stress. Sehr unangenehm wurde aufgenommen, dass ich mich z.T. auf SCRUM-Prinzipien stützte, mir aber sagen lassen musste, Ich nehme das zu ernst und müsse auch mal "5e gerade sein lassen". D.h. nach Lust und Laune darf man vom Prozess abweichen, andere ins Abseits stellen und es dann gutheißen. Da hieß es dann : Next Project please! Wie gesagt ich beobachte SCRUM und dessen Umsetzung seit rund 15 Jahren und ich kann keine einzige Firma nennen, die es a) 100% richtig und b) erfolgreich eingesetzt hätte. Kein Einzige. Ich sehe ausnahmslos mehr Nachteile als Vorteile.
SCRUM betrifft höchstens Scheinselbstständige. Echte Selbstständige lachen darüber.
Bernd G. schrieb: > SCRUM betrifft höchstens Scheinselbstständige. Echte Selbstständige > lachen darüber. Die wussten gar nicht, was das ist, bis sie es hier gelesen haben ;-)
J. S. schrieb: > Crazy H. schrieb: >> Da klopfen sich die Gruppen selber auf die Schulter und erörtern wie gut >> sie sind. > > Oh ja. War selber vor Kurzem in einer solchen Gruppe. Der Scrum-Master > hat in dem review sofort nach Problemen gefragt und weil keiner sofort > geantwortet hatte, "alles gut gelaufen" eingetragen. Wo eingetragen? > Meinung war und Kritik am Vorgehen äußerte und an vergessenen und > nichterledigten Dingen, die ausdrücklich vom Vormeeting noch als Tasks > benannt wurden, gab es Stress. SCRUM heißt nicht unverbindlich oder irgendwas machen. Die vereinbarten Sprintziele sind selbstverständlich der Anspruch. Ist das in Wasserfall-Projekten anders? Vielleicht mal die Vorurteile überdenken (vor dem Schreiben). > Sehr unangenehm wurde aufgenommen, dass ich mich z.T. auf > SCRUM-Prinzipien stützte, mir aber sagen lassen musste, Ich nehme das zu > ernst und müsse auch mal "5e gerade sein lassen". D.h. nach Lust und > Laune darf man vom Prozess abweichen, andere ins Abseits stellen und es > dann gutheißen. SCRUM ist kein Prozess, vielmehr ein Framework. Wenn der Scrummaster (oder wer auch immer da gesprochen hat) das so macht, dann ist es wohl kein SCRUM - eher ein Marketingschild. > Wie gesagt ich beobachte SCRUM und dessen Umsetzung seit rund 15 Jahren Beobachten ist nicht dabei sein, häufig hörensagen und persönliche Meinung. > und ich kann keine einzige Firma nennen, die es a) 100% richtig und b) > erfolgreich eingesetzt hätte. Kein Einzige. Ich sehe ausnahmslos mehr > Nachteile als Vorteile. Es gibt immer schlechte Beispiele. Veränderungen kosten halt Geld, unabhängig von SCRUM. Wenn mit wenig Veränderungswillen und viel Marketing-Getöse „etwas versucht“ wird - dann wird es garantiert scheitern. Interessanterweise meinen Opfer einer solchen Tragödie hernach, dass sie Kenntnis und Erfahrung hätten. Haben sie nicht. Nur ihren somatischen Marker gefüttert, der das wie immer vorher alles schon wusste. Nachtrag: zu viele Typos
:
Bearbeitet durch User
Chris D. schrieb: > Bernd G. schrieb: >> SCRUM betrifft höchstens Scheinselbstständige. Echte Selbstständige >> lachen darüber. > > Die wussten gar nicht, was das ist, bis sie es hier gelesen haben ;-) Doch. doch, wir wissen schon sehr wohl, was das ist, guckt einen ja auch an jeder Ecke an. Aber das geht an mir genau so vorbei wie die Begriffe "Tarifarbeitszeit, Gleizzeitüberschuss, Kantinenessenbezuschussungspauschale, Mitarbeiterführung, Mitarbeitergespräch, Teamkritikfähigkeitsverbesserung" und den ganzen anderen Scheiss, den es in der Industrie 2.0 gibt. Ich mache meine Arbeit, kriege mein Geld und lasse Teams ihr Teamsgedöhns machen.
Uwe D. schrieb: > noch das der > Projektleiter i.d.R. nichts, aber auch gar nichts mit Fachlichkeit zu > tun hat Eines der Kernprobleme bei SCRUM. Wenn die Inhalte einer Planungstätigkeit von der Form, also der Verwaltung entkoppelt sind, hat das keine Vorteile sondern nur Nachteile. Wir kennen die Planungsqualitäten von Leuten, die das Technische nicht draufhaben. Besonders schlecht ist es, wenn der technisch versierte Projektleiter gar nicht vorhanden ist, wie im Scrum-Team, das dann ersatzweise die Entscheidungen fällen muss. Ein führungsloser Haufen, wo der Redegewandeste das Wort führt. So mein Eindruck von Scrum-Besprechungen.
Ich hab nichts gegen SCRUM, aber es behindert mich mehr, als daß es was bringt. Siehe Erläuterung oben.
A. F. schrieb: > Uwe D. schrieb: >> noch das der >> Projektleiter i.d.R. nichts, aber auch gar nichts mit Fachlichkeit zu >> tun hat > > Eines der Kernprobleme bei SCRUM. Wenn die Inhalte einer > Planungstätigkeit von der Form, also der Verwaltung entkoppelt sind, hat > das keine Vorteile sondern nur Nachteile. Wir kennen die > Planungsqualitäten von Leuten, die das Technische nicht draufhaben. > Besonders schlecht ist es, wenn der technisch versierte Projektleiter > gar nicht vorhanden ist, wie im Scrum-Team, das dann ersatzweise die > Entscheidungen fällen muss. Ein führungsloser Haufen, wo der > Redegewandeste das Wort führt. > > So mein Eindruck von Scrum-Besprechungen. Du hast keine Ahnung von SCRUM, aber ja, Du hast eine Meinung. Hauptsache dagegen, auch wenn Deine Argumente eher für Deine Inkompetenz sprechen in Sachen Projektmethodik im Allgemeinen und SCRUM im Speziellen.
:
Bearbeitet durch User
Uwe D. schrieb: > Du hast keine Ahnung von SCRUM, aber ja, Du hast eine Meinung. Ich habe eine Ahnung von dem was ich tagtäglich sehe und ja ich habe eine Meinung dazu. Die ändert sich auch nicht, nur weil die Scrumverfechter ihre Methoden (ach, huch es is ja gar keine Methode) in den Himmel loben und sich noch eine eigene Sprache dafür geben. Jede, ausdrücklich JEDE Projektabwinklungsmethode (huch, ich habe es schon wieder Methode genannt) steht und fällt mit der Umsetzung durch die beteiligten Personen. Und daran krankt es. Scrum macht Vorgaben, die an vielen Stellen eines Entwicklungprozesses (ich leite auch HW, nicht nur SW) keinen Sinn ergibt. Dort wo es aber wichtig wäre, Vorgaben zu machen, gibt es nichts und jeder baut sich seine eigene Welt. Aber da sich das Thema immer weiter von der eingangs gestellten Frage wegbewegt: SCRUM hat mit der Arbeit von Selbständigen nichts zu tun. Scrum ist eine Methode, um Teamarbeit an einer gemeinsam zu bewältigenden Aufgabe zu erledigen. Das gibt es aber eben nicht. * Ein Selbständiger erledigt seine Arbeit allein * Ein Selbständiger organisiert seine Arbeit allein andere haben da nichts mitzudiskutieren, zu wissen, zu entscheiden oder was auch immer. Dort, wo das passiert, kann man nicht mehr von Selbständigen sprechen.
Natürlich (und das wurde hier auch bereits angesprochen) kann und darf ein Selbständiger den Scrummaster machen, so wie er auch Projektleiter ist. Aber auch dann erledigt er seine Arbeit allein und organisiert seine Arbeit allein Ein Selbständiger ist selbständig und nicht Teil des Teams.
A. F. schrieb: > Ein Selbständiger ist selbständig und nicht Teil des Teams. Oh, dann darf ein freier Musiker, den ein Orchester (o.ä.) für eine Aufführung engagiert, also auch mal was anderes spielen als der Rest, oder seinen Einsatz zu einem anderen Zeitpunkt geben? Der braucht nicht auf den Dirigenten zu achten? Oder ein Schauspieler, darf der auch in seiner Wohnung auftreten/filmen und den Anweisungen des Regisseur nicht folge leisten? Wie oben schon gesagt: Allein vom Eingebundensein in ein Team wird daraus noch keine Schein-Selbständigkeit. https://www.ihk-muenchen.de/de/Service/Recht-und-Steuern/Arbeitsrecht/Einstellung-von-Arbeitnehmern/Scheinselbst%C3%A4ndigkeit/ https://www.gulp.de/freelancing/wissen/scheinselbststaendigkeit/urteil-scrum-projekte-kein-indiz-scheinselbststaendigkeit Solange der oben angesprochene Musiker immer nur kurz für den einen Auftraggeber tätig ist, und daneben noch weitere Auftraggeber hat, sollte das kein Problem sein. Wenn der aber über eine längere Zeit immer nur und ständig für den einen AG tätig ist, sieht das schon anders aus.
:
Bearbeitet durch User
Achim H. schrieb: > Oh, dann darf ein freier Musiker, Ich würde fast wetten, dass es sich beim Musikus um einen Freiberufler handelt. Außer er führte eine Firma "Trompetensoli für feierliche Bestattungen GmbH". Es ist niedlich anzuschauen, wie sich hier etliche Leute verbiegen, um als Selbstständige durchzurutschen.
Achim H. schrieb: > Oh, dann darf ein freier Musiker, den ein Orchester (o.ä.) für eine > Aufführung engagiert, also auch mal was anderes spielen als der Rest, > oder seinen Einsatz zu einem anderen Zeitpunkt geben? Der braucht nicht > auf den Dirigenten zu achten? welch eine Schwachsinnige Auslegung von Selbständigkeit.
A. F. schrieb: > Achim H. schrieb: >> Oh, dann darf ein freier Musiker, den ein Orchester (o.ä.) für eine >> Aufführung engagiert, also auch mal was anderes spielen als der Rest, >> oder seinen Einsatz zu einem anderen Zeitpunkt geben? Der braucht nicht >> auf den Dirigenten zu achten? > > welch eine Schwachsinnige Auslegung von Selbständigkeit. Weil? Beschreibungen wären hilfreich, nicht Beleidigungen. Es ging doch um den Fakt, ab wann eine Selbständiger zum Scheinselbständigen mutiert, mit der Begründung: „Im Team immer.“
Uwe D. schrieb: > Es ging doch um den Fakt, ab wann eine Selbständiger zum > Scheinselbständigen mutiert, mit der Begründung: „Im Team immer.“ Nein, du verwechselst den formellen Aspekt Team mit dem Inhalt. Auch im Elektronikprojekt wird ein externer Freiberufler nicht irgendetwas machen, sondern das, was im Projektplan steht. Und natürlich wird ein Musiker nicht ein anderes Lied spielen, als der Rest des Orchesters.
A. F. schrieb: > Auch im Elektronikprojekt wird ein externer Freiberufler nicht > irgendetwas machen, sondern das, was im Projektplan steht. Nö, ein echter Selbständiger macht das, es in Vertrag steht. Was anderes macht er, wenn hierüber ein Vertrag geschlossen wurde.
Re D. schrieb: > > Nö, ein echter Selbständiger macht das, es in Vertrag steht. Was anderes > macht er, wenn hierüber ein Vertrag geschlossen wurde. Also entweder das was im Vertrag steht oder was anderes, wenn das im Vertrag steht. Alles klar.
A. F. schrieb: > Uwe D. schrieb: >> Es ging doch um den Fakt, ab wann eine Selbständiger zum >> Scheinselbständigen mutiert, mit der Begründung: „Im Team immer.“ > > Nein, du verwechselst den formellen Aspekt Team mit dem Inhalt. Auch im Wo genau verwechsle ich „Team“ mit „Inhalt“? Welcher Inhalt? Im Sprintplan ist nur festgeschrieben was der PO haben will. Mehr nicht. Die Kernfrage bleibt dennoch: Ab wann arbeitet der Freelancer unselbständig? Und meine Sichtweise ändert sich dennoch nicht: Die umzusetzenden Issues erledigt der Freelancer allein, ohne Weisungen. (Genau wie ein Fliesenleger - auch der kann kreativ sein, spezielle Fähigkeiten einsetzen und muss sich trotzdem an industrielle Normen halten. Trotzdem muss er sich mit dem Bauherrn oder dem GU abstimmen, zeitlich und inhaltlich. Es gibt Schnittstellen zu anderen Gewerken, die teilweise Vetorecht beim Bau haben. Trotzdem ist der Fliesenleger selbstständig.)
Klaus schrieb: > was anderes, wenn das im Vertrag steht. > Alles klar. Im Änderungsvertrag, dann passt es. Etwas anderes zu machen, als im Vertrag steht, ohne diese Änderungen vorher schriftlich zu fixieren machen vielleicht Leute wie Klaus, aber keine Profis.
Uwe D. schrieb: > Beobachten ist nicht dabei sein, häufig hörensagen und persönliche > Meinung. Beobachten ist "mitten drin" sein und mitbekommen, was läuft. Vor allem bekommt man mit, was die Mitarbeiter davon so halten, was sie untereinander in der Gruppe äußern und was sie gegenüber den Team- und Projektleitern davon auch offiziell äußern. Ein sehr interessanter Sachverhalt - nicht nur beim diesem Thema.
Achim H. schrieb: > Oh, dann darf ein freier Musiker, den ein Orchester (o.ä.) für eine > Aufführung engagiert, also auch mal was anderes spielen als der Rest, > oder seinen Einsatz zu einem anderen Zeitpunkt geben? Der braucht nicht > auf den Dirigenten zu achten? Den Vergleich mit dem Musiker muss man richtig aufziehen, wenn ein Schuh daraus werden soll und da geht es nicht darum, dass einer spielt was er will. Bei der Frage der Selbständigkeit unter Musikern muss man einmal die Künstler, also Komponisten, Arrangeure und freischaffende Musiker von den ausführenden Musikern, z.B. in einem Orchester trennen. Erstere außen vor gelassen, findet man auch in Orchestern beide Typen: Den freien Musiker und den festangestellten Musiker, und um die geht es hier im Bezug auf Scheinselbständigkeit. Diese Diskussion gibt es da natürlich auch, läuft aber auf dieselbe Frage hinaus: Der entscheidende Unterschied beim freien Musikers ist, dass er projektweise für eine Konzerttournee oder ersatzweise für einige Abende gebucht wird und dabei dann die freie Entscheidung hat, Preise und Umfang der Leistung zu bestimmen. Wenn er ein bestimmtes Repertoire nicht aufführen will, muss er es auch nicht. Ich kenne z.B. einen Bläser jüdischer Herkunft, der keine Wagneropern spielen will. Ein angestellter Musiker kann das nicht. Er hat das zu spielen, was nach Programmheft vorgegeben ist und auch die Zeiten einzuhalten. Insofern ist der freie Musiker dann ein Selbständiger, wenn er diese Vorteile ausnutzt und es entsteht die Frage nach der Scheinselbständigkeit, wenn er es nicht tut und er wie ein Angestellter getaktet wird. Dies soweit.
Das Ganze hat aber dem Thema Teamarbeit nichts zu tun. Dass die zusammen proben und spielen, impliziert z.B. nicht, dass es sich um eine Eingebundenheit in die Organisation einer Firma handelt, wie es bei dem Thema Freiberufler als Kriterium auftaucht. Insbesondere hat es mit SCRUM nichts zu tun, weil es dort um die Erledigung von gestellten Aufgaben geht, die zu Mehreren getätigt wird und die Umfänge nicht klar abgegrenzt sind, sondern eben sich das Team das selber verteilt. Das ist in der Musik anders: Die Aufgaben sind da ganz klar abgegrenzt und eindeutig verteilt. So muss man das auch bei dem gelinkten Urteil zu SCRUM sehen: Das Vorhandensein von SCRUM im Projekt ist alleine in der Tat nicht hinreichend für Scheinselbständigkeit und das wird dort auch so ausgesagt. Es ist aber ein Indiz - zwar auch eines von mehreren, aber durchaus kein schwaches. Es geht am Ende (wie bei den anderen Scheinselbständigkeitskriterien auch) darum, wie das im Bezug auf den Freiberufler gelebt wird. Insofern ist das Urteil keineswegs ein Gegenargument für den Aspekt Scheinselbständigkeit. Es sagt nur aus, dass nicht pauschal diese Schlussfolgerung gezogen werden darf, ohne weitere Aspekte zu berücksichtigen. SCRUM als solches ist also sehr wohl ein Aspekt, der in die Richtung Unselbständigkeit zeigt, besonders dann, wenn Aufgaben in kurzen Zeitabständen zugeteilt und umdefiniert werden. Daher ist (wie auch bei Projekten ohne SCRUM) darauf zu achten, dass die Aufgaben und Inhalte beim Freiberufler vertraglich genau fixiert sind.
Uwe D. schrieb: > Im Sprintplan ist nur festgeschrieben was der PO haben will. Mehr nicht. ?? Einspruch: Bei uns steht klitzeklein drin, wer was tun soll. Es sind zunächst nur Partialtasks, die auf weitere Partialtasks heruntergebrochen werden. Das ergibt zum Beginn des Projektes und dann in den S-Planungen jeweils einen detaillierten, nach unten breiter werdenden Baum. Daraus leiten sich Aufgabenpakete ab, die im JIRA abgebildet werden. Diese werden dann vom PO eindeutig an den Abwickler zugewiesen. Manchmal vom Scrum Master. Dabei wird natürlich berücksichtig, wer wass kann und wozu in der Lage ist, weil er die Zeit dafür findet.
E. S. schrieb: > Uwe D. schrieb: >> Im Sprintplan ist nur festgeschrieben was der PO haben will. Mehr nicht. > ?? > > Einspruch: > > Bei uns steht klitzeklein drin, wer was tun soll. Es sind zunächst nur > Partialtasks, die auf weitere Partialtasks heruntergebrochen werden. Nee, was der Kunde (PO) haben will steht drin. Und wie der freie Entwickler das umsetzt, ist sein Ding. User Stories sind so abzufassen, dass diese ohne Abhängigkeit allein abgearbeitet werden können. Das „wie“ bleibt beim Entwickler. > Das ergibt zum Beginn des Projektes und dann in den S-Planungen jeweils > einen detaillierten, nach unten breiter werdenden Baum. Die Sprint Plannings und Refinements geben den Takt vor und der PO legt fest, was wichtig ist und dahingehend wird priorisiert. Ein erfahrener Scrummaster lässt keine endlosen User Stories im Voraus zu. Aber Du weißt im Normalfall nicht, was in 8 Wochen programmiert wird. > Daraus leiten sich Aufgabenpakete ab, die im JIRA abgebildet werden. > Diese werden dann vom PO eindeutig an den Abwickler zugewiesen. > Manchmal vom Scrum Master. Nee Du, das Team einigt sich, wer eine Aufgabe übernimmt. Das Team gibt auch ein Commitment ab, dass die geplanten Issues im Sprint umgesetzt werden. Manager haben in dem Bereich nichts zu suchen. Wer das macht, hat SCRUM nicht kapiert.
Uwe D. schrieb: > das Team einigt sich, wer eine Aufgabe übernimmt. Da gibt es bei 4 Personen, von denen jeder was anderes kann, aber sehr wenig Spielraum. Allerhöchsten 2 können jeweils sinnieren, wer etwas macht. Der Rest verteilt sich von selber.
Uwe D. schrieb: > Nee Du, das Team einigt sich, wer eine Aufgabe übernimmt. Das Team gibt > auch ein Commitment ab, dass die geplanten Issues im Sprint umgesetzt > werden. > Manager haben in dem Bereich nichts zu suchen. Wer das macht, hat SCRUM > nicht kapiert. Das ist die Theorie. Habe ich so aber noch nie gesehen. Meistens verteilt immer einer die Aufgaben und zwar nach Wissen der Macher oder auch gerne dem Rosinenprinzip: Wer zuerst kommt, malt zuerst. Bedeutet: Wer ma Längsten in der Firma ist, der darf sich aussuchen, was er macht und den Rest kriegen die Spatzen. Geht nur solange, bis der Spatz keine Lust mehr auf Krümel hat und davon fliegt: In 2 von mir betreuten Projekten sind jetzt, kurz vor Weihnachten, insgesamt 3 junge Entwickler aus den zuliefernden Betrieben ausgeschieden und haben sich verbessert. Dummerweise waren das diejenigen, die am besten kommuniziert und dokumentiert haben. Die zurückgebliebenen müssen sich jetzt erst einmal orientieren und einarbeiten, denn trotz Doku und Scrum haben sie keine Ahnung, was der andere getrieben hat. Hier rächt sich das Scrum mit seinem unseeligen 2W-Rhythmus: Die Sprintplanungen stehen natürlich, nur sind 3 Sprinter nicht mehr auf der Bahn und rennen woanders. Nach der "alten" Methode hätte ich fertige Aufgabenblöcke mit Lieferterminen am 15. Dezember veranschlagt, die die Zuliefer bringen müssen.
Andi F. schrieb: > Das ist die Theorie. Habe ich so aber noch nie gesehen. Meistens > verteilt immer einer die Aufgaben und zwar nach Wissen der Macher oder > auch gerne dem Rosinenprinzip: Wer zuerst kommt, malt zuerst. Merkwürdig, so etwas habe ich weder bei meinen Arbeitgebern, noch bei unseren Kunden niemals erlebt. > In 2 von mir betreuten Projekten sind jetzt, kurz vor Weihnachten, > insgesamt 3 junge Entwickler aus den zuliefernden Betrieben > ausgeschieden und haben sich verbessert. Dummerweise waren das > diejenigen, die am besten kommuniziert und dokumentiert haben. Die > zurückgebliebenen müssen sich jetzt erst einmal orientieren und > einarbeiten, denn trotz Doku und Scrum haben sie keine Ahnung, was der > andere getrieben hat. > > Hier rächt sich das Scrum mit seinem unseeligen 2W-Rhythmus: Na klar, wenn drei Entwickler gehen und sich die anderen erst einmal in deren Projekte einarbeiten müssen, dann liegt das an Scrum. Entschuldige bitte, daß ich das so offen frage, aber: hast Du ernsthaft das Gefühl, dieser Diskussion intellektuell gewachsen zu sein?
Ein T. schrieb: > noch bei unseren Kunden niemals erlebt. Die Kunden werden dir auch gerade erzählen was bei ihnen intern so (nicht) läuft. Ein T. schrieb: > aber: hast Du ernsthaft das Gefühl, > dieser Diskussion intellektuell gewachsen zu sein? Ich gebe die Frage zurück. Du hast nicht verstanden, was ich schrieb. Ein T. schrieb: > und sich die anderen erst einmal in deren Projekte einarbeiten müssen, Das genau sollte gar nicht der Fall sein, wenn alle in einem scrum team gemeinsam arbeiten. Das setzt ja voraus, dass permanent kommuniziert wird und alle einen Überblick haben. Das ist aber nicht der Fall und beweist, dass jeder sein eigenes Ding macht. Es gab also kein Team. Trotz Scrum. Ich sage das als Projektleiter dieser Projekte und ja ich habe Überblick, wer da was tut und liefert. Am Ende arbeiten sie alle nebeneinander her.
Uwe D. schrieb: > Nee Du, das Team einigt sich, wer eine Aufgabe übernimmt. Das Team gibt > auch ein Commitment ab, dass die geplanten Issues im Sprint umgesetzt > werden. Was passiert, wenn das Team dieses Commitment nicht abgibt? Darf sich das Team aussuchen, wieviel es macht? Was passiert wenn ein Teammitglied mit der Aufgabenverteilung unzufrieden ist? Wer überstimmt da wen am Ende? Da also stecken schon zwei Hinkefüsse drin, aber es geht weiter: Was passiert, wenn ein Selbständiger mit der ihm zugewiesenen Aufgabe nicht zufrieden ist oder sie als nicht in der Sprintzeit zu leisten einschätzt? Es ging hier nach meinem Verständnis ja nicht um Scrum sondern um die Selbständigen beim Scrum. Das halte ich für noch komplizierter zu managen, als die Probleme, die bei Scrum ohnehin schon auftauchen. Hier ist eine Diskussion: Beitrag "Re: Meeting-Hölle/Scrum" Wie man sieht gibt es zwei Lager: Die Ablehner und die Zustimmer. Mein Eindruck ist, daß die Zustimmer auch aus Eigennutz zustimmen, weil sie von den Unzulänglichkeiten des Scrum-Systems profitieren: Es entlastet sie von der Verantwortung, gesamtheitlich für das Projekt zu denken und sie können sich als Einzelperson im Team gut verstecken. Es scheinen mir auch die Jüngeren zu sein, die Scrum befürworten. Daß die Firma als solche dann ineffektiver wird, sollte sie nicht kratzen, weil sie als jüngere eh dauernd die Firma wechseln und heute generell weniger Bezug zur eigenen Firma vorherrscht.
Uwe D. schrieb: > PS: > Die öffentlichen Besteller nehmen nicht den Billigsten, sondern den > Wirtschaftlichsten Träumer. Uwe D. schrieb: > Nee Du, das Team einigt sich, wer eine Aufgabe übernimmt. Das Team gibt > auch ein Commitment ab, dass die geplanten Issues im Sprint umgesetzt > werden LOL. Daher werden von Sprint zu Sprint die Aufgaben immer kleinteiliger. Zum Schluss wird für jede Zeile die programmiert weden soll eine user story geschrieben. Das steigert die vom Management wahrgenommene Velocity ungemein, obwohl sie real zusammenbricht. Du gehörst eindeutig zu denen, die von Scrum nicht den leisesten Schimmer haben.
:
Bearbeitet durch User
Crazy H. schrieb: > 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. Nun ja. Die Entscheidungsgewalt hast du, und entscheiden kannst du, dir einen neuen Job zu suchen. Oliver
Oliver S. schrieb: > Nun ja. Die Entscheidungsgewalt hast du, und entscheiden kannst du, dir > einen neuen Job zu suchen. Oder es entscheidet ein anderer für ihn :-) Es ist in der aktuellen Lage und dem Hype, der immer noch um Scum gemacht wird, nicht angezeigt, dies oder andere angeblich "agile" Methoden offen zu kritisieren. Da ist man schnell der Quertreiber. Ist man dann über 35 gilt man als "alter" der nicht fähig ist, sich neuen Prozessen anzupassen. Da hilft auch das Argument nicht, dass Scrum schon 25 Jahre alt ist und man es als Methode bereits kennt, als man selber noch 25 war :-) Da helfen nur klare taktische Argumente: Im Scrum-Meeting dafür sorgen, dass alles genau protokolliert wird und die Entscheidungen nachvollziehbar sind - gfs auch mit Teammitgliednamen. Z.B. "Vorschlag Marco: SW-Modul 3 verschieben, bis genau spezifiziert. Entscheidung durch PO nötig" "Vorschlag Nils: LIB XY überarbeiten - vom Team angenommen. Hinweis Bernd: kann Doppelarbeit erfordern" Dann ist im Nachinein evident, wer Blödkram vorgeschlagen hat. Hat schon so manchem aktuellen U35 das Maul gestopft :-) Das erzieht die "agilen" Hüpfer zu mehr Zurückhaltung. Das ständige Zurückgeben an die Systemplaner erzieht diese, besser nachzudenken und macht klar, wegen wem umgebaut werden muss. Jedenfalls ist dann schon einmal klar sichtbar, wenn im Sprint 17 auffällt, dass man etwas vergessen hat, was in Sprint 11 hätte geplant werden müssen, obwohl der Bernd da einen Vorschlag gemacht hatte. Was auch hilft: Eine genaue Doku, wieviel Zeit in Planungen, Besprechung und Umsetzung sowie Redesign und Nacharbeit geflossen ist. Das zeht den Srum-Befürwortern meist schnell den Zahn. Nennt sich Project-Screening. Wird auch in manchen Firmen gemacht. Aber bitte mit objektiven Kennzahlen und nicht der Selbstbeweihräucherung des Teams, im Review dass alles super war. Nicht vergessen: 20min Scrum mit 6 Personen sind 2 Arbeitsstunden und nicht 1/3! Macht also bei einem Arbeitspreis von 140,- genau Euro 280,- am Tag!
Wir entwickeln in der Firma agil, aber nicht nach Scrum. Jedes Projekt hat einen technischen Projektleiter und einen Vertreter. Die meisten Programmierer arbeiten an mehreren Projekten, entsprechend ihrer Fähigkeiten. Die Projektleiter zerlegen Aufträge in Teilaufgaben mit Angabe der Priorität. Nur wenige davon haben einen konkreten Zieltermin. So stellen die Projektleiter stets gut gefüllte Pools voller Aufgaben (Tickets) zur Verfügung, aus denen sich die Programmierer bedienen. Hier gibt niemand ein konkretes Arbeitstempo vor. Jeder macht, wie er kann. Wenn man sich schlecht fühlt, geht man es ruhiger an. Dafür gibt man dann an anderen Tagen richtig Gas, wenn man gut drauf ist. Wir kontrollieren unsere Werke Gegenseitig, bevor etwas an die QA abgeliefert wird. Das führt auch zu gegenseitiger Beratung. Die Projektleiter beobachten den Fortschritt und greifen notfalls ein. Einmal pro Woche besprechen wir in einer Online-Konferenz (ohne Kameras) nur die Themen, die alle Entwickler betreffen. Meistens dauert das Meeting weniger als 30 Minuten. Manchmal wird es mangels Themen abgesagt. Dazwischen kommunizieren wir viel mit einem Chat-Programm. Das ist besonders Nützlich, wenn man keinen konkreten Ansprechpartner hat, wie für "Ich habe gerade aus Versehen die Customer Tabelle gelöscht, wer kann das reparieren?", oder "weiß jemand, wo die Standard-Währung gespeichert wird?".
Steve van de Grens schrieb: > Wir entwickeln in der Firma agil, Hört sich vernüftig an und entspricht weitgehend dem, was wir Anfang 2000, bevor Scrum hier eingeführt wurde, gemacht haben, als schon die Vernetzung lief und man erstmalig viel mit mails und chats gemacht hat. Allerdings ist speziell das Aufgaben-pool-Model ein wenig gefährlich, wenn zuviele Projektleiter sich um zu wenige Programmierer zanken und die wiederum sich die Lieblingsaufgaben raussuchten, dann in den Urlaub verschwanden und die unfertigen Reste den Zurückgebliebenen überließen. Da muss man aufpassen.
Bernd schrieb: > Oliver S. schrieb: >> Nun ja. Die Entscheidungsgewalt hast du, und entscheiden kannst du, dir >> einen neuen Job zu suchen. > Oder es entscheidet ein anderer für ihn :-) Es ist in der aktuellen > Lage und dem Hype, der immer noch um Scum gemacht wird, nicht angezeigt, Ein Freiberufler hat einen Vertrag und der besteht nicht aus künstlerischen Freiheiten. Und im SCRUM entscheidet das Team das miteinander arbeitet, nicht gegeneinander. > dies oder andere angeblich "agile" Methoden offen zu kritisieren. Da ist > man schnell der Quertreiber. Ja dann bleib‘ doch bei Deinem hierarchischen Leben. > Ist man dann über 35 gilt man als "alter" > der nicht fähig ist, sich neuen Prozessen anzupassen. Vorurteile überall. Im Übrigen werden in SCRUM die Regeln vom SCRUM Master durchgesetzt, das betrifft das gesamte Team, den Kunden und insbesondere die oft störenden Geldgeber. Management hat da nichts zu suchen. > Im Scrum-Meeting dafür sorgen, dass alles genau protokolliert wird und > die Entscheidungen nachvollziehbar sind - gfs auch mit In welchem Meeting? > "Vorschlag Marco: SW-Modul 3 verschieben, bis genau spezifiziert. > Entscheidung durch PO nötig" > > "Vorschlag Nils: LIB XY überarbeiten - vom Team angenommen. Hinweis > Bernd: kann Doppelarbeit erfordern" Dialoge auf Augenhöhe hast Du in jeder Methode - wenn diskutiert wird kommt nix rüber, außer „Ober-sticht-Unter“ und der ganze Rotz von Hierarchien. > Jedenfalls ist dann schon einmal klar sichtbar, wenn im Sprint 17 > auffällt, dass man etwas vergessen hat, was in Sprint 11 hätte geplant > werden müssen, obwohl der Bernd da einen Vorschlag gemacht hatte. So ein Gequatsche Liebe ich: Der Pathologe ist immer der klügste Arzt. Als wenn das ein Thema von SCRUM wäre. > Eine genaue Doku, wieviel Zeit in Planungen, Besprechung und Umsetzung > sowie Redesign und Nacharbeit geflossen ist. Aus dem gleichen Grund werden Brücken, Flughäfen usw.mit 3-fach höheren Kosten mit 8 Jahren Verspätung gebaut - weil Menschen wie Du behaupten alles berechnen und vorhersehen zu können. Und vor allem haben sie immer eins: Immer Antworten, warum das gerade so ist und wer Schuld hat. Aber nie eine Lösung und ein zufriedenes Team. > Nicht vergessen: 20min Scrum mit 6 Personen sind 2 Arbeitsstunden und > nicht 1/3! Macht also bei einem Arbeitspreis von 140,- genau Euro 280,- > am Tag! Genau richtig, im „Chef-Modus“ treffen sich alle hernach und kotzen sich aus, was der PL für‘n Arsch ist… und ich habe es ja vorher gesagt. Jeder zieht noch einen Kaffee in der Küche, dann verpissen sich alle nacheinander auf die Terrasse. Dauert mindestens eine Stunde. Aber ja, ist viel besser.
Michael B. schrieb: > Uwe D. schrieb: >> PS: >> Die öffentlichen Besteller nehmen nicht den Billigsten, sondern den >> Wirtschaftlichsten > > Träumer. Wie viele Ausschreibungen hast Du schon gemanaged? > > Uwe D. schrieb: >> Nee Du, das Team einigt sich, wer eine Aufgabe übernimmt. Das Team gibt >> auch ein Commitment ab, dass die geplanten Issues im Sprint umgesetzt >> werden > > LOL. > > Daher werden von Sprint zu Sprint die Aufgaben immer kleinteiliger. What? Die Tickets sollen ohne Abhängigkeiten an einem Tag bis maximal Sprintlänge - Tests - Rollout umgesetzt werden können, gut ist 8h pro Ticket. Dafür merkt der Kunde sehr schnell ob er das bekommt was er braucht. > Zum Schluss wird für jede Zeile die programmiert weden soll eine user > story geschrieben. Das steigert die vom Management wahrgenommene > Velocity ungemein, obwohl sie real zusammenbricht. Wie kannst Du etwas Entwickeln wenn Du nicht weißt was es leisten soll? Wird nicht der Erfolg daran gemessen, was vorher definiert und nachher getestet und freigegeben wurde? Hast Du ein Problem mit Verbinlichkeit..? > > Du gehörst eindeutig zu denen, die von Scrum nicht den leisesten > Schimmer haben. Ja, das hast Du gerade bewiesen.
Steve van de Grens schrieb: > Hier gibt niemand ein konkretes Arbeitstempo vor. Jeder macht, wie er > kann. Gematik? Oder irgend eins der anderen großartigen Projekte der öffentlichen Hand? Auf jeden Fall kommen da keine Kunden vor. Oliver
Uwe D. schrieb: > Aus dem gleichen Grund werden Brücken, Flughäfen usw.mit 3-fach höheren > Kosten mit 8 Jahren Verspätung gebaut - weil Menschen wie Du behaupten > alles berechnen und vorhersehen zu können. Du machst einen Denkfehler: Als noch nicht alles in Teams entschieden und weitergetreten wurde, wodurch dann jeder die Verantwortung auf andere schieben konnte, gab es solche Auswüchse wie BER nicht. Diese Negativbeispiele verplanter Projekt sind jügeren Datum, seit der Scrum-Mist eingeführt wurde.
Uwe D. schrieb: >> Nicht vergessen: 20min Scrum mit 6 Personen sind 2 Arbeitsstunden und >> nicht 1/3! Macht also bei einem Arbeitspreis von 140,- genau Euro 280,- >> am Tag! > Genau richtig, im „Chef-Modus“ treffen sich alle hernach Nein, im PL-Modus rede ich mit jedem einzelnen Entwickler, ohne dass die anderen dumm rumsitzen müssen. Macht 2x die Woche 5min mit jedem Einzelnen = 2x10min + 6 = 2h. Allerdings redet jeder 10min mit mir statt nur 20/6 = 3 in denen nichts rüber kommt. Man kann also die 3-fache Menge an Infos austauschen und viel mehr braucht es nicht. Ansonsten redet jeder aktiv zu jeder Zeit mit jedem, den er ansprechen muss und möchte - ohne Tagestakt und geplante Arbeitsunterbrechung. Angenehmer Nebeneffekt: Alle werden gleich behandelt, keiner drängt sich in den Vordergrund! Das Meeting bleibt entspannt und es geht nur um die Sache. Und: Die Leute sind viel offener und ehrlicher mit den Fehlern und Zeiten sowie Problemen, als in der Gruppe! Noch Fragen? Die Scrum-S....e führt nur zu einem großen Sauhaufen wo jeder sich nach vorne arbeiten und präsentieren will. Es wird wieder in den Schein investiert, um beim morgendlichen Blabla gut auszusehen und mit Ideen um sich zu schmeißen. Die Probleme bleiben aber und es muss trotzdem noch nachgesprochen werden, nur hat man eben die Scrumzeit verbummelt. Die Schwierigkeiten, die entstehen, wenn einige probieren, die Arbeit auf andere zu schieben oder eigene Fehler zz verschleiern, werden nur größer.
Bernd schrieb: > Du machst einen Denkfehler: Als noch nicht alles in Teams entschieden > und weitergetreten wurde, wodurch dann jeder die Verantwortung auf > andere schieben konnte, gab es solche Auswüchse wie BER nicht. Deswegen hatte der Kölner Dom eine Bauzeit von über 600 Jahren, wegen Scrum. Nein, im Ernst: agile Methoden (oder meinethalben Frameworks) wurden aus der Erfahrung heraus ersonnen, daß seinerzeit -- je nach Schätzung -- sechzig bis achtzig Prozent aller Softwareprojekte fehlschlugen, weil sie entweder ihren geplanten Zeitrahmen und / oder ihr geplantes Budget und / oder ihre geplante Funktionalität verfehlt haben. Außerdem waren Kunden häufig unzufrieden damit, während der zunehmend langen Planungsphasen keine Fortschritte sehen und keine Rückmeldungen geben zu können, und jede noch so kleine Änderung am Projekt oder dessen Umfang zog wieder langwierige Vertragsverhandlungen und meistens auch Erhöhungen der Budgetplanung nach sich. Wie wir in diesem Thread sehen, polarisieren agile Methoden und insbesondere auch Scrum. Dabei habe ich das Gefühl, daß die Scrum-Ablehner emotionaler an dieses Thema herangehen als die Scrum-Befürworter und jene (wie ich), denen diese Dinge weitgehend egal sind, weil sie sich um ihren Code kümmern wollen und ihre Energie nicht mit der Aufregung über Vorgehensweisen verschwenden wollen, von denen jede ihre ganz eigenen Vor- und Nachteile hat. Des Weiteren habe ich aus dieser Diskussion den Eindruck gewonnen, daß sich die Trennlinien zwischen Ablehnern und Befürwortern gewisse Gemeinsamkeiten mit der Kooperations- und Teamfähigkeiten der Diskutanten hat. Wer nicht so gerne im Team arbeitet, sondern lieber alleine und eigenverantwortlich, der wird mit agilen Methoden und insbesondere Scrum wohl nicht glücklich. Dabei hängt das aber möglicherweise auch mit den mitunter verheerenden Erfahrungen zusammen, die manche Diskutanten mit Kollegen gemacht haben. Ich habe auch das Gefühl, daß manche Teilnehmer hier nur in Extremen denken: auf der einen Seite der geniale Allrounder, der ein Projekt ganz alleine und nur mit seinem Lasten- und Pflichtenheft bewaffnet durchziehen kann, Kollegen und Teamarbeit als Störungen wahrnimmt und mitunter anscheinend auch häufig schreckliche Erfahrungen damit gemacht zu haben scheint. Auf der anderen Seite stehen dabei die Teamplayer, die mit guten Teams harmonisch zusammenarbeiten und bisweilen so komplexe Projekte bearbeiten, daß sie nicht mehr von einem noch so genialen Einzelkämpfer bewältigt werden können. Eventuell gibt es bei den Positionen, die hier im Thread geäußert werden, auch Zusammenhänge mit der Art von Projekten, die die Äußernden bearbeiten. So sind Hard- und Softwareprojekte ja unterschiedlich komplex, und je komplexer ein Projekt wird, umso eher wird ein Team zu dessen Umsetzung benötigt und dann natürlich auch eine Methode (oder meinethalben ein Framework), um dieses Team und die Arbeit sinnstiftend organisieren zu können. Die Selbstorganisation der Teams wie in agilen Methoden und Frameworks erfordert zwar zusätzliche Arbeit bei den Projektbeteiligten (die Meetings und ihre Vor- und Nachbereitung), was wiederum bei Menschen, die einfach nur ihre Aufgabe zugeteilt bekommen und sie dann möglichst ungestört abarbeiten wollen, auf (hin und wieder sogar enorm vehemente und emotionale) Ablehnung stößt. Zuletzt scheinen einige Teilnehmer sich jedoch auch mit der "Gleichmacherei" unwohl zu fühlen, die agile Methoden (und Frameworks) oft implementieren. Das untergräbt also die etablierten Hierarchien und Meritokratien, geht also mit einem zumindest teilweisen Verlust erworbener Meriten und der womöglich damit verbundenen Privilegien einher. Das gefällt vermutlich nicht jedem, der sich zu deren Erwerb derselben über Jahre hinweg engagiert hat.
Bernd schrieb: > Nein, im PL-Modus rede ich mit jedem einzelnen Entwickler, ohne dass die > anderen dumm rumsitzen müssen. Macht 2x die Woche 5min mit jedem > Einzelnen = 2x10min + 6 = 2h. Allerdings redet jeder 10min mit mir statt > nur 20/6 = 3 in denen nichts rüber kommt. > > Man kann also die 3-fache Menge an Infos austauschen und viel mehr > braucht es nicht. Ansonsten redet jeder aktiv zu jeder Zeit mit jedem, > den er ansprechen muss und möchte - ohne Tagestakt und geplante > Arbeitsunterbrechung. Oh ja, diese Vorgehensweise kenne ich und habe leider ausgesprochen schlechte Erfahrungen damit gemacht. In diesem Fall hängt nämlich alles daran, daß der Projektleiter alle verfügbaren Informationen korrekt bewertet und weitergibt. In meiner persönlichen Erfahrung hat das regelmäßig zu kleinen, mittleren und schweren Katastrophen geführt, wenn der Projektleiter eine Information nicht wichtig genug fand oder sie schlicht vergessen hatte, und am Ende ging dann häufig die große "hab ich doch gesagt"-Fingerzeigerei los und es gab deswegen manchmal sehr emotionale Riesenmeetings mit allen, in denen untersucht werden sollte, wo (oder gar: bei wem) der Informationsfluß gehakt hat. Und natürlich was das nur selten der Projektleiter. In meinen Erfahrungen war diese Vorgehensweise auch niemals nur mit einem einzigen Gespräch von nur zehn Minuten pro Entwickler erledigt. Denn wenn der Projektleiter sein Gespräch mit Entwickler A beendet und Entwickler B erklärt hat, was er mit A besprochen hatte, dann hatte Entwickler B womöglich einen Einwand, den es wieder mit A zu besprechen galt. Dasselbe geschah dann auch bei den Entwicklern C bis G, und am Ende sprang der Projektleiter in immer hektischeren Iterationen zwischen seinen Entwicklern hin und her, vergaß oder ignorierte dabei wichtige Informationen, und am Ende wurden dieselben Arbeiten zwei oder sogar viermal erledigt... also, im besten Fall. Nun, in sehr kleinen Teams von ein bis vielleicht drei Entwicklern kann das funktionieren, wenn der Projektleiter wirklich sehr, sehr gut ist. Aber ich habe schon zu viele mittelprächtige Projektleiter erlebt und vor allem auch, daß dieses Vorgehen bei vier oder mehr Entwicklern nie funktioniert hat.
Ein T. schrieb: > Nein, im Ernst: agile Methoden (oder meinethalben Frameworks) wurden aus > der Erfahrung heraus ersonnen, daß seinerzeit -- je nach Schätzung -- > sechzig bis achtzig Prozent aller Softwareprojekte fehlschlugen, weil > sie entweder ihren geplanten Zeitrahmen und / oder ihr geplantes Budget > und / oder ihre geplante Funktionalität verfehlt haben Daran hat Scrim jetzt genau was geändert ? Man kann keine Fertigstellungszeit mehr reissen weil das Ende nie vorgegeben war. Man kann keine Anforderungen mehr vergessen weil die Aufgabe nachträglich angepasst werden kann bis nichts mehr übrig ist. Was ist erlebe: Projekte dauern jetzt noch erheblich länger und es kommt deutlich weniger bei raus. Gern auch halbfertiges. Gern wird auch funktionierendes im Laufe der Entwicklung kaputtprogrammiert weil HonkB nicht versteht was HonkA gemacht hat, aber die Aufgabe zugewiesen bekam. Und das schon bei den wenigen Anwendungen, wo Scrum passt: Webentwicklung. eBay ist kaputter denn je, Chefkoch ist völlig kaputt, Kleinanzeigen wird nicht besser obwohl irgendwas regelmässig geändert wird, Reichelts Suche findet die ganze Welt, druckbar sind Warenkörbe mit 1 Artikel pro Seite, und von Zeitungsseiten reden wir gar nicht, die wollen eh nur Werbung verkaufen, der Rest ist denen scheissegal. Am Besten funktioniert noch eine Aufteilung des Gesamtprojekts in Teilbereiche pro Person, man nimmt jeweils die Person mit den höchsten Spezialkenntnissen und Interesse am Teilbereich, und jede Person hat die Verantwortung aber auch die Entscheidungsbefugnis über seinen Teilbereich. Wenn ein Teilbereich was von einem anderen will, reden die beiden halt darüber und legen das in einer Schnittstellenbeschreibung nieder.
:
Bearbeitet durch User
Ein T. schrieb: > auf der einen Seite der geniale Allrounder, der ein Projekt ganz > alleine und nur mit seinem Lasten- und Pflichtenheft bewaffnet > durchziehen kann, Die Vertreibung aus dem Paradies ist aber doch schon so lange her. Der Apfel ist gegessen und ausgeträumt... Eins sollte man bei Scrum allerdings schon beachte: es stammt aus dem Land der unbegrenzten Unmöglichkeiten, und da tickt der Arbeitsmarkt etwas anders als hier. Alles, was die dort tun, ist darauf ausgerichtet, Mitarbeiter in kürzester Zeit durch andere ersetzen zu können. Bei Kündigungsfristen von 1-2 Wochen und einer ausgeprägten "ich bin dann mal woanders"-Mentalität ist das zwingend erforderlich. Oliver
Ein T. schrieb: > Bernd schrieb: >> Du machst einen Denkfehler: Als noch nicht alles in Teams entschieden >> und weitergetreten wurde, wodurch dann jeder die Verantwortung auf >> andere schieben konnte, gab es solche Auswüchse wie BER nicht. > > Deswegen hatte der Kölner Dom eine Bauzeit von über 600 Jahren, wegen > Scrum. > > Nein, im Ernst: agile Methoden (oder meinethalben Frameworks) wurden aus > der Erfahrung heraus ersonnen, daß seinerzeit -- je nach Schätzung -- > sechzig bis achtzig Prozent aller Softwareprojekte fehlschlugen, weil > sie entweder ihren geplanten Zeitrahmen und / oder ihr geplantes Budget Sehr gute Zusammenfassung von Dir - hab nur ein Stückchen Deines Beitrages hier stehen lassen. Schlussendlich ist das Ressourcenthema essenziell, hier sorgt SCRUM durch die stärkere Verbindung im Team für höhere Chancen, dass Wissen weitergegeben/geteilt wird. Der Bedarf nach Schulungen etc. muss trotzdem an die übergeordnete Ebene gegeben werden, das löst weder Wasserfall noch Agil als Vorgehensweise auf. Hierarchische Strukturen sind nur in den Köpfen von Managern besser, das Team wird immer reaktiv arbeiten und lange nicht das Potenzial erreichen, dass es mit Vertrauen und Augenhöhe (persönliche Vorlieben/Abneigungen) schaffen kann… Michael B. schrieb: > Und das schon bei den wenigen Anwendungen, wo Scrum passt: > Webentwicklung. eBay ist kaputter denn je, Chefkoch ist völlig kaputt, > Kleinanzeigen wird nicht besser obwohl irgendwas regelmässig geändert Dann ist das DEINE Erfahrung. Es gibt z.B. einen sehr erfolgreichen Metallbauer in Süddeutschland, der u.a. mehr als 30% der Wartehäuser (der Name steht an jedem Teil lesbar dran) im öffentlichen Nahverkehr liefert - der arbeitet agil. Seit 15 Jahren Kunde… > Am Besten funktioniert noch eine Aufteilung des Gesamtprojekts in > Teilbereiche pro Person, man nimmt jeweils die Person mit den höchsten > Spezialkenntnissen und Interesse am Teilbereich, und jede Person hat die > Verantwortung aber auch die Entscheidungsbefugnis über seinen > Teilbereich. Wenn ein Teilbereich was von einem anderen will, reden die > beiden halt darüber und legen das in einer Schnittstellenbeschreibung > nieder. Das ist Deine Erfahrung. Meine auf keinen Fall, weil schnelle und/oder große Projekte i.d.R. die hierarchische Pyramide überfordert. Es sind weder Idioten noch Pfeifen: Die meisten LÜCKEN in Anforderungsdefinitionen entstehen auch nicht vorsätzlich, sondern eher, weil zu dem Zeitpunkt nicht an alles gedacht und geprüft wurde. Weiter oben hast Du ja ausgeführt, dass Du zeitsparend mit den Entwicklern redest - aber nur in dem Umfang, was Dir bekannt und bewusst ist - und natürlich immer nur aus Deiner Perspektive (Du, der Projektgott der alles weiß).
Oliver S. schrieb: > Ein T. schrieb: >> auf der einen Seite der geniale Allrounder, der ein Projekt ganz >> alleine und nur mit seinem Lasten- und Pflichtenheft bewaffnet >> durchziehen kann, > Eins sollte man bei Scrum allerdings schon beachte: es stammt aus dem > Land der unbegrenzten Unmöglichkeiten, und da tickt der Arbeitsmarkt > etwas anders als hier. Alles, was die dort tun, ist darauf ausgerichtet, > Mitarbeiter in kürzester Zeit durch andere ersetzen zu können. Das war definitiv nicht das Motiv, agil arbeiten zu wollen. Lass Deine Vorurteile weg. In öffentlichen als auch privaten Unternehmen arbeiten massenhaft Leute, die man nicht los wird, obwohl sie nicht die Leistung erbringen, die man erwarten könnte… Aber das hat nix mit SCRUM zu tun.
Uwe D. schrieb: > Es sind weder Idioten noch Pfeifen: > weil zu dem Zeitpunkt nicht an alles gedacht und geprüft wurde. Es sind also Idioten und Pfeifen die nicht an alles denken und nicht ausreichend prüfen. Danke der Bestätigung. Uwe D. schrieb: > Das ist Deine Erfahrung Richtig. ERFAHRUNG, nicht religiöses Wunschdenken. Uwe D. schrieb: > weil schnelle und/oder große Projekte i.d.R. die hierarchische Pyramide > überfordert Welche Pyramide ? Du hast offenkundig was an meiner Beschreibung nicht verstanden oder redest von irgendwas anderem. Jeder nach seiner Begabung in seinem Spezialgebiet, da gibt es auch begabte Vertriebler und begabte Organisierer, aber niemand stellt sich über den anderen. Offensichtlich kennst du nur Scheiss-Firmen.
Michael B. schrieb: > Uwe D. schrieb: >> Es sind weder Idioten noch Pfeifen: > >> weil zu dem Zeitpunkt nicht an alles gedacht und geprüft wurde. > > Es sind also Idioten und Pfeifen die nicht an alles denken und nicht > ausreichend prüfen. > > Danke der Bestätigung. Okay, wenn es möglich ist, VORHER an ALLLES zu denken und zu planen, dann ist Wasserfall gut. "ALLES" schließt auch externe Einflüsse und Erfahrungen ein, die sich während der Projektlaufzeit ergeben. Ab einer gewissen Projektkomplexität ist das sehr unwahrscheinlich. Ab wieviel Mann-Jahrzehnten ist für Dich ein Projekt "groß"?
Uwe D. schrieb: > Das war definitiv nicht das Motiv, agil arbeiten zu wollen. Lass Deine > Vorurteile weg. > > In öffentlichen als auch privaten Unternehmen arbeiten massenhaft Leute, > die man nicht los wird, obwohl sie nicht die Leistung erbringen, die man > erwarten könnte… Aber das hat nix mit SCRUM zu tun. Vielleicht liest du meinen Text noch einmal, und versuchst zu verstehen, was ich geschrieben habe. Die "Agilität" beim Personal (und das ist ausdrücklich in beide Richtungen gemeint) ist dort, wo die Methode herkommt, eine wesentlicher Vorteil gegenüber anderen Lösungen. Mit dem allwissenden Einzelkämpfer plant dort niemand, weil der eben schon morgen woanders einzelkämpfen gehen könnte. Hierzulande ist dieser Vorteil keiner, weil Uwe D. schrieb: > In öffentlichen als auch privaten Unternehmen arbeiten massenhaft Leute, > die man nicht los wird, obwohl sie nicht die Leistung erbringen, die man > erwarten könnte… Oliver
Michael B. schrieb: > Man kann keine Fertigstellungszeit mehr reissen weil das Ende nie > vorgegeben war. > Man kann keine Anforderungen mehr vergessen weil die Aufgabe > nachträglich angepasst werden kann bis nichts mehr übrig ist. Leider weiß ich nicht, was Du erfahren hast, aber es scheint einen bleibenden negativen Eindruck bei Dir hinterlassen zu haben. Meine Erfahrungen sind aber gänzlich andere -- wobei, naja, das hatte ich in meinem vorherigen Beitrag ja angedeutet: agile Methoden (oder Frameworks) passen nicht zu jedem Menschen und nicht zu jeder Aufgabenstellung gleich gut. > Am Besten funktioniert noch eine Aufteilung des Gesamtprojekts in > Teilbereiche pro Person, man nimmt jeweils die Person mit den höchsten > Spezialkenntnissen und Interesse am Teilbereich, und jede Person hat die > Verantwortung aber auch die Entscheidungsbefugnis über seinen > Teilbereich. Wenn ein Teilbereich was von einem anderen will, reden die > beiden halt darüber und legen das in einer Schnittstellenbeschreibung > nieder. Auch das entbindet die beteiligten Personen aber nicht von der Abstimmung ihrer Tätigkeiten, und genau darum geht es aus meiner Sicht bei Scrum und anderen agilen Methoden und Frameworks: um Kommunikation, und eben genau darum, Informationen zu teilen und Kommunikationsverluste zu vermeiden.
Michael B. schrieb: > Es sind also Idioten und Pfeifen die nicht an alles denken und nicht > ausreichend prüfen. Nicht jeder arbeitet in einem Umfeld, in dem ein "Hello World" schon als genialitisches Stück modernster Softwareentwicklung gilt. ;-)
Ein T. schrieb: > Auch das entbindet die beteiligten Personen aber nicht von der > Abstimmung ihrer Tätigkeiten, und genau darum geht es aus meiner Sicht > bei Scrum und anderen agilen Methoden und Frameworks: um Kommunikation, > und eben genau darum, Informationen zu teilen und Kommunikationsverluste > zu vermeiden. Der Mist ist inzw. der reinste Selbstzweck geworden. Schau dir mal das an, gerade drübergestolpert auf Heise: https://www.heise.de/blog/Mein-Scrum-ist-kaputt-126-Freundschaften-in-agilen-Teams-9604621.html Die 126. Blabla-Folge Schau dir die Profile der drei Personen an was die so treiben. Früher hätte sowas Autopolitur oder Microfaserputzlumpen aufm Kauflandparkplatz verkauft und das wäre weitaus seriöser gewesen als dieses Scrum/Agil/Kanban/Fengshui/Astrologie/Tarot/Wünschelrutengänger-Experten tum.
Ein T. schrieb: > Leider weiß ich nicht, was Du erfahren hast, Freue dich. > aber es scheint einen > bleibenden negativen Eindruck bei Dir hinterlassen zu haben. Richtig. Das schöne: ich kenne sowohl funktionierende kleine Firma als auch grosse Konzerne. Ich kenne dasselbe Projekt unter Fachleuten und unter Scrum Teams. Und das über 25 Jahre. Ich kenne erfolgreiche Entwicklung und gescheiterte Projekte. Und ich kenne die Gründe. Es ist nicht Voreingenommenheit, mit manchen Sachen hatte ich gar nichts zu tun sondern nur Einblick, sondern retrospektive Schlussfolgerung. > Meine > Erfahrungen sind aber gänzlich andere Wohl noch wenig Erfahrung.
:
Bearbeitet durch User
Uwe D. schrieb: > Die meisten LÜCKEN in > Anforderungsdefinitionen entstehen auch nicht vorsätzlich, sondern eher, > weil zu dem Zeitpunkt nicht an alles gedacht und geprüft wurde. Euer Missverständnis scheint mir, dass hierarchisch nicht das Gegenteil von "agil" ist. Der veraltete und naive Ansatz (Anforderung -> Planen -> Bauen -> Testen -> Fertig) hat für neue Dinge noch nie funktioniert. Beim Bauträger-Haus vielleicht, weil es das n-te ist. Beim Bauherren-Haus nicht, weil er seine Anforderungen zu Beginn nicht kennen kann. Bei SW erst recht nicht, weil "Bauen" 0 Euro kostet und dem Compilerlauf entspricht. Der Quellcode entspricht eher dem Bauplan als der Mauer (aber das ist ein anderes Thema, geschenkt). Agil in diesem Sinne ist heute jede SW-Entwicklung. Das Gegenteil von Hierarchie ist Anarchie. Von daher nähert sich Euer Verständnis von SW von 2 verschiedenen Seiten an: * Hirarchie = Ein Architekt (oder Team), dass alle Änderungen prüft, abwägt, priorisiert ... und ans "Fußvolk" weitergibt * Anarchie (Scrum): Alle Mitglieder teilen Anforderungen und Arbeiten unter sich auf. Bei Scrum sorgt ein Scrum-Master (oder der unfähige Chef) für das fehlende Maß an Hierachie, bei Hierarchie sorgen abstrakte Festlegungen der meisten Aspekte für das notwendige Maß an Anarchie.
Michael B. schrieb: > Ich kenne erfolgreiche Entwicklung > und gescheiterte Projekte. Und ich kenne die Gründe was waren denn die "Highlights", warum ein Projekt erfolgreich war? Was waren die "Lowlights", warum ein Projekt scheiterte? Kontest du da ein Muster identifizieren?
SCRUM ist doch nur ein kleinerer Wasserfall, passt m.E. am besten in Konzernen die weg von ihrem grossen Wasserfall wollen und Startups bei denen das nächste Ziel sonst nicht klar ist weil zu unorganisiert. In vielen Fällen wird es dann nicht richtig angewendet, typische Fehler sind zB: - Der SCRUM Master ist beim Daily SCRUM und sonstigen Meetings dabei, in der SCRUM Master Rolle, anstatt auf Augenhöhe - falls sich mitten im Sprint etwas so sehr ändert, dass das urprüngliche und vereinbarte Ziel nicht erreicht werden kann, spielt man nicht tetris mit den Tasks sondern der Sprint wird "gecancelt", neues Sprint Planning etc. Beides widerspricht direkt dem offiziellem SCRUM Handbook, das Problem ist aber das beides am Ziel vorbeigeht. Der SCRUM Master ist kein "Johnny Kontrolletti" der das Board vorliest, ungefragt Spalten festlegt/ändert (und damit den Prozess festlegt/ändert) und überall als "Typ im Hintergrund" dabei ist. Er sollte dem Team helfen sich selbst zu organisieren, SCRUM Master machen sich überflüssig wenn sie es richtig machen, Agile Coaching eben. Leider wird die Position oft nicht gut besetzt, übliche Lebensläufe sind dann "gescheiterer Entwickler" und "Teilzeit Hausmama die Erfahrung darin hat Kinder zu managen". Je nach Aufgabengebiet eignet sich Kanban oft eher oder Mischformen wie Kanplan, SCRUMPlan etc. pp., zB. wenn die Arbeit an sich eher reaktiv ist als rein planbar, hat man ja oft im "DevOps" Umfeld.
:
Bearbeitet durch User
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.