Livro ‘SCRUM’ por Jeff Sutherland

Livro 'SCRUM' de Jeff Sutherland
A arte de fazer o dobro do trabalho na metade do tempo
“Repleto de histórias empolgantes e exemplos reais. O método de gerenciamento de projetos conhecido como Scrum deve ser a ferramenta de produtividade mais largamente empregada entre as empresas de alta tecnologia. Jeff Sutherland tem sido brilhantemente bem-sucedido em sua missão de pôr esse recurso nas mãos de mais negócios em todo o mundo.” – Eric Ries, autor de A startup enxuta. O mundo vem sofrendo um processo de mudança contínuo cada vez mais acelerado. Para quem acredita que deve haver uma maneira mais eficiente de fazer as coisas, Scrum é um livro instigante sobre o processo de liderança e gestão que está transformando a maneira como vivemos...
Capa comum: 256 páginas
Editora: Editora Sextante (18 de fevereiro de 2019)
Idioma: Português
ISBN-10: 8543107164
ISBN-13: 978-8543107165
Dimensões do produto: 16 x 1,4 x 23 cm
Peso de envio: 358 g

Melhor preço cotado ⬇️

Leia trecho do livro

Prefácio

Por que Scrum?

Criei o Scrum, com Ken Schwaber, há mais de 20 anos, como uma forma mais rápida, confiável e eficiente de desenvolver softwares na indústria de tecnologia. Até aquele momento — e até 2005 —, a maior parte dos projetos de desenvolvimento de softwares era executada com base no método em cascata, segundo o qual um projeto era concluído em etapas distintas e conduzido passo a passo até o lançamento para os consumidores ou usuários. O processo era lento, imprevisível e muitas vezes não resultava em um produto que as pessoas quisessem ou pelo qual se dispusessem a pagar. Atrasos de meses ou até de anos eram comuns. Os antigos planos passo a passo, confortavelmente detalhados em diagramas de Gana, davam à gerência a sensação de que se tinha total controle sobre o desenvolvimento de um projeto. No entanto, quase sempre o cronograma logo estava atrasado e o orçamento era ultrapassado em uma escala desastrosa.

Para superar essas falhas, inventei, em 1993, um novo jeito de fazer as coisas: o Scrum. Trata-se de uma mudança radical em relação às metodologias prescritivas e hierarquizadas empregadas no passado no gerenciamento de projetos. Ao contrário delas, o Scrum se assemelha a sistemas evolucionários, adaptativos e autocorretivos. Desde sua concepção, a estrutura do Scrum se tornou a maneira como o setor de tecnologia cria novos softwares e produtos. Porém, apesar de ter obtido muito sucesso no gerenciamento de projetos de software e hardware no Vale do Silício, o Scrum permanece relativamente desconhecido no mundo dos negócios em geral. Por isto escrevi este livro: para revelar e explicar o sistema de gerenciamento Scrum para setores fora do mundo da tecnologia. Aqui falarei sobre as origens do Scrum no Sistema Toyota de Produção e no ciclo OODA da aviação de combate. Mostrarei como organizamos projetos em torno de equipes pequenas — e por que esse é um modo tão eficiente de trabalhar.

Explicarei como priorizamos projetos; como definimos os “sprints” de uma semana a um mês, para ganhar impulso e para que todos na equipe sejam responsáveis pelos resultados; e como conduzimos reuniões diárias rápidas, com todos de pé, para nos mantermos informados sobre o que já foi feito e sobre os desafios que inevitavelmente surgem. Além disso, explicarei como o Scrum incorpora os conceitos de aprimoramento contínuo e produto viável mínimo (MVP, na sigla em inglês) para receber retorno imediato dos consumidores em vez de esperar até que o projeto esteja completo. Como você verá nas páginas a seguir, já usamos o Scrum para tudo, desde fabricar carros com custos viáveis que fazem mais de 42 quilômetros por litro de combustível até levar os sistemas de bancos de dados do FBI para o século XXI.

