Em desenvolvimento ágil, é muito comum as equipes estabelecerem uma espécie de "comprometimento de sangue" com seus clientes em se entregar tudo que foi planejado no início de uma iteração. Pode haver muita boa vontade nisso, mas certamente é uma prática pouco eficiente. Mas porquê é ruim criar um compromisso para entregar o que foi planejado? Quando um compromisso é estabelecido, não cumpri-lo pode resultar em frustração tanto do cliente quando da equipe e de sua liderança. O que ocorre na prática é que não há garantia de que os requisitos planejados no início de uma iteração realmente poderão ser concluídos até o seu final.
Se a liderança do projeto, ou o cliente, estabelecerem uma relação de cobrança para com a equipe no que diz respeito a entrega ao fim de uma iteração dos requisitos planejados e acordados no seu início, fatores indesejáveis poderão atuar negativamente no processo, entre eles: (1) o aumento de trabalho over-time e do stress no dia-a-dia de trabalho; (2) a equipe começa a super-estimar as features com medo de assumir compromissos irreais (3) a qualidade pode começar a ser sacrificada; (3) relaxamento na execução das práticas e (4) em um atraso iminente, a equipe começa a evitar o acionamento do cliente para obtenção de feedback (pois isso pode significar mais trabalho para ser entregue no mesmo tempo).
O que fazer então? Sem metas rígidas, como gerar ritmo e obter alguma previsibilidade no projeto? O segredo é não tentar impor controle sobre o processo, mas estudá-lo e observá-lo com o intuito de se ganhar a capacidade de aperfeiçoá-lo sistemicamente. O objetivo é conquistar (e não controlar) o ritmo e a previsibilidade desejada. Se as metas de implementações para a iteração continuamente não são alcançadas, pode ser que:
- As metas estão sendo mal-definidas (consciente ou inconscientemente). Normalmente devido ao desconhecimento da capacidade real de produção da equipe. Às vezes tenta-se impor metas mais arrojadas para tentar puxar o ritmo da equipe, mas o resultado acaba sendo pior;
- Os requisitos foram insuficientemente explorados durante a reunião de planejamento. Apesar de não ser uma boa prática detalhar em excesso o que será desenvolvido, é importante conhecer o suficiente sobre o que será desenvolvido, de modo a diminuir a margem de erro nas estimativas. Isso pode ocorrer quando as reuniões de planejamento são rápidas de mais ou muito superficiais;
- Eventos não planejados (veja "variações especiais" mais a frente no texto) ocorreram durante a iteração diminuindo a capacidade de produção da equipe.
Em todos os 3 casos, a culpa não é da equipe. Não adiantará, portanto, pressioná-la ou influenciá-la para produzir mais. Todo o projeto é um sistema. Sistemas que produzem abaixo do esperado, o fazem devido a causas sistêmicas, não pela existência de um ou mais "culpados". Todo o sistema tem um rendimento e esse rendimento, segundo Deming, sofrerá de variações causadas por causas comuns ou por causas especiais. Especialmente quando falamos em projetos de software, há variações inerentes ao sistema e há variações especiais que tornam seu rendimento imprevisível, mas controlável. O ato de medir esse rendimento continuamente gera o controle estatístico necessário para nos dar a condição de prever resultados com muito mais acuracidade do que os planejamentos adivinhatórios e impositivos que estamos acostumados a ver. Assim, as expectativas devem ser trabalhadas com base em medições e não com base em compromissos irreais.
Durante o estudo e a observação do sistema da qual faz parte o projeto, será possível detectar variações especiais, removê-las e, assim, otimizar seu rendimento. Quando todas as variações especiais forem removidas, o sistema poderá ser otimizado como um todo e, aí sim, haverá uma melhoria substancial na sua capacidade de avançar com mais velocidade, mantendo o alto nível de qualidade desejado. Um projeto observado e aperfeiçoado com uma visão sistêmica pode oferecer muito mais controle e previsibilidade do que um projeto gerenciado com metas impostas de cima para baixo.