Forum: Ausbildung, Studium & Beruf SCRUM und die Arbeitsweise von Selbständigen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Olli Polli (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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?

von Olli Polli (Gast)


Lesenswert?

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.
von Opferanode für Teamstimmung (Gast)


Lesenswert?

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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.
von Opferanode für Teamstimmung (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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
von Hmmm (Gast)


Lesenswert?

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

von Uwe D. (monkye)


Lesenswert?

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….

von Peter A. (Gast)


Lesenswert?

Wer sich diesen SCRUM Rotz als selbstständiger freiwillig antut ist echt 
nicht zu retten.

Beitrag #7321783 wurde von einem Moderator gelöscht.
von Da Baby (Gast)


Lesenswert?

Wer sich als Ingenieur mit sowas befasst hat die Kontrolle längst 
verloren

Beitrag #7322131 wurde von einem Moderator gelöscht.
von Genervter (Gast)


Lesenswert?

Ich danke Gott, dass ich nicht mehr als Informatiker arbeiten muss.

von Uwe D. (monkye)


Lesenswert?

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.

von Peter A. (Gast)


Lesenswert?

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.
von Kindergärtner (Gast)


Angehängte Dateien:

Lesenswert?

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

von Peter A. (Gast)


Lesenswert?

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.

von Kindergärtner (Gast)


Lesenswert?

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"

von Peter A. (Gast)


Lesenswert?

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.

von Selbständiger (Gast)


Lesenswert?

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.

von T.U.Darmstadt (Gast)


Lesenswert?

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"

von Uwe D. (monkye)


Lesenswert?

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.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

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?"

von A. B. (funky)


Lesenswert?

und was hat das mit SCRUM zu tun? Genau. Nix!

von Bruno V. (bruno_v)


Lesenswert?

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.

von Herbert B. (Gast)


Lesenswert?

Wer als Freelancer diesen Scrumdreck mitmachen muss hat die Kontrolle 
über seinen Job verloren.

von Uwe D. (monkye)


Lesenswert?

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…

von Herbert B. (Gast)


Lesenswert?

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.

von Purzel H. (hacky)


Lesenswert?

Was soll das Gezerre. Wenn man's als Freiberufler abgegolten bekommt 
macht man's sonst eben nicht.

von Uwe D. (monkye)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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.

von He. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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
von He. (Gast)


Lesenswert?

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?

von Uwe D. (monkye)


Lesenswert?

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)"

von He. (Gast)


Lesenswert?

Aha! Gibt es auch Treffen, die mehr in der Mitte Deutschlands liegen und 
nicht an der polnischen Grenze?

von Herbert B. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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
von Bruno V. (bruno_v)


Lesenswert?

Wie wäre es mit Ruhrgebiet?

Z.B. ein Biergarten fußläufig von einem der großen Bahnhöfe Duisburg, 
Essen, Bochum, Dortmund.

von Achim H. (anymouse)


Lesenswert?

Bruno V. schrieb:
> Wie wäre es mit Ruhrgebiet?
(-1 von mir wg. Off-Topic in diesem Thread)

von Bruno V. (bruno_v)


Lesenswert?

Achim H. schrieb:
> (-1 von mir wg. Off-Topic in diesem Thread)

Uups, sorry, natürlich völlig zurecht

von Mann Fred (Gast)


Lesenswert?

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"!

von Uwe D. (monkye)


Lesenswert?

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.

von Mann Fred (Gast)


Lesenswert?

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.
von Reinhard S. (rezz)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Herbert B. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Herbert B. schrieb:
> Dann sucht ihr euch die falschen Kunden raus.

Keineswegs. Wir füllen diese Marktlücke und werden dafür gut bezahlt.

von Herbert B. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Herbert B. schrieb:
> Das "gut bezahlt" ist wohl eher Schmerzensgeld

Nicht jede Firma besteht aus Weicheiern.

von Klaus (feelfree)


Lesenswert?

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
von Reinhard S. (rezz)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von Klaus (feelfree)


Lesenswert?

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?

von Reinhard S. (rezz)


Lesenswert?

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?

von Klaus (feelfree)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Reinhard S. (rezz)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von Mann Fred (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.
von Herbert B. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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!

von J. S. (engineer) Benutzerseite


Lesenswert?

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? ;-)

von Uwe D. (monkye)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Herbert B. (Gast)


Lesenswert?

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.

von Mann Fred (Gast)


Lesenswert?

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.

von Some O. (some_one)


Lesenswert?

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.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

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:

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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! :-)

