A equipe constantemente falha em cumprir as metas de sprint

Somos uma pequena empresa de software com um produto.

Usamos o scrum e nossos desenvolvedores escolhem os recursos que desejam incluir em cada sprint. Infelizmente, nos últimos 18 meses, a equipe não entregou os recursos com os quais se comprometeu durante um sprint.

Eu li muitas postagens / respostas afirmando que algo como "o software é feito quando é feito, o mais cedo ou mais tarde ... não ajuda a pressionar a equipe, a colocar mais pessoas nele, ... "Recebi feedback semelhante de um dos desenvolvedores sobre minha pergunta sobre como podemos melhorar a taxa de sucesso dos sprints. Ah, e sim, usamos retrospectivas .

Minha pergunta é basicamente:

Quando é justo procurar o problema na qualidade dos desenvolvedores?

Estou começando a pensar que, se você escolher seu próprio trabalho / recursos e ainda assim falhar em cada sprint: - Você não poderá supervisionar a complexidade do seu próprio código; - ou o código é tão complexo que ninguém pode supervisionar a complexidade.

Estou esquecendo de algo?

Você deve primeiro perguntar: 'quem se importa'?

Concluir sprints é bom e, em algumas empresas, resulta em cookies do scrum parent. Mas o teste final é se a empresa está atingindo seus objetivos.

O acima é faceta. Se a empresa tiver êxito, sem nunca concluir o conteúdo planejado de um sprint, você também pode usar o Kanban: você classifica a lista de pendências, trabalha no que é mais importante e não se preocupa tanto com iterações definidas.

Um dos valores das iterações definidas é impulsionar a melhoria do processo (ou eliminar o desempenho inferior em algumas mentalidades). Você não está entendendo isso agora. Portanto, você pode adotar o restante do processo que melhora o processo (e eventualmente concluir sprints) ou pode decidir que gosta do que tem.

Estou esquecendo de algo?

SIM!

Você passou 18 meses - ou em algum lugar próximo a 36 sprints com retrospectivas, mas de alguma forma não conseguiu consertar? Administração não responsabilizar a equipe, e depois a sua gestão não segurar -los responsáveis por não responsabilizar o time?

Você está sentindo falta de sua empresa ser incompetente .

Então, como consertar isso. Você (o desenvolvedor) para de se comprometer com tanto trabalho. Se as histórias são tão grandes que você não pode fazer isso, precisa dividi-las em pedaços menores. E então você responsabiliza as pessoas pelo que elas dizem que serão feitas. Se isso acontecer, eles poderão executar apenas um pequeno recurso a cada sprint, e então descobrir o porquê e torná-lo melhor (o que pode envolver a substituição do desenvolvedor). Se eles não conseguirem descobrir como se comprometer com quantidades razoáveis ​​de trabalho, você os demitirá .

Antes disso, porém, eu olhava para a gerência que deixava as coisas por tanto tempo e descobria por que elas não estão fazendo seu trabalho.

Gostaria de sugerir que você faça uma pequena alteração e experimente o Kanban por algumas semanas, em vez do Scrum . Pode funcionar melhor para sua equipe.

Enquanto o Scrum aumenta a produtividade limitando o tempo de trabalho disponível em um sprint, o Kanban aumenta a produtividade e a velocidade limitando o número de problemas ativos e simultâneos. A estimativa de tempo não faz mais parte do processo. ( fonte )

Em poucas palavras, o que é Kanban?

O Kanban também é uma ferramenta usada para organizar o trabalho em prol da eficiência. Como o Scrum, o Kanban incentiva o trabalho a ser dividido em partes gerenciáveis ​​e usa um Quadro Kanban (muito semelhante ao Quadro do Scrum) para visualizar esse trabalho à medida que avança no fluxo de trabalho. Onde o Scrum limita a quantidade de tempo permitida para realizar uma determinada quantidade de trabalho (por meio de sprints), o Kanban limita a quantidade de trabalho permitida em qualquer condição (apenas tantas tarefas podem estar em andamento, apenas tantas podem -do list.)

Como SCRUM e Kanban são iguais?

Tanto o Scrum quanto o Kanban permitem que tarefas grandes e complexas sejam divididas e concluídas com eficiência. Ambos valorizam a melhoria contínua, a otimização do trabalho e do processo. E ambos compartilham o foco muito semelhante em um fluxo de trabalho altamente visível que mantém todos os membros da equipe informados sobre o WIP e o que está por vir.

