Um atraso, em geral, é quando se tem algo pronto depois do planejado, ocasionando um inconveniente desconforto. Em outro ponto de vista, pode-se ver um atraso como apenas um desperdício. Em um projeto ágil, um atraso resulta em descontinuidade, além de ocasionar outros tipos de desperdício como necessidade de reaprendizagem, mudança de contexto de tarefas, etc.
Jack Milunsky, atribuiu alguns atrasos comuns a
- Aprovações de projeto - deixar os desenvolvedores sentados, aguardando aprovação sobre algo no projeto inevitavelmente leva a desperdícios de tempo e de dinheiro.
- Espera por uma priorização adequada da lista de requisitos - para que só assim o trabalho possa começar.
- Aguardar até que dados recursos estejam disponíveis – isto normalmente demonstra necessidade de reflexão sobre se a organização não está assumindo muito trabalho.
- Mudanças no processo de aprovação – isso em si já é um processo de desperdício. Se isso acontece muito frequentemente, então pode ser mais fácil reduzir o tamanho do sprint.
- Aumento na quantidade de trabalho em andamento - quanto mais trabalho em andamento, há mais desenvolvedores tendo de aguardar para ver seus códigos em produção.
- Atrasos de clientes precisando assinar testes de aceitação – isto é verdade não apenas para assinatura, mas também para ter o cliente disponível para esclarecer questões quanto aos requisitos, dar feedback sobre demonstrações, etc.
Jack mencionou que também há muitos atrasos entre os sprints. A equipe deve identificar e erradicar os atrasos com algum trabalho pesado. Ele sugere,
Você tem que garantir que o backlog esteja devidamente preparado. Então, você precisa de um PO efetivo que entenda o mercado, o cliente, etc. Você precisa escrever histórias bem escritas. Você precisa estimar junto aos desenvolvedores o quanto antes, para que o PO possa tomar decisões para além da reunião de planejamento. É tudo uma questão de se projetar os atrasos para fora do sistema buscando-se suavizar os pontos de transição. E vale a pena mapear este processo fim-a-fim para identificar os atrasos em cada um desses pontos.
Interessante notar as principais causas de atrasos em projetos de TI mencionadas por Wouter Baars. Às quais incluem,
- Gold Plating – quanto uma equipe gasta muito tempo melhorando uma funcionalidade que não foi requisitada pelo cliente.
- Negligenciar o controle de qualidade - algumas vezes, a pressão do tempo pode fazer com que os programadores ou as equipes do projeto sejam tentados a pular os testes. Isto quase sempre causa mais atrasos do que evita.
- Trabalhar em muitos projetos ao mesmo tempo – mudanças de contexto de tarefas leva a mais problemas do que soluções
- A síndrome da ‘solução que resolve tudo’ – tentar ajustar uma solução existente a qualquer novo problema.
- Pessoas medíocres – insuficiência técnica ou de processo causa atrasos em vários níveis.
- Clientes que falham em cumprir acordos - quando clientes não se programam para dar retorno em questões às quais estão envolvidos, os projetos ficam propensos ao colapso.
- Tensão entre clientes e desenvolvedores - se o projeto não está transcorrendo bem o suficiente, a tensão pode causar atrasos adicionais. Isso perturba o sentimento de confiança e o ambiente de trabalho.
Outro interessante motivo para atrasos foi sugerido por Robert Neri quando ele apontou que o impacto da adoção de Agile numa organização também pode ocasionar atrasos. Diz ele que,
Uma das coisas que quase sempre encontramos é que as organizações de Suporte não podem se mover tão rápido quando os sprints do projeto, e assim tendem a atrasas os projetos ágeis. Semelhantemente, projetos não-ágeis têm períodos de dificuldade quando lidam com integrações com projetos ágeis.
Então, se seu projeto ágil está atrasando, tente mapear as razões para uma dessas causas comuns de atrasos. Uma vez que você tenha identificado a causa raiz, deve ser mais fácil começar um trabalho para resolvê-la imediatamente. Isto deve reduzir uma das maiores fontes de desperdício no projeto.