O que é mais importante: o plano ou a realidade?

A resposta dessa pergunta está na compreensão do modelo apresentado neste livro, o Scrum, um método alternativo de gerenciamento de projetos nos negócios, diferente do tradicional método cascata. Sua proposta inicial de aplicação era solucionar os problemas encontrados na maioria dos projetos que envolviam a criação de softwares, sendo aplicado pela primeira vez no desenvolvimento de um novo sistema de computação para o FBI. Essa aplicação permitiu que o projeto, iniciado com a metodologia cascata, fosse finalizado após mais de 10 anos de tentativas e centenas de milhões de dólares gastos sem geração do resultado esperado.

Este livro aborda a experiência de um dos autores, Jeff Sutherland, em diversos projetos que impulsionaram a criação do método Scrum. Entre elas estão: sobrevivência como piloto de caça, tomada de sua própria companhia L2 melhorando o desempenho, estudo de células cancerígenas que ajudou a compreender as organizações como sistemas complexos, e aplicação do Scrum em projeto de modernização do FBI.

Por meio dessas experiências, ele apresenta as origens do Scrum, a visão geral de seu funcionamento e a aplicação em projetos de desenvolvimento de software e outros projetos não tecnológicos, como na educação e no governo. No decorrer de suas histórias, o autor explica por que as empresas devem abandonar o método tradicional em cascata, e implementar o Scrum para revolucionar seu negócio.

Nos três primeiros capítulos o autor se dedica a explicar as origens e inspirações do Scrum, e a partir do capítulo seis começa a apresentar cada um dos princípios e práticas que compõem o método apresentado no livro, ilustrando-os com cases de projetos dos quais participou e aplicou essa metodologia, deixando mais claras as vantagens de sua utilização.

No primeiro capítulo é apresentado o case do FBI, em que o autor tinha como desafio desenvolver e implementar um novo sistema de computação para a empresa. Esse sistema deveria automatizar e otimizar os processos, permitindo um melhor acesso às informações, além de permitir a conexão dos dados e impedir ataques terroristas, como o que ocorreu no dia 11 de setembro de 2001.

Esse projeto já estava em andamento há 10 anos, sem geração de resultados positivos e com orçamento estourado. Inicialmente, Jeff precisou analisar a situação e a forma como as pessoas estavam trabalhando para conseguir identificar o porquê de o projeto não ser concluído com sucesso. Sua conclusão foi que o problema não estava nas equipes, nem na falta de inteligência ou capacidade, mas sim a metodologia adotada: o método cascata tradicional.

Com o método tradicional, a equipe gastava mais tempo com o planejamento das atividades, geração de relatórios e diagramas de Gantt, do que com o desenvolvimento e análise do que realmente estava sendo entregue, impedindo a visualização da realidade e a identificação da necessidade de ajustes no plano em decorrência dos problemas que, naturalmente, surgem durante um projeto. Entendendo isso, passaram a questionar por que tanto tempo e esforço eram gastos na realização de uma tarefa e por que somos tão ruins para prever o tempo e o esforço que as atividades vão exigir.

Para conseguir finalizar o projeto entregando um resultado satisfatório, Jeff propôs mudar a estratégia de como o sistema deveria ser desenvolvido, sem restringir as equipes a diagramas, pois isso dificultava o processo de desenvolvimento de ideias excepcionais e levava a atrasos no projeto.

Neste capítulo também é apresentado o Manifesto Ágil, em que foram definidos alguns valores para o desenvolvimento de softwares: “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, responder às mudanças em vez de seguir um plano”, e a partir desse manifesto o Scrum foi estruturado para colocar esses valores em prática.

A nova abordagem proposta por Jeff no projeto do FBI incluiu a implementação de ciclos de inspeção e adaptação. Cada ciclo deveria verificar se o projeto estava no caminho certo, sempre questionando se seria possível aprimorar o método de trabalho para atingir os objetivos de forma mais rápida e melhor, conforme um dos valores do manifesto, tomando decisões e lidando da melhor com os obstáculos que forem surgindo no projeto. Dessa forma, foram obtidos feedbacks em curto prazo e continuamente, evitando desperdício de tempo e esforço com algo que não irá agregar valor ao produto final.

Apesar de uma insegurança da diretoria com a proposta apresentada por Jeff, ela foi aceita e permitiu a conclusão com sucesso do projeto, comprovando que o planejamento é útil, porém deve ser sempre revisto de acordo com as circunstâncias da realidade, e que é importante que as empresas inovem para permanecerem no mercado, sem se apegar aos métodos tradicionais que focam em comando, controle e previsibilidade rígida.