Veja o restante dos detalhes neste link

Minha pergunta é basicamente: quando é justo procurar o problema na qualidade dos desenvolvedores

Não há informações suficientes em sua postagem para responder a essa pergunta. Não há como saber se eles estão falhando por serem incompetentes ou porque estão comprometidos em fazer mais trabalho do que o razoável.

Se eu sou um desenvolvedor incrivelmente talentoso, em uma equipe de desenvolvedores incrivelmente talentosos, e falhamos em terminar as histórias do X em dois sprints (ou 36!), Somos incompetentes? Ou, simplesmente somos péssimos em estimativa? Isso depende se as histórias foram "crie uma tela de login" ou "envie um homem com segurança para Marte".

O problema começa com histórias ruins e / ou estimativas ruins

A estimativa é difícil. Muito difícil. Os humanos são péssimos, e é por isso que o Scrum nos faz dividir o trabalho em blocos que não devem levar mais de um dia ou dois, e montar pequenos grupos desses blocos que temos certeza de que podemos concluir em um curto período de tempo . Quanto maiores os blocos, e quanto maior o período, menos precisas são nossas estimativas.

Como são suas lojas? Eles são bem escritos, com bons critérios de aceitação? Eles são pequenos o suficiente para fazer em apenas alguns dias? Sem histórias bem escritas (que são culpa de toda a equipe de desenvolvimento, incluindo o proprietário do produto), não se pode esperar que a equipe faça boas estimativas.

O problema é agravado por retrospectivas ruins

O que você está fazendo de errado, aparentemente, é que não está tirando proveito de retrospectivas. Você passou 18 meses sem resolver esse problema; portanto, a equipe não está percebendo o problema ou está falhando em resolvê-lo em suas retrospectivas.

Cada retrospectiva termina com pelo menos um item de ação para a equipe executar, a fim de melhorar o desempenho no próximo sprint. Cada retrospectiva inclui falar sobre os itens de ação do sprint anterior para ver se eles foram feitos e se foram eficazes?

A solução não é culpar, é aprender

O primeiro passo deve ser parar de procurar culpa e começar a trabalhar para melhorar a equipe. Sua equipe provavelmente não é incompetente, apenas ruim em estimativa e planejamento. Force a equipe a terminar um sprint, mesmo que isso signifique que eles escolham uma única história e terminem uma semana mais cedo. Se eles não podem fazer isso, então são incompetentes ou as histórias são simplesmente muito complexas. A resposta para essa pergunta deve ser óbvia.

Quando conseguirem terminar uma história, saberão com razoável certeza que podem fazer X pontos de história em um sprint. A matemática simples ajudará a responder à questão de saber se eles podem fazer mais histórias ou não.

Melhoria contínua é a solução

Quando eles terminam uma história em um sprint, é hora de ver se eles podem fazer duas. Espuma, enxágüe, repita. Quando eles começam a falhar nos objetivos do sprint, você encontra o limite para suas habilidades de estimativa. Volte ao número de pontos da história da história anterior e mantenha-se nessa por um tempo.

Sempre leve as retrospectivas a sério. Se eles não terminaram um sprint, descubra o porquê e aja de acordo. Eles tinham muitas incógnitas? Eles têm a combinação errada de habilidades? Quão boas foram suas estimativas? Se eles estimavam que uma história tinha X pontos, seria necessário uma quantidade relativamente igual de trabalho que as histórias do priorado com pontos X? Caso contrário, use isso para ajustar os pontos das histórias daqui para frente.

Você diz que "usa retrospectivas". Mas o que a equipe realmente faz nessas retrospectivas? Como você passou 18 meses sem abordar esse aspecto do seu processo, acho que a resposta é: nada de muito útil.

Para mim, a retrospectiva é a parte mais importante do processo. Jogue fora ou mude qualquer outra coisa sobre o scrum o quanto quiser (por mútuo acordo da equipe durante uma retrospectiva, é claro), mas comprometa-se a reservar um tempo regularmente para conversar sobre como o processo está funcionando para todos, compartilhar o que funcionou e o que não aconteceu trabalhar e propor idéias para melhorar. Continue tentando melhorar seu processo pouco a pouco a cada sprint e, mais cedo ou mais tarde, você poderá ter algo que funcione muito bem.

