• Nenhum resultado encontrado

SCRUM - A Arte de Fazer o Dobro Do Trabalho Na Metade Do Tempo

N/A
N/A
Protected

Academic year: 2021

Share "SCRUM - A Arte de Fazer o Dobro Do Trabalho Na Metade Do Tempo"

Copied!
190
0
0

Texto

(1)
(2)

DADOS DE COPYRIG HT

Sobre a obra:

A presente obra é disponibilizada pela equipe Le Livros e seus diversos parceiros, com o obj etivo de oferecer conteúdo para uso parcial em pesquisas e estudos acadêm icos, bem com o o sim ples teste da qualidade da obra, com o fim exclusivo de com pra futura.

É expressam ente proibida e totalm ente repudiável a venda, aluguel, ou quaisquer uso com ercial do presente conteúdo

Sobre nós:

O Le Livros e seus parceiros disponibilizam conteúdo de dom inio publico e propriedade intelectual de form a totalm ente gratuita, por acreditar que o conhecim ento e a educação devem ser acessíveis e livres a toda e qualquer pessoa. Você pode encontrar m ais obras em nosso site: LeLivros.site ou em qualquer um dos sites parceiros apresentados neste link.

"Quando o mundo estiver unido na busca do conhecimento, e não mais lutando por dinheiro e poder, então nossa sociedade poderá enfim evoluir a um novo

(3)

Ficha Técnica

Copy right © 2014 by Jeff Sutherland and Scrum , Inc. Todos os direitos reservados.

Tradução para a língua portuguesa © 2014 Texto Editores Ltda. Título original: Scrum : The art of doing twice the work in half the tim e

Preparação de texto: Meggie Monauar Revisão: Paula Jacobini Diagram ação: Cristiane Viana

Capa: Ideias com Peso

Dados Internacionais de Catalogação na Publicação (CIP) Angélica Ilacqua CRB-8/

7057 Sutherland, Jeff

Scrum : a arte de fazer o dobro do trabalho na m etade do tem po / Jeff Sutherland; tradução de Natalie Gerhardt.

-São Paulo : LeYa, 2014. Bibliografia ISBN 9788544100882

Título original: Scrum : The art of doing twice the work in half the tim e

1. Scrum (Desenvolvim ento de software) 2. Negócios 3. Adm inistração I. Título II. Gerhardt, Natalie

14-0701 CDD 658 Índices para catálogo sistem ático:

1. Adm inistração - negócios 2014 TEXTO EDITORES LTDA. Um a editora do Grupo LeYa Rua Desem bargador Paulo Passaláqua, 86 01248-010 — Pacaem bu — São Paulo, SP

(4)

Jeff Sutherland

SCRUM A arte de fazer o dobro do trabalho na m etade do tem po

(5)

Prefácio

Por que Scrum ?

Eu criei o Scrum , j unto com Ken Schwaber, há vinte anos, para ser um a form a m ais rápida, eficaz e confiável de criar softwares para o setor de tecnologia. Até aquele ponto — e até 2005 —, a m aior parte do desenvolvim ento de software era feita usando o m étodo em cascata, no qual um proj eto era concluído em todos os estágios distintos e seguia, passo a passo, em direção ao lançam ento para os consum idores, ou usuários. O processo era lento, im previsível e, em geral, nunca resultava em um produto que as pessoas queriam ou estavam dispostas a pagar para obter. Atrasos de m eses ou até m esm o de anos eram endêm icos ao processo. Os planos iniciais de passo a passo, expostos em detalhes reconfortantes em diagram as de Gantt, asseguravam aos gestores que tínham os total controle do processo de desenvolvim ento — no entanto, quase sem pre, nós rapidam ente ficávam os atrasados em relação ao cronogram a, e desastrosam ente acim a do orçam ento.

Para superar essas falhas, em 1993, inventei um a nova form a de fazer as coisas: o Scrum . Trata-se de um a m udança radical das m etodologias prescritivas e de cim a para baixo usadas na gerência de proj etos no passado; j á o Scrum é sem elhante aos sistem as autocorretivos, evolucionários e adaptativos. Desde o com eço, a estrutura do Scrum se tornou a form a de o setor tecnológico criar novas aplicações de software e produtos. Contudo, em bora ele tenha se tornado m uito bem -sucedido no gerenciam ento de proj etos de software e hardware no Vale do Silício, ainda perm anece pouco conhecido em outros setores de negócios. E foi por isso que escrevi este livro: para revelar e explicar o sistem a de gerenciam ento do Scrum para setores de negócios fora do m undo da tecnologia. Aqui eu falo sobre a sua origem no Sistem a Toy ota de Produção e no ciclo OODA da aviação de com bate. Discuto com o organizam os proj etos em torno de equipes pequenas — e por que essa é a form a m ais eficaz de se trabalhar. Explico com o priorizam os as diversas tarefas nos proj etos; com o definim os Sprints de um a sem ana a um m ês para criarm os um a força e tornarm os todos na equipe responsáveis; com o fazem os reuniões breves diárias para m anter o controle de tudo o que

(6)

foi feito e dos desafios que inevitavelm ente aparecem ; e com o o Scrum incorporou os conceitos de aprim oram ento contínuo e produtos m inim am ente viáveis para obter feedback im ediato dos consum idores, em vez de esperar até que o proj eto tenha sido concluído. Com o você verá, usam os o Scrum para construir qualquer coisa, desde carros viáveis que fazem 42 quilôm etros por litro de com bustível até trazer os sistem as de banco de dados do FBI para o século 21.

Leia este livro. Acho que você verá com o o Scrum pode aj udar a transform ar o m odo com o a sua em presa trabalha, cria, planej a e pensa. Eu realm ente acredito que esse sistem a pode aj udá-lo a revolucionar a form a com o as em presas funcionam em praticam ente todos os setores, assim com o ele revolucionou a inovação e a velocidade para o m ercado em um a gam a estarrecedora de novas em presas e um a variedade enorm e de novos produtos surgindo fora do Vale do Silício e do m undo da tecnologia.

(7)

CAPÍTULO 1

A m aneira com o o m undo funciona está quebrada

Jeff Johnson tinha quase certeza de que aquele não seria um bom dia. Em 3 de m arço de 2010, o Federal Bureau of Investigation (FBI) cancelou o seu proj eto m ais am bicioso de m odernização — aquele que poderia ter evitado o 11 de setem bro, m as que se transform ou em um dos m aiores fiascos da indústria de software de todos os tem pos. Por m ais de um a década, o FBI tentou atualizar seu sistem a de com putação, e tudo indicava que iria falhar. De novo. E agora o proj eto era dele.

Ele havia chegado ao FBI sete m eses antes, atraído pelo novo Diretor-Executivo de Inform ação (Chief Information Officer, CIO), Chad Fulgham , com quem trabalhara na Lehm an Brothers. Jeff era o diretor-assistente da nova Divisão de Engenharia de Tecnologia da Inform ação (TI), e tinha um escritório no últim o andar do edifício J. Edgar Hoover, no centro de Washington, D.C. Era um a sala grande com vista para o Monum ento de Washington. Mal sabia Jeff que, pelos dois anos seguintes, acabaria em um escritório sem j anelas e do tam anho de um a caixa de fósforos no porão do prédio, tentando consertar algo que todos diziam ser im possível.

“Não foi um a decisão fácil”, conta Jeff. Seu chefe e ele decidiram declarar derrota e cancelar um program a no qual haviam trabalhado por quase dez anos e custara centenas de m ilhões de dólares. Àquela altura, fazia m ais sentido trazer o proj eto para “dentro de casa” e tentar fazê-lo por conta própria. “Mas aquilo precisava realm ente ser feito, e m uito bem feito”.

Tratava-se do aguardado proj eto para um novo sistem a de com putação que efetivam ente trouxesse o FBI para a era m oderna. Em 2010 — a era do Facebook, Twitter, Am azon e Google —, a agência ainda preenchia a m aioria de seus relatórios no papel, e utilizava um sistem a cham ado Autom ated Case Support. Ele rodava em com putadores gigantescos que, em algum período da década de 1980, eram o que existia de m ais m oderno. Mas, naquele m om ento, m uitos agentes especiais nem o usavam m ais; era ainda inconveniente e m uito lento para um a época de ataques terroristas e crim inosos espertos.

(8)

Quando um agente do FBI queria fazer algo — qualquer coisa, na verdade —, desde pagar a um inform ante para perseguir um terrorista até fazer um relatório sobre um ladrão de bancos, o processo não era m uito diferente do que era feito trinta anos antes. Johnson o descreve da seguinte m aneira:

Era necessário escrever o relatório usando um processador de texto e depois im prim i-lo em três vias. Um a seria enviada para aprovação, outra arquivada localm ente para o caso de a prim eira se perder; e, na terceira via, você teria de pegar um a caneta verm elha — não, eu não estou brincando, um a caneta verm elha m esm o — e circular as palavras-chave que deveriam ser inseridas no banco de dados. Você tinha de indexar o próprio relatório.

Quando um pedido era aprovado, a via em papel recebia determ inado núm ero — sim , um núm ero escrito em um pedaço de papel é o m odo com o o FBI m antém todos os seus arquivos de casos. Esse m étodo era tão antiquado e furado que recebeu parte da culpa quando a agência não conseguiu “unir os pontos” que m ostravam vários ativistas da Al-Qaeda entrando no país pouco tem po antes dos atentados terroristas de 11 de setem bro. Um escritório tinha um suspeito; outro se perguntava por que tantos estrangeiros suspeitos estavam assistindo a aulas de pilotagem de avião. E outro ainda tinha um suspeito em sua lista de vigilância, m as não repassou a inform ação. Assim , ninguém no FBI foi capaz de reunir todas aquelas peças.

Depois dos ataques, a Com issão do 11 de Setem bro investigou a fundo para tentar descobrir o principal m otivo de aquilo ter acontecido, e chegou à conclusão de que os analistas não conseguiram ter acesso às inform ações necessárias. Diz o relatório: “A ineficiência dos sistem as de inform ação do FBI significava que tal acesso dependia em grande parte das relações interpessoais do analista com pessoas em outras unidades ou equipes que detinham tais inform ações”.

Antes da tragédia, o FBI nunca havia concluído um a avaliação da am eaça global do terrorism o dentro dos Estados Unidos. Houve um a série de razões para isso, desde foco no avanço da carreira dos funcionários até um a total falta de com partilham ento de inform ações. No entanto, o relatório apontou a ausência de sofisticação tecnológica com o talvez o principal m otivo por que o FBI falhara de form a tão drástica nos dias que antecederam os ataques. “Os sistem as de inform ação do FBI eram com pletam ente inadequados”, concluiu o docum ento. “O FBI não tinha capacidade para

(9)

saber o que sabia: não havia qualquer m ecanism o adequado para acessar ou com partilhar o conhecim ento institucional”.

Quando os senadores com eçaram a fazer perguntas desconfortáveis para a agência, o FBI praticam ente disse “não se preocupem , tem os um plano de m odernização j á em andam ento”. O sistem a planej ado se cham ava Virtual Case File (VCF) e deveria m udar tudo. Sem deixar que a crise passasse em branco, os funcionários relataram que precisavam apenas de m ais US$ 70 m ilhões, além dos outros US$ 100 m ilhões j á orçados, para concluírem o trabalho. Se você ler os relatórios sobre o VCF da época, perceberá que as palavras revolucionário e transformação são usadas de form a generosa.

Três anos depois, o program a foi cancelado. Não funcionava. Nem um pouquinho. O FBI tinha gastado US$ 170 m ilhões dos contribuintes para com prar um sistem a de com putador que nunca seria usado — nem um a linha de código ou aplicação ou clique do m ouse. Tudo aquilo era o m ais absoluto desastre. E não era com parável a um erro da IBM ou da Microsoft. A vida das pessoas estava, literalm ente, em risco. O Senador Patrick Leahy, de Verm ont, dem ocrata e então Presidente do Com itê Judiciário do Senado, declarou, na época, ao Washington Post:

Nós tínham os inform ações que poderiam ter im pedido os ataques terroristas de 11 de setem bro. Estavam bem ali, diante de nós, e ninguém fez nada... Eu não estou vendo os problem as serem corrigidos... Talvez cheguem os ao século XXII antes que consigam os ter a tecnologia do século XXI.1

É bastante esclarecedor dizer que m uitas das pessoas que trabalhavam no FBI quando o desastre do Virtual Case File aconteceu não estão m ais trabalhando lá.

Em 2005, a agência anunciou um novo program a, o Sentinel. Daquela vez, ia funcionar. Daquela vez, tom ariam todas as precauções necessárias, fariam os procedim entos orçam entários corretos e usariam as ferram entas certas de controle. Já tinham aprendido a lição. O preço? Meros US$ 451 m ilhões. E estaria em pleno funcionam ento em 2009.

O que poderia dar errado? Em m arço de 2010, a resposta caiu na m esa de Jeff Johnson. A Lockheed Martin, em presa contratada para desenvolver o sistem a Sentinel, j á tinha gastado US$ 405 m ilhões do orçam ento. Tinham desenvolvido apenas m etade do proj eto e j á estavam um ano atrasados. Um a análise independente estim ou que levariam outros seis a oito anos para

(10)

concluir o proj eto, e que ainda teriam de investir m ais US$ 350 m ilhões do dinheiro dos contribuintes.

Encontrar um a solução para aquilo era problem a de Johnson. O que tinha dado errado e com o a situação foi resolvida são o m otivo por que estou escrevendo este livro. Não era um a questão de inteligência. Não era que a agência não tivesse as pessoas certas nos lugares certos e tam bém não era um a questão de tecnologia errada. Tam bém não tinha nada a ver com ética no trabalho ou com o estím ulo adequado de com petitividade. Era por causa da maneira com o as pessoas estavam trabalhando. A maneira com o a m aioria das pessoas trabalha. A m aneira com o nós acham os que o trabalho precisa ser feito, porque foi assim que aprendem os a fazê-lo.

Quando você ouvir o que aconteceu, vai achar que, em um prim eiro m om ento, parece fazer sentido: as pessoas na Lockheed se reuniram antes de entrar na concorrência para o contrato, analisaram os requisitos e com eçaram a planej ar com o desenvolver um sistem a que atenderia a todas as necessidades do cliente. Eles tinham m uitas pessoas inteligentes trabalhando por m eses a fio, planej ando tudo o que precisava ser feito. Então, dedicaram m ais alguns m eses planej ando como fazê-lo. Desenharam lindos diagram as com tudo isso, e o tem po que levaria para atingir os obj etivos. Então, com um a seleção cuidadosa de cores, apresentaram um fluxo que m ostrava cada um a das fases do proj eto com o um a cascata.

Esses fluxos se cham am “diagram as de Gantt”, em hom enagem a Henry Gantt, que os desenvolveu. Com o advento dos com putadores pessoais na década de 1980, tornou-se bem m ais fácil desenvolver diagram as com plicados — e torná-los realm ente complexos —, e eles se tornaram verdadeiras obras de arte. Cada etapa do proj eto está detalhadam ente definida; cada evento im portante, cada data de entrega. Esses diagram as são realm ente algo im pressionante de se ver. O único problem a com eles é que estão sem pre errados. Sem pre.

Henry Gantt inventou esses fam osos diagram as por volta de 1910. Eles com eçaram a ser usados na Prim eira Guerra Mundial pelo General William

(11)

Crozier, quer era o Oficial Chefe do Arm am ento do exército dos Estados Unidos. Todos que j á estudaram essa guerra sabem que sua capacidade organizacional eficiente não foi exatam ente um ponto notável. O porquê de um artefato da Prim eira Guerra Mundial ter se tornado um a ferram enta

prática utilizada no gerenciam ento de proj etos no século 21 nunca ficou m uito

claro para m im . Nós j á desistim os de guerras de trincheiras, m as, de algum a form a, as ideias que as norteiam ainda são populares.

É m uito tentador ter todo o trabalho que precisa ser feito exposto para todos verem . Já visitei diversas em presas com funcionários cuj o único

trabalho é atualizar diariam ente os diagram as de Gantt. O problem a é que

quando aquele plano elegante se depara com a realidade, ele cai por terra. Só que, em vez de descartar o plano ou o m odo com o pensam nele, os gerentes contratam pessoas para fazer com que pareça que o plano está funcionando. Basicam ente, o que eles fazem é contratar pessoas para m entir por eles.

Esse padrão desastroso é um eco daqueles relatórios que os politburos2 soviéticos recebiam na década de 1980 um pouco antes do colapso da URSS. Um a m iragem com pleta. Assim com o naquela época, os relatórios se tornaram m ais im portantes do que a realidade que deveriam descrever, e se houvesse discrepâncias, o problem a estava na realidade, não nos diagram as.

Quando eu era um cadete em West Point, dorm ia no quarto antigo de Dwight Eisenhower. À noite, as luzes da rua refletiam um brilho dourado no consolo da lareira e, às vezes, isso m e acordava. Havia um a placa que dizia DWIGHT D. EISENHOWER DORMIU AQUI. E eu m e lem braria de que Eisenhower, certa vez, disse que planej ar o com bate é im portante, m as assim que o prim eiro tiro fosse disparado, o plano viraria fum aça. Pelo m enos ele teve o bom senso de não usar um diagram a de Gantt.