No segundo capítulo são abordadas as inspirações do autor para estruturar o Scrum. Muitas delas estão relacionadas aos estudos de Hirotaka Takeuchi e Ikujiro Nonaka, incluindo conceitos da metodologia Lean. Além disso, incorporam técnicas utilizadas na indústria japonesa como, por exemplo, as equipes multifuncionais e autônomas, com objetivos transcendentes e líderes facilitadores do processo.

A origem do Scrum também está relacionada a algumas experiências do autor, que destaca a importância de que em projetos deve-se considerar que os elementos podem mudar ao longo dele, inclusive a necessidade do cliente, sendo importante trabalhar com um modelo que responda mais às necessidades do cliente - “mudar ou morrer”.

Outro ponto abordado neste capítulo é o conceito Shu Ha Ri: “Shu” conhece as regras e as repete; “Ha”, após domínio das formas, pode inovar; “Ri” deixa de lado as formas, já domina a prática e consegue ser criativo naturalmente. Ele se aplica ao Scrum, ou seja, só se aprende na prática, quando o corpo, o meio e o espírito se alinham por meio de treino constante e aperfeiçoamento.

O capítulo três realça a importância de uma equipe alinhada. Também ressalta que as empresas devem focar em equipes ao invés de indivíduos – diferentemente do que costuma acontecer quando há promoções, bônus e contratações – já que são as equipes que permitem o sucesso de um projeto, e não apenas um indivíduo.

Em seus estudos dos projetos de sucesso, o autor chega à conclusão de que existem três elementos comuns nas equipes desses projetos:

Transcendência: há um senso de propósito acima do comum;

Autonomia: existe autonomia para decidir a melhor forma de realizar o trabalho, ou seja, a partir do objetivo estratégico definido pela diretoria, os integrantes da equipe são capazes de decidir como irão trabalhar, com auto gerenciamento e auto organização;

Multifuncionais: equipe formada com indivíduos que possuem todas as funcionalidades necessárias para a realização do projeto, com diversidade de habilidades, de pensamento, de experiência. O autor ressalta que, devido às limitações de natureza humana, esse elemento gera os melhores resultados em equipes pequenas, até 9 pessoas, uma vez que em grupos maiores a capacidade de comunicação constante é atrapalhada, gerando correntes cruzadas, com divisão social e funcional com objetivos contrários, consequentemente perde-se a multifuncionalidade;

Para ilustrar esses elementos, o autor cita dois exemplos: aplicação do Scrum no jornalismo e na guerra. No primeiro caso, uma equipe de repórteres e produtores da NPR se organizou de forma autônoma durante uma revolução egípcia, devido a cortes nas redes de comunicação, o que impediu o contato com os executivos de Washington. Isso gerou melhores resultados e maior número de reportagens do que era esperado. Já no segundo caso, foi adotada a conduta de guerra colaborativa, ou seja, equipes multifuncionais na Guerra do Iraque, em que não separavam a coleta de informações de planejamento de operações. Dessa forma, havia constante comunicação entre as pessoas que coletavam as informações, as que planejavam o que fazer com esses dados e as que iam a campo.

Além disso, são apresentados 3 papeis importantes que devem estar presentes em uma equipe Scrum, são eles:

O proprietário do produto (Product Owner): responsável pelos riscos e recompensa, possui a visão do objetivo do projeto, ou seja, o que é possível e o que deve ser feito;

A equipe: formada pelas pessoas que realizam as tarefas, responsáveis por transformar a visão do proprietário do produto em realidade, possuem as competências e autonomia necessárias para essa transformação;

O Scrum Master: responsável pelo treinamento da equipe e por eliminar os obstáculos encontrados durante o projeto, além disso, guiar a equipe em direção ao aperfeiçoamento contínuo;

Esses papeis foram inspirados em uma dança realizada por um time de rúgbi da Nova Zelândia, a haka, que por meio dessa dança energiza os jogadores, e traz para o jogo: concentração, colaboração extrema, ímpeto de destruição (eliminar obstáculos) e entusiasmo de todos.

Por fim, o autor cita o “erro fundamental de atribuição”, um dos erros humanos mais comuns no julgamento das ações das pessoas. Ele consiste em uma tendência de atribuir os comportamentos à personalidade e ignorar o contexto em que o comportamento foi observado. Dessa forma, estamos sempre buscando a culpa em indivíduos e não nos sistemas. E essa é uma das diferenças do Scrum, uma vez que ele não busca definir culpa e falhas, mas sim recompensar os comportamentos positivos.

