Um grande aumento de velocidade é realista em um ambiente Scrum?

Meu gerente recentemente realmente pressionou para usar a velocidade como objetivo e medida de produtividade. Atualmente, estamos trabalhando a uma velocidade média de 50 pontos da história. Meu gerente quer que aumentemos de 40% para 70 pontos da história (sem aumento de membros da equipe). Se não conseguirmos esse aumento, ele quer que façamos uma análise completa do motivo.

Toda a ideia de medir o desempenho da equipe pela velocidade e usá-lo como um alvo me parece errada, mas estou tendo dificuldade em explicar o porquê. Qualquer ajuda? Por que esse não é o caminho certo para medir e incentivar a produtividade?

Bem, é perfeitamente simples aumentar a velocidade em 40% - basta adicionar 40% mais pontos a todas as suas estimativas e fazer a mesma quantidade de trabalho.

Dado que é assim, deve ficar claro por que usar a velocidade como alvo está errado, apenas incentiva estimativas infladas.

Uma resposta menos simplória é que sua estimativa já pressupõe que você está indo o mais rápido possível enquanto faz tudo corretamente. A única maneira de realmente aumentar a produtividade em 40% é trabalhar horas extras ou não fazer tudo corretamente. Ambos aceleram as coisas no curto prazo, mas diminuem as coisas no longo prazo. E o longo prazo, neste caso, não é muito longo, um mês no exterior. A estratégia ideal de longo prazo é nunca ir mais rápido que o seu ritmo sustentável.

O Peopleware fala eloquentemente sobre os problemas de tentar forçar os programadores a aumentar a produtividade e é um clássico frequentemente citado. Mas, em geral, não será fácil mudar de idéia de um gerente que está seguindo o caminho que é seu. Seu projeto pode estar com problemas - isso certamente é uma bandeira vermelha.

Como os comentários apontaram, o pedido está obviamente errado da maneira como foi colocado. Mas ele não está realmente errado em querer melhorar constantemente a produtividade. Como regra, é para isso que os gerentes se esforçam (e são avaliados).

Dito isto, os gerentes estão sempre buscando melhorar o desempenho, e Scrum e Agile têm tudo a ver com serem adaptáveis. Embora a velocidade seja uma medida do seu ritmo atual e sustentável, você não deve se preocupar com os louros. O Scrum tem um lugar para avaliar e alterar o que funciona e o que não funciona no seu processo: a retrospectiva. Se você tirar proveito disso e ajustar seu processo, a produtividade (e possivelmente a velocidade) deverão aumentar.

Então, você está procurando (em suas retrospectivas) maneiras de se tornar mais produtivo como uma equipe? Existe algo em seus sprints que consuma regularmente uma quantidade desproporcional de esforço? Pode ser endereçado? Provavelmente não lhe dará um aumento de 40%, mas 5-10% é um começo, não? Todo sprint deve procurar gargalos e resolvê-los. Eventualmente, você pode se aproximar da meta que ele estabeleceu para você.

TL; DR

O Velocity é muito útil para estimar cronogramas ou gerar valores de planejamento e também pode ser um controle de detetive significativo para avaliar gargalos do processo ou alterações na capacidade da equipe. No entanto, não é uma medida válida de produtividade.

Quando o Velocity está confuso com os objetivos de gerenciamento

"Velocidade" é um intervalo que expressa a capacidade média de uma equipe durante um período histórico. É uma análise estatística do desempenho passado, que pode ser usada para projetar estimativas probabilísticas da capacidade futura da carga de trabalho ou tempos de ciclo. Isso contrasta fortemente com um "objetivo de agendamento", que é um objetivo gerencial que define uma linha do tempo ou uma meta para fins de planejamento.

Gerentes de projeto ágeis experientes sabem que o uso adequado da velocidade é determinar se uma equipe tem capacidade sustentável para atender às metas de agendamento definidas pelo gerenciamento. Às vezes a resposta é sim, e todos estão felizes. Às vezes, a resposta é não, quando o triângulo de ferro força as decisões de negócios sobre escopo, custo, tempo e qualidade.

