A arte da eficiência

*Por Alexandre Nishikawa

“Ninguém deveria passar a vida fazendo um trabalho sem significado. Isso não é ruim apenas para os negócios, mas também destrói a alma das pessoas.” Essa frase resume bem um dos propósitos do livro mais recente do cocriador do Scrum, Jeff Sutherland, Scrum: a arte de fazer o dobro do trabalho na metade do tempo. Ela explica por que esse método existe em primeiro lugar, e serve como base para implantá-lo em sua organização. O livro está organizado em três seções – as origens do Scrum, discussões sobre os principais elementos que o fazem funcionar, e, por fim, por que as coisas precisam mudar não só nos negócios, mas também no mundo inteiro.

É interessante notar que uma das primeiras inspirações para o Scrum veio da pesquisa de Rodney Brooks no MIT, que envolvia a criação de robôs autônomos de seis pernas. Em sua pesquisa, o Dr. Brooks não desenvolveu  um único cérebro para coordenar o movimento das pernas do robô. Em vez disso, sua equipe e ele incorporaram regras simples em cada perna, de modo que esses robôs tinham que aprender a andar pelo prédio por tentativa e erro.

No início, quando o robô era ligado, cada perna tentava independentemente fazer o que achava melhor, e o resultado era que o robô não conseguia sair do lugar.

Com o tempo, as pernas aprenderam a coordenar seus movimentos e, paulatinamente, passaram a agir como uma única unidade. Essa observação levou à pergunta que motivou a concepção do Scrum: “O que aconteceria se criássemos um conjunto de instruções simples para que as pessoas trabalhassem juntas em equipe, exatamente como essas pernas? Elas se auto-organizariam, otimizando seus resultados da mesma forma que esse robô.”

Ao ler essa história, percebi que o Scrum é muito parecido com os robôs de seis pernas aprendendo a andar. Por design, o Scrum não possui uma estrutura para torná-lo escalável, pois suas regras básicas de dimensionamento estão incorporadas dentro da própria metodologia: as equipes são autônomas e empoderadas, agregando valor a cada Sprint (No Scrum, os projetos são divididos em ciclos, tipicamente mensais, chamados de Sprints), buscando continuamente formas de melhorar.

Através de um processo paulatino de inspeção e adaptação, várias equipes Scrum aprendem a coordenar suas ações, melhorando o desempenho da equipe como um todo, e não só dos membros que a compõem, individualmente. Nenhum gestor é necessário para direcionar o processo, apenas um árbitro para lembrar as partes individuais o que aprenderam coletivamente.

Então, por que grandes projetos geralmente dependem de um único gestor para direcionar tudo? Segundo Sutherland, os gestores não confiam nas equipes que estão fazendo o trabalho e pensam que dirigir tudo desde um ponto central é mais eficiente.

Mas, qual é a definição de “equipe” no Scrum? Jeff compartilha a resposta presente no artigo original de Takeuchi e Nonaka, “O novo jogo de desenvolvimento de produtos”. Segundo a pesquisa de Takeuchi e Nonaka, as melhores equipes de produtos são transcendentes (um senso de propósito além do comum), autônomas (auto-organizáveis, auto-gerenciadas e com poder de decisão) e multifuncionais (possuem todas as habilidades necessárias para concluir o projeto).

Então, como se cria uma equipe Scrum? As equipes são multifuncionais, recebem uma visão audaciosa do projeto, além de tempo e espaço para se auto-organizarem em torno da solução. Através de vários testes práticos e pesquisas, Sutherland prova que o método Scrum tem potencial para multiplicar o desempenho das equipes.

Ele cita, por exemplo, que na indústria de software há uma diferença de 10:1 na produtividade entre os melhores colaboradores e os piores. E, pior, que na indústria em geral, há uma diferença de 2000:1 na produtividade entre as melhores equipes e as piores equipes! E o que explica tamanha diferença de produtividade? Um sistema falho que insiste que os funcionários façam um trabalho sem sentido, orientado centralmente.