No seu caso, esse processo não parece estar funcionando. Como as metas do sprint não estão sendo cumpridas, é prudente que se concentre retrospectivamente no porquê desse caso. Obviamente, a equipe teve muito trabalho para o sprint. Mas por que eles fizeram isso?

• Eles subestimaram a complexidade do trabalho?
• A gerência os pressionou a assumir mais trabalho do que a equipe achava que poderia lidar?
• Eles tiveram muitas interrupções / emergências que consumiram recursos para concluir o trabalho planejado?
• Eles tiveram gargalos que atrasaram a conclusão do trabalho (por exemplo, aguardando ativos de uma equipe de design externa)?
• E até: um ou mais membros da equipe foram incapazes de fazer o trabalho?

Esse é o tipo de pergunta que a equipe deveria ter se perguntado a cada corrida nos últimos 18 meses. Depois, armados com as respostas, eles podem propor melhorias de processo sugeridas para testar o próximo sprint. Isso pode incluir:

• Faça menos trabalho no próximo sprint (duh!)
• Seja mais conservador nas estimativas
• Diga para quem está nos pressionando a fazer mais trabalho, porque já estamos assumindo mais do que podemos realizar agora
• Gerencie melhor as interrupções e ajuste a quantidade de trabalho no próximo sprint para acomodar emergências inevitáveis
• Corrija os gargalos ou planeje os que você não pode evitar
• Não atribua histórias a membros da equipe que não possam realizá-las (e, separadamente, descubra a resposta da gerência para resolver uma situação com um membro de equipe com baixo desempenho, desde treinamento e orientação até demissão)

Esse é o tipo de conversa que deveria ter acontecido a cada sprint nos últimos 18 meses. Não se trata de pressionar a equipe ou adicionar mais recursos, mas de usar suas retrospectivas para melhorar seu processo continuamente. Isso claramente não está acontecendo aqui.

Você pensaria que, no 15º sprint com gols perdidos, a equipe discutiu isso em sua retrospectiva tantas vezes, até o ponto em que eles decidiram assumir os objetivos de sprint mais mínimos possíveis apenas para conseguir um completo. No 25º sprint incompleto, eu apenas fazia um sprint com uma única alteração de string e nada mais. Se a equipe não conseguir gerenciar isso em um sprint, os problemas serão ainda piores do que você deixou transparecer.

Para ficar claro, como vários já apontaram, as metas de sprint são previsões, não compromissos de ferro, e as metas perdidas não são, em si, indicativas de outra coisa senão fazer previsões imprecisas. Uma ótima equipe pode errar muitos objetivos porque é uma péssima previsão, enquanto uma péssima equipe pode atender a todos e não entregar nenhum valor real. Mas se suas previsões estiverem erradas na mesma direção por 18 meses seguidos, essa parte do seu processo não funcionará. Use suas retrospectivas para corrigir o processo, para que suas previsões estejam razoavelmente próximas da realidade real do que a equipe pode oferecer a cada sprint.

"o software é feito quando está pronto, nem antes, nem depois."

Isso é verdade, mas para cada tarefa em que seus desenvolvedores começam a trabalhar, todos na sua organização entendem a Definição de Concluído para cada tarefa?

Parece que um dos seus maiores problemas é Estimation , mas os desenvolvedores só podem fornecer uma estimativa realista quando tiverem uma 'definição de pronto' inequívoca e claramente especificada. (Que inclui problemas de processo da empresa - por exemplo, documentação do usuário, pacotes de trabalho em uma liberação formal, etc.)

Não é de surpreender que a superestimação esteja causando um problema, uma vez que a maioria dos desenvolvedores vê que estimar o tempo necessário para concluir uma tarefa é a mais difícil.

No entanto, a maioria dos desenvolvedores tende a ter um controle razoável (embora otimista ) da quantidade de esforço que é capaz de realizar, por um determinado período de tempo.

O problema geralmente é que os desenvolvedores lutam para criar um relacionamento entre uma tarefa e a quantidade total de esforço necessária quando lidam com informações incompletas - principalmente se são pressionados a apresentar todas as respostas antecipadamente para uma tarefa realmente enorme .

Isso naturalmente leva a que as estimativas de tempo sejam desconectadas da realidade e elas perdem de vista coisas como o processo de construção e a documentação do usuário.

A desconexão tende a começar no início, quando a tarefa é descrita; e geralmente é composto por uma pessoa não técnica que elabora uma lista de requisitos sem ter idéia da quantidade de esforço necessário.

