Capítulo 1
A escolha diante de nós
Para mim, uma das coisas mais instigantes da vida é volta e meia constatar que o jeito como eu pensava que o mundo funcionava estava errado. Isso significa que há uma maneira mais nova, melhor, mais exata e mais abrangente de ver o mundo. Em geral, descubro que o modo como as coisas funcionam na biologia, na ciência, nos negócios e na vida é mais intricado e integrado, mais sutil e mais aberto à mudança do que eu poderia imaginar. É incrivelmente libertador.
Isso me lembra da história por trás da publicação do revolucionário livro Tratado elementar de química, de Antoine Lavoisier, em 1789. Lavoisier propunha que, através da experimentação rigorosa, era possível chegar a princípios básicos:
É uma máxima universalmente admitida na geometria e, de fato, em todos os ramos do conhecimento que, no curso da investigação, devemos partir de fatos conhecidos para o que é desconhecido. (…) Assim, a partir de uma série de sensações, observações e análises, surge um encadeamento sucessivo de ideias tão interligadas que permite a um observador atento remontar até certo ponto a ordem e a conexão de todo o conhecimento humano.1
Lavoisier teorizou que alguns elementos químicos básicos não podiam ser decompostos. Argumentou que eles formavam as unidades fundamentais da matéria. E, assim, começou a procurá-los com rigor. Foi ele o cientista que nomeou o oxigênio, o hidrogênio e o carbono, a pessoa que descobriu o papel do oxigênio na combustão e na respiração, que mostrou que a água é composta de hidrogênio e oxigênio. Lavoisier revolucionou o campo da química. Criou uma nova linguagem para descrever como as partes que compõem a realidade interagem umas com as outras. Ou seja, descreveu de forma inteiramente nova como o mundo funciona. E foi capaz de usar os princípios básicos que estabeleceu para prever a existência de outros elementos que não chegaram a ser descobertos em seu tempo.
Antes de Lavoisier, os químicos só podiam examinar os elementos que a natureza por acaso deixava ao seu alcance. A ideia de Lavoisier era: em vez de nos limitarmos a esses elementos, por que não experimentar até que possamos encontrar o universo completo de todos os compostos químicos possíveis, não apenas aqueles com os quais convenientemente nos deparamos?
Suas ideias eram impressionantes. A publicação de seu livro se tornou um dos grandes divisores de águas da história da ciência. Antes de Lavoisier, cientistas e intelectuais presumiam que o mundo funcionava de um jeito. Depois, entendeu-se que ele funcionava de forma completamente diferente. A química moderna nasceu. O mundo se transformou. Hoje, tudo – desde os botões da sua camisa até o frio da sua geladeira, passando pela tinta deste livro ou pelos chips que acionam o dispositivo em suas mãos enquanto você lê estas palavras – existe por causa dessa descoberta.
Adoro quando esse tipo de coisa acontece, quando uma nova descoberta muda de modo fundamental a forma como vemos e entendemos o mundo em que vivemos. Quando tudo que pensávamos saber é questionado por causa de novas informações ou novos dados. Quando o mundo era de um jeito em um dia e, no seguinte, enxergamos possibilidades que não éramos capazes de conceber na véspera.
Uma nova forma de pensar
Nos anos que se passaram desde a publicação do meu primeiro livro, Scrum: A arte de fazer o dobro do trabalho na metade do tempo, que escrevi junto com meu pai, Jeff Sutherland, cada vez mais pessoas acordaram para o fato de que estamos no meio de uma mudança semelhante no que diz respeito ao modo como o mundo dos negócios funciona agora. Uma revolução está impulsionando a transformação desse setor. E, como no caso de Lavoisier, está nos mostrando um novo universo, onde os antigos limites não se aplicam mais. Ultimamente, tenho usado uma nova frase em minhas conversas com empresas, CEOs e altos executivos: “O Scrum é a arte de mudar o possível.”
A demanda pelo Scrum está sendo impulsionada por rápidas mudanças sociais, econômicas e políticas, que por sua vez estão sendo impulsionadas pela imensa velocidade dos avanços tecnológicos. Com certeza você já ouviu falar na lei de Moore, criada por Gordon Moore, cofundador da Intel. Em 1965, ele escreveu um artigo com o título “Cramming More Components into Integrated Circuits” (Como agrupar mais componentes em circuitos integrados). O que hoje é chamado de lei de Moore é a conclusão do artigo: o número de transístores em um chip dobraria a cada dois anos. Isso é crescimento exponencial. Ah, e ao mesmo tempo o preço desse aumento na capacidade de processamento seria reduzido pela metade.
Não somos capazes de perceber a velocidade dessas mudanças. É quase impossível tentar entender o que virá a seguir. Permita-me compartilhar uma velha charada francesa para crianças com o intuito de ilustrar a rapidez com que tudo está acontecendo. Digamos que você se depare com um belo lago cheio de lírios – talvez o de Giverny, tão famoso por todos aqueles quadros de Monet. Imagine: água parada, lírios flutuando, talvez uma pequena ponte, o céu e as árvores emoldurando o lago, pintando-o com seus reflexos.
Agora digamos que o número de lírios no lago dobra todos os dias. Daqui a 30 dias, eles cobrirão por completo a superfície da água, sufocando o lago com pétalas. Sem querer, eles matarão todas as formas de vida – peixes, sapos e até a si próprios. Mas ainda há tempo para salvar o lago, certo? E, no fim das contas, os lírios são lindos. Se você decidir esperar até que os lírios tenham coberto metade da superfície para intervir, quantos dias terá para salvar o lago?
Um. Apenas um. No dia 29 os lírios terão coberto metade do lago. No dia seguinte, cobrirão tudo.
Vou dar outro exemplo do ritmo que uma duplicação de transistores e capacidade de processamento impõe. Vamos usar a famosa parábola de grãos de trigo em um tabuleiro de xadrez, que remonta ao ano de 1256 (o que já indica que as pessoas vêm pensando sobre esse tipo de assunto há muito tempo). Se você colocasse um grão de trigo em uma casa de um tabuleiro de xadrez e, em seguida, dobrasse o número de grãos em cada casa subsequente, no momento em que chegasse à última casa teria dobrado 63 vezes. Essa última casa teria cerca de 9 quintilhões (9.223.372.036.854.775.808, para ser exato) de grãos de trigo. É um número grande, bem grande. Incompreensível. Intangível. E esse é o ritmo da mudança que estamos vivendo. As velhas formas de trabalhar estão se desintegrando diante de problemas que se transformam rápido demais e que estão simplesmente além de sua capacidade de enfrentamento. A complexidade não é mais algo raro, é algo com o qual temos que lidar todos os dias.
O que acontece depois do que vem a seguir
O Scrum é a forma pela qual uma pessoa, uma equipe ou uma organização se torna capaz de responder a essa complexidade, de responder a metamorfoses que não podem ser previstas, de se mover com agilidade e entusiasmo através de um espaço de problemas em constante transformação. O ritmo das mudanças pelas quais estamos passando exige uma maneira diferente de trabalhar. O Scrum é uma resposta para isso.
No entanto, para realmente obter o poder do Scrum, o tipo de aumento drástico de produtividade e entrega de valor que ele proporciona, é preciso haver uma mudança fundamental na gestão e nas operações. Embora algumas equipes Scrum possam concluir seus projetos com grande velocidade, o que queremos de fato é o Scrum no nível corporativo. As estruturas tradicionais têm que mudar, assim como os incentivos e a gestão do desempenho. Mesmo que não façam parte das equipes Scrum propriamente ditas, todos os membros da organização devem aprender como interagir com elas, fornecer o que elas precisam, ajudá-las e gerenciá-las de uma nova forma.
Quando compreendem de fato o escopo da transformação necessária, aqueles que trabalham em organizações tradicionais às vezes simplesmente jogam a toalha. Há burocracia demais, história demais, procedimentos corporativos demais em empresas estabelecidas. Não podemos simplesmente mudar tudo, dizem os gerentes, não é assim que trabalhamos por aqui. E, se as coisas dão errado, eles começam a procurar alguém para culpar.
Não importa quem foi responsável pelo sucesso ou fracasso de uma empresa, nem como o dinheiro foi gasto, nem o que deu errado. A única coisa que importa é: o que acontece depois do que vem a seguir? O passado é passado. Isso é verdade nos negócios, na política e nos relacionamentos. Como você quer que seja o futuro? Como pode se posicionar para tirar proveito das mudanças que sabe serem necessárias? Como incutir na sua equipe, no seu departamento ou na sua empresa não apenas resiliência, mas um sistema que realmente ajude a equipe a se fortalecer toda vez que um problema for encontrado? Como podemos construir um sistema robusto o suficiente para que, sempre que um desastre acontecer, sua organização não apenas se recupere, mas aprenda, cresça e aumente sua capacidade?
As melhores organizações aprendem com seus erros e sucessos e, em seguida, usam essas lições de modo sistemático para se aperfeiçoar. Como costumo dizer às minhas equipes quando me trazem algo que deu errado: “Ótimo. Agora sabemos que isso não funciona. Da próxima vez, tragam-me um erro mais interessante.”
O que você realmente quer é o que eu chamo de uma “empresa renascentista” – isto é, uma empresa que se libertou dos grilhões do passado, das velhas formas de olhar o mundo, e agora é capaz de criar coisas que eram inimagináveis poucos anos atrás. Precisamos de uma lei de Moore para as pessoas. Como nós mesmos podemos nos tornar mais rápidos, eficientes e produtivos? E como fazer isso em escala?
Um mundo feito de Lego
Venha comigo para o norte da Europa, até a Suécia – lar da Ikea, da trilogia Millenium, da banda pop ABBA e do sol da meia-noite. A Suécia também é o lar da Saab. Você talvez conheça a Saab como uma fabricante de automóveis, mas fazer carros sempre foi uma atividade secundária para a empresa. Na verdade, o principal negócio da Saab é fabricar aviões de combate.
Desde o fim da Era Napoleônica, a Suécia tem uma política oficial de neutralidade, semelhante à da Suíça. E foi capaz de manter essa política oficialmente em meio à Segunda Guerra Mundial e à Guerra Fria. Mas ter a OTAN de um lado e a URSS de outro era, digamos, uma situação estressante para os nossos bons amigos do Norte.
A Saab vem construindo caças desde 1937. Na época, era óbvio que o mundo estava prestes a entrar em um conflito mundial, e os suecos, que não estavam alinhados com nenhuma nação ou nenhum grupo, decidiram montar sua força aérea. Em 1950, apresentaram o caça Saab 29 Tunnan, uma aeronave que era páreo para os melhores caças a jato do mundo na época. Fabricaram cerca de 55 esquadrilhas operacionais, muitas em alerta e capazes de decolar em 60 segundos. Com o tempo, começaram a vender seus aviões para vários países: Áustria, Brasil, África do Sul, Tailândia e outros.
Após o Tunnan, vieram o Lansen, o Draken e depois, na década de 1980, o Gripen A/B, seguido pelo C/D. E então eles tiveram um problema. O Gripen era um bom avião e vendia muito bem, mas a Saab e as Forças Armadas da Suécia queriam modernizá-lo, torná-lo mais poderoso, dar-lhe um alcance maior e armas melhores. E foi assim que surgiu a ideia do Gripen E.
No início, os engenheiros da Saab iam simplesmente modernizar cerca de 60 Gripens 39C já existentes, porque, afinal de contas, aviões são caros e difíceis de fabricar. Em algum momento dessa atualização das aeronaves eles adotaram o Scrum – a princípio apenas na equipe de software, mas logo a ideia se espalhou: para o pessoal de design, de engenharia, de controle de qualidade, enfim, para toda a empresa. O Scrum@Scale é uma estrutura organizacional modular, com equipes multifuncionais que entregam valor com rapidez. Mas, à medida que ele se espalhava pela Saab, os líderes da empresa tiveram uma nova ideia radical: e se o avião refletisse a estrutura organizacional da empresa?
Queremos uma aeronave que tenha potencial para voar por 50 anos, decidiu a Saab. Sabemos que a tecnologia mudará de forma radical ao longo das décadas. Os projetos atuais de aeronaves são muito difíceis de atualizar, pois estão fortemente interligados, cada parte atrelada a todas as outras. E se construirmos um avião que seja modular, que possa ser facilmente desmontado e montado de novo, como uma organização de equipes Scrum? Poderíamos atualizar sistemas inteiros o tempo todo. Não precisaríamos esperar por um programa de modernização totalmente novo. Em vez disso, por que não fazer com que, caso surjam novos radares ou novos computadores ou um motor melhor, possamos simplesmente remover o antigo e conectar o novo, sem ter que tocar no resto do avião? E se fabricássemos um caça como se fosse feito de Lego?
“Queremos que seja um sistema plug-and-play”, disse Jörgen Furuhjelm, da Saab, referindo-se a um sistema em que é possível encaixar uma nova peça e pô-la para funcionar. “É o que chamamos de um caça inteligente. Não sabemos o que nossos clientes vão querer daqui a alguns anos.”
É preciso desenvolver um motor melhor? Sem problema, basta trocá-lo. Radar melhorado? Feito. Armas mais sofisticadas? Pronto. A filosofia da Saab permite que o Gripen faça coisas que pareciam impossíveis. Ele é capaz de pousar em uma estrada em condições climáticas extremas. Pode ser reabastecido e rearmado em menos de 10 minutos – são necessárias apenas seis pessoas e nenhuma ferramenta especial. A maioria dos outros caças leva de duas a três vezes mais tempo. A Saab pode trocar um motor em uma hora. É isso que a modularidade proporciona.
E a empresa é considerada pelos funcionários um lugar divertido. A única companhia que ultrapassa a Saab no ranking de melhores lugares para se trabalhar, segundo os estudantes de engenharia suecos, é a Google. E, ao contrário da maioria das empresas do mundo, onde a maior parte das pessoas preferiria fazer praticamente qualquer outra coisa a ir para o escritório, os funcionários da Saab querem ir todo dia para o trabalho.
“O segredo é o comprometimento. As pessoas acham que o projeto é realmente legal. Elas gostam de aviões. E existe um senso de comprometimento nas equipes que chega a ser quase palpável”, conta Furuhjelm.
Este é o poder do Scrum. Ele liberta as pessoas para trabalhar com mais rapidez, de forma mais produtiva e para realizar mais trabalho em menos tempo. Permite que as equipes façam seu serviço com paixão e sem impedimentos. Quando abraçou o Scrum, a Saab descobriu que o simples fato de se concentrar em tirar os obstáculos do caminho de seus funcionários era capaz de liberar uma quantidade incrível de potencial humano.
Embora o Gripen E seja simplesmente melhor – com peças melhores, equipamento melhor, enfim, tudo melhor – que seu antecessor, ele é mais barato de desenvolver, fabricar e operar. Manter 150 Gripens no ar por 40 anos custaria cerca de 22 bilhões de dólares. Isso é cerca de metade do que seria gasto para manter apenas 65 F35 americanos.
E isso foi possível com o Scrum. A Saab construiu um caça altamente avançado do zero. Muitas vezes trabalho em empresas cujos gestores dizem: “Ah, a estrutura do Scrum é boa para desenvolver softwares. O que estamos fazendo é complexo demais para isso.” É nesse ponto que geralmente começo a contar sobre o Gripen e comento: “Tenho certeza de que o que você está fazendo ou fabricando não é mais complexo que um avião de caça.”
Scrum e Ágil
Nos últimos anos, o Scrum, muitas vezes sob a bandeira do Ágil, tornou-se onipresente. Ele já mudou não só o modo como empresas de software e tecnologia funcionam, mas cada vez mais a forma como grandes companhias de quase todos os setores trabalham. Negócios do setor bancário, montadoras de automóveis, fabricantes de equipamentos médicos, firmas de biotecnologia, seguradoras, empresas da área da saúde, entre outros, recorreram ao Ágil para permanecer relevantes hoje. Algumas das maiores empresas do mundo, como Bosch, Coca-Cola, USAA, Schlumberger, Fidelity e Lockheed Martin, usaram o Scrum para entregar valor e qualidade na velocidade que seus clientes agora consideram essencial.
Muito disso tem sido impulsionado pelo que frequentemente chamamos de transformações digitais. A ideia é que acabou o tempo em que negócios e TI ficavam separados. Hoje, toda organização é uma empresa de tecnologia. E os softwares já tomaram conta do mundo. Existem mais linhas de código no seu carro do que no Windows. Imagine só, minha nova máquina de lavar quer a senha do wi-fi!
E agora as empresas – muitas vezes estimuladas por um CEO que assistiu a uma palestra no TED ou ouviu falar sobre os benefícios do Ágil por seus colegas ou por uma consultoria – decidem que, de um jeito ou de outro, vão se tornar Ágeis.
Neste ponto, acho que é bom eu definir o termo Ágil e como o Scrum se relaciona com ele. O Scrum foi inventado em 1993 e formalizado por seus dois criadores, Jeff Sutherland e Ken Schwaber, em 1995. Em meados da década de 1990, em grupos na Usenet e em conferências, havia muitas pessoas com dificuldade para encontrar formas de desenvolver softwares que não tivessem a terrível taxa de falhas que estava se tornando cada vez mais comum.
Em 2001, 17 dessas pessoas se reuniram por alguns dias em um resort de esqui em Snowbird, no estado americano de Utah. Meu pai, Jeff Sutherland, estava lá, assim como Ken Schwaber e outro pioneiro na adoção do Scrum, Mike Beedle. As outras 14 pessoas vinham de diferentes setores e metodologias, mas reconheciam que estavam todas tentando lidar com os mesmos problemas de formas parecidas, se não exatamente do mesmo jeito.
De acordo com o que algumas pessoas que estavam lá me contaram, no primeiro dia todos discutiram. Debateram principalmente sobre como chamariam aquela espécie de guarda-chuva que sabiam que estava lá mas que ainda não tinha nome. Perto do final do dia, Mike Beedle sugeriu Ágil. Todos acharam que esse nome seria mais fácil de vender do que alguns dos outros finalistas, como Leve. Então se decidiram por Ágil. Em seguida, começaram a discutir sobre o que isso significava.
No dia seguinte, debateram mais um pouco. Certo, o nome era Ágil, mas o que isso de fato significava? Como poderia ser descrito? Bem, nove das pessoas presentes decidiram sair e fazer uma pausa, enquanto as outras oito ficaram na sala. Uma delas, Martin Fowler, foi até o quadro branco e disse algo do tipo: “Seria uma pena se não conseguíssemos chegar a um acordo sobre pelo menos uma coisa durante esses dois dias…” Em cerca de 15 minutos, as oito pessoas naquela sala chegaram ao seguinte:
Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Por meio deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos últimos itens de cada tópico, valorizamos mais os primeiros.
Quinze minutos depois, quando os outros nove voltaram, um deles, Ward Cunningham – o inventor da wiki, a tecnologia de edição colaborativa usada na Wikipédia, entre outras coisas –, disse: “Isso é incrível!” Nenhuma palavra foi alterada.
Então isso é o Ágil: uma declaração de valores. Eles passaram o resto do dia desenvolvendo 12 princípios, como “Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial”, “Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessários e confie neles para fazer o trabalho” e “A atenção contínua à excelência técnica e ao design eficiente aumenta a agilidade”. Tudo isso é ótimo, mas não é uma descrição de como pôr esses princípios em prática. Não havia estrutura nem metodologia, apenas quatro valores e alguns princípios de bom senso.
E isso mudou o mundo. Eles colocaram o Manifesto Ágil em um site, agilemanifesto.org, e foram para casa continuar o trabalho duro de pôr tudo aquilo em prática. Não faziam ideia do impacto que o manifesto teria para além do mundo do software.
Mas quero fazer um alerta: quando uma pessoa diz que trabalha de forma Ágil, é muito importante perguntar o que exatamente ela quer dizer com isso. O Scrum é, de longe, a maneira mais popular de fazê-lo – cerca de 70% das equipes Ágeis usam o Scrum. Não é o único método, mas simplesmente dizer que uma empresa é Ágil não significa muita coisa.
A lei de Moore para pessoas
Se você nunca ouviu falar do Scrum, ou mesmo se você já tiver ouvido falar mas ainda não tiver certeza de como ele pode ajudar o seu negócio, deixe-me explicar de forma resumida a história dele, de onde vem e o que se propõe a fazer.
Desde os anos 1980, as pessoas no Vale do Silício se preocupam com o impacto da lei de Moore sobre o crescimento acelerado da tecnologia. À medida que as máquinas que construímos foram aumentando sua capacidade, os projetos de software ficaram mais complexos e, infelizmente, o fracasso desses projetos se tornou mais comum, levando a desperdícios cada vez maiores de tempo, energia, produtividade e sonhos.
Tomemos como exemplo o projeto TAURUS, da Bolsa de Valores de Londres, nessa época. TAURUS é um acrônimo para Transfer and Automated Registration of Uncertified Stock (Transferência e Registro Automatizado de Ações Não Certificadas). O problema era que o sistema de liquidação da Bolsa usava um sistema chamado Talisman. Liquidação é uma palavra chique para “receber o que você comprou”. Então, depois que você comprava uma ação na Bolsa, a transferência dela para sua carteira de ações poderia levar de duas a três semanas, e esse processo envolvia o envio de certificados de ações em papel de um lugar para outro. O sistema de compra e venda chamava-se Seaq. Era eletrônico, mas não conseguia se comunicar com o sistema Talisman, vários anos mais antigo que ele.
O projeto TAURUS deveria consertar isso. Seria um sistema de liquidação eletrônico que substituiria o antigo em papel e, além disso, seria conectado a sistemas de liquidação internacionais, permitindo a negociação de valores mobiliários com outros países. Seria maravilhoso. Mas os operadores individuais precisavam de uma coisa e os institucionais, de outra. A maioria dos operadores também queria que o TAURUS conversasse com seus sistemas customizados em vez de substituí-los. Então mais e mais funções começaram a ser exigidas do programa TAURUS.
Ainda assim, seria incrível. Ele se integraria a cerca de 17 sistemas diferentes. Impressionante. Mas, de acordo com o que Hamish McRae escreveu no jornal The Independent em 12 de março de 1993, havia três problemas. Em primeiro lugar, construir enormes sistemas de software do zero e gerar um “Big Bang” é incrivelmente arriscado. Não pode haver falhas. O menor dos erros seria catastrófico. No entanto, essa abordagem era comum na época – e pode ser vista até hoje. As empresas fazem grandes apostas de que um sistema enorme resolverá tudo a partir do momento em que for posto para funcionar. De acordo com dados do Standish Group, cerca de 40% dos projetos feitos dessa maneira fracassam totalmente.2 Metade deles atrasa, estoura o orçamento e não consegue solucionar as questões que deveria. No caso do TAURUS, isso significava que eram mínimas as chances de sucesso de um sistema que deveria substituir completamente o sistema de liquidação em um dos maiores centros financeiros do mundo.
Em segundo lugar, apontou McRae, um sistema muito bom que funcione é infinitamente preferível à busca de um sistema perfeito que não funcione. Como se diz: o perfeito é inimigo do bom. No projeto TAURUS, como em quase todos os projetos em qualquer lugar, o que chamamos de scope creep – isto é, o aumento incessante de escopo e complexidade em relação ao plano inicial – acabou sendo a sua sentença de morte. Não seria ótimo se esse novo sistema fizesse não só tudo aquilo que já pensamos e pedimos que ele faça, mas também esta outra tarefa? E se preparasse um café expresso perfeito enquanto as pessoas estão esperando uma negociação ser finalizada, não seria ainda mais incrível?, e assim por diante. Por fim, um projeto que era simples e bem definido no começo se transforma em uma geringonça com a missão de fazer tudo para todos. E, claro, acaba não sendo capaz nem mesmo de realizar as tarefas mais simples que seus idealizadores planejaram no início.
Isso é muito comum nas empresas que usam o sistema SAP. O SAP é líder de mercado nos chamados sistemas de Planejamento de Recursos empresariais (ERP, na sigla em inglês). Sistemas ERP devem fazer de tudo. São bancos de dados gigantescos que rastreiam recursos, como dinheiro, matéria-prima ou capacidade de produção, e os combinam com folha de pagamento, faturas, pedidos e assim por diante. Portanto, um sistema ERP entra em contato com todas as áreas de uma empresa – suprimentos, vendas, RH, contabilidade, produção, ou seja, praticamente tudo mesmo – e as integra digitalmente. O sistema funciona muito bem se você usar seu “modelo básico”, isto é, sem customizações.
O problema surge quando, como aconteceu com o TAURUS, as pessoas ficam entusiasmadas com sua solução mágica para tudo: integrar todos os sistemas, conversar com os mainframes antigos no porão, lidar com o que está na nuvem, costurar todos os retalhos de sistemas improvisados de vários departamentos. (Ou substituí-los completamente! Por algo melhor!) E assim começam as incessantes mudanças no escopo. Que tal se o fizermos se comunicar com esse sistema que já usamos há 30 anos? Ou: Ele deveria incluir todos os recursos daquele software que compramos há 20 anos e não é mais atualizado. A lista é interminável.
Nos últimos seis meses, trabalhei com três empresas globais que tentam há mais de uma década implementar o SAP. Em uma gigante do mercado de bebidas, depois que falei sobre como deveríamos manter as coisas simples, um engenheiro se aproximou de mim e falou em voz baixa: “Já gastamos mais de 1 bilhão de dólares com isso. E ainda não está funcionando.” Em outra empresa com centenas de milhares de funcionários trabalhando em algumas das áreas mais remotas do planeta, disseram-me que 1 bilhão de dólares era pouco. Eles haviam gasto 1,5 bilhão no SAP e não tinha dado certo. Não vou deprimir você com o terceiro exemplo. Acredite em mim: é ruim. Todas as três empresas tinham uma coisa em comum: apesar daqueles bilhões de dólares e milhares de pessoas, o sistema não funcionava. E ainda assim eles continuam jogando mais centenas de milhões de dólares por ano no problema, fazendo tudo do mesmo jeito e esperando resultados diferentes.
Mas voltemos ao TAURUS, aquela joia perfeita em forma de sistema de liquidação, e àquelas pobres almas com a tarefa hercúlea de integrar 17 propostas diferentes de como o sistema deveria funcionar, fazendo de tudo para todo mundo. E a equipe tentou. Tentou de verdade.
Sobre o terceiro problema do TAURUS, vou apenas citar um parágrafo de McRae:
A Bolsa de Valores não tem escutado seus clientes. Ela conta com muitos tipos diferentes: as firmas-membro, as empresas cujas ações são negociadas, os investidores institucionais, os investidores pessoais. Os membros estavam preocupados com os custos do TAURUS; as empresas estavam descontentes (e algumas tinham se recusado a ajudar); as instituições eram, na melhor das hipóteses, indiferentes ou, na pior, hostis; e qualquer pequeno investidor que soubesse do projeto estava preocupado com as taxas adicionais que provavelmente teria que pagar. É preciso uma arrogância bem particular para insistir em algo quando há esse tipo de resistência.
“Uma arrogância bem particular” – a arrogância do especialista. A arrogância do profissional. A arrogância do burocrata. A arrogância do processo acima das pessoas, de dar mais valor a descrições intricadas de coisas que funcionam do que às coisas em si. A insistência egoísta de que um plano complicado ao qual se dedicaram com afinco era melhor que a ideia mais prudente de que as coisas poderiam mudar e talvez fosse bom se planejar para isso.
Assim o TAURUS, que nasceu como uma linda ideia, foi cancelado em 1993, depois de anos de esforços, milhares de pessoas trabalhando o dia inteiro e madrugada adentro e uns 75 milhões de libras jogados no lixo. O impacto total de custos para os investidores é estimado em cerca de 400 milhões de libras.
Isso é muito dinheiro. Mas também muito tempo perdido e muitas vidas desperdiçadas. Um grupo de pessoas realmente inteligentes dedicou anos a criar algo que se tornou sinônimo de desastre tecnológico.
E bem que eu gostaria de poder lhe dizer que o TAURUS é um dos piores exemplos que posso dar, mas não é. Existem muitos outros. O projeto Connecting for Health, do Sistema Nacional de Saúde do Reino Unido, deveria criar registros de saúde eletrônicos: nove anos desperdiçados, a um custo de 12 bilhões de libras. O Sistema de Suporte de Combate Expedicionário para as Forças Armadas dos Estados Unidos: sete anos perdidos, a um custo de 1,1 bilhão de dólares. O Departamento de Trânsito da Califórnia gastou dezenas de milhões de dólares a partir de 1987 para construir um sistema que, em 1990, era pior que o sistema que deveria substituir – e ainda assim eles só conseguiram desistir em 1994. O San Francisco Chronicle descreveu o projeto como “um sistema impraticável que não poderia ser consertado sem que fossem gastos mais alguns milhões de dólares”.
Nossas máquinas se tornaram mais rápidas e mais capazes, mas nós, humanos, não conseguíamos acompanhá-las – esse era o contexto em que meu pai estava trabalhando no início da década de 1990. Se você quiser a história completa do que aconteceu, leia Scrum: A arte de fazer o dobro do trabalho na metade do tempo. Mas, em suma, ele pensou em uma nova forma de trabalhar. Seu insight crítico era que esses tipos de fracasso não eram culpa das pessoas envolvidas. Os gestores, desenvolvedores e designers nesses projetos gigantescos que deram errado não eram pessoas ruins. Não eram burros. Não falharam porque queriam. Tinham começado o processo sonhando alto e com o desejo de fazer a diferença, de mudar o jeito como o mundo fazia as coisas.
Não foram as pessoas que falharam, foi o sistema. Foi o modo como estavam trabalhando, como pensavam sobre o que devia acontecer quando iam às reuniões para discutir e planejar seus esforços. Para elas, era simplesmente assim que as coisas eram feitas. Trabalhar de qualquer outra forma seria como se um peixe questionasse o profundo envolvimento de sua espécie com a água.
Um manual de sobrevivência
As pessoas cujos empregos correm risco por causa da automação na verdade não são diferentes das empresas cuja razão de existir está sob constante ameaça. Não importa se você está fazendo escolhas pessoais sobre seu trabalho, planejando as metas estratégicas para uma grande multinacional ou decidindo como uma cultura se adaptará a uma nova série de circunstâncias com um conjunto de axiomas muito diferentes: o que determinará seu sucesso é a capacidade de se adaptar rapidamente. Como meu pai e eu escrevemos em nosso livro anterior: mude ou morra.
Neste livro, porém, quero oferecer mais algumas ferramentas. Vou levá-lo em uma viagem ao redor do mundo, do espaço sideral a centrais de atendimento, de novas tecnologias radicais a um restaurante. As tendências podem parecer assustadoras, mas realmente acredito que podemos aprender a abraçar a mudança, nos tornando mais resilientes e menos amedrontados, capazes de realizar mais, parando de lamentar o que não podemos mais fazer e agindo com propósito global em vez de sermos prisioneiros das forças ao nosso redor.
Porque a verdade é que o Scrum sozinho não faz nada. Ele apenas liberta a grandeza que vive dentro de todos nós. Essa grandeza está lá. Pode estar escondida ou abatida, mas nunca é perdida para sempre. É o que nós, humanos, somos.
Um dia pensamos que as coisas funcionam de um jeito; no dia seguinte, descobrimos que estávamos enganados. Em um segundo, podemos perceber que estivemos observando o mundo através de uma lente estreita, que existe um universo de possibilidades que nunca imaginamos, e agora, de repente, podemos reformular o modo como o mundo funciona… e, na verdade, sempre pudemos.
Resumo
O Scrum é a arte de mudar o possível. Você pode se adaptar a este mundo de mudanças cada vez mais aceleradas e ver do que você, sua organização, seus colegas e sua equipe são realmente capazes. Esteja você fazendo escolhas pessoais sobre seu trabalho ou planejando as metas estratégicas para uma grande multinacional, a capacidade de se adaptar rapidamente determinará seu destino.
O fracasso é inevitável e inestimável. Não importa quem foi responsável pelo sucesso ou pelo fracasso de uma empresa, como o dinheiro foi gasto ou o que deu errado. As melhores organizações aprendem com seus erros e sucessos e, em seguida, usam essas lições para melhorar.
A perfeição é superestimada. Um bom sistema que funcione é infinitamente preferível à busca de um sistema perfeito que não funcione.
Backlog
Analise cada um dos quatro valores do Manifesto Ágil e avalie quão Ágeis você e sua organização são. Lembre-se: “mesmo havendo valor nos últimos itens de cada tópico, valorizamos mais os primeiros”.
Indivíduos e interações mais que processos e ferramentas
Software (produto ou serviço) em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Examine como sua organização reage a uma falha ou um fracasso. É uma oportunidade de aprendizado valiosa ou um momento de apontar culpados?
Avalie a sua capacidade de adaptação e inovação, e também a de sua organização. Com que facilidade você consegue acompanhar as mudanças em demandas, desejos e necessidades? Você é um disruptor ou está esperando o momento em que se tornará irrelevante? O que está ajudando ou prejudicando sua capacidade de reagir à mudança?
LEIA MAIS
