Como parar / evitar o excesso de tempo em uma equipe Scrum?

Na verdade, estou ajudando uma pequena loja de software na implementação do Scrum. Recentemente, o Scrum Master me informou que ele tem um problema porque a Equipe está trabalhando ao longo do tempo para alcançar o Escopo (Backlog Comprometido). Então eles têm uma velocidade irreal .

Minhas perguntas formais são:

1. Além de falar sobre a Reunião Retrospectiva; você acha que é uma boa ideia implementar alguns obstáculos para evitar o excesso de tempo?

2. Em caso afirmativo, quais técnicas / ferramentas você sugere?

   • Sistema de controle de revisão (SVN, GIT, HG, etc ...), blocos por horas (8 a 5)
   • Blocos da estação de trabalho por horas (8 a 5) ou horas acumuladas (até 8 horas / dia)?
   • Outras)...

3. Ou, talvez, não impeça esse tipo de coisa; mas implementar algum "sistema de penalidades" por horas extras injustificadas ?

@Baqueta (e outros com perguntas semelhantes): Não, eles não são pagos por Horas Extra. Meu primeiro conselho a eles foi revisar suas estimativas porque talvez eles estivessem subestimando. Este foi o meu conselho favorito:

Se eles tiverem interesse em fazer horas extras, remova-o. Desenvolvimento não é algo que você pode fazer durante 60 horas por semana e se manter produtivo, e existem inúmeros estudos por aí que provam isso. Se o pagamento de horas extras for o problema, elimine-o e melhore o pagamento base para obter o que vale.

Além disso, acho que o problema raiz (para esta equipe) é uma combinação do seguinte:

1. Os desenvolvedores estão sendo informados sobre o que devem obter em um sprint / não estão sendo consultados sobre o que é viável / estão sendo ignorados quando dizem que há muito trabalho.
2. Os desenvolvedores estão constantemente subestimando quanto tempo as tarefas levarão / quantas unidades de trabalho estão envolvidas em cada tarefa.

Resumo: conversarei com a equipe para revisar suas estimativas e com o OP porque acho que eles não estão sendo consultados sobre o escopo, como você mencionou.

Sinceramente, esses "obstáculos" mencionados no número 2 são a pior ideia que já ouvi há muito tempo. O que acontece se um bug de prioridade máxima for encontrado às 16h45 e o cara que tem a capacidade de substituir seus bloqueios estiver doente? Quanto ao # 3 - você está sugerindo punir as pessoas por fazerem o trabalho delas .

Se a equipe estiver constantemente trabalhando horas extras para concluir os sprints, então eles têm interesse em fazer horas extras - por exemplo, pagamento de horas extras ou receber horas extras de férias - ou estão se comprometendo a fazer muito trabalho nos sprints.

Se eles tiverem interesse em fazer horas extras, remova-o . Desenvolvimento não é algo que você pode fazer durante 60 horas por semana e se manter produtivo, e existem inúmeros estudos por aí que provam isso. Se o pagamento de horas extras for o problema, elimine-o e melhore o pagamento base para obter o que vale.

Se houver muito trabalho entrando nos sprints, isso geralmente ocorre por uma de três razões:

1. Os desenvolvedores estão sendo informados sobre o que devem obter em um sprint / não estão sendo consultados sobre o que é viável / estão sendo ignorados quando dizem que há muito trabalho.
2. Os desenvolvedores estão constantemente subestimando quanto tempo as tarefas levarão / quantas unidades de trabalho estão envolvidas em cada tarefa.
3. Os desenvolvedores continuam sendo atraídos para tarefas que não fazem parte do scrum.

Se for o número 1, você está fazendo errado . Não há duas maneiras!

Se for o número 2, a causa usual é a inexperiência - com estimativas de tempo ou com o sistema em desenvolvimento. Uma boa maneira de contornar isso é parar de fazer estimativas de tempo e começar a estimar 'unidades de trabalho'. Use alguma unidade abstrata, apenas verifique se não são horas em tempo real (em última análise, você ainda está representando um intervalo de tempo, mas a abstração é importante!). Você pode começar a calcular quantas unidades de trabalho são realmente executadas em uma semana e depois configurar sprints usando esses dados.

Se for o número 3, você precisará começar a considerar essas outras tarefas de alguma forma. Se for consistente, deve ser fácil explicar (veja o item 2 acima). Se é frequente, mas imprevisível, é muito mais complicado de lidar. Você vai querer dar uma olhada no por que isso está acontecendo (por exemplo, erros sérios no código 'ativo' => seu teste é completo o suficiente?), Mas se isso não puder ser corrigido, o scrum pode não ser a abordagem certa para você. Minha equipe recentemente mudou para Kanban por esse mesmo motivo ...

Editar: Esclareceu minhas críticas às idéias apresentadas na pergunta.

Antes de tudo, parece que eles tiveram muito trabalho em um sprint se precisassem trabalhar horas extras para fazê-lo. Todas as horas estão registradas? Nesse caso, você pode contar quanto trabalho real é um argumento e usar esse número para calcular o trabalho para o próximo sprint.

Também é importante garantir que a equipe entenda que eles estão apenas se prejudicando, exigindo muito trabalho. Até o manifesto ágil fala sobre ritmo sustentável: "Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente". Trabalhar horas extras o tempo todo não é sustentável.

Em suma, sugiro comunicação em vez de força e multas. Eu imagino que isso levaria apenas à desmoralização da equipe.

Os desenvolvedores que trabalham horas extras provavelmente estão respondendo a algum incentivo, real ou percebido. O objetivo é remover o incentivo, se for real, ou comunicar que um incentivo percebido não está operacional.