Mas o que explica o sucesso do Scrum? Muitos livros de negócios/gestão falam sobre produtos, planejamento, marketing, vendas, estimativas, storytelling; poucos, todavia, discutem um tema importante: a felicidade. Tirando Delivering Happiness da Zappos, este é o primeiro livro que afirma que uma equipe deve focar na felicidade. Por quê? Porque a felicidade precede resultados importantes e é um indicador de sucesso, em qualquer esfera da vida de um indivíduo. Em sua própria empresa, Jeff observou a produtividade triplicar, concentrando-se simplesmente em melhorar a felicidade de sua equipe. Jeff considerou essa métrica de felicidade um dos principais indicadores de aumento (ou redução) da produtividade. Estas são as quatro perguntas que Jeff faz em seus feedbacks:

• Em uma escala de 1 a 5, como você se sente em relação ao seu papel na empresa?
• Nessa mesma escala, como você se sente em relação à empresa como um todo?
• Por que você se sente assim?
• O que faria com que ficasse mais feliz no próximo Sprint?

Apesar de abominar o tradicional planejamento “em cascata”, onde temos diversas fases de projeto e uma sequência linear e imutável, Sutherland não desdenha completamente os tópicos de estimativa e planejamento, e explica como a metodologia Scrum aborda esses tópicos. Por exemplo, exemplifica as histórias do usuário, estimativas relativas, pôquer do planejamento, velocidade e outros conceitos relacionados. O que mais me chamou nessa discussão foi a história sobre a necessidade de enfrentar a realidade de um projeto que poderia prejudicar uma empresa:

O CEO de uma empresa de capital aberto deixou sua empresa em apuros ao propor uma meta audaciosa que, se não fosse cumprida, impactaria diretamente o preço das ações da empresa, permitindo a entrada de concorrentes no mercado. Uma das metas era que a conclusão do projeto não poderia, de maneira alguma, ser adiada: logo, a execução teria que ser perfeita.

Infelizmente, quando Jeff foi chamado para organizar o projeto, essa empresa já tinha desperdiçado seis meses de tempo precioso “planejando”, e ele percebeu que atrasariam a entrega em mais de um ano. Além da complexidade do projeto, seu desenvolvimento estava dividido entre sete grupos distintos, cada qual responsável por uma parte do sistema – sistema esse extremamente intricado que precisava funcionar perfeitamente.

Como todo projeto multimilionário, havia um documento de requisitos com milhares de páginas, e quase um metro e meio de altura em cima da mesa de conferência. Então, o que Jeff pediu aos líderes de projeto? Deu a todos eles uma tesoura, fita adesiva, e pediu que cortassem todos os requisitos que tinham que cumprir para atender à meta do CEO.

Uma vez concluído, todas as pequenas tiras de papel foram coladas na parede. No final, 50% do papel tinha ficado em cima da mesa, ou seja, 50% do documento não passava de palavrório, coisas inúteis e desnecessárias que ninguém iria ler.

Essa cena me faz lembrar do mundo corporativo, com seus relatórios burocraticamente preenchidos, mas raramente lidos; ou, no pior dos casos, com seus relatórios redundantes que geram retrabalho ou mesmo trabalho inútil simplesmente por que as equipes não conseguem dialogar e coordenar seus esforços. Esse é um verdadeiro exemplo de desperdício e ineficiência que a metodologia Scrum visa acabar.

Mas, qual é o problema do desperdício? Em uma parte do livro, é abordado um tema de grande impacto nas equipes – – os imbecis. Jeff define um imbecil “como alguém que gosta de agitar as outras pessoas, levando-as a um estado de confusão mental”. Eles criam um grande volume de desperdício, especialmente o emocional.

Na sua opinião, eles estão “apenas cedendo aos aspectos negativos de sua personalidade” e afetam seriamente o desempenho da equipe. Todos conhecemos alguém que poderia se encaixar nessa descrição de imbecil. Confrontá-los é um trabalho árduo e não há respostas fáceis para lidar com eles.

A metodologia Scrum ajuda a diminuir esse tipo de desperdício, já que expõe os imbecis: um ambiente de melhoria contínua e cooperação entre as equipes requer um nível de amadurecimento emocional que faz com que eles não sobrevivam no sistema.

*Alexandre Nishikawa, Engenheiro Mecatrônico pela Universidade de São Paulo com dupla graduação em Automação no Politecnico di Milano, diretor da Starpack Plásticos, associado ao IFL.