Im Endeffekt schon die Kompetenz der Leute in dem was sie tun.
Es hilft, wenn jemand etwas nicht zum ersten Mal tun soll, sondern in dem Erfahren ist was er tut. Klar, irgendwann muss man immer zum ersten Mal ran,aber nicht zu 100%.
Es hilft, die Leute nicht zu überfordern. Und dazu gehört, sie nicht neben ihrer Arbeit noch Stuss wie User Stories in lachhafter Formulierung und abstruser Vergabe von Story Points schreiben zu lassen. Der Mann ist (wasauchimmer: Programmierer, Softwaretester, Dokumentationsschreiber) und nicht Märchenerzähler.
Klar: gute Leute sind schwer zu finden und teuer zu bezahlen. Aber lieber mehr billige Leute zu nehmen löst das Problem nicht.
geniale Allrounder, der ein Projekt ganz
alleine und nur mit seinem Lasten- und Pflichtenheft bewaffnet
durchziehen kann
Langsam, langsam - hier sind schon die nächsten Denkfehler:
Allrounder (als Gegenentwurf zum Spezialisten) ist nicht zwangsläufig mit "alleine" = "nicht im Team" zu assoziieren! Gerade die Umsetzung eines Konzeptes erfolgt meistens durch Spezialisten. Nehmen wir einen Layouter, der nur PCBs macht, oder einen der nur simuliert.
Allein/Team besagt wiederum nicht, dass das an Lastenhefte geknüpft ist. Das ist ein hinreichender Schluss und auch kein Gegensatz. Sowohl der Allrounder/der Spezialist als Alleinumsetzer oder im Team brauchen irgendwelche Vorgaben. Wie man die gibt oder nennt, ist dabei erst einmal egal.
Der Knackpunkt beim Scrum ist, dass es a) ändernde Vorgaben abfangen soll und b) ein Teamwork ermöglichen soll.
Jetzt kommen wir mal zum Kernpunkt: "Selbständigkeit"
abseits der allgemeinen Diskussion um Scrum ist ein Punkt klar:
Ein Selbständiger, der allein oder in einem Team (es gibt auch in Gruippen arbeitende Selbständige - siehe "Layouter") etwas machen soll, braucht ebenso genaue Vorgaben, wie der Angestellte. Da gibt es erst einmal keinen Unterschied. Wenn die Firma keinen Werkvertrag mit definiertem Ergbenis haben will, sondern nach Zeit bezahlt, ist es auf den ersten Blick Wurscht. Dann könnte man auch mit einem Teamsystem wie Scrum arbeiten.
Es gibt aber rechtliche Randbedingungen, die definieren, was ein wirtschafltich Selbständiger ist und wie er arbeitet und diese widersprechen einer flexiblen, tageweisen Vergabe von Aufgaben und einem Teamentscheid, wer etwas tun soll. Das geht eben rechtlich nicht, auch wenn es praktisch möglich ist und gemacht wird.
Hinzu kommt, dass eben Firmen sehr gerne die Kosten dadurch kontrollieren wollen, dass sie für eine Leistung eine feste Summe zahlen. Der Selbständige arbeitet dann solange er muss und berechnet nach Werkvertrag. Das aber erfordert eine genaue Vorgabe des Ergebnisses.
Heißt für mich: Manche Aufgaben, die ein offenes Ergebnis mit offenen Kosten haben, lassen sich nicht an einen Selbständigen auslagern. Das geht dann einfach nicht.
Die Aufgaben, bei denen das möglich ist, brauchen ein trotzdem ein genaues Arbeitsziel. Wenn man nun der Ansicht ist, dass eine Aufgabe unbedingt nach Scrum gemacht werden muss, dann kann der Grund nur sein, daß es unbedingt von einer Gruppe gemacht werden muss - meinetwegen wegen der Zeit. Dann braucht das Scrumteam eben diese Definition des Aufgabenziels.
Wenn man aber der Meinung ist, dass das von einem Selbständigen gemacht werden kann, oder einer Einzelperson in der Firma, dann braucht es nur das Aufgabenziel - aber kein Scrum.
Scrum und Selbständigkeit haben also keine Überschneidung. Sie schließen sich praktisch und rechtlich aus.
Wenn ich als Projektleiter Arbeitsziele definiere, dann schiebe ich das entweder nach intern (da können die dann Scrummen, bis sie schwarz werden) oder nach extern und lasse es da machen. In beiden Fällen ist der technische Aufwand, die Ziele zu definieren, der gleiche. Bei den Selbständigen muss aber vertraglich noch was gemacht werden, was die Sache nochmal teuerer macht.
Allerdings kriege ich von denen nach meiner Erfahrung auch sehr schnell und gute Ergebnisse, während das Scrum Team viel am Diskutieren und Verteilen ist und sich die einzelnen Teilnehmer hinter der Gruppe verstecken. Alles in allem habe ich sowohl IM Scrum team als Mitglied, als auch als Projektleiter, der das Team beauftragt, keine guten Erfahrungen gemacht, als Effizienz angeht. Die Teams wechseln auch zu schnell ihre Struktur, d.h. da kündigt einer und die Aufgabe bleibt liegen, bis ein neuer gefunden ist, weil das eben auch alles Spezialisten sind.
Da ist mir der Selbständige lieber: Der muss bis zum Projektende mit im Boot bleiben und die Arbeit abgeben. Ich habe per Vertrag genau diese Person an der Angel.
Agil in diesem Sinne ist heute jede SW-Entwicklung.
Ojeoje.
SW-Entwicklung wo Anforderungen und die Wege zur Umsetzung von vornherein bekannt sind, gibt es natürlich auch heute noch, in Summe vielleicht sogar überwiegend. Vom SPS-Programmierer, der die hundertste Automation mit kleinen Abweichungen irgendwo hinzaubert bis zur Functional-Safety-Programmierung, wo dies eine Grundforderung ist.
Ich will mich auch nicht darüber erheben, doch das wird treffend mit "Programmierung" bzw. "Programmierer" bezeichnet.
Wenn bei Dir zu Projektbeginn alle SW-Anforderungen bekannt und fix sind (oder zumindest sein könnten), dann arbeitest Du vielleicht in so einer Branche oder in Automotive (also nicht in deren Vorentwicklung). Dann hast Du natürlich Recht.
Da ist mir der Selbständige lieber: Der muss bis zum Projektende mit im
Boot bleiben und die Arbeit abgeben. Ich habe per Vertrag genau diese
Person an der Angel.
Dann geht es bei Deiner Kritik an Scrum aber gar nicht an Scrum, sondern vielmehr darum, wieviel Kontrolle zu ausüben kannst. Und dann verstehe ich auch, warum Du Scrum nicht magst, denn dessen Idee ist ja gerade, daß die Teams aus Menschen bestehen, die sich selbst organisieren können.
Erstens geht es mir als PL nicht um die Art von Kontrolle der Personen und deren Abläufe, sondern um die Einhaltung der Projektzeiten und der Ziele und diese Kontrolle ist nötig und berechtigt!
Zweitens widerspricht Kontrolle aus üben nicht dem sich organisieren. Wo ist da der Widerspruch? Im Gegenteil, je besser die sich organisieren, desto besser fürs Projekt.
Soweit der erste Blick. Aber:
Aus deiner Darstellung "selber Organisieren" kann man messerschaft schlussfolgern, dass es in Srum-Teams keinen Teamleiter gibt. Den braucht es dann ja nicht, weil man sich selber einteilt.
Problem 1: Wer übt die disziplinarische Funktion aus und kann beurteilen, was jeder leistet? Wer bewertet wen? Geht das dann noch?
Problem 2: Was passiert, wenn Grüppchen entstehen, die Einzelne in die Ecke drängen? Beim Verteilen der Aufgaben gibt es immer 1-2 Deppen, die den Dreck machen dürfen. Wer verhindert das?
Problem 3:
Als Projektleiter bin ich zwar in erster Linie an Ergebnissen orientiert, bin mir aber bewusst, dass es in der Gruppe menschlich stimmen muss. Da wird es schwer, wenn sich einzelen vorne hindrängen wollen, um in der Karriere hoch zu kommen. Daher bin ich auch an einem guten Umgang und Wohlbefinden interessiert! Wer sorgt im Team dafür?
Problem 4: Wenn doch ein Teamleiter exisitert, wie verhält er sich? In welchem Verhältnis steht er zum Srum Master?
Oft genug ist der Teamleiter der ScrumMaster, der ProductOwner oder beides.
daß die Teams aus Menschen bestehen, die sich selbst organisieren
können.
... dann wäre eine Gruppe von Selbständigen auch ein Scrum-Team. Oder zumindest wäre das theoretisch in einer solchen Konstellation möglich. Soweit auch gut. Aber auch hier schlägt die Realität zu:
So funktioniert das leider nicht!
Den Selbständigen darf man nicht dem disziplinarischen Teamleiter unterordnen, denn er darf nicht in die Kunden-Orga eingebunden sein. Das wird zwar oft so gemacht, ist aber rechtlich kritisch. Musste ich schon unerfahrenen Teamleitern stecken, die die Externen mitsteuern wollten.
Man kann ihn rechtlich nur dem Scrum Master unterordnen, hat aber nichts davon, weil der keine Aufgaben verteilen soll und darüber hinaus auch sofort wieder das Problem, der Organisation untereinander: Der Selbständige darf keine Weisungen entgegennehmen, also kann das Team in seiner Gesamtheit ihm nichts zuteilen. Weder die Internen, noch andere Externe. Das wird zwar auch oft so gemacht, ist aber rechtlich noch kritischer!
Es muss also doch wieder einen geben, der für Ordnung sorgt und die Aufgabenpakete definiert. Das kann aber nur ein Projektleiter sein. Das ist rechtlich in Ordnung und funktioniert auch bei einer Gruppe von Selbständigen, hat aber mit Scrum nichts mehr zu tun, weil die weitgehend unabhängig voneinander arbeiten.
Da es sich nicht lohnt, jeden Krümel als Aufgabe auszulagern, kriegen die Selbständigen ein großes Paket von sagen wir einer 3MM-Arbeit mit 3M Zeit und klarem Ergebnis. Das geht, wenn die Aufgabe schmal genug geschnitten ist, dass die Person es leisten kann.
Das Team bekommt auch eine 3MM-Arbeit, benötigt dafür mit Orgaaufwand 4MM Zeit und macht es dann in 2x 2W-Sprints in insgesamt 4 Wochen mit 4 Personen parallel. Fein!
Ergebnis: Selbständige und Team arbeiten parallel. Der Selbständige effektiver, das Team mit hoher Geschwindigkeit > 100%. Organisiert vom PL.
Und jetzt kommt der Trick:
Man nehme kein Scrum, elimiere das viele Synchronisieren und spalte die Arbeit von vorn herein gleichmäßig und gut verteilt auf die 4 Personen auf. Ohne das Scrum-BlahBlah brauchen die Internen dann keine 4 sondern nur 3 Wochen und dann sind sie auch billiger, als der Selbständige!
Das Scrum selber verbraucht nämlich auch noch Verwaltung, (z.B. für seine eigene Berurteilung des Scrums selber).
Fazit: Mit einem guten Scrum braucht man keinen Teamleiter, aber einen Scrum-Master!
Mit einem guten Projektleiter braucht man weder Scrum, noch Teamleiter noch Scrum-Master, noch Scrum-Gurus, die Scrum-Master ausbilden und den anderen Kram drum herum!
Wenn mit ganz viel Geschick verteilt man die Aufgaben einfach parallel an 4 Selbständige! Ist immer noch sicherer und besser, als es in das große Teamchaos der Internen reinzuschmeißen und sich dann erklären zu lassen, dass dies und das nicht geht und länger dauer und Tralala ...
Es muss also doch wieder einen geben, der für Ordnung sorgt und die
Aufgabenpakete definiert. Das kann aber nur ein Projektleiter sein.
Pardon, aber mit so einem Projektleiter würden meine Teammates und ich bald damit beginnen, uns neue Arbeit zu suchen. Aber wenn Du im echten Leben so auftrittst wie hier im Forum, wärst Du bei uns schneller wieder weg, als Du "Projektleiter" sagen kannst.
Wir brauchen nämlich niemanden, der für Ordnung sorgt. Das können wir selbst. Wir brauchen auch niemanden, der uns Aufgabenpäckchen schürt. Das können wir nämlich auch selbst. Wir brauchen ganz gewiss auch niemanden, der nachschaut, ob wir brav unsere Hausaufgaben gemacht haben und uns dann Noten dafür gibt.
Was wir hin und wieder brauchen, ist Input von "der Front", also von unseren Vertrieblern und Beratern bezüglich der Bedarfe, Ideen und Wünsche unserer Kunden, und bei strategischen Themen, langfristiger Planungen und unlösbaren Konflikten auch von unserem Chef und unseren Abteilungsleitern.
Aber vielleicht hat das auch mit dem Arbeitsumfeld und der Unternehmenskultur zu tun. Ich habe das riesige Glück, dass ich mit erfahrenen und motivierten Vollprofis zusammenarbeiten darf. Dieses Glück hat sicherlich nicht jeder. Aber wer braucht einen Projektleiter um des Projektleiters willen? Nur die, mit denen man ohnehin nicht zusammenarbeiten möchte.
Es gibt ganze Firmen (oder zumindest Abteilungen darin) die bestehen nur aus (Möchtegern) Projektleitern, alle Arbeit ist ausgelagert da keiner in der Firma in der Lage ist, sie zu tun. Aber fleissig Pflichtenhefte für die Zulieferer schreiben, darin sind sie erfahren.
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.
Du verstehst den Unterschied zwischen hierarchischer Führung (=Pyramide) und SCRUM (Teamverantwortung) sehr wohl, also lass den Quatsch jedes Wort auf die Goldwaage zu legen.
Offensichtlich kennst du nur Scheiss-Firmen.
Nö, es macht halt einen Unterschied, ob ständig „von oben nach unten geschissen“ wird oder ob es Wertschätzung gibt.
Was die Projektgrößen angeht: von 500h zu Zweit bis >100.000h mit 50 Leuten alles. Und auch große Migrationen mit laufender Produktion in mehreren Zeitzonen über 3-5 Tage am Stück.
Erstens geht es mir als PL nicht um die Art von Kontrolle der Personen
Ziele und diese Kontrolle ist nötig und berechtigt!
Zweitens widerspricht Kontrolle aus üben nicht dem sich organisieren. Wo
ist da der Widerspruch?
Kontrolle heißt zu allererst nicht vertrauen.
Du hast SCRUM nicht verstanden.
Aus deiner Darstellung "selber Organisieren" kann man messerschaft
schlussfolgern, dass es in Srum-Teams keinen Teamleiter gibt. Den
braucht es dann ja nicht, weil man sich selber einteilt.
Problem 1: Wer übt die disziplinarische Funktion aus und kann
beurteilen, was jeder leistet? Wer bewertet wen? Geht das dann noch?
Disziplinarische Verantwortung spielt gar keine Rolle. Wozu sollte das gut sein?
Was heißt denn „was jeder leistet“? Bezahlt Deine Firma im Akkord pro Zeile oder Methode oder Codeblock?
Der Kunde bewertet, denn er nimmt Dir das Produktinkrement ab oder User Stories/Features/Epics oder, oder, oder.
Problem 2: Was passiert, wenn Grüppchen entstehen, die Einzelne in die
Ecke drängen? Beim Verteilen der Aufgaben gibt es immer 1-2 Deppen, die
den Dreck machen dürfen. Wer verhindert das?
In nicht ständig neu zusammengewürfelten Teams passiert das nicht, wer mobbt fliegt raus.
Und den Scheiß hast Du auch ohne SCRUM.
Problem 3:
Als Projektleiter bin ich zwar in erster Linie an Ergebnissen
orientiert, bin mir aber bewusst, dass es in der Gruppe menschlich
stimmen muss. Da wird es schwer, wenn sich einzelen vorne hindrängen
Sehe Punkt 2.
Problem 4: Wenn doch ein Teamleiter exisitert, wie verhält er sich? In
welchem Verhältnis steht er zum Srum Master?
In gar keinem. Er hat nix zu melden in Sachen Projektarbeit. Nochmal: Management hat im Team nichts verloren, außer Glückwünsche u.ä. Positives
Oft genug ist der Teamleiter der ScrumMaster, der ProductOwner oder
beides.
Dann hat die Firma SCRUM nicht verstanden. Ein guter Teamleiter oder Geschäftsführer kann auch bewusst die Rolle wechseln.
Du bist sehr Problemorientiert, Chancen kommen in Deinen Worten nicht vor - so mal als Feedback - schließlich magst Du ja die harte Ansprache.
Es muss also doch wieder einen geben, der für Ordnung sorgt und die
Aufgabenpakete definiert. Das kann aber nur ein Projektleiter sein.
Du nimmst Dich zu wichtig.
Das Team bekommt auch eine 3MM-Arbeit, benötigt dafür mit Orgaaufwand
4MM Zeit und macht es dann in 2x 2W-Sprints in insgesamt 4 Wochen mit 4
Personen parallel. Fein!
Und woher nimmst Du Deine Anforderungen und Arbeitspakete? Fallen die vom Himmel? Willst Du mir jetzt erzählen, dass die Lastenhefte Deiner Kunden 100% Abdeckung haben und so verständlich sind, dass jeder im Team das deuten kann?
Und jetzt kommt der Trick:
Man nehme kein Scrum, elimiere das viele Synchronisieren und spalte die
Arbeit von vorn herein gleichmäßig und gut verteilt auf die 4 Personen
auf.
Du redest dann wie oft mit den Leuten und verteilst welche Arbeit die wo genau beschrieben ist? Das heißt, jeder arbeitet für sich - synchronisieren ist ja unnötig.
Komplex können Deine Projekte nicht sein.
Ohne das Scrum-BlahBlah brauchen die Internen dann keine 4 sondern
nur 3 Wochen und dann sind sie auch billiger, als der Selbständige!
SCRUM hat nichts mit den Fähigkeiten Deiner Belegschaft zu tun.
Das Scrum selber verbraucht nämlich auch noch Verwaltung, (z.B. für
seine eigene Berurteilung des Scrums selber).
Wofür genau? Meinst Du eine Retrospektive? Die gibts in nicht-agilen Organisationen auch, heißt dann „Best Practice“ oder „Wissensmanagement“ oder „Aussprache beim Chef“…
Mit einem guten Projektleiter braucht man weder Scrum, noch Teamleiter
noch Scrum-Master, noch Scrum-Gurus, die Scrum-Master ausbilden und den
anderen Kram drum herum!
Der Projektleiter ist ohne Team - ja genau: nichts.
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.
Ist mir leider durchgerutscht: In welchem Facebook Post hast Du denn das gelesen? SORRY, was für‘n Schrott. Die Ausschreibungen dazu haben ganz klar klassisches Baurecht festgeschrieben, Wasserfall und den allseits bekannten Leistungsphasen.
Es gibt ganze Firmen (oder zumindest Abteilungen darin) die bestehen nur
aus (Möchtegern) Projektleitern, alle Arbeit ist ausgelagert da keiner
in der Firma in der Lage ist, sie zu tun. Aber fleissig Pflichtenhefte
für die Zulieferer schreiben, darin sind sie erfahren.
Ja, die Welt ist echt Scheiße.
Nein im Ernst. Wer schreibt denn die User Stories? In Projekten die ich mache oder machte ist mindestens der PO dabei, dazu fachkundige Leute, denn nur die wissen genau, was sie brauchen. Was die Leute meist nicht gut können, das Ganze in technische Worte zu packen (Lastenheft). Aber das sollen sie im SCRUM gar nicht, denn sie sollen beschreiben was sie brauchen und warum - in „Benutzersprache“ (umgangssprachlich), dazu die Bedingungen, was die Anforderung erfüllen muss, damit sie das Ergebnis akzeptieren.
Das es auch technische Stories/Aufgaben gibt, bleibt unbenommen.
Firmen, die die zeitlichen Abläufe nicht einfach nur den Entwicklern überlassen möchten, die allenthalben neue Ideen haben und Sachen einbauen, die niemand braucht und den Projektrahmen sprengen.
Wenn man nur die Anforderungen reinwirft und nicht kontrolliert = steuert, was davon wann realisiert wird, kann es nicht mit den zugelieferten Teilen externer Projektpartner synchronisiert werden.
Die einfache Welt, die du da zeichnest (das können wir alles selber und brauchen nur ab und zu Infos aus dem PM) das funktioniert nur für eine Software, die ihr ausschließlich selber schreibt und organisiert.
Bei einer vollständigen Geräteentwicklung müssen Mechanik, Elektronik und Software mit einander im Bunde voranschreiten und da braucht es einen engen Zeittakt und auch der Verzicht auf Module zu bestimmten Zeitpunkten, wenn die Termine nicht gehalten werden.
Das aber ist die Regel bei Softwareentwicklern: Die teilen sich die Arbeit ein und schieben die Termine.
alle Arbeit ist ausgelagert da keiner
in der Firma in der Lage ist, sie zu tun.
Es gibt Dinge die eine Firma selber nicht tun kann, wie spezielle Chips bauen, feinmechanische und optische Hardware entwickeln. Die werden im Auftrag entwickelt und das muss mit der Elektronik und der firmware aligend sein. Um diese Komponenten muss sich jemand kümmern. Das hat nichts damit zu tun, dass die eigenen Entwickler untauglich wären.
Du lebst ein einer sehr eng begrenzten Welt mit Kleinkarosicht.:-)
Und: Die Abteilungen die das liefern, müssen gesynched werden. Damit kann nicht einfach jede Abteilung die Aufgaben und Reihenfolgen definieren, auf der Basis dessen, was sie in ihren Teams lokal überblicken.
Firmen, die die zeitlichen Abläufe nicht einfach nur den Entwicklern
überlassen möchten, die allenthalben neue Ideen haben und Sachen
einbauen, die niemand braucht und den Projektrahmen sprengen.
[...]
Das aber ist die Regel bei Softwareentwicklern: Die teilen sich die
Arbeit ein und schieben die Termine.
Vielleicht gilt das für die Softwareentwickler, mit denen Du zu tun hast, aber für meine Kollegen gilt das nicht. Bei uns entwickelt niemand etwas, das nicht gebraucht wird, und wir kennen unsere Prioritäten und Deadlines. Da sich alle Beteiligten eigenverantwortlich auf die Verantwortlichkeiten, Prioritäten und Deadlines verpflichtet haben, passiert es sehr selten, daß es dabei knirscht. Nach meiner Erfahrung jedenfalls seltener als mit Projektleiter.
Beim Lesen Deiner Aussagen und Formulieren meiner Antwort ist mir aber etwas aufgefallen, nämlich, daß es ja immer solche und andere gibt. Vielleicht ist das, was Du aus Deiner Erfahrung beschreibst, nur eine Art selbsterfüllender Prophezeiung: wenn Leute, die sich nicht so gerne... kontrollieren, gängeln, bevormunden und wie unreife Kinder behandeln lassen wollen, einfach weggehen und sich ein neues Wirkungsfeld suchen, dann bleiben am Ende bei Dir nurmehr jene übrig, die Deine Führung und Anleitung brauchen.
Wenn man nur die Anforderungen reinwirft und nicht kontrolliert =
steuert, was davon wann realisiert wird, kann es nicht mit den
zugelieferten Teilen externer Projektpartner synchronisiert werden.
Die einfache Welt, die du da zeichnest (das können wir alles selber und
brauchen nur ab und zu Infos aus dem PM) das funktioniert nur für eine
Software, die ihr ausschließlich selber schreibt und organisiert.
Wir brauchen keine "Infos aus dem PM", weil es bei uns keines gibt. Aber wir tauschen uns natürlich trotzdem mit den anderen Teams aus, denn sie sind auf unsere und wir auf ihre Zuarbeit angewiesen. Dafür bietet Scrum sogar ein eigenes Format an, das Scrum of Scrums, bei denen Vertreter der Teams, und häufig auch des Kunden und externer Partner, zusammen und eigenverantwortlich für den nötigen Austausch und die Synchronisation untereinander sorgen.
Du lebst ein einer sehr eng begrenzten Welt mit Kleinkarosicht.:-)
Ich fürchte, das tun wir alle -- und womöglich auch Du. :-)
Das schließt doch nicht aus, für mehrere Kunden tätig zu sein.
Dass man für mehrere Kunden tätig ist, heißt nicht, dass man automatisch die Kriterien für Selbständigkeit erfüllt!
Eine der Stellen kann auch eine Angestelltenposition sein. Das war bei mir anfänglich der Fall
Und es kann sein, dass eine vermeintliche selbständige Tätigkeit nachher anders gewertet wird.
Darum geht es ja hier.
Jetzt eine einfache Überlegung, die auch mein derzeitiger PG verfolgt:
Da Scrum das Zusammenarbeiten von Personen organisieren soll, ist die Mitwirkung in einem Scrum-Team automatisch ein Hinweis auf einen bestehende Zusammenarbeit in einem Team und nicht auf Eigenständigkeit. Scrum ist noch kein Beleg für Unselbständigkeit, aber es deutet eher in diese Richtung. Es ist sogar mehr Hinweis auf Arbeiten in der Gruppe, als z.B. mit den anderen zusammen in einem Büro zu sitzen.
Es sind deshalb auch schon angebliche Selbständige abkassiert worden, obwohl sie nicht in der Gruppe mit anderen sassen, kaum anwesend waren, aber online eng am Team dran waren.
Ist man stattdessen als Selbständiger in einer Firma tätig und nimmt ausdrücklich nicht an Scrum teil, obwohl es das dort gibt und gelebt wird, unterstreicht es die Sonderstellung. Das Fähnchen weht also in Richtung Eigenständiges Arbeiten.
Aus den Reihen der Berater hört mal deshalb auch ganz klar die Vorgabe, am Besten nicht in Scrum mit zu wirken.
Da Scrum das Zusammenarbeiten von Personen organisieren soll, ist die
Mitwirkung in einem Scrum-Team automatisch ein Hinweis auf einen
bestehende Zusammenarbeit in einem Team und nicht auf Eigenständigkeit.
Mit Selbstständigkeit assoziiere ich, dass man sich selbst um die Finanzen, Steuern und Verträge kümmert.
Wenn ich dem Gärtner sage: "Da in dieses Beet soll der Buchsbaum, und dort außen Herum die Hecke" dann habe ich die Entscheidungen getroffen. Ist der bestellte Gärtner deswegen unselbstständig? Ich denke, das kann man so nicht sagen. Die Fachliche Ebene hat mit der formellen Selbstständigkeit nichts zu tun.
Da Scrum das Zusammenarbeiten von Personen organisieren soll, ist die
Mitwirkung in einem Scrum-Team automatisch ein Hinweis auf einen
bestehende Zusammenarbeit in einem Team und nicht auf Eigenständigkeit.
Erfreulicherweise sind Finanzbehörden gar nicht so dumm oder gierig, wie manche ihnen gerne unterstellen. Die wissen natürlich ganz genau, daß niemand ganz allein und einsam vor sich hin arbeitet.
Kleiner Hinweis meinerseits: In China und Indien arbeitet niemand mit
einem Scrumsystem. Das geht alles Top-Down. Cheffe sagt an.
"Beweis" durch Behauptung? Das mag vielleicht für billige Programmiersklaven in asiatischen Sweatshops gelten, aber unsere Kunden aus Asien arbeiten alle agil. Bei meinem niederländischen Lieblingskunden wurde kürzlich ein neuer Scrum Master aus Bangalore eingestellt, der macht das seit > 15 Jahren. Sei mir bitte nicht böse, aber meine Erfahrungen und Kenntnisse passen irgendwie überhaupt gar nicht zu Deinen Behauptungen. Hast Du seriöse Belege für Deine Behauptungen, die Du mit uns teilen möchtest? Danke.
Ein Arzt und ein Maschinenbauer/BWL Typ der eine Softwarefirma hatte die
nie ein erfolgreiches Produkt erzeugt hat.
"Ein Arzt und ein Maschinenbauer/BWL Typ"? Von wem redest Du denn da so abfällig, etwa von Ken Swaber -- der nicht nur Maschinenbau und BWL, sondern auch Informatik studiert hat? Und Jeff Sutherland ist zwar Mediziner, aber auf techniknahe Fachgebiete wie Biometrie (sic!) und Radiologie spezialisiert ist. Ich persönlich würde ja vermuten, daß jeder der beiden im Schmutz unter seinem kleinen Fingernagel mehr Erfahrung und Kompetenz hat als ein dahergelaufener "laberkopp", dessen "Beiträge" stets nur aus Neid und Mißgunst bestehen.
Mit Selbstständigkeit assoziiere ich, dass man sich selbst um die
Finanzen, Steuern und Verträge kümmert.
Das ist richtig, deckt aber nur den steuerlichen und vertraglichen Teil des Tuns ab. Aus rechtlicher Sicht nützt es dir auch wenig, wenn du das alles gemacht hast, aber aufgrund der Einstufung durch das FA oder die RV als ein rentenversicherungspglichtiger Selbständiger oder eben als Scheinselbständig eingestuft wirst.
Ich habe eine Weile in und mit Frankreich / der Schweiz gearbeitet und da ist das schnell passiert, bzw gar nicht anders gereglt, dass der "Selbständige" trotzdem in die Kassen einzahlt.
Auch in Deutschland mehren sich diese Fälle, dass im Nachhinein eine solche Einstufung erfolgt. Das hat mit einerseits geänderten Regeln, vor allem aber mit einer geänderten Auslegung zu tun. Nach einem jüngst berichteten Urteil ist es eben nicht mehr ausreichend, einmal eine Statusfeststellung gehabt zu haben, sondern die jeweils zu beurteilende Tätigkeit muss zwingend auch eine selbständige gewesen sein.
Wer wie ein Angestellter zwischen anderen Angestellten bei seinem Kunden im Büro ist, der hat schon einmal ein gewaltiges Erklärungsproblem, weil Büroarbeit auch von daheim gemacht werden kann und muss, weil ja der "Selbständige" eigene Arbeitsmittel zu benutzen hat. Und einen Internetzugang dürfte der wohl besitzen.
Was auch eine Rolle spielt: Immer mehr Quasi-Selbständige aus dem Ausland bevölkern den deutschen Arbeitsmarkt, weil sie woanders nicht landen können und sich dort nicht so einfach wie in Deutschland um die Sozialbeiträge drücken können.
Schwaber hat keinen Abschluss in Informatik/Computer Science oder ähnlichen Fächern, Sutherland auch nicht.
Schwaber sagt selbst 'tried unsuccessfully to make waterfall projects successful' also vor seinem Manifesto nie was erfolgreich umgesetzt.
Tragisch, da es nachweislich tausende erfolgreicher Softwareprodukte gibt, die ohne sein Scrum entstanden sind.
Inzwischen gibt es aber auch abertausende mit Scrum (oder an Scrum?) gescheiterte Projekte.
Religionen sind halt ein Kreuz. Ob von Jesus, Mohammed, oder Schwaber/Sutherland. Die halten sich wegen ihrer Fanbois auch wenn sie nachweislich falsch sind. Es muss halt nur was drinstehen, was gerne geglaubt wird.
Schwaber hat keinen Abschluss in Informatik/Computer Science oder
ähnlichen Fächern, Sutherland auch nicht.
Interessant. Man schreibt ja den Informatikern besondere Fähigkeiten in der Logistik zu. Wenn es da zu keinem Abschluss gereicht hat, dann muss man sich fragen, woher die logistischen Fähigkeiten der Herren kommen sollen, mit denen sie prahlen und womit sie glauben, andere beraten zu können.
Schwaber sagt selbst 'tried unsuccessfully to make waterfall projects
successful' also vor seinem Manifesto nie was erfolgreich umgesetzt.
Das ist das, was ich so vermute: Mr. Mittelmaß erklärt Mechanismen für andere Mittelmäßige.
Schwaber hat keinen Abschluss in Informatik/Computer Science oder
ähnlichen Fächern, Sutherland auch nicht.
Aus der deutschsprachigen Wikipedia: "Schwaber studierte Maschinenbau an der United States Merchant Marine Academy sowie Informatik an der University of Chicago und Betriebswirtschaftslehre an der University of California." Ich bin zu faul, nachzusehen, ob er auch einen Abschluß hat.
Nebenbei waren am Agile Manifesto aber natürlich auch etliche Informatiker beteiligt, unter ihnen auch bekannte Leute wie Kent Beck, Martin Fowler, Robert "Uncle Bob" Martin, Stephen Mellor und Ward Cunningham.
Schwaber sagt selbst 'tried unsuccessfully to make waterfall projects
successful' also vor seinem Manifesto nie was erfolgreich umgesetzt.
Du solltest an Deinem Englisch arbeiten... und besser recherchieren, denn dann hättest Du sicherlich auch den Artikel [1] mit diesen Zitat gefunden: "Ken Schwaber started his own company in 1985 after working in a corporate environment for nearly ten years. [...] At the time, roughly 45% of the projects he was working on were successful, and the rest considered somewhat a waste. People didn’t like their job, and they kept running away, trying to find anything else.
Schwaber was a waterfall enthusiast and tried to make it work, but he just couldn’t. He knew there’s a need for change in the industry. In the paper SCRUM Development Process, he wrote later explaining waterfall is a method that assumes software development is a well-understood process without any unexpected outcomes or problems. However, that is not true; software development is very unpredictable for multiple reasons."
Zu Deutsch: "Ken Schwaber gründete 1985 sein eigenes Unternehmen, nachdem er fast zehn Jahre lang in einem Konzernumfeld gearbeitet hatte. [...] Damals waren etwa 45 % der Projekte, an denen er arbeitete, erfolgreich, und der Rest galt als Zeitverschwendung. Die Leute mochten ihre Arbeit nicht und rannten immer wieder weg, um etwas anderes zu finden.
Schwaber war ein Wasserfall-Enthusiast und versuchte, es zum Laufen zu bringen, aber er schaffte es einfach nicht. Er wusste, dass in der Branche Veränderung nötig war. In dem Artikel „SCRUM Development Process“ erklärte er später, dass Wasserfall eine Methode ist, die davon ausgeht, dass Softwareentwicklung ein gut verstandener Prozess ohne unerwartete Ergebnisse oder Probleme ist. Das stimmt jedoch nicht; Softwareentwicklung ist aus mehreren Gründen sehr unvorhersehbar."
Tragisch, da es nachweislich tausende erfolgreicher Softwareprodukte
gibt, die ohne sein Scrum entstanden sind.
Na klar gibt es die, bis Ende der Neunziger war das ja die dominierende (um nicht zu sagen, die einzige) Methode in der Softwareentwicklung. Für kleine, vorhersehbare Projekte mit begrenzten Funktionsumfang -- wir etwa, sagen wir: die Steuerung einer Spül- oder Kaffeemaschine -- funktioniert der Wasserfall sicherlich auch heute noch.
Aber mit wachsender Leistung von Computern und Entwicklungswerkzeugen werden auch die Projekte komplexer und umfangreicher, hängen von immer mehr internen und externen Faktoren und Menschen ab. Das alles macht den Entwicklungsprozeß weniger vorhersehbar. Und dann wird es mit nicht-agilen Methoden schwierig, weil der Umgang mit und die Beherrschung von unvorhergesehenen Ereignissen darin üblicherweise nicht vorgesehen ist.
Inzwischen gibt es aber auch abertausende mit Scrum (oder an Scrum?)
gescheiterte Projekte.
Das hat die Standish Group anhand von Projekten aus den Jahren 2002 bis 2011 untersucht und schreibt in ihrem Chaos Report von 2011: "Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns." Übersetzt heißt das: "Softwareanwendungen, die mit dem agilen Prozess entwickelt werden, haben eine dreimal höhere Erfolgsquote als die traditionelle Wasserfallmethode und einen viel geringeren Prozentsatz an Zeit- und Kostenüberschreitungen."
Hier [2] findet Du nicht nur das Zitat, sondern auch eine hübsche Grafik dazu, wenn Dir das lieber ist.
Das mag sein. Aber hier geht es nicht um Religion, sondern um das Management von Projekten -- und übrigens nicht nur von Softwareprojekten, ganz am Rande bemerkt. Agile Projekte funktionieren nachweislich besser als Dein geliebter Wasserfall, auch wenn Dir das nicht gefällt oder Du es nicht verstehst. Mein Ratschlag wäre, Dich daran zu gewöhnen, denn ich befürchte, daß die Realität wenig Rücksicht auf Deine Befindlichkeiten nehmen wird... und wir wissen ja: wer nicht mit der Zeit geht, wird mit der Zeit gegangen. :-)
Na klar gibt es die, bis Ende der Neunziger war das ja die dominierende
(um nicht zu sagen, die einzige) Methode in der Softwareentwicklung. Für
kleine, vorhersehbare Projekte mit begrenzten Funktionsumfang -- wir
etwa, sagen wir: die Steuerung einer Spül- oder Kaffeemaschine --
funktioniert der Wasserfall sicherlich auch heute noch.
Softwareprojekte waren früher eher größer als heute. Und Wasserfall hat einen sehr engen Anwendungsbereich, z.B. Funktionale Sicherheit. Für innovative SW hat es noch nie funktioniert. Das ist ein Mythos. Wie jener, nach dem man früher Nassi-Shneydermann-Diagramme gemacht habe, bevor man losprogrammierte. 99.9% wurden nachträglich erstellt.
Nebenbei waren am Agile Manifesto aber natürlich auch etliche
Informatiker beteiligt, unter ihnen auch bekannte Leute wie Kent Beck,
Martin Fowler, Robert "Uncle Bob" Martin, Stephen Mellor und Ward
Cunningham.
Das ändert alles nichts daran, daß es vor 30 Jahren erdacht wurde - also zu einem Zeitpunkt, als es an Universitäten kaum organisierte Informatikausbildung gab.
Das hat sich heute gewaltig geändert.
Die Ideen, da dahinter standen, um einen großen Haufen Programmierer zu organisieren, sind total obsolet. Die aufgaben des Entwicklers sind auch heute völlig andere: Der Aufwand fürs Codieren ist gesunken, es stehen Planungs- und Organisationshilfen in elektronischer Form zur Verfügung.
Die Ideen, da dahinter standen, um einen großen Haufen Programmierer zu
organisieren, sind total obsolet. Die aufgaben des Entwicklers sind auch
heute völlig andere: Der Aufwand fürs Codieren ist gesunken, es stehen
Planungs- und Organisationshilfen in elektronischer Form zur Verfügung.
Diese Werkzeuge können aber den direkten interaktiven Kontakt zwischen den Beteiligten nicht ersetzen -- und ergänzen darüber hinaus natürlich auch das Repertoire der agilen Methoden.
Viele Gründe für SCRUM sind längst weggefallen.
An Deinen Aussagen hier [1] sehe ich schon, was für ein angenehmer Zeitgenosse und Lieferant Du bist. Da ist es nur logisch, warum agile Methoden nichts für Dich sind -- und wie kompetent und objektiv Dein Urteil darüber ist.
Nebenbei waren am Agile Manifesto aber natürlich auch etliche
Informatiker beteiligt, unter ihnen auch bekannte Leute wie Kent Beck,
Martin Fowler, Robert "Uncle Bob" Martin, Stephen Mellor und Ward
Cunningham.
Die Tatsache, dass an der Entwicklung mehrere bekannte Personen beteiligt sind, bürgt nicht unbedingt für Qualität, weil es immer Kompromisse sind, die da heraus kommen.
Entscheident für mich ist, dass es Erfahrungen sind, welche der Personenkreis mit deren Projekten in deren Ländern mit deren Mitarbeitern und der damals vorliegenden Ausbildung und Organisation hatten.
Das lässt sich keineswegs uneingeschränkt auf heutige Prozessem heutige Personen und heutige Firmen übertragen, die hier ansässig sind.
Selbständige in Europa und Deutschland haben auch mit den Selbständigen in den USA, Japan und anderen Ländern nichts zu tun. Sie haben nicht einmal etwas mit den Selbständigen und deren Arbeitsweisen in Frankreich zu tun.
Deshalb finde ich es abschließend sehr suspekt, dass Scum für alles und jenes in Deutschland eingeführt wird und zu bewerten, was bisher vorlag und wie es funktionierte. Aber wir haben uns ja daran gewöhnt, dass alles was aus den USA kommt, pauschal als super eingestuft und übernommen wird.
Auch in Deutschland mehren sich diese Fälle, dass im Nachhinein eine
solche Einstufung erfolgt.
Mein derzeitiger Projektgeber sieht sich genau mit solchen Vorwürfen kontrontiert. Bei einer Betriebsprüfung kam heraus, dass gleich mehrere Selbständige permanent und dauerhaft inhouse tätig waren und an Scrum Meetings teilgenommen hatten - zusammen mit dem restlichen Team.
Jetzt steht die Frage im Raum, was die Arbeitsweise dieser Selbständigen von der der Angestellten überhaupt noch unterscheidet und inwieweit sie real selbständig waren.
Sich allein "selbständig" zu nennen und noch irgendwo ein angebliches Büro zu haben, reicht da nicht aus. Besonders ist es jetzt ein Problem, dass die Firma Notebooks ausgegeben hatte.
Ich bin super raus, weil ich praktisch nur von daheim aus arbeite und nur eigene Arbeitsmittel benutze.
Selbständige in Europa und Deutschland haben auch mit den Selbständigen
in den USA, Japan und anderen Ländern nichts zu tun. Sie haben nicht
einmal etwas mit den Selbständigen und deren Arbeitsweisen in Frankreich
zu tun.
Also kurz gesagt: kommt aus Amiland und ist hier nicht anwendbar. Widerspricht zwar meinen Erfahrungen im und mit dem Ausland, aber... ach, egal, glaub' doch einfach, was Du willst.
Schön, das solche Sozialdienst hoch genommen werden. Selbständig und
Abrechnung auf Stundenbasis schließen sich halt aus.
Das nicht unbedingt: Jeder selbstständige Handwerker und beratende Ingenieur stellt Rechnungen auf Stundenbasis. Auch Gutachter, Autoren und Musiker tun das.
Es kommt auf die tatsächliche Tätigkeit an. Ist sie fachlich alleine zu leisten? Arbeitet derjenige eng mit den fest Angestellten zusammen? Rechnet er auf eigenes Risiko ab?
Sobald die Tätigkeit in die Infrastruktur der Firma "eingebettet" ist, wird es problematisch und bei Scrum ist eben ganz genau das nicht nur der Fall, sondern ausdrücklich Programm: Bei Scrum soll ein Team (und nicht eine Einzelperson) eine Leistung erbringen und sich dabei möglichst selbst managen.
Das ist keine Selbstständigkeit. Auch ein Team mit / aus Selbständigen löst das Problem nicht. Es ist nur heuete normal geworden, was seine Gründe aber in wirtschaftlichen Gesichtspunkten und nicht etwas technischen Anforderungen hat:
Beitrag "Re: Freiberuflichkeit, Stundenlohn, Haftung etc."
Das Einzige, was wirklich sauber und sachlich und fachlich korrekt ist, ist eine Auftragsvergabe mit einem klar umrissenen Ziel durch einen Projektgeber, das der Auftragnehmende (Allein oder eine Gruppe) dann intern bearbeiten. Mehrere Selbständige sind dann kein Problem, wenn sie sich zu einer GbR zusammengegeschlossen haben.
Der Projektleiter sitzt dann als ein Teammitglied mit den Teamleitern in den übergeordneten ORGA-Meetings und koordiniert den Stand. Die Teamleiter geben ihre Aufgabenpakete an ihre SCRUM-Teams, der PL die Pakete an die Externen.
Als externer PL beauftrage ich einen Selbständigen mit der Erstellung eines Gerätekonzepts. Er verfasst einen HW- und SW-Entwicklungsplan, Blockschaltbilder für die Elektronik und die Software. Dauer 6 Wochen, ein Auftrag, Abrechung auf Stundenbasis, kontinuierliche Entwicklung mittels internem Dokumentensystem. Ich kann genau verfolgen, wie der Stand ist, was er tut und ziehe die Infos ins Scrum-Meeting.
Wenn es da irgendwelche Änderungen und Wünsche gibt -> Änderungsauftrag per mail mit Liste als Req-Change. Als Antwort bekomme ich eine Zeitabschätzung, dann kommt die Freigabe. Sonst redet ihm da keiner rein. Er sitzt nicht bei uns, nutzt einen eigenen PC und hat nur eine mail-Adresse mit dem Zugang zum Dokusystem. Keine Teilnahme an Scrum nötig. Rechnung alle 2 Wochen.
Alles paletti - hielt auch einer Betriebsprüfung stand.
"Der Product Owner vertritt die Interessen des Kunden. Er ist der
Auftraggeber und möglicherweise auch der Kunde selbst. "
Einfach mal denken!
"Auftraggeber" ist in deinem Satz derjenige, der das Scrum-Team beauftragt und nicht der, der das Endprodukt haben will. Was sich großkotzig PO nennt ist nicht anderes als ein Mittler und Anforderungsverwalter, aber nicht der, der es am Ende bezahlt.
Und "Endkunden" sitzen ganz sicher nicht in einem Scrum-Team. Die sitzen nicht einmal in der Firma.
Der PO ist am Ende einfach der Software-PL oder Integrationmanager, die die SW haben will.
Oh ha, so unter Missachtung der reinen Lehre wird das bei dir mit Scrum nie was.
Natürlich kann der Auftraggeber aus deiner Firma sein - bei InHouse Entwicklungen.
Wenn du aber für einen externen Endkunden was mit Scrum entwickelst und der NICHT einen Vertreter im Scrum Prozess hat sondern die Firma, also euch, mal machen lässt, dann muss es eine Auftragsbeschreibung, ein Lastenheft geben und gegen das wird zum Schluss verglichen ob der Auftrag erfüllt wurde und bezahlt wird oder eben nicht. Damit macht ihr aber alles andere als agil sondern ein V-Modell.
Man kann alles machen - aber wenn du es Scrum nennst sollte Scrum drin sein. Nicht das was du denkst.
SCRUM ist gut für Gezänke. Ich liebe es diesem Zirkus immer wieder zuzuschauen, wie im Kindergarten.
"Nein Scrum muss so gemacht werden", "nein so, ihr habt kein Ahnung!". "Nein der Projektowner macht x", "Nein genau das macht der nicht! Ich weiss das genau, ich habe nen Wochendkurs zum Scrummaster gemacht!" "Ja aber letzte Woche hast du noch bei McDonalds gearbeitet" mähmähmäh...
"Nein Scrum muss so gemacht werden", "nein so, ihr habt kein Ahnung!".
Genau das ist es, was ich seit 20 Jahren sehe: Jede Firma macht es anders und als Folge passt es schon unter den Angetellten nirgends so richtig zusammen.
ich habe nen Wochendkurs zum Scrummaster gemacht!
Auch das ist mein großes Problem mit Scrum: Eine Methode, die so simpel ist, dass man sie in wenigen Stunden erlernen und an ein Team per Schulung weiterkommunizieren kann, ist definitiv nicht komplex genug, um die Notwendigkeiten heutiger Entwicklungen von Systemen aus HW und SW sinnvoll abzubilden. Die einzelnen Stränge sind dabei auch viel zu unterschiedlich, als dass man eine Methode, die einst für dynamisches SW-Entwickeln erdacht wurde, darauf abbilden könnte. Ich habe schon ein paar mal die hilflosen Versuche mitansehen dürfen, einen PCB-Entwicklungsprozess mitsamt Mechanik einem Scrum zu unterwerfen und es dann mit der SW zu verheiraten. Nichts hat da gepasst und es mussten ständig Schleifen gedreht werden.
... und schon gar nicht kann eine einzelne Personen einen PO abgeben, der ein größeres System überschaut oder planen kann. Das geht maximal für kleine Moduln und Komponenten. Die Vorgaben für Systemkomponenten und deren Funktion in größeren Geräten kommen heute von mehreren Quellen gleichzeitig und umfassen funktionstechnische, marketingtechnische und rechtliche Themen, die von Spezialisten bearbeitet werden. Schon diese Gruppe sprengt typischerweise die ideale Größe eine Scrum-Teams und soweit sie sich scrum-ähnlich als team verhalten und abstimmen, um gemeinsame Lösungen zu schaffen, haben sie das schon lange vorher so getan. Um gemeinsam ein System zu entwerfen, ist ein gemeinschaftlich organisierter Prozess definitiv von Nöten - allerdings braucht da niemand festgelegte Sprintlängen.
Als Konsequenz muss man klar die Schlussfolgerung ziehen, dass ein Scrum-Team maximal so groß sein darf, dass die Breite des bearbeiteten Themas die fachlich Kompetenz des PO nicht übersteigt. D.h. es muss für jede wesentliche Komponente einen eigenen PO geben, der "seinem" Team die Untervorgaben macht und für inhaltliche sowie zeitliche Konsistenz mit der Entwicklung der anderen, konkurrenten Komponenten sorgt. Allein schon vom Verwaltungsaufwand her, können das dann kaum mehr als 5 Leute sein. Solche Betrachungen exisitieren ja bereits in Hülle und Fülle, die ideale Teamgrößen aufzeigen.
Unter Berücksichtigung der rechtlichen Definitionen für "Selbständigkeit" gibt es dann eben einen Projektleiter, der bezüglich einer Komponente als PO fungiert und diese nicht an ein Team, sondern an eine Firma oder eben einen Selbständigen weiterleitet und diesen "trackt". Wenn man jetzt weiterdenkt, könnte man sich auch 2 Selbständige vorstellen, die als ein Team an einem Auftrag arbeiten, nur die Anforderungen nehmen und sich dann untereinander abstimmen, quasi wieder als Scrum-Truppe.
Von daher sehe ich da erst einmal kein grundsätzliches Problem, in einer Firma tätig zu werden, die Scrum betreibt: Ich suche nur ständig nach den wirklichen Unterschieden zu den Firmen, die formell kein Scrum betreiben, denn die Aufspaltung in Teams mit einem "Leiter" sowie die Weiterbeauftragung an sich selbst organisierende Externe hatten wir ja schon immer.
Der einzige richtige und nennenswerte Unterschied, den ich bisher ausmachen konnte, der auch relevante Auswirkung zeigt, ist der Sachverhalt, dass man an den Aufgaben und Inhalten der Tasks, die zu Sprintbeginn festgelegt wurden, mittendrin praktisch nichts ändern kann und darf. Das ist für den Entwickler natürlich sehr vorteilhaft ist, um ad hoc Aufgaben von irgendwoher abzuwehren. Allerdings ist damit ein wesentliches Umsteuern im Grunde nur im 2W-Takt möglich. Inwieweit das agiler sein soll, als eine Abstimmung ohne Zeitskala bei Bedarf und sofortige Reaktion auf Anforderungen durch einen AG, müsste man mir dann nochmal erklären.