Avalie suas opções políticas

Temos uma velocidade média de 50 pontos na história ... Me pediram para aumentá-la de 40% para 70 pontos na história (sem aumento de membros da equipe).

Supondo que suas práticas de estimativa sejam sólidas e que sua velocidade seja razoavelmente estável, seu gerente não terá prazer em ajustar a escala de estimativa ou definir metas de gerenciamento que não sejam baseadas no desempenho histórico. Como você apontou corretamente, isso é fundamentalmente um problema de capacidade .

O limite de capacidade pode estar relacionado ao número de pessoas em sua equipe ou pode ser uma limitação de seus processos organizacionais. Obviamente, adicionar mais pessoas nem sempre aumenta a capacidade real do projeto; consulte a Lei de Brooks para obter mais informações sobre esse equívoco comum.

O problema que você enfrenta é político. Pelo tom da sua postagem, parece que seu gerente deseja ver um aumento na produtividade sem fazer nenhuma alteração real na capacidade subjacente da equipe. As soluções são, portanto, também políticas e de natureza amplamente educacional.

Se você é uma loja Scrum, peça ao seu Scrum Master para resolver esse problema através dos canais de estrutura apropriados. Retrospectivas de preparação e sprint da lista de pendências costumam ser as oportunidades ideais de inspeção e adaptação para esse problema em particular.

Se você não é uma loja Scrum, deve decidir qual a maneira correta de abordar suas preocupações na sua organização. Se você estiver em boas relações com seu gerente, pode até emprestar-lhe uma cópia do Agile Estimating and Planning para que vocês discutam durante o almoço.

Se tudo mais falhar, prepare-se para uma marcha da morte retocando seu currículo e fazendo o seu melhor profissional até que o projeto implodir. 68% dos projetos de TI falham ; a menos que as metas de gerenciamento estejam firmemente fundamentadas na capacidade organizacional, a sua provavelmente será uma delas.

Não estou entendendo qual o papel do seu gerente na equipe Scrum? Ele é um treinador? Ele é dono de um produto?

Se ele está dentro da equipe como um treinador ou algo assim (ele trabalha em uma tarefa de desenvolvimento), você pode perguntar por que ele subestima sua própria produtividade, porque parece que não foi o caso de outros membros da equipe. Se ele acredita que pode assumir pessoalmente mais 30 pontos da história a cada iteração, deixe-o mostrá-lo.

Mais provável: ele está fora da equipe, talvez o proprietário do produto? Nesse caso, ele deveria entender fazer um pedido tão estúpido, apenas parou de agilidade.

Uma regra básica é que o proprietário do produto define a meta enquanto a equipe define o que pode ser feito em uma iteração. Não fazer isso leva ao círculo de ferro clássico e bem conhecido: recursos, velocidade, características. Escolhe dois! Você não pode escolher três deles de uma só vez (e lembre-se: a qualidade não é uma variável de ajuste, tentar reduzir custos com baixa qualidade tornará as coisas ainda piores).

Se ele não quiser mudar a meta atual, talvez seja possível alcançar um aumento de 40% na produtividade recrutando mais pessoas para a equipe? Talvez investir em algum treinamento avançado para alguns membros da equipe? As equipes também podem ganhar velocidade ao longo do tempo através da melhoria contínua, mas certamente não por decisão arbitrária.

Tentar mudar a velocidade de uma equipe é como tentar mudar o tamanho de uma sala. Isso pode ser feito, mas basicamente você precisa mudar de quarto.

Você não tem um Scrum Master ou outras pessoas com conhecimentos básicos de Scrum que poderiam explicar isso para ele?

Nesse caso, o gerente mudou de direção após obter uma estimativa honesta e fiel da equipe. O gerente deve recorrer às partes interessadas e informá-las que seus requisitos não podem ser concluídos no tempo solicitado. O gerente / analista deve priorizar quais dos recursos DEVEM ser incluídos e os outros que podem esperar (mesmo que apenas algumas semanas). Se a parte interessada não estiver sendo razoável, pode ser necessário que os gerentes superiores se envolvam, o que geralmente pode ser desafiador e exigir um conjunto de discussões totalmente diferente.