Então, a Lockheed apresentou ao FBI todos aqueles lindos diagram as, e a agência assinou o contrato. Supostam ente, a tarefa agora estava tão bem planej ada que nada poderia dar errado. “Olhem , está no plano codificado por cor, com definição de hora e gráficos de barras.”

Ainda assim , quando Jeff e seu chefe, o CIO Chad Fulgham , olharam o plano na prim avera de 2010, sabiam o que estavam vendo, o que todos aqueles diagram as eram na realidade: um a farsa com pleta. Quando os dois com eçaram a analisar o desenvolvim ento real e o que j á tinha realm ente sido entregue, perceberam que o problem a estava m uito além de poder ser resolvido. Novos defeitos estavam sendo descobertos no software a um a velocidade m uito m aior do que conseguiam corrigir os antigos.

Chad inform ou ao Inspetor Geral do Departam ento de Justiça que eles conseguiriam concluir o proj eto Sentinel se o desenvolvessem internam ente, cortando o núm ero de desenvolvedores, e, assim , conseguiram entregar a parte m ais desafiadora do proj eto em m enos de um quinto do tem po com m enos de um décim o da quantia orçada. O ceticism o nos relatórios geralm ente secos do Inspetor Geral (IG) para o Congresso foi palpável. No relatório de outubro de 2010, depois de expor nove pontos de preocupação sobre a proposta, os assistentes do IG concluíram : “em sum a, tem os

(12)

preocupações e questões significativas em relação à capacidade de essa nova abordagem finalizar o proj eto Sentinel dentro do orçam ento e do prazo estipulados e com funcionalidade sem elhante...”.3

Um a nova form a de pensar

Esta nova abordagem se cham a Scrum . Eu a criei vinte anos atrás. Agora essa é única m aneira com provada de aj udar proj etos desse tipo. Existem duas form as de fazer as coisas: o m étodo antigo da “cascata” que gasta centenas de m ilhões de dólares e não entrega nenhum resultado, ou a nova form a, que, com m enos gente e em m enos tem po, consegue m ais resultados com m ais qualidade e m enos custos. Sei que soa bom dem ais para ser verdade, m as a prova está nos resultados. Funciona m esm o.

Há vinte anos, eu estava desesperado. Precisava de um a nova form a de pensar sobre o trabalho. E, por m eio de m uita pesquisa e experiências e análise de dados passados, percebi que todos nós precisávam os de um a nova form a de organizar os em preendim entos hum anos. Nada disso é ciência espacial, j á se falou disso antes. Existem estudos que datam da Segunda Guerra Mundial m ostrando algum as das form as com o as pessoas trabalham m elhor. Contudo, por algum m otivo, elas nunca j untaram as peças. Nas últim as duas décadas, tentei fazer exatam ente isso, E, agora, essa m etodologia se tornou onipresente no prim eiro cam po ao qual eu a apliquei: o desenvolvim ento de softwares. Em gigantes com o Google, Am azon e Salesforce.com e em pequenas start-ups sobre as quais você ainda nem ouviu falar, essa estrutura m udou radicalm ente a form a com o as pessoas fazem as coisas.

O m otivo por que ela funciona é sim ples. Eu olhei a form a com o as pessoas realmente trabalham , em vez de com o elas dizem que trabalham . Analisei um a pesquisa realizada por décadas e as m elhores práticas de em presas em todo o m undo, analisei m ais a fundo as m elhores equipes nessas em presas. O que as tornava superiores? O que as tornava diferentes? Por que algum as equipes atingiam resultados excepcionais e outras apenas resultados m edíocres?

Por m otivos que explicarei m elhor em capítulos m ais adiante, eu cham ei de “Scrum ” essa estrutura de desem penho de equipe. O term o vem do j ogo de rúgbi e se refere à m aneira com o um tim e trabalha j unto para avançar com a bola no cam po. Alinham ento cuidadoso, unidade de propósito, clareza de obj etivo, tudo se unindo. Trata-se de um a m etáfora perfeita para o que um a equipe desej a fazer.

Tradicionalm ente, a gerência quer duas coisas em qualquer proj eto: controle e previsibilidade. Isso resulta em um vasto núm ero de docum entos,

(13)

gráficos e diagram as, exatam ente com o os da Lockheed. Meses de esforço para o planej am ento de todos os detalhes, para que não haj a nenhum erro, para que o orçam ento não estoure, e para que tudo sej a entregue no prazo.

O problem a é que o cenário cor-de-rosa nunca vira realidade. Todo o esforço investido no planej am ento, tentando restringir m udanças e adivinhar o im ponderável, não serve para absolutam ente nada. Todo proj eto envolve a descoberta de problem as e surtos de inspiração. Qualquer tentativa de restringir o em preendim ento hum ano de qualquer natureza a diagram as coloridos é bobagem e está fadada ao fracasso. Não é dessa m aneira que as pessoas trabalham e não é dessa form a que os proj etos avançam . Não é com o as ideias florescem ou com o as coisas excepcionais sãos feitas.

Em vez disso, esse tipo de diagram a gera frustação porque as pessoas não conseguem o que realm ente queriam . Os proj etos atrasam e estouram o orçam ento e, em m uitos casos, acabam não dando certo. Isso é verdadeiro principalm ente nos casos que envolvem equipes criativas trabalhando em algo novo. Na m aioria das vezes, a gerência não tom a conhecim ento do cam inho em direção ao fracasso, até que m ilhões de dólares e m ilhares de horas tenham sido investidos em vão.

O Scrum pergunta por que leva tanto tem po e tanto esforço para as coisas serem feitas, e por que som os tão deficientes para perceber quanto tem po e esforço algo vai exigir. A catedral de Chartres levou 57 anos para ser construída. É bem seguro apostar que, no início do proj eto, os pedreiros tenham olhado para o bispo e dito “Vinte anos no m áxim o. Talvez sej a possível term inar em quinze”.

O Scrum acolhe a incerteza e a criatividade. Coloca um a estrutura em volta do processo de aprendizagem , perm itindo que as equipes avaliem o que j á criaram e, o m ais im portante, de que forma o criaram . A estrutura do Scrum busca aproveitar a m aneira com o as equipes realm ente trabalham , dando a elas as ferram entas para se auto-organizar e, o m ais im portante, aprim orar rapidam ente a velocidade e a qualidade de seu trabalho.

Em essência, o Scrum tem com o base um a ideia sim ples: ao com eçar um proj eto, por que não fazer paradas regulares para verificar se o que está sendo feito está seguindo na direção certa, e se, na verdade, os resultados são os que as pessoas desej am ? E verificar se existem m aneiras de aprim orar a form a com o se está trabalhando para obter resultados m elhores e executados m ais rapidam ente, e quais seriam os obstáculos que im pedem as pessoas de obtê-los.

Isso é cham ado de ciclo de “Inspeção e Adaptação”. De tem pos em tem pos, pare de fazer o que está fazendo, revise o que j á fez e verifique se ainda deveria estar fazendo aquilo e com o você pode fazê-lo m elhor. É um a ideia sim ples, m as executá-la exige reflexão, introspecção, honestidade e disciplina. Estou escrevendo este livro para m ostrar com o fazer isso, e não apenas para em presas de desenvolvim ento de software. Eu j á vi o Scrum ser usado com sucesso para fabricar carros, gerenciar um a lavanderia, dar aulas, construir foguetes espaciais, planej ar um casam ento — e até m esm o, com o a m inha esposa o usa, para se certificar, nos fins de sem ana, de que lista de

(14)

afazeres dom ésticos que ela m e passou foi cum prida.

Os resultados finais do Scrum — ou o obj etivo do proj eto, se preferir — são equipes que m elhoram drasticam ente a produtividade. Nos últim os vinte anos, m ontei essas equipes repetidas vezes. Já fui Diretor-Executivo (CEO, na sigla em inglês), Diretor de Tecnologia da Inform ação (CTO, na sigla em inglês) e Chefe do Departam ento de Engenharia de várias em presas, desde pequenas start-ups, com poucos funcionários em um a sala, até grandes em presas com escritórios espalhados pelo m undo. Já prestei serviços de consultoria e coaching para centenas de outras.