Às vezes, as pessoas da gerência sênior especificam tarefas e ignoram completamente os problemas de processo da empresa; não é incomum para a gerência sênior pensar que coisas como definir testes ou criar uma versão formal liberada ou atualizar um documento do usuário acontecem magicamente sem tempo ou esforço. requeridos.

Às vezes, os projetos falham antes que um desenvolvedor escreva uma linha de código porque alguém, em algum lugar, não está fazendo seu trabalho corretamente.

Se a equipe de desenvolvimento não estiver envolvida na aceitação de requisitos ou na captura de critérios de aceitação, isso significa uma falha no gerenciamento - porque significa que alguém que não conhece o código e os problemas técnicos comprometeu os negócios com um conjunto incompleto de requisitos, e deixou o projeto aberto a erros de interpretação, fluência no escopo, revestimento de ouro etc.

Se a equipe de desenvolvimento estiver envolvida na captura e na concordância de requisitos, pode ser uma falha da equipe, responsável por esclarecer os detalhes (e os critérios de aceitação - por exemplo, "Como é a entrega do produto? Quando é feito ?" ) A equipe de desenvolvimento também é responsável por dizer NÃO quando houver outros problemas de bloqueio no caminho ou se um requisito for apenas irrealista.

Portanto, se os desenvolvedores estiverem envolvidos na captura de requisitos:

• A equipe tem a oportunidade de se sentar com o gerente de produto para esclarecer os requisitos / definição de pronto?
• A equipe faz perguntas suficientes para esclarecer os requisitos implícitos / assumidos? Com que frequência essas perguntas são respondidas satisfatoriamente?
• A equipe exige critérios de aceitação (definição de concluído) antes de fornecer uma estimativa?
• Quão bem os critérios de aceitação geralmente são capturados para cada tarefa? É um documento vago com detalhes esparsos ou descreve a funcionalidade tangível e as palavras que um desenvolvedor poderia traduzir inequivocamente em um teste?

As chances são de que a produtividade da sua equipe não seja um problema; sua equipe provavelmente está envidando todo o esforço possível para desenvolver. Seus problemas reais podem ser um ou mais dos seguintes:

• Requisitos incompletos e vagos.
• Requisitos / tarefas que são grandes demais em primeiro lugar.
• Má comunicação entre a equipe de desenvolvimento e a alta gerência.
• Falta de critérios de aceitação claramente definidos antes das tarefas serem entregues à equipe.
• Especificação incompleta ou vaga / ambígua de testes de aceitação. (ie Definição de Concluído)
• Tempo insuficiente alocado para definir / concordar com os critérios de aceitação.
• Os desenvolvedores não consideraram tempo para testar o código de linha de base existente ou corrigir os erros existentes
• Os desenvolvedores testaram o código de linha de base existente, mas não apresentaram os bugs como problemas de bloqueio antes de fornecer estimativas sobre os requisitos
• A gerência viu os problemas / bugs e decidiu que os bugs não precisam ser corrigidos antes de escrever um novo código.
• Os desenvolvedores estão sob pressão para contabilizar 100% de seu tempo, mesmo que possivelmente 20% (ou algum número semelhante) seja provavelmente ocupado por reuniões, distrações, e-mails etc.
• As estimativas são acordadas com o valor de face e ninguém ajusta espaço para erro ou contingência (por exemplo, "decidimos que isso deve levar 5 dias, portanto esperamos que seja feito em 8.").
• As estimativas são tratadas por todos (desenvolvedores e gerenciamento) como números únicos, em vez de números "intervalo" realistas - ou seja,
  • Melhor estimativa de caso
  • Estimativa realista
  • Estimativa do pior caso

... a lista poderia durar muito mais tempo do que isso.

Você precisa fazer alguma "descoberta de fatos" e descobrir exatamente por que as estimativas são constantemente desconectadas da realidade. O software de linha de base existente é ruim? Falta cobertura de teste de unidade? Seus desenvolvedores evitam a comunicação com o gerenciamento? O gerenciamento evita a comunicação com os desenvolvedores? Existe uma desconexão entre as expectativas de gerenciamento e as expectativas dos desenvolvedores quando se trata de "Definição de Concluído" ?

Meu conselho para reiniciar a equipe é escolher a menor história possível por equipe, por sprint e completar essa história, e somente essa história!

Eu concordo com os outros pôsteres, ou a equipe é incompetente ou eles estão tentando fazer muita coisa.