Se eu estivesse no seu lugar eu iria chegar a um caso detalhado a respeito de porque o projeto ESTÁ vai demorar tanto tempo como foi estimada. Tente também identificar itens de baixo retorno. Encontre os itens que não agregam muito valor e exigem esforços substanciais de programação e lembre-se de removê-los do sprint. Crie também uma abordagem iterativa que forneça "X" na data "Y" e verifique se é viável; em seguida, crie uma iteração de acompanhamento que fornecerá os itens restantes.

Basicamente, alguém precisa dizer à parte interessada o que ela espera receber até o prazo final e que isso inclui a maioria de seus requisitos. e que no próximo lançamento eles terão os itens restantes. Se o cliente não é razoável, a gerência superior precisa estar envolvida, o gerente deve poder fazer isso acontecer.

No entanto, se o cliente tiver prometido demais e ninguém falou até agora, será uma batalha difícil. Infelizmente, essa não é uma situação incomum.

Parece que você enfrenta dois problemas.

A parte sobre a medição da velocidade que o incomoda provavelmente é que a medida é o custo . O que você realmente deseja melhorar é o valor . Infelizmente, medir o valor do software é notoriamente difícil e subjetivo. Mesmo assim, mesmo uma métrica imperfeita e subjetiva pode ser útil. Pode ser que o problema real não seja que sua equipe precise escrever mais código, mas que as histórias precisem ser mais valiosas.

A outra questão é que, com base na sua conta, seu gerente esperava um aumento de 40% na produtividade. Não foi declarado na sua pergunta o contexto dessa solicitação. Pode ser um desejo bem-humorado, se bem que desejável, de sua equipe melhorar. Ou pode ser uma indicação não tão sutil que seu gerente acredita que sua equipe está com baixo desempenho.

editar: Com base no seu comentário, a situação parece ruim. Parece que sua empresa está lançando as bases para demitir você e sua equipe (talvez seu gerente também). Eu sugiro que você procure outro emprego.

Demita ele. Ou seja, exagere e explique que ele perdeu toda a confiança de sua equipe e explique que ele não tem valor para os negócios. Explique que os gerentes com esse nível de incompetência são muito mais fáceis de substituir do que a equipe abaixo.

Não há uma boa razão para aturar esse gerente, mas isso não significa automaticamente que os desenvolvedores devem renunciar. Não há necessariamente algo errado com o negócio, apenas com esse indivíduo. Corrija esse problema.

E para impedir qualquer fuga da alta gerência, deixe claro que este não é um erro perdoável. Isso indica que o gerente responsável não entende a equipe que está gerenciando. Isso não se presta à correção, nem é necessário no atual mercado de trabalho. Os gerentes são eminentemente substituíveis, assim como os treinadores esportivos. Proprietários não despedem equipes.

Agora, isso pode parecer uma estratégia que pode sair pela culatra. Mas considere: se a alta gerência estiver do lado do gerente, você já estaria em uma posição perdida. Portanto, se você considerar apenas as situações em que ainda não está nessa posição perdida, o resultado provavelmente será muito mais positivo. O risco real é que a alta gerência apenas despeda toda a equipe, incluindo o gerente. Somente você pode estimar esse risco. Aparentemente, sua produção é desejada, senão eles não pediriam mais, mas a que preço?

Minha experiência é que tem sido muito, muito difícil aumentar a velocidade real de uma equipe, já que nem a equipe, o domínio do problema ou a pilha de tecnologia mudam.

Onde eu pude obter aumentos, é uma questão de:

• limpar dívidas técnicas; garantir que tudo esteja executando a versão correta (não necessariamente a mais recente!), que o código seja bem fatorado e que não haja redundância no sistema (código duplicado, código não utilizado etc.)

• melhorar práticas; emparelhar sempre que possível (sim, descobri que aumenta a velocidade), dedicar um tempo para refatorar agressivamente (idem!) e ser implacável quanto ao escopo e ao foco