Os resultados podem ser tão drásticos que grandes em presas de pesquisa e análise, com o a Gartner and Standish, agora afirm am que o antigo estilo de trabalho se tornou obsoleto. As em presas que ainda insistem nas ideias j á tentadas e m alogradas de com ando e controle e que tentam im por um nível rígido de previsibilidade estão sim plesm ente fadadas ao fracasso se seus concorrentes usarem o Scrum . A diferença é grande dem ais. Em presas de capital de risco, com o a OpenView Venture Partners em Boston, da qual sou conselheiro, dizem que o Scrum oferece um a vantagem com petitiva grande dem ais para não ser usado. Os profissionais dessas em presas não são calorosos nem confusos, são hom ens de negócio de visão aguçada, e sim plesm ente afirm am : “Os resultados são inquestionáveis. As em presas têm duas opções: m udar ou m orrer”.

Consertando o FBI

No FBI, o prim eiro problem a que a esquipe do Sentinel enfrentou foram os contratos. Cada um a das m udanças acabava se tornando um a negociação contratual com a Lockheed Martin. Assim , Jeff Johnson e Chad Fulgham passaram m eses deslindando os contratos, trazendo o desenvolvim ento para ser feito internam ente e cortando a equipe de centenas de pessoas para m enos de cinquenta. A equipe principal era ainda m enor.

Na prim eira sem ana, eles fizeram o que várias pessoas fazem quando se encontram na m esm a situação: im prim iram toda a docum entação de requisitos. Se você nunca viu o que isso significa em um proj eto de grande porte, posso dizer que o m aterial pode chegar a centenas e centenas de páginas. Vi pilhas que tinham vários centím etros de altura. E j á vi isso em vários proj etos: pessoas cortando, colando e desenvolvendo um docum ento clichê, sendo que ninguém , na verdade, leria até o final aquelas m ilhares de páginas. Não dá m ais para fazer isso, e esse não é o obj etivo. Eles construíram um sistem a que os força a endossar um a fantasia.

“Havia 1.100 requisitos. Os docum entos form avam pilhas com m uitos centím etros de altura”, conta Johnson. Só de pensar neles faz com que eu

(15)

sinta pena das pessoas que dedicaram sem anas de suas vidas produzindo docum entos que não serviam para nada. O FBI e a Lockheed Martin não estão sozinhos nessa em preitada — j á vi esse tipo de situação em quase todas as em presas nas quais trabalhei. Aquela pilha alta de futilidade é um dos m otivos por que o Scrum pode ser um a m udança tão poderosa para as pessoas. Ninguém deveria passar a vida fazendo um trabalho sem significado algum . Isso não apenas é ruim para os negócios, com o tam bém destrói a alm a das pessoas.

Então, depois de ler a pilha de docum entos, eles analisaram e priorizaram cada um dos requisitos do sistem a, o que é de total im portância e m ais difícil do que parece. Em geral, as pessoas dizem que tudo é im portante. Mas a pergunta que precisa ser respondida, e foi o que as equipes do Sentinela fizeram , é: o que agregará m ais valor para o proj eto? Faça essas coisas prim eiro. No desenvolvim ento de um software existe um a regra, criada a partir de décadas de pesquisa, que afirm a que 80% do valor de qualquer parte dele está em 20% de suas funcionalidades. Pense nisto: qual foi a últim a vez que você usou a função do Editor de Visual Basic no Microsoft Word? Provavelm ente, você nem sabe o que é Visual Basic, quanto m ais por que você precisaria usar tal ferram enta. Mas ela está lá, e alguém dedicou seu tem po im plem entando essa funcionalidade, m as eu garanto que ela não representa um aum ento significativo no valor agregado do Word.

Fazer as pessoas priorizarem de acordo com o valor as obriga a produzir aqueles 20% prim eiro. Em geral, depois que eles foram concluídos, elas se dão conta de que não precisam dos outros 80%, ou que o que parecia im portante no início do proj eto, na verdade, não era.

Para a equipe do Sentinel, a pergunta se tornou: “Tudo bem , nós vam os desenvolver este proj eto enorm e que é de vital im portância e j á gastam os centenas de m ilhões de dólares nele. Quando ele vai ser concluído?”. Depois de pensar nisso, eles prom eteram entregar o software no outono de 2011. O relatório do Inspetor Geral do outono de 2010 é um estudo da descrença:

O FBI afirm ou que vai utilizar um a “m etodologia ágil” para concluir o desenvolvim ento do Sentinel, usando m enos funcionários do FBI, da Lockheed Martin, além das em presas que forneceram os principais com ponentes-padrão do Sentinel. Além disso, o FBI planej a reduzir o núm ero de funcionários contratados trabalhando no Sentinel de cerca de 220 para quarenta. O FBI tam bém afirm ou que o núm ero de funcionários do FBI designados diretam ente para o proj eto tam bém será reduzido de trinta para 12 [...] O FBI nos inform ou que acredita que conseguirá concluir o Sentinel com os aproxim adam ente US$ 20

(16)

m ilhões restantes do orçam ento e no prazo de 12 m eses a partir da im plem entação dessa nova abordagem .4

O uso da expressão “m etodologia ágil” m ostra com o o IG sabia pouco sobre o Scrum . O term o “ágil” data de um a reunião de 2001, na qual eu e 16 outros líderes de desenvolvim ento de software escrevem os o que se tornou conhecido com o “Manifesto Ágil”. Nele declaram os os seguintes valores: pessoas em vez de processos; produtos que realm ente funcionem em vez de docum entação dizendo com o o produto deveria funcionar; trabalhar com os clientes em vez de negociar com eles; e responder às m udanças em vez de seguir um plano. Scrum é a estrutura que eu construí para colocar esses valores em prática. Não existe um a m etodologia.

É claro que a prom essa de 12 m eses feita por Johnson causou um a im pressão um pouco errada. Porque, na verdade, eles não sabiam ; não tinham com o saber. O FBI desconhecia a velocidade com que suas equipes poderiam trabalhar. Isto é algo que eu sem pre digo para os executivos: “Eu só poderei dizer a data à m edida que eu vir o aprim oram ento da equipe. Ou sej a, o quanto vão ficar m ais rápidos. O quanto eles vão conseguir acelerar”.

É claro que tam bém é essencial que os m em bros da equipe descubram o que poderia impedi-los de acelerar. Nas palavras de Jeff Johnson: “Eu lidei com a rem oção do obstáculo”. Um “obstáculo” é um a ideia que vem da em presa que concebeu várias das ideias nas quais o Scrum se baseia: a Toy ota. E, para ser m ais específico, do Sistem a Toy ota de Produção desenvolvido por Taiichi Ohno.

Não entrarei em detalhes aqui, m as um dos conceitos-chave que Ohno apresentou foi a ideia de “fluxo”. Ou sej a, a produção deveria fluir de form a calm a e rápida por todo o processo, e ele dizia que um a das principais tarefas da gerência era identificar e rem over os obstáculos para tal fluxo. Tudo que fica no cam inho constitui um desperdício. Ohno nos dá um conceito de desperdício, assim com o um valor de negócios, em seu livro clássico, O

sistema Toyota de produção:

Não é exagero dizer que, em um período de crescim ento lento, tal desperdício sej a m ais um crim e contra a sociedade do que um a perda nos negócios. A elim inação do desperdício deve ser o principal obj etivo de um a em presa.5

(17)

Ohno fala m uito sobre diferentes tipos de desperdícios e obstáculos que podem atrapalhar a produção. Para que o Scrum realm ente funcione, alguém da equipe sênior de gerenciam ento precisa com preender a fundo que os obstáculos são praticam ente crim inosos. Vou explicar como elim inar o desperdício posteriorm ente neste livro. Por ora, basta dizer que o efeito da elim inação é drástico, e as pessoas não costum am fazer isso porque requer honestidade consigo m esm as e com os outros.

Jeff Johnson sabia que aquele era o seu trabalho.

A equipe do Sentinel levou cerca de três m eses para descobrir quanto tem po realmente levaria para concluir o proj eto. O m otivo? A resposta nos leva de volta àquele ciclo de “Inspeção e Adaptação” sobre o qual falei antes. O Scrum funciona com a definição de obj etivos sequenciais que devem ser concluídos em um período definido. No caso do FBI, eles decidiram por ciclos de duas sem anas, com preendendo que, ao final de cada ciclo, deveria haver um a parte concluída do produto. Isso significava que eles precisavam ter algum a coisa funcionando, algo que poderia ser m ostrado para qualquer pessoa que quisesse ver, m as certam ente para os stakeholders e, idealm ente, para aqueles que realm ente usariam o program a.

Essa m etodologia perm ite que as equipes tenham um feedback quase que im ediato do trabalho realizado. Eles estão na direção certa? O que planej am fazer em seguida é realmente o que deveriam fazer, considerando tudo que descobriram durante aquele ciclo?

