Existem pesquisas sobre até que ponto os desenvolvedores gostam ou odeiam o scrum? [fechadas]

Antecedentes: Durante uma conferência, um analista apontou em um tweet que os desenvolvedores odeiam o scrum.

Eu e outra pessoa respondemos que esse não era o caso e começamos a discutir diferentes cenários sobre por que os desenvolvedores não gostam do scrum.

Um dos cenários em que esses desenvolvedores preguiçosos não conseguem se esconder em um projeto scrum. Eles são constantemente desafiados pela equipe a contribuir.

Esta discussão resultou em uma postagem no blog e vídeo http://elsewhat.com/2010/05/20/lazy-developers-hate-agile-and%C2%A0scrum/

Eu recebi três comentários que tentei responder de maneira neutra, mas eles comentam que existem pessoas que detestam o scrum (e eu sempre tenho 100% de certeza de que não são desenvolvedores preguiçosos).

Questão

Já houve uma pesquisa entre desenvolvedores sobre até que ponto os desenvolvedores gostam ou odeiam o scrum?

Scrum é muito exigente ...

.. especialmente quando é pervertido pela gerência.

Portanto, não tenho dúvida de que muitos desenvolvedores odeiam o Scrum.

Uma maneira de perverter o Scrum que vi em uma grande corporação era dividir a velocidade pelos desenvolvedores. E, claro, torná-lo muito visível no stand-up diário. Adivinha o que aconteceu a curto prazo?

Descobri que o Scrum geralmente não é adequado em algumas organizações, especialmente empresas públicas e governos.

Após 5 anos de prática intensiva, ensino e treinamento em Scrum, tanto em grandes empresas quanto em empresas muito pequenas, cheguei à conclusão de que o Scrum é apenas outra técnica, assim como Java é outra linguagem que não C # e que o que faz a diferença é o indivíduos que o utilizam, não a técnica em si.

Meta-comentário: Seria legal ter perguntas de pesquisa sobre Programadores.

Como o Scrum varia muito entre equipes diferentes e organizações diferentes, essa pergunta será muito difícil de responder. O Scrum deve capacitar a equipe a fornecer ótimos softwares e os desenvolvedores devem gostar disso.

Onde isso dá errado? A resposta está na minha declaração acima. A equipe não está habilitada ou um ótimo software não é entregue.

Existem tantos modos de falha, aqui estão alguns:

• O proprietário do produto não entende o cliente ou a empresa.
• A equipe não entende o cliente ou o negócio.
• Questões organizacionais impedem que a equipe cumpra seus objetivos.
• O Scrum se transforma em um microgerenciamento diário.

Às vezes são conhecidos como scrum-buts .

O IMO Scrum tem mais chances de ser apreciado / bem-sucedido se:

• A equipe tomou a decisão de adotar o Scrum porque achou que era apropriado para o produto / projeto.
• Há um feedback forte / contínuo do cliente através do proprietário do produto.
• Navio após cada corrida.
• A equipe tem autonomia, é auto-organizada e possui total confiança / apoio da organização.
• Uma grande porcentagem de itens na lista de pendências vem da equipe.

Outro comentário é que, no Scrum, os programadores "preguiçosos" são responsáveis ​​apenas pela equipe, portanto podem preferir que sejam responsáveis ​​perante o chefe. De qualquer forma, não acho que isso seja um fator.

Um problema que vejo no Scrum é o problema do frango e do ovo. Se você já é ágil, pode não precisar do Scrum. Se você é inerentemente não ágil, o Scrum provavelmente não o mudará, pode até piorar as coisas, pois trará qualquer agilidade à superfície e a tornará tão visível que as forças anti-ágeis podem esmagá-la :-)

Uma organização não-ágil pode se tornar ágil? Eu não sei. Acho que o Scrum quer fazer isso, mas não tenho certeza.

Para minha experiência, desenvolvedores / arquitetos odeiam muito o scrum. Pode ser por causa das razões abaixo

1. Muitas organizações de produtos consideram principalmente a entrega do negócio o objetivo principal e vinculam cada história do sprint a uma necessidade do negócio. Portanto, eles sequestram / comprometem os motivos da arquitetura, plataforma, design limpo e qualidade do código em várias ocasiões. Às vezes, eles não consideram os gritos dos desenvolvedores. Isso é o que os desenvolvedores profissionais sentem que não são preguiçosos.

2. O Agile / Scrum dá dominância e clareza aos proprietários / gerentes de produtos por não fornecerem detalhes completos sobre requisitos e inturnos que eles esperam que os desenvolvedores imaginem / assumam a necessidade de prosseguir com o desenvolvimento. Isso leva a diferenças na implementação, muitos defeitos, uma enorme dor para os desenvolvedores ao queimar o óleo da meia-noite muitas vezes.

3. Em muitas ocasiões, os proprietários de produtos comprometem os requisitos técnicos, pois os objetivos de negócios geralmente ignoram os desenvolvedores, as opiniões dos arquitetos sobre o produto, atform, os objetivos de longo prazo da arquitetura e nos terminam com soluções de curto prazo para prosseguir, o que não é a escolha certa para qualquer produto.

4. Eventualmente, você acabará com um produto que possui defeitos, falhas de design, às vezes cria reversões, classificações de insatisfação do usuário, problemas de desempenho, base de código horrível para que o desenvolvedor toque ainda mais.

Eu realmente não considero o scrum / ágil como melhor metodologia em muitas ocasiões.

Eu odeio isso. E a maioria dos desenvolvedores que conheço também odeia.

É muito difícil fazer um trabalho cerebral e criativo, como desenvolvimento de software sob um microscópio.