O SCRUM, Tickets, Tempo para entrega e afins

A ideia do SCRUM é organizar um processo de desenvolvimento para percorrer os diferentes ciclos do projeto mais rapidamente. Mas isso sempre incentiva os comportamentos corretos ao fazê-lo? Muitos dos usuários que participaram do debate em torno da questão nos últimos anos têm histórias semelhantes de como os desenvolvedores usam atalhos, se distraem com a pontuação alta de seus tickets ou até fingem produtividade para os gerentes. A grande pergunta é… Como evitar essas armadilhas?

Muito dos debates nos últimos anos tentou lidar com o impacto e as limitações do SCRUM em qualquer equipe ou indivíduo. Enquanto muitos veem o SCRUM como a causa das falhas da equipe, outros acreditam que seja um erro de atribuição e dizem que a disfunção nas equipes de desenvolvimento é muito mais profunda.

Já os defensores do SCRUM veem a má gestão como a causa. Stevem Jones um dos magos na atualidade escreve de forma enfática: Se a gerência está essencialmente ignorando os desenvolvedores, há prazos fixos a serem alcançados com um escopo predefinido, ou é um ambiente de guerra de egos em vez de uma equipe focada em alcançar o mesmo objetivo, eventualmente os desenvolvedores irão desistir e recorrer apenas a fazer as tarefas atribuídas porque acreditam que estão sob pressão e com isto farão um trabalho ruim em qualquer metodologia de desenvolvimento e o simples fato de tantas pessoas sentirem a necessidade de dizer algo sobre isso é um indicador da frustração que o SCRUM causa.

Quais são as armadilhas típicas do SCRUM?

Uma primeira crítica generalizada é sobre como as dinâmicas não intencionais acontecem durante as discussões. Um argumento é que eles podem degenerar para ser apenas uma demonstração de produtividade, especialmente quando os gerentes estão presentes. Esta é a razão pela qual a maioria dos usuários rotula os standups como “gerenciamento de atualizações”. Em sua mente, o check-in apenas convida os gerentes a manter o controle sobre o que está sendo trabalhado de maneiras inúteis. Isso é ainda mais verdadeiro para equipes distribuídas que trabalham de forma assíncrona.

Priorizando o “FEITO”

Outro ponto levantado é que qualquer processo que divida o trabalho e acompanhe o progresso leva a uma nova medição do progresso (deliberada ou não). Apenas introduzindo métricas, isso influencia o comportamento das pessoas que contribuem para elas.

Muito autores sugerem que isso significa que os desenvolvedores podem cortar custos para concluir o que foi prometido para terminar no sprint atual. O problema é que um ticket individual que está sendo trabalhado e movido para “concluído” durante um sprint é uma caixa preta. Conta o mesmo para o indicador de velocidade. “Uma implementação ruim”, que passa no controle de qualidade e uma implementação bem testada e bem arquitetada são equivalentes. É um falso indicador de produtividade.

Outro tópico que reflete a discrepância entre grandes indivíduos versus grandes equipes. Com todos seguindo a metodologia SCRUM, você pode ter alguns desenvolvedores altamente eficientes, mas não tem uma equipe e sem os incentivos certos, a auto-organização é uma meta não cumprida.

Os membros da equipe vão fazer as coisas da maneira que preferem/são incentivados a fazer e, a menos que isso resulte em uma equipe útil, muitas coisas não são feitas e os membros da equipe continuam marchando para o caos, além disso, deixar que cada desenvolvedor escolha seu método para resolver um problema, cria mais trabalho durante a depuração.

Tarefas complicadas são despriorizadas

Na mesma linha, vários autores criticam ainda mais a ilusão de produtividade – há um foco em obter qualquer coisa para “PRONTO”, enquanto o pensamento profundo não parece muito produtivo. Assim, os desenvolvedores podem escolher problemas fáceis e pular os problemas difíceis de resolver. O SCRUM incentiva a escolha de trabalhos que podem ser feitos facilmente e rapidamente produzidos em um ritmo constante. O resultado: atualizações diárias e check-ins incentivam tarefas de coleta que podem ser feitas em um dia.

Até este ponto podemos enfatizar que um “TICKET PRONTO” geralmente é uma decisão de recurso e não uma verificação do código que está sendo escrito. Quando a velocidade é a única medida, a equipe não tem mais tempo para consultar, dar uma segunda opinião, verificar um conceito diferente, temos que lembrar que precisamos procurar aconselhamento e segundas opiniões. Mas qualquer tempo fazendo isso é menos tempo gasto produzindo “TICKETS PRONTOS”, e trocar idéias se a sua métrica é o tempo isto é totalmente anti-produtivo.

Arquitetura orientada por tickets

Não apenas os desenvolvedores fazem escolhas sobre o que trabalhar com base no sistema de tickets, criando involuntariamente uma arquitetura confusa, com os desenvolvedores trabalhando nos tickets sequencialmente e independentemente uns dos outros, pois a arquitetura começa rapidamente a espelhar os tickets.

Lendo artigos, livros e discussões encontramos aqueles que argumentam que não seguir as regras do SCRUM adequadamente é a causa raiz de todos os problemas. No entanto, talvez o ponto mais forte contra o processo SCRUM seja sobre ele se tornar o processo que substitui todo o resto, e por isso pode quebrar uma equipe vencedora.

Essa é uma longa lista de problemas, sejam eles causados ​​ou não estritamente ou apenas trazidos à tona pelo SCRUM. No entanto, igualmente numerosas foram as sugestões de como permitir que os desenvolvedores vivam de acordo com as regras do scrum.

Standup diário ≠ novos tickets todos os dias

Muito dos debates sugerem que as reuniões diárias criam pressão para entregar um tíquete fechado todos os dias. Mas a priorização de tarefas ainda deve acontecer Se isso não acontecer naturalmente, é o trabalho do Gerente priorizar as tarefas dentro do sprint dando enfase nas tarefas maiores. De qualquer forma, se até o segundo dia do sprint, ninguém pegou a tarefa complexa, então o GERENTE deve dizer ‘Vejo que ninguém iniciou a tarefa X – essa é uma grande tarefa e precisa ser iniciada imediatamente se vamos terminá-lo neste sprint.”

Pare de perseguir recordes pessoais não rastreando-os

Sim, você deve quebrar tudo em um sprint em pequenos pedaços, mas o scrum não diz que você deve ficar obcecado com o progresso – certamente não colocando os desenvolvedores uns contra os outros. Pare completamente de rastrear as pontuações dos indivíduos. Muitos gerentes podem precisar reaprender seu processo. “Diga à gerência que, no momento em que elogiam um desenvolvedor ou dão um aumento com base no volume de tickets, eles mudam radicalmente o comportamento.”

O foco deve ser se a equipe cumpriu seus compromissos como uma equipe. O GERENTE deve enfatizar isso e evitar qualquer discussão ou medição de quantos ticket cada desenvolvedor fez.

Fonte: Deamons