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.
Muito bom este post!!! Estou realmente muito satisfeito em trabalhar com o SCRUM. Estamos tendo uma visão clara do que alcançar, e satisfeitos com nosso progresso. Conseguimos ver rapidamente onde precisamos melhorar. Com certeza devemos nos preocupar com o bem-estar do time, e não explorá-los! Devemos ter uma cultura de desenvolvimento humano.
Oi Isac, Públio…
O Isac tem razão na conta, mas eu prefiro trabalhar 7 horas por dia mesmo 😉 Na verdade, para o trabalho intelectual, já estou dando um desconto do tempo do cafézinho, pois não dá nem isso por dia (acho que de 2 a seis horas no máximo de trabalho produtivo, segundo o texto).
Quanto aos argumentos do Públio, acho que concordo. Mas o certo é que já sabemos há muito tempo que 40 horas semanais é melhor tempo, em média, para o ser humano trabalhar, das fábricas aos escritórios. Ford usou isso para mudar a relação com o trabalhador. A lei brasileira ainda fala de 44 horas, o que mostra como estamos atrasados. Obviamente, o chefe que não paga horas extras adora "ser feitor" e cobrar essas horas extras dos funcionários, mas o chefe que paga horas extras devia ser mais esperto e contratar mais gente.
No passado, eu já vi "fábricas de software" que eram indiferenciáveis de uma oficina do século passado. Uma amiga minha, que tinha feito todas as tarefas, foi proibida de gastar 10 minutos para tomar um café porque "não estava na hora do intervalo". Espero que hoje isso não exista mais, mas você acabou de me dar um exemplo. Já posso imaginar que a partir desse momento, você acabou suas tarefas sempre as 18:00, não? A principal característica do ser humano é ser adaptável.
Perfeito, mas vai botar isso na cabeça de um gerente de fábrica que tem que gerar produtividade de 40 horas semanais. No Brasil, pelo menos onde trabalhei, ainda se tem a visão distorcida de que quanto mais se cobra mais se tem.
Por exemplo, recentemente, o governo retirou o IPI da linha branca de eletrodomésticos e baixou os dos automóveis. Houve um aquecimento da economia e o governo, invariávelmente, arrecadou mais.
Mesmo percebendo o sucesso, o governo voltou com o imposto. A mesma coisa acontece na fábrica de software e nos departamentos de TI. Os gerentes precisam justificar o custo dos salárias enfiando demanda para equipe de 9 às 18.
Já aconteceu comigo, de eu acabar uma tarefa às 17h, e meu superior querer que eu iniciasse uma tarefa (para interromper às 18h) para não gerar um desconforto político.
O grande problema do Scrum, ao meu ver, é o problema cultural do brasileiro. Scrum pode até funcionar, mas o departamento de TI ou fábrica de software devem ter superiores com cabeça de paraquedas (funciona melhor quando está aberto).
Ótimo artigo, Xexeo!
Só uma coisa, se você trabalhar das 9 às 5, serão 7 horas de trabalho e 1 hora de almoço. Acredito que o correto seria das 9 às 6, não?