Image: renjith krishnan / FreeDigitalPhotos.net http://www.freedigitalphotos.net/images/view_photog.php?photogid=721

O oitavo princípio do Manifesto Ágil é: “Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente”.  Eu explico em uma espécie de “tradução livre” do original em inglês para: “Em processos ágeis, trabalhamos de 9 às 5, de segunda a sexta”. Por que essa interpretação?

Em um artigo destinado a indústria de jogos, Evan Robinson nos ensina que trabalhar mais do que 40 horas por semana só aumenta os nossos custos e diminui a qualidade do trabalho produzido. Programadores cansados programam mal. Sem falar, é claro, da diminuição da qualidade de vida do time. Ele ainda nos mostra que, depois de certo tempo, passamos a produzir negativamente. Estudos sobre o assunto, sempre apontando nessa direção, começaram no início do século XX. A indústria de software realmente leva tempo para aprender.

Minha experiência como professor e consultor, observando o que acontece ao meu redor,  mostra que muitos profissionais estão envolvidos em projetos longos, atrasados e trabalhando horas extras para “recuperar o tempo perdido”. Já cheguei a ter alunos saindo de uma aula às 10 horas da noite, depois de trabalhar um dia todo, para voltar às suas empresas e continuar programando.

Uma das principais lições que o Scrum nos dá ao longo do projeto é conhecer o ritmo do time. Sprint após Sprint o time estima e tenta executar o que estimou. Ele percebe quando trabalhou demais ou trabalhou de menos, estimou com a “mão pesada” ou com “demasiado otimismo”. E, como as Sprints são pequenas, ele tem um feedback imediato, o que permite a correção do rumo. Além disso, a estrutura de reuniões de Planejamento, Retrospectiva e Scrum diário faz com que a estimativa esteja em constante discussão, causando um efeito emergente de alinhar a maneira de pensar de todos os membros.

Feedback é a palavra chave. Ciclos curtos fazem com que os seres humanos percebam os efeitos das suas previsões e decisões. Se você errar uma decisão tomada a um ano atrás, nem vai se lembrar que foi você que a tomou. Duas semanas atrás, você ainda se lembra dos motivos, mesmo que não os tenha anotado.

A Sprint pequena, aliás, é um fator importantíssimo para criar um ritmo sustentável. Imaginando que a equipe erre na sua previsão para menos, o maior custo que ela vai ter em uma Sprint de 2 semanas será de um a três dias de “trabalho forçado”. E isso será imediatamente corrigido na Sprint seguinte, permitindo até que seja dada alguma folga para compensar o esforço. Lembremo-nos: quando a equipe se cansa, é o software que fica quebrado.

Agora, tudo isso só vai dar certo se o Scrum for adotado plenamente por todos, inclusive pelo Product Owner. Podemos imaginar um PO ver muitos pontos entregues e não perceber que pediu demais da equipe. Até mesmo posso ver esse PO dizendo que a equipe trabalhou “por que estava motivada” ou ainda “por que esse é o comprometimento que o Scrum define” e esquecer que, motivada ou não, ela ficou cansada. Motivada em uma Sprint, revoltada no seguinte é o padrão que podemos esperar.

Para quem sobra resolver esse problema? Acertou quem disse: o Scrum Master. Muitas vezes vemos o Scrum Master como um bombeiro, pronto para apagar incêndios, ou seja, remover impedimentos, mas deve ficar claro: o Scrum Master é principalmente um gerente de riscos. Ele deve agir de maneira pró-ativa em relação aos impedimentos, prevendo-os antes que eles aconteçam.

Cabe ao Scrum Master levar time e Product Owner ao ritmo sustentável. Isso envolve mediar o relacionamento entre time e PO, estar atento aos sinais de fadiga, carga excessiva ou pequena demais.  A diferença entre o Scrum Master e o “gerente normal” é que o último normalmente tenta levar o time à produtividade planejada enquanto o primeiro ajuda o time a achar a sua produtividade e melhorá-la continuamente. A busca por uma produtividade planejada, provavelmente sem nenhuma base real para previsão, exige horas extras para acabar o serviço e pode resultar nas  famosas “marchas da morte”, projetos onde todos saem acabados e até mesmo doentes. A descoberta e melhoria contínua da produtividade, ao contrário, cria no time uma sensação de orgulho e satisfação do dever feito.

Trabalho saudável é outra forma de ler "ritmo sustentável". Trabalhar faz bem a mente, mas descansar é um complemento indispensável. De 9 às 5 temos a produtividade máxima. Devemos, então, manter esse objetivo dentro de nossas "normas" de execução do Scrum.