• encontrar e / ou comprar as melhores ferramentas para o trabalho (por exemplo, o ReSharper for .NET vale seu peso em ouro, Airbrake e Splunk para desenvolvimento em Ruby, etc.)

Concordo com outras pessoas aqui que dizem que seu gerente solicitando um aumento arbitrário na velocidade é uma bandeira vermelha. Eu estaria procurando outro emprego como alta prioridade.

Seu gerente está pedindo (ou informando) que sua equipe trabalhe horas extras. Embora remover gargalos e obter ganhos de eficiência possa melhorar um pouco sua velocidade, a única maneira de obter esse aumento (40%) é trabalhando mais horas, pois você precisa colocar mais unidades de trabalho nesse período.

Vamos dar uma olhada.

Por uma interação de duas semanas, digamos 10 dias. A utopia seria de 8 horas por dia, com um argumento sendo abstraído para um dia de trabalho. Então, de cima, sua velcoidade seria 8. Mas, relisticamente, as pessoas provavelmente estão recebendo 6 boas horas por dia com e-mail, reuniões, intervalos para ir ao banheiro etc. Então, agora você está com 6 por desenvolvedor. Portanto, sua linha de base é 6. Digamos que você queira que as pessoas trabalhem horas extras, agora lá 10 horas por dia. Então, isso seria 10 pontos de velocidade por desenvolvedor.

Sua velocidade sempre flutua, talvez tenha sido baixa porque você teve que lidar com muitos bugs durante essa iteração, talvez os requisitos estivessem ausentes, talvez alguém adoecesse por alguns dias. Talvez tenha sido alto porque o trabalho foi superestimado ou sua equipe passou horas extras.

Mas se você estiver em 50 estáveis, realmente chegar a 70 exigirá horas extras.

O problema com a velocidade é que é uma variável dependente, uma saída medida do seu processo de desenvolvimento. Exigir aumentar a velocidade em 40% é como tentar trabalhar mais cedo, gritando para os carros irem mais rápido. A velocidade aumenta alimentando mais combustível e ar no motor ou adquirindo um carro mais rápido, além de encontrar uma rota com menos tráfego.

Trabalhar mais horas não aumenta a velocidade se você a medir adequadamente, digamos em pontos de recurso por desenvolvedor-hora. Só funciona se você medir pontos por dia e depois redefinir o que é um "dia" no meio da medição. Isso fornece apenas a ilusão de velocidade.

Um aumento na velocidade requer a melhoria das variáveis ​​independentes no processo dev; computadores e compiladores mais rápidos, sistema de compilação mais eficiente, melhor processo de design, desenvolvedores mais capazes, melhor espaço de trabalho, motivação para supervisor. Uma melhoria de 40% exigiria mudanças muito significativas.

Pergunte se o seu gerente consideraria co-localizar sua equipe em escritórios fechados em torno de uma sala de trabalho comum, comprar equipamentos novos para desenvolvedores ou contratar alguns desenvolvedores realmente seniores para orientar a equipe, se isso lhe desse 40%. Se não houver recursos disponíveis para melhorar as entradas do seu processo de desenvolvimento, isso praticamente exclui o interesse sincero em melhorar. Isso deixa a engenharia reversa do seu gerente para descobrir o que realmente o está motivando, o que seria o assunto de toda uma discussão.

Bem, estou um pouco surpreso que as outras respostas levem o pedido do chefe a sério. Alguém que exige um aumento de 40% na produtividade não sabe a primeira coisa sobre desenvolvimento de software.

Ainda gosto de ler Phil Factor sobre este tópico:

Existem duas rotas básicas para o gerenciamento de TI. Você pode aprender seu ofício com sangue, suor e lágrimas e subir a escada gradualmente, com base na credibilidade que você ganhou com o know-how técnico e os projetos bem-sucedidos. Como alternativa, você pode vestir um terno e gravata afiados, aprender a linguagem e conversar suavemente até o topo.

Ambas as rotas parecem igualmente eficazes. Lidar com a última raça certamente pode causar alguns momentos de desânimo e incredulidade ... até desespero ... e parte disso está documentada nessas histórias.