Continue lendo. Acho que você verá como o Scrum pode transformar a maneira como sua empresa trabalha, cria, planeja e pensa. Acredito de verdade que o Scrum pode revolucionar o funcionamento dos negócios em praticamente qualquer setor, assim como revolucionou a inovação e a entrada no mercado de uma gama impressionante de novas empresas e uma variedade incrível de novos produtos vindos do Vale do Silício e do mundo da tecnologia.

— Dr. Jeff Sutherland

CAPÍTULO 1

A maneira como o mundo funciona está errada

Jeff Johnson tinha certeza de que aquele dia não seria bom. Em 3 de março de 2010, o mais ambicioso projeto de modernização do Federal Bureau of Investigation (FBI) foi cancelado —projeto que deveria evitar outro n de Setembro, mas que se transformara em um dos maiores fiascos de todos os tempos na indústria de software. Havia mais de uma década que a agência tentava atualizar seu sistema de computação, mas agora parecia que o plano não seria concretizado. De novo. E dessa vez o projeto era de Jeff.

Ele chegara ao FBI sete meses antes, persuadido por Chad Fulgham, novo diretor-executivo de Informação da agência, com quem havia trabalhado no banco Lehman Brothers. Jeff seria o diretor-assistente da Divisão de Tecnologia da Informação (TI). Ganhou um escritório no último andar do edificio J. Edgar Hoover, no centro de Washington, D.C. Era uma sala grande. Tinha até vista para o Monumento a Washington. Mal sabia ele que, nos dois anos seguintes, acabaria em uma sala sem janela do tamanho de uma lata de sardinhas no porão do prédio, tentando consertar algo que todos diziam não ter conserto.

“Não foi uma decisão fácil”, conta Jeff. Junto com o chefe, resolveu se dar por vencido e cancelar um projeto que já se arrastava havia quase io anos e custara centenas de milhões de dólares. Àquela altura, fazia mais sentido a própria agência assumi-lo. “Mas precisávamos realizá-lo, e bem.”

O projeto era o tão esperado novo sistema de computação que levaria o FBI para os tempos modernos. Em 2010 – a era do Facebook, do Twitter, da Amazon e do Google —, a maioria dos relatórios da agência era preenchida em papel. O sistema usado pelo FBI se chamava Automated Case Support (Auxílio de Caso Automatizado). Rodava em computadores gigantescos que tinham sido o suprassumo da tecnologia em algum momento dos anos 1980. Muitos agentes especiais nem se davam o trabalho de usá-lo. Era lento e inconveniente demais para uma época de ataques terroristas e criminosos sagazes.

Quando um agente do FBI queria fazer algo — na verdade, qualquer coisa, desde pagar um informante para ficar de olho em um terrorista até preparar um relatório sobre um ladrão de bancos —, o procedimento não era muito diferente do empregado 30 anos antes. Johnson o descreve da seguinte forma: “Era necessário escrever um relatório em um processador de texto e imprimir três vias. Uma delas era enviada para aprovação. Outra era arquivada no local, para o caso de a primeira se perder. Quanto à terceira, você pegava uma caneta vermelha — sem brincadeira, uma caneta vermelha mesmo — e circulava as palavras-chave, que deviam ser inseridas no banco de dados. Você mesmo tinha que indexar seu relatório.” Quando um pedido era aprovado, a via em papel voltava dos andares superiores com um número. Um número anotado em um pedaço de papel era o método utilizado pelo FBI para manter o controle de todos os arquivos de casos. Era um método tão ultrapassado e falho que foi apontado como um dos culpados pelo fato de a agência não ter conseguido “ligar os pontos” que mostravam vários ativistas da Al-Qaeda entrando no país semanas e meses antes do atentado de n de Setembro. Um dos escritórios desconfiava de um indivíduo. Outro se perguntava por que tantos estrangeiros suspeitos estavam tendo aulas de voo. Outra unidade tinha um homem na lista de vigilância, mas não compartilhou a informação. Ninguém no FBI foi capaz de juntar os dados.

