Announcement: there is an English version of this forum on Uwe D. schrieb: > Nachtrag: Das Beispiel https://de.wikipedia.org/wiki/Eiffelturm hatte > ich schon einmal gebracht - lange vor SCRUM und Co. - und trotzdem > 2,5-fach über dem Planbudget… Das ist für heutige Großbauprojekte ja schon lächerlich günstig. :-)
Hallo Uwe, Nett von Dir zu hören und Deine Gedanken zum Thema zu lesen. Ja. Unser Meeting hat mir auch gefallen. Müssen wir wieder machen. Grüße, Gerhard
Steve van de Grens schrieb: > Gerhard O. schrieb: >> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? > > Dazu muss der Auftraggeber wissen, was er braucht. In der Praxis weiß er > es oft nicht, speziell bei komplexen Projekten. Na zumindest auf dem Top-Level weiß der Auftraggeber durchaus sehr wohl, was er braucht. Zum Beispiel: -eine Steuerung für eine Maschine, die 1000 Eisenteile pro Tag biegt -einen Zug, der 500 Passagiere befördert und mindestens 200 km/h fährt -ein Gebäude mit 300 Mietwohnungen à so-und-soviel Quadratmetern Unterhalb des Top-Levels wird es dann schwieriger. Da bräuchte es fähige Leute, die zum Kunden gehen und die Branche verstehen um die es geht. Mit einem guten Verständnis von den Besonderheiten und technischen Bestimmungen der jeweiligen Branche. These: SCRUM existiert vor allem deshalb, weil Vertriebler hauptsächlich nach "kann gut verkaufen" eingestellt werden, nicht nach "versteht tatsächlich die Probleme des Kunden, weil er einfach Ahnung von der Materie hat". Das ist nur halb ironisch gemeint - ich denke, da ist durchaus was Wahres dran.
:
Bearbeitet durch User
Mark B. schrieb: > Uwe D. schrieb: >> Nachtrag: Das Beispiel https://de.wikipedia.org/wiki/Eiffelturm hatte >> ich schon einmal gebracht - lange vor SCRUM und Co. - und trotzdem >> 2,5-fach über dem Planbudget… > > Das ist für heutige Großbauprojekte ja schon lächerlich günstig. :-) Das ist das Hauptsächliche: Löse das Dilemma. Ähnlich ist es bei Projekten wie: Stuttgart 21. Wieviele Bahnhöfe sind denn schon in der Dimension unterirdisch gebaut worden, unter den gegebenen Bedingungen? Waren wirklich die richtigen Gutachter dabei? Wer hat von der Seite Einfluss genommen? Waldschlösschenbrücke Dresden Geplant schon vor dem 1.WK - und gebaut gegen riesigen Widerstand (von vielen Leuten, die da nicht wohnen oder selbstgerecht in ihrem Elfenbeinturm sitzen). Immerhin nur 30% Mehrkosten, vor allem wegen diverser Rechtsstreitigkeiten und damit einhergehender längerer Bauzeit. Und heute? Da reicht ein Experiment mit einem Fahrradweg auf der benachbarten Brücke, dem „Blauen Wunder“, da steht der Verkauf im Umkreis von 1km fast komplett still. Den Zuwachs an Verkehr kann man den umsetzenden Firmen des Bauwerks nicht anlasten. Warum haben denn die „schlauen Ich-hab-es-ja-schon-vorher-gesagt-Klugscheißer“ keinen besseren Vorschlag gemacht? Genau - weil sie es nicht konnten. Vielleicht mal miteinander reden, wer ja ein guter Anfang.
Uwe D. schrieb: > Warum haben denn die „schlauen Ich-hab-es-ja-schon-vorher-gesagt-Klugscheißer“ > keinen besseren Vorschlag gemacht? Den besseren Vorschlag und die untermauerten Warnungen vor schlummernden Herausforderungen wurden sehr oft bereits gemacht. Nur werden diese in der Regel von den Machern, die das Projekt schönmachen, z.B. für die Politik und Haushältern, kaltgestellt. Und das wird sich vermutlich auch in der Zukunft nie ändern.
Mark B. schrieb: > Na zumindest auf dem Top-Level weiß der Auftraggeber durchaus sehr wohl, > was er braucht. Zum Beispiel: > -eine Steuerung für eine Maschine, die 1000 Eisenteile pro Tag biegt > -einen Zug, der 500 Passagiere befördert und mindestens 200 km/h fährt > -ein Gebäude mit 300 Mietwohnungen à so-und-soviel Quadratmetern Das mögen Motivationen, Ziele, Abschätzungen oder was auch immer sein. Meist aber keine harten Fakten. Etwas bisheriges 1-1 ersetzen oder kopieren ist planbar. Z.B. Deine Steuerung, wenn der Vorgänger das gleiche macht. Etwas neues hingegen ist nur vage im Voraus zu durchdenken. Darum baut man Prototypen, egal ob virtuell oder real. Wenn Deine Steuerung früher mechanisch war und jetzt elektronisch, sind möglicherweise mit kleinen Umstellungen die 10-fachen Mengen oder Aufträge mit höheren Anforderungen möglich.
:
Bearbeitet durch User
Uwe D. schrieb: > Wieviele Bahnhöfe sind denn schon in der Dimension > unterirdisch gebaut worden, unter den gegebenen Bedingungen? Kein Einziger! und das hat seinen Grund: Das ist unangemessen gefährlich, aufwändig, langwierig und teuer. Daher gibt es das nicht. Schon Haltestellen für die U-Bahnen werden aus diesen Gründen zögerlich gebaut. Dass in Stuttgart so arg gebaut wurde, hat einfach damit zu tun, dass der Herr Mappus, der damals an der Regierung war, sich ein Prestige-Objekt gönnen wollte. Zudem haben Recherchen inzwischen ergeben, dass dort sehr einflussreiche Unternehmer mit den Grundstücken spekuliert haben und so Profit einfahren konnten, als sie diese der Bahn / der Stadt verkaufen konnten. Es wurde gebaut, weil gebaut werden sollte, obwohl selbst der Architekt damals Einwände gehabt hat und vor Risiken bei den Röhren gemahnt hatte. Das Problem des Wassereinschubs und Aufquellen war hinlänglich bekannt. Die meisten Stuttgarter kannten die Zusammenhänge und wollten das nicht haben. Da aber auch viele von Außerhalb mitwählen durften, wurde ihnen das von aussen aufgezwungen. Soviel zum Thema Gruppenentscheidung.
Uwe D. schrieb: > Wer wiederholt nicht das vereinbarte abliefert, > der kriegt eins auf den Deckel - warum sollte es mit der > Verantwortung/Verbindlichkeit anders laufen? Was bedeutet denn konkret "auf den Deckel"? Wenn die Gruppe entscheidet, wer was zu tun hat, dann gibt es bei der Verteilung immer Verlierer und Gewinner. Da finden sich dann die Grüppchen zusammen und verteilen sich das so, dass sie gut glänzen können und andere die A-Karte haben! Alles erlebt. Uwe D. schrieb: > Diese Teams entwickeln weniger Erfahrene aktiv weiter, Wieso sollte das nur dort zustande kommen? Eine Weiterentwicklung erfordert immer, dass ein Unerfahrener an eine Aufgabe dran kommt, die er noch nicht beherrscht. Wenn man sich das zeitlich leisten kann, dann geht das mit und ohne Scrum. Wenn es keine Hierarchie gibt, gibt es keine neutrale Person, die für eine Balance sorgt. Es ist also nicht automatisch sichergestellt, dass sich alle weiterentwickeln. Da gibt es immer eine Gruppendynamik, die einzelne an den Rand drängt. Das im SCrum alle gleichberechtigt sind, ist ein Ideal. Kann sein, wird aber bei weitem nicht erreicht.
Uwe D. schrieb: > Warum haben denn die „schlauen > Ich-hab-es-ja-schon-vorher-gesagt-Klugscheißer“ keinen besseren > Vorschlag gemacht? > > Genau - weil sie es nicht konnten. Vielleicht mal miteinander reden, wer > ja ein guter Anfang. Die machen immer gute Vorschläge. Und das Beste ist, im Gegensatz zum Hauptprojekt gibt es bei den Alternativkonzepten keine Planungsfehler und Kostensteigerungen, die durchdenken alleine die komplette Komplexität in einem Rutsch, während Teams aus hunderten Ingenieuren einfach zu dumm sind. (Oder die Alternativprojekte haben doch nur den Vorteil, dass sie nicht ausgeführt werden und deshalb auf dem Papier für immer und ewig viel besser und billiger sind?)
K. F. schrieb: > Uwe D. schrieb: >> Wieviele Bahnhöfe sind denn schon in der Dimension >> unterirdisch gebaut worden, unter den gegebenen Bedingungen? > Kein Einziger! und das hat seinen Grund: Das ist unangemessen > gefährlich, aufwändig, langwierig und teuer. Daher gibt es das nicht. > Schon Haltestellen für die U-Bahnen werden aus diesen Gründen zögerlich > gebaut. In Deutschland nur kleinere Bahnhöfe, aber in Europa - in Paris z.B. schon: STATION CHÂTELET-LES HALLES > Die meisten Stuttgarter kannten die Zusammenhänge und wollten das nicht > haben. Da aber auch viele von Außerhalb mitwählen durften, wurde ihnen > das von aussen aufgezwungen. > > Soviel zum Thema Gruppenentscheidung. Es ist meistens so: Wenn es klappt, dann wird stolz gefeiert - wenn es schief geht, dann haben es alle vorher gewusst.. K. F. schrieb: > Uwe D. schrieb: >> Wer wiederholt nicht das vereinbarte abliefert,… > Was bedeutet denn konkret "auf den Deckel"? > Wenn die Gruppe entscheidet, wer was zu tun hat, dann gibt es bei der > Verteilung immer Verlierer und Gewinner. Es gibt eine knackige Ermahnung, dann eine gelbe Karte und bei der nächsten großen Sache fliegt die Person aus dem Team. Warum sollte die Verbindlichkeit höher sein, wenn jemand im nicht agilen Projektumfeld arbeitet? Ehrlicherweise ist es doch fast immer so, dass die Kollegenschaft das kotzen kriegt, wenn es Leute gibt, die einfach so die Zeit rumbringen dürfen und vielleicht noch großkotzig alles besser wissen. > Da finden sich dann die > Grüppchen zusammen und verteilen sich das so, dass sie gut glänzen > können und andere die A-Karte haben! Alles erlebt. Dann ist der SCRUM Master nicht tough… > > Uwe D. schrieb: >> Diese Teams entwickeln weniger Erfahrene aktiv weiter, > Wieso sollte das nur dort zustande kommen? > Eine Weiterentwicklung erfordert immer, dass ein Unerfahrener an eine > Aufgabe dran kommt, die er noch nicht beherrscht. Wenn man sich das > zeitlich leisten kann, dann geht das mit und ohne Scrum. Hatte ich ja geschrieben - es geht auch ohne SCRUM. Im SCRUM Team mache ich es, wenn der Bedarf besteht. Denn der Geldgeber ist dazu verpflichtet, entsprechend qualifizierte Ressourcen zu stellen. Das ist der Standard in meinen Projekten. Selbst externe Dienstleister werden dazu angehalten, ihre Ressourcen aktiv im gemeinsamen Projekt weiterzuentwickeln. Da habe ich optimal Einfluss auf das Ergebnis. Wertschätzung mögen alle.. > Wenn es keine Hierarchie gibt, gibt es keine neutrale Person, die für > eine Balance sorgt. Es ist also nicht automatisch sichergestellt, dass > sich alle weiterentwickeln. Da gibt es immer eine Gruppendynamik, die > einzelne an den Rand drängt. Im SCRUM Team gibt es keine Hierarchie - wer die installiert, will kein SCRUM Team, sondern betreibt Marketing. > Das im SCrum alle gleichberechtigt sind, ist ein Ideal. Kann sein, wird > aber bei weitem nicht erreicht. Dann frage doch mal in der nächsten Retrospektive, warum das so ist… Das Problem ist nicht SCRUM, sondern die Verhinderer - Angst vor dem Versagen, Überforderung, fehlende Erfahrung, …
Uwe D. schrieb: > Das Problem ist nicht SCRUM, sondern die Verhinderer - Angst vor dem > Versagen, Überforderung, fehlende Erfahrung Das Dogma ist nie schuld, nur die Menschen...
Michael B. schrieb: > Das Dogma ist nie schuld, nur die Menschen... Man merkt schon, wie sehr Du an einer sachlichen Diskussion zur Erweiterung Deines Horizonts interessiert bist. Wenn man sich an Vorurteilen festhalten kann, gewinnt der Tag Struktur und das Leben wird schön einfach.
Michael B. schrieb: > Uwe D. schrieb: >> Das Problem ist nicht SCRUM, sondern die Verhinderer - Angst vor dem >> Versagen, Überforderung, fehlende Erfahrung > > Das Dogma ist nie schuld, nur die Menschen... Wie beim Kommunismus. Der ist ja so super. Nur haben das bisher leider alle total falsch gemacht.
Cyblord -. schrieb: > Michael B. schrieb: >> Das Dogma ist nie schuld, nur die Menschen... > > Wie beim Kommunismus. Der ist ja so super. Nur haben das bisher leider > alle total falsch gemacht. Staatlich organisierte Versuche mit Sozialismus und Kommunismus sind bisher allesamt gescheitert, das stimmt. Aber auf einer freiwilligen Basis ist der Kommunismus mitunter sogar in marktwirtschaftlichen Umgebungen erfolgreich, etwa in israelischen Kibbuzen.
Ein T. schrieb: > in israelischen Kibbuzen. Kibuzzim Sollte man erfragen, wie die Macht- und Entscheidungsstrukturen in einem solchen Kibuz gelagert sind und wirken? Soweit mir bekannt arbeiten die gesamtverantwortlich entscheidend und der einzige, der etwas zusagen hat, ist der örtliche Rabbi - vorwiegend in religiösen, aber auch sozialen Fragen. Da ist er so eine Art allround-Ansprechpartner für alles.
Ein T. schrieb: > Wenn man sich an Vorurteilen festhalten Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. Ich habe zu Scrum sogar einen 'Doppelblindtest', also dasselbe Projekt mal mit und mal ohne agile Methoden erlebt. Cyblord -. schrieb: > Wie beim Kommunismus. Der ist ja so super. Nur haben das bisher leider > alle total falsch gemacht. Erklär das mal dem Kommunisten Ein T.
K. F. schrieb: > Ein T. schrieb: >> in israelischen Kibbuzen. > Kibuzzim Wenn man schon klugscheißen will, sollte man es wirklich besser wissen. Im Deutschen ist der Plural "Kibbuze" (bzw. als Dativ "in Kibbuzen") korrekt. Dein hebräischer Plural "Kibbuzim" ist zwar korrekt, aber hebräisch. > Sollte man erfragen, wie die Macht- und Entscheidungsstrukturen in einem > solchen Kibuz gelagert sind und wirken? Soweit mir bekannt arbeiten die > gesamtverantwortlich entscheidend und der einzige, der etwas zusagen > hat, ist der örtliche Rabbi - vorwiegend in religiösen, aber auch > sozialen Fragen. Da ist er so eine Art allround-Ansprechpartner für > alles. Das wäre aber ungewöhnlich, denn die meisten Kibbuze sind säkular orientiert. Der religiösen Kibbuzbewegung gehören nur knapp sechs Prozent der Kibbuze an. Genau wie das mit dem Plural oben würdest Du das aber alles wissen, wenn Du wenigstens den (knappen) Artikel in der deutschsprachigen Wikipedia gelesen hättest. Wenn Du künftig erfolgreicher klugscheißen, es also wirklich besser wissen willst, und zudem englische Sprache verstehend lesen kannst, hat die englischsprachige Wikipedia umfangreichere Informationen. Viel Glück!
Michael B. schrieb: > Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. Es fällt mir außerordentlich schwer, das zu glauben.
Ein T. schrieb: > Michael B. schrieb: >> Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. > > Es fällt mir außerordentlich schwer, das zu glauben. Um so leichter scheinst du an Scrum-Versprechen zu glauben. Bias.
Michael B. schrieb: > Ein T. schrieb: >> Michael B. schrieb: >>> Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. >> >> Es fällt mir außerordentlich schwer, das zu glauben. > > Um so leichter scheinst du an Scrum-Versprechen zu glauben. Ach, beruflich entwickle ich jetzt seit über 30 Jahren Software, mal mit und mal ohne agilen Methoden. Meine agilen Projekte waren bis auf wenige Ausnahmen erfolgreicher in der Zielerreichung und trotzdem angenehmer und entspannter. Wenn Dein Auftreten im echten Leben allerdings dem in diesem Forum ähnelt, dann verstehe ich gut, warum agiles Arbeiten bei Dir nicht funktioniert.
Ein T. schrieb: > dann verstehe ich gut, warum agiles Arbeiten bei Dir nicht funktioniert. Tritt dir selbst ans Schienbein und nicht anderen, ich gucke anderen zu wie sie ihr Scrum durchziehen (und weiss nicht ob ich lachen oder weinen soll). Aber Ätzhammeln wie dir, die anderen nur in die Eier treten wollen, sind da sicher richtig aufgehoben
Michael B. schrieb: > Tritt dir selbst ans Schienbein [...] > Aber Ätzhammeln wie dir, die anderen nur in die Eier treten wollen, [...] Armes Schneeflöckchen... Wenn Du gar so empfindlich bist, solltest Du Dir erstmal solche Ausfälle verkneifen: Michael B. schrieb: > Erklär das mal dem Kommunisten Ein T. Das ist übrigens genau das was ich gemeint habe: wer zwar selbst ständig mit Provokationen wie dieser böswilligen Unterstellung um sich wirft, jedoch bei Gegenwind sofort das Mimimöschen gibt, ist mit anderen Menschen inkompatibel und kann deswegen natürlich auch nicht agil arbeiten. Bei agilen Methoden geht es nämlich darum, einander auf Augenhöhe zu begegnen, also andere ernst und ihre Anregungen und Kritiken anzunehmen. Pöbelnde Mimis sind für diese Arbeitsweise offensichtlich denkbar ungeeignet und werden erst kurz eingenordet, und im Wiederholungsfall geräuschlos entfernt.
Ein T. schrieb: > Bei agilen Methoden geht es nämlich darum, einander auf Augenhöhe zu > begegnen Ja aber das ist auch so ein Problem: Diese Gleichberechtigung existiert in der Wirtschaft nicht, dann kann sie auch in SW Teams nicht existieren. Am Ende ist jemand in der Verantwortung dass das Ding fertig wird und tut was der Kunde erwartet und was man verkaufen kann. Und als jemand der diese Verantwortung hat, will ich auch ansagen können was läuft. Kann ich das nicht, nehme ich auch die Verantwortung nicht an. Das Team selbst hat keine Verantwortung. Die können schön auf Augenhöhe coden aber niemand kommt zu denen wenn der Kunde warten muss oder das Ding macht was es will.
Cyblord -. schrieb: > Ein T. schrieb: >> Bei agilen Methoden geht es nämlich darum, einander auf Augenhöhe zu >> begegnen > > Ja aber das ist auch so ein Problem: Diese Gleichberechtigung existiert > in der Wirtschaft nicht, dann kann sie auch in SW Teams nicht > existieren. Du weißt doch, wie Zusammenarbeit in einem Technikerteam läuft: Kompetenz, Erfahrung und die Güte der Vorschläge spielen dabei durchaus eine Rolle. Bei agilen Projekten gewinnt halt (ok: im Idealfall), wer den besten Vorschlag gemacht hat. Das ist einer der wesentlichen und gewünschten Unterschiede zum klassischen Projektmanagement, wo häufig nicht der beste Vorschlag gewinnt, sondern nur der Große Mufti -- egal, wie kompetent er ist oder nicht. > Am Ende ist jemand in der Verantwortung dass das Ding fertig > wird und tut was der Kunde erwartet und was man verkaufen kann. Und als > jemand der diese Verantwortung hat, will ich auch ansagen können was > läuft. Dafür gibt es bei vielen (den meisten?) agilen Methoden eigens eine Rolle, beispielsweise im SCRUM-Framework den sogenannten "Product Owner". Der legt ähnlich wie ein klassischer Projektleiter sogar etwas fest, nämlich was gemacht wird. Im Gegensatz zu einem klassischen Projektleiter schreibt er jedoch nicht vor, wie es gemacht wird, und verläßt sich anstelle dessen darauf, daß die Fachleute das selbst am Besten wissen. Das hat natürlich auch etwas mit Wertschätzung, Vertrauen und Verantwortung zu tun. Der PO muß seinen Kollegen vertrauen (und vertrauen können), daß sie dazu fähig sind, selbständig die beste Lösung für ein Problem finden und umsetzen, oder sich Unterstützung holen zu können -- und natürlich müssen die dann auch die Verantwortung dafür übernehmen. Tatsache ist und bleibt jedoch, daß starre und unflexible Hierarchien keinen Beitrag zur Lösung technischer Probleme leisten, und häufig stehen sie dabei sogar im Weg.
Ein T. schrieb: > Der legt ähnlich wie ein klassischer Projektleiter sogar etwas > fest, nämlich was gemacht wird. Im Gegensatz zu einem klassischen > Projektleiter schreibt er jedoch nicht vor, wie es gemacht wird, und > verläßt sich anstelle dessen darauf, daß die Fachleute das selbst am > Besten wissen. Und genau dafür brauchst du im Team TOP Leute. Und die hast du meist nicht. Weil man heute nur ein paar billige Inder hat, die nur machen was zu 100% irgendwo Step-by-Step beschrieben ist.
Cyblord -. schrieb: > Ein T. schrieb: >> Der legt ähnlich wie ein klassischer Projektleiter sogar etwas >> fest, nämlich was gemacht wird. Im Gegensatz zu einem klassischen >> Projektleiter schreibt er jedoch nicht vor, wie es gemacht wird, und >> verläßt sich anstelle dessen darauf, daß die Fachleute das selbst am >> Besten wissen. > > Und genau dafür brauchst du im Team TOP Leute. Und die hast du meist > nicht. Da habe ich bisher anscheinend das große Glück gehabt, immer mit entweder kompetenten und erfahrenen oder neu- und wissbegierigen Menschen arbeiten zu dürfen. > Weil man heute nur ein paar billige Inder hat, die nur machen was > zu 100% irgendwo Step-by-Step beschrieben ist. Das ist ein kulturelles Ding, sie wollen ihr Gesicht nicht verlieren, darum traut sich niemand, etwas anderes zu machen. Sogar wenn er weiß, daß es eine bessere Lösung gibt, wird ein Inder niemals seinem Vorgesetzten noch seiner Dokumentation widersprechen, nicht einmal verklausuliert.
Ein T. schrieb: > Bei agilen Projekten gewinnt halt (ok: im Idealfall), wer > den besten Vorschlag gemacht hat. Das ist einer der wesentlichen und > gewünschten Unterschiede zum klassischen Projektmanagement, wo häufig > nicht der beste Vorschlag gewinnt, sondern nur der Große Mufti Du zeichnest hier aber ein sehr einseitiges Bild. Es kommt am Ende darauf an, wer zum "Mufti" erhoben wurde. Das sollte ja immer derjenige sein, der die meiste Ahnung hat. Und dass sich "Ahnung" auf mehrere Personen verteilt und es deshalb keinen einzelnen geben kann, der etwas größeres auf die Beine stellt, sollte damit klar sein. Somit stimme ich der Aussage an anderer Stelle zu, dass es keinen einzigen Product Owner geben kann. Ob bei Scrum jetzt damit automatisch der gewinnt, der - wie du annimmst - > den besten Vorschlag gemacht hat ist damit aber noch nicht sicher gestellt! Der Effekt solcher Gruppenentscheidungen ist nämlich, dass immer das akzeptiert wird, was von der Mehrheit verstanden wird. Wenn ein einzelner einen genialen Vorschlag macht, der über dem Level ist, das die Mehrheit noch versteht, kommt er eben nicht durch! Es ist daher nötig, dass die Gruppe nicht über jeden Krümel abstimmt, sondern in den meisten Fragen einfach auch den Entscheidungen des "Mufti" vertraut, wenn sich gezeigt hat, dass diese in der Regel gut sind. Hier steckt aber das Problem: Viele möchten ihre eigenen Vorschläge durchbringen. Wenn die nämlich halbwegs funktionieren, werden die Personen selber zum Mufti, weil die Alternative ja gar nicht getestet wurde. Also werden Seilschaften geschmiedet und heraus kommt, was die Seilschaft befürwortet. Andere Vorschlagsgeber werden schon in der Phase der Entscheidungsfindung weggebissen und unterdrückt! Man sieht solches Verhalten an den sehr mittelmäßigen Entscheidungen in technischen Gremien und politischen Gruppen, wo jeder um die Vormacht streitet, um voran zu kommen. Im Bundestag z.B. "gewinnt" bei Weitem nicht der beste Vorschlag! Es gewinnt der, der den Harbeck am Besten über den Tisch zieht. Und das ist bekannterweise der allseits als mittelmäßig eingestufte Lindner. Er kann sich mit Blockadehaltung und Verhandlungsdruck durchsetzen. Niemand akzeptiert seine Vorschläge, weil man ihn für schlau hält, oder er es gar ist! Das Bundestag ist damit ein Beispiel, dass Scrum in keinster Weise funktiniert.
Ein T. schrieb: > wird ein Inder niemals seinem Vorgesetzten noch seiner > Dokumentation widersprechen, nicht einmal verklausuliert. Das ist auch bei Chinesen sehr ähnlich. Das ist sogar auch in europäischen Ländern weit verbreitet. Es ist ein Beispiel dafür, das Gruppen nicht automatisch richtig arbeiten, wenn nicht jemand auch sicherstellt, dass dort gleichberechtigt agiert wird und jeder dazu angehalten wird, seine Meinung zu postulieren. Oft schiebt sich einer in den Vordergrund und die anderen kuschen. Sie kuschen natürlich sehr gerne auch freiwillig und aus Bequemlichkeit, weil sie so die Verantwortung abgeben, aber in der Gruppe prima mitschwimmen. Und sind wir mal ehrlich: Die Meisten standen schon vor der Entscheidung, derm Boss klarmachen zu müssen, dass er daneben liegt und haben es dann gelassen, um keinen Zoff zu bekommen oder das Vertrauen zu zerstören. Wenn jemand dann sehr dominant ist, drückt er die anderen ungewollte an die Wand. Im Ergebnis sieht man, dass diese dann irgendwann einmal LMAA fahren und sich denken, "ok dann machen wir es so und lassen ihn selber später drüber stolpern". Und ja, auch ich habe das schon gemacht! Lass den Ellenbogentypen reinrasseln.
Und was hat das jetzt alles mit Scrum zu tun? Das sind doch Probleme die es früher genau so schon gab
Ein T. schrieb: > Das ist ein kulturelles Ding, sie wollen ihr Gesicht nicht verlieren, > darum traut sich niemand, etwas anderes zu machen. Sogar wenn er weiß, > daß es eine bessere Lösung gibt, wird ein Inder niemals seinem > Vorgesetzten noch seiner Dokumentation widersprechen, nicht einmal > verklausuliert. Mit dieser Einstellung ist man freilich in internationalen Projekten eher fehl am Platz. Dokumente können Fehler enthalten, und tun dies auch sehr oft. Der richtige Weg ist dann eben diese Fehler zu korrigieren. Wer dazu nicht imstande oder nicht willens ist, der sollte vielleicht einfach einen anderen Job machen?
Um noch mal auf die Eingangsfrage zurückzukommen: Ich arbeite als Entwickler in einem bisher eher traditionell ausgerichteten Unternehmen. Jetzt wird auch bei uns Agile und Scrum vom neuen Management als neueste Sau durch´s Dorf getrieben. Manchmal fühle ich mich wie in einer Sekte! Für den BWLer ist halt alles, was er nicht messen kann, suspekt. Außerdem sind ihm solche Aufgaben suspekt, für die Spezialwissen erforderlich ist, die er nicht durchschaut und wo ihm Fachexperten vom Pferd erzählen können. Begeistert ist er hingegen, wenn er mit Phrasen glänzen kann und "Prozesse optimieren" kann. Die Idee von Scrum ist schnell beschrieben: Eine anspruchsvolle Aufgabe solange in kleinere Aufgäbchen zerlegen, bis sie auf einen Klebezettel passen, mit einer eindeutigen Arbeitsdauer und schließlich einem Fälligkeitsdatum versehen werden können und einem beliebigen und austauschbaren Teammitglied zugewiesen werden können. Dieses "Dumbing down" ist nichts Neues, geschweige denn Originelles. Frederick W. Taylor als Theoretiker und Ford als Unternehmer haben damit schon vor hundert Jahren die Fließbandfertigung möglich gemacht. Ein anderes Beispiel ist McDonalds, die Restaurants betreiben, ohne daß auch nur irgendeiner in einem solchen Laden kochen kann. Mit großem Gewinn habe ich mir die Werke von Gunter Dueck (Bücher und Vorträge auf Youtube) zu Gemüte geführt. Dueck beschreibt, wie Techies auf den Inhalt und die Qualität der Arbeit fokussiert sind, während BWLer rein auf die Prozesse schauen. Er vergleicht Informatiker von Wesen her mit Katzen und BWLer (bzw. Manager) mit Hunden und kommt zum Schluß, daß Agile von Managern eingesetzt wird als Versuch, den Katzen das Apportieren beizubringen. Was die Besprechungen betrifft, so ist es eine Herabsetzung der Entwickler, wenn sie täglich ihr Sprüchlein aufsagen müssen (und dann gar noch gelobt oder geschimpft werden von Leuten, die nicht einmal ein Grundverständnis von Softwareentwicklung haben). Ich zitiere unten aus einem Aufsatz, den ich mit großem Gewinn gelesen habe und wo das wunderbar beschrieben wird. Die implizite Annahme, daß jeder im Team austauschbar ist und im Prinzip jeder die Aufgäbchen gleich schnell und gut machen kann, ist eine Zumutung für jemanden, für den Exzellenz in seinem Bereich das persönliche Ziel ist. Es gilt auch das Parkinsonsche Gesetz der Trivialität: Je trivialer ein Thema ist, desto intensiver und länger die Diskussionen in den "Meetings". Inhaltliche Themen mit einem Mindestmaß an Anspruch wie Einsatz von Entwurfsmustern hingegen treffen auf dummes Schweigen. Und dann diese Anglismen, gewürzt mit deutschen Floskeln, was zu einer völlig stereotypen Audrucksweise führt. "Am Ende des Tages schauen wir uns alle in die Augen und kommen zum Ergebnis, daß wir mehr Commitment gebraucht hätten". Für das Management ist der Gewinn: Das Förderbändchen schnurrt immer und alles ist quantitativ darstellbar. Der Enzwickler entwickelt aber leider die "Scrum Fatigue", weil er gefühlt nur noch am Band steht und kleine Päckchen packt und gar nicht mehr dazu kommt, ein schwierigeres Thema systematisch zu analysieren und dann auf höherer logischer Ebene zu lösen. Das Management will gerne mehr "Velocity" (Story Points geteilt durch Zeit)? Können sie gerne haben, bekommen sie halt mehr Story Points. Gerne können die Techies und BWLer da Katz und Maus spielen! https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ "Corporate Agile, losgelöst von der Beratungsumgebung, geht noch weiter und geht davon aus, dass die Ingenieure nicht schlau genug sind, um herauszufinden, was ihre internen "Kunden" wollen. Das bedeutet, dass die Arbeit in "User Stories" und "Iterationen" zerlegt wird, die der Arbeit oft das Gefühl nehmen, etwas erreicht zu haben, sowie jede Hoffnung, eine langfristige Vision für die Zukunft zu entwickeln. (...) Es ist bekannt, dass kreative Menschen ihre Kreativität verlieren, wenn sie aufgefordert werden, sich während der Arbeit zu erklären. Genauso verhält es sich mit Software. Programmierer müssen oft in einem Umfeld einseitiger Transparenz arbeiten. Diese agilen Systeme, die so oft falsch angewendet werden, verlangen, dass sie trotz mangelnder Gegenseitigkeit einen demütigenden Einblick in ihre Zeit und Arbeit bieten. Anstatt an tatsächlichen, langfristigen Projekten zu arbeiten, für die sich eine Person begeistern könnte, wird sie auf die Arbeit an atomisierten "User Stories" auf Feature-Ebene verwiesen und darf oft nicht an Verbesserungen arbeiten, die nicht mit kurzfristigen, unmittelbaren Geschäftsanforderungen in Verbindung gebracht werden können (oft von oben heraus). Diese fehlgeleitete, aber gängige Variante von Agile eliminiert das Konzept des Eigentums und behandelt Programmierer als austauschbare, kommerzialisierte Komponenten. (...) Unter Agile häufen sich technische Schulden an und werden nicht angegangen, weil die Geschäftsleute, die das Sagen haben, ein Problem erst sehen, wenn es viel zu spät oder zumindest zu teuer ist, um es zu beheben. Darüber hinaus werden einzelne Ingenieure allein aufgrund der Optik des aktuellen zweiwöchigen "Sprints" belohnt oder bestraft, was bedeutet, dass niemand fünf "Sprints" vorausschaut. Agile ist nur ein gedankenloser, kurzsichtiger "Sprint" nach dem anderen: kein Fortschritt, keine Verbesserung, nur ein Ticket nach dem anderen. (...) Ständige Überwachung der eigenen Arbeit deutet auf mangelndes Vertrauen und einen niedrigen sozialen Status hin, und die statussensibelsten Menschen (selbst wenn sie die besten Arbeiter sind) sind die ersten, die ablehnen, wenn die Überwachung zunimmt. Wenn sie das Gefühl haben, dass ihnen nicht vertraut wird (und was wird sonst noch von einer Kultur kommuniziert, die erwartet, dass jede Arbeit gerechtfertigt ist?), dann verlieren sie schnell die Motivation." Eine Arbeitsweise wie Scrum ist wahrscheinlich nur sinnvoll in kritischen Situationen, wo schnelles und abgestimmtes Handeln erforderlich ist, etwa bei kurz vor einem neuen Release.
A. B. schrieb: > Und was hat das jetzt alles mit Scrum zu tun? Das sind doch Probleme die > es früher genau so schon gab Es hat deshalb damit etwas zu tun, weil Scrum die bereits vorhandenen und funktionierenden Dinge in einem Prozess für sich vereinnahmt und sie als neu und Scrum-korelliert darstellt, während es die nicht funktionierenden Dinge, als alt, langsam und behäbig darstellt, die jetzt agil sein sollen.
Mark B. schrieb: > Wer dazu nicht imstande oder nicht willens ist, der sollte vielleicht > einfach einen anderen Job machen? Du darfst nicht vergessen, daß es viele Vorgesetzte gibt, die sich nichts sagen lassen wollen und dafür sorgen, dass diejenigen, die ihnen die Fehler vorrechnen, in die Ecke gedrängt werden und nicht hochkommen. Die braven Ja-Sager, die kritiklos und bedingungslos alles machen, was man ihnen sagt, sind da eher beliebt, weil diese Sorte dann oben bleibt und das Ruder in der Hand hält. Aus der Beobachtung kann man sagen, dass diese sich auch oft gegen genau formulierte Dokumente und Konzeptpapiere aussprechen, weil diese ihren Vorgehen, des spontanen Entscheidens widersprechen. Obendrein werden einmal als Vorgabe formulierte Dinge dann zum boomerang, wenn sich herausstellt, dass es ein komplizierter Weg war, der zu Mehrarbeit führte. Die Qualität der Vorgaben des Vorgesetzten wird dadurch nämlich meßbar, was ebenfalls nicht beliebt ist. Es kann damit ein großes Problem sein, wenn durch Scrum oder andere Arbeitstechniken das Team angehalten wird, Aufgaben zu planen und Lösungen zu dokumentieren, weil dann heraus kommt, dass man einen falschen Weg beschritten hat und offenbar wird, wer für die Entscheidungen verantwortlich ist. Da reicht es dann wenn klar ist, daß Müller und Meier für "links" entschieden hatten und Schulze überstimmten, der für "rechts" plädierte. Sollte sich dann zeigen, dass "rechts" besser gewesen wäre, geht aber niemand her und erhebt Schulze zum neuen primären Ideengeber, sondern man schliesst sich Müller und Meier an, die stabil stehen und unterstüzt sie darin, sich die Idee schön zu reden, Schulze als Quertreiber hinzustellen und sorgt sorgt som it dafür, dass Schulze rausgedrängt wird, oder er sich zurückhält.
Wie sagt der Lateiner: Es gibt keinen vom Management oktroyierten Prozess, der aus schlechten Entwicklern gute macht, aber viele Prozesse, die gute Entwickler demotivieren und frustrieren.
Gerhard O. schrieb: > Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? > > Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken > der Details... Garnichts. Wir deutschen Ingenieure waren ja eben deswegen so beliebt, weil wir so genau und präzise planen und denken konnten. Es ist halt nur nicht Hipp genug! Und: Weil immer mehr Nichtdeutsche in deutschen Firmen arbeiten, die das nicht kennen und nicht können, müssen die auch irgendwie organisiert werden. Obendrein bildet Deutschland ja auch nur noch bachler mit G8 aus, d.h. die jungen Entwickler kommen mit immer weniger Erfahrung in Firmen. Hinzukommen die, welche keine Hochschulweg beschritten haben und sehr abstrakt denken und mit Texten umgehen können. Es sind durch die Bildungsoffensiven sehr viele ohne ein Abi in die Entwicklunsabteilungen vorgerückt. Vor 20 Jahren war der Schwerpunkt noch auf lang und gut ausgebildeten Leuten, die an Text, und Planungsarbeit gewöhnt waren. Sie mussten genau arbeiten, weil viele Schritte lang und teuer waren, wenn man sie wiederholt hätte. Heute muss alles HopplaHopp gehen - Tempo geht vor Qualität. Da, wo Scrum herkommt, aus "meiner" Welt der Softwareenticklung, ist es besonders krass: Es wird alles nur noch schnell mit buildung blocks zusammengefuhrwerkt, mit Rust verknoddelt und virtualisiert gePythoned. Und dann wird andauernd eine verwanzte und ungetestete Software als Beta an den Kunden rausgehauen.
Ein T. schrieb: > Ach, beruflich entwickle ich jetzt seit über 30 Jahren Software, mal mit > und mal ohne agilen Methoden. Meine agilen Projekte waren bis auf wenige > Ausnahmen erfolgreicher in der Zielerreichung und trotzdem angenehmer > und entspannter. Solange nicht das gleiche Projekt von einer parallelen Gruppe in konventioneller Weise gelöst wurde, kann man keine Aussage treffen, wie SCRUm geholfen und sich niedergeschlagen hat. Softwareprojekte sind untereinander nicht zu vergleichen. ES sind oft kleine Details, die fehlen und die zu einem Fiasko führen. Es sind auch oft strategische Entscheidungen beteiligt, die von neuen Personen in der Leitung anders getroffen werden, die zu anderen Aufwänden führen. Der wichtigste Punkt ist, was an Grundstock in einem Paket schon da ist, wenn die Anforderungen für eine neue SW kommen und was davon verwendet werden soll. Das ist bei jedem Paket völlig anders, d.h. die Voraussetzungen entscheiden über den Erfolg. Scrum- oder nicht-Scrum lässt sich nur beurteilen, wenn 2 gleich große Teams an einer ähnlichen Aufgabe arbeiten, die von 0 beginnen und es somit nur vom Team abhängt, wie gut die Planung läuft und wie die error rate sich darstellt. Von der Qualität der Planung am Anfang hängt es ab, wie gut man hinterher liefern, in Betrieb nehmen und ändern kann. Mein PG hat das schon mal so gemacht und feststellen müssen, dass das SCRUM Team für die gleiche Maturity am Ende fast 20% mehr Mannstunden verbraten hat. Obwohl sie zeitweilig voraus waren. Als Ergebnis zeigte sich, dass eine gute Planung nicht ersetzt werden kann und sich am Ende auszahlt. Der PG hat als Folge den Scrum-Prozess vollständig aus der Firma entfernt. Die SW wird jetzt modular von System-Architekten geplant und linear aufgesetzt. Dann kommen die Selbständigen und Internen und setzen es paketweise um.
Grundsätzlich geht es ja in erster Linie einfach um Komplexitätsreduktion und verbesserte Kommunikation. Worüber wollen wir uns unterhalten? Ganz ähnliche Strategien kann man bei der Evaluation anwenden - wobei da aber ganz vorab grundlegendes Know How, Fleiß und Engagement bestimmender sind. Es (also die Planorientierung) ist ein Versuch, etwas mehr Objektivität und Wiederholbarkeit zu gewinnen und als ein solcher eigentlich ein netter Zusatz, bzw. ein Qualitätsgewinn. Schlecht ist, wenn gewissermaßen das Werkzeug und die Orientierung zum Ziel verkommt. Ein gutes Beispiel ist Emil Pagliarulo mit seiner "KISS" Orientierung. Manchmal reicht das eben nicht, und dann muss man mehr machen, etwas grundlegend anderes machen, selbst hinterfragen nicht vergessen - und innere Kündigung wirkt sich normalerweise auch nicht sonderlich positiv auf das Endergebnis aus. So ganz allein sind die Entwickler mit dem aktuellen Müllhaufen aber nicht, auch die Spiele- und Computerzeitschriften haben ihren (Jubel-) Beitrag dazu geleistet, dass die aktuelle Situation so ist, wie sie nach vielen Jahren sein muss. Viel Déjà-vu halt und kaum Kante -> Gähn. Glücklicherweise haben andere Entwickler die kognitive Kurve einigermaßen hinbekommen - wo man sich dann aber fragt, wie man das (Qualitätsmanagement) unterstützen kann. Eine Engine-Auswechslung z.B. für ES6 wäre schwierig, aber irgendwo auch ziemlich wichtig.
Nun meckern bei uns in der Firma die nächsten über Scrum. Berichtet wird immer das gleiche: 50 % der Arbeitszeit geht für Gebabbel drauf. Wenn es jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war kein richtiger Sozialismus." Nun ist mir aufgefallen, dass vor 15 Jahren ein Buzzword sehr populär war, nun aber vollkommen verschwunden zu sein scheint: "prozessorientiertes Denken". Damals kam keine Anzeige für ITler ohne dieses Buzzword aus. Das war den BWLern offenbar sehr wichtig. Haben die nun Scrum entdeckt, um die Leute an der kurzen Leine zu führen? Auch bei uns in der Firma gibt es "Prozesse". So arbeitet die EDV-Service-Abteilung nur mit Ticket. Das Ticket-Tool ist unter aller Sau. Geholfen wird einem nur mäßig. Auf die Idee, Standardlösungen ins Intranet zu stellen, kommen die Leute nicht. Nun ist mir aufgefallen, dass dort Externe arbeiten. Ich weiß nicht, wer diese Leute dort stellt. Die brauchen die Tickets offenbar für die Rechnungslegung. Die würden mit proaktivem Vorgehen und Standardlösungen im Intranet ihr Wasser abgraben. Aber der Prozess ist ja schön ordentlich, auch wenn alle schimpfen, dass banalste IT-Probleme Wochen bis zur Lösung brauchen oder gar nicht abgearbeitet werden. Diese Konstruktion haben bestimmt die BWLer verzapft. Ich habe auch Kollegen im Hause, die gehen voll darin auf. Nun hat besagter EDV-Service vor einem Jahr den Drucker in unserem externen Standard nicht stabil zu laufen gekriegt. Der hat häufig Aufträge verschluckt. Ich nahm mich der Sache an, installierte einen Druckertreiber vom Hersteller und seitdem druckt es zuverlässig. Ich stellte eine Standardlösung für alle zur Verfügung, beschrieb das Problem. Wurde angemotzt: "Ticket schreiben und EDV richtig nerven." Ich habe aber keine Lust auf solche Spielchen. Auf die Idee, dass die Arbeit, durchgeführt nach bestem Wissen und Gewissen und mit Leidenschaft, dann am produktivsten sein könnte, auf die Idee kommen die Leute in den höheren Etagen offenbar nicht. Wäre ja zu einfach. Ich mache das schließlich und ich kann für mich reklamieren, mit mehreren guten Idee die Produktivität enorm vorangebracht zu haben. Ich kann jetzt leider nichts ins Detail gehen, aber bei der einen Idee dauerte die Umsetzung 30 min und es hatte sich schon am nächsten Tage für mich persönlich ammortisiert, weil es dumme, wiederkehrende, mauslastige und fehlerträchtige Arbeit unnötig machte. Das ist auch schon 13,5 Jahre her. (Es dankte mir keiner.) Es kam in vielen Projekten seitdem zur Anwendung.
Rudi R. schrieb: > Nun meckern bei uns in der Firma die nächsten über Scrum. Berichtet wird > immer das gleiche: 50 % der Arbeitszeit geht für Gebabbel drauf. Wenn es > jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich > entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war > kein richtiger Sozialismus." Vielleicht macht ihr Scrum aber wirklich nicht richtig? Ohne jetzt zu wissen, wie "richtig" da geht. Ansonsten ist das hier eh nur ein klassischer Rant-Beitrag ohne tiefergehende Verbindung zum Thema. Ich zitiere auch gerne meinen älteren Beitrag hier: Reinhard S. schrieb: > Rudi R. schrieb: >> ich bin ja eigentlich nur beratend dabei, >> (…) >> wenn nur diese dämlichen Besprechungen nicht wären > > Dämliche Besprechungen gibts auch außerhalb von Scrum und wenn du nur > beratend dabei bist ist sowas doch genau dein Jobprofil? Also lieber mal > die Position wechseln. > >> Nur geht mir >> Teamarbeit auf die Nerven, wo man nicht diskutieren kann, weil >> intellektuelle Gefälle so stark ist, dass ich gar nicht mehr zu manchen >> Leuten durchdringen kann. > > Was hat das mit Scrum zu tun? > > Klassischer (...)Troll.
Mit Scrum brauchst du 3x mehr Personal. Das ist also eine aktive Massnahme gegen Arbeitslosigkeit. Am Freitag noch arbeitslos, am Montag schon Scrum-Master und darf auf Entwicklerpersonal losgelassen werden, ist doch super. Schau dir mal die an, Scrum-masterin: https://www.tiktok.com/@thescrummastery/video/7326188606517775662 Dazu noch der Jiraverwalter, der Backorifficemanger, der Whiteboardcleaner, der Kanbanzettelverwalter, der Scrumkartenmischer,... Damit kann auch noch der nutzloseste Esser in Lohn und Brot gebracht werden, Politiker lieben es. Die Leute wissen ja selber dass sie überflüssig sind: https://www.reddit.com/r/scrum/comments/18kiudx/feel_useless_as_a_scrum_master/?tl=de
:
Bearbeitet durch User
Reinhard S. schrieb: > Vielleicht macht ihr Scrum aber wirklich nicht richtig? Unser mit 50 Jahren an Krebs verstorbener Christ hat auch nur nicht ausreichend viel gebetet. Wenn sie das täten, wüssten sie, dass es nicht 20% langer dauert sondern nie fertig wird, und dass nicht 50% in Palaver draufgeht, sondern jeder Mitarbeiter 90% damit verbringt, nach der Scrum-Kriterien möglichst gut da zu stehen und egal wird, was er wirklich schafft.
Viel Aufwand investieren die Gegner eines Frameworks, um zu erklären, warum es nicht geht. Und es wird lauter Zeug aus dem Ärmel gekramt, der wirklich in jedem Projekt auch auftritt. Und ehrlich, wenn Ihr zu blöd seid ein Daily auf zwei Tage pro Woche einzusparen, dann hat das nichts mit SCRUM oder AGIL zu tun, sondern mit Euer Unfähigkeit als Team oder Euch selber. Unreflektierter Mist wird ständig wiederholt und wird dadurch nicht besser. Wenn es einem nicht gefällt, ja dann lass es. Meine Güte - geht mir das Gejammer auf den Sack.
:
Bearbeitet durch User
Michael B. schrieb: > sondern jeder > Mitarbeiter 90% damit verbringt, nach der Scrum-Kriterien möglichst gut > da zu stehen und egal wird, was er wirklich schafft. Ob er nun versucht nach Scrum-Kriterien gut dazustehen oder nach anderen Kriterien ist doch egal. Was man wirklich schafft zählt eh am wenigsten, grad bei großen Firmen.
Uwe D. schrieb: > Und ehrlich, wenn Ihr zu blöd seid ein Daily auf zwei Tage pro Woche > einzusparen, Oh oh! Solche Abweichungen von der Regel bestraft SCRUM mit einem unausweichlichen Versagen. So steht es in den Büchern. Und so hat es der Consulter phrophezeit.
Martin K. schrieb: > Wir deutschen Ingenieure waren ja eben deswegen so beliebt, > weil wir so genau und präzise planen und denken konnten. Ok, hin und wieder stürzt dabei mal ein Stadtarchiv oder eine Brücke ein, und wir brauchen manchmal vierzehn Jahre für einen Flughafen. Aber immerhin haben wir deutschen Ingenieure alles genau und präzise geplant und gedacht -- nicht wie diese chinesischen Dummköpfe, die einen Flughafen in lediglich elf Monaten hinstellen, ohne jemals Pläne oder Gedanken darauf verschwendet zu haben. :-)
Reinhard S. schrieb: > Rudi R. schrieb: >> Wenn es >> jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich >> entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war >> kein richtiger Sozialismus." > > Vielleicht macht ihr Scrum aber wirklich nicht richtig? Naja, wie denn auch? Dein Vorredner schreibt ja selbst: Rudi R. schrieb: > Ich habe aber keine Lust auf solche Spielchen. Wie soll denn eine agile Methode denn funktionieren, wenn sich einige Leute verweigern, weil sie "keine Lust" darauf haben? Und in diesem Fall betrifft das ja sogar einen der wichtigsten Mitarbeiter des Unternehmens, der in dem "externen Standard" die Druckertreiber installiert...
Uwe D. schrieb: > Unreflektierter Mist wird ständig wiederholt und wird dadurch nicht > besser. Wenn es einem nicht gefällt, ja dann lass es. Wobei das Beste ja noch ist, daß ausgerechnet jene am Lautesten jammern, die ihren eigenen Aussagen zufolge gar nicht mit Scrum arbeiten, sondern das nur in anderen Teams beobachtet haben wollen.
Ein T. schrieb: > Wobei das Beste ja noch ist, daß ausgerechnet jene am Lautesten jammern, > die ihren eigenen Aussagen zufolge gar nicht mit Scrum arbeiten, sondern > das nur in anderen Teams beobachtet haben wollen. Als Freiberufler kann man sich regelmässig den Scrum-Zoo anschauen.
Ein T. schrieb: > > Rudi R. schrieb: >> Ich habe aber keine Lust auf solche Spielchen. > > Wie soll denn eine agile Methode denn funktionieren, wenn sich einige > Leute verweigern, weil sie "keine Lust" darauf haben? Und in diesem Fall > betrifft das ja sogar einen der wichtigsten Mitarbeiter des > Unternehmens, der in dem "externen Standard" die Druckertreiber > installiert... Eben, weil es nicht gut nicht. Ich weiß nicht, was die Sache mit dem Druckertreiber soll? Da ging es um das Thema mit der Prozessorientierung. Ich habe mich einfach mal hingesetzt und das Problem endgültig gelöst. Sowas nennt man Engagement. Bin eben kein Beamter mit einer Scheißegalhaltung. Und das ist ja das Problem auch mit Scrum: Man erwartet sonst was von diesem Prozess, aber was auf der Strecke bleibt, ist das Lösen des Problems in der Sache. Es genügt eben nicht, einen Prozess zu haben, und jeder füllt seine Rolle im Prozess aus. Ich sehe Parallelen zu Industrialisierung, als man aus Profitgründen die Arbeitsschritte so aufteilte, das jeder nur noch drei Handgriffe zu beherrschen brauchte. Das hat natürlich den Vorteil, der Effizienzsteigerung und auch der Arbeitssicherheit, weil die Leute trainiert sind, genau das eine zu tun. Aber es führte auch zu einer Entfremdung von der Arbeit. Will man das jetzt bei Software auch? Softwareentwicklung ist Geistesarbeit und lässt sich nicht in solchen Happen aufteilen, wie Scrum es verspricht oder wie sich manche Leute das vorstellen. Softwarenentwicklung ist auch keine Fließbandarbeit. Ich komme mit dem zyklomatischen Entwicklungsmodell viel besser zurecht. Ist übrigens auch iterativ und inkrementell. Es ist aber ohne Ringelpitz mit Anfassen, ohne soziale Gruppentänze. Der gesunde Menschenverstand darf eben nie auf der Strecke bleiben. Ein T. schrieb: > Wobei das Beste ja noch ist, daß ausgerechnet jene am Lautesten jammern, > die ihren eigenen Aussagen zufolge gar nicht mit Scrum arbeiten, sondern > das nur in anderen Teams beobachtet haben wollen. Also ich war in der Scrum-Mühle und weil es nicht funktionierte, wird aktuell ein Scrum light gemacht. Auch grober Unfug, aber man geht pragmatisch ran. Scrum ist einfach Murks.
Oben im Text schrieben Leute etwas zu Kaizen und Lean Management. So einen Berater hatten wir auch schon in der Firma, der das etablieren wollte. Und dann gab es Leitsätze für Lean Management in der Softwareentwicklung. Da wurde tatsächlich ausgearbeitet: "Jeder Schritt in der Softwareentwicklung muss neue Funktionalität hinzufügen." Ich empfand das als Absage an Refaktoring, also dass jemand das Gestrüpp mal der beseitigt und der Code sauberer wird. Das war wider alle Erfahrung. Dieser Lean-Quatsch hatte sich nach wenigen Monaten erledigt. Das war vor 14 Jahren. Der Berater von damals hat immer noch seine Beratungsfirma, aber Kaizen/Lean scheint kein Thema mehr zu sein. Der hat aber noch mehrere andere Sachen, wie z. B. Softskill-Geschichten, Führungstraining, Teamtrainig.
Rudi R. schrieb: > Ich sehe Parallelen zu Industrialisierung, als man aus Profitgründen die > Arbeitsschritte so aufteilte, das jeder nur noch drei Handgriffe zu > beherrschen brauchte. Das hat natürlich den Vorteil, der > Effizienzsteigerung und auch der Arbeitssicherheit, weil die Leute > trainiert sind, genau das eine zu tun. Aber es führte auch zu einer > Entfremdung von der Arbeit. Will man das jetzt bei Software auch? > Softwareentwicklung ist Geistesarbeit und lässt sich nicht in solchen > Happen aufteilen, wie Scrum es verspricht oder wie sich manche Leute das > vorstellen. Softwarenentwicklung ist auch keine Fließbandarbeit. Aus der Sicht der Manager ist ein nicht-entfremdeter Arbeitsprozess absolut nichts erstrebenswertes. Nichts fürchten Unternehmer und Manager so sehr wie auf (bestimmte) Mitarbeiter existenziell angewiesen zu sein. Deshalb wird man immer danach streben, die Prozesse so weit zu standardisieren, daß die Mitarbeiter relativ leicht austauschbar sind. Und es ist eine traurige Tatsache, dass BWLer die Softwareentwicklung als Fließbandarbeit verstehen. Ihre Denk- und Rechenkünste sind von der Art "Vier Schreiner bauen 5 Regale in 3 Tagen. Wie viele Regale bauen acht Schreiner in 12 Tagen?" oder "Vier Entwickler machen 12 User Stories in 14 Tagen. Berechnen sie die Velocity". Daß ein fleißiger Dummkopf langfristig mehr Schaden anrichtet als 10 faule Dummköpfe, sehen sie nicht. Die unterschiedliche Denke von Managern und Techies ist tragisch, aber real, genauso wie die Unterschiede von Männern und Frauen in Beziehungen.
Joe schrieb: > Die unterschiedliche Denke von Managern und Techies ist tragisch, aber > real, genauso wie die Unterschiede von Männern und Frauen in > Beziehungen. So ist es. Ich habe auch vorhin Ihren ersten Beitrag nochmal durchgelesen (Wo Sie auf Taylorismus eingehen.) und wollte das noch mal loben. Ich habe in den letzten Wochen auch öfter mal darüber nachgedacht und kam zu dem Schluss, dass es unterschiedliche Wertesysteme sind, die BWLer und Techies unterscheiden. BWLern geht es um Status, Dienstwagen, Hiercharchien, wie viele Leute man unter sich. Techies wollen interessante Aufgabenstellungen und Probleme lösen. Die Arbeit an sich macht Spaß. Natürlich muss auch das Gehalt stimmen, aber die Identifikation mit der Arbeit und der Spaß daran, das sind wichtige Dinge. Die BWLer legen ja ständig ihre Wertmaßstäbe an die Techies an. Ich war mal in einem Asssessmentcenter für IT-ler. Ist nun 15 Jahre her. Die suchten Softwareentwickler, Informatiker. Das Assessmentcenter klopfte aber Selbstdarstellung, Spontaneität und solchen Käse ab, als würden sie einen Verkäufer oder Constultant suchen. Das läuft ja falsch in Deutschland, dass die BWLer (eigentlich nur Kulturfolger) allen anderen ihre Wertmaßstäbe aufzwingen und den Karren an die Wand fahren, weil sie vom Kerngeschäft keine Ahnung haben. Man kann ja in Deutschland nur schwer eine Fachkarriere machen, Spezialist werden. Wird nicht goutiert. Man braucht dann Leute unter sich. Das Fachwissen eines DB-Experten, der fast alle Stellschrauben in Oracle kennt, um das Optimum herauszuholen, wird nicht goutiert. Und wenn er plötzlich Personalverantwortung bekommen soll, um aufsteigen zu können, dann verträgt sich das mitunter mit der Persönlichkeit dieser Koryphäe nicht. Die Techies legen ja auch nicht ihre Wertmaßstäbe an die BWLer an, an irgendwelche Verkäufer, die geschickt den Kunden alles mögliche andrehen. Als Techie (häufig introvertiert) ist man sich bewusst, dass sie auf die anderen (häufig extrovertiert) angewiesen sind, und dass man sich ergänzen kann und muss. Das ist der Fraktion der BWLer nicht bewusst.
Rudi R. schrieb: > Der Berater von damals hat immer noch seine Beratungsfirma, aber > Kaizen/Lean scheint kein Thema mehr zu sein. Der hat aber noch mehrere > andere Sachen, wie z. B. Softskill-Geschichten, Führungstraining, > Teamtrainig. Der hätte früher Wunderelixir an naives Landvolk verkauft und wäre mit seinem Karren über die Jahr- und Bauernmärkte gezogen. Heute sind die Scrummaster, Berater, Trainer und können gerade mal unfallfrei den Rechner einschalten.
Rudi R. schrieb: > Das läuft ja falsch in Deutschland, dass die BWLer (eigentlich nur > Kulturfolger) allen anderen ihre Wertmaßstäbe aufzwingen und den Karren > an die Wand fahren, weil sie vom Kerngeschäft keine Ahnung haben. Die gute Nachricht bzw. der einzige Trost ist vielleicht, daß man als Techie mit Geschäftssinn und Verkaufstalent gute Chancen hat, reich zu werden. "Der Ingenieur ist das Kamel, auf dem der Kaufmann zum Erfolg reitet" Der Kern des Streits ist vielleicht, daß die Manager das Scrum als etwas begreifen bzw. als etwas entdeckt haben, mit dem man die Techies an die Kandare nehmen kann. Der Techie kann jetzt nicht mehr einfach vor sich hintüfteln, sondern wird eingespannt und ist mit Heatmaps, Charts etc. Meß- und beobachtbar. Überflüssig, zu erwähnen, daß Qualität und Kreativität dabei aus dem Fokus geraten.
Also ich werfe mal in die Runde, das SCRUM eigentlich recht hilfreich sein kann, innerhalb eines Unternehmens die Kommunikationsflüsse zu steuern. Richtig angewendet vorrausgesetzt, natürlich und mit Einarbeitungsaufwand verbunden und den richtigen Menschen, an den richtigen Positionen. Passt nicht für alle Typen von Projekten, aber SCRUM für zb Anwendungsentwicklung sollte auch nur ein Entwicklungsstrang sein.Vorentwicklung/Core Entwicklung, die NICHT nach SCRUM arbeitet(oder nur sehr begrenzt die Aktivittäten dokumentiert) und Basis-Frameworks und Architekturen bereitstellt ein anderer. Auch das wurde weiter oben recht treffend beschrieben. Mein Liebling zu den stetigen Änderungen in der Arbeitswelt: https://teamentwicklung-lab.de/forming-storming-norming-performing-1 Das Resumee: Ist nicht einfach Schritt zu halten in der Arbeitswelt, war's noch nie. Habe mich damit abgefunden, das in 20Jahren die Entwickler die Hände über dem Kopf zusammenschlagen, wenn die meinen Code sehen - "Wie konnte der nur..." Offtopic: Der neueste Scheiß ist OKR. Echt hot. Schlussendlich soll das ganze ja dazu dienen, die Ziele eines Unternehmens sichtbar zu machen und komplexe Abläufe zu vereinfachen. DIese großen Ziele werden dann von den Verantwortlichen herunter gebrochen und ausdefiniert. Streng hierarchisch sollte das funktionieren, einen guten Überblick über das Ganze zu bekommen, wenn jeder max. 3 Ziele ausformuliert. Das ist dann SCRUM in anders. Bin mal gespannt. PS: Squad Owner = Team Lead
:
Bearbeitet durch User
Franko S. schrieb: > Als Freiberufler kann man sich regelmässig den Scrum-Zoo anschauen. Alles gut, ich schaue mir derweil den Freiberufler-Zoo an.
Rudi R. schrieb: > Ich weiß nicht, was die Sache mit dem Druckertreiber soll? Dann sind wir schon zu zweit. Ich weiß nämlich auch nicht, was die Sache mit dem Druckertreiber soll. Andererseits hatte ich gehofft, daß Du das wüßtest, schließlich hattest Du die Druckertreiber ja hier eingebracht. > Und das ist ja das Problem auch mit Scrum: Man erwartet sonst was von > diesem Prozess, aber was auf der Strecke bleibt, ist das Lösen des > Problems in der Sache. Es genügt eben nicht, einen Prozess zu haben, und > jeder füllt seine Rolle im Prozess aus. Ein Prozeß allein führt natürlich noch nicht zu einer Lösung. Aber es hatte und hat doch auch niemand behauptet, daß das so wäre. Außer Dir selbst sehe ich niemanden, der diese Erwartung geäußert hätte. Abgesehen davon helfen Prozesse, Wege zu den Lösungen zu organisieren. Das ist kein Alleinstellungsmerkmal agiler Methoden. Deren Alleinstellungsmerkmal ist nur, durch eine verbesserte Kommunikation flexibel auf Probleme und geänderte Rahmenbedingungen reagieren zu können. > und weil es nicht funktionierte, wird aktuell ein Scrum light gemacht. Ah, also beschwerst Du Dich in diesem Thread eigentlich gar nicht über Scrum, sondern über irgendeine seltsame Abart davon. Fassen wir das also mal zusammen: Du machst gar kein Scrum und beschwerst Dich auch gar nicht über Scrum, sondern machst und beschwerst Dich über irgendeine merkwürdige Abwandlung davon. Außerdem verweigerst Du Dich den Kollaborations- und Kommunikationswerkzeugen Deiner Teams und beklagst Dich dann darüber, daß die Kollaboration und die Kommunikation mit den Teams nicht funktioniert.
Joe schrieb: > Aus der Sicht der Manager ist ein nicht-entfremdeter Arbeitsprozess > absolut nichts erstrebenswertes. Nichts fürchten Unternehmer und Manager > so sehr wie auf (bestimmte) Mitarbeiter existenziell angewiesen zu sein. Das ist auch absolut richtig so, obgleich es den Technikern manchmal nicht gefällt. Aber zu den Aufgaben eines Management gehört es, die langfristige Überlebens- und Handlungsfähigkeit des Unternehmens sicherzustellen. Eine Abhängigkeit des Unternehmens von einzelnen Mitarbeitern kann fatale Folgen haben, nicht nur für die wirtschaftliche Existenz des Unternehmens, sondern auch für die seiner Mitarbeiter.
Ein T. schrieb: > Ein Prozeß allein führt natürlich noch nicht zu einer Lösung. Aber es > hatte und hat doch auch niemand behauptet, daß das so wäre. Außer Dir > selbst sehe ich niemanden, der diese Erwartung geäußert hätte. Um mal auf dem gleichen "hohen" Argumentationsniveau zu bleiben: Es scheint mir so, als ob du der Einzige bist, der nicht verstanden hat, worauf Rudi hinaus will. Ein Prozess kann auch hinderlich sein beim Lösen von Problemen. Etwa wenn er Probleme falsch aufteilt und den falschen Leuten die falschen Aufgaben zuteilt. Das Scrum wird m.E. u.a. deswegen zurecht kritisiert, weil es Nicht-Techies bestimmen läßt, welche Aufgaben in welcher Reihenfolge bearbeitet werden sollen. In Folge dessen wird das technische Produkt viele Jahresringe von User Stories haben, aber nicht unbedingt optimal durchdacht sein. Eine typische Reaktion auf Kritik an Scrum erinnert in der Tat an die Reaktion auf Kritik am Sozialismus: Es sei ganz einfach nicht der wahre Sozialismus bzw. nicht das wahre Scrum. Dieser Fehlschluss ist bestens auch als False-Scotsman-Fallacy bekannt. Damit zu argumentieren wirkt nicht sehr intelligent. Auch dort, wo die deiner Meinung nach "merkwürdigen Abwandlungen" von Scrum existieren, wird wohl von den lokalen "Imams" fest behauptet werden, es handle sich um das wahre Scrum, nur die Mitarbeiter seien nicht reif dafür. In dem Laden etwa, wo ich arbeite, beschweren sich sehr viele über Scrum - aber derjenige, der das eingeführt hat, wird den Teufel tun, zu sagen, es sei nicht das "wahre" Scrum.
Ein T. schrieb: > Absolut richtig so, obgleich es den Technikern manchmal > nicht gefällt. Aber zu den Aufgaben eines Management gehört es, die > langfristige Überlebens- und Handlungsfähigkeit des Unternehmens > sicherzustellen. Eine Abhängigkeit des Unternehmens von einzelnen > Mitarbeitern kann fatale Folgen haben, nicht nur für die wirtschaftliche > Existenz des Unternehmens, sondern auch für die seiner Mitarbeiter. Genau das meinte ich. Das ist ja das Dilemma: Aus Sorge um die langfristige Überlebens- und Handlungsfähigkeit des Unternehmens treffen Manager Entscheidungen, die nicht in ihre Kernkompetenz gehören. Man will keine "Diven", sondern Leute, die tun, was man ihnen sagt.
Joe schrieb: > Um mal auf dem gleichen "hohen" Argumentationsniveau zu bleiben: Es > scheint mir so, als ob du der Einzige bist, der nicht verstanden hat, > worauf Rudi hinaus will. Ich verstehe möglicherweise besser als Du, worauf er hinauswill: alle doof außer dem Erleuchteten, also ihm. > Ein Prozess kann auch hinderlich sein beim Lösen von Problemen. Etwa > wenn er Probleme falsch aufteilt und den falschen Leuten die falschen > Aufgaben zuteilt. Das Scrum wird m.E. u.a. deswegen zurecht kritisiert, > weil es Nicht-Techies bestimmen läßt, welche Aufgaben in welcher > Reihenfolge bearbeitet werden sollen. Ach, agile Methoden hieven Nichttechniker in Entscheidungspositionen und klassische nicht? Wie absurd. Bist Du der Zweitaccount von Dieter D.?
Joe schrieb: > Genau das meinte ich. Das ist ja das Dilemma: Aus Sorge um die > langfristige Überlebens- und Handlungsfähigkeit des Unternehmens treffen > Manager Entscheidungen, die nicht in ihre Kernkompetenz gehören. Ihre Kernkompetenz ist es, die Überlebens- und Handlungsfähigkeiten des Unternehmens sicherzustellen. Daß das mitunter mit dem kollidiert, was die Techniker wollen, ist zwar bedauerlich, liegt aber in der Natur der Sache, insbesondere auch deswegen, weil das Management nicht nur andere Prioritäten, sondern oft auch einen wesentlich besseren Überblick über die Gesamtsituation hat (und ihn jedenfalls haben sollte). Gutes Manager sagen ihren Technikern allerdings, warum eine Entscheidung gegen sie getroffen werden mußte. > Man will keine "Diven", sondern Leute, die tun, was man ihnen sagt. Man will ohnehin keine Diven. Die zerstören nur erst die Stimmung, dann die Motivation, und am Ende das Team.
Ein T. schrieb: > Ach, agile Methoden hieven Nichttechniker in Entscheidungspositionen und > klassische nicht? Wie absurd. Bist Du der Zweitaccount von Dieter D.? Nein, das ist alles andere als absurd: Der Fokus eines nichttechnischen Produkt Owners auf unmittelbare "Benefits" ist eine systematische Schwäche des Ansatzes. Ich kenne auch keinen Dieter D. Ist das jemand hier im Forum, der dir früher mal gesagt hat, daß du irrst? Gerne hingegen zitiere ich kurz aus einem Klassiker: "It has been a significant agile contribution to bring user stories to the forefront. (...) As a basis to development they lead to piecemeal systems, built to handle one function after the other without sufficient attention to the infrastructure." Bertrand Meyer, Agile!, Springer 2014 Ich erspare mir weitere Ausführungen, bevor ich nicht gesehen habe, daß eine Diskussion ohne Unterstellungen und ad hominem Angriffen möglich ist.
Ein T. schrieb: > das Management nicht nur andere > Prioritäten, sondern oft auch einen wesentlich besseren Überblick über > die Gesamtsituation hat (und ihn jedenfalls haben sollte) Ideal sind Kooperationen zwischen visionären Unternehmern und ebensolchen Techies. Nicht alles ist schwarz oder weiß. Ein Opernhaus braucht Diven und Kaufleute und Buchhalter.
Joe schrieb: > Ideal sind Kooperationen zwischen visionären Unternehmern und > ebensolchen Techies. Nicht alles ist schwarz oder weiß. Ein Opernhaus > braucht Diven und Kaufleute und Buchhalter. Paradebeispiel dafür ist ja gerade Apple mit Steve und Woz.
Cyblord -. schrieb: > Joe schrieb: >> Ideal sind Kooperationen zwischen visionären Unternehmern und >> ebensolchen Techies. Nicht alles ist schwarz oder weiß. Ein Opernhaus >> braucht Diven und Kaufleute und Buchhalter. > > Paradebeispiel dafür ist ja gerade Apple mit Steve und Woz. Jep. Das Traumpaar schlechthin.
Joe schrieb: > Nein, das ist alles andere als absurd: Der Fokus eines nichttechnischen > Produkt Owners auf unmittelbare "Benefits" ist eine systematische > Schwäche des Ansatzes. ...und würde sich in nichts von klassischen Ansätzen unterscheiden, wenn dort Nichttechniker technische Entscheidungen treffen. Nichtsdestotrotz ist es im Falle von Scrum so, daß der Product Owner zwar so heißt, er aber über keine direkte Weisungskompetenz gegenüber dem Team verfügt. Deswegen ist und bleibt es Aufgabe des Teams, auf eine saubere Infrastruktur zu achten. > Ich kenne auch keinen Dieter D. Ist das jemand hier im Forum, der dir > früher mal gesagt hat, daß du irrst? Das ist jemand hier im Forum, der häufig spät in Threads einsteigt, die er nicht gelesen hat, und dann durch absurde Behauptungen auffällt. Wenn Du dieses Forum häufiger nutzt, wirst Du ihm begegnen.
Ein T. schrieb: > ...und würde sich in nichts von klassischen Ansätzen unterscheiden, wenn > dort Nichttechniker technische Entscheidungen treffen. Nichtsdestotrotz > ist es im Falle von Scrum so, daß der Product Owner zwar so heißt, er > aber über keine direkte Weisungskompetenz gegenüber dem Team verfügt. > Deswegen ist und bleibt es Aufgabe des Teams, auf eine saubere > Infrastruktur zu achten. Ich bin zugegebenermaßen etwas verwundert, weil mir nicht bekannt ist, daß technische Architekturentscheidungen bei "klassischen Ansätzen" ausdrücklich durch Nichttechniker gefällt werden sollen. Kannst Du da was zu zitieren? Zu Scrum habe ich nochmal gegoogelt: https://scrumguide.de/product-owner/ "Der Product Owner ist immer derjenige, der die Interessen aller Beteiligten in Product Backlog Items umwandelt und festlegt, welche davon am wichtigsten sind und daher vom Projektteam zuerst bearbeitet werden müssen. Sowohl das Unternehmen als auch die externen Stakeholder haben zu akzeptieren, dass er diese Entscheidungen trifft. Andernfalls bekommt er nicht genügend Raum, seine Aufgaben gut ausführen zu können." Mit anderen Worten: Der Product Owner entscheidet, was *bis wann* gemacht werden muß und das Entwicklerteam hat nur den Entscheidungsspielraum, wie es umgesetzt wird. Das ist ein Kerngedanke von Scrum - genauso habe ich es mir auch von den Scrum-Typen, die bei uns vor 1 Jahr im Haus rumliefen, bestätigen lassen. Und genau das ist die Krux. Hier liegt konkret eine Schwäche des agilen Ansatzes vor. Bertrand Meyer als Koryphäe für Software Engineering habe dazu ich ja weiter oben schon kurz zitiert. Man kann sich das mit einer Analogie veranschaulichen: Ein Product Owner, der wenig von Statik versteht, würde immer festlegen, was als nächstes am Haus gemacht werden müßte: Diese Woche die Einbauküche, damit die Hausherren schon mal ihr eigenes Essen kochen könnten, nächste Woche dann der Dachstuhl gezimmert, dann die Wasseranschlüsse gemacht, anschließend der Keller gegraben, dann wieder die Fliesen in der Küche usw. usw. >> Ich kenne auch keinen Dieter D. Ist das jemand hier im Forum, der dir >> früher mal gesagt hat, daß du irrst? > > Das ist jemand hier im Forum, der häufig spät in Threads einsteigt, die > er nicht gelesen hat, und dann durch absurde Behauptungen auffällt. Wenn > Du dieses Forum häufiger nutzt, wirst Du ihm begegnen. Nachdem sich die Threads hier auch gerne im Kreis drehen ist es relativ egal, wann man einsteigt. Oder? Absurde Behauptungen habe ich keine aufgestellt. Obwohl ich dir alles mögliche an den Kopf werfen könnte, brauche ich keine Polemik, sondern argumentiere sachlich. Meine Empfehlung wäre, nachzufragen, was der andere gemeint haben könnte, bevor man pöbelt. Insbesondere dann, wenn man selbst immer die "Kommunikation" und "soziale Kompetenz" so hochhält.
Joe schrieb: > Ein T. schrieb: >> ...und würde sich in nichts von klassischen Ansätzen unterscheiden, wenn >> dort Nichttechniker technische Entscheidungen treffen. > > Ich bin zugegebenermaßen etwas verwundert, weil mir nicht bekannt ist, > daß technische Architekturentscheidungen bei "klassischen Ansätzen" > ausdrücklich durch Nichttechniker gefällt werden sollen. Tatsächlich besteht dazu keine zwingende Notwendigkeit (wie das Wort "wenn" in meinem Satz andeutet), aber es kommt in der Praxis ausgesprochen häufig vor. Von allen Projektleitern, mit denen ich im Laufe der Jahre zusammengearbeitet habe, hatten geschätzt 60% keinen technischen Hintergrund und weitere 20% zwar einen solchen, aber in einem ganz anderen Bereich. > Zu Scrum habe ich nochmal gegoogelt: [...] > [...] genauso habe ich es mir auch von den Scrum-Typen, die bei > uns vor 1 Jahr im Haus rumliefen, bestätigen lassen. Du selbst verfügst also über keinerlei praktische Erfahrungen. > https://scrumguide.de/product-owner/ > "Der Product Owner ist immer derjenige, der die Interessen aller > Beteiligten in Product Backlog Items umwandelt und festlegt, welche > davon am wichtigsten sind und daher vom Projektteam zuerst bearbeitet > werden müssen. Sowohl das Unternehmen als auch die externen Stakeholder > haben zu akzeptieren, dass er diese Entscheidungen trifft. Andernfalls > bekommt er nicht genügend Raum, seine Aufgaben gut ausführen zu können." > > Mit anderen Worten: Der Product Owner entscheidet, was *bis wann* > gemacht werden muß Von "bis wann" steht dort allerdings nichts, und auch nichts davon, daß das Team diese Entscheidungen widerspruchslos akzeptieren müsse. Beides hast Du nur in die gegoogelten Texte hineininterpretiert. Du erwartest hoffentlich nicht, daß ich auf Strohmann-Argumente eingehe, daher nur soviel dazu: der Product Owner gehört selbst zu jenem Team, das gemeinsam entscheidet. Allerdings ist mir aufgefallen, daß es hierarchisch sozialisierten Menschen mitunter schwer fällt, kooperative Kollaborationsmodelle zu verstehen, sogar wenn sie es wollen. Praktische Erfahrung hilft aber meist schnell. > Nachdem sich die Threads hier auch gerne im Kreis drehen ist es relativ > egal, wann man einsteigt. Oder? Absurde Behauptungen habe ich keine > aufgestellt. Hoffentlich kannst Du akzeptieren, daß ich zu beiden Punkten eine andere Position vertrete. Aber so ist es ja leider oft, wenn Gegoogeltes auf die Erfahrungen aus der praktischen Realität trifft.
Joe schrieb: > Man kann sich das mit einer Analogie veranschaulichen: Ein Product > Owner, der wenig von Statik versteht, würde immer festlegen, was als > nächstes am Haus gemacht werden müßte: Diese Woche die Einbauküche, > damit die Hausherren schon mal ihr eigenes Essen kochen könnten, nächste > Woche dann der Dachstuhl gezimmert, dann die Wasseranschlüsse gemacht, > anschließend der Keller gegraben, dann wieder die Fliesen in der Küche > usw. usw. Die Erfahrung hat schon immer den Unterschied gemacht und es ist einfach Glückssache, mit wem man dann schlussendlich im Sandkasten landet. Ein T. schrieb: > Von allen Projektleitern, mit denen ich im > Laufe der Jahre zusammengearbeitet habe, hatten geschätzt 60% keinen > technischen Hintergrund und weitere 20% zwar einen solchen, aber in > einem ganz anderen Bereich. Sehe ich auch so. Ich finde deine durchgehende Argumentationskette bisher am schlüssigsten und ich konnte bisher tatsächlich keinen Punkt erkennen, der wirklich GEGEN SCRUM spricht. Was mich allerdings etwas stört, ist die Tatsache, das manche Leute sich manchmal so an einer Sache fest beißen und immer auf der eigenen Sichtweise zu dem Thema bestehen. Vermutlich werde ich dafür gelyncht, aber die einzige Differenz die ich beobachten kann zwischen euch zwei ist, das ihr vermutlich aus zwei verschiedenen Unternehmen und somit aus zwei verschiedenen Arbeitswelten kommt. Wieso kann nicht das eine neben dem anderen existieren? SCRUM ist sicherlich nicht das Allheilmittel und passt nicht für alle Projekttypen(Ja, ja wir machen dann kein richtiges SCRUM, schon klar). Genauso gibt es eben Projekte, wofür SCRUM gut geeignet ist und die angwendeten Methoden sinnvoll sind. Geistige Flexibilität ist das, was einen gesunden Menschenverstand ausmacht. Wenn es mir nicht in einem Unternehmen gefällt, wie ich meine Arbeitskraft einbringen kann,dann suche ich mir halt ein Unternehmen wo es mir gut geht. So einfach ist das. Eine Meinung zum Thema SCRUM haben heißt ja nicht, das man sich für das LIcht oder die Dunkelheit entscheiden muss. Wir sind hier nicht in der Kirche. PS. Eine beschissene Architektur können noch so ausgefeilte Methoden nicht kompensieren.
:
Bearbeitet durch User
Ein T. schrieb: > Von "bis wann" steht dort allerdings nichts, und auch nichts davon, daß > das Team diese Entscheidungen widerspruchslos akzeptieren müsse. Beides > hast Du nur in die gegoogelten Texte hineininterpretiert. Du erwartest > hoffentlich nicht, daß ich auf Strohmann-Argumente eingehe, daher nur > soviel dazu: der Product Owner gehört selbst zu jenem Team, das > gemeinsam entscheidet. Der P.O. legt u.a. auch die zeitliche Prio von Aufgaben fest. Eine Konsequenz davon ist eine Tendenz zur Fokussierung weg von Domänen- und Architekturthemen hin zu "Features" und "Benefits". Und ein Kernmerkmal von Scrum ist die Trennung bestimmter Rollen (auch wenn dann doch alle irgendwie zusammen gehören und ein Team sind). Das ist unzählige Male beschrieben worden. > Allerdings ist mir aufgefallen, daß es hierarchisch sozialisierten > Menschen mitunter schwer fällt, kooperative Kollaborationsmodelle zu > verstehen, sogar wenn sie es wollen. Praktische Erfahrung hilft aber > meist schnell. Praktische Erfahrung ist immer sehr subjektiv und der Satz mit den hierarchisch sozialisierten Menschen ist eine Generalisierung von der Art "Nach meiner Erfahrung aus 5 Ehen nach tendieren Frauen dazu, ..." oder "Als Weltgereister sage ich: Dem Asiaten fällt es mitunter schwer, ...". Was soll man auf solche Einlassungen antworten? Wir reden hier perfekt aneinander vorbei. Ich versuche, den Ansatz durch Studium der theoretischen Beschreibungen zu verstehen - und Du kommst daher in der Art "Da mag vielleicht in der Theorie nicht funktionieren, aber in meiner erlebten Praxis schon". Es gibt genug andere Erfahrungen, die in eine anderen Richtung gehen, und da wird es schon interessant, wenn man sich die Theorie anschaut. Da bleibt der Vergleich mit einer Religion nicht weit. Man studiert hier vielleicht die kanonischen Texte, um zu verstehen. Konfrontiert mit Aussagen aus solchen Texten heißt es dann vom Adepten "Sie dürfen die Texte nicht wörtlich nehmen".
Joe J. schrieb: >SCRUM ist sicherlich nicht das Allheilmittel und > passt nicht für alle Projekttypen(Ja, ja wir machen dann kein richtiges > SCRUM, schon klar). Genauso gibt es eben Projekte, wofür SCRUM gut > geeignet ist und die angwendeten Methoden sinnvoll sind. So wie es da steht, kann ich es natürlich nur unterschreiben. Mein "Beef" mit Scrum geht in die Richtung, daß es gerne als Allheilmittel verschrieben wird, von Managern aufoktroyiert wird und als System verwendet wird, einen kreativen und komplizierten Prozess wie Softwareentwicklung in eine Dauerhektik von kleinen Sprints zu verwandeln. Gunter Dueck vergleicht gerne Manager mit Hunden (Herdentiere und gehorsam) und Techies mit Katzen (Einzelgänger und eigenwillig). Er beschreibt Agile aus einen Versuch der Hunde, den Katzen das Apportieren beizubringen, bzw. als Versuch der BWLer, den Ingenieuren ihre Methoden aufzuzwingen.
Uwe D. schrieb: > Und ehrlich, wenn Ihr zu blöd seid ein Daily auf > zwei Tage pro Woche einzusparen, Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur ihre reine Nettozeit, sondern auch vor- und Nachbereitung und daran hängt es, um die ausgetauschten Infos für andere nutzbar sind, oder nicht und ob das, was man von anderen hört, genutzt werden kann, oder nicht. Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau verschiebt. Die anderen sehen dabei zu, haben aber nichts davon, da sie mit diesen Aufgaben nichts zu tun haben. Am Ende haben 7 Leute 3min berichtet, wo sie stehen und 18 min gewartet. Mit Start Stopp sind dann 20min weg, die man nicht mal so eben wieder reinholt. Wenn dann noch ein paar inhaltliche Fragen geklärt werden, hast du wieder den Fall, dass maximal die Hälfte etwas beitragen kann, während die andere lauscht. Und dann bläht das richtig auf. Diese Meetings laufen sehr oft wie ein Multiprozessorsystem mit 8 Teilnehmern, die abwechselnd einen einzigen Bus belegen, während alle anderen idle sind und Zeit verbraten. Zeit, die man besser nutzen könnte. Der einzige, der etwas davon hat, ist der Projektleiter, der schauen kann, ob die Jungs noch on track sind. Das aber könnte er auch einmal die Woche. Ich halte es daher für zweckmäßiger, dass nur diejenigen an solchen Meetings teilnehmen, die wirklich etwas beizutragen haben oder Entscheidungen treffen müssen, wofür sie andere benötigen. Man kann, wenn man unbedingt den Stand des anderen benötigt, auch selber aktiv ins board schauen und den Stand der Aufgaben ansehen, ohne dass da andere mit geblockt werden. Das gleiche gilt für Infos: Die verteilt man proaktiv in dem Moment, wo sie anfallen zielgerichtet an die 2 die es brauchen und nicht erst an alle und auch nicht erst am nächsten Tag. Auch eine Entscheidung schiebe ich nicht auf den nächsten Tag, wenn ich sie mit einer anderen Person zusammen fällen kann. Es muss nicht jeder zu jedem Zeitpunkt alles mitbekommen! Das ist nur dann nötig, wenn wirklich eine sehr kleine Gruppe an einer größeren Aufgabe dran ist und es viele Fragen und Schnittstellen zwischen den Bearbeitern gibt. Der klassische Fall ist eben eine Gruppe von Programmiereren die ein Paket entwickeln. Für alles andere taugt SCRUM einfach nicht.
Joe J. schrieb: > Sehe ich auch so. Ich finde deine durchgehende Argumentationskette > bisher am schlüssigsten und ich konnte bisher tatsächlich keinen Punkt > erkennen, der wirklich GEGEN SCRUM spricht. Vielen Dank für die Blumen! :-) > Was mich allerdings etwas stört, ist die Tatsache, das manche Leute sich > manchmal so an einer Sache fest beißen und immer auf der eigenen > Sichtweise zu dem Thema bestehen. Vermutlich werde ich dafür gelyncht, > aber die einzige Differenz die ich beobachten kann zwischen euch zwei > ist, das ihr vermutlich aus zwei verschiedenen Unternehmen und somit aus > zwei verschiedenen Arbeitswelten kommt. Ich sehe keinerlei Veranlassung für eine Lynchjustiz, denn mein Eindruck ist das ebenfalls. Allerdings komme ich aus einem... äh, "hybriden" Unternehmen, das heißt, daß wir uns an der Arbeitsweise unserer Kunden orientieren. Darum verwenden wir bei internen Projekten Scrum. Bei Projekten mit direktem Bezug zum Kunden machen wir das, was der Kunde bevorzugt, und je nach Kunde ist es dann eben ein klassischer oder ein agiler Ansatz, in diesem Falle fast immer Scrum. Da es dabei aber immer um dasselbe Kernthema geht -- Betrugsprävention in Echtzeit -- ergibt sich für uns eine recht gute Übersicht, was besser funktioniert, und unsere Erfahrung ist, daß agile Methoden meistens besser funktionieren. > PS. Eine beschissene Architektur können noch so ausgefeilte Methoden > nicht kompensieren. Das "meistens" steht dort aus einem bestimmten Grund, denn gegen Stinker im Projekt helfen Methoden des Projektmanagament leider ebenso wenig wie gegen überhöhte Erwartungen und andere Torpedos, und ebensowenig natürlich gegen verhunzte Architekturen oder ähnliche Probleme. Allerdings ist es agil nach meiner Erfahrung viel häufiger möglich, verhunzte Teilaspekte zu korrigieren. In klassischen Projekten stemmt sich mitunter ein Projektleiter dagegen, weil er die Notwendigkeit als weniger akut bewertet, er den Druck seiner Vorgesetzten zu Fertigwerden bekommt und ihn weitergibt. Wenn ein ganzes Team dahinter steht und erklärt, daß der Umbau jetzt nötig sei, hat das oft eine viel überzeugendere Wirkung auf Vorgesetzte und Kunden als wenn diese undankbare Aufgabe einem einzelnen Projektleiter zufällt.
Joe schrieb: > Der P.O. legt u.a. auch die zeitliche Prio von Aufgaben fest. Das Team legt das fest, und der PO ist Teil des Teams. > Eine > Konsequenz davon ist eine Tendenz zur Fokussierung weg von Domänen- und > Architekturthemen hin zu "Features" und "Benefits". Und ein Kernmerkmal > von Scrum ist die Trennung bestimmter Rollen (auch wenn dann doch alle > irgendwie zusammen gehören und ein Team sind). Das ist unzählige Male > beschrieben worden. Das hängt vom Team ab, dessen Zusammenstellung -- genau wie bei klassischen Ansätzen auch -- wesentlich für den Erfolg des Projekts ist. Darüber hinaus betrifft das nicht nur agile Methoden, denn in klassischen Projekten hängen Gedeih und Verderb primär an wenigen Einzelpersonen. Agile Projekte dagegen versuchen, die Kenntnisse und Erfahrungen aller Teammitglieder zu nutzen. Selbstverständlich klappt das nicht immer, aber das tun klassische Projekte bekanntlich auch nicht. Ein Grund für die Entwicklung der agilen Methoden war ja schließlich, daß damals je nach Studie 65-75 Prozent der Projekte an ihren Zeit- und / oder Budgetgrenzen gescheitert waren. > Wir reden hier perfekt aneinander vorbei. Ich versuche, den Ansatz durch > Studium der theoretischen Beschreibungen zu verstehen Die meisten der theoretischen Beschreibungen, die ich bisher gehört oder gelesen habe, bestehen im Wesentlichen aus Bullshit-Bingo. Das ist es, was ich meine: ob, wie und wie gut agile Methoden in der Praxis funktionieren, stellt sich erst in der Praxis heraus. Leider lassen sich diese Methoden darum ohne praktische Erfahrungen kaum bis gar nicht seriös beurteilen. Im Wesentlichen ist die Nummer ziemlich einfach: es geht darum, durch eine formalisierte Kommunikation den Informationsfluß und die Zusammenarbeit im Projekt zu optimieren und die Erfahrungen aller Beteiligten zu nutzen. Und ganz unter uns: ich sitze lieber in ein paar gefühlt unnützen Meetings als kurz vor der Ziellinie eines Projekts feststellen zu müssen, daß irgendwie eine wichtige Information verloren gegangen ist und jetzt schnellstmöglich noch eingearbeitet werden muß.
Ein T. schrieb: > Das hängt vom Team ab, dessen Zusammenstellung -- genau wie bei > klassischen Ansätzen auch -- wesentlich für den Erfolg des Projekts ist. Das ist natürlich richtig - aber auch eine Tautologie. > Darüber hinaus betrifft das nicht nur agile Methoden, denn in > klassischen Projekten hängen Gedeih und Verderb primär an wenigen > Einzelpersonen. Agile Projekte dagegen versuchen, die Kenntnisse und > Erfahrungen aller Teammitglieder zu nutzen. Das habe ich wiederum anders erlebt in meinem kurzen Scrum-Leben. Es gibt erfahrerene ITler und weniger Erfahrene. Und leider gibt es keine Arithmetik in der Art "drei Juniors == 1 Senior". Der Kollege, der den Thread aufgemacht hat, hat sich beklagt, daß in den Meetings alle mögliche Betriebsamkeit herrscht, aber wenn er dann einem systematischen Vorschlag macht, etwa den Einsatz bestimmter Entwurfsmuster, dann wird abgepfiffen, weil die eine Hälfte nichts davon versteht und die andere Hälfte gleich in´s nächste Meeting muß. Ähnliche Erfahrungen habe ich auch gemacht. Auf der einen Seite muß jeder zu jedem Ticket in Daily sein Sprüchlein aufsagen (und dabei die anderen langweilen), aber wenn man ein bißchen tiefer geht, dann wird gleich abgepfiffen. "Das sprengt hier den Rahmen. Wenn, dann lade zu einem extra Meeting dazu sein" "So wie unsere Terminkalender sind, geht da frühestens übernächste Woche was". Ähnlich beim Planungspoker: Man soll aus dem Stegreif den Umfang einer bestimmten User-Story benennen. Da komme ich mir vor wie bei einer Schnellversteigerung. Wenn einer eine abweichende Meinung hat, und diese genau begründet, dann, s.o., wird auch abgepfiffen. Was mir abgeht, ist, daß man mal sich einen Tag zu zweit oder dritt in ein Büro zurückzieht und systematisch entwirft. Ich bin selbst jenseits der 50 und Dipl.Inf, könnte also mit dem einen oder anderen Junioren fachsimpeln und dann etwas richtig gutes entwerfen. > Die meisten der theoretischen Beschreibungen, die ich bisher gehört oder > gelesen habe, bestehen im Wesentlichen aus Bullshit-Bingo. Ich habe mir das Buch Agile! von Bertrand Meyer kommen lassen und lese es gerade. Ein fundierteres Werk zu dem Thema scheint es nicht zu geben. Mit Google findet man dann auch, was man als kanonische Skripten bezeichnen könnte, also vielleicht Beschreibungen von Schwaber/Sutherland persönlich. Dann bleiben noch unzählige Fundstellen und Homepages von Beratungsfirmen, also der ganze agile Wirtschaftsraum. Freilich ist das Bullshit-Bingo, habe ich ja weiter oben schon mal angemerkt, daß solche Berater-Leute eine völlig stereotypische Sprechweise haben und manche davon haben mir ehrlich gesagt wie gehirngewaschen gewirkt. Können wir uns darauf einigen, daß Scrum in bestimmten Konstellationen eine gute Sache sein kann: Gutes Team, Aufgaben, die voneinander abhängig sind, die Chance von Junioren, sich regelmäßig Unterstützung abholen zu können. In anderen Situationen ist es Sand im Getriebe: Schwierige Themen, die parallel eingekippt werden, Aufgaben, die jeder in einem Team von Seniors am besten eigenständig lösen kann, und dann nur einmal vorstellen braucht. Insgesamt halte ich Scrum für einen ungeeigneten Weg, um mit der Arbeitsverdichtung umzugehen. "Operative Hektik ersetzt geistige Windstille" fällt mir dazu ein. Und dann noch einer aus dem Agile!-Buch: "What is good, is not new, and what is new, is not good".
Joe schrieb: > Joe J. schrieb: >>SCRUM ist sicherlich nicht das Allheilmittel und >> passt nicht für alle Projekttypen(Ja, ja wir machen dann kein richtiges >> SCRUM, schon klar). Genauso gibt es eben Projekte, wofür SCRUM gut >> geeignet ist und die angwendeten Methoden sinnvoll sind. > > So wie es da steht, kann ich es natürlich nur unterschreiben. > > Mein "Beef" mit Scrum geht in die Richtung, daß es gerne als > Allheilmittel verschrieben wird, Dann ist Dein Problem also nicht Scrum, sondern die Werbung dafür. Werbung sagt aber eher wenig über die Nützlichkeit eines Produktes. > von Managern aufoktroyiert wird Vor dem Hintergrund, daß im klassischen Projektmanagement jedem Projekt ein eigener Manager aufoktroyiert wird, ist das ein besonders lustiger Einwand. > und als > System verwendet wird, einen kreativen und komplizierten Prozess wie > Softwareentwicklung in eine Dauerhektik von kleinen Sprints zu > verwandeln. Ganz im Gegenteil wird der Prozeß kreativer und oft sogar einfacher, wenn die Kenntnisse und Erfahrungen der Beteiligten kombiniert werden. Die Sprints sind auch keineswegs hektisch, sondern nur Zeiträume bis zu Punkten, an denen der jeweils aktuelle Stand der Beteiligten betrachtet und koordiniert wird. Kommst Du wie geplant voran? Haben sich unerwartete Probleme aufgetan? Kannst Du mir helfen, oder ich Dir? Im Prinzip geht es dabei um ähnliche Themen wie die, die klassischerweise der Projektleiter bearbeitet, nur daß die bei agilen Methoden eben gemeinsam angegangen werden.
Ein T. schrieb: > Dann ist Dein Problem also nicht Scrum, sondern die Werbung dafür. > Werbung sagt aber eher wenig über die Nützlichkeit eines Produktes. Das Aufoktroyierte ist das Schlimme. So wie wenn die Dame des Hauses sich bunte Pillen aufschwätzen lässt und von der ganzen Familie verlangt, diese regelmäßig und in großen Mengen einzunehmen.
J. S. schrieb: > Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur > ihre reine Nettozeit, sondern auch vor- und Nachbereitung Huch... > Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master > den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau > verschiebt. ...und dafür brauchst Du eine "Vor- und Nachbereitung"? Ui.
Joe schrieb: > Ähnliche Erfahrungen habe ich auch gemacht. Auf der einen Seite muß > jeder zu jedem Ticket in Daily sein Sprüchlein aufsagen Es scheinen merkwürdige Vorgehensweisen als "Scrum" bezeichnet zu werden. > Was mir abgeht, ist, daß man mal sich einen Tag zu zweit oder dritt in > ein Büro zurückzieht und systematisch entwirft. Ich bin selbst jenseits > der 50 und Dipl.Inf, könnte also mit dem einen oder anderen Junioren > fachsimpeln und dann etwas richtig gutes entwerfen. Auch in agilen Projekten spricht nichts dagegen, so etwas zu machen. Ich bin übrigens auch über 50 und mache das ziemlich oft. Für Wissensvermittlung und detaillierte Planungen sind die Daily Standups nicht gedacht.
Ein T. schrieb: > Es scheinen merkwürdige Vorgehensweisen als "Scrum" bezeichnet zu > werden. Real existierendes Scrum halt. Eingeführt von realen zertifizierten Scrum***ioten, die saftige Rechnungen schreiben. Wobei wir wieder bei der Frage wären, was Scrum eigentlich ist. *Was kann nicht weglassen, ohne daß es dann kein Scrum mehr ist?* Solange das nicht genau definiert ist, wird uns die No-true-Scotsman-fallacy immer einholen.
Joe schrieb: > Real existierendes Scrum halt. Eingeführt von realen zertifizierten > Scrum***ioten, die saftige Rechnungen schreiben. Dabei ärgert mich nur dass ich selbst nicht so einer bin.
Joe schrieb: > Das Aufoktroyierte ist das Schlimme. Und ein nicht weniger aufoktroyierter Projektleiter, der allen Mitgliedern des Teams dann seinerseits aufoktroyiert, was sie bis wann wie (und bisweilen auch wo) zu tun haben, das erscheint Dir weniger schlimm?
Ein T. schrieb: > Dann sind wir schon zu zweit. Ich weiß nämlich auch nicht, was die Sache > mit dem Druckertreiber soll. Andererseits hatte ich gehofft, daß Du das > wüßtest, schließlich hattest Du die Druckertreiber ja hier eingebracht. Es geht um Ihren Angriff ad hominem in dieser Sache. Die Geschichte mit dem Druckertreiber zeigt eine Problemlösung ohne viel Allüren. Da Sie sich abschätzig äußerten, muss ich davon ausgehen, dass Sie die Nase etwas höher tragen und dies als minderwertige Arbeit ansehen. Was halten Sie eigentlich von Reinigungskräften? Joe J. schrieb: > Ein T. schrieb: >> Von allen Projektleitern, mit denen ich im >> Laufe der Jahre zusammengearbeitet habe, hatten geschätzt 60% keinen >> technischen Hintergrund und weitere 20% zwar einen solchen, aber in >> einem ganz anderen Bereich. > > Sehe ich auch so. Ich finde deine durchgehende Argumentationskette > bisher am schlüssigsten und ich konnte bisher tatsächlich keinen Punkt > erkennen, der wirklich GEGEN SCRUM spricht. Als Projektleiter ist man zwischen den Fronten und dazu muss man kein Techniker sein. Die Persönlichkeitsstruktur vieler MINTler würde dazu auch gar nicht passen, weil die ja fokussiert arbeiten müssen. MINTler sind in der Regel introvertiert, Projektleiter extrovertiert. Ein kluger Projektleiter schaufelt seinen MINTlern die entsprechenden Freiräume für Problemlösungen ein, hält nicht ständig Meetings ab. Softwareentwickler müssen arbeiten können. Meine Scrum-Erfahrungen waren überwiegend negativ, weil vieles nervte. Ein T. schrieb: > Ganz im Gegenteil wird der Prozeß kreativer und oft sogar einfacher, > wenn die Kenntnisse und Erfahrungen der Beteiligten kombiniert werden. > Die Sprints sind auch keineswegs hektisch, sondern nur Zeiträume bis zu > Punkten, an denen der jeweils aktuelle Stand der Beteiligten betrachtet > und koordiniert wird. Kommst Du wie geplant voran? Haben sich > unerwartete Probleme aufgetan? Kannst Du mir helfen, oder ich Dir? Im > Prinzip geht es dabei um ähnliche Themen wie die, die klassischerweise > der Projektleiter bearbeitet, nur daß die bei agilen Methoden eben > gemeinsam angegangen werden. Was ich erlebte, war eher die Dauerhektik. Scrum ist nicht Voraussetzung für kooperatives Arbeiten und auch nicht förderlich. Kooperatives Arbeiten hängt von den Personen ab, von der Unternehmenskultur. Bei uns in der Firma helfen sich die Leute ständig. Kreativität habe ich im Scrum-Prozess wenig bis gar nicht erlebt. Die meisten waren darauf konditioniert, ihr Sprintziel zu erreichen. Für grundsätzliches Nachdenken und Fachsimpeln war keine Zeit. Ich habe auch schon erlebt, wie die Scrum-Masterin ein "Swarming" einberief, und dann konnte alle Entwickler an einem Freitagnachmittag bei jemanden auf den Bildschirm schauen und sie sollten ein Problem lösen. Eine extrem teure Angelegenheit. Und das war künstlich hervorgerufen, weil das Sprintende nahte. Warum nicht einfach unfertiges Committen? Habe ich im Projekt öfter angemahnt: Pusht den Kram, dass es jeder hat. Dann kann jeder, der will, im Source-Code wühlen und den Fehler beheben, eine Erklärung geben, warum es falsch war Es ist doch vollkommener Unfug mit drei, vier Entwicklern gemeinsam auf Source-Code zu schauen und der Herr über Maus u. Tastatur springt ständig erratisch hin und her und ein anderer quatscht ständig rein. Joe schrieb: > Der P.O. legt u.a. auch die zeitliche Prio von Aufgaben fest. Eine > Konsequenz davon ist eine Tendenz zur Fokussierung weg von Domänen- und > Architekturthemen hin zu "Features" und "Benefits". Gut beschrieben und das beschreibt ungefähr das, was ich in dem Projekt erleben durfte, das mich veranlasste, diese Diskussion zu starten. Da griffen die Entwickler gerade das, was gerade genehm war. Für grundsätzliche Dinge war keine Zeit. Für Bug fixing und Refaktorieren auch nicht. Das Projektteam komplett abgelöst. Ich war ja später hinzugekommen und meine Meldung, dass das mächtig scheitern würde, veranlasste, dass es heute andere Leute machen und ich bin dabei. Wir haben heute zwar Sprints, aber kein SCRUM. Einige würden sagen: "Scrum extra light." Ich würde sagen: Es ist Entwicklung mit gesunden Menschenverstand. Die Scrum-Masterin hat übrigens das Weite gesucht. Ein T. schrieb: > Das hängt vom Team ab, dessen Zusammenstellung -- genau wie bei > klassischen Ansätzen auch -- wesentlich für den Erfolg des Projekts ist. > Darüber hinaus betrifft das nicht nur agile Methoden, denn in > klassischen Projekten hängen Gedeih und Verderb primär an wenigen > Einzelpersonen. Agile Projekte dagegen versuchen, die Kenntnisse und > Erfahrungen aller Teammitglieder zu nutzen. Selbstverständlich klappt > das nicht immer, aber das tun klassische Projekte bekanntlich auch > nicht. Ein Grund für die Entwicklung der agilen Methoden war ja > schließlich, daß damals je nach Studie 65-75 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert waren. Es hängt sowohl in agilen als auch in klassischen Ansetzen von den Leuten ab. Und Scrum ist auch nicht einzige agile Modell. Was das Reißen von Zeit- und Budgetgrenzen angeht, da dürfte sich heute nicht viel verbessert haben. Ein T. schrieb: > Auch in agilen Projekten spricht nichts dagegen, so etwas zu machen. Ich > bin übrigens auch über 50 und mache das ziemlich oft. Für > Wissensvermittlung und detaillierte Planungen sind die Daily Standups > nicht gedacht. Ich spricht grundsätzlich nichts dagegen, aber meiner Erfahrung konditioniert Scrum die Entwickler, schnell mal irgendwelchen Pfusch abzuliefern, weil das Sprintende naht. Ich bin ja sogar der Meinung, dass es vielen Entwicklern gut täte, Kolloquien abzuhalten. Es kann doch nicht sein, dass Entwickler durch die Gegend laufen, die nicht wissen, was die Entwurfsmuster Adapter, Beobachter und Dekorierer sind. Es sollten ständig solche Thematiken in angenehmer Atmosphäre behandelt werden. Aber dann kommt die BWLer-Fraktion und meckert, weil das unproduktive Stunden seien. Ein T. schrieb: > Du Dich den Kollaborations- und Kommunikationswerkzeugen Deiner Teams > und beklagst Dich dann darüber, daß die Kollaboration und die > Kommunikation mit den Teams nicht funktioniert. Das ist schlichtweg gelogen. Ein T. schrieb: > Allerdings ist mir aufgefallen, daß es hierarchisch sozialisierten > Menschen mitunter schwer fällt, kooperative Kollaborationsmodelle zu > verstehen, sogar wenn sie es wollen. Und das ist schlichtweg Unsinn. Hierarchisch orientierte Menschen werden selten Softwareentwickler. Hierarchie- und Statusdenken wird bei Ärzten, Juristen und BWLer groß geschrieben, während in den Entwicklungsabteilungen flache Hierarchien herrschen und die Leute mit Doktortitel diesen nicht ständnig mit Monstranz vor sich her tragen. Ich habe bzw. hatte Kollegen wie Vorgesetzte, die da nie Aufhebens drum machen bzw. machten. Es sind doch die Entwickler, die sich über Scrum beschweren. Mich interessiert eine Hierarchie nicht, auch keine Hackordnung. Ich will einfach nur das beste geben, lasse mich gerne auch inspirieren, möchte aber auch inspirieren. Da ich häufig einen formell höheren Studienabschluss habe, viel im Eigenstudium dazu lerne und nachweislich produktiver bin, kann man von mir auch was lernen. Man muss mich nur fragen, mein Source-Code ist auch für jeden im Unternehmen einsehbar.
Rudi R. schrieb: > Ein T. schrieb: >> Ich weiß nämlich auch nicht, was die Sache mit dem Druckertreiber soll. > > Es geht um Ihren Angriff ad hominem in dieser Sache. Die Geschichte mit > dem Druckertreiber zeigt eine Problemlösung ohne viel Allüren. Sie beweist aber auch, daß Du Dich aus der Kommunikation und Kooperation mit Deinen Teams herausziehst und Dich weigerst, ihre Kollaborationswerkzeuge zu nutzen. Du wurdest laut Deiner eigenen Aussage dazu aufgefordert, ein Ticket anzulegen, hast dies aber mit der Begründung: "Ich habe aber keine Lust auf solche Spielchen" [1] bewußt und gezielt verweigert. Und deswegen ist meine logische Schlußfolgerung >> Du Dich den Kollaborations- und Kommunikationswerkzeugen Deiner Teams >> und beklagst Dich dann darüber, daß die Kollaboration und die >> Kommunikation mit den Teams nicht funktioniert. auch keineswegs > [...] schlichtweg gelogen. sondern schlicht und ergreifend die Wahrheit, zumindest wenn Du den ganzen Vorgang hier richtig dargestellt hast. Und damit ist meine Aussage dann auch kein persönlicher Angriff, sondern eine simple Tatsachenfeststellung, deren Fundament Deine eigenen Aussagen in diesem Thread sind. [1] Beitrag "Re: Meeting-Hölle/Scrum" > Als Projektleiter ist man zwischen den Fronten und dazu muss man kein > Techniker sein. Die Persönlichkeitsstruktur vieler MINTler würde dazu > auch gar nicht passen, weil die ja fokussiert arbeiten müssen. MINTler > sind in der Regel introvertiert, Projektleiter extrovertiert. Ein kluger > Projektleiter schaufelt seinen MINTlern die entsprechenden Freiräume für > Problemlösungen ein, hält nicht ständig Meetings ab. Softwareentwickler > müssen arbeiten können. Solche Ansichten hatten die schlechtesten Projektleiter meiner Karriere. Ich erspare uns und unseren Mitlesern lieber, näher darauf einzugehen. > Meine Scrum-Erfahrungen waren überwiegend > negativ, weil vieles nervte. Vor allem nerven die, die sich der Zusammenarbeit bewußt entziehen, weil sie "keine Lust auf solche Spielchen" haben -- und dann triumphieren weil sie ja schon immer gewußt haben wollen, daß das alles nicht funktionieren kann. > Was ich erlebte, war eher die Dauerhektik. Komisch, in meinen klassisch geführten Projekten waren der Zeitdruck und die daraus resultierende Hektik immer viel größer -- sogar ohne daß nach Beginn des Projekts Änderungen vorgenommen werden mußten. Meine agilen Projekte sind meistens viel entspannter, und dabei auch auf Veränderungen vorbereitet. > Scrum ist nicht Voraussetzung > für kooperatives Arbeiten und auch nicht förderlich. Wenn man sich dem verweigert, dann funktioniert es natürlich auch nicht. > Ich spricht grundsätzlich nichts dagegen, aber meiner Erfahrung > konditioniert Scrum die Entwickler, schnell mal irgendwelchen Pfusch > abzuliefern, weil das Sprintende naht. Ehrlich, ich habe keine Ahnung, was Ihr da macht, aber mit Scrum hat das wenig zu tun. Wenn ein Entwickler nicht so weit gekommen ist wie das Team gemeinsam geplant hatte, dann ist er auf unvorhergesehene Schwierigkeiten gestoßen, hat darauf schon in den Daily Standups hingewiesen und versucht, dort Hilfe und Unterstützung zu erhalten. Genau dafür sind die Daily Standups ja gedacht. > Es kann doch > nicht sein, dass Entwickler durch die Gegend laufen, die nicht wissen, > was die Entwurfsmuster Adapter, Beobachter und Dekorierer sind. Schlimm, mit was für "Entwicklern" Du Dich herumschlagen mußt. Daß agile Methoden mit schlecht ausgebildeten Pfeifen nicht gut funktionieren, ist allerdings auch nicht verwunderlich, insbesondere dann nicht, wenn sich gleichzeitig die Erfahrenen wie Du der Zusammenarbeit entziehen. Komisch ist allerdings, daß wir unseren "Frischlingen" mitunter erst einmal beibringen müssen, nicht jedes Problem gewaltsam auf Gedeih und Verderb mit Entwurfsmustern der GOF totzuschlagen, und was Antipatterns sind. > Mich interessiert eine Hierarchie nicht, auch keine Hackordnung. Ich > will einfach nur das beste geben, Dann lerne, mit Deinen Teams zu kommunizieren, zu kollaborieren und zu kooperieren. Das heißt zu allererst, die dort verwendeten Kommunikations-, Kollaborations- und Kooperationswerkzeuge und die Methoden nicht nur zu akzeptieren, sondern auch, sie sinnvoll zu benutzen.
Ein T. schrieb: > J. S. schrieb: >> Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur >> ihre reine Nettozeit, sondern auch vor- und Nachbereitung > Huch... > >> Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master >> den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau >> verschiebt. > ...und dafür brauchst Du eine "Vor- und Nachbereitung"? Ui. Du liest fälschlicherweise einen Widerspruch in meine Aussage hinein, weil du sie nicht verstanden hast: Der erste Teilsatz beschreibt ein Soll, der zweite (leider) das Ist. Diese Diskrepanz führe ich an. Oder anders formuliert: Ein nutzvolles Meeting erfordert immer eine Vorbereitung (egal ob Scrum) was leider oft nicht gegeben ist. Bei den daily meets ist das besonders eklatant, daher wird Zeit verbraten, die oft nutzlos ist. Dies besonders dann, wenn Scrum über mehrere Projektmitarbeiter drüber gezogen wird, die gar nicht an derselben Aufgabe tätig sind, was aber unvollständlicherweise oft der Fall ist. Scrum sollte daher nur zwischen den Personen stattfinden, die wirklich an einem Teilprojekt arbeiten, welches diese enge Abstimmung auch erfordert und dann sollte auch tunlichst über Inhalte gesprochen werden. Den reinen Status Quo über den Stand der Erledigung der Teilaufgaben innerhalb des Teilprojektes muss nicht täglich kommuniziert und getrackt werden. Soweit das tracken sein muss, kann derjenige, gfs der PO, ins scrum tableu schauen, wie er Stand ist, wenn er das unbedingt braucht. Würden die Leute nicht alles und jenes mit Scrum abwickeln wollen und überall und jeden drüberstülpen, dann gäbe es diese "Meeting-Hölle" auch nicht.
J. S. schrieb: > Ein T. schrieb: >> J. S. schrieb: >>> Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur >>> ihre reine Nettozeit, sondern auch vor- und Nachbereitung >> Huch... >> >>> Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master >>> den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau >>> verschiebt. >> >> ...und dafür brauchst Du eine "Vor- und Nachbereitung"? Ui. > Du liest fälschlicherweise einen Widerspruch in meine Aussage hinein, > weil du sie nicht verstanden hast: Ich hab' das schon ganz gut verstanden: einerseits beschwerst Du Dich über den Zeitaufwand für die Vor- und Nachbereitung der Daily Standups, jedoch beklagst Du dann gleichzeitig deren Banalität. > Ein nutzvolles Meeting erfordert immer eine Vorbereitung (egal ob Scrum) Dem stimme ich zwar grundsätzlich zu, aber meine "Vor- und Nachbereitung" für ein Daily Standup dauert in der Regel etwa dreißig Sekunden, in denen ich die Frage beantworte, was ich heute vorhabe. Diese Gedanken muß ich mir allerdings ohnehin immer machen, sie sind also nicht verschwendet. > was leider oft nicht gegeben ist. Bei den daily meets ist das besonders > eklatant, daher wird Zeit verbraten, die oft nutzlos ist. Dies besonders > dann, wenn Scrum über mehrere Projektmitarbeiter drüber gezogen wird, > die gar nicht an derselben Aufgabe tätig sind, was aber > unvollständlicherweise oft der Fall ist. Keineswegs. Für meine Kollegen ist es eine wertvolle Information, wenn ich gestern die Server des Kunden X aktualisiert habe und heute die Zertifikate auf den Servern des Kunden Y erneuere. Wenn meine Kollegin Eva (*) erklärt, daß sie heute an den Newslettern für den Kunden Z arbeiten wird, ist das für mich eine sinnvolle Information. Auf diese Weise haben mit je zwei Sätzen von Eva und mir alle Kollegen eine grobe Idee, was wir gerade tun, und inwieweit das Einfluß auf ihre Arbeit haben kann. (*) The names have been changed to protect the innocent. > Scrum sollte daher nur zwischen den Personen stattfinden, die wirklich > an einem Teilprojekt arbeiten, welches diese enge Abstimmung auch > erfordert und dann sollte auch tunlichst über Inhalte gesprochen werden. Inhaltliche Erörterungen gehören auch nicht in die Daily Standups. > Den reinen Status Quo über den Stand der Erledigung der Teilaufgaben > innerhalb des Teilprojektes muss nicht täglich kommuniziert und getrackt > werden. Das gehört ebenfalls nicht in die Daily Standups, sondern in die Tickets. > Soweit das tracken sein muss, kann derjenige, gfs der PO, ins > scrum tableu schauen, wie er Stand ist, wenn er das unbedingt braucht. Ich dachte, Du wolltest Scrum am Liebsten abschaffen? Ohne Scrum hat der PO aber gar kein Scrum-Tableau, und es gäbe auch keinen PO. Und dann? Was wäre Deine Alternative, was schlägst Du vor? > Würden die Leute nicht alles und jenes mit Scrum abwickeln wollen und > überall und jeden drüberstülpen, dann gäbe es diese "Meeting-Hölle" auch > nicht. Wie schon mehrmals hier im Thread angeklungen ist, muß man Scrum und andere agile Methoden schon richtig anwenden, um einen Gewinn daraus zu ziehen. Zu dieser richtigen Anwendung gehört, die Daily Standups kurz zu halten und da eben keine Statusabfragen zu machen. Dafür gibt es andere Werkzeuge, und da arbeiten dann auch nur die Betroffenen zusammen.
Ein T. schrieb: > Dann lerne, mit Deinen Teams zu kommunizieren, zu kollaborieren und zu > kooperieren. Das heißt zu allererst, die dort verwendeten > Kommunikations-, Kollaborations- und Kooperationswerkzeuge und die > Methoden nicht nur zu akzeptieren, sondern auch, sie sinnvoll zu > benutzen. Weil ich bei der Druckproblematik kein Ticket geöffnet habe, ist das jetzt eine Verweigerung von "Kommunikationswerkzeugen"? Interessant. Ich habe da kein Ticket erstellt, weil Kollegen von mir das bereits mehrmal machten. Dann druckte es einmal und die nächsten fünf, sechs Druckaufträge wurden verschluckt. Und genau die Kollegin, die mir sagte: "Mach 'nen Ticket auf. Geh die auf die Nerven." War im "prozessorientierten Denken", während ich einfach mal recherchierte, und das mit dem Drucktreiber probierte. Ich habe das Problem zur Freude vieler am Standort endgültig behoben. Der firmeninterne EDV-Service sitzt auch an einem anderen Standort und hat nur seine Checkliste. Die haben auch kein Skin in the Game, weil sie ja unter den dysfunktionalen Drucker nicht litten. Und nur weil mal "Kommunikations-, Kollaborations- und Kooperationswerkzeuge" verwendet, wird es einfach nicht gut. Erst recht nicht, wenn eine Scrum-Masterin einen rammdösig quatscht und Softwareengineering-Themen auf der Strecke bleiben.
Rudi R. schrieb: > Weil ich bei der Druckproblematik kein Ticket geöffnet habe, ist das > jetzt eine Verweigerung von "Kommunikationswerkzeugen"? Ja, natürlich. Ein Ticketsystem ist ein Kommunikationsmedium. Wenn man das nicht nutzt, weil man "keine Lust auf solche Spielchen" hat, dann darf man sich nicht wundern, wenn die Kommunikation nicht klappt. > Ich habe da kein Ticket erstellt, weil Kollegen von mir das bereits > mehrmal machten. Das war nicht Deine Begründung in diesem [1] Beitrag. Deine Begründung war dort, daß Du "keine Lust auf solche Spielchen" hast. [1] Beitrag "Re: Meeting-Hölle/Scrum" > Der firmeninterne EDV-Service > sitzt auch an einem anderen Standort und hat nur seine Checkliste. Die > haben auch kein Skin in the Game, weil sie ja unter den dysfunktionalen > Drucker nicht litten. Der Richtige Ansatz (tm) wäre gewesen, die Lösung irgendwo zu dokumentieren, dann für jeden nicht funktionierenden Drucker ein Ticket mit einem Link auf diese Lösung zu erstellen und das Ticket demjenigen zuzuweisen, der sich in diesem Unternehmen um solche Dinge kümmern soll, also in Deinem Fall diesem firmeninternen EDV-Service. > Und nur weil mal "Kommunikations-, Kollaborations- und > Kooperationswerkzeuge" verwendet, wird es einfach nicht gut. Vielleicht ja doch? Probier es doch einfach mal aus. Und selbst wenn nicht: indem Du Probleme, besser sogar noch mit Lösungsansätzen, und im Idealfalle sogar Lösungen über die vorhandenen Werkzeuge kommunizierst, bist Du aus der Nummer jedenfalls 'raus. In Deine, Fall des Druckers dokumentierst Du das Problem und die Lösung, dann legst für jeden nicht funktionierenden Drucker ein Ticket mit einem Hinweis auf diese Dokumentation an und am Ende weist Du das Ticket dem (oder denen) zu, die für solche Aufgaben verantwortlich sind. Danach ist das Problem dann nicht mehr Deines, und wenn es weiterhin nicht richtig funktioniert, weiß jeder, an wem das Problem liegt und wo er Druck machen muß, damit es behoben wird. Und mit genügend Druck von außen könnte sich möglicherweise sogar Euer firmeninterner EDV-Service dazu motivieren lassen, den Kopf aus dem Gesäß zu nehmen und die Arbeit zu machen, für die Euer Arbeitgeber diesen lahmen Haufen bezahlt. > Erst recht > nicht, wenn eine Scrum-Masterin einen rammdösig quatscht und > Softwareengineering-Themen auf der Strecke bleiben. Wie gesagt: ich habe keine Ahnung, was Ihr da macht, aber offensichtlich ist das weder Scrum noch eine andere agile Methode. Und Du hast mir weiter oben dabei auch zugestimmt, als Du hier [2] geschrieben hast: "[...] wird aktuell ein Scrum light gemacht". Mich haben jedenfalls noch nie eine Scrum-Masterin oder ein Scrum-Master "rammdösig gequatscht" und in meinen Projekten ist das Softwareengineering ebenso präsent wie Architektur- und Intrastrukturthemen. [2] Beitrag "Re: Meeting-Hölle/Scrum"
Ein T. schrieb: >> Ich habe da kein Ticket erstellt, weil Kollegen von mir das bereits >> mehrmal machten. > > Das war nicht Deine Begründung in diesem [1] Beitrag. Deine Begründung > war dort, daß Du "keine Lust auf solche Spielchen" hast. Ich habe in der Tat keine Lust auf solche "Spielchen". Denn was da meine Kollegin machte, alle zwei Wochen ein Ticket für die gleiche Sache zu erstellen, sind "Spielchen", weil sie ja ganz bewusst nerven wollte und mich anmotzte, weil ich das Problem einfach löste, anstatt es ihr gleich zu tun. Es ging gar nicht darum, dass ich das Ticketsystem boykottierte erstmaligen Auftreten des Problem ignorierte, sondern nach mehrfachen Auftreten des Problems anfing, auf das Ticketsystem und die dahinter stehenden Leute ignorierte. Deshalb habe ich die Anekdote am 05.10. gebracht und es geht auch daraus hervor, was ich als Spielchen bezeichnete. Sicherlich nicht das Ticketsystem als solches, sondern die Aussage, die EDV richtig zu nerven. Denn genau das hat meine Kollegin gemacht: alle zwei Woche 'nen Ticket schreiben und herummotzen, dass es nicht geht. Anstatt sich bei mir zu bedanken, dass die Lösung kam, war sie es, die mich anmotzte und meinte, ich hätte den EDV-Service, der es ja nicht hinbekam, weiterhin nerven sollen. Genau das sind Spielchen, Machtspielchen.
Rudi R. schrieb: > Anstatt sich bei > mir zu bedanken, dass die Lösung kam, war sie es, die mich anmotzte und > meinte, ich hätte den EDV-Service, der es ja nicht hinbekam, weiterhin > nerven sollen. Genau das sind Spielchen, Machtspielchen. Nein, das ist ein Problem in der Firma. Euer EDV-Service hat nichts unternommen und trotzdem lösen sich Probleme und lassen sie gut dastehen, weil halt Leute wie du die Arbeit von denen machen. Was nicht ihre Aufgabe ist, wofür sie nicht bezahlt werden und schlimmstenfalls noch nicht mal Ahnung von haben und alles nur schlimmer machen. Wenn die Firma es nicht schafft, eine ordentliche Arbeitsumgebung mit funktionierenden Werkzeugen hinzustellen ist da einiges schiefgelaufen.
Reinhard S. schrieb: > Euer EDV-Service hat nichts > unternommen und trotzdem lösen sich Probleme und lassen sie gut > dastehen, weil halt Leute wie du die Arbeit von denen machen. Da prallen Mentalitäten aufeinander. Auf der einen Seite der auf die technischen Aspekte fokussierte Techie, der relativ ignorant für politische Konstellationen ist. Auf der anderen Seite Politiker, für die die technischen Probleme nur der Aufhänger für die eigentlichen Themen, nämlich Machtspiele, sind. Das real existierende Scrum eignet sich bestens für politische Spielchen, man hat auch hier alle Möglichkeiten, Koalitionen zu schmieden, Belagerungen, Feinden in der Rücken zu fallen, potemkinsche Dörfer etc. Kenner des wahren Scrum haben nur Spott und Verachtung dafür übrig. Das wahre Scrum basiert nämlich auf Gleichheit, Brüderlichkeit, Flexibilität, Einbeziehung des ganzen Teams, freiwilliger und intensiver Kooperation und einem kontinuierlichen Verbesserungs-Prozess. Mit Hilfe dieser Merkmale kann Scrum von anderen Frameworks unterschieden werden.
Ein T. schrieb: > Joe schrieb: >> Das Aufoktroyierte ist das Schlimme. > > Und ein nicht weniger aufoktroyierter Projektleiter, der allen > Mitgliedern des Teams dann seinerseits aufoktroyiert, was sie bis wann > wie (und bisweilen auch wo) zu tun haben, das erscheint Dir weniger > schlimm? Die erfahrenen Projektleiter, die den fachlichen Rat seiner Mitarbeiter einholten, vor dem Management die Interessen des Teams vertraten, habe ich in guter Erinnerung. Im Gegensatz zu den Denglisch-Phrasen von sich gebender Agilisten, die scheinbar der Meinung sind, alles sei lösbar, wenn man nur den Prozess einhält.
Joe schrieb: > Das real existierende Scrum eignet sich bestens für politische > Spielchen, man hat auch hier alle Möglichkeiten, Koalitionen zu > schmieden, Belagerungen, Feinden in der Rücken zu fallen, potemkinsche > Dörfer etc. Das hat nichts mit Scrum zu tun, das hängt von den Menschen ab. > Das wahre Scrum basiert nämlich auf Gleichheit, Brüderlichkeit, > Flexibilität, Einbeziehung des ganzen Teams, freiwilliger und intensiver > Kooperation und einem kontinuierlichen Verbesserungs-Prozess. Klingt wie ein Werbeprospekt. > Mit Hilfe > dieser Merkmale kann Scrum von anderen Frameworks unterschieden werden. Wenn du diese Merkmale auf Arbeit hast wirst du bzw. das Team auch ohne Scrum Erfolg haben.
Hallo, Ein T. schrieb: > und im > Idealfalle sogar Lösungen über die vorhandenen Werkzeuge kommunizierst, > bist Du aus der Nummer jedenfalls 'raus. und Ein T. schrieb: > Danach ist das Problem dann nicht mehr Deines, und wenn es weiterhin > nicht richtig funktioniert, weiß jeder, an wem das Problem liegt und wo > er Druck machen muß, damit es behoben wird. Man muss sich das mal vorstellen, da kann ein Problem ohne großen Aufwand innerhalb kürzester Zeit aus der Welt geschafft werden und dann kommt jemand und kritisiert das sich der Problemlöser nicht an die (offensichtlich nicht funktionierende) Kommunikationswege gehalten hat. So langsam wird mir klar was in der deutschen Industrie schief läuft. Wäre ich der Besitzer des Unternehmens, für das du arbeitest, würde ich dir SOFORT nahelegen deinen beruflichen Wirkungskreis zu verlegen. Leute wie dich, die keine Verantwortung übernehmen wollen um 'raus' zu sein, braucht kein Unternehmen. Joe schrieb: > Das wahre Scrum basiert nämlich auf Gleichheit, Brüderlichkeit, > Flexibilität, Einbeziehung des ganzen Teams, freiwilliger und intensiver > Kooperation und einem kontinuierlichen Verbesserungs-Prozess. Mit Hilfe > dieser Merkmale kann Scrum von anderen Frameworks unterschieden werden. Mit anderen Worten: Scrum funktioniert nur perfekt wenn man den ideale Mitarbeiter hat und die Realität menschlicher Verhaltensweisen völlig ignoriert. Also gar nicht. rhf
Ein T. schrieb: > Und ein nicht weniger aufoktroyierter Projektleiter, der allen > Mitgliedern des Teams dann seinerseits aufoktroyiert, was sie bis wann > wie (und bisweilen auch wo) zu tun haben, das erscheint Dir weniger > schlimm? Es wird immer jemanden geben, der Dir Top-Level Anforderungen vorgibt die Du abzuarbeiten hast. Ob die nun vom Kunden kommen, oder vom Vertrieb in der Firma wo Du arbeitest, aus einer Norm oder sonstwoher. Warum also soll es nicht einen Projektleiter geben, der Dir sagt welche für Anforderungen bis wann umgesetzt sein sollen? Das Problem, das ich bei Scrum sehe ist, dass die Arbeit die ansonsten der Projektleiter macht (Koordinieren und sich abstimmen mit anderen Abteilungen, Stakeholdern etc.) ja nicht auf einmal verschwunden ist. Sondern sie ist nun zum Teil beim Product Owner, zum Teil aber auch bei den Entwicklern. Das heißt, dass die Entwickler weniger Arbeitszeit für ihre eigentliche Arbeit übrig haben. Was spricht gegen eine Arbeitsteilung, in der manche Menschen die Aufgabe haben zu koordinieren, und andere die Aufgabe haben zu entwickeln?
Rudi R. schrieb: > Deshalb habe ich die Anekdote am 05.10. gebracht und es geht auch daraus > hervor, was ich als Spielchen bezeichnete. Sicherlich nicht das > Ticketsystem als solches, sondern die Aussage, die EDV richtig zu > nerven. Denn genau das hat meine Kollegin gemacht: alle zwei Woche 'nen > Ticket schreiben und herummotzen, dass es nicht geht. Anstatt sich bei > mir zu bedanken, dass die Lösung kam, war sie es, die mich anmotzte und > meinte, ich hätte den EDV-Service, der es ja nicht hinbekam, weiterhin > nerven sollen. Genau das sind Spielchen, Machtspielchen. Wenn ein Ticket trotz hoher Priorität und mehrfacher Hinweise nicht bearbeitet wird, wird das zum Vorgesetzten eskaliert. Ihr habt offenbar schwerwiegende Probleme mit Eurer Unternehmenskultur. Wenn Deine Kollegen sich gegenseitig blockieren, muß Zusammenarbeit scheitern. Das hat aber nichts mit agilen Methoden zu tun -- die machen solche Probleme zwar deutlich sichtbar, können und sollen sie aber nicht lösen.
Joe schrieb: > Da prallen Mentalitäten aufeinander. Auf der einen Seite der auf die > technischen Aspekte fokussierte Techie, der relativ ignorant für > politische Konstellationen ist. Auf der anderen Seite Politiker, für die > die technischen Probleme nur der Aufhänger für die eigentlichen Themen, > nämlich Machtspiele, sind. Joe schrieb: > Die erfahrenen Projektleiter, die den fachlichen Rat seiner Mitarbeiter > einholten, vor dem Management die Interessen des Teams vertraten, habe > ich in guter Erinnerung. Im Gegensatz zu den Denglisch-Phrasen von sich > gebender Agilisten, die scheinbar der Meinung sind, alles sei lösbar, > wenn man nur den Prozess einhält. Das Leben muß sehr angenehm sein, wenn man so einfache Welt- und Feindbilder hat. Und wenn Du das ernst meinst, lebe ich anscheinend in einem vollkommen anderen Universum als Du. Viel Glück für Deinen weiteren Lebensweg.
Roland F. schrieb: > Man muss sich das mal vorstellen, da kann ein Problem ohne großen > Aufwand innerhalb kürzester Zeit aus der Welt geschafft werden und dann > kommt jemand und kritisiert das sich der Problemlöser nicht an die > (offensichtlich nicht funktionierende) Kommunikationswege gehalten hat. > So langsam wird mir klar was in der deutschen Industrie schief läuft. Locker bleiben, das ist jetzt seine neue Erklärung, am Anfang hatte er nur keinen Bock. Und wenn jeder in der Company sein eigenes Ding macht und das weder dokumentiert noch kommuniziert, endet das im totalen Chaos. > Wäre ich der Besitzer des Unternehmens, für das du arbeitest, würde ich > dir SOFORT nahelegen deinen beruflichen Wirkungskreis zu verlegen. Leute > wie dich, die keine Verantwortung übernehmen wollen um 'raus' zu sein, > braucht kein Unternehmen. Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die ihre Arbeit einfach ignorieren? Du würdest Dich als Besitzer des Unternehmens auch nicht darüber ärgern, daß Du teure Kollaborationswerkzeuge betreibst, die aber von mehreren Deiner Mitarbeitern einfach ignoriert werden? Stattdessen würdest Du lieber jemandem kündigen, der sich darum kümmert, der seine Kollegen mithilfe dieser Werkzeuge dazu bringt, das zu machen, für das Du sie bezahlst... Du hast noch nie ein Unternehmen besessen, oder?
Mark B. schrieb: > Warum also soll es nicht einen Projektleiter geben, der Dir sagt welche > für Anforderungen bis wann umgesetzt sein sollen? Das funktioniert noch weniger. Der Grund für die Entwicklung agiler Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an ihren Zeit- und / oder Budgetgrenzen gescheitert sind.
Roland F. schrieb: > Mit anderen Worten: Scrum funktioniert nur perfekt wenn man den ideale > Mitarbeiter hat und die Realität menschlicher Verhaltensweisen völlig > ignoriert. > Also gar nicht. Beziehungsweise der Prozess der Softwareentwicklung funktioniert einigermaßen, obwohl Scrum eingesetzt wird. Es gibt einmal das Agile Manifest, was hehre Prinzipien beinhaltet. Dann Scrum als konkretes Regelwerk mit Zeremonien und Ritualen. Damit stellt sich die Frage, ob das Einhalten der Form ein Unternehmen automatisch agil macht. Die Frage stellt sich ja auch in anderen Kontexten: Ist einer, der Fastenregeln einhält und Gebete auswendig kann usw., aber geizig und unbarmherzig bleibt, ein frommer Mann geworden? Kann ein Staat, der die Menschenrechte mit Füßen tritt, ein sozialistischer Staat sein? Mich regt es auf, immer herablassend zu hören zu bekommen in der Art "ist ja schon daneben, was bei euch alles als Scrum bezeichnet wird" und das auch noch als Argument zu meinen und anschließend mit anekdotischem Wissen zu prahlen.
Ein T. schrieb: > Das Leben muß sehr angenehm sein, wenn man so einfache Welt- und > Feindbilder hat. Und wenn Du das ernst meinst, lebe ich anscheinend in > einem vollkommen anderen Universum als Du. Viel Glück für Deinen > weiteren Lebensweg. Ich finde ständig polemische Abwertungen und Pauschalisierungen sowie apodiktische Behauptungen in deinen Beiträgen. Dies war nicht geeignet, meine Meinung über Agilisten als parareligiös zu erschüttern.
Ein T. schrieb: > Das funktioniert noch weniger. Der Grund für die Entwicklung agiler > Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert sind. Wie viele scheitern jetzt daran? Runde 70%?
:
Bearbeitet durch User
Ein T. schrieb: > Ich hab' das schon ganz gut verstanden: einerseits beschwerst Du Dich > über den Zeitaufwand für die Vor- und Nachbereitung der Daily Standups, > jedoch beklagst Du dann gleichzeitig deren Banalität. Nein du hast es immer noch nicht verstanden! Es wird Zeit für minderwertige delays verbraten, WEIL sie unvorbereitet sind. Damit sie effektiv würden, müssten sie länger und intensiver und MIT Vorbereitung sein.
Ein T. schrieb: > Roland F. schrieb: >> Man muss sich das mal vorstellen, da kann ein Problem ohne großen >> Aufwand innerhalb kürzester Zeit aus der Welt geschafft werden und dann >> kommt jemand und kritisiert das sich der Problemlöser nicht an die >> (offensichtlich nicht funktionierende) Kommunikationswege gehalten hat. >> So langsam wird mir klar was in der deutschen Industrie schief läuft. > > Locker bleiben, das ist jetzt seine neue Erklärung, am Anfang hatte er > nur keinen Bock. Und wenn jeder in der Company sein eigenes Ding macht > und das weder dokumentiert noch kommuniziert, endet das im totalen > Chaos. Ich habe mir meinen Beitrag vom 05.10.2024 noch einmal komplett durchgelesen. Aufhänger war "prozessorientiertes Denken", dass BWLer darin das Allheilmittel sehen, wenn nur die Prozesse stimmten. Dass der EDV-Service selten hilfreich ist und viele meckern, schrieb ich auch. Und dass das Druckerproblem nach mehreren Anläufen nicht gelöst war, schrieb ich auch. Ich habe ja gerade nicht mein eigenes Ding gemacht, sondern ein Problem gelöst, das uns alle betraf. Ich habe es dokumentiert und kommuniziert; es ging eine Mail an alle Leute am Standort. Wie sonst hätte jemand motzen können, wenn ich es nicht kommuniziert habe? Das Chaos beginnt, wenn die Leute Dienst nach Vorschrift schieben, nicht mehr mitdenken. Was machen Sie eigentlich, wenn Sie in der Teeküche den Kaffee verschütten? Liegen lassen? Ist ja schließlich Sache der Putzfrau (anderer Prozess!), die vielleicht zweimal pro Woche kommt. Nachdem unsere Putzkräfte im Januar 2022 kündigten, sind wir auf externe Dienstleister angewiesen. Das Unternehmen war froh, die beiden Putzfrauen los zu werden. Nun sind es ja keine Personalkosten mehr, sondern hat 'ne andere Buchungsnummer. Das finden BWLer toll: ein Prozess! Aber was ist die Folge? Die Leistung ist unterirdisch und wir zahlen mehr als für die beiden direkt angestellten Frauen. Das ist vollkommen irre. Und weil das auch noch externe Leute sind, haben wir keine Kontrolle, wer da kommt und alle hatten sie Probleme mit der Alarmanlage.
Ein T. schrieb: > Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, > daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die > ihre Arbeit einfach ignorieren? Du würdest Dich als Besitzer des > Unternehmens auch nicht darüber ärgern, daß Du teure > Kollaborationswerkzeuge betreibst, die aber von mehreren Deiner > Mitarbeitern einfach ignoriert werden? > Ich würde mich als Unternehmenseigentümer über Mitarbeiter ärgern, die Dienst nach Vorschrift schieben. Ich will Problemlöser. Wenn der EDV-Service nicht in der Lage ist, ein konkretes Druckerproblem zu lösen, freue ich mich, wenn ein anderer ITler das Problem löst. Entscheidend ist, dass das Problem aus der Welt ist. > Stattdessen würdest Du lieber jemandem kündigen, der sich darum kümmert, > der seine Kollegen mithilfe dieser Werkzeuge dazu bringt, das zu machen, > für das Du sie bezahlst... Du hast noch nie ein Unternehmen besessen, > oder? Diese Kollegen können nicht machen, für was sie bezahlt werden, weil ein technisches Problem vorliegt. Es hat sich niemand darum gekümmert, dass bestimmte Werkzeuge verwendet werden. Es wurde ja gemacht und man stellte fest, dass es nicht funktionierte, dass das Problem über diesen Weg nicht gelöst wird. Das Denken in Prozessen, wie Sie es vormachen, ist geradezu unternehmeruntypisch. Das gibt's bei angestellten BWLern, die man mit Unternehmern nicht verwechseln sollte.
Rudi R. schrieb: > Das Denken in Prozessen, wie Sie es vormachen, ist geradezu > unternehmeruntypisch. Das gibt's bei angestellten BWLern, die man mit > Unternehmern nicht verwechseln sollte Richtig. An deinem Diskutanten stört mich, daß ständig kolportiert wird: Wenn jeder sich an die Anweisungen von oben halten würde, wäre die Welt ein besserer Ort. So klingt typischerweise ein frischgebacker BWLer. An anderer Stelle ist dann von "hierarchisch sozialisierte Menschen" die Rede, was dann wieder nach linksorientiert/Piratenpartei erinnert. Wird dann mit der Suggestivfrage angereichert "Du hast noch nie ein Unternehmen besessen, oder?", was wohl die Welt in Menschen unterteilt, die mindestens eine Pommesbude besitzen und den großen Rest, inklusive aller BWL Lehrstühle. Die echte Welt braucht letztlich beides, proaktive Mitarbeiter und auch Bürokratie. Was nicht geht, ist eines durch das andere ersetzen zu versuchen.
Hallo, Ein T. schrieb: > Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, > daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die > ihre Arbeit einfach ignorieren? Du lenkst ab. Es geht nicht um die zuständige Abteilung, es geht um deine Kritik an einem Mitarbeiter einer anderen Firma dafür, das er einfach so ein Problem löst ohne sich an die dafür vorgesehene Fehlermeldungsprozedur zu halten. Ein T. schrieb: > Du hast noch nie ein Unternehmen besessen, oder? Und wieder eine Ablenkung, bleib doch einfach beim Thema. Rudi R. schrieb: > Ich würde mich als Unternehmenseigentümer über Mitarbeiter ärgern, die > Dienst nach Vorschrift schieben. Ich will Problemlöser. Wenn der > EDV-Service nicht in der Lage ist, ein konkretes Druckerproblem zu > lösen, freue ich mich, wenn ein anderer ITler das Problem löst. > Entscheidend ist, dass das Problem aus der Welt ist. Dem ist nun wirklich nichts hinzuzufügen, danke Rudi. rhf
Joe schrieb: > Die echte Welt braucht letztlich beides, proaktive Mitarbeiter und auch > Bürokratie. Was nicht geht, ist eines durch das andere ersetzen zu > versuchen. Sehr richtig. Die Menschen ergänzen sich. Das habe ich weiter oben schon beschrieben, dass viele MINTler wissen, dass sie nicht die extrovertierten Rampensäue sind und auch nie sein werden. Sie wissen, dass sie auf die anderen angewiesen sind. Viele BWLer hingegen, die dann die Entscheidungen treffen, sind genau von diesem Typus, dass das von Vorteil sein kann, wenn man im Kundengespräch regelrecht aufgeht. Nun sind diese Leute am längeren Hebel, aber sie verstehen nicht, dass sie ihre Wertmaßstäbe nicht an die oft sehr introvertierten MINTler anlegen können. Ich habe oben schon von meinem Assessmentcenter-Erlebnis geschrieben. Da ging es um eine Entwicklerstelle und wir sollten eine Nachrichtensendung machen. Joe schrieb: > anderer Stelle ist dann von "hierarchisch sozialisierte Menschen" die > Rede, was dann wieder nach linksorientiert/Piratenpartei erinnert. Wird > dann mit der Suggestivfrage angereichert "Du hast noch nie ein > Unternehmen besessen, oder?", Er widerspricht sich selbst, indem er suggeriert, man sei hierarchisch organisiert, wirft aber einem vor, dass man sich in eine Hierarchie nicht einordnet und einfach - jenseits der Prozesse - ein Problem löst. Tatsächlich gebe ich nicht viel auf Hierarchien. Mir geht's um Kompetenzen. Ich bekomme auch täglich Anfrufe von Kollegen, die 'ne Frage haben, weil sie meine Erfahrung und Kompetenz schätzen. Dafür gibt es keinen Prozess. Ich verbuche das noch nicht mal richtig, aber das Unternehmen kommt voran. Warum ich es nicht korrekt verbuche? Der bürokratische Aufwand für eine halbe Stunde hier und da bei etlichen Projekten ist einfach zu hoch. Die ganzen Buchungsungsnummer sind leider durch ein Rechtemanagement mir ohnehin versperrt. Dass es so viele Buchungsnummern gibt, ist auch so eine Ausgeburt der Kontrollsucht der BWLer, die dem irrigen Gedanken anhängen, dass es Projekte und Prozesse gibt und dass da niemand ausschert. Die glauben wirklich, dass ein Entwickler ausschließlich an seinem aktuellen Projekt arbeitet und dass da nie Rückfragen von zum vorherigen Projekt kommen oder dass Kollegen ganz anderer Projekte Hilfe bei bestimmten Thematiken brauchen. Eigentlich ist mein Verhalten und meine Arbeitsmoral genau das, was man sich wünscht: Probleme aus den Weg räumen, die Dinge zuverlässig und mit hoher Qualität erledigen. Ich bekomme ja diese Rückmeldungen. "Dienst nach Vorschrift" kommt für mich nicht in Frage. Ich kann mich damit nicht identifizieren. Die Kollegin, die mich wegen der Druckergeschichte anmotzte, weil ich ihrer Meinung nach auch den EDV-Service hätte triezen sollen, ist allgemein von früh bis spät am Meckern, die ständig aufzählt, wofür sie alles nicht zuständig ist. Ich habe auch schon auf einem Kundenserver einen Drucker eingerichtet. Eigentlich hätte der Kunde das machen müssen, aber wir wollten nicht warten, bis die das gebacken kriegen. Mit lpadmin habe ich das eingerichtet. Dazu wurde unser Account sogar der sudo-Gruppe zugeordnet. Uns war klar, dass ein zu spät eingerichteter Drucker uns viel Geld kostet, weil wir den Drucker testen mussten, einen ZPL-Labelprinter. Ich hatte keine Lust auf Fingerpointing. Wäre abreisen und eine weitere teure Dienstreise (mit Flug, Mietwagen und Hotel) mehrerer Leute besser gewesen?
Reinhard S. schrieb: > Ein T. schrieb: >> Das funktioniert noch weniger. Der Grund für die Entwicklung agiler >> Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an >> ihren Zeit- und / oder Budgetgrenzen gescheitert sind. > > Wie viele scheitern jetzt daran? Runde 70%? Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %.
Ein T. schrieb: > Das funktioniert noch weniger. Der Grund für die Entwicklung agiler > Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert sind. Die stammen aber von den Marketing Deppen, die nicht-existierendes dem Kunden für morgen versprochen haben. Heute wird ihn nur agil versprochen "wir arbeiten dran und Sie sitzen im Team" bis er dann halt die Reissleine zieht weil ewig nichts rauskommt ausser mock-ups.
J. S. schrieb: > Ein T. schrieb: >> Ich hab' das schon ganz gut verstanden: einerseits beschwerst Du Dich >> über den Zeitaufwand für die Vor- und Nachbereitung der Daily Standups, >> jedoch beklagst Du dann gleichzeitig deren Banalität. > > Nein du hast es immer noch nicht verstanden! > > Es wird Zeit für minderwertige delays verbraten, WEIL sie unvorbereitet > sind. Damit sie effektiv würden, müssten sie länger und intensiver und > MIT Vorbereitung sein. Daily Standups sind nicht dazu da, tiefergehendes Wissen zu vermitteln. Dafür existieren andere Formate, und dafür sind Vor- und Nachbereitung sinnvoll.
Rudi R. schrieb: > Ich würde mich als Unternehmenseigentümer über Mitarbeiter ärgern, die > Dienst nach Vorschrift schieben. Ich will Problemlöser. Wenn der > EDV-Service nicht in der Lage ist, ein konkretes Druckerproblem zu > lösen, freue ich mich, wenn ein anderer ITler das Problem löst. > Entscheidend ist, dass das Problem aus der Welt ist. Dieses kleine Problem mag zwar jetzt zunächst gelöst erscheinen, ist es aber langfristig eben leider nicht. Aus unternehmerischer Sicht habe ich allerdings plötzlich ganz andere, wesentlich schwerwiegendere Probleme: 1. einen EDV-"Service", der offensichtliche Probleme mit seiner Kompetenz, einer Überlastung und / oder womöglich sogar seiner Motivation hat, 2. einen EDV-"Service", der mir seine Überforderung oder Überlastung nicht angezeigt hat, so daß ich keine Abhilfe schaffen konnte, 3. einen Externen, der sich -- trotz ausdrücklicher Ermahnung -- nicht an die etablierten Kommunikationsprozesse meines Unternehmens hält. "Oh", sagt da der Dienstleister, "aber ich habe doch eine E-Mail geschickt". Das hilft nur leider nichts. Jetzt ist das Problem zwar erst einmal gelöst. Aber nächstes oder übernächstes Jahr, wenn das Unternehmen gewachsen ist und die Maschine gegen eine größere austauschen muß, weiß niemand mehr von dieser E-Mail. Schon gar nicht die Leute, die ich als Ersatz oder Erweiterung meines EDV-"Service" eingestellt habe, und die diese E-Mail nie erhalten haben. Wenn der Externe seine Lösung ins Ticketsystem geschrieben hätte, das offenbar die vorgesehene Kommunikationslösung des Unternehmens ist, dann wäre diese Lösung auch in vielen Jahren noch leicht auffind- und umsetzbar. Unternehmerisches Denken ist im Wesentlichen nachhaltiges und strategisches Denken. Probleme kurzfristig zu lösen, gehört natürlich dazu und ist ein taktischer Erfolg. Aber mindestens genau so wichtig ist es, Strategien und Lösungen zu etablieren, die dauerhaft funktionieren -- und dem Unternehmen jene Freiräume zu schaffen, die es zur Weiterentwicklung zwingend benötigt. Eine Fokussierung auf kurzfristige Lösungen führt dazu, daß das Unternehmen immer nur denselben Problemen hinterher läuft, die niemals dauerhaft gelöst werden und deswegen immer wieder auftauchen.
Ein T. schrieb: >> Wie viele scheitern jetzt daran? Runde 70%? > > Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber > die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %. 75% der Scrumm-Projekte sollen innerhalb der geplanten Zeit und des geplanten Budgets bleiben? Mit dem geplanten Funktionsumfang? Erscheint mir unglaubwürdig.
Roland F. schrieb: > Hallo, > Ein T. schrieb: >> Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, >> daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die >> ihre Arbeit einfach ignorieren? > > Du lenkst ab. Keineswegs, warum sollte ich? > Es geht nicht um die zuständige Abteilung, Aber ja doch, es geht natürlich auch darum. Wenn meine Mitarbeiter ihre Arbeit nicht machen, dann muß ich als Unternehmer (oder Vorgesetzter) zuerst einmal herausfinden, warum das so ist, und dann Abhilfe schaffen. Wenn ein externer Dienstleister die etablierten Prozesse nicht einhält und den Informationsfluß in meinem Unternehmen dadurch behindert, muß ich herausfinden, warum das so ist, und dann Abhilfe schaffen. > es geht um > deine Kritik an einem Mitarbeiter einer anderen Firma dafür, das er > einfach so ein Problem löst ohne sich an die dafür vorgesehene > Fehlermeldungsprozedur zu halten. Wie kommst Du darauf, daß meine Kritik beträfe, daß er ein Problem löst? Das ist doch super! Ich kritisiere hingegen etwas ganz anderes: nämlich daß er sich nicht an die etablierten Kommunikationsmethoden hält, die seine Lösung langfristig festhalten, und sie dadurch zukünftig wieder auffindbar machen. > Ein T. schrieb: >> Du hast noch nie ein Unternehmen besessen, oder? > > Und wieder eine Ablenkung, bleib doch einfach beim Thema. Oh, nein, das ist keine Ablenkung. Ganz im Gegenteil hinterfrage ich, ob Du gelernt hast, unternehmerisch zu denken. Wie ich gerade in meinem Beitrag zu [1] geschrieben habe, gehört dazu nämlich ein bisschen mehr als kurzfristige Lösungen zu bejubeln. [1] Beitrag "Re: Meeting-Hölle/Scrum" > Dem ist nun wirklich nichts hinzuzufügen, danke Rudi. rolleyes Ihr ärgert Euch also weder über Mitarbeiter, die ihre Arbeit nicht machen, noch über solche, die den internen Informationsfluß torpedieren. Wow, Eure geduldige Nachsicht möchte ich gerne mal haben.
Michael B. schrieb: > Ein T. schrieb: >> Das funktioniert noch weniger. Der Grund für die Entwicklung agiler >> Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an >> ihren Zeit- und / oder Budgetgrenzen gescheitert sind. > > Die stammen aber von den Marketing Deppen, die nicht-existierendes dem > Kunden für morgen versprochen haben. In einem Artikel des seligen Dr. Dobbs Journal habe ich weiland eine Studie gelesen, die eine Quote von 68 % gescheiterter Projekte angegeben hat. Die Website ist leider offline, und leider kann ich diese Studie auch in der Wayback Machine nicht finden.
Ein T. schrieb: > ich als Unternehmer Bist Du wirklich Unternehmer? Weil, Du klingst wie ein BWLer mit Management und & Orga als Schwerpunktfächer. Ich weiß jetzt nicht, ob deine Beiträge als Satire gemeint sind. Mit dieser Sturheit, immer nur die Prozess-Standardisierung zu verteidigen, verrätst Du eigentlich die Agilität.
Ein T. schrieb: > Eine Fokussierung auf kurzfristige > Lösungen führt dazu, daß das Unternehmen immer nur denselben Problemen > hinterher läuft, die niemals dauerhaft gelöst werden und deswegen immer > wieder auftauchen. Genau das würde ja weiter oben schon angeführt als systematische Schwäche von Scrum, daß es auf oberflächlich und kurzfristige Lösungen abzielt.
Reinhard S. schrieb: > Ein T. schrieb: >> Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber >> die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %. > > 75% der Scrumm-Projekte sollen innerhalb der geplanten Zeit und des > geplanten Budgets bleiben? Mit dem geplanten Funktionsumfang? Erscheint > mir unglaubwürdig. Mir erscheint das auch zu hoch gegriffen, aber wie gesagt: es ist schwierig, seriöse und belastbare Daten zu finden. Andererseits sehe ich, daß agile Methoden mittlerweile in vielen Unternehmen benutzt werden, und ihre Verbreitung weiter zuzunehmen scheint. Meine ganz persönliche Vermutung ist, daß das nicht so wäre, wenn diese Methoden keine besseren Ergebnisse erzielen würden als die vorher verwendeten. Die größeren Unternehmen beschäftigen ja sogar eigens Mitarbeiter, sogenannte Controller, deren Aufgabe die ökonomische Überwachung ist. Würde denen nicht auffallen, wenn agile Projekte überwiegend scheiterten, ihre gesetzten Zeit- und Budgetgrenzen überschritten, oder weniger produktiv wären? Klar, das könnte auch alles eine gigantische Verschwörung von Unternehmern, Managern, Betriebswirten und Beratern sein. Solche Leute sind doch, wie hier bereits mehrmals im Thread angedeutet worden ist, grundsätzlich alle ziemlich dämlich und ohnehin nur an Macht, Party und der Unterdrückung von Technikern interessiert. Vielleicht sind die auch alle von einem bislang unbekannten Alienparasiten befallen, oder der Geist von Idi Amin zwingt sie dazu, agile Methoden zu benutzen, wer weiß? :-)
Rudi R. schrieb: > Nun > sind diese Leute am längeren Hebel, aber sie verstehen nicht, dass sie > ihre Wertmaßstäbe nicht an die oft sehr introvertierten MINTler anlegen > können. Die guten Verkäufertypen wissen, daß sie auf die Techniker existentiell angewiesen sind! Eigentlich ist das ganze Thema schon 20 Jahre alt. Aus der Zeit stammt auch eine vielbeachtete soziologische Arbeit zur McDonaldisierung der Gesellschaft. Klar, ein McDonald's ist perfekt organisiert. Aber was macht man, wenn ein Kunde eine französische Zwiebelsuppe haben will? Ein Koch, der bei dem Laden arbeitet, würde sich vielleicht hinstellen und aus dem vorhandenen Käse und Zwiebeln was zaubern. Sehr zum Mißfallen des Managements, versteht sich. Die McDonaldisierung aka Scrum ist auch ein Versuch, dem Fachkräftemangel zu begegnen. Leider fühlt man sich als akademisch ausgebildeter Informatiker bei solchem Zirkus genauso deplatziert wie ein Koch in einem McDonald's.
Ein T. schrieb: > Die größeren Unternehmen beschäftigen ja sogar eigens Mitarbeiter, > sogenannte Controller, deren Aufgabe die ökonomische Überwachung ist. > Würde denen nicht auffallen, wenn agile Projekte überwiegend > scheiterten, ihre gesetzten Zeit- und Budgetgrenzen überschritten, oder > weniger produktiv wären? Difficile est, satiram non scribere. Vielleicht würden die Controller ja beschließen, daß die Projekte eben noch nicht wirklich agil waren?
Ein T. schrieb: > Klar, das könnte auch alles eine gigantische Verschwörung von > Unternehmern, Managern, Betriebswirten und Beratern sein. Solche Leute > sind doch, wie hier bereits mehrmals im Thread angedeutet worden ist, > grundsätzlich alle ziemlich dämlich und ohnehin nur an Macht, Party und > der Unterdrückung von Technikern interessiert. Vielleicht sind die auch > alle von einem bislang unbekannten Alienparasiten befallen, oder der > Geist von Idi Amin zwingt sie dazu, agile Methoden zu benutzen, wer > weiß? :-) Vielleicht braucht es auch gar keine Verschwörungstheorie, sondern nur die Erkenntnis, daß auch Unternehmer, Manager, Betriebswirte und Berater nur Menschen sind, und allgemein eine besondere Mentalität und Sichtweise auf Probleme haben, die sich von der Sichtweise der Techies unterscheidet?
Ein T. schrieb: >> Es wird Zeit für minderwertige delays verbraten, WEIL sie unvorbereitet >> sind. Damit sie effektiv würden, müssten sie länger und intensiver und >> MIT Vorbereitung sein. > > Daily Standups sind nicht dazu da, tiefergehendes Wissen zu vermitteln. > Dafür existieren andere Formate, und dafür sind Vor- und Nachbereitung > sinnvoll. Ja, aber für die ist dann zu wenig Zeit. Das ist meine Beobachtung und Erfahrung. Ich sehe es ja täglich wie es läuft. Es herrscht chronischer Zeitmangel, der dazu führt, dass an anderer Stelle wieder gepfuscht wird. So wenig die 15min auch sein mögen, so sehr fehlen sie dann woanders. Offiziell läuft der Prozess und SCRUM, praktisch wird es dauernd umgangen um irgendwie weiterzukommen. Daher ist es zweckmäßig den formellen Prozess zu verschlanken oder lieber zu kippen, statt dafür Zeit zu verbraten, nur um ihn offiziell einzuhalten.
Ein T. schrieb: > Das funktioniert noch weniger. Der Grund für die Entwicklung agiler > Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert sind. Wie ist denn "gescheitert" definiert? Ist ein Projekt gescheitert, wenn es auch nur einen Tag länger dauert bis zur Fertigstellung als es in der ursprünglichen Deadline vorgesehen war? Es gibt manche Branchen, in denen ist "Scheitern" der Normalfall. Zwei Beispiele: Bauwesen und Eisenbahn. Es gibt nahezu kein Großprojekt im Hoch-/ Tiefbau, in dem die ursprünglich geplanten Termine eingehalten werden. Siehe Elbphilharmonie, Stuttgart 21, Berliner Flughafen, ... Bei der Eisenbahn gilt Ähnliches: Der Kunde will eine neue Straßenbahn, oder eine neue Lok, oder einen neuen Triebzug bestellen. Liefertermin soll in zwei Jahren sein. Jeder Hersteller weiß: Der Termin ist sowieso nicht zu halten. Trotzdem geben Siemens, Alstom, Stadler, Skoda fröhlich ihre Angebote für den Auftrag ab. Warum? Weil man selbst mit der ersten Pönale, die man wegen der verspäteten Lieferung dann zahlen muss, unterm Strich immer noch Geld verdient. Im Bauwesen ist Software-Entwicklung jetzt nicht so relevant, bei der Eisenbahn dagegen umso mehr. Die Funktionen der Fahrzeuge werden zu etwa 70% in Software realisiert. Meines Erachtens existiert auch kein gesicherter Nachweis dafür, dass Projekte durch SCRUM tatsächlich besser laufen. Wenn es den doch geben sollte, so bitte ich um einen Link zu der entsprechenden Quelle.
Gerhard O. schrieb: > https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/ Lesenswerter Aufsatz, danke. Für mich persönlich fehlt aber die Antwort, warum ein gesundes Team eine Medizin wie Scrum braucht Im Artikel heißt es: "...Wenn das Management die Entwickler im Wesentlichen ignoriert, es feste Fristen gibt, die innerhalb eines vorgegebenen Umfangs eingehalten werden müssen, oder wenn ein gnadenloser Kampf statt eines Teams herrscht, das sich auf das Erreichen desselben Ziels konzentriert, wenn Vorausplanung und Querdenken nicht geschätzt werden, dann wird man irgendwann aufgeben und sich darauf beschränken, nur noch die zugewiesenen Aufgaben zu erledigen. Ich habe das schon erlebt. Aber schieben Sie die Schuld nicht auf Scrum...“ In einem ungesunden Umfeld wirkt Scrum also nicht. Was aber bringt Scrum in einem gesunden Umfeld? Wenn das Management die Entwickler wertschätzt und auf ihren Rat hört, feste Fristen, die innerhalb eines vorgegebenen Umfangs eingehalten werden müssen, zugunsten Qualitätszielen/Vermeidung technischer Schulden zurückstehen müssen, wenn Kooperation und Teamgeist herrscht, wenn Vorausplanung und Querdenken geschätzt werden - was braucht es dann den ganzen Scrum Kram? Die Frage wird so nicht gestellt, obwohl sie m.E. wie der sprichwörtliche Elefant im Raum steht.
Prozesshuber vs Praktiker, das geht noch endlos so weiter. "Du musst erst ein Ticket aufmachen mähmähmäh". Solche Trullen kenne ich auch zur Genüge, nur dass ich das immer als Aussenstehender miterleben darf. Scrumzoo halt, die nächste Stufe ist die Klapse.
Joe schrieb: > was braucht es dann den ganzen Scrum Kram? SCRUM schließt das Management von der Projektarbeit aus. In der SCRUM Welt ist das Management salopp gesagt für die Urlaubsanträge zuständig.
J. S. schrieb: > Ein T. schrieb: >> Daily Standups sind nicht dazu da, tiefergehendes Wissen zu vermitteln. >> Dafür existieren andere Formate, und dafür sind Vor- und Nachbereitung >> sinnvoll. > > Ja, aber für die ist dann zu wenig Zeit. Das ist meine Beobachtung und > Erfahrung. Ich sehe es ja täglich wie es läuft. Es herrscht chronischer > Zeitmangel, der dazu führt, dass an anderer Stelle wieder gepfuscht > wird. So wenig die 15min auch sein mögen, so sehr fehlen sie dann > woanders. Offiziell läuft der Prozess und SCRUM, praktisch wird es > dauernd umgangen um irgendwie weiterzukommen. Daher ist es zweckmäßig > den formellen Prozess zu verschlanken oder lieber zu kippen, statt dafür > Zeit zu verbraten, nur um ihn offiziell einzuhalten. Seit ich kommerzielle Software entwickle, habe ich noch kein einziges Projekt ohne Zeitdruck erlebt. Aber wenn eine tägliche maximal fünfzehn Minuten lange Absprache des Teams eine unüberwindliche Hürde darstellt, hast Du auch mit klassischen Methoden des Projekt- und Teammanagement massive Probleme. Dann ist nämlich auch keine Zeit für die Erstellung ordentlicher Lasten- und Pflichtenhefte, halbwegs realistische Zeit- und Aufwandsplanungen, und die auch in solchen Projekten notwendige Kommunikation vorhanden. Und darunter leiden dann die Qualität des Produkts sowie die Gesundheit und Motivation der Mitarbeitenden. Ich glaube aber, Du mißverstehst da etwas. Denn die Kommunikation unter den Teammitgliedern muß ohnehin stattfinden. In klassischen Projekten gibt es häufig eine Mischung aus geplanten Meetings und dem Flurfunk, was leider mit zunehmender Größe des Teams und zunehmender Komplexität des Projekts immer schlechter funktioniert. In den Meetings müßten dann nämlich drölfzig Themen abgehandelt werden, aber weil alle wieder coden müssen und einige schon ins nächste Meeting müssen, bleibt am Ende immer etwas offen. Außerdem verleiten solche Mammut-Meetings dazu, daß hinterher niemand mehr weiß, was da alles besprochen wurde, es wurde zwar alles gesagt, aber nicht von jedem, und das einzig meßbare Ergebnis ist, daß die Kekse weg sind. BTDT. Der Flurfunk ist sogar noch gefährlicher, weil dabei in den meisten Fällen nur die aktuellsten und spannendsten Themen besprochen werden, nicht alle Teammitglieder dabei und informiert sind, und im Zweifelsfalls bestimmte, aber wichtige Informationen vergessen oder verfälscht dargestellt werden, wie beim bekannten Kinderspiel "Stille Post". Mir wird hier im Thread zu oft nach Kritikpunkten an agilen Methoden gesucht. Letzten Endes müßte es aber seriöserweise nicht nur um eine Kritik an agilen Methoden gehen, sondern vielmehr um den Vergleich mit anderen zur Verfügung stehenden Möglichkeiten. Kennst Du denn eine Methode des Projektmanagements, die ohne Fehl und Tadel ist und für jedes Projekt und Team jeder Komplexität und Größe perfekt funktioniert, und bei der der Zeitdruck geringer wird? Dann sollten wir unbedingt und aller schnellstens ein Manifest darüber schreiben und eine Beraterfirma dafür gründen... :-)
Joe schrieb: > Klar, ein McDonald's ist perfekt organisiert. Aber was macht man, wenn > ein Kunde eine französische Zwiebelsuppe haben will? Ein Koch, der bei > dem Laden arbeitet, würde sich vielleicht hinstellen und aus dem > vorhandenen Käse und Zwiebeln was zaubern. Sehr zum Mißfallen des > Managements, versteht sich. > > Die McDonaldisierung aka Scrum ist auch ein Versuch, dem > Fachkräftemangel zu begegnen. Leider fühlt man sich als akademisch > ausgebildeter Informatiker bei solchem Zirkus genauso deplatziert wie > ein Koch in einem McDonald's. Ja, diese McDonaldisierung ist problematisch. Bei einem Massengeschäft wie McDonald's mag das sinnvoll sein. Und dann wird eben keine Zwiebelsuppe gemacht. Aber das Geschäftsmodell lässt sich nicht auf alles andere übertragen. Aber sie versuchen es. Nun ist Softwareentwicklung für Kunden und Projekte eine hochspezifische Angelegenheit. Die Komplexität der Anforderungen dadurch zu reduzieren, dass man es in möglichst kleine Pakete zerstückelt und in Sprints abfrühstückt, funktioniert einfach nicht.
Mark B. schrieb: > Wie ist denn "gescheitert" definiert? Das haben die Ersteller der betreffenden Studien definiert, die ich aber leider nicht mehr finde. > Meines Erachtens existiert auch kein gesicherter Nachweis dafür, dass > Projekte durch SCRUM tatsächlich besser laufen. Wenn es den doch geben > sollte, so bitte ich um einen Link zu der entsprechenden Quelle. Naja, so ein gesicherter Nachweis müßte dann doch zuerst einmal von dem, der danach verlangt, akzeptiert werden... und warum sollte ich einen -- für jede denkbare Bedeutung der Worte -- "gesicherten Nachweis" erbringen? Ich habe schließlich meine eigenen Erfahrungen, daß meine agilen Projekte viel besser funktionieren und gleichzeitig trotzdem entspannter und angenehmer sind. Das reicht mir. Ich möchte hier niemanden missionieren und spreche deswegen nur für mich, aus meinen und über meine eigenen Erfahrungen -- und denen meiner Kollegen (zumindest wenn ich ihren Aussagen vertrauen darf, woran zu zweifeln ich allerdings keinerlei Anlaß habe). Wenn es Dich wirklich interessiert, dann hast Du doch dasselbe Internet mit denselben Suchmaschinen wie ich auch, kannst dieselben Informationen finden wie ich, und ihnen ganz nach Deinem Belieben ver- oder mißtrauen. Vielleicht ist diese Zuammenfassung [1] verschiedener (dort auch verlinkter) Studien ein Startpunkt für Dich, um Deinen Informationsdurst zu stillen. Ich würde mich freuen, wenn Du am Ende etwas dazu sagen könntest, was Du gefunden hast, und was Deine Meinung bestätigt oder Dich überrascht hat. Danke! [1] https://echometerapp.com/en/scrum-statistics/
Rudi R. schrieb: > Die Komplexität der Anforderungen dadurch zu reduzieren, dass man es in > möglichst kleine Pakete zerstückelt und in Sprints abfrühstückt, > funktioniert einfach nicht. Beziehungsweise die Portionierung selbst ist regelmäßig die eigentliche geistige Arbeit, wogegen die Pakete selbst abzuarbeiten recht anspruchslos ist. In dem Beispiel mit dem McDonalds würde es ganz bestimmt klappen, nach kurzer Zeit eine genießbare Zwiebelsuppe ins Sortiment aufzunehmen. Ein Problem taucht erst wieder auf, wenn einer eine italienische Minestrone haben will. Da braucht es wieder den Koch. Menschliches Wissen ist immer noch kaum durch Prozesse ersetzbar. Nimm 10 Typen von der Straße, kaufe eine medizinische Bibliothek, die besten und teuersten medizinischen Geräte sowie Breitbandverbindung zu ChatGPT. Das ersetzt keinen erfahrenen Arzt. Deswegen finde ich auch das Insistieren darauf, alle Lösungen für die Nachwelt zu dokumentieren, nur bedingt hilfreich. Das Nachschauen in der medizinischen Datenbank macht noch keinen Arzt.
Gerhard O. schrieb: > https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/ Richtig guter Artikel, danke! :-)
Ein T. schrieb: > Richtig guter Artikel, danke! :-) Holzschnittartig mit wahllos zusammengewürfelten banalsten "Argumenten" die man ja noch nie gehört hat, KI generierter Contentmüll halt. Die Kommentare sind viel besser.
Franko S. schrieb: > Holzschnittartig mit wahllos zusammengewürfelten banalsten "Argumenten" > die man ja noch nie gehört hat, KI generierter Contentmüll halt. Die > Kommentare sind viel besser. Wie süß, ein Troll. :-)
Ein T. schrieb: > Gerhard O. schrieb: >> > https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/ > > Richtig guter Artikel, danke! :-) Find ich auch. "Ticket-driven architecture" - Prägnanter kann man die Kritik nicht äußern. Bin glatt neidisch, dass mir dieser Begriff nicht selbst eingefallen ist. "Features over robust code" habe ich auch beobachtet, ebenso "Complicated tasks get deprioritized": Es wird das gemacht, was schnelle und einfache Storypoints verspricht. Ich teile die Kritik in dem Artikel.
Bei Heise schreibt man auch von der "Scrum-Hölle": https://www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html
Ist halt mies wenn Scrum in ein kaputtes Umfeld eingebracht wird, in der Hoffnung auf Erlösung. Das kann Scrum nicht bieten, wird allerdings oft von Beratern als Lösung verkauft. Ich glaube, Scrum löst überhaupt kein ernsthaftes Problem. Und alle anderen Probleme kann man auch ohne Scrum bewältigen.
Reinhard S. schrieb: > Ein T. schrieb: >>> Wie viele scheitern jetzt daran? Runde 70%? >> >> Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber >> die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %. > > 75% der Scrumm-Projekte sollen innerhalb der geplanten Zeit und des > geplanten Budgets bleiben? Mit dem geplanten Funktionsumfang? Erscheint > mir unglaubwürdig. Da hast Du vollkommen: Es scheint nur so. Interessanterweise: andere nachprüfbare Zahlen hast Du nicht, nur „berechtigte Zweifel“. Ha-Ha-Ha. Gemeinsam ist den „Traditionalisten“, dass es Schuldige braucht: BWL‘er, Manager, agile Evangelistenn usw. - und natürlich Abschätzigkeit und Beleidigungen. Die meisten „Argumente“ haben selten etwas mit SCRUM zu tun, denn die Allermeisten Themen treten selbstverständlich in allen (Projektmanagement-) Methoden und Frameworks auf.
Uwe D. schrieb: > Gemeinsam ist den „Traditionalisten“, dass es Schuldige braucht: BWL‘er, > Manager, agile Evangelistenn usw. - und natürlich Abschätzigkeit und > Beleidigungen. Hier ein weiteres Zeugnis des Aufstands der traditionalistischen Code-Affen: (danke für den Link, rudi) https://www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html "Die Mehrheit der Kommentare stammt von Entwicklerinnen und Entwicklern, die beklagen, dass Scrum vom Management zweckentfremdet wird, um mehr Kontrolle auszuüben. Scrum wird also nicht so eingesetzt, dass sich ein Team damit selbst organisiert, wie es bei agilen Methoden eigentlich vorgesehen ist, sondern es wird als Projektmanagement-Werkzeug verwendet, dem alles andere untergeordnet wird. Statt "Individuals and Interactions over Processes and Tools" (wie es im agilen Manifest formuliert ist) passiert genau das Gegenteil: Scrum dominiert als Prozess alles. Dadurch wird Agilität im Keim erstickt, weil sie offensichtlich nicht gewünscht ist. Die traurige Wahrheit ist, dass in vielen Unternehmen nicht einmal Fake Agile vorherrscht, sondern eine schlimmere Variante: Dark Agile. Dabei geht es nur darum, auf dem Papier gut auszusehen, während Scrum in Wirklichkeit als Kontroll- und Steuerungsinstrument missbraucht wird. Genau das habe ich im letzten Blogpost als die schlimmste Variante beschrieben, wie man Agilität falsch leben kann." Und ich bin stolz, ein Traditionalist zu sein! Freiheit statt Agilismus!
Angehängte Dateien:
Ein T. schrieb: > In einem Artikel des seligen Dr. Dobbs Journal habe ich weiland eine > Studie gelesen, die eine Quote von 68 % gescheiterter Projekte angegeben > hat. Die Website ist leider offline, und leider kann ich diese Studie > auch in der Wayback Machine nicht finden. Da bei Scrum das Ziel während das Projekt läuft beliebig nach unten angepasst werden kann, müsste Scrum immer erfolgreich sein. Notfalls war es halt zum Schluss eine Forschungsarbeit wie es nicht geht. Erschreckend wenn 25% nicht mal das hinbekommen.
Michael B. schrieb: > Da bei Scrum das Ziel während das Projekt läuft beliebig nach unten > angepasst werden kann, müsste Scrum immer erfolgreich sein. Interessante Interpretation! Ich fürchte nur, dass es für diese Auslegung kaum Beifall vom Aufraggeber gibt, da dieser ein Ergebnis haben wollte. Wenigstens kann die Truppe dann sagen, "Hui, wir haben aber wenigstens Scrum erfolgreich betrieben". > Notfalls war es halt zum Schluss eine Forschungsarbeit wie es nicht geht. Na da wäre ich ja gern dabei, wenn das SO! präsentiert wird. :-) Das ursprüngliche Ziel ist ja eigentlich das Einarbeiten von Änderungen und das Finden der jeweils optimalen Lösung mit dem Ziel Kosten, Zeit und Qualität zu optmieren, bzw die Randbedingungen einzuhalten. An der Stelle kann es nicht mehr darum gehen, OB etwas gemacht wird, sondern nur noch WIE . Allenfalls kann man den Findungsprozess zur Machbarkeit eines Systems vorlagern und diese dabei nach Scrum-Richtlinien fahren (wobei ich dann sofort fragen würde, worin der Unterschied zu einer klassischen Machbarkeitsstudie in der Forschung liegen soll). Ein Misch-Masch des Vorgehens und Pendeln zwischen Koncept und Umsetzung und der Weise, dass mittendrin Anforderungen angenommen oder gegeben werden, die die Machbarkeit infragestellen, darf es nicht geben. Für jedes Projekt braucht es eine Vorstudie (und sei es nur ein kurzes Durchdenken der Geschichte durch einen erfahrenen Systemingenieur) die aufzeigt, ob ein System sicher machbar ist, wo es mehrere Wege gibt, welche davon risikoreich sein könnten und untersucht werden müssen und ob man gfs eine Machbarkeiststudie benötigt und was da hinein muss bzw welche Ziele die haben muss. Alle potenziellen show stopper müssen natürlich im Vorhinein geklärt werden, mitsamt Aufzeigen der möglichen minimalen und maximalen Qualität, Kosten und Zeitbedarf der Teillösung. Ab dann kann man entscheiden, ob man ein Risiko nimmt, um Tempo zu bekommen und dann Kosten hinnimmt, oder ob man Zeit investiert zur Sicherstellung und Einleitung von Sparmaßnahmen. Ja, das ist total old style und viel uncooler, als einfach anfangen und drauflos bauen, um dann super gail "Scrum-Zickzack" zu fahren. ES würde aber die eine oder andere Firma schon vor völlig nutzlosen Investitionen und tausenden überflüssiger Funktionen und Änderungen bewahrt haben.
Rudi R. schrieb: > "Complicated tasks get deprioritized": Es wird das gemacht, was schnelle > und einfache Storypoints verspricht. Das halte ich für den entscheidenden Satz! Mit Bezug zu meinem vorherigen Beitrag läuft es aber leider ganz genau so, dass man wichtige Entscheidungen nach hinten schiebt, weil man mit Scrum ein Alibi hat, nicht ausreichend über Anforderungen nachdenken zu müssen, erst einmal loslegen kann, um Tempo aufzunehmen und dann schaut, was man noch so braucht, da man "neue" Anforderungen jederzeit "agil" nachschieben darf. Das System zielt an der Stelle stark in Richtung des optimalen Zeitvektors. Kosten und Qualität sind noch nicht genau definiert. Die Umsetzer in der Truppe rüsten sich gegen viele potenzielle Anforderungen mit aufwändigen Universallösungen, Zusatzfunktionen und allem Möglichen, das am Ende keiner aber braucht und nur Zeit und Geld verbrät. Das System schwenkt daher zur Startphase bereits stark in Richtung des Qualitätsvektors, vorwiegend Unterrichtung "Menge und Funktionsumfang". Mittendrin kriegt dann einer mit, dass die Kosten explodieren und versucht Sparlösungen zu initiieren und untersuchen zu lassen. Dann werden Alternativen gesucht und diskutiert, die Zeit verbraten und kaum Qualität bringen. Am Ende wird wenig gespart, die Qualität sinkt, weil Funktion oder Güte weggelassen wird. Irgendwann merkt dann einer, dass die Zeit wegläuft und das Gesamtsystem wird versucht, in Richtung Zeit zu drehen und idealerweise den Kostenvektor beizubehalten. Damit braucht es schnell irgendwelche teuere Zwischen- oder Sonderlösungen, um überhaupt etwas hinzubekommen. Am Ende ist kein Geld und keine Zeit mehr, alles fertig zu bauen, weil die Zwischenlösungen Zeit und Budget verbraten haben und es fällt für das Zielsystem noch mehr Qualität und Funktion weg. Als Ergebnis gibt es ein System, das teuer und schlechter ist, als das Machbare, aber dennoch mehr Zeit verbraucht hat und völlig inkosistent gebaut ist, da die jeweiligen Entscheidungen zwischen Qualität, Zeit und Kosten einem jeweils zeitlich veränderlichen Verktor unterworfen wurden: Komponenten, die früh geplant und gebaut wurden, sind weitgehend vollständig, auch einigermaßen günstig gebaut, haben aber eine eher geringe Qualität, da man schnell drauf los gelegt und wenig geplant hat. Viel fehlt, sie hätten nochmal überarbeitet werden sollen, was dann aber nicht mehr passierte. In Einzelfällen sind sie so untauglich, dass sie ersetzt werden müssen oder aber die Qualität des Systems nach unten ziehen, wenn sie genutzt werden. Komponenten, die mittendrin geplant und gebaut wurden, sind mehr als vollständig, oftmals total überplant und überdesigned. Sie sind zwar ebenso noch ziemlich effektiv gebaut und produziert und haben auch eine eher hohe Qualität, sind aber relativ viel zu teuer, weil ein Teil der Funktionen gar nicht benötigt wird und ein weiterer Teil nicht genutzt werden kann, da hintere Komponenten abgespeckt werden mussten. Komponenten, die gegen Ende geplant und gebaut wurden, haben den höchsten und besten Funktionsumfang, da am Genauesten bekannt ist, was gebraucht wird. Sie sind aber entweder extrem teuer, weil sie mit teueren Sonderlösungen und Zukauf arbeiten, um Zeit reinzuholen, oder sie leiden unter dem Kostendiktat und werden funktionell abgespeckt, womit sie die einst geplanten Funktionen des Gesamtsystems noch mehr einschränken. Das trifft insbesondere auf schnell dahin gezimmerte Zwischenlösungen zu, die schnell für eine Messe oder Präsentation gemacht werden, weil die normale Zeitschiene geplatzt ist. Diese besitzen dann eine noch geringe Qualität, als jene der Gruppe 1. Weder sie noch die Originale können aber nochmal überarbeitet werden. Komponenten dieser letzter Gruppe leiden auch an den Randbedingungen, die durch die zu schlecht geplanten ersten Komponenten gesetzt wurden.
:
Bearbeitet durch User
J. S. schrieb: > kaum Beifall vom Aufraggeber Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei rauskommt.
Joe schrieb: > Statt "Individuals and Interactions over Processes and Tools" (wie es im > agilen Manifest formuliert ist) passiert genau das Gegenteil: Scrum > dominiert als Prozess alles. Das beobachte ich auch. Entwickler werden zu Implementieraffen abgestempelt. Ich sage es nicht, aber denke es bei vielen Entwickler: Warum machst du dir das Leben zu schwer? Es fehlt bei vielen die Reflektion darüber, was sie da fabrizieren. Ich erlebe Entwickler, die sich es schaffen, 20 mal praktisch den gleichen Codeblock hintereinander zu schreiben. Die Codeblöcke unterscheiden sich minimal und systematisch. Auf die Idee, 'ne Funktion zu zimmern, kommen die nicht. Ich sehe das Monate später, weil ich irgendwas anpassen muss, irgendeinem Bug auf der Spur bin. Und ich darf dann erstmal refaktorieren. Hätte er die Funktion direkt am Anfang gezimmert, hätte er viel Zeit gespart und die Bugs auch nicht fabriziert, weil ja 20 Code-Blöcke schwerer zu überblicken als 20 Funktionsaufrüfe und die Funktion selbst. Ich habe es ja oben irgendwo mal geschrieben: Ich bin der Überzeugung, dass Entwickler besser werden, wenn sie regelmäßig ihr Zeug diskutieren, am besten in lockerer Runde. Ich habe kürzlich erlebt, wie ich Wochen auf die Entwicklung eines Kollegen wartete. Vor zwei Wochen wurde sie in den Hauptzweig gemergt. Da war vieles falsch und ich durfte refaktorieren. Er hat viel komplizierte Zeilen hintereinander geklöppelt, anstatt gut händelbare Funktionen zu entwickeln. Zum Refaktorieren nehme ich gerne den Emacs wegen seiner Tastaturmakros. Das geht dann fix und der Werksstudent hat nicht schlecht gestaunt. Ich bin auch der Meinung, dass das, was der Kollege über Wochen entwickelte, in einem Drittel der Zeit hätte entwickelt werden können, wenn er wichtige Designprinzpien wie KISS und DRY verwendet hätte. Jetzt ist es so, dass man in die Spezifikation vom Kunden schauen kann (es geht um eine Schnittstelle), und die in den dortigen Tabellen beschriebenen Nachrichtentypen kann man nun praktisch direkt in den Code übernehmen, denn die Argumente meiner Funktion entsprechen zufällig auch der Reihenfolge der Spalten in den Tabellen: Name, Länge, Typ, Wert. Ich erinnere mich noch mit Grausen, was ein Kollege in meiner alten Firma gezimmert hatte. Er fing an, eine Schnittstelle zu programmieren. Dann folgte eine ähnliche Schnittstelle und kopierte er die Implementierung der ersten Programmierung, passte diese an. Das machte er ca. 40 mal. Ich kam frisch von der Uni und sagte, da müssen wir ran. Der Chef skeptisch, er war dagegen, weil er das in seinem Scrum nicht vorgesehen hat. Ich habe eine gemeinsame Oberklasse entwickelt und sehr, sehr viel Code eingespart. Es stellte sich heraus, dass ein Bug drin war. Nun war der Bug aber auch vorher drin, ca. 40 mal! Nach dem Refaktorierungen nur noch einmal. Behebung ging schnell. Es soll mir keiner erzählen, dass besagter Kollege den Bug in allen 40 Klassen behoben hätte. Und man stelle sich vor, der Entwickler hätte von Anfang von DRY beherzigt. Er hätte initial viel Zeit gespart und ich hätte keine Refaktorierung machen müssen. Das war so offensichtlich, aber ich war der Buhmann. Schlechte Entwickler sind das Problem und das Niveau hebt man an, wenn Raum für Diskussionen und Weiterbildung geschaffen wird. Ich finde es auch immer wieder erstaunlich, dass viele Entwickler sich auch nicht trauen, eine Funktion rekursiv zu formulieren. Oft geht das einher mit hoher Eleganz und Verständlichkeit. Ich habe mit besagten Werksstudenten eine Funktion geschrieben (im Zuge des Refaktorierens), in der Rekursion auftrat. Er wollte es sich schon ganz kompliziert machen, aber es mit der Rekursion sehr schnell abgefrühstückt. Ich hoffe, er lernt davon. Joe schrieb: > Und ich bin stolz, ein Traditionalist zu sein! Freiheit statt Agilismus! Ich denke, Agilität ist nicht unbedingt falsch, da sie ja Personen über Prozesse stellt. Die Scrum-Hektik ist das Problem. Ich sehe mich weder als Traditionalist noch als Progressiven. Ich bin ein Anhänger des gesunden Menschenverstandes. Der Entwickler steht im Mittelpunkt und er muss seine Fähigkeiten ständig ausbauen. Und ich kann jedem Entwickler raten, regelmäßig auszuscheren und mal etwas zweckfremdes zu machen, sich intellektuell mit der Softwareentwicklung zu beschäftigen. Bücher gibt's genug. Habe ich schon mal geschrieben, dass ich von einem Kollegen angeschrien wurde? Ich schrieb ihm ganz freundlich, dass Teile seines Codes unter gewissen Umständen nicht funktionieren können. Ich hätte das gerne diskutiert, ich hätte ihm geholfen, es zu beheben. Er meinte, wenn er Zeit fände. Dann gingen zwei, drei Wochen ins Land. Er schien überlastet. Ich änderte den Code, weil es gemeinsamer Code ist und wir eine gemeinsame Veranwortung dafür haben, als Team. Dann sah er es, platzte rein und schie mich an: "Warum hast du das geändert? Mein Code funktioniert! Die Tests zeigen es!" - Er hatte offenbar noch nie gehört, dass Tests die Fehlerfreiheit von Code nicht zeigen können. Rückblickend muss ich sagen: Er war so ein typischer Entwickler, der einfach drauflos programmierte, nicht reflektierte und deshalb irgendwann ins Schwimmen kam und er letztendlich unterging. Er verließ das Unternehmen wenige Monate später. (Auf LinkedIn sehe ich, dass er heute "Certified Scrum Product Owner" ist.) Ich wusste damals auch nicht, dass er nur Fachinformatiker war, während ich mit einem Diplom aufwarten konnte, vielleicht aber nicht seine Berufserfahrung hatte, aber sehr wohl mehr Programmiererfahrung. Was mir auch aufgefallen ist. Mir sind schon mehrfach Leute begegnet, die mich davon abhalten wollen, etwas auf meine Art zu programmieren oder etwas zu refaktorieren, indem sie mit so Schlagwort wie 80:20 kommen, also Pareto. Dass 20 % zu 80 % des Ergebnisses beitragen und ich mich da nicht so hineinsteigern solle. Nun ist das ein Totschlagargument, weil man ja nicht wissen kann, auf welcher Seite man gerade entwickelt. Außerdem bezahlt der Kunde nicht für 80 %, sondern für 100 %, also muss man auch für die fehlenden 20 % etwas entwickeln. Und es sollte ingesamt sehr effizient und vernünftig passieren, egal ob es für die 20 % oder für die 80 % sind. Daher ist Code-Qualität so wichtig, darum sind KISS und DRY so wichtig, oder auch das Demeter-Prinzip. Das anzusprechen, ist als theoretisch verpönt und ich spüre geradezu die Abneigung dagegen. weil man eventuell nachdenken muss. Bei vielen Menschen stelle ich fest, dass die Angst davor haben, wenn sie mit Niveau konfrontiert werden. Viele Menschen in meinen Altern wehren sich mit Händen und Füßen dagegen, mal in ein klassisches Konzert zu gehen, denn die Musik könnte ja fordernd sein.
Rudi R. schrieb: > Was mir auch aufgefallen ist. Was mir aufgefallen ist: Softies schimpfen gerne über andere Softies... ;-) Rudi R. schrieb: > Viele Menschen in meinen Altern wehren sich mit Händen und Füßen > dagegen, mal in ein klassisches Konzert zu gehen, denn die Musik könnte > ja fordernd sein. Na dann schick sie mal in ein zeitgenössisches Konzert. Das ist garantiert fordernd.
:
Bearbeitet durch Moderator
Michael B. schrieb: > J. S. schrieb: >> kaum Beifall vom Aufraggeber > > Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die > Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei > rauskommt. Es geht nicht um Schuld, sondern Mitsprache. Und wenn der AG nicht in der Lage ist sein Produkt zu beschreiben oder 1.000x ändert oder die Prioritäten verschiebt?
Uwe D. schrieb: > Michael B. schrieb: >> J. S. schrieb: >>> kaum Beifall vom Aufraggeber >> >> Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die >> Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei >> rauskommt. > > Es geht nicht um Schuld, sondern Mitsprache. Und wenn der AG nicht in > der Lage ist sein Produkt zu beschreiben oder 1.000x ändert oder die > Prioritäten verschiebt? Eben dann ist er schuld und kann die Schuld nicht bei die Firma suchen die sein Projekt umsetzen sollte.
Ich glaube hier gibt es ein Verständnisproblem: Uwe D. schrieb: > Michael B. schrieb: >> J. S. schrieb: >>> kaum Beifall vom Aufraggeber >> >> Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die >> Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei >> rauskommt. > > Es geht nicht um Schuld, sondern Mitsprache. Und wenn der AG nicht in > der Lage ist sein Produkt zu beschreiben oder 1.000x ändert oder die > Prioritäten verschiebt? Seit wann sitzt der Auftraggeber im SCRUM Team? Und seit wann leitet der irgendetwas? Der sitzt in einer anderen Firma, gfs einer anderen Abteilung und will nur das Ergebnis. Leiten sollten sich das Scrum Team doch angeblich komplett selber?
Martin K. schrieb: > Seit wann sitzt der Auftraggeber im SCRUM Team? Er stellt den Product Owner im Team. .
Michael B. schrieb: > Martin K. schrieb: >> Seit wann sitzt der Auftraggeber im SCRUM Team? > > Er stellt den Product Owner im Team. Wer macht denn sowas?
Ein T. schrieb: > Michael B. schrieb: >> Martin K. schrieb: >>> Seit wann sitzt der Auftraggeber im SCRUM Team? >> >> Er stellt den Product Owner im Team. > > Wer macht denn sowas? Habe ich regelmäßig, auch in Großprojekten, das der PO durch den AG gestellt wird.
Rudi R. schrieb: > Tatsächlich wird Pair-Programming nur wenig Zeit gegeben, > obwohl da ein Greenhorn von einem Erfahrenen, der ich ja > mittlerweile bin, sehr gut lernen kann. Genau darum funktioniert Scrum bei dir nicht. Du bist halt ein Erfahrener, da haben die kleinen Kinder nix verloren und vergeuden nur deine Zeit. Wieso die überhaupt deine Luft atmen dürfen, weißt du bis heute nicht.
Mark B. schrieb: > Es gibt manche Branchen, in denen ist "Scheitern" der Normalfall. Zwei > Beispiele: Bauwesen und Eisenbahn. Es gibt nahezu kein Großprojekt im > Hoch-/ Tiefbau, in dem die ursprünglich geplanten Termine eingehalten > werden. Siehe Elbphilharmonie, Stuttgart 21, Berliner Flughafen, ... Garnicht so groß, ist hier im Straßenbau der Normalfall. Die Freigabe der sanierten Kreisstraße 90 verzögert sich leider um 5 Wochen, weil unerwartete Bodenverhältnisse vorgefunden wurden. Die Sanierung der Brücke Bahnhofstraße konnte leider noch nicht wie geplant fertiggestellt werden, weil Bohrungen auf unerwartete Hindernisse stießen. Der Ausbau der B79 verzögert sich auf unbestimmte Zeit, weil ... Das sind keine Flughäfen, sondern wenige km Straße! Ich habe den Eindruck, dass die Planer durchweg mit Unfähigkeit glänzen.
Ein T. schrieb: > Michael B. schrieb: >> Martin K. schrieb: >>> Seit wann sitzt der Auftraggeber im SCRUM Team? >> >> Er stellt den Product Owner im Team. > > Wer macht denn sowas? Stopp: Unter Auftraggeber verstehe ich nicht den PO, sondern eher das PM oder eine externe Firma. Uwe D. schrieb: > Habe ich regelmäßig, auch in Großprojekten, das der PO durch den AG > gestellt wird. D.h. der funkt euch dann ständig die Anforderungen rein? Dann sind die Aufwände ja nicht kalkulierbar. Wie läuft das dann mit Verrechnung? Stundenbasis, wenn sich was tut? Für mich als Selbständigen scheidet das total aus. Es braucht eine eng umrissene Aufgabe, die so wie bestellt auch abgearbeitet wird. Sie dazu auch: Beitrag "SCRUM und die Arbeitsweise von Selbständigen"
Martin K. schrieb: > Für mich als Selbständigen scheidet das total aus. Es braucht eine eng > umrissene Aufgabe, die so wie bestellt auch abgearbeitet wird. Für dich ist damit Scrum auch völlig unrelevant. Du machst geliefert wie bestellt ein Wasserfall oder V Modell.
Rudi R. schrieb: > Es gibt Neuigkeiten zu "meinem" Scrum-Projekt. Meine Warnungen an die > richtige Stelle adressiert, haben nun dazu geführt, dass andere Leute > mit dem Projekt betraut werden. Es hört nun hoffentlich auf mit der > Sprinterei und Scrummerei. Auch der personelle Zusammensetzung des alten > Teams war ja ungünstig, weil da kaum jemand länger als zwei Jahre in der > Firma war, d.h. viele Domänen- und Frameworkwissen einfach nicht da war. > Vielleicht mag ja das Scrum für irgendwelche Casual Games oder Websites > vernünftig sein und wer immer Scrum macht und nicht anderes kennt, der > wendet Scrum auf jedwedes Problem an. Das schrieb ich im Februar. Das neue Team ist etabliert, arbeitet seit April. Was hat sich nicht geändert: 1. Es gibt Sprints. Was hat sich geändert: 1. Es gibt viele kleine Commits. 2. Es wird schnell zusammengeführt, was die Entwickler programmieren. Das Gluckenproblem ist größtenteils weg. Das Gluckenproblem hatten wir bei einem Entwickler, der wochenlang an einer Sache arbeitete, anstatt schon mal etwas zu pushen, dass ich mir das hätte mal anschauen können. Ich erwähnte ja, dass ich viel refaktorieren musste. 3. Es gibt weniger Besprechungen. Es gibt eine wöchentliche Besprechung von einer knappen Stunde. Das war's. 4. Es gibt keine ausufernden Sprintplanungen. Wir hatten ja zuvor eine Scrum-Masterin, die tagelang herausarbeitete, welche Tasks im nächsten Sprint sein müssen. Das war ja genau diese Besprechungen, die mich so ankotzten, denn in der Zeit hätte ich ja vieles schon machen können. 5. Es gibt kein Sprint-Ziel. Wenn man was nicht schafft, ist es auch wurscht. Die zu mir zugwiesenen Tasks sind so allgemein formuliert, dass eine Definition of Done schon schwierig ist. 6. Gesunder Menschenverstand ist wieder eingekehrt. 7. Es macht wieder Spaß.
Heißt das nun, ihr habt Scrum faktisch abgeschafft, oder modifiziert? Das hier: Rudi R. schrieb: > 1. Es gibt Sprints. passt irgendwie nicht zu dem: Rudi R. schrieb: > 5. Es gibt kein Sprint-Ziel. Kingt nach ziellosem Entwickeln. Wodurch definiert sich dann ein Sprint? Zeitraster? Michael B. schrieb: > Martin K. schrieb: >> Für mich als Selbständigen scheidet das total aus. Es braucht eine eng >> umrissene Aufgabe, die so wie bestellt auch abgearbeitet wird. > > Für dich ist damit Scrum auch völlig unrelevant. So sehe ich das auch.
Martin K. schrieb: > Ein T. schrieb: >> Michael B. schrieb: >>> Martin K. schrieb: >>>> Seit wann sitzt der Auftraggeber im SCRUM Team? >>> >>> Er stellt den Product Owner im Team. >> >> Wer macht denn sowas? > > Stopp: Unter Auftraggeber verstehe ich nicht den PO, sondern eher das PM > oder eine externe Firma. Dein Verständnis bildet nur eine Möglichkeit ab. Selbstverständlich kann der Endkunde auch der Auftraggeber sein. Vielleicht in Deiner bisherigen Welt nicht. Beispiel: Fraunhofer IPK entwickelt ein Messtool für Schmelzanlagen (Glas). Das ist natürlich kein Serienprodukt. > > Uwe D. schrieb: >> Habe ich regelmäßig, auch in Großprojekten, das der PO durch den AG >> gestellt wird. > D.h. der funkt euch dann ständig die Anforderungen rein? > Häh? Der PO legt die Anforderungen zusammen mit seinem Fachleuten fest schreibt diese in EPICS/FEATURES/USER STORIES und bespricht diese mit dem SCRUM Team im Refinement… Der PO legt fest was wichtig ist und gibt die Marschrichtung vor. Du hast den Sinn und Nutzen offenbar nicht verstanden. Und wenn der Endkunde - aka Auftraggeber - sagt STOPP, dann ist es eben so. Wir bekommen die Sprintziele bezahlt und müssen diese natürlich auch wie vereinbart liefern (inkl. State of the art). Und natürlich behalten wir als AN eine Beratungspflicht, falls der PO etwas ziemlich „blödes“ will - das ist ja aber das normalste Ding. Gesetzliche Regeln gelten natürlich auch bei SCRUM.
:
Bearbeitet durch User
Rudi R. schrieb: > 3. Es gibt weniger Besprechungen. Es gibt eine wöchentliche Besprechung > von einer knappen Stunde. Das war's. > 6. Gesunder Menschenverstand ist wieder eingekehrt. > 7. Es macht wieder Spaß. Als ich das gelesen habe, habe ich mir erstmal gedacht, dass du tatsächlich als Person in einer modernen Welt in der Software-Entwicklung völlig ungeeignet bist. Man kann das ja kurz zusammenfassen: 3. Die lassen mich endlich in Ruhe, ich kann meinen Kram machen so, wie ich es schon immer gemacht habe! Damals war es gut! Okay, heute knacken meine Knochen, und meine Haut kriegt immer mehr Falten, aber DAMALS WAR ES GUT! 6. Ich habe es schon immer besser gewusst, die anderen sind alle dumm, was für ne Versammlung von modernen Wichsern, ICH ICH kann es! Zu 7.: Deine Bude geht den Bach runter. Wer nicht in der Lage ist, vernünftige Konzepte wie Scrum, Scrum 2, Kanban etc. nicht nur zu lesen, sondern zu verinnerlichen, da würde ich als Geschäftsführer eine möglichst knappe Abfindung auf die Kündigung drauf legen, um solche Leute los zu werden. Und ich würde auch darauf schauen, Kunden, die so ticken, ebenfalls nach und nach abzustoßen.
Carsten P. schrieb: > Genau darum funktioniert Scrum bei dir nicht. Du bist halt ein > Erfahrener, da haben die kleinen Kinder nix verloren und vergeuden nur > deine Zeit. Wieso die überhaupt deine Luft atmen dürfen, weißt du bis > heute nicht. Endlich mal jemand der das versteht. Mein Chef meint immer man müsse auch mit Low Performern arbeiten und redet immer was von "weniger Arroganz" usw. Unverständlich!
:
Bearbeitet durch User
Cyblord -. schrieb: > Endlich mal jemand der das versteht. Mein Chef meint immer man müsse > auch mit Low Performern arbeiten und redet immer was von "weniger > Arroganz" usw. Unverständlich! So unverständlich ist es gar nicht, falls du das ernst gemeint hast. Manche Leute kleben halt an ihrem Job wie in einer Behörde. Da wurde schon immer alles genau so gemacht, wieso sollten wir denn da was ändern, da könnte ja jeder Dahergelaufene kommen und mir sagen, dass ich mich zu ändern habe. Es soll Leute geben, die Depressionen bekommen haben bei einer Umstellung von Fax auf E-Mail. Der Unterschied, um aufs Thema zu kommen, zwischen Meeting und Scrum -- oder zwischen Individuen und Teams ist, dass in einem guten Team nicht darum geht, wer schuldig ist an einem Fehler, sondern darum, gemeinsam das Ziel zu erreichen. In einem klassischen Unternehmen braucht man Controller, um auf Menschen zu zeigen, um ihre persönlichen Fehler in Geld umzurechnen und sie dann rauszuschmeißen. In einem modernen Unternehmen braucht man sie nicht, weil das Team gemeinsam den Fehler behebt, eingedenk dessen, dass jeder mal nen Bug eincheckt. Und statt dann Fingerpointing zu betreiben, kümmert sich so ein gutes Team um Tests und Automatisierung in der Software-Entwicklung, damit das keinem mehr passiert. So habe ich das jedenfalls zB bei der DATEV kennengelernt. Da gibt es keine Obstschalen für alle, und man geht nicht jeden Abend Tanzen wegen erzwungener Gemeinschaft, sondern man hört einfach auf, die Fehler auf andere zu schieben, und fixt sie einfach. Das hat aber auch viel mit Charakter zu tun, unter anderem einem so guten Selbstbewusstsein, dass man dazu steht, auch mal Mist zu bauen. Und wenn sich alle dieser Tatsache bewusst sind, dass das halt allen mal passiert, gibt es kein "DUUU bist schuld!" mehr, auch nicht von den Vorgesetzten. Und genau dann kann man auch ein paar Steine mitschleppen, die im Team genau diesen einen Job machen und geistig nicht mehr willens sind, etwas Neues zu machen. Das Team ist dann flexibel genug und kann das kompensieren.
:
Bearbeitet durch User
Carsten P. schrieb: > dass in einem guten Team nicht > darum geht, wer schuldig ist an einem Fehler, Du hast aber schon mitbekommen, dass das Aufarbeiten von Fehlern ein integraler Bestandteil des SCRUM-Prozesses ist? Es geht ja vor allem um die inhaltliche Verbesserung der Zusammenarbeit, z.B. Art und Umfang der Kommunikation, die Menge der vorgelagerten Konzeptarbeit, Aufwand für Prüfungen am Arbeitsplatz vor der Weitergabe an Kollegen. Dafür reserviert Scrum ja sogar Termine im Prozess. Da kommt man um Kritik an Falschem nicht herum. Und: Carsten P. schrieb: > die Fehler auf andere zu schieben, und fixt sie einfach. Es geht nicht ums "Verschieben", sondern um das "Benennen". Wenn man von Teammitgliedern ein ständiges Lernen und sich-Verbessern fordert, braucht es auch Anhaltspunkte dafür. Spontanes Kompensieren kann man für schnelle ad hoc Tätigkeiten nutzen, wenn schnell eine Lösung her muss. Mal eben aber an den Tasks anderer herumdoktern, widerspricht auch irgendwo der Scrum-Strategie. So entsteht ja wieder ein Chaos nach dem Motto jeder macht alles und vorgelagerte Taskplanungen werden konterkariert. Ein stillschweigendes Korrigieren kann sogar dazu führen, dass das System immer mehr dahin geht, weil sich einige angewöhnen, "schnell" zu arbeiten und die Fehlersuche auf andere verlagern.
Carsten P. schrieb: > In einem klassischen Unternehmen braucht man > Controller, um auf Menschen zu zeigen, um ihre persönlichen Fehler in > Geld umzurechnen und sie dann rauszuschmeißen. In einem modernen > Unternehmen braucht man sie nicht, weil das Team gemeinsam den Fehler > behebt, eingedenk dessen, dass jeder mal nen Bug eincheckt. Und statt > dann Fingerpointing zu betreiben, kümmert sich so ein gutes Team um > Tests und Automatisierung in der Software-Entwicklung, damit das keinem > mehr passiert. So habe ich das jedenfalls zB bei der DATEV > kennengelernt. Da gibt es keine Obstschalen für alle, und man geht nicht > jeden Abend Tanzen wegen erzwungener Gemeinschaft, sondern man hört > einfach auf, die Fehler auf andere zu schieben, und fixt sie einfach. (...) > Und wenn sich alle dieser Tatsache bewusst sind, dass das halt allen mal > passiert, gibt es kein "DUUU bist schuld!" mehr, auch nicht von den > Vorgesetzten. Ich lese das sorgfältig - aber es bleibt für mich die Frage, wozu ein "modernes Unternehmen", das bereits eine gute Fehlerkultur und Teststrategie hat, dann so ein Scrum braucht. Genausowenig wie ein gute Ehe die ganze Branche der Eheberater braucht und auch auf irgendwelche stereotypen Rituale und Zeremonien scheissen kann.
Moin, beinhalten Eure Scrum Mitglieder auch Kollegen von der HW Seite? Oder arbeitet man nur mit geprüfter, fertiger Elektronik Baugruppen-HW? Arbeiten die Kollegen da manchmal noch in parallel um HW zu optimieren oder zu debuggen? Wie sieht da die Zusammenarbeit diesbezüglich aus und laesst sich das auf einen gemeinsamen Nenner bringen? Diesen Aspekt habe ich hier noch nicht bemerkt. Finde ich aber wichtig. Gruß, Gerhard
:
Bearbeitet durch User
Carsten P. schrieb: > So unverständlich ist es gar nicht, falls du das ernst gemeint hast. > Manche Leute kleben halt an ihrem Job wie in einer Behörde. Da wurde > schon immer alles genau so gemacht, wieso sollten wir denn da was > ändern, da könnte ja jeder Dahergelaufene kommen und mir sagen, dass ich > mich zu ändern habe. Es soll Leute geben, die Depressionen bekommen > haben bei einer Umstellung von Fax auf E-Mail. Es geht nicht um das Kleben an einem Job. Es geht auch nicht behördenartig zu. Nur weil etwas nue ist, ist es nicht besser. Das hat man in der SW-Entwicklung immer und immer wieder erlebt. Und was ist die Quintessenz daraus: Sei ein guter Entwickler und verbessere dich stetig. Setze deinen Verstand ein. Methodik entwickelt keine Software. Es ist der denkende Mensch. Die Methode bringt weder die richtigen Algorithmen noch die richtige Architektur hervor. > > Der Unterschied, um aufs Thema zu kommen, zwischen Meeting und Scrum -- > oder zwischen Individuen und Teams ist, dass in einem guten Team nicht > darum geht, wer schuldig ist an einem Fehler, sondern darum, gemeinsam > das Ziel zu erreichen. In einem klassischen Unternehmen braucht man > Controller, um auf Menschen zu zeigen, um ihre persönlichen Fehler in > Geld umzurechnen und sie dann rauszuschmeißen. Es sollte jedem bewusst sein, dass da eine gewisse Effizenz ist. Niemand hat Verständnis mit Sohnemann, wenn man ihn drei Aufgabe gibt: Post einwerfen, Lebensmittel einkaufen und den Anzug aus der Reinigung zu holen, er aber dreimal in die Stadt fährt, obwohl Reinigung, Briefkasten und Supermarkt direkt beieinander stehen. > In einem modernen > Unternehmen braucht man sie nicht, weil das Team gemeinsam den Fehler > behebt, eingedenk dessen, dass jeder mal nen Bug eincheckt. Dieses Bewusstsein gibt es auch in klassischen Unternnehmen. Wenn man aber Zeit verballert und alles in Sprints kaputtschnürt, dann bleibt wenig Zeit für Fehlerbehebung. > Und statt > dann Fingerpointing zu betreiben, kümmert sich so ein gutes Team um > Tests und Automatisierung in der Software-Entwicklung, damit das keinem > mehr passiert. Fehler muss man ansprechen, sonst gibt es ja keine Verbesserung. > So habe ich das jedenfalls zB bei der DATEV > kennengelernt. Da gibt es keine Obstschalen für alle, und man geht nicht > jeden Abend Tanzen wegen erzwungener Gemeinschaft, sondern man hört > einfach auf, die Fehler auf andere zu schieben, und fixt sie einfach. Hat nichts modernen Unternehmen zu tun. > Das hat aber auch viel mit Charakter zu tun, unter anderem einem so > guten Selbstbewusstsein, dass man dazu steht, auch mal Mist zu bauen. Ja, richtig. > Und wenn sich alle dieser Tatsache bewusst sind, dass das halt allen mal > passiert, gibt es kein "DUUU bist schuld!" mehr, auch nicht von den > Vorgesetzten. > Fände ich nicht schlimm. Man lernt für gewöhnlich aus Fehlern, also muss man sie benennen. Wie oft habe ich als Entwickler in den letzten 30 Jahren falsches programmiert. Da schließe ich die Zeit als 12-jähriger ein, als ich mit QBasic programmiert habe, aber natürlich auch später, als ich längst Senior-Entwickler war. > Und genau dann kann man auch ein paar Steine mitschleppen, die im Team > genau diesen einen Job machen und geistig nicht mehr willens sind, etwas > Neues zu machen. Das Team ist dann flexibel genug und kann das > kompensieren. Scrum ist ja nichts neues, sondern schon wieder 20 Jahre alt und meines Erachtens gescheitert. Scrum ist die Illusion, die jedem noch so inkompetenten Entwicklerteam einflüstert: "Tschakka, ihr schafft das."
> Carsten P. schrieb: > konterkariert. Ein stillschweigendes Korrigieren kann sogar dazu führen, > dass das System immer mehr dahin geht, weil sich einige angewöhnen, > "schnell" zu arbeiten und die Fehlersuche auf andere verlagern. Stillschweigend sollte man natürlich nicht korrigieren. Es gibt ja mehrere Arten von Fehlern: 1. Schussligkeitsfehler. Man erkennt ja am Code drumherum, dass der Entwickler sowohl fachlich, algoirithmisch und architektonische auf der Höhe ist oder nicht. Ich korrigiere dies, schreib 'ne Mail an den Entwickler. Es gibt Leute, die dann austicken. Diese sind dann bei mir dann unten durch. Ich habe auch schon solche Korrekturen und Mails an meinem Code erlebt, war aber nicht am Austicken, obwohl die Person hätte erkennen müssen, dass es nur ein Schussligkeitsfehler ist, es aber eine Belehrung gibt hinsichtlich der anderen Archtitektur, Algorithmus usw. Womit wir zur nächsten Fehlerart kommen. 2. Fehler hinsichtlich der Architektur, des Designs und des Algorithmus. Da muss man dann auch schon weiter ausholen und das würde ich persönlich besprechen. Leider ist es so, dass vielen diese Themen komplett abhold sind. Wenn ich erkläre, bitte nicht Polling implementieren, sondern das Beobachter-Muster einsetzen, dann stoße ich da schon an Grenzen. 3. Fachliche Fehler gibt es auch noch, wenn jemand die Spezifikation falsch verstanden hat. Sollte man klären wie 2., aber das Kompetenzgefälle ist da nicht so groß, als dass sich jemand gekränkt fühlt könnte. Ich habe auch schon erlebt, dass jemand einen kleinen Algorithmus 1:1 umsetzte, einen Fehler meinte erkannt zu haben, ohne aber verantwortungsbewusst es ohne diesen Fehler zu implementieren. Der Fehler war eine triviale Definitionslücke. Ich weiß rückblickend nicht, ob er schon mit manchen Leuten im Clinch lag und vielleicht deshalb das Unternehmen verließ. Mir kam das seltsam vor und ich mag es auch nicht, wenn jemand seinen Verstand an der Garderobe abgibt, oder ob da schon ein Vermeidungsverhalten vorlag, weil irgendwas vorgefallen ist. Er traute sich vielleicht gar nicht mehr, den Fehler selbst anzusprechen oder einfach eigenmächtig die Definitionslücke zu schließen. Das wäre in der Tat ein kulturelles Problem, wenn die Chefs/Projektleiter einschüchternd auf die Leute einwirken. Aber das kann Scrum weder abstellen noch wird es durch Scrum befördert. Wir hatten ja wirklich auche inen Projektleiter, der bei manchen Leuten (v.a. beim Kunden) gut ankam, aber auch seine persönlichen Defizite hatte und möglicherweise aufgrunddessen, dass er nur Quereinsteiger war (Elektrotechniker, ohne Algorithmenkompetenz), Diskussionen schnell abwürgte. Ich Anekdote habe ich ja schon mal erzählt, dass er aus dem Bauch heraus eine Entscheidung traf, wo ich dann sagte: "Wollen wir das nicht mal diskutieren?" Denn ich sah sofort Probleme. Er war zur Diskussion nicht bereit, ein Entwickler setzte es um und ich habe die ganze Implementierung Wochen später ersetzt, das sie nur Ärger machte. Und ich ersetzte sie durch jene, die ich von Anfang an im Sinn hatte.
Cyblord -. schrieb: > Das ist wie mit dem Kommunismus. Er ist überall gescheitert. Aber > natürlich nicht weil er schlecht ist. Er wurde immer nur schlecht > umgesetzt. Naja, einerseits kann man vergessen dass sich jeder nur so viel nimmt wie er braucht, weil jeder will immer mehr haben und wenn dort im Regal Brot, Kohl und Schokoriegel liegen, dann würde sich der erste seinen Einkaufskorb mit allen Schokoriegeln voll machen und die anderen bekommen dann nur noch Brot und Kohl. Der Kommunismus funktioniert aber eben nur genau dann, wenn man Ressourcen im Überfluss hat. Und das nicht weil man dafür im Überfluss leben muss, es geht dabei einfach nur um die Leute welche dabei immer an der Spitze sind. Das sieht man auch an Berlin, die Sozis dort geben das Geld mit beiden Händen aus und können ohne Länderfinanzausgleich nicht ein Jahr überleben, weil es ihnen einfach aus den Fingern rinnt. Die geben aber auch Millionen für nutzlose Projekte aus, zum Beispiel die Straßen welche sie verbarrikadieren und dort temporär Bäume in Pflanzkübel auf die Straße stellen. Die Autofahrer müssen dann Umwege fahren und verpesten die Luft, sorgen für mehr Lärm und Verkehr in anderen Straßen. Ich wette die Leute von SPD oder Grünen leben dort und wollen ihre Ruhe haben, deshalb packen sie da für ein paar Millionen Euro diese Pflanzkübel hin.
Gerhard O. schrieb: > Arbeiten die Kollegen da manchmal noch in parallel um HW zu optimieren > oder zu debuggen? > > Wie sieht da die Zusammenarbeit diesbezüglich aus und laesst sich das > auf einen gemeinsamen Nenner bringen? Wir machen Hardware und Software. Während der Woche schafft jeder was er kann, stimmt sich mit den Leuten ab die für seine Arbeit notwendig sind und am Freitag setzt man sich noch mal zusammen, das kann aber in Fällen wo viel geklärt werden muss dann über mehrere Stunden gehen, so dass man dann auch mal erst 21 Uhr wieder zu Hause ist. Meist hat man die Dinge aber schon während der Woche besprochen und am Freitag wird quasi alles rekapituliert und für die nächste Woche geplant. Etwa jeden Monat trifft man sich mit dem Auftraggeber, aber das ist eigentlich auch dynamisch und je nach Notwendigkeit. Es müssen auch nicht alle mit dabei sein. Scrum hatten wir zwar in der Uni beim Projektmanagement, aber in der Art nutzt man es bei uns nicht. Änderungen werde sofort umgesetzt, denn man will ja keine Zeit damit verschwenden sinnlose Dinge zu tun. Wir sitzen aber quasi alle in einem Raum, die Firma ist nicht so groß und die Kommunikation ist einfach. Wenn irgend etwas ist, dann kommt man mal kurz rüber und klärt das. Das finde ich so gut, habe aber auch nie in einer wirklich großen Firma gearbeitet und weiß nicht wie es da so ist.
Rudi R. schrieb: > Scrum ist ja nichts neues, sondern schon wieder 20 Jahre alt und meines > Erachtens gescheitert. So hart würde ich es nicht formulieren, aber man muss sich eingestehen, dass so wie Scrum vielfach betrieben wird, nichts Neues gebracht- und auch keine Probleme behoben hat. Wenn als Beispiel der Informationsaustausch unter den Teammitgliedern nicht funktioniert, dann wird das mit Scrum meistens schlechter, weil alle denken, dass das ja hetzt geregelt ist. Man befolgt die Scrum-Regeln und nimmt an den meetings teil und alles ist gut. Rudi R. schrieb: > ein Entwickler setzte es um und ich habe die > ganze Implementierung Wochen später ersetzt, das sie nur Ärger machte. > Und ich ersetzte sie durch jene, die ich von Anfang an im Sinn hatte. Das ist ein schönes Beispiel. Jeder macht was er will und man arbeitet gegen- statt miteinander. Bevor man so irgendwas einführt und mit Begriffen wie "Dynamik" und "Agilität" um sich wirft, um die Performance zu steigern, müssen zunächst die basics gelegt werden, d.h. die Mitarbeiter dazu angehalten werden, zu einem gemeinsamen Arbeitsstil zu gelangen. Wenn das nicht der Fall ist, kriegtst du nichts zusammen.
Joe schrieb: > Ich lese das sorgfältig - aber es bleibt für mich die Frage, wozu ein > "modernes Unternehmen", das bereits eine gute Fehlerkultur und > Teststrategie hat, dann so ein Scrum braucht. Genausowenig wie ein gute > Ehe die ganze Branche der Eheberater braucht und auch auf irgendwelche > stereotypen Rituale und Zeremonien scheissen kann. Auf die einzelne Persönlichkeit von einem "idealen" Entwickler bezogen hast du absolut Recht. Ich sehe Scrum oder auf noch weniger starre Regeln basierte Konzepte wie Scrumban da auch positiv. Nochmals auf die DATEV bezogen, wo ich es eben so kennengelernt habe, gab es auch mal Streit über Themen, ob eine private Variable mit _-Präfix oder ohne definiert werden sollte und ob "this." geschrieben werden sollte oder nicht (C#). Ich sage es mal so: Wenn Teams sich über solche Dinge streiten, muss das Produkt echt gut sein, denn sonst hätten die Leute Anderes zu tun ;-) Anders herum geht es aber so: Wenn Individuen sich nichtmal an Scrum gewöhnen können, ist das Projekt schon zum Scheitern verurteilt. Wenn sie es alle miteinander im Sinn von einem Miteinander können, braucht man Scrum nicht mehr oder nur als Maßstab an der Wand, ohne dass man sich da jeden Morgen treffen und messen muss. Dann sollte die Entwicklungsumgebung die Arbeit strukturieren, etwa "Oh, Bug, mein Thema, den nehm ich mir und fixe ihn!" Ich kann nur nochmals von der DATEV erzählen. In dem Team damals habe ich den Projektleiter angequatscht, ob ich (externer Mitarbeiter) zwei Stunden für das Thema LINQ und ForAll kriegen kann. Er sagte "ja, klar!", alle waren da, manche waren danach angestrengt und haben Nachfragen gestellt, und nachdem dann alle bereit waren, das Konzept zu antizipieren, wurde der gesamte Code innerhalb von 3 Monaten doppelt so schnell und auch noch zuverlässiger trotz Parallelisierung. Und der eine Kollege, der sich partout nicht beteiligen wollte, hat sein Zeug gemacht wie bisher, und niemand hat in seinen Code gehackt, um sein Ego nicht zu beißen. Das Projekt ist an diesem einen nicht gescheitert. Aber klar, wenn du viele solche Totalverweigerer im Team hast, die nur Fingerpointing betreiben wollen, um ihren Arsch zu retten, hilft Scrum auch nicht. Hier kommt es freilich auch sehr auf die Teamleitung und die höheren Ebenen an. Bei der DATEV war es damals nach meinen Erfahrung von Team zu Team so oder so, aber darüber hatten sich schon Strukturen etabliert, die diese Team-Orientierung absolut unterstützt haben.
:
Bearbeitet durch User
Carsten P. schrieb: > Anders herum geht es aber so: Wenn Individuen sich nichtmal an Scrum > gewöhnen können, ist das Projekt schon zum Scheitern verurteilt. Wenn > sie es alle miteinander im Sinn von einem Miteinander können, braucht > man Scrum nicht mehr oder nur als Maßstab an der Wand, ohne dass man > sich da jeden Morgen treffen und messen muss. Wenn Du von "an Scrum gewöhnen" sprichst: Man kann sich an viel gewöhnen, es bleibt halt die Frage, wie sinnvoll die Zeremonien sind. Im Manifest heißt es, "Individuals and Interactions over Processes and Tools". Man braucht doch solche blöden festen Zeremonien wie z.B. Retrospective nicht. In dem Sinne, daß man nach jedem Sprint einen festen Termin geblockt hat, wo alle unbedingt ihren Senf dazu geben müssen, was sie am letzten Sprint gut fanden und was nicht. Stell Dir ein Eheberater vor, der einen Prozess vorschreibt, wo die Familie jede Woche am Samstag etwas zusammen macht. Anschließend muss jedes Mitglied vom Nesthäkchen bis zum "Familienoberhaupt" sagen, was es toll fand und was nicht. Der Mann hat der Frau einmal morgens und einmal abends ein Kompliment zu machen und umgekehrt. Für das Thema Haushaltsgeld wird einmal im Monat eine Stunde geblockt. Aber natürlich gibt es auch Freiheiten: Der Mann darf Donnerstag und Sonntag zum Stammtisch und die Frau zweimal die Woche ihre Freundinnen zum Kaffeekränzchen treffen. (Die "Sei-Spontan-Paradoxie" von Watzlawick lässt grüßen). Will damit sagen: Man muss diesen Scrum-Käfig doch nicht haben! Wenn man sich abstimmen will, greift man zum Telefonhörer, wenn man Probleme hat, wendet man sich an einen Kollegen und wenn etwas blöd gelaufen ist, dann setzt man sich zusammen und redet darüber. Wenn das schon nicht klappt, dann klappt auch Scrum nicht. Erzwungene feste Termine nerven, ich habe weiter oben schon das Parkinsonsche Gesetz der Trivialität erwähnt, nachdem es unmöglich ist, im großen Kreis über anspruchsvollere Themen zu sprechen.
Joe schrieb: > Zeremonien Wahrscheinlich die treffendste Beschreibung: Projekte mit 2 oder 30 Beteiligten, Anfänger oder Experten oder Jahresammler, Bekanntes oder Innovatives, Write only vs. 20 Jahre support, IG-Metall-Disney vs. Startup, ... Wenn ein paar gute Leute dabei sind und machen dürfen, gelingt es meist trotz Scrum, mit unfähigen Diven, unmotivierten Anfängern oder zu vielen Köchen vielleicht nur wegen. Zeremonien, die typische blinde Flecken ans Licht bringen, die aber nie Selbstzweck sein dürfen.
Robert K. schrieb: > Rudi R. schrieb: >> ein Entwickler setzte es um und ich habe die >> ganze Implementierung Wochen später ersetzt, das sie nur Ärger machte. >> Und ich ersetzte sie durch jene, die ich von Anfang an im Sinn hatte. > > Das ist ein schönes Beispiel. Jeder macht was er will und man arbeitet > gegen- statt miteinander. Nein, das ist kein schönes Beispiel für "jeder macht, was er will", wenn du damit mich gemeint haben willst. Ich habe eine Fehlkonstruktion behoben. Eine Fehlkonstruktion, die durch durch abgehobenes Treffen von Entscheidungen enstanden ist, und dabei den Fachmann (also mich!) zu übergehen. Die Fehlentscheidung sorgte wochenlang für heißlaufende Telefondrähte und wurde dann durch mich behoben. Woher die Fehlentscheidung kam, das habe ich während nicht offen thematisiert. Da geht's auch Gesichtswahrung und Loyalität. Ich wurde ja angepflaumt, warum es nicht funktionierte. Die Implementierung des Kollegen entsprach prinzipiell der Vorgabe, war also nicht falsch. Die Vorgabe war falsch. Ich habe später aber auch keine Lorbeeren kassiert, weil ich die Chose reparierte.
Rudi R. schrieb: > Nein, das ist kein schönes Beispiel für "jeder macht, was er will", > wenn du damit mich gemeint haben willst. Ich habe eine Fehlkonstruktion > behoben. Eine Fehlkonstruktion, die durch durch abgehobenes Treffen von > Entscheidungen enstanden ist, und dabei den Fachmann (also mich!) zu > übergehen. Das Übergehen von Leuten mit den entsprechenden Kompetenzen hört sich für mich jetzt aber sehr sehr nach "jeder macht, was er will" an, und wenn Du bei dem "abgehobenen Treffen" anwesend gewesen wärst oder zum Beispiel in einem Scrum Daily Standup davon erfahren hättest, daß jemand anders an Deinem Fachgebiet arbeiten soll, dann hättest Du rechtzeitig einschreiten können. Insofern ist Dein Beispiel in meinen Augen ein sehr gutes Beispiel dafür, wie es ohne die Verwendung von agilen Methoden zu Informationsverlusten kommen kann, die es mit einer agilen Vorgehensweise nicht gegeben hätte.
Uwe D. schrieb: > Ich selbst kann nur von europäischen Firmen sprechen. Wer schon einmal > eine Software mit SIL > 2 mitgebaut hat - oder eine Zertifizierung nach > Common Criteria ab EAL3 aufwärts, der weiß das da extrem viel > Formalismus, Disziplin und vor allem langer Atem notwendig ist, um > erfolgreich (in Quality, Time & Budget) zu sein. > > Jede Menge Systeme wird genau so und mit SCRUM gebaut. Das betrifft > Aviation, Rail, Automotive, Computing… Meiner Erfahrung nach werden jede Menge Systeme TROTZ SCRUM gebaut. Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die Sicherheit des Produkts erhöht wird. Das einzige, was sich immer weiter erhöht, ist der Preis und wir haben in der Industrie mittlerweile einen Bürokratisierungsstand erreicht, der uns bald nach und nach vom Markt fegen wird! Der ganze Kram nennt sich "agil", ist aber eigentlich eine sehr formalistische und höchst unflexible Geschichte, die erkennbar für die Führung von vielen unselbstständigen Entwicklern in Form eines Mikro-Managements entwickelt wurde. Ich komme eigentlich ursprünglich aus der Forschung und Vorentwicklung. Dort ist man es gewohnt, Dinge eigenständig zu planen und zu entwickeln, auch in Gruppen. Auf geänderte Rahmenbedingungen konnte man sehr schnell reagieren und insbesondere sich selbst frei organisieren. Das konnten die Leute, weil sie genau das gelernt haben, schon im nicht-verschulten Studium. Seit vielen Jahren in der Serienentwicklung lief das ähnlich. Produkte wurden in immer besserer Qualität in annehmbarer Zeit entwickelt. Und das bei mehreren Kunden gleichzeitig, die nicht nur unterschiedliche Anforderungen hatten, sondern auch zu ganz verschiedenen Zeiten ihre Serienanläufe, Inbetriebnahmen, Fehler-Reports usw. Dazwischen Akquisen, Abstimmungen, seriennahe Vorentwicklung, damit auch für die nächste Produktgeneration genügend Fleisch da ist, womit man Konkurrenten ausstechen kann. Dieser SCRUM-Quark dagegen ist Gleichmacherei; flexible und eigenverantwortliche, ergebnisorientierte Arbeit (wo jede verdammte Stunde irgendein Kunde die ganze alberne "Sprint"-Planung durch irgendeine Anfrage, Error-Report, Akquise in den Abfluss spülen kann) wird durch sogenannte "agile" Prozesse ersetzt, die vielleicht für einfache Entwicklungs-Fließbandarbeit durch unselbstständige Entwickler geeignet sind, aber nicht für Firmen mit sehr hohen Lohnkosten, die sich allein durch etwas mehr Innovation am Markt halten können.
Gastino G. schrieb: > Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die > Sicherheit des Produkts erhöht wird. Das ist aber jetzt ein von Scrum losgelöstes Thema, wenngleich ein interessantes: Grundsätzlich soll der Papierkram ja sicherstellen DASS nach den Normen entwickelt und getestet wurde und die Prüfungen gelaufen sind. Ohne Papier wird es daher nicht notwendigerweise unsicherer, aber die Vorgehensweise ist belegbar und irgendwo auch tatsächlich belegt. Damit ist die Sicherheit formell zumindest bestätigt und durchaus höher. Das gilt natürlich nur, sofern a) die Prozesse auch eingehalten wurden und b) diese Vorgaben auch adequat waren, was beides nicht unbedingt der Fall ist. Ich sehe im Rahmen sicherheitskritischer Entwicklungen immer wieder FOkus an Stellen, die früher mal kritisch waren und als Folge in die Prozess- und Prüfungslandschaft eingelossen sind, heute aber längst gelöst und überholt sind. Teilweise sind die sogar der Sicherheit entgegenstehend. Anders herum gibt es Dinge, sich sich noch nicht in den Vorgaben niedergeschlagem haben, obwohl die fortschreitende Technik diese Probleme aufwirft. Damit stehen sie einer maximalen Sicherheit sogar im Wege.
Gastino G. schrieb: > Meiner Erfahrung nach werden jede Menge Systeme TROTZ SCRUM gebaut. So kann man das stehen lassen und hinzufügen, dass viele Projekte trotz signifikanter Abweichungen von Scrum (im positiven wie im negativen Sinne) kurzerhand trotzdem als nach Scrum durchgeführt deklariert werden, weil ein solcher Prozess drüber gestülpt und durchgeführt wurde. Die Befürworter sehen das als Bestätigung des System, obwohl der Erfolg des Projekts ohne Scrum besser- und vor allem billiger gewesen wäre. Der allgemeine Tenor ist aber immer noch Pro-Scrum und zwar firmen- abteilungs- und projektweit, daher ist dagegen nur schwer anzugehen. Es sind noch zu wenige Firmen, die nach Jahren mit Scrum die Auswirkungen gesehen und auch wirklich mal ein screening von Kosten und Nutzen gemacht haben, und es dann wieder rausgeworfen haben. Es wird noch dauern, bis sich Srum wirklich gesetzt hat und nur dort eingesetzt wird, wo es funktionieren kann. Dazu passt dieser Beitrag von oben:
Ein T. schrieb: > Das Übergehen von Leuten mit den entsprechenden Kompetenzen hört sich > für mich jetzt aber sehr sehr nach "jeder macht, was er will" an, In der Tat. Für mich auch. Allerdings: > wenn Du bei dem "abgehobenen Treffen" anwesend gewesen wärst oder zum > Beispiel in einem Scrum Daily Standup davon erfahren hättest, daß jemand > anders an Deinem Fachgebiet arbeiten soll, dann hättest Du rechtzeitig > einschreiten können. Das wäre die Frage ob er da wirklich gefehlt hat, denn das Übergehen ist bei einem Mehrheitsentscheid des Teams oft die Regel. Die eigentlich richtige Idee dahinter ist die angenommene Gruppenintelligenz, die den Einzelfehler verhindern soll. Das funktioniert natürlich nur, wenn die Gruppe diese Kompetenz auch hat! Das ist aber bei Weitem nicht der Fall und gilt nur für kleine GRuppen und daher funktioniert Scrum eben nur bei homogenen Gruppen ähnlichen Knowhows. Ansonsten setzt sich immer nur die durchschnittlich intelligente Lösung durch, die alle noch überblicken, und die gute Lösung des Fachmanns nicht, weil er alleine dasteht. Wie oben auch eingeworfen, zieht damit die durchschnittliche Entwicklerschaft die Leitung runter, statt hoch! > Insofern ist Dein Beispiel in meinen Augen ein sehr > gutes Beispiel dafür, wie es ohne die Verwendung von agilen Methoden zu > Informationsverlusten kommen kann, die es mit einer agilen > Vorgehensweise nicht gegeben hätte. Da sehe ich einen Interpretationsfehler deinerseits: In diesem Beispiel zeigt es sich ja gerade, dass es nicht der Informationsverlust ist, sondern mangelnde Kompetenz. Scrum wurde auf eine zu heterogene Gruppe angewendet, wo es nicht funktionieren kann. Gastino G. schrieb: > wird durch sogenannte "agile" Prozesse ersetzt, die vielleicht für > einfache Entwicklungs-Fließbandarbeit durch unselbstständige Entwickler > geeignet sind, genau das!
J. S. schrieb: > Gastino G. schrieb: >> Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die >> Sicherheit des Produkts erhöht wird. > > Das ist aber jetzt ein von Scrum losgelöstes Thema, Natürlich ist das alles ganz alleine Scrum schuld. Genau wie an den beiden Weltkriegen, Tschernobyl, Fukushima und der Versenkung der Rainbow Warrior, das war alles Scrum! (Aufmerksame Beobachter hätten das allerdings schon vorhersehen können, als Scrum den armen Jesus gekreuzigt hat.)
Ein T. schrieb: > Das Übergehen von Leuten mit den entsprechenden Kompetenzen hört sich > für mich jetzt aber sehr sehr nach "jeder macht, was er will" an, und > wenn Du bei dem "abgehobenen Treffen" anwesend gewesen wärst oder zum > Beispiel in einem Scrum Daily Standup davon erfahren hättest, daß jemand > anders an Deinem Fachgebiet arbeiten soll, dann hättest Du rechtzeitig > einschreiten können. Insofern ist Dein Beispiel in meinen Augen ein sehr > gutes Beispiel dafür, wie es ohne die Verwendung von agilen Methoden zu > Informationsverlusten kommen kann, die es mit einer agilen > Vorgehensweise nicht gegeben hätte. Ich habe ja davon erfahren. Ich fragte doch: "Wollen wir das nicht mal diskutieren?" Dann kann man Pros und Kontras eruieren, was ich übrigens für mich ja auch immer still mache, wenn ich für ein Probleme mehrere Lösungsansätze im Sinn habe. Der Projektleiter, der nicht diskutieren wollte, war sich seiner Sache zu bewusst und lag dann gründlich daneben. Das würde ich auch nicht als Fehler der Organisation ansehen, sondern als sein persönliches Defizit. Agile Methoden verhindert das nicht und begünstigen das auch nicht. Das ist vollkommen unabhängig. Es ist eigentlich immer schlau, die Fachleute, die im Saft stehen, zu fragen. Nicht so, wie es Politiker oder Manager tun, die sich Alibis verschaffen wollen (z. B. für Massenentlassungen), sondern es geht um richtige Befragung. Und man lässt es die Entwickler entwickeln, die hinterher auch Skin in the Game haben. Ich war der mit Skin in the Game, der wochenlang dieses Theater ausbaden musste. Der Entwickler bzw. der Entscheider waren weg. bzw. haben den Kopf eingezogen. Das ist mir schon öfter aufgefallen. Ich musste vor vier Jahren für Projekt eine Feature implementieren. Und es gibt dann immer ganz schlaue Projektleiter, die dann über den Flurfunk mitkriegen, sowas wurde doch schon mal in einem anderen Projekt umgesetzt. Also hat sich ein anderer Entwickler hingesetzt, der vom fremden Projekt, der kein Skin in the Game hatte. Es funktioniert nichts. Es wurde regelrecht gepfuscht. Es wäre besser gewesen, ich hätte mich der Sache von Anfang an angenommen. Es war in jedem Falle nur viel Konfiguration und ein bisschen Programmierung. Der Entwickler war dann auch noch so frech und behauptete, dass ich falsch liege und sein Zeug schon funktioniere. Ich bin regelrecht gewarnt, wenn ich höre: "Lass uns das doch mal von X übernehmen." Weil es bislang immer so war: Die Zeit, zu verstehen, was der andere gemacht hat, dann erkennt man, dass es Murks ist und das ganze Bug fixing verschlingt so viel Zeit. Und dann programmiert man es komplett neu und richtig. Oft erlebt und immer mit dem faden Beigeschmack: Man hätte so viel Zeit gespart, wenn man es direkt selbst gemacht hätte.
J. S. schrieb: > Das wäre die Frage ob er da wirklich gefehlt hat, denn das Übergehen ist > bei einem Mehrheitsentscheid des Teams oft die Regel. Daß die Fachleute übergangen werden, kann natürlich immer und überall geschehen. Aber wenn die Fachperson sich in der Gruppe geäußert hat und trotzdem übergangen worden ist, kann man sie hinterher nicht mehr dafür verantwortlich machen. Und alle in der Gruppe wissen das auch! > Das funktioniert natürlich nur, wenn die > Gruppe diese Kompetenz auch hat! Wenn die Gruppe vornehmlich aus Inkompetenten besteht, die das Fachwissen und die Erfahrung der Kompetenten weder anerkennen noch berücksichtigen, dann kann die ganze Angelegenheit ohnehin nicht funktionieren. Da helfen dann auch agile Methoden nichts. Die sind schließlich kein Allheilmittel, auch wenn die Feinde von agilen Methoden das gerne als Strohmann-Argument mißbrauchen. Dann nutzen allerdings auch die hierarchischen Ansätze genau gar nichts. Huch!
Ein T. schrieb: > Dann nutzen allerdings > auch die hierarchischen Ansätze genau gar nichts. Doch, wenn nämlich die Vorgaben von der fachkompetenten Person kommen. Das ist ja eben der Punkt: Wenn es nicht die Gruppe ist, die eine homogene Kompetenz hat, dann kann es eben auch die Gruppe nicht entscheiden, sondern es muss die einzelne Person tun.
J. S. schrieb: > Es wird noch dauern, bis sich Srum wirklich gesetzt hat und nur dort > eingesetzt wird, wo es funktionieren kann. Angesichts der Tatsache, daß eine ganze Branche davon lebt, das Wunderelixier Scrum zu vertreiben, wird es sicherlich noch lange brauchen, bis es Gesunden nicht mehr verschrieben wird.
Joe schrieb: > Angesichts der Tatsache, daß eine ganze Branche davon lebt, das > Wunderelixier Scrum zu vertreiben, Es ist immer wieder erbaulich, daß die agilen Methoden ausgerechnet von ihren Feinden als "Wunderelixir" und Allheilmittel gepriesen werden, damit sie dann bitter darüber weinen können, daß sie weder das Eine noch das Andere sind und sein können. Und selbstverständlich kann ein jedes Produkt, das nicht restlos alle Probleme dieser Welt augenblicklich lösen kann und von windigen Figuren angepriesen wird, natürlich nur unnützer, überflüssiger Mist sein. Der intellektuelle Tiefgang dieser sich bereits seit geraumer Zeit im Kreis drehenden "Diskussion" läßt erahnen, welche sachliche und fachliche Substanz hinter solchen "Argumentationen" steckt. Nicht zuletzt deswegen mag ich mich jetzt aus diesem ebenso langwierigen wie langweiligen Geplänkel zurückziehen und mich konstruktiveren, sinnvolleren und vergnüglichen Tätigkeiten widmen. Vielen Dank, habt einen schönen Tag.
J. S. schrieb: J. S. schrieb: > Gastino G. schrieb: >> Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die >> Sicherheit des Produkts erhöht wird. > > Das ist aber jetzt ein von Scrum losgelöstes Thema In der Tat: Scrum und agil ist das genau Gegenteil von SIL. Bei SIL (z.B . 61508) sind die Anforderungen von Anfang an klar und unverhandelbar. Die verwendeten Techniken und Verfahren müssen bekannt und erprobt sein. (Das viel zu viel Papier generiert wird, ist auch meine Erfahrung. "Form" ist halt deutlich einfacher zu erstellen und zu prüfen als "Inhalt" und so werden die meisten Dokument "write only")
Ein T. schrieb: > Der intellektuelle Tiefgang dieser sich bereits seit geraumer Zeit im > Kreis drehenden "Diskussion" läßt erahnen, welche sachliche und > fachliche Substanz hinter solchen "Argumentationen" steckt. Nicht > zuletzt deswegen mag ich mich jetzt aus diesem ebenso langwierigen wie > langweiligen Geplänkel zurückziehen und mich konstruktiveren, > sinnvolleren und vergnüglichen Tätigkeiten widmen. Vielen Dank, habt > einen schönen Tag. Ich wünsche Dir auch eine schöne Zeit. Aber ehrlich gesagt finde ich es keinen so großen Verlust, wenn Dein "Geplänkel" wegfällt. Habe Deine Beiträge nochmal von Anfang an überflogen und finde fast nur ad hominem-Repliken, Anekdotisches und Prahlen wie "ich als Unternehmer" und Überspitzungen. Rabulistik nannte man das mal (1). Ich habe nichts gefunden, was in einer Diskussion produktiv wäre, kein Konzedieren, daß der "Gegner" auch mal einen Punkt gemacht hat. Beispiel: > Es ist immer wieder erbaulich, daß die agilen Methoden ausgerechnet von > ihren Feinden als "Wunderelixir" und Allheilmittel gepriesen werden, > damit sie dann bitter darüber weinen können, daß sie weder das Eine noch > das Andere sind und sein können. Der Punkt ist doch, daß Scrum regelmäßig als Allheilmittel angepriesen wird. Wie Schlangenöl. Ein "Feind" von Scrum wird man für viele alleine dadurch, daß man sagt, daß es eben kein Allheilmittel ist, sondern in vielen Fällen auch wirkungslos oder gar ungesund ist. Das wirkt wie religiöser Eifer. > Und selbstverständlich kann ein jedes > Produkt, das nicht restlos alle Probleme dieser Welt augenblicklich > lösen kann und von windigen Figuren angepriesen wird, natürlich nur > unnützer, überflüssiger Mist sein. Das ist ein typisches Beispiel für beleidigtes Werfen eines Strohmann-Arguments. Es wurde ja konzediert, daß Scrum *in bestimmten Konstellation* nützlich und wertvoll sein kann. (1) https://www.frag-machiavelli.de/arthur-schopenhauer/ https://de.wikipedia.org/wiki/Eristische_Dialektik
Bruno V. schrieb: > Das viel zu viel Papier generiert wird, ist auch meine Erfahrung. > "Form" ist halt deutlich einfacher zu erstellen und zu prüfen als > "Inhalt" und so werden die meisten Dokument "write only") So ganz write only ist das ja nicht. Man muss zwei Dinge trennen: a) die politisch motivierten Vorgaben, die von außerhalb kommen und die man einfach beachten muss, ob man sie mag oder nicht. Die müssen eben rein, formuliert, beachtet und getestet werden. b) die Dinge, die technisch in ein Produkt fließen sollen, weil die GL das möchte oder es eine Kunde haben will. Auch da gibt es eben unveränderliche Dinge, an denen nicht gerüttelt werden soll und je genauer und präzisier diese formuliert sind, desto besser. Besser vor allem auch für den Leistungserbringer, weil ihm dann keine Mängel oder Fehler vorgehalten werden können. Ab da kommt dann eine Umsetzung und die Mitwirkung des Lieferanten und damit gfs. auch Scrum (u.a. wenn die liefernde Abteilung die Entwicklung ist und die Vorgaben des System engineerings umsetzen soll, darf). Hier ist Dynamik und Freiraum gegeben, der gefüllt werden muss. Ich sehe da nicht notwendigerweise ein Diskrepanz zwischen SIL und Scrum: Ein gesundes System Engineering ist in der Lage, die SIL-Vorgaben so umzusetzen und aufzubereiten, dass sie leistbar werden. Dazu braucht es eben nach den Lastenheften / formalen Spezifikationen eben belastbare Konzepte. Darauf kommt es an. Und die können und dürfen durchaus von Teams erarbeitet werden und damit auch mittels Scrum. Der Knackpunkt bei SIL und anderen ähnlich gelagerten Projekten ist eben, dass der Anteil der Vorgaben sehr hoch und der Freiraum eng definiert ist, wodurch sich auch eine stringente Umsetzung ergibt, während Scrum eigentlich dafür gedacht ist, die offenen, unklaren und veränderlichen Entscheidungen zu managen. Scrum eignet sich in SIL-Projekten daher hauptsächlich bei technischen Umsetzung einer SW oder firmware, nicht aber der HW und noch weniger der Systemdefinition. Würde man Scrum wirklich nur dort einsetzen, wo es passt und wofür es gedacht wäre, gäbe es weniger Diskrepanzen und Kritik daran.
War früher einfacher. "Kommste mit eine Rauchen?" Selbst ohne Idealformat ist es schwierig, die Leute auf einen kleinsten gemeinsamen Nenner zu bekommen - oder auf den dann selber auch noch einzusteigen. Ideal ist sowieso oft problematisch und lebensfremd Statistisch Normal kann auch OK sein. Kommt sowieso häufiger vor als man denkt. Funktional dagegen spielt ein wenig in einer anderen Liga. Man vergleiche z.B. einen VW Käfer mit einem aktuellen Formel 1 Wagen. Stört doch gar nicht, wenn die letzteren gut performen.
Bruno V. schrieb: > J. S. schrieb: > > J. S. schrieb: >> Gastino G. schrieb: >>> Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die >>> Sicherheit des Produkts erhöht wird. >> >> Das ist aber jetzt ein von Scrum losgelöstes Thema > > In der Tat: Scrum und agil ist das genau Gegenteil von SIL. Bei SIL (z.B > . 61508) sind die Anforderungen von Anfang an klar und unverhandelbar. > Die verwendeten Techniken und Verfahren müssen bekannt und erprobt sein. Nö, wir haben zertifizierte Software gemäß EN50128 agil gebaut und geliefert.
Uwe D. schrieb: > Nö, wir haben zertifizierte Software gemäß EN50128 agil gebaut und > geliefert. Natürlich kannst Du die "agil" bauen. "Top down" und "V-Modell" hat allerdings wenig zu tun mit dem, was die meisten unter agil verstehen.
Bruno V. schrieb: > Natürlich kannst Du die "agil" bauen. "Top down" und "V-Modell" hat > allerdings wenig zu tun mit dem, was die meisten unter agil verstehen. Und das wiederum hat nichts mit dem zu tun, was Scum unter "agil" versteht.
Bruno V. schrieb: > > Natürlich kannst Du die "agil" bauen. "Top down" und "V-Modell" hat > allerdings wenig zu tun mit dem, was die meisten unter agil verstehen. Beides hat auch seine Berechtigung und schließt agil nicht aus. Bei einem abgeschlossenen Modul, das über drei Wochen entwickelt wird, hilft so ein "Mini-V" für sich ganz persönlich. Und es ist gut, dass man die Aufgabenstellung intellektuell durchdringt bevor man in die Tasten haut. Scrum ist die große Illusion, dass man darauf verzichten kann, dass alle Entwickler gleich gut sind, dass jeder alles programmieren. Die Scrum-Seuche zieht gerade durch mein Unternehmen. Nun hört man weiteren Standorten, die es satt haben. Es wird zu viel gequatscht und fehlt die Zeit für die eigentliche Aufgabe. Ein Team treibt es so exzessiv, dass die Besprechungen von 15 Mann einberufen, in denen nur zwei Leute qualifiziert etwas zum Thema beitragen können. Mal sehen, wie lange der Unsinn noch anhält. Ein T. schrieb: > Es ist immer wieder erbaulich, daß die agilen Methoden ausgerechnet von > ihren Feinden als "Wunderelixir" und Allheilmittel gepriesen werden, > damit sie dann bitter darüber weinen können, daß sie weder das Eine noch > das Andere sind und sein können. Und selbstverständlich kann ein jedes > Produkt, das nicht restlos alle Probleme dieser Welt augenblicklich > lösen kann und von windigen Figuren angepriesen wird, natürlich nur > unnützer, überflüssiger Mist sein. Nein, es wird nicht von den Kritikern als Wunderelixier angepriesen. Vielleicht wird der Gegenseitige unterstellt, dass sie es als Wunderelixier anpreisen, aber das hat angesichts der allgegenwärtigen Propaganda für Scrum ja auch eine Berechtigung. Diesen Eindruck kann man haben. Auf die Kritikpunkte wird ja von der Befürworterseite gar nicht eingegangen. Es heißt dann nur: "Ihr macht's falsch." > > Der intellektuelle Tiefgang dieser sich bereits seit geraumer Zeit im > Kreis drehenden "Diskussion" läßt erahnen, welche sachliche und > fachliche Substanz hinter solchen "Argumentationen" steckt. In meinem Falle stecken 16 Jahre Berufserfahrung dahinter. Ich kenne es ohne Scrum, ich kenne es mit Scrum. Und Scrum ist eindeutig nervtötender und setzt falsche Anreize. Das wichtigste ist immer noch der gesunde Menschenverstand. Und man sollte nie vergessen, dass Softwareentwicklung eine intellektuelle Tätigkeit ist. Und diese Sprinterei für schnelle Ergebnisse ist schädlich, wenn man das Programmierte Wochen später wieder wegschmeißen darf. Man darf und sollte planen, damit man sich mittel- und langfristig Programmierarbeit spart. Wenn ich von mich ausgehe: Ich kann gut wiederkehrende Muster erkennen und wenn ich etwas für A entwickle, merke ich: "Mensch, das kann ich für B, C und D so ähnlich auch anwenden." Dann programmiere ich das so, dass ich es auch weiternutzen kann. Da kommen dann Schablonenmethoden und Strategieklassen zum Einsatz. Manchmal brauche ich aber nicht mal das, weil ich das Problem allgemeiner formuliere, dafür die Lösung schreibe. Ich bin da recht gut. Ich merke auch, wie meine Kollegen sich 'nen Krampf programmieren, weil sie nicht in der Lage sind, den gerichteten Graphen für die Topologie-Beschreibung in unserer Anwendung zu nutzen. Wo ich 'ne halbe Stunde und fünf Zeilen Code brauche, sitzen die mitunter Tage und schreiben halbe Romane. (Ich scherze nicht, es ist mitunter wirklich so.) Im agilen Manifest steht als erstes: "Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge". Und genau das vermisse ich in der Scrum-Praxis. Ich glaube, das oben schon geschrieben zu haben: Das wichtigste ist, dass die Entwickler hinzulernen. Und dann sollte man doch das Sprintziel mal beiseite lassen und zwei Tage vermeintlich unproduktives tun, mal was ausprobieren, mal was lesen, mal etwas verstehen, vielleicht eine generischere Lösung von mir. In dem Bereich unserer Projekte, in dem arbeite, bin ich hoch produktiv. Mir wurde schon mehrfach attestiert, dass ich die Arbeit mache, wo in anderen Projekten fünf Leute dran sitzen. Und das kommt ja daher, weil ich mir die Frechheit rausnehme, mich als Individium wichtiger zu nehmen als den Prozess, als das Werkzeug. Ich durchdenke eine Problemstellung, bringe etwas zu Papier. Ich defäkiere dann aufs Sprintziel, aber ich sehe am Horizont ja die Abnahmetermine, die durch mein Vorgehen nicht gefährdet, sondern gesichert werden. Ich kann meine Vorteile auch außerhalb meiner Domäne ausspielen. Ein Kollege sollte im aktuellen Projekt etwas programmieren, aber er brauchte Wochen. Die Aufgabenstellung war einfach und es gab eine Spec vom Kunden: eine Schnittstellenbeschreibung. Er geht das durch und kodiert das runter. Ich hingegen würde mir überlegen, wie ich das Convenientmethoden verpacken kann, die mir die einzelnen Nachrichtenbausteine simpel beschreiben. Dann mache ich das für ein, zwei Nachrichtentypen händisch, merze noch ein paar Fehler aus, aber beim Rest würde ich die Tabellen aus der Spec in den Emacs kopieren und mir das alles per Tastaturmakros zurechtrücken. Leider war es da schon zu spät. Aber ich habe Tastaturmakros angewandt, um zu refaktorieren. Der Kollege hat gestaunt, wie fix ich bin. Da ich bei uns die Azubis betreue, sehe ich, wenn die von ihrer Arbeit abschweifen und etwas vermeintlich unproduktives tun. Ich finde es gut. Der eine Azubi hat den Spacemacs ausprobiert, ist nun zu Doom Emacs gewechselt. Es gefällt mir, dass er sich da reinfuchst. Lieber heute ein bisschen Zeit dafür aufbringen und dann später enorm viel Zeit sparen. Tastaturmakros zeige ich den Azubis gerne, in der Hoffnung, sie zu inspirieren. Und natürlich gibt es dieses Feature auch in anderen Editoren. Wenn jemand den Vim genauso bedienen kann wie ich den Emacs, ist daran doch nichts auszusetzen. In einem Scrum-Prozess wäre dafür keine Zeit.
Rudi R. schrieb: > In dem Bereich unserer Projekte, in dem arbeite, bin ich hoch produktiv. > Mir wurde schon mehrfach attestiert, dass ich die Arbeit mache, wo in > anderen Projekten fünf Leute dran sitzen. Und das kommt ja daher, weil > ich mir die Frechheit rausnehme, mich als Individium wichtiger zu nehmen > als den Prozess, als das Werkzeug. Ich durchdenke eine Problemstellung, > bringe etwas zu Papier. Ich defäkiere dann aufs Sprintziel, aber ich > sehe am Horizont ja die Abnahmetermine, die durch mein Vorgehen nicht > gefährdet, sondern gesichert werden. Ich glaube Dir das sofort und gebe Dir bei dem Ganzen auch Recht, aber... es ist der totale Luxus, ein Management zu haben, welches solchen Einzelkämpfern wie Dir vertraut und diese machen lässt. Normalerweise mißtraut man den Techies, denkt, das sie irgendetwas vor sich abstrahieren und overengineeren, was keinen praktischen Nutzen hat, aber den Spieltrieb des Nerds befriedigt - wenn man sie lässt. Die Lösung von Scrum ist dann ja, daß der Product Owner mit der Businessbrille entscheidet, an was gearbeitet wird. Man will die teure Ressource "Entwickler" an die Kandare nehmen und kontrollieren, mit was sich die Techies beschäftigen. Daß wie beschrieben die Unterschiede bei den Skills riesig sind, stört nur die Abstraktion der Manager, daß Programmieren ein Standardtätigkeit ist, die mess-, skalier- und planbar ist. Agil bleibt damit in den meisten Fällen ein Käfig für die Entwickler, eine totale Verplanung der Zeit der Techies. Und es wird das Losbasteln bevorzugt, weil es gleich sichtbare Ergebnisse bringt. Der Ausdruck "Ticketgetriebe Architektur" bringt es schon auf den Punkt.
Rudi R. schrieb: > Scrum ist die große Illusion, dass man darauf verzichten kann, dass alle > Entwickler gleich gut sind, dass jeder alles programmieren. Ich denke nicht, das diese Illusion an Scrum hängt oder erst mit Scrum entstanden ist. > Und das kommt ja daher, weil > ich mir die Frechheit rausnehme, mich als Individium wichtiger zu nehmen > als den Prozess, Du widersetzt dich den Firmenanweisungen? :D
Rudi R. schrieb: > Nun meckern bei uns in der Firma die nächsten über Scrum. Berichtet wird > immer das gleiche: 50 % der Arbeitszeit geht für Gebabbel drauf. Ich mag Dir nicht zu Nahe treten, aber wenn 50% Eurer Arbeitszeit für "Gebabbel draufgehen", dann arbeitet Ihr entweder an extrem komplexen Aufgaben, oder irgend etwas in Eurer Kommunikation ist kaputt. Die Defekte in Eurer Kommunikation können an Scrum liegen, müssen sie aber nicht. > Wenn es > jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich > entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war > kein richtiger Sozialismus." Das ist eine schöne Anekdote, aber kein Argument. > Auch bei uns in der Firma gibt es "Prozesse". So arbeitet die > EDV-Service-Abteilung nur mit Ticket. Das Ticket-Tool ist unter aller > Sau. Mir sind schon viele Ticket-Werkzeuge begegnet, aber kein gutes. > Nun ist mir aufgefallen, > dass dort Externe arbeiten. Ich weiß nicht, wer diese Leute dort stellt. > Die brauchen die Tickets offenbar für die Rechnungslegung. Das ist ein Mißbrauch des Ticketsystems. Tickets dienen der Kommunikation und nicht dem Controlling.
Mike J. schrieb: > Der Kommunismus funktioniert aber eben nur genau dann, wenn man > Ressourcen im Überfluss hat. Das ist nicht richtig, der Kommunismus funktioniert, allerdings nicht auf einer (zwangsweise durchgesetzten) staatlichen Ebene. Auf einer zivilrechtlichen Ebene funktioniert der Kommunismus in israelischen Kibbuzen recht gut. Aber: die Kibbuzim sind ein freiwilliger Teil des Kibbuz, sie werden nicht gezwungen und können gehen, wenn und wann sie wollen.
Carsten P. schrieb: > Wenn Individuen sich nichtmal an Scrum > gewöhnen können, ist das Projekt schon zum Scheitern verurteilt. Das könnte die klügste Aussage im ganzen Thread sein. Danke.
Sheeva P. schrieb: > as könnte die klügste Aussage im ganzen Thread sein. Danke. Nicht zwangsläufig! Es ist absolut legitim, Prozesse infrage zustellen, wenn sie für eine Situation einfach nicht passen oder falsch angewendet werden und nach Aktenlage wird keine andere Methode der Projektorganisation so oft falsch appliziert, wie das scrum System. Und es wird falsch interpretiert! Hier geht es schon los: Rudi R. schrieb: > scrum ist die große Illusion, dass man darauf verzichten kann, dass alle > Entwickler gleich gut sind, dass jeder alles programmieren. Das ist eigentlich oft anders herum: Scrum setzt voraus, daß alle gleich kompetent sind, weil sie sonst kein Team bilden können, welches sich die anstehenden Teilaufgaben aufteilt, da sich die Aufgaben nämlich von selber verteilen. Jeder macht das was er kann und andere können ihm da weder helfen noch reinreden. Somit liegt eine klassische Separation vor und Scrum ist wirkungslos. Und noch ein Beispiel: Rudi R. schrieb: > Nun hört man > weiteren Standorten, die es satt haben. Es wird zu viel gequatscht und > fehlt die Zeit für die eigentliche Aufgabe. Hier wird Scrum an einer Stelle eingesetzt, wo ohnehin schon Zeitknappheit herrscht und somit der Versuch, ein qualitativ besseres Ergebnis durch Einsatz von Organisation nach hinten losgeht, weil jede Minute dieser versuchten Organisation die Zeit für das Eigentliche wegnimmt. Wenn man Scrum einführt, muss auch die Zeit dafür reserviert werden. Und auch das ist völlig falsch: > Ein Team treibt es so exzessiv, dass die Besprechungen von 15 > Mann einberufen, in denen nur zwei Leute qualifiziert etwas > zum Thema beitragen können. In Besprechungen können ohnehin nicht mehr als 5 Personen effektiv kommunizieren und größer darf ein Scrum Team gar nicht sein. Wenn die Qualifikation zu weit auseinander ist, kann zur Lösung der Aufgaben kein Scrum Team herhalten, sondern es müsste hierarchiert werden. Wahrscheinlich ist es aber so, dass die Personen in dieser 15er Gruppe alle etwas anderes bearbeiten und nichts miteinander zu tun haben. Das ist ein typisches Beispiel für das formelle Festhalten an Scrum und dem gleichzeitg stattfindenen Verstoßen dagegen. So wird tatsächlich massig Zeit verschwendet, die dann logischerweise fehlt. Scrum darf kein Selbstläufer werden, sondern der Zeitaufwand muss in einem gesunden Verhältnis zum Tun stehen. Wer mehr als 20% seiner Zeit für Orga und Abstimmung (egal nach welcher Methode) verwendet, muss da mal schauen, ob er das verbessern kann. Da läuft nämlich was gewaltig schief. Es muss vor allem aus den Köpfen heraus, alles und überall nach der gleichen Methode abwickeln zu wollen. Das kann nicht gutgehen!
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.