No capítulo quatro o autor reflete sobre o tempo como o maior limitador dos projetos, e como não devemos desperdiçá-lo. Por isso, uma das práticas incorporadas ao Scrum foi o sprint, que acabou se tornando a essência desse modelo.

O sprint, que significa ir a toda velocidade por um pequeno período, foi inspirado em uma política do Laboratório de Mídia do MIT: a cada 3 semanas as equipes apresentavam o que estavam fazendo, e se o produto demonstrado não funcionasse ou não fosse legal, os diretores cancelavam o projeto. Com isso, os feedbacks eram constantes e eram desenvolvidos produtos interessantes de forma mais rápida.

No Scrum, os sprints correspondem a ciclos de trabalho definidos por períodos regulares para estabelecer um ritmo de trabalho. Durante cada ciclo, devem ser realizadas reuniões diárias curtas (Daily Scrum), cujo objetivo é fazer com que todos saibam como o sprint está se desenvolvendo e obter a maior quantidade possível de informações úteis no menor intervalo de tempo possível.

Para que essas reuniões tenham resultados positivos é importante que elas não sejam longas, até 15 minutos, de modo que sejam objetivas e diretas. Caso algum ponto exija mais tempo, uma reunião específica deve ser realizada. Além disso, as reuniões devem acontecer, de preferência, sempre no mesmo horário para dar à equipe um ritmo regular, e com participação de todos. Se um integrante sequer não estiver presente, aumentam as chances de acontecerem falhas na comunicação. A partir de um estudo de Jim Coplien, foi identificado que quanto maior a saturação de comunicação, mais rápida é a equipe, por isso é necessária a participação de todos.

Para viabilizar a agilidade da reunião, o Scrum Master deve realizar três perguntas para cada um da equipe:

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

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

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

E a partir das respostas, a equipe deve discutir de forma rápida e eliminar os obstáculos que surgiram, e um ajudar o outro a atingir o sucesso do sprint.

O capítulo cinco reforça a essência do Scrum: o ritmo, mostrando que apesar desse modelo criar um padrão diferente do que o encontrado na maioria das empresas, existem padrões que parecem positivos, porém representam desperdícios que estão presentes no dia a dia dos projetos.

Para Taiichi Ohno, da Toyota, um dos influenciadores durante a criação do Scrum, existem três tipos de desperdícios: Muri, o desperdício causado pela irracionalidade; Mura, desperdício causado pela inconsistência; e Muda, o desperdício causado pelos resultados. E esses desperdícios podem ser relacionados com as ideias de Deming e o ciclo PDCA, ou seja, o planejamento evita o desperdício irracional, a realização das tarefas evita o desperdício por inconsistência e a verificação evita o desperdício por resultados. O Agir está relacionado à determinação de evitar os três desperdícios citados.

No livro, o autor apresenta algumas práticas que ajudam a evitar esses desperdícios. Entre elas está a realização de apenas uma tarefa por vez, por completo e corretamente, de forma que a concentração não esteja dividida, e assim a o resultado seja atingido de forma mais rápida. Além disso, é importante concluir a tarefa antes de iniciar outra, pois tarefas incompletas representam um esforço investido sem resultado positivo. Por fim, acertar de primeira evita desperdício de tempo, porém, como seres humanos, cometemos erros, e por isso devemos lidar com eles o quanto antes para atingir os resultados esperados com mais qualidade, rapidez e evitar que sejam propagados.

Outra prática citada pelo autor é equilibrar as horas trabalhadas e as horas de descanso, uma vez que é comprovado que o excesso de trabalho reduz a produtividade, leva à fadiga e a erros, gerando na verdade mais trabalho para efetuar as correções necessárias. Isso está relacionado a metas irracionais e atos heroicos, e Jeff explica que os objetivos devem ser motivadores e não absurdos, pois isso na verdade leva a excesso de trabalho e esforços considerados “heroicos”, quando na verdade devem ser vistos como falha no planejamento.

O capítulo é finalizado com o autor indicando que o Scrum busca que o trabalho seja executado sem gerar incômodos, mas de forma leve, com disciplina e fluxo para gerar resultados incríveis.

No capítulo seis é apresentado um case da Medco, em que o autor foi chamado para viabilizar a implementação de um projeto de farmácias especializadas em um prazo muito limitado e com diversos obstáculos, inclusive softwares desatualizados.

