O Scrum transforma desenvolvedores ativos em desenvolvedores passivos?


103

Sou desenvolvedor web, trabalhando em uma equipe de três desenvolvedores e um designer. Já faz cinco meses que implementamos a metodologia de desenvolvimento de software ágil scrum. Mas tenho um sentimento estranho que 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 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 autodidata seu trabalho se tornaria. Isso parece ser uma regra. Porque nós tendemos a moldar nossas vidas nós mesmos.

Há uma grande diferença entre você decidir o que fazer ou ser informado sobre o que fazer .

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

No entanto, devido à metodologia scrum, agora muitas decisões simplesmente vêm do proprietário do produto. Ele prioriza os PBIs , analisa como o software deve funcionar, mesmo às vezes como a interface do usuário e a funcionalidade devem ser implementadas. 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 estou sempre sendo instruído a fazer algo, em vez de decidir fazer algo . Essa síndrome agora me tornou mais passivo em relação ao trabalho.

  1. Costumo pesquisar menos para encontrar uma solução, abordagem ou técnica melhor
  2. Não acordo de manhã esperando chegar a um trabalho agradável. Em vez disso, sinto-me forçado a trabalhar para viver
  3. Tenho mais fome de trabalhar em meus próprios projetos de hobby depois do trabalho
  4. Não vou pressionar mais a equipe para chegar aos níveis tecnológicos mais altos
  5. Agora passo mais tempo no jantar ou no chá e tenho menos entusiasmo em voltar ao trabalho
  6. Agora estou mais disposto a terminar o trabalho mais cedo, para que eu possa chegar em 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 tem parte na formação do software geral, tornando a passiva para o projeto? Como posso superar esse sentimento?


4
Você tem certeza de que não estava se comprometendo muito disfuncionalmente antes?
Donal Fellows

27
Bom post no blog.
Robert S.

20
O que você está descrevendo não é SCRUM

4
@Chade. O que discuti aqui não é uma queixa da minha situação de trabalho. Eu só me pergunto se esse clima é o resultado do scrum? E se outros desenvolvedores também estão enfrentando a mesma coisa ou não?
Saeed Neamati

5
@Saeed - Desculpe por ser franco, mas seu humor é o resultado de sua decisão sobre como lidar com seu ambiente de trabalho. Pode ser afetado por outras opiniões e atitudes também, mas você também pode optar por adotar esse método. Isso o isenta da necessidade de ser responsável pelas decisões de design e permite que você trabalhe na solução de problemas específicos. Ele não consome toda a sua energia e permite que você trabalhe em mais projetos de sua casa. Você tem mais tempo para desenvolvê-lo. Estas não são coisas ruins. Não é tarefa do seu empregador fazer você feliz. Você pode encontrar outro emprego ou pode aceitar isso.
precisa saber é o seguinte

Respostas:


51

No entanto, agora sinto que estou sempre sendo instruído a fazer algo, em vez de decidir fazer algo.

Este é um indicador sério de que algo saiu dos trilhos. Um projeto ágil não deve ser assim. Essa retórica de "pessoas em processo" deve incluir "não forçamos nosso pessoal a fazer coisas ruins". Aqui estão algumas idéias:

Você está fazendo "scrum but"? Ou seja, parte scrum, parte outra coisa. (ou seja: "Estamos fazendo scrum, mas todas as nossas histórias têm de vir do nosso PMO, não de um proprietário do produto.") Muitas porcarias loucas se chamam Scrum atualmente.

Você, pessoalmente, não está envolvido no processo em que deveria estar? Conheço várias 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 proprietário do produto no início do desenvolvimento da história e obtenha seu feedback. (Como o PO, eles têm a palavra final, mas isso não significa que eles precisam fazer isso sozinhos.)

No Scrum, a equipe deve ser a proprietária do processo, e espera-se que o processo mude ao longo do tempo para atender às necessidades da equipe. Exponha suas preocupações na retrospectiva. Se você pode sugerir um ajuste no processo, isso tende a facilitar a venda para algumas equipes.


