Forum: Ausbildung, Studium & Beruf Meeting-Hölle/Scrum


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


Lesenswert?

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

von Gerhard O. (gerhard_)


Lesenswert?

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

von Mark B. (markbrandis)


Lesenswert?

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


Lesenswert?

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.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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.

von Bruno V. (bruno_v)


Lesenswert?

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


Lesenswert?

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.

von Katrin I. (Gast)


Lesenswert?

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.

von Re D. (re_d228)


Lesenswert?

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

von Uwe D. (monkye)


Lesenswert?

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

von Michael B. (laberkopp)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Katrin I. (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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!

von Ein T. (ein_typ)


Lesenswert?

Michael B. schrieb:
> Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen.

Es fällt mir außerordentlich schwer, das zu glauben.

von Michael B. (laberkopp)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Katrin I. (Gast)


Lesenswert?

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.

von Katrin I. (Gast)


Lesenswert?

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.

von A. B. (funky)


Lesenswert?

Und was hat das jetzt alles mit Scrum zu tun? Das sind doch Probleme die 
es früher genau so schon gab

von Mark B. (markbrandis)


Lesenswert?

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?

von Joe (jowu)


Lesenswert?

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.

von Katrin I. (Gast)


Lesenswert?

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.

von Katrin I. (Gast)


Lesenswert?

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.

von Joe (jowu)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.