O Scrum transforma desenvolvedores ativos em desenvolvedores passivos?

102

Sou um desenvolvedor web trabalhando em uma equipe de três desenvolvedores e um designer. Agora, há cerca de cinco meses, implementamos a metodologia de desenvolvimento ágil de software scrum. Mas eu tenho uma sensação estranha que eu só queria compartilhar neste site.

Um fator importante na vida humana é o processo de tomada de decisão. No entanto, há uma grande diferença nas decisões que você toma. Algumas decisões são apenas o resultado de uma força interna ou externa, enquanto outras decisões são completamente baseadas no seu livre arbítrio, e algumas decisões são simplesmente algo entre elas. Quanto mais liberdade você tiver na tomada de decisões, mais auto-dirigido seu trabalho se tornaria. Isso parece ser uma regra. Porque tendemos a moldar nossas vidas nós mesmos.

Existe uma grande diferença entre você decidir o que fazer ou saber o que fazer .

Antes do scrum, eu senti vontade de ter mais liberdade para tomar as decisões relacionadas ao desenvolvimento, análise, priorização da implementação, etc. Eu tinha mais a sensação de que estou decidindo o que estou fazendo .

No entanto, devido à metodologia scrum, agora muitas decisões vêm simplesmente do proprietário do produto. Ele prioriza o PBIs , ele analisa como o software deve funcionar, até às vezes como a interface do usuário e a funcionalidade devem seja implementado. Eu sei que isso faz parte da metodologia scrum, e também sei que isso pode resultar em melhores vendas de produtos no futuro. No entanto, agora sinto que sempre me dizem para fazer algo, em vez de decidir fazer algo . Essa síndrome agora me tornou mais passiva em relação ao trabalho.

  1. Eu costumo pesquisar menos para encontrar uma solução, uma abordagem ou uma técnica melhor
  2. Eu não acordo de manhã esperando conseguir um trabalho agradável. Em vez disso, sinto-me forçado a trabalhar para viver
  3. Eu tenho mais fome para trabalhar em meus próprios projetos de hobby depois do trabalho
  4. Eu não vou mais empurrar a equipe para chegar aos níveis tecnológicos mais altos
  5. Eu passo mais tempo agora no jantar, ou no horário do chá e tenho menos entusiasmo para voltar ao trabalho
  6. Agora estou mais disposto para que o trabalho termine mais cedo, para que eu possa voltar para casa

O grande problema é que eu vejo e diagnostico esse comportamento em meus colegas também. É o resultado do scrum? O scrum realmente faz a equipe de desenvolvimento sentir que não faz parte da formação do software geral, tornando-o passivo ao projeto? Como posso superar esse sentimento?

    
por Saeed Neamati 25.03.2012 / 12:25
fonte

17 respostas

51

However, I now feel like I'm always getting told to do something, instead of deciding to do something.

Este é um indicador sério de que algo saiu dos trilhos. Um projeto ágil não deve se sentir assim. Essa retórica de "pessoas acima do processo" deveria incluir "não forçamos nosso pessoal a fazer coisas que sugam". Aqui estão algumas ideias:

Você está fazendo "scrum mas"? Isto é, parte scrum, parte alguma outra coisa. (ou seja: "Estamos fazendo scrum, mas todas as nossas histórias têm que vir do nosso PMO, não do dono de um produto".) Muita porcaria maluca é chamada Scrum nos dias de hoje.

Você, pessoalmente, não está envolvido no processo em que deveria estar? Eu conheço um número de pessoas que estão chateadas com o conteúdo das histórias, e acontece que elas só se envolvem quando a história está no backlog do sprint. Converse com o dono do produto desde o início do desenvolvimento da história e receba seu feedback. (Como a OC, eles têm a palavra final, mas isso não significa que eles tenham que fazê-lo sozinhos.)

No Scrum, a equipe deve possuir o processo, e espera-se que o processo mude com o tempo para atender às necessidades da equipe. Traga suas preocupações na retrospectiva. Se você puder sugerir um ajuste de processo, isso tende a facilitar a venda para algumas equipes.

    
por 26.07.2015 / 18:42
fonte
60