10
O Scrum +1 (como todas as metodologias Ágeis) é mais pesado na conversa do que na direção. O OP deve descrever o que o resultado final precisa ser capaz de alcançar e, em seguida, envolver os designers e desenvolvedores em maneiras de chegar lá.
StevenV

5
"people over process": Engraçado, então por que impor o processo SCRUM em vez de deixar as pessoas usarem o seu? E por que todas essas medidas (programação em pares, revisões freqüentes de progresso) que, em nome da transparência, permitem monitorar o trabalho dos desenvolvedores muito mais de perto?
Giorgio

3
@Giorgio: porque o desenvolvimento estruturado permite que as equipes trabalhem juntas, sem pisar nos dedos uma da outra o tempo todo. Ainda não descobrimos como fazê-lo perfeitamente ainda.
Phoshi

2
@Giogio, este é um problema com o ágil em geral. Embora um objetivo seja ter pessoas super processadas, na realidade o Agile se torna seguido religiosamente - o que novamente coloca o processo sobre as pessoas. Pessoalmente, acho que o lean faz um trabalho melhor do que o ágil, embora não tente impor uma estrutura estritamente horizontal da equipe - ele permite que os desenvolvedores escolham melhor as tarefas. Supondo que sua equipe não mude, um quadro kanban, além do que você está fazendo agora, pode deixar a gerência feliz e feliz também, dando liberdade para escolher suas histórias / tarefas.
jQwierdy

62

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

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

Você está enganado. Apenas de uma breve olhada na página da Wikipédia para o Scrum, podemos ver que: "a equipe, um grupo multifuncional que faz a análise, o design, a implementação, o teste, etc." Vejo? O Dono do produto diz o que fazer, mas cabe à equipe decidir como fazer isso.

Você é a pessoa responsável pela implementação, portanto, decida como o aplicativo será implementado. Ouça a opinião do Dono do produto, mas a decisão final é com você (ou com a equipe).

BTW microgestão se transformar desenvolvedores ativos para desenvolvedores passivos.


38
Amém até a última linha
Wivani

6
"O Dono do produto diz o que você deve fazer, mas cabe à equipe decidir como fazer isso." É exatamente isso que pode ser um problema para a motivação dos desenvolvedores: falta de inovação. Na maioria das vezes, o cliente deseja cavalos mais rápidos, não carros. Mas concordo totalmente com a microgestão.
MaR

1
+1 em @Lukas, devido à diferenciação entre o quê e como . Obrigado parceiro.
Saeed Neamati

5
"O Product Owner diz o que você deve fazer" - não concordo totalmente com isso. Eles devem dizer o que precisam . Uma diferença leve, mas importante. Em outras palavras: eles descrevem o problema / questão, você fornece a solução.
DanMan

2
@MaR É por isso que os desenvolvedores não conversam com os clientes. Os clientes falar com o proprietário do produto e pedir cavalos mais rápidos, o PO é aquele que vê problemas todos os clientes, combina e priorizados-los, e no processo descobre que os carros são melhores do que cavalos mais rápidos
Izkata

29

O que você está descrevendo NÃO é SCRUM

O proprietário do seu produto está superando seus limites se ele estiver lhe dizendo como fazer seu trabalho tecnicamente, não é disso que se trata o SCRUM.

O SCRUM é sobre liberar os desenvolvedores para se concentrarem nas questões de desenvolvimento e capacitá- los a se encarregarem de determinar quanto tempo as coisas levam e como fazê-las.

O SCRUM é sobre colaboração, é para isso que servem as reuniões de planejamento da Sprint, para promover a colaboração entre todos os interessados; 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 dos clientes, mas os desenvolvedores devem fazer a engenharia e o design, não o proprietário do produto.

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 hash a funcionalidade diretamente com os clientes. Os programadores criaram GUI's feitas no vácuo raramente atendem às necessidades dos clientes.

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

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


3
A natureza humana sempre encontrará uma maneira de arrebatar a derrota das garras da vitória.
Warren P

2
Há o que SCRUM deveria ser, e o que acaba sendo , pelo menos na maioria das empresas. O SCRUM não é mau por si só, mas é uma ferramenta que é facilmente usada pelo mal pela administração.
AresAvatar