Comece com as menores coisas, as histórias mais simples e complete um único sprint. Faça com que a equipe termine um sprint e tenha sucesso, e isso os ajudará a ver como priorizar seus compromissos de tempo e trabalho. Com o tempo, a equipe poderá trabalhar cada vez mais até atingir o pico de produtividade.

Você deve coletar dados e criar níveis de confiança com base no desempenho passado.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

O exemplo mais simples é com sprints de tempo constante, como a cada duas semanas. Estime quantos pontos da história a equipe terminará dentro de duas semanas. Depois que as duas semanas terminarem, veja quantos pontos da história foram realmente concluídos. Com o tempo, você poderá estimar 15 pontos, mas apenas terminar 10. Nesse caso simples, você pode começar a avançar com um ajuste de velocidade para planejar apenas 10 pontos por sprint. Ou você planeja concluir 66% do trabalho estimado.

Ao criar níveis de confiança com desvios padrão, você pode dizer à gerência: de acordo com as metas atuais do projeto, esperamos que apenas 50% de confiança possamos terminar em 3 semanas, mas 95% de confiança que possamos terminar em 5 semanas.

A idéia por trás do Agile e do Scrum é criar um loop de feedback rígido para que você possa avaliar seu processo. Você deve perguntar "Onde foi que isso aconteceu?", Pois parece que ele foi completamente quebrado.

1. Planeje o que você fará e faça uma lista
   • Isso deve consistir na seleção de itens de uma lista de pendências de itens que precisam ser concluídos. Antes que qualquer coisa seja incluída na lista de tarefas do sprint, a equipe precisa concordar que eles o compreendem completamente e que estimam aproximadamente que será necessário menos de um sprint para ser concluído.
   • Idealmente, a lista de pendências é ordenada por prioridade (para o negócio) e você pode receber por ordem de prioridade.
   • Se os itens da lista de pendências forem muito grandes, divida-os em pedaços menores. Em seguida, divida os pedaços em tarefas individuais que podem ser concluídas em um dia ou menos.
   • Não espere que esse planejamento seja fácil ou rápido.
2. Executar em itens da lista por um período definido (um sprint)
3. Revise o que você realizou
   • Que histórias foram terminadas?
   • Se nenhuma história foi concluída, que tarefas foram inventadas?
   • Se nenhuma tarefa foi concluída, o que exatamente todos fizeram na última segunda-feira? Terça-feira passada ?, etc. - neste momento, é hora de uma introspecção severa ...

4. Solucione os problemas (analise o feedback e se adapte)

   • Quanto tempo demoraram as coisas que terminaram?
   • O que impediu a conclusão de tarefas?
   • Os membros da equipe estão dividindo histórias (recursos) em tarefas que podem ser concluídas em 1 dia ou menos? Caso contrário, faça isso e faça parte da lista de tarefas.
   • Quais alterações na lista de tarefas ou nos itens da lista de tarefas foram feitas durante o sprint? Isso foi motivo para não terminar? Se for, não altere a lista ou os recursos. Jogue o recurso alterado na lista de pendências até ficar estável.
   • Como você pode reduzir o tamanho e o escopo de alguns itens para algo que pode ser finalizado em um sprint? Escolha algo minúsculo como uma melhoria de registro, uma correção simples de erro, um erro de digitação, apenas para concluir algumas coisas para permitir que a equipe avalie o que eles podem fazer. Se você não puder fazer isso, pare de correr e planeje novamente .

5. Volte ao passo um e repita até o lançamento ...

Existem obstáculos na documentação, problemas de acoplamento na criação de dependências, problemas de comunicação, informações insuficientes nos requisitos? ... O que? Os desenvolvedores passaram o tempo tentando aprender novas tecnologias? Eles gastaram grandes quantidades de tempo em design? Coisas como o aprendizado foram contabilizadas na lista de tarefas do sprint?

Você achou que sua equipe achou que eles haviam isolado seus problemas a cada retrospectiva? A equipe agiu para corrigir os problemas. A equipe não respondeu e o gerenciamento simplesmente ditou as soluções e o curso da ação?

Dado o longo período de tempo, algo está errado sistemicamente, não simplesmente com os desenvolvedores. Em algum momento (antes de um ano foi para cima) alguém da equipe (incluindo o scrum master) deveria ter perguntado, o que, ainda que pequena, pode se realizar?

