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.
:
Bearbeitet durch User
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.
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.