No Scrum cham am os esses ciclos de Sprint [corrida de velocidade de curta distância]. No início de cada ciclo, acontece um a reunião para planej ar o Sprint. A equipe decide a quantidade de trabalho que acredita ser capaz de realizar nas duas sem anas seguintes. Eles escolhem as tarefas na lista de prioridades, as anotam em post-its e os colam na parede. A equipe decide quantas tarefas será capaz de executar em duas sem anas.

No final do Sprint, a equipe se reúne e m ostra o que conseguiu realizar naquele tem po. Eles analisam quantos dos post-its da parede realm ente foram concluídos. Será que tinham escolhido tarefas dem ais e não conseguiram concluir todas? Ou será que haviam escolhido poucas? O im portante era que com eçassem a estabelecer um a base para sentir o ritm o do trabalho — a velocidade que conseguiam atingir.

Depois de m ostrarem o que conseguiram fazer — e é aqui que as ideias de Ohno entram —, a equipe discute não o que fizeram , m as como fizeram . Eles perguntam : “Com o podem os trabalhar m elhor no próxim o Sprint? Quais foram os obstáculos que tivem os de rem over durante esse período? Quais são os obstáculos que estão dim inuindo o nosso ritm o?”.

E foi por isso que Jeff Johnson precisou de alguns m eses antes de poder dizer quanto tem po o proj eto dem oraria. Ele queria m ensurar a velocidade de cada equipe com base em alguns Sprints e, depois, ver o quanto eles poderiam m elhorar — o quanto m ais poderiam acelerar e avançar. Um a vez que analisou quantas tarefas cada equipe concluiu em cada Sprint e verificou quantas ainda havia até o final do proj eto, ele foi capaz de proj etar um a data de conclusão.

(18)

Além de descobrir a velocidade das equipes, ele tam bém queria saber quais eram os obstáculos que as atrasava. O que ele realm ente queria fazer era acelerar as equipes para que produzissem m ais rápido. Mas não trabalhando m ais tem po (explicarei posteriorm ente por que esse é um cam inho inútil que acaba fazendo com que as coisas levem m ais tem po), m as sim trabalhando melhor e de form a mais inteligente. Jeff relatou que suas equipes aum entaram a produtividade em um fator de três, ou sej a, estavam avançando três vezes m ais rápido depois que com eçaram a se m over, em relação ao início do proj eto. O m otivo? Ficaram m elhores no trabalho em equipe, sim , m as o m ais im portante: descobriram o que os atrasava e, a cada Sprint, tentavam se livrar dos obstáculos.

Por fim , foram necessários 18 m eses de codificação para im plem entar o sistem a de banco de dados do proj eto Sentinel, e m ais dois m eses para disponibilizá-lo para todo o FBI. “Foi um a trem enda pressão de tem po”, contou Johnson em um a entrevista. “E vocês têm de entender que o sistem a é usado para tudo: pagam ento de inform antes, arm azenam ento de provas, arquivos dos casos, agendas. Esta reunião está no Sentinel”.

E, na opinião dele, qual era a parte m ais eficaz do Scrum ? “As dem onstrações. O trabalho voltado para um produto dem onstrável com frequência”. A cada duas sem anas a equipe do Sentinel se reunia e dem onstrava tudo o que tinha conseguido. E esse sistem a de m ostrar e contar não era apenas para eles. A equipe levava o que tinha feito e o m ostrava para as pessoas que realm ente usariam o program a. Todos que tinham interesse no proj eto enviavam um representante, o que significava um a apresentação com casa cheia. Gravações. Inteligência. Agentes especiais. Um funcionário do Inspetor Geral. Representantes de outras agências governam entais. Algum as vezes, o Diretor ou Vice-Diretor do FBI estava na sala, assim com o o próprio Inspetor Geral. Não era um público m uito fácil de se lidar.

E foi isso que fez as coisas funcionarem , afirm a Johnson. “Scrum não é sobre os desenvolvedores. Mas sim sobre os clientes e os stakeholders. Sério, era um a m udança organizacional. Mostrar o produto real era a parte m ais eficaz.”

Na verdade, m ostrar o produto era extrem am ente válido porque as pessoas estavam bastante descrentes, para dizer o m ínim o, quanto ao progresso do trabalho. Elas não conseguiam acreditar que o Sentinel continuava provocando avanços em um ritm o cada vez m ais rápido. “Eu disse para o Congresso que com 5% do orçam ento e em vinte m eses nós conseguiríam os o que a Lockheed não tinha conseguido fazer com 90% do orçam ento em um período de dez anos”, conta Johnson.

Todos estavam céticos. Nós tínham os de fazer relatórios para o Assistente do Procurador Geral da Justiça. Tínham os de ser transparentes em relação ao status do proj eto, m as o nosso público

(19)

continuava desconfiando de que havia algo desonesto acontecendo. Eles j á tinham visto aqueles tipos de indicadores no passado, os relatórios com eçaram a ficar m enos detalhados e outra coisa estava acontecendo.

O ceticism o contagiou o resto do FBI. Os caras no porão vão ferrar com

tudo de novo, era o que pensavam . Aquele seria apenas um sistem a

tem porário que os deixaria na m ão de novo e eles teriam de voltar a usar o papel.

Jeff falou para sua equipe sobre um a citação que tivera de decorar quando ainda era um cadete naval. Era um trecho do discurso “Cidadania num a República”, que Teddy Roosevelt fez em Sorbonne, em 1910. Ele costum a ser bastante citado, e você talvez j á o conheça:

Não é o crítico que conta, não o hom em que aponta com o o hom em forte tropeça, ou onde o executor de ações poderia ter feito m elhor. O crédito pertence ao hom em que está realm ente na arena, com o rosto desfigurado pela poeira e suor e sangue; que se esforça coraj osam ente; que erra, que tenta de novo e de novo, porque não existe esforço sem erros e lacunas; m as quem realm ente se esforça para fazer as obras, quem conhece grandes entusiasm os, as grandes devoções; quem consom e-se em um a causa digna é quem m elhor conhece, no final, o triunfo das grandes realizações, e que, na pior das hipóteses, se falhar, pelo m enos não será enquanto não tiver ousado m uito, de tal form a que seu lugar nunca será j unto às alm as frias e tím idas que não conhecem a vitória nem a derrota.6

A equipe enfrentou alguns atrasos enquanto tentava descobrir exatam ente com que rapidez conseguiria trabalhar e o nível de dificuldade de tudo que tinha pela frente. Por fim , em j ulho de 2012, eles ativaram o Sentinel. E tiveram de ativar todo o sistem a e para todos. Não tinha com o fingir um a coisa daquelas.

“Aconteceu de um dia para outro. Em um caso crim inal ou de contra terrorism o, algo acontecendo em Los Angeles poderia ser relacionado a algo acontecendo em Chicago”, explicou Jeff Johnson. “Não poderíam os perm itir

(20)

que pistas fossem perdidas. Em cada detalhe nós tínhamos de apresentar uma

solução boa, conhecida e clara.”

E tal solução deveria ser clara e boa o suficiente para ser m antida em um j ulgam ento. Os dados no Sentinel seriam usados em j ulgam entos, e sua integridade precisava estar acim a de qualquer suspeita.

Jeff estava frenético e nervoso naquele prim eiro dia. Foi até o escritório e ligou o Sentinel. Ele carregou. Bom sinal. Então, tentou aprovar um docum ento com um a assinatura eletrônica — um a tarefa básica que dezenas de m ilhares de funcionários do FBI costum avam fazer o tem po todo. Ele recebeu um a m ensagem de erro. Não estava funcionando. Ele entrou em pânico, e visões de desastre encheram sua cabeça. Então, leu com cuidado o código de erro que tinha recebido e se deu conta do que aquilo significava: ele não havia inserido o cartão com o qual o com putador verificaria a sua identidade. Ele, então, inseriu o cartão, clicou com o m ouse e o Sentinel estava pronto.

O sistem a teve um efeito drástico no FBI. A capacidade de com unicação e com partilham ento de inform ações m udou fundam entalm ente o que a agência seria capaz de fazer. Em j aneiro de 2013, um agente de cam po do FBI foi cham ado quando um a conta de um a pequena em presa foi invadida por um hacker. O valor de US$ 1 m ilhão fora transferido para outro país antes que os bancos norte-am ericanos pudessem tom ar qualquer atitude. Usando o Sentinel, o agente local coordenou um a ação conj unta com um colega na em baixada do país de destino, que alertou as autoridades locais, que, por sua vez, im pediram que a transferência fosse concluída antes de entrar no sistem a bancário. Isso aconteceu em questão de horas, algo que sim plesm ente não seria possível na época das três vias de docum entos e canetas verm elhas. Foi a diferença entre pegar um bandido ou perm itir que ele se safasse.