Na sua situação, as retrospectivas são tarde demais.
Você está realizando reuniões de stand-up diárias e realmente obtendo status das pessoas sobre o que elas fizeram nas 24 horas anteriores?
O scrum master está usando essas reuniões para medir o progresso de cada desenvolvedor em relação a seus objetivos?
Você precisa usar essa parte da metodologia Scrum para monitorar o progresso à medida que avança. Deve dar uma boa visão do que as pessoas estão fazendo.
Eles estão distraídos? Passar muito tempo com café, ou ajudar outras pessoas no SE / SO, ou ler as notícias, ou fazer inspeções que não são consideradas? Ou eles estão realmente de cabeça para baixo, a todo vapor e completamente comprometidos demais? A exibição diária deve fornecer uma boa ideia. Também ajudará a manter os desenvolvedores focados na tarefa em questão, para que eles não tenham que admitir que não fizeram nada ontem.
E, é claro, se eles reportarem um progresso constante durante todo o sprint e ainda não entregarem no final, eles estavam mentindo e talvez fosse hora de um novo desenvolvedor.

É difícil estimar o esforço e o tempo necessários para concluir uma tarefa complexa, como código de programação. Como Joel Spolsky coloca:

Os desenvolvedores de software não gostam muito de fazer agendas. Geralmente, eles tentam fugir sem um. "Será feito quando terminar!", Dizem eles, esperando que um zinger tão corajoso e engraçado reduza seu chefe a um acesso de risadinhas e, na jovialidade que se segue, o cronograma será esquecido.

No entanto, as empresas precisam de prazos para operar. Como Joel sugeriu, tente usar o Agendamento Baseado em Evidências, que produzirá estimativas de tempo com probabilidade associada, à qual a gerência pode se relacionar como qualquer tipo de risco.

Scrum faz algumas coisas.

Primeiro, incentiva a priorização. O fornecedor do trabalho precisa dizer o que quer que seja feito primeiro e não dizer "tudo é igualmente importante".

Segundo, gera um produto utilizável, mesmo que nem tudo esteja terminado. Esse é o ponto de ter um "produto potencialmente transportável" no final de cada iteração.

Terceiro, fornece um loop de feedback mais rígido. Ao insistir para que as coisas sejam "concluídas" no final de um sprint, você evita o problema "90% do recurso concluído, mas apenas na metade do caminho"; ao pressionar prazos, você pode deixar de lado as coisas que precisam ser deixadas de lado, para que pareça que você quase cumpriu o prazo ou pode fingir. Ao ter uma definição de feito e insistir nas coisas que estão sendo feitas, você sabe se algo é mais difícil do que parece antes, em vez de mais tarde.

Em seguida, evita o inventário, movendo o planejamento detalhado para perto de fazer o trabalho. Planejar as coisas distantes é uma forma de inventário: capital gasto em recursos que não estão disponíveis para venda ou uso imediato pelos clientes. Esse inventário pode apodrecer (os planos mudam sob os pés, novas informações o tornam obsoleto), desalinhar com as necessidades (acontece que não precisamos de uma rede distribuída, porque a coisa que o utilizava não valia a pena) e reduzir o valor das mercadorias embarcadas (se, no último ano, metade do seu tempo foi gasta no planejamento para o próximo ano e além, você poderia ter recebido o dobro do que enviasse se trabalhasse em coisas para estar pronto por enquanto). Se você puder aproximar o planejamento da execução sem perda (complicado!), Poderá diminuir o estoque.

Não é a única maneira de resolver esses problemas. Você parece estar usando o scrum, onde ele fornece um fluxo de trabalho para os desenvolvedores trabalharem a cada período, adicionando periodicamente novo trabalho a ser feito e verificando o progresso.

Essa é uma maneira útil de usar padrões scrum-esque. Ele mantém o trabalho fluindo, mantém o planejamento próximo à produção, fornece alguns loops de feedback etc. Ele ainda tem vantagens em não prejudicar o desenvolvimento e os testes para se adequar ao sistema (se o teste for melhor realizado com o trabalho estiver basicamente finalizado , tentar concluir as coisas e testá-las no mesmo sprint força o backend do sprint a não envolver novos desenvolvimentos!)

O fracasso em colocar exatamente o que eles farão em um sprint não prova que seus desenvolvedores não estão fazendo um ótimo trabalho. Isso significa que eles não estão seguindo o SCRUM do alto, em vez disso, usam partes da estrutura.