Após os ataques, a Comissão do n de Setembro conduziu uma investigação profunda para tentar descobrir o principal motivo pelo qual a agência permitira que o atentado ocorresse. A conclusão foi que os analistas não tinham acesso às informações que deveriam analisar. “A ineficiência dos sistemas de informação do FBI fazia com que esse acesso dependesse em grande parte das relações interpessoais do analista com indivíduos nas unidades operacionais ou com equipes que detinham tais dados”, dizia o relatório.

Antes dos ataques, o FBI nunca tinha realizado uma avaliação completa da ameaça terrorista aos Estados Unidos. Havia vários motivos para isso: desde o foco em progresso na carreira até a falta de compartilhamento de informações. Entretanto, a carência de sofisticação tecnológica foi apontada como sendo talvez a principal razão de o FBI ter falhado de forma tão grave nos dias que antecederam o 11 de Setembro. “Os sistemas de informação do FBI eram completamente inadequados”, concluiu o relatório da Comissão. “O FBI não tinha a capacidade de saber o que sabia; não havia nenhum mecanismo adequado para acessar ou compartilhar o conhecimento institucional.”

Quando os senadores começaram a fazer perguntas constrangedoras, a agência se limitou a dizer: “Não se preocupem, já temos um plano de modernização em andamento.” Esse plano era o sistema Virtual Case File (VCF), que supostamente mudaria tudo. Sem deixar a crise passar em branco, os dirigentes do FBI afirmaram que só precisavam de mais 70 milhões de dólares, além dos 100 milhões já orçados, para concluir o trabalho. Quando lemos os relatórios sobre o VCF elaborados naquela época, duas palavras saltam aos olhos: revolucionário e transformação aparecem aos montes.

Três anos depois, o programa foi cancelado. Não funcionava. Nem um pouco. O FBI gastara 170 milhões de dólares dos contribuintes para bancar um sistema de computador que nunca seria usado — nem uma única linha de código, nem um aplicativo, nem um dique. Era um completo desastre. E não se tratava apenas de um erro da IBM ou da Microsoft. A vida das pessoas corria perigo, literalmente. Na época, o senador democrata Patrick Leahy, de Vermont, então presidente do Comitê Judiciário do Senado, declarou ao Washington Post:

Tínhamos informações que poderiam ter impedido o 11 de Setembro. Estavam bem ali, diante de nós, e ninguém fez nada. […] E não vi os problemas serem corrigidos. […] Talvez cheguemos ao século XXII antes de termos a tecnologia do século XXI.

O fato de muitos dos funcionários da época do desastre do Virtual Case File não estarem mais no FBI é bastante ilustrativo.

Em 2005, a agência anunciou um novo programa, o Sentinel. Dessa vez daria certo. Tomariam todos os cuidados necessários, realizariam os procedimentos orçamentários corretos e usariam as ferramentas de controle adequadas. Haviam aprendido a lição. O preço? Meros 451 milhões de dólares. Em 2009 o sistema estaria em pleno funcionamento.

O que poderia dar errado? Em março de 2010 a resposta caiu na mesa de Jeff Johnson. A Lockheed Martin, empresa contratada para desenvolver o Sentinel, já gastara 405 milhões de dólares do orçamento, desenvolvera apenas metade do projeto e já estava um ano atrasada. Um estudo independente estimou que seriam necessários de seis a oito anos adicionais para concluir o Sentinel, além de mais 35o milhões de dólares dos contribuintes.

A tarefa de Johnson era encontrar uma solução para o problema.

O que deu errado e como a situação foi resolvida é o motivo pelo qual estou escrevendo este livro. O problema não era que as pessoas não fossem inteligentes. Nem que o FBI não tivesse o pessoal certo nos lugares certos. Tampouco uma questão de tecnologia errada. Não tinha nada a ver com a ética de trabalho ou com o nível adequado de competitividade.