von Bruno V. (bruno_v)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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
von Uwe D. (monkye)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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/

von Mann Fred (Gast)


Lesenswert?

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.
*************************************************************

von Uwe D. (monkye)


Lesenswert?

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?

von Mann Fred (Gast)


Lesenswert?

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.

von Achim H. (anymouse)


Lesenswert?

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.

von Mann Fred (Gast)


Lesenswert?

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?

von Sheeva P. (sheevaplug)


Lesenswert?

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

von Mann Fred (Gast)


Lesenswert?

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. :-)

von Achim H. (anymouse)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

Achim H. schrieb:
> Selbstständigen Freiberuflern

Es gibt keine nicht selbständigen Freiberufler. Und für Profis heißt es 
selbständig.

von Achim H. (anymouse)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Mann Fred (Gast)


Lesenswert?

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!

von Uwe D. (monkye)


Lesenswert?

Sinnlos.

: Bearbeitet durch User
von J. S. (engineer) Benutzerseite


Lesenswert?

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?

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

Schon spannend, wie einige hier die Planwirtschaft verteidigen, obwohl 
klar ist, das die an einer bestimmten Größe scheitert.

von Uwe D. (monkye)


Lesenswert?

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…

von Michael S. (mal-s)


Lesenswert?

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
von Mann Fred (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Martin M. (mcmaier)


Lesenswert?

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 ;-)

von Ein T. (ein_typ)


Lesenswert?

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

von Mann Fred (Gast)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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!

von Mann Fred (Gast)


Lesenswert?

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.

von Crazy Harry (crazy_h)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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
von Mann Fred (Gast)


Lesenswert?

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" ...

von Mann Fred (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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“.

von Mann Fred (Gast)


Lesenswert?

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.

von Crazy Harry (crazy_h)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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
von Mann Fred (Gast)


Lesenswert?

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.

von Crazy Harry (crazy_h)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Bernd G. (Gast)


Lesenswert?

SCRUM betrifft höchstens Scheinselbstständige. Echte Selbstständige 
lachen darüber.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

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 ;-)

von Uwe D. (monkye)


Lesenswert?

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
von Andi (chefdesigner)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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.

von Crazy Harry (crazy_h)


Lesenswert?

Ich hab nichts gegen SCRUM, aber es behindert mich mehr, als daß es was 
bringt. Siehe Erläuterung oben.

von Uwe D. (monkye)


Lesenswert?

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
von Andi (chefdesigner)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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.

von Achim H. (anymouse)


Lesenswert?

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
von Bernd G. (Gast)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.“

von Andi (chefdesigner)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Klaus (feelfree)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.)

von Re D. (Gast)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Papa Schlumpf (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Papa Schlumpf (Gast)


Lesenswert?

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.

von Andi (chefdesigner)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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?

von Andi (chefdesigner)


Lesenswert?

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.

von Bernd G. (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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
von Oliver S. (oliverso)


Lesenswert?

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

von Bernd G. (Gast)


Lesenswert?

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!

von Monk (roehrmond)


Lesenswert?

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?".

von Bernd G. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Bernd G. (Gast)


Lesenswert?

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.

von Bernd G. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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
von Oliver S. (oliverso)


Lesenswert?

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

von Uwe D. (monkye)


Lesenswert?

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ß).

von Uwe D. (monkye)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von Achim H. (anymouse)


Lesenswert?

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ß"?

von Oliver S. (oliverso)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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. ;-)

von Franko S. (frank_s866)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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
von Bruno V. (bruno_v)


Lesenswert?

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.

von Wegstaben V. (wegstabenverbuchsler)


Lesenswert?

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?

von Mladen G. (mgira)


Lesenswert?

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
Bitte 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
Noch kein Account? Hier anmelden.