Inicialmente, Jeff percebeu que a equipe desse projeto cometeu um dos erros mais comuns que levam a atrasos: dedicaram muito tempo com planejamentos detalhados com antecedência, fazendo com que o plano se tornasse mais importante que a realidade. Esse é um dos pontos que o Scrum se diferencia do método tradicional, pois nele é recomendado que seja feito um planejamento detalhado apenas da entrega do próximo elemento que agrega valor e o restante do projeto um seja feito um planejamento macro, em vez de fazer o planejamento detalhado de todas as etapas do projeto com antecedência. Com essa estratégia, ao final de cada sprint é possível apresentar algo de valor para o cliente e coletar feedbacks para realizar ajustes e detalhar a próxima etapa.

Em seguida, o autor mostra que o planejamento no Scrum é feito a cada sprint e é formado por algumas etapas, cada uma com os seus desafios. São elas:

Listar as tarefas que precisam ser feitas para atingir o objetivo;

Ordenar as tarefas de acordo com prioridades;

Descobrir quanto esforço, tempo e dinheiro será necessário

Neste capítulo, Jeff esclarece que as pessoas pensam por meio de histórias e contextos, por isso ao definir uma tarefa é importante entender por que ela deve ser realizada, para evitar que seja feita de forma errada. Além disso, sugere que para definir uma tarefa é importante considerar para quem será feito o trabalho, o que deve ser feito, sua motivação, e as histórias devem ser curtas o suficiente para que seja possível estimá-las e colocá-las em prática.

Após definir as tarefas, é preciso verificar se a lista está pronta. Para essa verificação, Jeff sugere o uso dos critérios INVEST: para que para uma história esteja pronta, ela não deve depender de outra (Independente), deve permitir mudanças (Negociável), deve entregar valor (Valiosa), deve ser possível de dimensioná-la (Estimável), deve ser curta (Sucinta) e deve passar por um teste para ser definida como concluída (Testável).

Por fim, o autor explica que os seres humanos não são bons em previsão de esforço, tempo e dinheiro, porém tem resultados positivos quando é feito o dimensionamento relativo, ou seja, comparar tarefas umas com as outras, colocando um peso para cada uma. E acrescenta que a melhor proporção para esse dimensionamento é o uso da sequência Fibonacci (0,1,1,2,3,5,8,13...), pois a distância entre os números é suficiente para identificar a diferença entre eles e permite ter opiniões sobre a dimensão de cada tarefa.

O desafio do dimensionamento relativo está em como definir o peso de cada tarefa. É importante evitar o efeito de contágio, que faz com que as pessoas pensem que, se todo mundo concorda com algo, as ressalvas delas estão erradas. Ou seja, devemos usar outras estimativas para melhorar as nossas, e não as substituir. O efeito halo também deve ser evitado, pois nesse caso a característica de algo influencia o modo como as pessoas percebem outras características da mesma coisa não relacionadas à primeira. Isso impede que seja feita uma análise dos dados reais, uma vez que, nesse efeito as pessoas são atraídas por algo que tem aparência positiva.

Como alternativa para evitar esses efeitos, o autor sugere o método Delphi, que permite grande variedade de opiniões e tenta eliminar as ideias preconcebidas, porém exige muito tempo. Outra opção apresentada é o pôquer planejamento para coletar estimativas de forma mais rápida e precisa: cada pessoa escolhe uma carta do baralho (número de Fibonacci) para avaliar a tarefa. Em seguida, se as opiniões estiverem a uma distância de até duas cartas e feita a soma dos números, faz a média e segue para a próxima tarefa. Se não, quem selecionou a carta mais alta e a mais baixa explicam seu raciocínio, e a rodada se repete.

O último ponto desse capítulo está relacionado à medição da velocidade da equipe em cada sprint, por meio da soma dos pontos das tarefas concluídas, e à determinação o que está impedindo que a equipe trabalhe mais rápido.

O capítulo sete destaca a importância do empoderamento das pessoas que compõem uma equipe e como o nível de felicidade pode influenciar o resultado dos projetos. Com um exemplo dos alpinistas, o autor ilustra o fato de que as pessoas são mais felizes durante os momentos que levam ao objetivo, do que quando o objetivo é atingido em si. Ele ressalta que a maioria das culturas não incentivam esse tipo de felicidade e cita uma frase do livro “Seja Mais Feliz”, em que “nós não somos recompensados por desfrutar a jornada, mas pela conclusão bem-sucedida da jornada. A sociedade recompensa resultados, não processos”.

Neste momento, Jeff apresenta mais uma prática do Scrum, também inspirada no kaizen, mais um dos conceitos de Taichii Ohno, da Toyota. Essa prática consiste em identificar o que pode ser realizado para tornar as coisas melhores. No Scrum, isso é chamada de “retrospectiva do sprint”, e consiste em, ao final de cada ciclo, os integrantes respondem a algumas perguntas e pensam sobre o que deu certo, o que poderia ter sido melhor, o que pode ser melhorado, como se sentem em relação ao seu papel na empresa, como se sente em relação à empresa como um todo, por que se sente assim e como ficaria mais feliz no próximo sprint. Ao partir dessas respostas, é possível medir a felicidade atual da equipe, projetar o futuro e agir e resolver uma questão antes que se torne um problema.