No porão do FBI, a equipe do Sentinel ainda está lá, e as divisórias foram rem ovidas das baias para que um colega possa olhar para o outro. Na parede há um pôster grande com os princípios do “Manifesto Ágil”— princípios que eu aj udei a escrever e dediquei m inha vida para dissem inar pelo m undo. Por m ais estranho que pareça para um a sala sem j anelas, um a alfazem a cultivada cresce, saudável, sob a luz fluorescente. “Alfazem a” era o codinom e do protótipo do Sentinel. Os m em bros da equipe ainda estão nos seus postos, aperfeiçoando e acrescentando novas funcionalidades ao sistem a que desenvolveram .

Existe um a piada antiga na com unidade do Scrum : um a galinha e um porco estão cam inhando pela estrada, e a galinha diz:

“Ei, porco, eu estava pensando que a gente devia abrir um restaurante.” “E qual vai ser o nom e do restaurante?”, pergunta o porco. “Que tal ‘Presunto e Ovos’?”

“Não, obrigado”, responde o porco. “Eu teria que m e com prom eter, m as você só teria de se envolver.”

A ideia do Scrum é que os “porcos” são aqueles que estão com pletam ente com prom etidos com o proj eto e são responsáveis diretos

(21)

pelos resultados. As “galinhas” são as pessoas inform adas sobre os progressos realizados, ou sej a, os stakeholders ou partes interessadas. Na parede da sala do Sentinel, tem os um sino na form a de um a cabeça de porco. Quando ele soa, as pessoas que fizeram tudo aquilo que todos disseram que não poderia ser feito sabem que estão sendo cham adas. Tem os outra cam painha do lado de fora, m as aquela é só para as galinhas.

A cada dia o m undo se torna um lugar m ais com plicado, e o trabalho que realizam os está cada vez m ais com plexo, em um ritm o cada vez m ais rápido. Pense em carros, por exem plo. Eu costum ava passar m uito tem po fazendo consertos sim ples no m eu carro. Há uns trinta anos, eu conseguiria reconstruir um radiador. Agora, quando abro o capô do m eu carro, posso m uito bem estar olhando para a parte interna de um com putador. Na verdade, é exatam ente o que estou fazendo, j á que o novo Ford tem m ais linhas de código do que o Facebook e o Twitter j untos. Criar algo tão com plexo assim é um grande peso para a hum anidade. Sem pre que as pessoas estão envolvidas em um esforço criativo e com plexo, sej a para enviar um foguete para o espaço, inventar um interruptor de luz m elhor ou capturar um crim inoso, os m étodos tradicionais de gerenciam ento sim plesm ente não funcionam .

E nós sabem os disso — tanto com o indivíduos quanto com o sociedade. Nós enxergam os os ecos da nossa vida real representados em distopias fictícias com o as m ostradas no desenho Dilbert ou no film e Como

enlouquecer seu chefe. Todos nós j á chegam os em casa e contam os para a

nossa fam ília ou am igos sobre a loucura que é a “organização” corporativa m oderna. Já disseram para todos nós que preencher corretam ente o form ulário é m ais im portante do que fazer o trabalho ou que precisam os fazer um a reunião para nos preparar para um a reunião preparatória. É um a loucura. Ainda assim , continuam os fazendo isso. Mesm o diante do absoluto e com pleto fracasso.

O lançam ento do Healthcare.gov, website no qual os norte-am ericanos deveriam poder se cadastrar para o seguro de saúde, é um ótim o exem plo disso. A interface era linda; inteligente, clara — um prim or de design. Ela foi concluída em três m eses usando o Scrum . A funcionalidade, porém , era um fracasso. Sim plesm ente não funcionava. Ela deveria conectar os bancos de dados da receita federal aos bancos de dados estaduais, das seguradoras, do departam ento do serviço de saúde. Trata-se de um trabalho com plexo que envolveu m ais de vinte em presas trabalhando em diferentes partes, e elas planej aram tudo usando as técnicas em cascata e só testaram o site ao final do proj eto por alguns dias, em vez de realizar testes increm entais ao longo de todo o processo.

A tragédia é que todo m undo sabia o que ia acontecer. As pessoas que trabalham para aquelas em presas não são burras. Elas sabiam . O problem a foi que todo m undo disse “Não é m inha responsabilidade”. Cada em presa entregou a sua parte e ficou por isso m esm o. Eles nunca olharam o site do ponto de vista do usuário, m as apenas do próprio ponto de vista. E fizeram isso porque não estavam alinhados entre si — não estavam unidos em prol de um obj etivo com um . O que o Scrum faz é prom over a união das equipes para

(22)

criar grandes proj etos, e isso exige que todos não apenas vej am o obj etivo final, m as que tam bém façam entregas increm entais para atingi-lo. Não havia ninguém responsável pelo proj eto do site Healthcare.gov que tenha insistido para que tudo fosse testado à m edida que fosse desenvolvido e, infelizm ente, em term os de fracasso, a história desse site dificilm ente pode ser considerada atípica.

Quantas vezes você ouve falar sobre algum proj eto enorm e com custo de m ilhões e m ilhões de dólares ser cancelado não apenas porque os custos ultrapassaram o orçam ento, m as tam bém por que sim plesm ente não

funcionavam? Quantos bilhões de dólares são gastos a cada ano para não

produzir nada? Quanto tem po da sua vida é desperdiçado em um trabalho que tanto você quanto seu chefe sabem que não cria nenhum valor? É com o se você estivesse cavando buracos para tapá-los em seguida, se você for considerar todo o im pacto que está causando.

Não precisa ser assim . Não precisa m esm o. Só porque todo m undo sem pre disse para você que é assim que o m undo funciona não significa que eles estão certos. Existe sim um a m aneira diferente de fazer as coisas — um a m aneira diferente de se trabalhar.

E se você não o fizer, você será substituído. Ou a sua em presa vai m orrer. O m undo hipercom petitivo do século 21 não tem espaço para bobagens.

Um ponto ainda m ais im portante: trabalhar de um a form a produtiva ao m áxim o — com o m odo Scrum — não precisa se restringir aos negócios. E se as pessoas usassem esse m étodo para resolver os grandes problem as da hum anidade, tais com o a dependência do petróleo, problem as de educação, falta de água potável nas partes m ais pobres do m undo, ou o aum ento nos índices de crim inalidade? E se realm ente existir um a m aneira m elhor de viver, trabalhar e resolver os problem as de um a form a diferente? Um a m aneira que realm ente possa m udar o m undo? Pois existe. Há pessoas usando o Scrum para lidar com cada um a dessas questões que eu m encionei, e elas estão causando um grande im pacto.

Neste livro você vai aprender algum as das m aneiras fundam entais com o as pessoas trabalham m elhor, por que som os péssim os ao fazer estim ativas e por que fazer hora extra vai resultar em m ais atrasos ao proj eto. Vou m ostrar todas as pesquisas e aplicações que pessoas com uns, cientistas e organizações fizeram diligentem ente durante anos, e m ostrar com o o Scrum une tudo isso de um a form a que você pode com eçar a usá-lo im ediatam ente. Eu vou m ostrar como fazer isso. Prim eiro, porém , eu quero contar a história de com o cheguei até aqui.

PONTOS PRINCIPAIS

(23)

tentador demais ficar desenhando diagramas sem fim. Todo o trabalho

que precisa ser feito em um proj eto de grande porte deve ser definido para todos verem — m as, quando os planos detalhados se deparam com a realidade, eles viram ruínas. Inclua no seu m étodo de trabalho a possibilidade de m udança, descoberta e inovação.

Inspeção e Adaptação. De tem pos em tem pos, pare de fazer o que está fazendo, revise o que j á fez e verifique se isso ainda é o que você deveria estar fazendo e se existe um a m aneira de fazer m elhor. Mudar ou morrer. Ficar preso ao m odo antigo de fazer as coisas, de m andar ou controlar e m anter um a previsibilidade rígida resultará apenas no fracasso. Nesse m eio tem po, a concorrência que estiver disposta a m udar deixará você com endo poeira.

Fracasse rápido para que possa corrigir o problema o quanto antes. A cultura corporativa costum a dar m ais valor a form ulários, procedim entos e reuniões do que à criação de valor palpável que pode ser verificado a curtos possibilita de tem po pelos usuários. O trabalho que não resulta em valor real é loucura. Trabalhar em um produto em ciclos curtos possibilita um feedback inicial do usuário, perm itindo que você possa elim inar im ediatam ente tudo aquilo que obviam ente constitui um desperdício de esforço.