11

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 conduzem a história e pagam as contas. O proprietário do produto garante que a história seja concluída. De alguma forma, seu grupo chegou à conclusão de que o Dono do Produto deveria lhe dizer como programar.

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

Você está envolvido no título de proprietário do projeto ou algo assim. Se você tem um motivo válido para discordar da história, diga alguma coisa, faça seu argumento. Você nem sempre pode ganhar. O trabalho deles é retornar aos usuários e informar que há um problema válido com a solicitação. Vamos ser sinceros: se a história solicitar que você solte um banco de dados aleatoriamente ao longo do dia, sem backup, sem perda de dados ou tempo de inatividade, você tem um problema e o dever de esclarecer a história.


10

Parece que suas aventuras no Agile foram corrompidas pelo Scrum. Acho que, de todas as metodologias ágeis, o Scrum é o menos ágil. É mais como cachoeiras em miniatura e gerenciamento de projeto adicional. Isso, é claro, faz com que seja o mais apreciado pelos gerentes, que sentem que estão recuperando o controle daqueles desenvolvedores irritantes, mas é claro que você vê a realidade da situação.

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

Então mude. Fale com a gerência e diga que é uma etapa retrógrada, que sua produtividade é menor do que costumava ser e todos estão descontentes com a maneira como está funcionando. Mostre o Manifesto Ágil (e seu gêmeo do mal ) e demonstre que você não apenas aprendeu as lições deste experimento, mas deseja evoluir os bons trechos dele para um sistema melhor (um que você costumava ter, que parece funcionar bem) para voce).


6
mim? sim - costumávamos trabalhar bem, então a gerência decidiu que o Agile era o futuro e impôs o scrum, o que nos restringiu tremendamente. O que costumávamos fazer sem esforço ficou atolado no processo e na burocracia. Uma vez eu peguei 3 cartas do scrum board !! As luzes piscaram e as sirenes tocaram por essa violação do 'caminho do scrum', e uma vez levei o cartão de volta para minha mesa . Os policiais de gerenciamento de projetos vieram para mim. E eu costumava me sentar nas corridas diárias, que também não caíam bem. Todas as trivialidades IMHO, mas foram transformadas em montanhas.
Gbjbaanb

2
Você não acha que, no seu caso, é uma implementação ruim e de cima para baixo do Scrum que causou uma perda de produtividade? Você diz que ficou "atolado no processo e na burocracia", o que é estranho, porque o Scrum é a metodologia menos burocrática mais simples do mundo ... Na verdade, toda a estrutura do Scrum se encaixa em uma folha ou 2. Entre o que você chama de "quadro de scrum" não faz parte da estrutura. No caso de Saeed, embora eu acredite que o problema seja uma lacuna entre o tipo de organização em que ele trabalhou (com grande liberdade e poder de decisão para os desenvolvedores) e o tipo de organização em que Scrum se aplica.
precisa saber é o seguinte

3
@ Ian31: Sim, esse projeto foi particularmente ruim, mas o Scrum apela a esse tipo de gerente. Você nunca os vê escolher Kanban ou Crystal, afinal. O Scrum se transforma facilmente em "scrum but" quando esses caras se apossam dele. pena.
Gbjbaanb

1
Eu acho hilário que qualquer empresa transforme Scrum em uma cerimônia religiosa. Ei! Fique de pé durante esta cerimônia onde fingimos ser ágeis! Ei! Sorria enquanto fingimos ouvi-lo e, em seguida, continue alegremente fazendo o que queríamos!
Warren P

2
Eu discordo totalmente do impulso desta resposta. Eu acho que algum tipo de "mini-cascata" pode ser muito benéfico, especialmente para desenvolvedores inexperientes, mas inteligentes, que podem fazer 5 coisas diferentes ao mesmo tempo e não terminar nenhuma delas. De fato, a pessoa que me treinou no Scrum disse que você ainda pode fazer "mini-cachoeiras" no Scrum, se quiser, mas, idealmente, elas devem durar um período de dias ou até horas . Eu pensei, as horas são muito curtas. Você nem sempre pode projetar> implementar -> testar uma história em poucas horas. E dividir histórias para que você possa nem sempre é o ideal.
Robin Green

