¿Hay alguna encuesta sobre hasta qué punto les gusta a los desarrolladores u odian el scrum? [cerrado]

Antecedentes: durante una conferencia, un analista señaló en un tweet que los desarrolladores odian el scrum.

Yo y otra persona respondimos que este no era el caso, y comenzamos a discutir diferentes escenarios sobre por qué a los desarrolladores no les gustaría el scrum.

Uno de los escenarios donde los desarrolladores perezosos no pueden esconderse en un proyecto scrum. El equipo los desafía constantemente a contribuir.

Esta discusión resultó en una publicación de blog y video http://elsewhat.com/2010/05/20/lazy-developers-hate-agile-and%C2%A0scrum/

Recibí tres comentarios que traté de responder de manera neutral, pero los comentarios señalan que hay algunas personas que detestan el scrum (y siempre estoy 100% seguro de que no son desarrolladores flojos).

Pregunta

¿Ha habido alguna vez una encuesta entre desarrolladores sobre hasta qué punto les gusta u odian los scrum?

Scrum es muy exigente ...

.. especialmente cuando es pervertido por la gerencia.

Por lo tanto, no tengo dudas de que muchos desarrolladores odian Scrum.

Una forma de pervertir a Scrum que vi en una gran corporación fue dividir la velocidad entre los desarrolladores. Y, por supuesto, hazlo muy visible en el standup diario. ¿Adivina qué pasó a corto plazo?

He descubierto que Scrum generalmente no es adecuado en alguna organización, especialmente en empresas públicas y gobiernos.

Después de 5 años de práctica intensiva de Scrum, enseñanza y entrenamiento, tanto en grandes corporaciones como en compañías muy pequeñas, he llegado a la conclusión de que Scrum es solo otra técnica, al igual que Java, es otro lenguaje que C # y que lo que hace la diferencia es individuos que lo usan, no la técnica en sí.

Meta-comentario: Sería genial tener preguntas de encuesta sobre programadores.

Dado que Scrum varía mucho entre diferentes equipos y diferentes organizaciones, esta pregunta será muy difícil de responder. Scrum debería tratar de capacitar al equipo para que entregue software excelente y a los desarrolladores les debería gustar.

¿A dónde va mal? La respuesta está en mi declaración anterior. El equipo no está habilitado o no se entrega un excelente software.

Hay tantos modos de falla, aquí hay algunos:

• El dueño del producto no entiende al cliente o al negocio.
• El equipo no entiende al cliente o al negocio.
• Los problemas de organización se interponen en el camino del equipo para lograr sus objetivos.
• Scrum se convierte en una microgestión del día a día.

Esos a veces se conocen como scrum-buts .

Es más probable que le guste / tenga éxito a IMO Scrum si:

• El equipo tomó la decisión de adoptar Scrum porque consideró que era apropiado para el producto / proyecto.
• Hay comentarios fuertes / continuos del cliente a través del propietario del producto.
• Enviar después de cada sprint.
• El equipo tiene autonomía, es autoorganizado y tiene plena confianza / apoyo de la organización.
• Un gran porcentaje de los elementos en la cartera de pedidos provienen del equipo.

Otro comentario es que en Scrum los programadores "perezosos" solo son responsables ante el equipo, por lo que pueden preferir eso a ser responsables ante su jefe. En cualquier caso, no creo que esto sea un factor.

Un problema que veo con Scrum es el problema del huevo y la gallina. Si ya eres ágil, es posible que no necesites Scrum. Si eres inherentemente poco ágil, Scrum probablemente no lo cambiará, incluso puede empeorar las cosas porque traerá cualquier agilidad a la superficie y la hará tan visible que las fuerzas antia ágiles pueden aplastarla :-)

¿Puede una organización no ágil volverse ágil? No lo sé. Creo que Scrum quiere hacer eso, pero no estoy seguro de que pueda.

Según mi experiencia, los desarrolladores / arquitectos odian mucho el scrum. Podría deberse a las siguientes razones

1. Muchas organizaciones de productos en su mayoría consideran que la entrega comercial es el objetivo principal y vinculan cada historia de sprint a una necesidad comercial. Por lo tanto, secuestran / comprometen los motivos de la arquitectura, la plataforma, el diseño limpio y la calidad del código en varias ocasiones. A veces no consideran los gritos de los desarrolladores. Esto es lo que sienten los desarrolladores profesionales que no son flojos.

2. Agile / scrum da dominio, indulgencia a los propietarios de productos / gerentes de productos al no dar detalles completos sobre los requisitos y, a la vez, esperan que los desarrolladores imaginen / asuman la necesidad de continuar con el desarrollo. Esto lleva a una diferencia en la implementación, demasiados defectos, un gran dolor para los desarrolladores al quemar su aceite de medianoche en muchas ocasiones.

3. En muchas ocasiones, los propietarios de productos comprometen los requisitos técnicos con los objetivos comerciales, a menudo ignoran a los desarrolladores, las opiniones de los arquitectos sobre el producto, las formas y los objetivos a largo plazo de la arquitectura y nos terminan con soluciones a corto plazo para continuar, lo cual no es una opción correcta para ningún producto.

4. Eventualmente, terminará con un producto que tiene defectos, fallas de diseño, a veces retrocesos de construcción, clasificaciones de insatisfacción del usuario, problemas de rendimiento, una base de código horrible para que el desarrollador la toque aún más.

Realmente no considero scrum / agile como mejor metodología en muchas ocasiones.

Lo odio. Y la mayoría de los desarrolladores que conozco también lo odian.

Es bastante difícil hacer un trabajo cerebral y creativo como el desarrollo de software bajo un microscopio.