Seu problema não é Scrum (e como Jarrod Roberson mencionou nos comentários, não é Scrum o que você está descrevendo) - o microgerenciamento do seu Product e sua (e equipe) falta de assertividade .

"No entanto, devido à metodologia scrum, agora muitas decisões vêm simplesmente do proprietário do produto. Ele prioriza os PBIs, analisa como o software deve funcionar, às vezes até como a interface do usuário e a funcionalidade devem ser implementadas. Eu sei que isso é parte da metodologia scrum. "

Você está enganado. Apenas a partir de uma breve olhada na página da Wikipédia para o Scrum pode-se ver que: "a Equipe, um grupo interfuncional que faz a análise, projeto, implementação, teste, etc ". O Product Owner diz a você o que fazer, mas cabe à equipe decidir como fazer isso.

Você é a pessoa responsável pela implementação, portanto, você deve decidir como o aplicativo será implementado. Ouça a opinião do Product Owner, mas a decisão final depende de você (ou da equipe).

O microgerenciamento BTW faz transformar desenvolvedores ativos em desenvolvedores passivos.

    
por 16.08.2011 / 16:24
fonte
28

O que você está descrevendo é NOT SCRUM

O dono do seu produto está superando seus limites se ele está lhe dizendo como fazer o seu trabalho tecnicamente, não é sobre o que é SCRUM.

O SCRUM é sobre liberar os desenvolvedores para se concentrarem em questões de desenvolvimento e capacitar eles se encarregam de determinar quanto tempo as coisas levam e como fazê-las.

SCRUM é sobre colaboração, é para isso que as reuniões de planejamento da Sprint são realizadas, para promover a colaboração entre todas as partes interessadas; proprietário do produto, desenvolvedores e testes.

Sim, o proprietário do produto deve priorizar os recursos, o que precisa ser entregue primeiro de acordo com as necessidades do cliente, mas os desenvolvedores devem fazer engenharia e design, e não o proprietário do produto.

Eu não concordo que os desenvolvedores devam projetar interfaces gráficas e fluxos de trabalho, a menos que sejam especificamente encarregados e treinados para trabalhar com os clientes e eliminar a funcionalidade diretamente com os clientes. As GUIs construídas pelo programador, feitas a vácuo, raramente atendem às necessidades dos clientes.

O SCRUM trata de colocar um processo leve que pode ser previsível e repetível ao longo do manifesto ágil.

Fico triste ao ouvir histórias de que coisas muito boas estão sendo pervertidas assim.

    
por 18.08.2011 / 21:11
fonte
11

Eu acho que antes do Scrum, todo mundo fez o que queria: yippee ki-yay mf'er . Seus usuários são seus benfeitores e eles dirigem a história e pagam as contas. O product owner garante que a história seja feita. De alguma forma, seu grupo chegou à conclusão de que o Dono do Produto deveria estar lhe dizendo como programar.

Você quer escrever código ou criar aplicativos pequenos que você acha que são legais? "Eu quero fazer um primeiro recurso e não B, para que eu possa manter a minha liberdade de escolha." Encontre um benfeitor diferente e não uma nova metodologia de desenvolvimento.

Você está preso no título do proprietário do projeto ou algo assim. Se você tem uma razão válida para discordar da história, diga alguma coisa, faça sua argumentação. Você nem sempre pode ganhar. O trabalho deles é retornar aos usuários e informar que há um problema válido com a solicitação deles. Sejamos honestos, se a história pedir que você solte um banco de dados aleatoriamente ao longo do dia, sem backup, sem perda de dados ou tempo ocioso, você tem um problema e um dever de esclarecer a história.

    
por 16.08.2011 / 15:15
fonte
10

Parece que suas aventuras no Ágil foram corrompidas pelo Scrum. Acho que, de todas as metodologias ágeis, o Scrum é o menos ágil. É mais como cascatas em miniatura e gerenciamento de projetos adicionais. Isso, é claro, faz com que seja mais apreciado pela gerência, que acha que está retomando o controle desses desenvolvedores irritantes, mas é claro que você vê a realidade da situação.

Agile não é sobre seguir um caminho prescrito, ele é projetado para torná-lo mais produtivo e motivado. As pessoas não processam diz o manifesto (parafraseado), e isso está perdido no sistema que você está usando.