8

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

Infelizmente, acho que muito software é menor do que poderia ser, porque muitas vezes partes são escritas para o desenvolvedor e não para o cliente. Sua nova abordagem deve reduzir isso, mas às custas do seu sentimento de propriedade.

Não tenho idéia de como sugerir que você melhore ou torne as coisas mais divertidas, mas é uma ótima pergunta e uma visão muito boa.


100% concorda. Agora você está mais alinhado com o proprietário do produto, mas isso significa que você tem menos liberdade para fazer o que acha certo. Eu também experimentei isso e isso foi péssimo e tornou meu trabalho muito menos agradável. Mas isso significava que eu estava muito melhor alinhado com os objetivos de negócios e gerente de produto. A empresa paga as contas - incluindo meu salário -, então sim, eles conseguem dizer o que querem em nível de detalhe. Eu não acho que eles estão realmente lhe dizendo como codificar. Se eles soubessem como poderiam fazer isso sozinhos.
22613 Michael Durrant

A empresa não paga aos desenvolvedores o que eles querem. Eles pagam aos desenvolvedores pelo ganho de produtividade que um bom ambiente de software oferece. Se você deixar que a empresa lhe diga o que fazer "detalhadamente", você realmente acha que eles obterão o bom ambiente de software que estão procurando?
Andomar 25/11/13

@Andomar - É um equilíbrio. Cada lado tem seus ideais, suposições e falhas. Ignorar qualquer um desses leva a perigo.
22413 Jonno

5

Você está recebendo histórias de usuários na forma de "Como um papel -, eu quero - objetivo / desejo - para que - seja benéfico--"? Parece que o Dono do produto deseja fazer o trabalho de design e pode não ser a melhor pessoa para fazer isso. O uso do padrão de história do usuário pode ajudar a garantir que o Dono do Produto atenda aos interesses comerciais e o desenvolvimento do software esteja sendo realizado pelos desenvolvedores do software.


4
Como desenvolvedor, nunca mais quero ver esse tipo de história de usuário, para que nunca precise gemer por sua inanidade.
Warren P

@WarrenP Sim, o clichê pode ser uma chatice, seja na forma de código ou de requisitos do clichê. Eu acho que o ponto principal é que todos esses três elementos devem ser declarados ou entendidos, mas mais importante, deve ficar claro para todos o que realmente é desejado, e os requisitos do modelo padronizado podem realmente impedir isso. Especialmente se os desenvolvedores começarem a pensar que preencher algumas breves palavras nesse modelo é sempre suficiente.
Robin Green

4

No Scrum, há muito espaço para os desenvolvedores contribuírem e aconselharem sobre novos recursos, interface do usuário, usabilidade ... A colaboração e a conversa entre empresários e desenvolvedores são necessárias no Scrum e isso permite. No entanto, no final, o proprietário do produto sempre terá a palavra final, porque ele é o responsável por maximizar o valor comercial dos incrementos de software produzidos sprint após sprint (em outras palavras, o ROI).

Do manifesto ágil:

Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso.

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 é responsável pela qualidade interna do software que produz.

Talvez você trabalhe em uma empresa criada por desenvolvedores, onde os programadores tiveram liberdade para implementar os recursos que desejassem. No entanto, a maioria das metodologias ágeis faz uma separação clara entre o pessoal 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, posso entender o sentimento que você tem de que não é mais capaz de "influenciar o cenário geral", mas com o crescimento da empresa, acho que teria sido o caso, Scrum ou não.

Em relação à análise, design e outras atividades de meta-desenvolvimento mencionadas (que não devem ser realizadas pelo Dono do produto), as equipes Agile devem ser multifuncionais e livres de silos. 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 lá versus apenas "código de monitoramento".


3

Pelo contrário, descobri que ter um proprietário do 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, e isso geralmente leva a discussões frutíferas.


3