1 Dan Eggen e Griff Witte, The FBI’s Upgrade That Wasn’t; $170 Million Bought an Unusable Computer System, The Washington Post, Washington, 18 de agosto de 2006, Seção A, p. 1.

2 Politburo era o com itê central do Partido Com unista da antiga União Soviética (URSS), e politburos eram seus afiliados. (N.T.)

3 U.S. Departm ent of Justice, Office of the Inspector General, Status of the Federal Bureau of Investigation’s Implementation of the Sentinel Project, Relatório de 11 de outubro de 2010.

4 Ibid.

5 Taiichi Ohno, Toyota Production System: Beyond Large-scale Production, Cam bridge, MA, Productivity, 1988. [Em português, O sistema Toyota de produção: além da produção em larga escala, Porto Alegre, Bookm an, 1997.]

(24)

6 Roosevelt, Theodore, Citizenship in a Republic. Discurso proferido na Université Paris-Sorbonne, França, 23 de Abril de 1910. [Em português, Cidadania numa República. Disponível em : <http://wallacecezar.wordpress.com /2010/11/24/o-hom em -na-arena-cidadania-num a -repblica/>. Acesso em : 31 j ul. 2014]

(25)

CAPÍTULO 2 As origens do Scrum

Para os pilotos de com bate no Vietnã, o período de serviço m ilitar era sinônim o de sobrevoar o território inim igo em cem m issões. Metade dos pilotos foi derrubada, alguns foram resgatados, m as a m aioria nunca conseguiu voltar. Em 1967, ainda com o um j ovem piloto de com bate inexperiente, fui enviado da base m ilitar Mountain Hom e Air Force, em Idaho, para a base Udorn Roy al Thai Air Force, na região norte da Tailândia, para realizar o trabalho m ais perigoso da Força Aérea dos Estados Unidos: reconhecim ento.

Isso aconteceu m uito antes da era das m issões Predator com drones e im agens de satélite confiáveis. Todas as arm as foram retiradas do m eu RF-4C Phantom , e a aeronave equipada com câm eras e um tanque extra de com bustível. A m inha m issão era sobrevoar o território inim igo, de form a que o m eu navegador pudesse tirar fotos antes e depois das m issões de bom bardeio. A m aioria das operações era realizada à noite, e eu voava pela escuridão tropical a apenas algum as centenas de pés do chão, quase esbarrando na copa das árvores. No m om ento em que cruzava a fronteira do Vietnã do Norte, o m eu Heads-Up Display7 se acendia com o um a m áquina de fliperam a, e o sistem a de aviso contra m ísseis soava com um a fúria de bipes e apitos. O céu era cortado por balas disparadas de canhões antiaéreos, e eu sabia que, em questão de m inutos, um radar antim ísseis estaria com a m inha aeronave na m ira, a não ser que quinhentos pés fosse baixo o suficiente para m e m anter invisível para o radar.

Naquelas situações a adrenalina corria nas m inhas veias, m as eu nunca perdi a calm a. Ao contrário, o perigo quase m e acalm ava. Acredito que isso se deve ao treinam ento que recebi na Força Aérea para aprender a controlar o risco. Lá aprendi quatro coisas: observar, avaliar, decidir e agir. Para ser m ais específico, observava a região-alvo, planej ava o m elhor cam inho para entrar na zona de ataque, avaliava as opções diante de eventos inesperados, e, por fim , agia de form a decisiva com base nos instintos e no treinam ento. A hesitação resultava na m orte de pilotos, assim com o a im prudência. Assim

(26)

que o m eu navegador tirava as fotografias, eu puxava o m anche e saía da zona de guerra, com m eu cam po de visão se reduzindo, devido à força g. O navegador costum ava desm aiar por causa da força e, em alguns casos, perdia o controle dos intestinos. Mas nunca reclam ou. Eu sem pre consegui nos levar de volta a salvo.

Naquela época eu era apenas um j ovem piloto rezando para sobreviver às m issões designadas a m im . Eu não sabia que a m inha experiência nessa função e o treinam ento que recebi sobre com o pensar e agir em situações de vida ou m orte definiriam o m odo com o eu trabalharia pelo resto da vida. Cheguei ao Vietnã em 1967 com dois esquadrões de pilotos de com bate F-4 e dois da aeronave de reconhecim ento RF-4C, em um total de cem aviões. O avião de reconhecim ento substituiu duas esquadrilhas de RF-101. Daquelas cinquenta aeronaves RF-101, apenas quarto não foram derrubadas em um ano. E essas quatro restantes tinham tantos buracos de bala que era im possível voar com elas. Não sei com o seus pilotos conseguiram pousá-las depois da últim a m issão. O RF-4C era um a nave de com bate m ais resistente, m as, m esm o assim , m etade dos aviões foi abatida em um ano. Melhoram os a taxa de sobrevivência, m as, ainda assim , 50% dos que chegaram com igo não voltaram para a base, em bora alguns tenham sido resgatados na floresta antes que se tornassem prisioneiros.

Quando voltei da guerra, fiz m estrado em estatística em Stanford e passei o m aior tem po possível no laboratório de inteligência artificial da universidade. Depois, tornei-m e professor de m atem ática da Air Force Academ y, onde entrei em um program a de PhD em biom etria na University of Colorado Medical School. Lá, perguntei ao m eu orientador, dr. John Bailar, um dos pesquisadores m ais reconhecidos em m edicina e estatística, com o eu poderia escrever um a tese que fosse útil e não term inasse em um a prateleira em poeirada na biblioteca. Ele m e entregou trezentos artigos m édicos sobre câncer, cada um deles exibindo dados estatísticos que variavam drasticam ente entre hum anos e anim ais e tipos de tum or. Bailar disse que se eu conseguisse explicar por que todos eram diferentes, ele m e daria o título de doutor. Então, foi exatam ente o que fiz, e consegui m eu PhD.

Para isso, passei anos tentando descobrir o que acontecia quando um a célula se tornava cancerosa. Aprendi m uito sobre teoria de sistem as e com o um sistem a apresenta apenas determ inados estados estáveis. Quando um a célula evolui, ela passa de um estado estável para outro. Dediquei quase dez anos para descobrir as regras para transpor um sistem a adaptativo com plexo de um estado para outro, e com o fazer com que o próxim o estado fosse positivo em vez de negativo.

Anos m ais tarde, ocorreu-m e que organizações, equipes e pessoas constituem sistem as adaptativos com plexos. Os elem entos que fazem com que um a célula passe de um estado a outro são os m esm os que m ovem as pessoas. Para m udar um a célula, é necessário, prim eiro, inj etar energia no sistem a. Prim eiro tem os o caos — parece não haver regras, tudo está no fluxo. Quando você faz isso em organizações com o um a tentativa de m udança, as pessoas costum am se apavorar, não conseguem entender o que

(27)

está acontecendo e não sabem com o agir. No entanto, de form a bastante rápida, assim com o ocorre com as células, a organização entra em um novo estado estável. A única questão é se o novo estado é m elhor do que o antigo. A célula é cancerosa ou saudável? Eu m e perguntava como podemos descobrir

algumas regras simples que possam guiar as equipes a entrar em um estado mais produtivo, feliz, incentivador, divertido e arrebatador? Passei os quinze

anos seguintes tentando descobrir a resposta.

Durante o governo Reagan, as verbas destinadas à pesquisa científica foram drasticam ente cortadas, incluindo as destinadas ao estudo do câncer realizada pelos National Cancer Centers, onde eu trabalhava com o analista dos dados coletados nos estudos clínicos e epidem iológicos do Colorado Regional Cancer Center. Enquanto eu pensava no que fazer, um a em presa cham ada MidContinent Com puter Services entrou em contato com igo porque ouviram dizer que eu era o principal especialista na área da m ais nova tecnologia da em presa. A MidContinent trabalhava prestando serviços para 150 bancos na Am érica do Norte e seu m ais novo e desej ável produto cham ava-se “Caixa Autom ático de Autoatendim ento” (ATM, na sigla em inglês), ou caixas eletrônicos. Estávam os em 1983, quando sacar dinheiro significava ficar em um a fila no banco ou passar de carro em um

drive-through bancário, quando você precisava preencher um cheque para “sacar”

a quantia que queria e entregá-lo ao caixa.

Os caixas eletrônicos seriam a solução, m as, naquela época, a em presa enfrentava problem as para fazer suas redes se com unicarem entre si. Eles precisavam de alguém que conhecesse sistem as, então m e fizeram um a proposta lucrativa para ser o vice-presidente de sistem as avançados. As m áquinas que form avam a rede de com putadores eram iguais às que eu passara anos rodando os m eus program as de doutorado, então, eu era um a boa opção.

Ou foi apenas o que pensei. Nada nunca é fácil, não é? Quando entrei na em presa, deparei-m e com um departam ento que usava o m étodo em cascata para o planej am ento dos proj etos. Havia centenas de program adores de com putador que se sentavam em suas m esas o dia inteiro trabalhando de m aneira ostensiva, m as sem conseguir entregar nada dentro do prazo ou do orçam ento. Para os caixas autom áticos, os custos eram 30% m ais altos do que a receita. A falta de eficiência surpreendia.

No início, passei um tem po tentando entender com o as coisas funcionavam . Dá para im aginar com o a alta diretoria tratava a m inha equipe. Houve m uitos gritos, m icrogerenciam ento, com portam ento passivo-agressivo e exigências de m ais trabalho com horas-extras. Mas não im portava o quanto a diretoria pressionasse, os atrasos eram crônicos, os proj etos estavam acim a do orçam ento previsto e nada era entregue quando deveria ser.

Decidi que a m elhor opção seria m udarm os tudo. A operação estava defeituosa dem ais para ser consertada de form a gradual; assim , decidi criar um a em presa dentro de um a em presa. Pedi ao nosso CEO, Ron Harris, que m e deixasse m ontar um a organização separada com todos que estavam envolvidos nas redes ATM. Teríam os a nossa própria equipe de vendas, nossa

(28)

própria equipe de m arketing e nosso próprio departam ento financeiro. Ron era um CEO brilhante e criativo que confiava no m eu trabalho. Talvez sob a direção de outra pessoa, isso nunca tivesse acontecido. Depois de ouvir a m inha ideia, ele disse: “Sutherland, se você quer um a dor de cabeça dessa, fique à vontade”.

E foi o que fiz. Cheguei aos desenvolvedores e gerentes e disse a eles: “Nós tem os que parar de fazer as coisas que estão nos m atando”. A situação era com o aquela antiga piada sobre ficar batendo com a cabeça contra um m uro de tij olos só para se sentir m elhor depois que parar. “Tem os de descobrir um m odo m elhor de trabalhar”, afirm ei, “e tem os de com eçar j á”. Então, com ecei a dirigir um a pequena em presa com o um a equipe dividida em subequipes. Os bônus não tinham com o base o desem penho individual, m as sim o desem penho da em presa com o um todo. Descobrim os ferram entas que abriram o cam inho até o Scrum dez anos m ais tarde — por exem plo, os conceitos de Dono do Produto (Product Owner), Pendências do Produtor (Product Backlog) e Sprints sem anais, os quais abordarei em m ais detalhes m ais adiante. Em seis m eses, éram os a divisão m ais lucrativa da em presa, e a receita era 30% m ais alta do que os custos. Os nossos sistem as Nonstop Tandem constituíram os prim eiros com putadores de transações on-line que os bancos tiveram confiança o suficiente para usar, então nós os distribuím os por toda a Am érica do Norte. Hoj e, você encontra caixas eletrônicos praticam ente em qualquer lugar do país, e cada um deles sabe exatam ente quanto dinheiro você tem . A m inha equipe teve m uito a ver com isso. E, sim , você pode agradecer.

Aprendendo a pensar com o um robô

Depois da m inha experiência na carreira m ilitar seguida pela carreira acadêm ica, eu m e considerava m eio que um intruso no m undo dos negócios. No entanto, aquela perspectiva constituiu um dos m eus ativos m ais valiosos. Desde o prim eiro dia, eu não conseguia entender por que as pessoas insistiam em trabalhar de um a form a que sabiam que era ineficiente, destrutiva, desum anizadora e depressiva. Acho que elas im aginam que, se todo m undo trabalha assim , então essa deve ser a m elhor form a de se trabalhar.

Eu realm ente adorei a época em que trabalhei para a MidContinent, m as estava ávido para testar as m inhas habilidades diante de novos desafios. Nas duas décadas seguintes, acabei prestando m eus serviços para em presas pequenas e grandes com o Vice-Presidente de Engenharia ou Diretor Executivo de Tecnologia. Em cada um deles, tentei fazer as equipes trabalharem j untas de form as m ais eficientes. E, em um a dessas em presa, eu m e vi em um prédio em Cam bridge, Massachusetts, a apenas alguns

(29)

quarteirões do MIT. Alguns doutores e professores haviam acabado de fundar um a nova em presa para construir robôs, e eles a dirigiam em um a sala no laboratório do MIT. Ao final, acabaram sublocando espaço da m inha em presa.

Algum as sem anas depois que se m udaram , o inesperado aconteceu: um robô de seis pernas e do tam anho de um gato entrou no m eu escritório e com eçou a m e perseguir em volta da m inha m esa de trabalho. O inventor entrou nervoso e se desculpou pela m áquina, m as, a cada dois ou três dias, o episódio se repetia. Um dos robôs fugia do laboratório e com eçava a correr pelo prédio. Eu conseguia ouvir o som das pernas m ecânicas passando pelos corredores.

Nas tardes de sexta-feira, eu sem pre servia vinho e cervej a no escritório, para que os funcionários relaxassem e socializassem depois de um a sem ana pesada de trabalho. Eu convidava o cientista robótico que trabalhava no final do corredor para participar desses eventos e, certa vez, Rodney Brooks apareceu; ele era professor de inteligência artificial no MIT e um dos fundadores da em presa de robótica. Eu perguntei com o os robôs errantes funcionavam .

“Há décadas tentam os construir um a m áquina que realm ente tenha a capacidade de pensam ento inteligente”, disse ele. “Gastam os bilhões de dólares, m uitos anos de trabalho para construir os m aiores com putadores que podem os, com os m aiores bancos de dados, m as tudo que conseguim os foi um com putador que consegue vencer seres hum anos em um j ogo de xadrez”.

Ele m e explicou que tinha usado um a abordagem com pletam ente diferente com seus robôs. Em vez de tentar construir algo com um cérebro central, sua equipe fez um robô cuj as pernas tinham , cada um a, um cérebro próprio. Além disso, um processador na espinha trabalhava com algum as regras sim ples: siga em frente, volte, não bata nas outras pernas. O chip da rede neural na cabeça do robô conhecia tais regras e agia com o um árbitro para todas as partes. Ele dizia a elas o que via através da câm era, quando ele atingia um obstáculo, por exem plo.

O que é interessante, explicou Brooks, é que cada vez que você liga o robô, ele aprende a andar pela prim eira vez. Não há banco de dados de com o as coisas estão dispostas na sala; em vez disso, o m undo é o banco de dados. O robô descobre tudo pela prim eira vez a cada vez que é ligado. Ele bate nas coisas com base no lugar em que se encontra, o que significa que pode se adaptar a qualquer am biente.

“Deixe eu m ostrar para você”, sugeriu enquanto m e levava ao laboratório. Ele enfiou um chip neural em branco em um dos robôs insectoides, e observei enquanto aquela m áquina ganhava vida. Hesitante no com eço, ele tropeçava pela sala com o um filhote de gam o8 se erguendo sobre as pernas pela prim eira vez. No entanto, a cada passo, ia se tornando m ais seguro. As pernas aprendiam rapidam ente a colaborar entre si e trabalhar j untas. Em questão de poucos m inutos, o robô corria pela sala.

Referências

Documentos relacionados

No entanto, maiores lucros com publicidade e um crescimento no uso da plataforma em smartphones e tablets não serão suficientes para o mercado se a maior rede social do mundo

Em virtude do grande impacto socioeconômico dessa doença, objetivamos realizar um levantamento epidemiológico dos pa- cientes vítimas de TRM no hospital público de Sergipe (HUSE),

Além disso, estudos que contemplam a situação de saúde da equipe de enfermagem são vastos; entretanto, ainda são necessárias pesquisas que subsidiem a visão dos

Apart from the two nuclear energy companies that were strongly hit by the earthquake effects (the Tokyo and Tohoku electric power companies), the remaining nine recorded a

Desta forma, conforme Winnicott (2000), o bebê é sensível a estas projeções inicias através da linguagem não verbal expressa nas condutas de suas mães: a forma de a

O objetivo desse estudo é realizar uma revisão sobre as estratégias fisioterapêuticas utilizadas no tratamento da lesão de LLA - labrum acetabular, relacionada à traumas

Finally,  we  can  conclude  several  findings  from  our  research.  First,  productivity  is  the  most  important  determinant  for  internationalization  that 

Como já destacado anteriormente, o campus Viamão (campus da última fase de expansão da instituição), possui o mesmo número de grupos de pesquisa que alguns dos campi