A questão era a maneira como as pessoas trabalhavam. A maneira como a maioria das pessoas trabalha. O modo como todos achamos que o trabalho deve ser feito, porque foi assim que aprendemos.

Quando se analisa o que aconteceu, a princípio tudo parece fazer sentido: os funcionários da Lockheed se reuniram antes de entrar na concorrência pelo contrato, analisaram as exigências e planejaram como desenvolver um sistema que atendesse a todas as necessidades do cliente. A empresa designou muitos funcionários inteligentes para trabalhar meses a fio estudando o que precisava ser feito. Em seguida, a equipe passou mais alguns meses planejando como tudo aquilo seria realizado. Fez lindos diagramas que mostravam todas as metas a serem alcançadas e o tempo que seria gasto em cada uma das etapas. Então, com uma cuidadosa escolha de cores, expôs como cada fase sucederia à anterior, na forma de uma cascata.

MÉTODO CASCATA

Livro 'SCRUM' por Jeff Sutherland

Gráficos como esse se chamam diagramas de Gantt, em homenagem a seu criador, Henry Gana. Na década de 1980, com o advento dos computadores pessoais, ficou bem mais fácil criar esses gráficos complicados — e torná-los realmente complexos-, e eles se tornaram verdadeiras obras de arte. Todas as etapas do projeto são detalhadas. Cada evento importante. Todas as datas de entrega. Esses diagramas são de fato impressionantes de se ver. O único problema é que estão sempre, sempre errados.

Henry Gantt inventou esses famosos gráficos por volta de 1910. Eles começaram a ser usados na Primeira Guerra Mundial pelo general William Crozier, chefe de Material Bélico do Exército dos Estados Unidos. Qualquer um que tenha estudado essa guerra sabe que a organização não foi um ponto notável. Nunca entendi muito bem por que uma ferramenta da Primeira Guerra Mundial passou a ser aplicada ao gerenciamento de projetos no século XXI. Já não existe mais a guerra de trincheiras, mas, de algum modo, as ideias que a organizaram ainda são populares.

É muito tentador esmiuçar diante dos olhos de todo mundo todo o trabalho a ser feito em um projeto imenso. Já visitei diversas empresas em que há funcionários cujo único trabalho é atualizar os diagramas de Gana todo dia. O problema é que aquele lindo plano cai por terra no instante em que dá de cara com a realidade. Só que, em vez de descartá-lo ou de mudar seu modo de pensar, os gerentes contratam gente que faça parecer que o plano está funcionando. No fundo, pagam alguém para mentir para eles.

Esse padrão desastroso lembra os relatórios que o Partido Comunista da União Soviética recebia na década de 1980, pouco antes do colapso do bloco. Uma miragem. Como naquela época, os relatórios de hoje se tornaram mais importantes do que a realidade que deveriam mostrar. Caso surjam discrepâncias, o problema está na prática, nunca nos gráficos.

Quando eu era cadete na Academia Militar, dormia no antigo quarto de Dwight Eisenhower. À noite, a luz da rua refletia em uma placa dourada em cima da lareira e às vezes isso me acordava. A placa dizia: DWIGHT D. EISENHOWER DORMIU AQUI. E então eu lembrava que, certa vez, Eisenhower disse que se planejar para o combate é importante, mas o plano vira fumaça assim que o primeiro tiro é disparado. Pelo menos ele tinha o bom senso de não usar um diagrama de Gantt.

Então a Lockheed apresentou todos aqueles lindos gráficos ao FBI, que assinou o contrato. Em tese, a tarefa tinha sido tão bem planejada que nada poderia dar errado. “Olhe só, o plano tem diversas cores, cronogramas e gráficos de barras.”