Se eles tivessem dividido pela metade (ou esquartejado) quanto eles se comprometeram com cada sprint, mas mantivessem todo o resto igual, teriam terminado mais do que se comprometeram com cada sprint! Você teria a mesma quantidade de código produzido. Claramente, as "falhas de sprint" não são a parte importante, porque esse é apenas um detalhe interno do processo. O objetivo da empresa é fazer a merda, e essa merda ser boa; não seguir algum processo específico, a menos que seu objetivo seja um determinado tipo de certificação de processo ISO.

O processo existe subserviente ao objetivo das coisas feitas.

Por outro lado, como eles não seguem as regras do SCRUM, você não está recebendo o mesmo tipo de feedback. Você deve examinar o material resultante para ver se o tipo de falhas produzidas são as que o SCRUM foi projetado para lidar; existem histórias que vivem como zumbis para sempre, e só são mortas até tarde? Existem histórias que parecem fáceis, elas explodem e em uma retrospectiva em que não vale o trabalho total? O produto é realmente transportável nos momentos em que você precisa / deseja enviá-lo?

"O software é feito quando está pronto, o mais cedo, o mais tardar" é uma receita para o fracasso, se você não definiu a aparência de "pronto".

A maioria dos engenheiros tentará produzir a melhor solução possível, mas isso pode facilmente levar ao revestimento de ouro, especialmente com engenheiros menos experientes. As únicas responsabilidades da gerência são definir exatamente onde está o objetivo e manter seus engenheiros indo nessa direção. Os engenheiros frequentemente tentam fazer curvas laterais para melhorar os recursos, e cabe à gerência decidir se essa curva lateral acelerará as coisas a longo prazo, ou se está apenas melhorando para melhorar.

O ponto do desenvolvimento ágil é que cada nova peça de trabalho deve ser tão boa quanto necessária para atender a esse sprint E NÃO É MELHOR !!!!!! Sim, essa é a maior ênfase que posso adicionar no StackOverflow - e ainda não é suficiente. Se você achar que as pessoas estão adicionando coisas que não são necessárias neste momento , elas precisam de treinamento sobre como fazer o desenvolvimento ágil corretamente.

Ah, e sim, usamos retrospectivas.

Oh, bom, então você sabe por que sua equipe está falhando, certo? Você teve 36 oportunidades para falar sobre o que funcionou e o que não funcionou; portanto, os mestres do scrum devem entender completamente como resolver os problemas, certo?

Tenho um pressentimento, pela descrição que você dá, de que sua empresa caiu na mentalidade "SCRUM nos torna produtivos". A verdade é que o SCRUM não torna a sua produtividade. Em vez disso, é uma ferramenta para ajudá-lo a tornar- se produtivo de uma maneira que identifique realidades de desenvolvimento que muitas vezes são negligenciadas pela gerência e pelos desenvolvedores.

O que o scrum master identificou como possíveis problemas com a equipe? Eles estão constantemente atribuindo o dobro do trabalho que podem suportar? Nesse caso, o scrum master deve sugerir gentilmente que eles trabalhem menos, porque o scrum master pode observar a velocidade da equipe.

Quando é justo procurar o problema na qualidade dos desenvolvedores?

O momento em que se deve procurar o problema na qualidade dos desenvolvedores é o momento em que você tem certeza de que é o problema. Este não é um novo problema criado pelo SCRUM. Essa é a realidade dos negócios. O SCRUM deve fornecer muito mais informações sobre os recursos dos membros da sua equipe do que as abordagens tradicionais. Você deve saber se o problema é "os desenvolvedores de software não são bons o suficiente" versus "as expectativas de gerenciamento não são realistas" em um grau muito melhor do que você entenderia com uma abordagem tradicional. É a hora de a gerência fazer o que é melhor: descobrir as pessoas certas para o trabalho, para que a empresa possa ganhar dinheiro. Se você não pode dizer onde está o problema, imagine como seria difícil dizer sem todas essas retrospectivas!

Se você acha que as pessoas podem ser boas o suficiente (o que implica que a contratação não foi um erro da parte da gerência), meu conselho seria começar a pensar fora da caixa. Se o trabalho não estiver sendo concluído, considere alterar a forma do trabalho para os desenvolvedores. Uma das maneiras mais fáceis de encontrar para cumprir os prazos de conclusão do sprint é ajustar os critérios CONCLUÍDOS, para que você fique feliz com o resultado, não importa como ele seja feito. Assim, a conclusão se torna uma tautologia.