Nós praticamos Scrum aqui. Temos uma reunião quinzenal de planejamento, na qual alimentamos as prioridades atuais de negócios, os sucessos e falhas do sprint anterior e decidimos, como equipe , o que queremos abordar para o próximo sprint.

Uma das maneiras de fazer isso é classificar a lista de pendências em um quadro por complexidade verticalmente e prioridade de negócios horizontalmente. Depois disso, o Dono do produto teve sua opinião; portanto, cabe à equipe escolher o que queremos fazer. Obviamente, escolher uma tarefa de baixa prioridade e alta complexidade é desaprovada, mas estamos decidindo isso como uma equipe. Isso torna as sessões de planejamento mais longas, mas vale a pena e é uma parte essencial do processo Agile.

E às vezes temos microgerenciamento, mas esse é um problema diferente.


3

O verdadeiro problema que você está descrevendo é uma patologia comum quando as equipes adotam uma metodologia: elas desligam o cérebro. Isso é verdade tanto no sistema ágil da nova escola quanto nos sistemas pesados ​​da velha escola.

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

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

Nesse caso específico, parece que o proprietário do produto pode estar fazendo muito. Você está confortável conversando com ele sobre isso? Você se sentiria 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.


2

Eu não estou realmente em sintonia com toda a coisa do scrum, pois há mais cachoeiras há um tempo.

Mas, para ser sincero, isso parece mais uma questão de pessoal de gerenciamento do que uma questão de técnica de gerenciamento de projetos. Como é mais baseado em pessoas do que em técnica.


Não @temptar, nosso relacionamento é muito bom. Sem ofensa, sem ódio, nada. Está tudo bem, tudo, exceto como nos sentimos em relação ao trabalho.
Saeed Neamati

2

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


2

Eu tive a mesma experiência com o Scrum e gostaria de chamá-lo de "tirania da história".

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

A única saída que encontrei até agora foi abandonar o Scrum - geralmente não é possível e / ou apropriado porque, afinal de contas, tem suas vantagens - ou introduzir algo como o tempo de 20% do Google para oferecer aos desenvolvedores uma saída criativa além do "você" fique à vontade para escolher como implementar a página de login ", porque, na realidade, você não é como sua implementação é restringida pelo código e pela arquitetura do sistema existentes - ou seja, a menos que se considere a liberdade de escolher entre 'um loop for e a while' liberdade.


1

Há uma grande diferença entre você decidir o que fazer ou ser informado sobre o que fazer .

Na minha experiência, há apenas um longo caminho entre saber o que fazer e decidir o que fazer.

No final, dessa maneira, geralmente acontece que fomos instruídos não 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 passam felizmente por nós tanto controle quanto podemos controlar (e, se a confiança deles é realmente firme, eles até tentam passar). mais que isso)

Ah, e na minha experiência, isso basicamente não tem nada a ver com Scrum / ágil. Aconteceu com scrum, iterativo, cascata, o que for. Parece que a questão da confiança é um processo agnóstico


1

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


1

De acordo com minha experiência, Scrum é observar profundamente o que você faz. Está apenas sentado no seu ombro e assistindo o que você faz. Embora tenha sua própria vantagem, odeio a metodologia scrum. Ele espera a contagem, não a qualidade. A qualidade está sendo comprometida com a metodologia scrum.


"A qualidade está ficando comprometida com a metodologia scrum.": Talvez seja um pouco extremo dizer que a qualidade fica comprometida, mas, sim, a controlabilidade do projeto recebe uma prioridade mais alta que a qualidade.
Giorgio

Incrível o quão poucas pessoas sabem sobre scrum ou ágil, e ainda como elas postam como autoridades. Ficamos com a impressão de que um indivíduo trabalhou por algumas semanas em um grupo disfuncional onde eles disseram estar "fazendo scrum" e concluíram que é assim que o scrum deve ser. Nesse caso, é um cara completamente anônimo, com apenas uma postagem ou comentário em 4 anos, e nenhuma evidência de conhecimento sobre o assunto. É por isso que não podemos levar muitos desses comentários muito a sério.
Curtis Reed
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.