Gibt es Umfragen darüber, inwieweit Entwickler Scrum mögen oder hassen? [geschlossen]

Hintergrund: Während einer Konferenz wies ein Analyst in einem Tweet darauf hin, dass Entwickler Scrum hassen.

Ich selbst und eine andere Person antworteten, dass dies nicht der Fall sei, und diskutierten verschiedene Szenarien, warum Entwickler Scrum nicht mögen würden.

Eines der Szenarien, in denen sich diese faulen Entwickler nicht in einem Scrum-Projekt verstecken können. Sie werden vom Team ständig aufgefordert, einen Beitrag zu leisten.

Diese Diskussion führte zu einem Blogbeitrag und einem Video http://elsewhat.com/2010/05/20/lazy-developers-hate-agile-and%C2%A0scrum/

Ich habe drei Kommentare erhalten, die ich neutral zu beantworten versucht habe, aber diese Kommentare weisen darauf hin, dass es einige Leute gibt, die Scrum verabscheuen (und ich bin immer zu 100% sicher, dass sie keine faulen Entwickler sind).

Frage

Gab es jemals eine Umfrage unter Entwicklern darüber, inwieweit Entwickler Scrum mögen oder hassen?

Scrum ist sehr anspruchsvoll ...

.. vor allem, wenn es vom Management pervers ist.

Daher habe ich keinen Zweifel, dass viele Entwickler Scrum hassen.

Eine Möglichkeit, Scrum zu pervertieren, die ich in einem großen Unternehmen gesehen habe, bestand darin, die Geschwindigkeit der Entwickler zu teilen. Und natürlich beim täglichen Aufstehen sehr gut sichtbar machen. Ratet mal, was kurzfristig passiert ist?

Ich habe festgestellt, dass Scrum in einigen Organisationen normalerweise nicht geeignet ist, insbesondere in öffentlichen Unternehmen und Regierungen.

Nach 5 Jahren intensiven Scrum-Übens, Lehrens und Coachings sowohl in großen Unternehmen als auch in sehr kleinen Unternehmen bin ich zu dem Schluss gekommen, dass Scrum nur eine andere Technik ist, genau wie Java eine andere Sprache als C # ist und dass der Unterschied die ist Personen , die es verwenden, nicht die Technik selbst.

Meta-Kommentar: Es wäre cool, Umfragefragen zu Programmierern zu haben.

Da Scrum zwischen verschiedenen Teams und Organisationen sehr unterschiedlich ist, wird diese Frage sehr schwer zu beantworten sein. Bei Scrum sollte es darum gehen , das Team in die Lage zu versetzen, großartige Software bereitzustellen, und Entwickler sollten dies mögen.

Wo geht es schief? Die Antwort ist in meiner obigen Aussage. Das Team ist nicht befugt oder es wird keine großartige Software geliefert.

Es gibt so viele Fehlermodi, hier einige:

• Der Product Owner versteht den Kunden oder das Unternehmen nicht.
• Das Team versteht den Kunden oder das Geschäft nicht.
• Organisatorische Probleme stehen der Erreichung der Ziele durch das Team im Wege.
• Scrum wird zu einem täglichen Mikromanagement.

Diese werden manchmal als Scrum-Buts bezeichnet .

IMO Scrum wird eher gemocht / erfolgreich sein, wenn:

• Das Team hat sich für Scrum entschieden, weil es dies für das Produkt / Projekt für angemessen hielt.
• Es gibt ein starkes / kontinuierliches Feedback des Kunden durch den Product Owner.
• Versenden Sie nach jedem Sprint.
• Das Team hat Autonomie, ist selbstorganisierend und volles Vertrauen / Unterstützung von der Organisation.
• Ein großer Prozentsatz der Elemente im Backlog stammt vom Team.

Ein weiterer Kommentar ist, dass "faule" Programmierer in Scrum nur gegenüber dem Team rechenschaftspflichtig sind, so dass sie es möglicherweise vorziehen, gegenüber ihrem Chef rechenschaftspflichtig zu sein. Ich denke jedenfalls nicht, dass dies ein Faktor ist.

Ein Problem, das ich bei Scrum sehe, ist das Henne-Ei-Problem. Wenn Sie bereits agil sind, benötigen Sie Scrum möglicherweise nicht. Wenn Sie von Natur aus unagil sind, wird Scrum es wahrscheinlich nicht ändern, es kann sogar die Situation verschlimmern, da es jede Agilität an die Oberfläche bringt und es so sichtbar macht, dass die anti-agilen Kräfte es zerquetschen können :-)

Kann eine nicht agile Organisation einfach agil werden? Ich weiß es nicht. Ich denke, Scrum will das tun, aber ich bin mir nicht sicher, ob es das kann.

Nach meiner Erfahrung hassen Entwickler / Architekten Scrum sehr. Könnte aus folgenden Gründen sein

1. Viele Produktorganisationen betrachten meistens die Geschäftsabwicklung als primäres Ziel und verknüpfen jede Sprint-Story mit einem Geschäftsbedarf. Daher entführen / kompromittieren sie bei mehreren Gelegenheiten die Motive von Architektur, Plattform, klarem Design und Codequalität. Manchmal berücksichtigen sie keine Schreie von Entwicklern. Dies ist, was professionelle Entwickler fühlen, die nicht faul sind.

2. Agile / Scrum gibt Dominanz, Nachsicht Produktbesitzer / Produktmanager viel darüber, dass sie keine vollständigen Details zu Anforderungen und Inturn geben, von denen sie erwarten, dass Entwickler sich vorstellen / annehmen, dass sie mit der Entwicklung fortfahren müssen. Dies führt zu Unterschieden in der Implementierung, zu vielen Fehlern und enormen Schmerzen für Entwickler, da sie ihr Mitternachtsöl häufig verbrennen.

3. In vielen Fällen, in denen Produktbesitzer technische Anforderungen mit Geschäftszielen kompromittieren, ignorieren Entwickler, Meinungen von Architekten zu Produkten, Formulare und langfristige Ziele der Architektur häufig und sie geben uns kurzfristige Lösungen, die für kein Produkt die richtige Wahl sind

4. Schließlich erhalten Sie ein Produkt, das Fehler, Designfehler, manchmal Rollbacks, Unzufriedenheitsbewertungen des Benutzers, Leistungsprobleme und eine schreckliche Codebasis aufweist, die der Entwickler weiter berühren kann.

Ich halte Scrum / Agile in vielen Fällen wirklich nicht für eine bessere Methodik.

Ich hasse es. Und die meisten Entwickler, die ich kenne, hassen es auch.

Es ist ziemlich schwierig, zerebrale, kreative Arbeit wie Softwareentwicklung unter dem Mikroskop zu leisten.