Então mude isso. Chame a atenção da gerência e diga que é um passo retrógrado, que sua produtividade é menor do que costumava ser e todos estão insatisfeitos com a maneira como ela está funcionando. Mostre o Manifesto Ágil (e seu gêmeo maligno ) e demonstre que você não apenas aprendeu lições desta experiência, mas quer evoluir as partes boas dela para um sistema melhor (uma que é como você costumava ter, que parece funcionar bem para você).

    
por 16.08.2011 / 12:26
fonte
8

Eu acho que simplesmente vocês estão acostumados a ter mais propriedade - e todos que eu acho que preferem isso, sua natureza humana.

Infelizmente, muitos softwares são menos do que poderiam, porque muitas vezes as partes são escritas para o desenvolvedor e não para o cliente. Sua nova abordagem deve reduzir isso, mas às custas do sentimento de propriedade.

Não faço ideia de como sugerir que você melhore ou divirta as coisas, mas é uma ótima pergunta e uma boa ideia.

    
por 16.08.2011 / 12:14
fonte
5

Você está recebendo histórias de usuários na forma de "Como um --role--, eu quero --goal / desejo-- para que --benefit--"? Parece que o Product Owner deseja fazer o trabalho de design, e ele / ela pode não ser a melhor pessoa para fazer isso. Usar o padrão de história do usuário pode ajudar a garantir que o Product Owner esteja aderido aos interesses de negócios, e o desenvolvimento de software está sendo feito pelos desenvolvedores de software.

    
por 16.08.2011 / 18:22
fonte
4

No Scrum há muito espaço para os desenvolvedores contribuírem e darem seus conselhos sobre novos recursos, interface do usuário, usabilidade ... Colaboração e conversação entre pessoas de negócios e desenvolvedores é necessária no Scrum e isso permite isso. No entanto no final, o dono do produto sempre terá a palavra final porque ele é o responsável por maximizar o valor comercial dos incrementos de software produzidos após o sprint (em outras palavras, o ROI).

Do Manifesto Ágil:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

O proprietário do produto informando como a interface do usuário e a funcionalidade devem ser implementadas não é aceitável. Nesse caso, você deve ter a palavra final, já que você é responsável pela qualidade interna do software que você produz.

Talvez você trabalhe em uma empresa criada por desenvolvedores onde os programadores tivessem liberdade para implementar os recursos desejados. No entanto, a maioria das metodologias Ágeis faz uma separação clara entre as pessoas do domínio de negócios e a equipe responsável pela produção de software (desenvolvedores, testadores ...), que é a divisão de trabalho mais comum na maioria dos lugares. Se minhas suposições estiverem corretas, eu posso entender o sentimento que você tem de que você não é capaz de "ter uma influência no quadro geral", mas com a empresa crescendo, acho que teria sido o caso de qualquer maneira, Scrum ou não. / p>

Com relação à análise, design e outras atividades de meta-desenvolvimento que você menciona (que não devem ser feitas novamente pelo Product Owner), as equipes Agile devem ser multifuncionais e livres de silo. Ninguém deve possuir todo o conhecimento em torno de uma atividade de desenvolvimento específica, então talvez haja uma oportunidade para você diversificar o local apenas contra o "monkeying de código".

    
por 16.08.2011 / 16:58
fonte
3

Pelo contrário, descobri que ter um proprietário de produto tomando decisões sobre a funcionalidade me permite dedicar mais tempo à produção de código de qualidade. Além disso, se houver preocupações válidas, sempre posso questionar as decisões dos proprietários do produto, o que geralmente leva a discussões proveitosas.

    
por 16.08.2011 / 15:37
fonte
3

Nós praticamos o Scrum aqui. Temos uma reunião de planejamento quinzenal onde nos alimentamos das prioridades de negócios atuais, e sucessos e fracassos do sprint anterior, e decidimos, como uma equipe , o que queremos resolver para o próximo sprint.