Isso coloca o ônus no gerenciamento, especialmente no mestre SCRUM. O truque é escrever tarefas que, se concluídas, são muito valiosas, mas, se deixadas incompletas, ainda oferecem valor agregado suficiente à empresa para que valha o salário. Após 18 meses, espero que suas retrospectivas tenham ensinado algo a você. Se não, talvez você deva escrever as histórias com a intenção explícita de histórias falhadas, descobrindo algo que está errado na sua empresa e trazendo à tona. Isso forneceria à empresa imensos dados valiosos, dada a frustração que a empresa parece ter com a equipe de desenvolvimento. O problema pode realmente ser os desenvolvedores, como você pergunta. Ou o problema pode ser uma patologia na mentalidade da empresa que você não tinha ideia até agora!

Se, de fato, o problema é da empresa, não dos desenvolvedores, as informações que você extrai dessas histórias incompletas podem valer mais do que o produto que você coleta das que foram bem-sucedidas! Pode ser a informação que salva toda a sua empresa! Isso parece uma informação realmente valiosa para mim, e você pode usar o SCRUM como uma ferramenta para ajudá-lo a reuni-lo.

"Quando é justo olhar para a qualidade dos desenvolvedores?"

O tempo todo. Obviamente, algumas pessoas são mais produtivas que outras, você não precisa de uma desculpa como empregadora para medir seu desempenho.

O mais complicado é como você faz isso. Meu conselho é contratar alguns contratados experientes para trabalhar ao lado de sua equipe de funcionários perm no mesmo conjunto de tarefas estimado por seus funcionários e para ver se eles têm uma velocidade mais alta.

Isso fornecerá uma boa comparação com o mercado atual sem prendê-lo em um contrato de longo prazo.

Também pode dar um chute no traseiro dos caras do perm.

Além disso, se eles reclamarem que os contratados estão pulando na qualidade etc. para ganhar velocidade, isso levará a uma conversa sobre onde está o valor do negócio. Produtos de manutenção de longo prazo ou produtos de curto prazo enviados.

Se for o material de longo prazo, forçará você a quantificá-lo e colocá-lo no sprint como requisitos!

Já existem várias respostas excelentes. Em particular, estimativas ruins, comprometimento excessivo e / ou trabalho não programado são causas freqüentes de derrapagem.

Mas estou curioso para saber por que "[seus] desenvolvedores escolhem os recursos que desejam incluir em cada sprint". Os desenvolvedores normalmente devem trabalhar nos recursos com a maior prioridade em primeiro lugar - e a prioridade é uma decisão de negócios, ou seja, deve ser proveniente do proprietário do produto, agindo como um proxy para as partes interessadas da empresa.
(Existem exceções. Em particular, os recursos de alto risco geralmente são trabalhados anteriormente. E, em alguns casos, um recurso voltado para o usuário pode depender de outras funcionalidades, por exemplo, "precisamos realmente adicionar um banco de dados antes de podermos implementar o X". )

Por outro lado, as estimativas são decisões técnicas e não devem ser feitas (ou adivinhadas) pelas pessoas de negócios. Você não diz nada sobre isso - eu levantei o ponto apenas porque, na minha experiência, quando os desenvolvedores estão escolhendo no que trabalhar, é bastante comum que as pessoas de negócios tentem ditar quanto tempo deve levar.

Parece que você tem um processo bastante disfuncional. Eu recomendaria não contratar consultores para desenvolvedores, pelo menos por enquanto, porque isso provavelmente terá um efeito negativo no moral. Mas parece que sua organização poderia usar alguma ajuda no lado do gerenciamento de projetos. É aí que eu começaria, contratando um coach ágil experiente - se não fosse para um compromisso de médio a longo prazo, pelo menos para uma avaliação ou "verificação de saúde". Um bom treinador lhe dirá se você tem desenvolvedores com desempenho insatisfatório, mas pelo menos dessa forma, é toda a equipe (não apenas os desenvolvedores) que está sendo analisada.

Outra observação: na minha experiência, é muito difícil fazer com que o scrum seja bem-sucedido como uma metodologia de gerenciamento de projetos, se você também não está seguindo bons processos de desenvolvimento. Você está fazendo testes de unidade automatizados? ou ainda melhor, teste de aceitação automatizado? Seus desenvolvedores estão emparelhados ou pelo menos realiza revisões frequentes de código e / ou orientações? Você está praticando alguma forma de integração contínua?