No entanto, é fácil ficar triste e amargurado quando se encontra incompetência técnica em posições de poder e atribuir a todos os gerentes o mesmo poder. Phil desaconselha. A maioria dos gerentes trabalha duro e contribui bem para a empresa, e mesmo os gerentes ruins podem ser treinados até o padrão exigido, se você seguir apenas algumas orientações simples. Faz parte da responsabilidade da sua equipe ajudar seu gerente a funcionar de uma maneira que traga benefícios a todos.

Por fim, se você não pode treiná-los, promovê-los ou evitá-los, talvez possa aprender a amá-los apenas por sua contribuição não intencional à rica comédia do local de trabalho.

O conselho para não ficar "triste e amargurado" é o melhor que você pode obter. Não lute contra um chefe tecnicamente incompetente por questões técnicas. Ele verá isso como um ataque pessoal.

Seu gerente não entendeu o uso da velocidade. Não é uma métrica e não é um destino. Seu objetivo é a calibração da carga de trabalho da equipe por sprint.
Se você pensar bem, sua velocidade surge de uma melhor estimativa, que você mede após cada corrida. Geralmente, à medida que o tempo avança, ele deve se tornar um pouco estável. Mas isso não muda o fato de ser um subproduto do que sua equipe está realmente fazendo: criando valor para seus clientes.

A razão pela qual é errado usá-lo como destino e / ou métrica é porque isso a tornaria uma métrica básica. Ficaria bom no papel, mas não faria absolutamente nada para refletir se seus produtos estão ou não satisfazendo as necessidades de seus clientes. E é isso que é mais importante (espero).

Quanto à minha experiência e ir direto ao ponto.

Primeiro, você pode aumentar a estimativa, mas isso não significa que você está fazendo mais.

Segundo (premissa: sem inflar, apenas focando na velocidade da equipe),

Tente encontrar as habilidades dentro de sua equipe. Eles estão trabalhando no que são melhores? Você precisa de um arquiteto de sistemas para tomar decisões difíceis em relação à construção do aplicativo e coisas complexas? Como a equipe está gastando seus esforços? Eles estão gastando tempo pesquisando soluções para seus problemas, refatorando, tomando decisões de negócios ou o quê?

Eles são confortáveis, focados e estimulados? O que vem a seguir para eles?

Isso não é "sou empurrado para os limites" ... é mais como uma pergunta para toda a equipe "estamos nos limites?" e "Como podemos empurrar os limites?" ...

Tenho líderes de equipes de alto desempenho (para primeiras construções e / ou migrações) ... a motivação da equipe é a chave do sucesso ... e planejar como seria a base do aplicativo é essencial. Às vezes, eu ou um colega de chá assumimos o papel de arquiteto de sistemas e decido como e para onde a "coisa" deve ir.

Às vezes, quando vejo que meus colegas de chá estão perdendo eficiência, tento quebrar e convido-os a sair para tomar uma cerveja ou algo do que gostam. Isso resolve todos os conflitos e, no dia seguinte, eles voltam a se concentrar.

VENDENDO ...

Se explique os motivos pelos quais você não pode aumentar a velocidade, use o ROI.

O Scrum se concentra no que é mais importante para o cliente. Teoricamente, as tarefas mais lucrativas.

Se o seu problema é vender o esforço de desenvolvimento, o que você acha que vender, qual é o ROI do esforço de desenvolvimento, converte diretamente os pontos da história no "preço". Se você pode provar que sua equipe trabalha com um ROI alto, quem vai questionar você? Além disso, toda equipe tem limites se a equipe encontrou seu "tamanho de conforto", tente um aumento mês a mês, se não puderem concluir todas as tarefas, esse é (provavelmente) o limite.

Mostre o histórico das tarefas, a receita de lucro (se disponível), o argumento utilizado e mostre que PRODUTIVIDADE NÃO É O ESFORÇO DA EQUIPE é um cálculo determinado pela equipe para avaliar a complexidade e talvez o tempo para obter algo feito