O livro descreve a criação do Scrum, um método de trabalho para produção de software com alta produtividade, em 1993. E de como ele evoluiu para outras áreas em que a gestão de projetos podia trazer benefícios, tanto na indústria quanto na oferta de serviços.

Para esclarecer os pontos importantes, o criador do Scrum descreve vários casos de sucesso em empresas e em organizações de governo e não governamentais em que usou o novo modo de trabalhar, mas cita também casos que geraram algum aprendizado.

Ele começou com o chamado “Manifesto Ágil”, no qual declarou os seguintes valores: indivíduos em vez de processos; produtos que de fato funcionem em vez de documentação dizendo como deveriam funcionar; colaboração com o cliente em vez de negociação com ele; e responder às mudanças em vez de seguir um plano. Ele afirma que o Scrum é uma estrutura para pôr em prática esses valores, e não uma metodologia.

Para a criação ele usou o aprendizado que teve na Força Aérea, fundamentado em quatro pontos: Observar, Orientar, Decidir e Agir. Sendo mais específico: observar a região-alvo, planejar o melhor caminho para entrar na zona de ataque e a melhor rota de fuga e, por fim, agir de forma decisiva com base nos instintos e no treinamento recebido.

Um dos testes que aplica para verificar se um grupo trabalhando com o Scrum está no caminho certo é perguntar, digamos, a um analista de redes: “Você faz parte de qual equipe?” Se a resposta mencionar o produto em que está trabalhando (por exemplo, automação ou integração), em vez da sua especialidade (engenharia de redes), ele é aprovado. Quando um especialista se identifica com sua especialidade, mais do que com o produto que está desenvolvendo, ele sabe que ainda há trabalho pela frente.

Ao fim de cada dia, o Scrum Master, encarregado do comando do processo, faz uma reunião de avaliação com as seguintes perguntas a cada integrante:

1. O que você fez ontem para ajudar a equipe a concluir o sprint?

2. O que você fará hoje para ajudar a equipe a concluir o sprint?

3. Quais obstáculos estão atrapalhando a equipe?

E só. A reunião se resume a isso. Se ela demorar mais de quinze minutos, está sendo realizada de modo errado. O objetivo é fazer com que toda a equipe saiba exatamente como tudo está se desenrolando no sprint.

E para a poiar a regra de que todos têm de participar ativamente, as reuniões são em pé.

Seguem alguns trechos esclarecedores:

O primeiro passo quando se está implementando o Scrum é criar uma lista de tarefas, que também podemos chamar de backlog.

Não é só porque a multifuncionalidade pode gerar ótimos resultados que você deve bancar o Noé e pegar dois indivíduos de cada área para a sua equipe. Essa dinâmica só funciona bem em grupos pequenos. Os dados mostram que, se mais de nove pessoas são incluídas em uma equipe, a velocidade diminui.

Toda quinta-feira, eles se reúnem e olham para a imensa lista de coisas a fazer, desde montar um protótipo de um novo painel até testar as lanternas de seta [de um novo modelo de carro]. A lista é ordenada de acordo com o nível de prioridade das tarefas, então o grupo diz: “Certo, levando em conta a lista, quantos desses itens podemos fazer esta semana?” Com “fazer” eles querem dizer “terminar” – finalizar o item.

Um elemento crucial de um sprint é que, assim que a equipe se compromete com aquilo que realizará, as tarefas sejam fixas. Nada mais pode ser acrescentado por alguém de fora da equipe.

O quadro é dividido em algumas colunas: “A fazer”, “Fazendo” e “Feito”. A cada sprint, a equipe da empresa põe na coluna “A fazer” a maior quantidade possível de post-its que eles acreditam que conseguirão realizar naquela semana. Conforme os dias passam, um integrante da equipe pega uma dessas tarefas e a passa para a coluna “Fazendo”. Quando a atividade é finalizada, ela é movida para a coluna “Feito”. Todos os membros da equipe podem ver no que os outros estão trabalhando em determinado momento.

Para que passe para a coluna “Feito”, o produto precisa estar completo, pronto para ser utilizado pelo cliente.

A essência do Scrum é o ritmo.

Uma das principais coisas que fazíamos com cada post-it era escrever não só o que precisava ser criado, mas também como saberíamos quando aquilo estivesse pronto.

Existem apenas três funções no Scrum. Ou você é parte da equipe e realiza o trabalho, ou é um Scrum Master e ajuda a equipe a determinar como realizar o trabalho de uma maneira melhor, ou você é um Product Owner, que se relaciona intimamente com o cliente e ajuda a definir as prioridades na execução.

Quando receberem o seu produto, o seu serviço ou uma mudança em suas vidas, as pessoas vão informar quais são os próximos itens mais valiosos. Em seguida, desenvolva 20% deles e entregue de novo. E de novo.

