Announcement: there is an English version of this forum on Wegstaben V. schrieb: > Kontest du da ein Muster identifizieren? 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. Bruno V. schrieb: > Der veraltete und naive Ansatz Oje. Bruno V. schrieb: > Agil in diesem Sinne ist heute jede SW-Entwicklung. Ojeoje. Bruno V. schrieb: > Das Gegenteil von Hierarchie ist Anarchie Ojeojeoje. Du wirst eines Tages noch ganz gross rauskommen mit deinem Geschwärz.
Ein T. schrieb: > 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: 1. 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. 2. 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.
Michael B. schrieb: > Bruno V. schrieb: >> Der veraltete und naive Ansatz > > Oje. > > Bruno V. schrieb: >> 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.
Michael B. schrieb: > Ein T. schrieb: >> Meine Erfahrungen sind aber gänzlich andere > > Wohl noch wenig Erfahrung. Dreißig Jahre Berufserfahrung sind wenig, aber ich bin ja auch erst 52. :-)
Bernd schrieb: > 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. Dann gibt es Hickhack!
Und noch eine Schlussfolgerung: Wenn die idee die ist, ... > 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 ... Scrum funktioniert nur in der Theorie!
Bernd schrieb: > 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.
Sheeva P. schrieb: > Aber wer braucht einen Projektleiter 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.
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. Lies es noch einmal: *Es sind weder Idioten noch Pfeifen:* > Uwe D. schrieb: >> Das ist Deine Erfahrung > > Richtig. > > ERFAHRUNG, nicht religiöses Wunschdenken. Ja, aber nicht meine. Was Du machst ist DEUTEN. > 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. 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.
Bernd schrieb: > 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. > Scrum funktioniert nur in der Theorie! Für Dich stimmt das absolut.
:
Bearbeitet durch User
Bernd schrieb: > 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. 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. Und schon vor ca. 150 Jahren lagen erfahrene Ingenieure ordentlich daneben - ganz ohne Feinbild SCRUM. siehe hier —> https://de.wikipedia.org/wiki/Eiffelturm
Michael B. schrieb: > Sheeva P. schrieb: >> Aber wer braucht einen Projektleiter > > 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.
:
Bearbeitet durch User
Sheeva P. schrieb: > Aber wer braucht einen Projektleiter 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. Uwe D. schrieb: > Der Kunde bewertet, denn er nimmt Dir das Produktinkrement ab richtig und der Kunde der Abteilungen bin ich. Michael B. schrieb: > 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.
Bernd schrieb: > Sheeva P. schrieb: >> Aber wer braucht einen Projektleiter > > 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. :-)
Stefan F. schrieb: > 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.
Uwe D. schrieb: > Du verstehst den Unterschied zwischen hierarchischer Führung (=Pyramide) > und SCRUM (Teamverantwortung) Kleiner Hinweis meinerseits: In China und Indien arbeitet niemand mit einem Scrumsystem. Das geht alles Top-Down. Cheffe sagt an. Und das ist (leider) verdammt schnell und erfolgreich. Es gibt für alles 3-5 Firmen und dort wo es läuft, wird gekauft. Dauerstress und Belastung pur. Während hier einige in meetings die Eier schaukeln, rennen und die Chinesen davon. Die Japaner haben sie schon abgehängt. Wer hat eigentlich Scrum erfunden?
Martin K. schrieb: > 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. Liege ich da etwa falsch?
:
Bearbeitet durch User
Andi schrieb: > Wer hat eigentlich Scrum erfunden? Ein Arzt und ein Maschinenbauer/BWL Typ der eine Softwarefirma hatte die nie ein erfolgreiches Produkt erzeugt hat. Dafür verdienen sie sich seit dem mit Beratung wir man es angeblich besser macht eine goldene Nase.
Martin K. schrieb: > 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.
Andi schrieb: > 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.
Michael B. schrieb: > Andi schrieb: >> Wer hat eigentlich Scrum erfunden? > > 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.
Monk schrieb: > 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. Die Frage ist, wie lange das noch so bleibt!
Ein T. schrieb: > Ich persönlich würde ja vermuten, Ein Leben aus Vermutungen. 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.
:
Bearbeitet durch User
Michael B. schrieb: > Ein Arzt und ein Maschinenbauer/BWL Typ der eine Softwarefirma hatte die > nie ein erfolgreiches Produkt erzeugt hat. In solchen Fällen bleibt ja auch nichts anderes, als Berater zu werden :-) Michael B. schrieb: > 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.
Michael B. schrieb: > 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." [1] https://www.scrumdesk.com/the-history-of-scrum-how-when-and-why/ > 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. [2] https://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall > Religionen sind halt ein Kreuz. 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. :-)
Ein T. schrieb: > 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.
Ein T. schrieb: > 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. Viele Gründe für SCRUM sind längst weggefallen.
Andi schrieb: > 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. [1] Beitrag "Re: Crowdstrike! Nun sind alle dran, Abstürze ohne Ende"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.