Para tornar suas equipes mais felizes, o Scrum adota os mesmos elementos que compõem as equipes de sucesso: autonomia, domínio e propósito, já citados anteriormente. Ou seja, ser capaz de controlar seu destino, com transparência, sentir que está melhorando e que possui um propósito transcendente.

No capítulo oito é abordado o conceito de priorização das tarefas. Primeiro apresenta o diagrama de Venn, para mostrar que toda empresa precisa equilibrar os seguintes atributos: o que é possível implementar, o que é possível vender e o que é possível amar; e nesse equilíbrio está a visão baseada na realidade. E é como atingir essa visão que é detalhada neste capítulo.

Para isso, o primeiro passo é criar uma lista de tarefas, chamada de backlog, com base em uma ideia clara do que quer ao fim do projeto. Em seguida, definir quais itens dessa lista geram mais valor ao negócio, que são mais fáceis de fazer, são mais importantes para o cliente, ou seja, definir prioridades. Na priorização deve ser considerado iniciar com as tarefas que agregam mais valor e trazem menos riscos, de modo que seja possível sempre ter algo pronto ao final de cada sprint.

Ao definir o que deve ser feito também é importante determinar como desenvolver 20% das funcionalidades primeiro, já que 80% do valor do desenvolvimento de um produto ou projeto está em 20% de suas funcionalidades. No Scrum, o responsável por identificar a visão, definir em quais tarefas o valor está concentrado e controlar o backlog é o Product Owner, citado no capítulo 3. Além disso, essa pessoa deve ser capaz de receber o feedback do cliente e repassá-lo para a equipe em cada sprint. Em suma suas características essências são formadas por algumas características inspiradas em um engenheiro da Toyota:

Ter conhecimento na área, conhecer o mercado para saber o que vai fazer diferença;

Ter poder de tomar decisões. Deve se responsabilizar pelos resultados, mas deixar que a equipe tome suas próprias decisões;

Estar disponível para a equipe, para explicar o que deve ser feito e por quê. Ser confiável, coerente e disponível. Equipe precisa dele para a “visão” e para aplicar a inteligência de mercado à importância das tarefas;

Ser responsável pelo valor. O segredo é decidir qual a medida de valor e dar ao Product Owner a responsabilidade de entregá-lo em quantidades cada vez maiores.

Após definir um Product Owner, o autor explica como essa pessoa pode tomar decisões de forma rápida, com feedbacks reais e constantes e realizar ajustes na estratégia para atingir o resultado. Esse processo é viabilizado pela ideia do ciclo OODA. Este ciclo consiste em uma combinação de observação e orientação, que leva a uma decisão que conduz uma ação, ou seja, Observar, Orientar, Decidir e Agir.

No decorrer de cada sprint, com as entregas incrementáveis o Product Owner pode efetuar ajustes no próximo sprint. Por isso, é importante lembrar da importância de ter sempre algo feito, de forma completa, cometendo erros no início com o menor dano possível, que corresponde a geração do mínimo produto viável (MVP), de modo que ele seja suficiente para apresentar ao cliente e obter feedbacks, e por fim, criar funcionalidades novas apenas quando acrescentarem valor ao produto.

No último capítulo o autor mostra que, apesar de ter sido criado com o objetivo de melhorar os projetos de desenvolvimento de softwares, o Scrum pode ser aplicado em diversos outros setores, que até ele fica impressionado. Isso reforça o fato de que o mundo está mudando e que o Scrum pode ajudar nesse processo. Alguns exemplos citados por ele é aplicação desse modelo na educação de uma escola da Holanda, na redução da pobreza de Uganda e no governo na cidade americana Olympia, retomando o que foi dito no capítulo 3: em vez de apontar os indivíduos ruins, devemos buscar os sistemas ruins e quais são os incentivos que levam a atitudes negativas.

A leitura deste livro é uma ótima maneira de se atualizar e conhecer práticas que podem auxiliar e facilitar o gerenciamento de projetos, em qualquer negócio. É recomendada para todos, líderes ou não, que estão em busca de novas formas de gerenciar suas equipes de forma mais prática e rápida, uma vez que em todo o livro são apresentados cases que ilustram os conceitos e princípios dessa metodologia, ou como o próprio autor afirma: um modo de ser, um estilo de vida.