O “Bobo Sábio” é a pessoa que faz perguntas desconfortáveis ou traz à tona verdades desagradáveis. Nem sempre é fácil conviver com esses indivíduos, pois podem ser considerados causadores de problemas ou os outros podem pensar que eles não se integram à equipe, mas esse tipo de pessoa precisa ser cultivado e utilizado.

Não busque as pessoas ruins; procure os sistemas ruins que as recompensam por agir dessa maneira.

Um mantra do Scrum é “se cometer um erro – e todo mundo os comete –, corrija-o no momento em que ele for detectado”, que ele justifica afirmando que a “Perda causada pela mudança de contexto” é puro desperdício e que “se você tem cinco projetos, 75% do seu trabalho vai para o lixo”.

Para enfatizar a importância de focar um trabalho por vez, recomendada pelo Scrum, ele cita “O psiquiatra Glenn Wilson selecionou quatro homens e quatro mulheres e testou o QI deles em condições tranquilas e em situações de distração (telefones tocando, e-mails chegando). Durante os testes, ele mediu a condutância da pele, os batimentos cardíacos e a pressão arterial dos participantes. Curiosamente, o QI médio dessas pessoas caiu mais de dez pontos quando elas foram postas em ambientes que as distraíam. Um dado ainda mais interessante é que a queda foi maior nos homens do que nas mulheres. (Talvez, por algum motivo, as mulheres sejam mais habituadas à distração)”.

Nota pessoal: O resultado não me surpreende. A histórica responsabilidade das mulheres com a casa e com as crianças fez com que elas sejam mais bem equipadas para a multitarefa que os homens, embora também percam alguma eficiência com isso.

Criticando a abordagem tradicional de gestão de projetos, com Diagramas de Gantt etc., ele afirma: “o planejamento em si se torna mais importante do que o plano. E o plano se torna mais importante do que a realidade. Nunca se esqueça disto: o mapa não é o terreno.

Os seres humanos são péssimos em fazer estimativas de quanto trabalho algo vai dar. Então ele sugere uma interessante técnica de dimensionamento relativo, ou seja, comparar as tarefas umas com as outras dando um número como: 1, 2, 3, 5, 8, 13. Cada número da série é a soma dos dois anteriores. Ele acredita que o uso desses números, conhecidos como “sequência de Fibonacci” é vantajoso sobre alternativas. Operacionalmente, ele recomenda a seguinte técnica para estimar os esforços para execução: 

“Cada pessoa tem um baralho de cartas com estes interessantíssimos números de Fibonacci: 1, 2, 3, 5, 8, 13 etc. Escolhe-se uma tarefa por vez para ser avaliada. Então, cada integrante do grupo separa a carta que considera corresponder à quantidade de esforço exigida por aquela tarefa e a coloca virada para baixo na mesa. Em seguida, todo mundo vira sua carta ao mesmo tempo. Se as opiniões de todos estiverem a uma distância de até duas cartas umas das outras (digamos, há um 5, dois 8 e um 13), a equipe apenas soma esses números, tira a média (neste caso 6,6) e passa para o próximo item. Lembre-se de que estamos falando de estimativas, não de cronogramas rígidos. Além disso, trata-se de previsões. Esse método incrivelmente simples evita qualquer tipo de comportamento de ancoragem, como o efeito de contágio ou o efeito halo, e permite que toda a equipe compartilhe seus conhecimentos a respeito de determinada tarefa. No entanto, é fundamental que as previsões sejam feitas pelo grupo que executará o trabalho.

O autor oferece uma explicação interessante para o PDCA:

“Taiichi Ohno, da Toyota, disse: “O desperdício é mais um crime contra a sociedade do que uma perda nos negócios.” Ele usou as seguintes palavras em japonês: Muri, o desperdício causado pela irracionalidade; Mura, o desperdício causado pela inconsistência; e Muda, o desperdício causado pelos resultados. Essas ideias se alinham com o ciclo PDCA de Deming: Plan [planejar], Do [fazer], Check [verificar], Act [agir]. Planejar significa evitar o Muri. Fazer significa evitar o Mura. Verificar significa evitar o Muda. E Agir se refere ao ímpeto, à motivação e à determinação de fazer tudo isso”. p. 88 de 268.

E faz uso de algumas citações:

“As pessoas não realizam multitarefas porque são boas nisso. Elas o fazem porque são mais distraídas. Têm dificuldade para inibir o impulso de se dedicar a outra atividade.” – David Sanbonmatsu

“Aquele que defende tudo acaba não defendendo nada.” – Frederico II da Prússia (Frederico, o Grande)

Tal Ben-Shahar, professor que ministrava a disciplina mais popular na Universidade Harvard, chamada psicologia positiva, escreve em seu livro Seja mais feliz: “Nós não somos recompensados por desfrutar a jornada em si, mas pela conclusão bem-sucedida de uma jornada. A sociedade recompensa resultados, não processos; chegadas, não viagens.”

Em resumo

É uma leitura interessante – embora um pouco repetitiva – e útil para pessoas envolvidas em projetos de qualquer natureza.

Livro lido em dez/22.