Mesmo assim, quando Jeff e seu chefe, o diretor-executivo Chad Fulgham, examinaram o plano na primavera de 2010, sabiam exatamente o que era aquele gráfico — a mesma coisa que todos os outros: uma farsa completa. Quando começaram a analisar o avanço real e o que de fato tinha sido entregue, os dois perceberam que o problema não tinha solução. Novos defeitos no software eram descobertos num ritmo muito mais acelerado do que aquele em que se corrigiam os antigos.

Chad informou à Inspetoria-Geral do Departamento de Justiça que seria possível concluir o Sentinel se o desenvolvimento fosse feito pela própria agência e se o número de desenvolvedores fosse reduzido. Com isso, eles entregariam a parte mais dificil do projeto em menos de um quinto do tempo estimado e por menos de um décimo da quantia orçada. O ceticismo é evidente nos severos relatórios da Inspetoria-Geral (IG) para o Congresso. No documento de outubro de 2010, depois de expor nove pontos da proposta que geravam preocupação, a IG concluiu:

Em suma, temos preocupações e dúvidas significativas quanto à capacidade que essa nova abordagem teria de finalizar o projeto Sentinel dentro do orçamento e do prazo previstos e com funcionamento semelhante […].[2]

Uma nova forma de pensar

O nome dessa nova abordagem é “Scrum”. Eu a criei há mais de 20 anos. Hoje, ela é a única maneira comprovada de auxiliar projetos desse tipo. Há duas formas de fazer as coisas: o antigo método em “cascata”, que gasta centenas de milhões de dólares e, com frequência, não apresenta nenhum resultado; ou a nova forma, que, com menos gente e menos tempo, garante mais resultados, com qualidade melhor e custos menores. Sei que isso parece bom demais para ser verdade, mas os resultados provam: funciona mesmo.

Há duas décadas, eu estava desesperado. Tinha que encarar o trabalho de um jeito novo. Com muita pesquisa, experimentação e análise de dados, percebi que todos precisávamos de uma nova forma de organizar os esforços humanos. Não estou falando de coisas de outro mundo; tudo isso já foi dito antes. Estudos da época da Segunda Guerra Mundial mostram algumas das melhores formas como as pessoas trabalham. Contudo, por algum motivo, ninguém tinha ligado os pontos. Por 20 anos, tentei fazer exatamente isso. E agora essa metodologia se tornou onipresente na área em que a pus em prática pela primeira vez: a de desenvolvimento de softwares. Em gigantes como Google, Amazon e Salesforce.com, assim como em pequenas startups sobre as quais você ainda não ouviu falar, essa estrutura mudou radicalmente o modo de trabalho.

O motivo pelo qual essa estrutura funciona é simples. Observei como as pessoas realmente trabalham em vez de me basear em como elas dizem que trabalham. Analisei pesquisas realizadas ao longo de décadas e práticas que deram certo em empresas do mundo inteiro. Também examinei as melhores equipes dessas empresas. O que as tornava superiores? O que as tornava diferentes? Por que alguns grupos atingiam resultados excepcionais e outros só chegavam a desfechos medíocres?

Por motivos que explicarei melhor nos próximos capítulos, chamei essa estrutura de trabalho em equipe de “Scrum”. O termo vem do rágbi e se refere à maneira como um time se une para avançar com a bola pelo campo. Tudo se alinha: posicionamento cuidadoso, unidade de propósito e clareza de objetivo. Trata-se de uma metáfora perfeita para o que desejo que as equipes façam.

Tradicionalmente, a gerência quer duas coisas em qualquer projeto: controle e previsibilidade. O resultado disso é uma quantidade imensa de relatórios, gráficos e diagramas — justamente o que ocorreu na Lockheed. Gastam-se meses no planejamento de todos os detalhes para que nenhum erro ocorra, o orçamento não estoure e tudo seja entregue no prazo.