Uma das maneiras de fazer isso é classificar o backlog em uma placa por complexidade verticalmente e prioridade de negócios horizontalmente. Depois disso, o Dono do Produto teve sua contribuição, então cabe à equipe escolher o que queremos fazer. Obviamente, escolher uma tarefa de baixa prioridade de alta complexidade é desaprovado, mas estamos decidindo isso como uma equipe. Isso faz com que as sessões de planejamento sejam mais longas, mas vale a pena, e uma parte essencial do processo ágil.

E nós temos microgerencias às vezes, mas isso é um problema diferente.

    
por 16.08.2011 / 16:39
fonte
3

O problema real que você está descrevendo é uma patologia comum quando as equipes adotam uma Metodologia: elas desligam seus cérebros. Isso é tão verdadeiro com um sistema ágil da nova escola quanto com os sistemas pesados da velha escola.

Q: A Metodologia prescreve x, mas x não está funcionando bem. O que deveríamos fazer?

A: Refine sua implementação de x. Talvez pare de fazer isso completamente. A Metodologia não é o seu chefe!

Neste caso específico, parece que o product owner pode estar fazendo muito. Você está confortável falando com ele sobre isso? Você ficaria confortável em ter essa conversa se não estivesse "fazendo scrum?" Se o proprietário do produto não é sensível ao feedback construtivo, não é um problema de metodologia, é um problema com o proprietário do produto.

    
por 16.08.2011 / 17:49
fonte
2

Eu não estou realmente em sintonia com a coisa toda scrum como tem sido mais cachoeira por um tempo.

Mas, para ser honesto, isso soa mais como uma questão de pessoal de gerenciamento do que um problema de técnica de gerenciamento de projetos. Como é mais baseado em pessoas do que em técnica.

    
por 16.08.2011 / 11:59
fonte
2

O papel dos líderes em uma equipe auto-organizada seria uma postagem no blog sobre algo que parece estar faltando no seu post. Onde a equipe está decidindo qual trabalho é realizado em um sprint? Onde a equipe é proprietária do processo e do trabalho? Você tem alguém que conhece o Scrum o suficiente para fazer Scrum e não uma versão pervertida dele?

    
por 16.08.2011 / 16:43
fonte
2

Eu tive a mesma experiência com o Scrum e gosto de chamar isso de "tirania da história".

Da minha experiência, os desenvolvedores mais do lado criativo / design / frontend parecem sofrer mais com isso do que as pessoas envolvidas no trabalho de back-end.

A única saída que encontrei até agora foi afastar o Scrum - muitas vezes não é possível e / ou apropriado porque afinal tem suas vantagens - ou introduzir algo como o tempo de 20% do Google para dar aos desenvolvedores uma saída criativa além do "você está livre para escolher como implementar a Página de login ", porque na realidade você não é a sua implementação é restrito pelo código existente e pela arquitetura do sistema - isto é, a menos que se considere a liberdade de escolher entre 'um loop for e while' uma liberdade.

    
por 16.08.2011 / 20:27
fonte
1

There is a big difference between you deciding what to do, or being told what to do.

Na minha experiência, há apenas um longo caminho de sendo dito o que fazer para decidir o que fazer.

Ao final deste processo, normalmente não somos instruídos porque eles gostam de poder e não porque eles não têm nada melhor para fazer. Muito pelo contrário, no final deste caminho - quando eles ganham confiança suficiente em nossa equipe - eles parecem aliviados e alegremente passam a nós tanto controle quanto podemos lidar (e se a confiança deles é realmente firme, eles ainda tentam passar mais do que isso)

Ah, e na minha experiência, isso basicamente não tem nada a ver com o Scrum / Agile. Aconteceu com scrum, iterativo, cachoeira, o que seja. Parece que a questão de confiança é agnóstica ao processo

    
por 16.08.2011 / 14:16
fonte
1

Em nossa equipe, o proprietário do produto nos diz o que faz e decidimos como o fazemos. É realmente importante ter essa separação ou você acabará na situação que descreveu.

    
por 22.03.2012 / 00:38
fonte
1

De acordo com minha experiência, o Scrum é para observar profundamente o que você faz. Está apenas sentado em seu ombro e observando o que você faz. Mesmo que tenha sua própria vantagem, eu odeio a metodologia scrum. Espera a contagem, não a qualidade. A qualidade está ficando comprometida com a metodologia scrum.

    
por 19.09.2013 / 18:06
fonte