Cada limite rígido sugerido possui algumas soluções alternativas ou outros problemas. Os blocos de controle de origem apenas levariam os desenvolvedores a manter seus commits até a janela abrir novamente. Os blocos da estação de trabalho precisariam ser eliminados assim que houvesse algum problema de suporte ou um dos desenvolvedores necessário para mudar seu horário por algum motivo. Os sistemas de penalidade apenas levarão a ocultar ou enterrar horas extras.

Eu acho que o problema é mais fundamental - a equipe tem algum incentivo (ou acredita que tem um incentivo) para trabalhar horas extras.

É isso que precisa ser abordado. Suas avaliações de desempenho estão ligadas aos seus números de velocidade? A gerência trabalha horas extras? Promoções e prêmios são concedidos para quem trabalha longas horas? Eles são contratados que são pagos por horas extras?

Simplesmente diga à equipe para não trabalhar horas extras. Período.

Isso pode fazer com que eles não consigam concluir algum trabalho. Isso não é um problema, é um ponto de dados. Eles podem usar esse ponto de dados no planejamento do próximo sprint. Novamente, não deixe que eles trabalhem horas extras. Se eles terminam ou não, eles têm outro ponto de dados. Espuma, enxágüe, repita.

Nenhuma quantidade de truques ou limites são necessários. Só não trabalhe horas extras. Saiba quanto trabalho você pode realizar e ajuste seu planejamento de sprint de acordo.

Talvez exista uma questão de não "quanto" eles estão trabalhando, mas quando. Isso pode ser um problema quando há um dia de trabalho programado, mas grande parte do horário normal é composta de reuniões e outras distrações sociais e pessoais. Eles estão trabalhando durante períodos extras porque se sentem mais produtivos.

Reduza a quantidade de trabalho no sprint e comece a trabalhar no horário flexível. Permita que eles entrem mais tarde. O responsável precisa apenas dizer às pessoas para irem para casa; está tudo bem. Existem algumas culturas corporativas que criam um ambiente em que sair mais cedo pode trazer algumas carrancas.

Eu lutei com isso quando mudei para o scrum. É natural querer fazer um esforço extra perto de um prazo, mas o scrum tem prazos a cada duas semanas, portanto é um ajuste. Além da sugestão que outras pessoas fizeram para reduzir os pontos de história comprometidos a cada iteração, eu também sugeriria garantir que as histórias sejam divididas o suficiente, para que cada desenvolvedor possa concluir pelo menos dois ou três em uma iteração.

Isso não apenas garante que cada desenvolvedor sinta que realizou algo a cada iteração, mas também oferece uma folga no seu escopo. Quando o seu burndown mostra que você não poderá terminar uma história, você pode retirá-la e realocar as pessoas para as histórias que podem ser concluídas. Quando as pessoas vêem que o escopo pode ser ajustado, é menos provável que se estressem com prazos irrealistas. Se você iniciar uma iteração com todas as histórias em andamento, não terá espaço para ajustes.

Um fluxograma cumulativo ideal deve se parecer com isso se todos estiverem terminando duas histórias por iteração:

Nunca é assim porque, na realidade, é muito difícil cronometrar todas as histórias para terminar no último dia, mantendo todos ocupados, mas é uma boa regra geral. Se você for supercomprometido, a área vermelha será maior e você poderá remover histórias. Se você for subcomprometido, a área azul será maior e você poderá adicionar histórias. Se suas histórias forem muito grandes, a área verde será maior e você deverá dividir as histórias.

Para evitar horas extras, você deve reduzir o escopo do projeto.

O gráfico a seguir mostra onde está a incerteza em um projeto:

Se você observar, nas fases de definição e requisitos do produto, há uma enorme variação na estimativa do esforço. Você não pode ter certeza se levará um mês ou um dia para implementar o recurso.

Aposto que nenhuma das tarefas foi realizada porque elas são muito grandes e não especificadas e são muitas.

Se sua equipe pode lidar com 10 tickets em 5 dias e receber 20 tickets, reduza esse número, encaminhe-o ao proprietário do produto / gerente de projetos / gerente / cliente e peça-lhes para priorizar.

Nesse ponto, é a única maneira de salvar a equipe das horas extras. Você não pode entregar tudo, mas o que você entregar terá menos chances de ter bugs.

Também aconselho a procurar um novo emprego e ajudar os companheiros de equipe a fazer o mesmo e a ajustar seus currículos e portfólios profissionais. Uma empresa que espera horas extras é aquela para a qual ninguém deve trabalhar e o software produzido será muito ruim.

Aconselho fortemente contra "blocos rígidos". Tais controles podem ser percebidos como microgerenciamento e podem falhar na solução do problema subjacente.

Sugiro que você descubra por que os programadores estão fazendo horas extras. A resposta pode te surpreender. Parece que você é um "outsider" (não um funcionário da empresa), e os programadores podem estar dispostos a ser sinceros com você se você se encontrar com eles em particular (one-on-one).

O motivo do trabalho extraordinário é realmente a carga de trabalho ou o motivo está mais relacionado à cultura ou às expectativas?

Os motivos da carga de trabalho podem ser

• O backlog comprometido é muito grande
• Os programadores ou o proprietário do produto são "banhados a ouro" (tornando os recursos mais complexos que o necessário)

As expectativas podem ser

• Algum tipo de recompensa financeira ou de reconhecimento por horas extras
• Medo de falhar. Os programadores têm medo de parecer mal ou ser punidos se não cumprirem o prazo
• Os programadores estão subestimando os efeitos nocivos a longo prazo das horas extras.