O problema é que esse cenário cor-de-rosa nunca se torna realidade. Todo o esforço investido no planejamento, na restrição de mudanças e na previsão do imponderável não serve para absolutamente nada. Em todo projeto surgem problemas e há rompantes de inspiração. Toda tentativa de restringir um empreendimento humano de qualquer magnitude a diagramas coloridos é uma bobagem fadada ao fracasso. Não é assim que os indivíduos trabalham e os projetos avançam. Não é assim que as ideias florescem e se desenvolvem criações excepcionais.

Pelo contrário, isso gera frustração, porque ninguém consegue o que quer. Os prazos não são cumpridos, os orçamentos estouram e muitas vezes os projetos acabam em completo fracasso. Isso é ainda mais verdadeiro para equipes que trabalham na criação de algo novo. Na maioria das vezes, a gerência só se dá conta de que tudo caminha para o fracasso quando milhões de dólares e milhares de horas já foram investidos em vão.

O Scrum questiona por que tanto tempo e esforço são gastos na realização de uma tarefa, e por que somos tão ruins em prever o tempo e o esforço que as atividades vão exigir. A Catedral de Chartres levou 57 anos para ser construída. Posso apostar que, no início do projeto, os pedreiros viraram para o bispo e disseram: “Vinte anos, no máximo. Acho até que a gente faz em 15.”

O Scrum acolhe a incerteza e a criatividade. Cria uma estrutura em torno do processo de aprendizagem, permitindo que as equipes avaliem o que já criaram e de que forma o criaram, o que é igualmente importante. A estrutura do Scrum procura aproveitar a maneira como as equipes de fato trabalham, fornecendo ferramentas para se auto-organizarem e otimizarem em pouco tempo a rapidez e a qualidade do trabalho.

Na essência, o Scrum se baseia em uma ideia simples: quando começamos um projeto, por que não verificar a intervalos regulares se ele está indo no caminho certo e se isso é de fato o que as pessoas querem? E por que não se perguntar se é possível aprimorar a forma como você está trabalhando para obter resultados melhores e mais rápidos, e o que estaria impedindo você de fazer isso?

O nome disso é ciclo de “inspeção e adaptação”. De tempos em tempos, pare o que está fazendo, revise o que já fez e verifique se deveria continuar fazendo a mesma coisa e como poderia fazer melhor. É uma ideia simples, mas executá-la exige reflexão, introspecção, honestidade e disciplina. É para mostrar como fazer isso que estou escrevendo este livro. E não estou pensando apenas em empresas de desenvolvimento de softwares. Já vi o Scrum ser aplicado com sucesso na construção de foguetes, na organização de um casamento. Até minha esposa o utiliza para se certificar de que a minha lista de afazeres domésticos seja cumprida todo fim de semana.

Os resultados do Scrum — o objetivo do projeto, se preferir — são equipes que melhoram consideravelmente a sua produtividade. Ao longo dos últimos 20 anos, montei várias equipes assim. Já fui CEO, diretor de TI e chefe do departamento técnico de várias empresas, desde pequenas startups com poucos funcionários aglomerados em uma sala até grandes organizações com escritórios espalhados mundo afora. Já prestei serviços de consultoria e coaching para centenas de outras companhias.

Os resultados podem ser tão impressionantes que firmas líderes de mercado em pesquisa e análise, como a Gartner, a Forrester Research e o Standish Group, hoje afirmam que o antigo modo de trabalhar se tornou obsoleto. As empresas que continuam insistindo nas ideias já testadas e malsucedidas de comando e controle e que tentam impor um nível de previsibilidade muito alto estão fadadas ao fracasso, caso seus concorrentes usem o Scrum. A diferença é grande demais. Empresas de capital de risco, como a OpenView Venture Partners, de Boston, da qual sou conselheiro, afirmam que o Scrum oferece uma vantagem competitiva grande demais para não ser aplicada. Os profissionais dessas companhias não são condescendentes; são homens de negócios de visão aguçada que simplesmente afirmam: “Os resultados são inquestionáveis. As empresas têm duas opções: mudar ou morrer.”

Marcações: ,