Capítulo 1 - A Maneira como o mundo funciona está quebrada

Jeff Johnson tinha quase certeza de que aquele não seria um bom dia. Em 3 de março de 2010, o Federal Bureau of Investigation (FBI) cancelou o seu projeto mais ambicioso de modernização — aquele que poderia ter evitado o 11 de setembro, mas que se transformou em um dos maiores fiascos da indústria de software de todos os tempos. Por mais de uma década, o FBI tentou atualizar seu sistema de computação, e tudo indicava que iria falhar. De novo. E agora o projeto era dele. [p. 5]

Esta história de contexto inicial ilustra um projeto em que se fracassou várias vezes. Isso nos conduz a alguns pontos:

A maneira como são feitos os processos não está clara.
Substituir algo antigo por um novo é um trabalho que muitas vezes não é fácil. Isso exige habilidade.
1. A maneira como as coisas são conduzidas importa.
2. Não é porque é novo e diferente que será melhor.
A maior parte do fracasso dos projetos está na parte de relacionamento com os interessados. As pessoas simplesmente não entendem como devem atender as expectativas.

Tratava-se do aguardado projeto para um novo sistema de computação que efetivamente trouxesse o FBI para a era moderna. Em 2010 — a era do Facebook, Twitter, Amazon e Google —, a agência ainda preenchia a maioria de seus relatórios no papel, e utilizava um sistema chamado Automated Case Support. Ele rodava em computadores gigantescos que, em algum período da década de 1980, eram o que existia de mais moderno. Mas, naquele momento, muitos agentes especiais nem o usavam mais; era ainda inconveniente e muito lento para uma época de ataques terroristas e criminosos espertos. [ibid]

Qualquer semelhança com o serviço publico brasileiro é mera coincidência. ⚠️

A questão principal é quando o antigo funciona e não há nada para substituí-lo. Nós temos sistemas que rodam emulados de um terminal IBM 360. O pagamento de todos nós, servidores públicos, roda religiosamente num mainframe.

Mudar uma estrutura de pensamento num sistema engessado só é possível(viável acredito que seria o termo mais correto) quando uma merda muito grande acontece. No caso do FBI foi o atentado de 11 de setembro.

O que tinha dado errado e como a situação foi resolvida são o motivo por que estou escrevendo este livro. Não era uma questão de inteligência. Não era que a agência não tivesse as pessoas certas nos lugares certos e também não era uma questão de tecnologia errada. Também não tinha nada a ver com ética no trabalho ou com o estímulo adequado de competitividade. Era por causa da maneira como as pessoas estavam trabalhando. A maneira como a maioria das pessoas trabalha. A maneira como nós achamos que o trabalho precisa ser feito, porque foi assim que aprendemos a fazê-lo. [p. 6]

A educação é um processo interessante. Por que é tão difícil fazer isso? Pense na seguinte situação: pergunte a um instrutor de autoescola quem ele prefere ensinar. Se é alguém que já sabe mas aprendeu errado ou se é alguém que não sabe nada e está disposto a aprender.

Reeducação é um processo lento e contínuo. E difícil.

Cada etapa do projeto está detalhadamente definida; cada evento importante, cada data de entrega. Esses diagramas são realmente algo impressionante de se ver. O único problema com eles é que estão sempre errados. Sempre. [p.6]

Sempre pense que um diagrama não reflete a realidade, mas uma perspectiva. Por exemplo, uma planta de uma casa não é a casa, mas o esboço e uma ideia de como está distribuído o espaço. Ela não diz, por exemplo, como o espaço precisa ser decorado. A questão interessante é quando a perspectiva perde a conexão com a realidade.

Ao olhar um diagrama precisamos entender qual é a perspectiva do problema. Isso nos ajuda a entender quais conclusões não podemos tirar.

É muito tentador ter todo o trabalho que precisa ser feito exposto para todos verem. Já visitei diversas empresas com funcionários cujo único trabalho é atualizar diariamente os diagramas de Gantt. O problema é que quando aquele plano elegante se depara com a realidade, ele cai por terra. Só que, em vez de descartar o plano ou o modo como pensam nele, os gerentes contratam pessoas para fazer com que pareça que o plano está funcionando. Basicamente, o que eles fazem é contratar pessoas para mentir por eles. [p.7]

Há vinte anos, eu estava desesperado. Precisava de uma nova forma de pensar sobre o trabalho. E, por meio de muita pesquisa e experiências e análise de dados passados, percebi que todos nós precisávamos de uma nova forma de organizar os empreendimentos humanos. Nada disso é ciência espacial, já se falou disso antes. Existem estudos que datam da Segunda Guerra Mundial mostrando algumas das formas como as pessoas trabalham melhor. Contudo, por algum motivo, elas nunca juntaram as peças. Nas últimas duas décadas, tentei fazer exatamente isso, E, agora, essa metodologia se tornou onipresente no primeiro campo ao qual eu a apliquei: o desenvolvimento de softwares. Em gigantes como Google, Amazon e Salesforce.com e em pequenas start-ups sobre as quais você ainda nem ouviu falar, essa estrutura mudou radicalmente a forma como as pessoas fazem as coisas. [p.7]

O motivo por que ela funciona é simples. Eu olhei a forma como as pessoas realmente trabalham, em vez de como elas dizem que trabalham. Analisei uma pesquisa realizada por décadas e as melhores práticas de empresas em todo o mundo, analisei mais a fundo as melhores equipes nessas empresas. O que as tornava superiores? O que as tornava diferentes? Por que algumas equipes atingiam resultados excepcionais e outras apenas resultados medíocres?[p.8]

O video acima é um exemplo de uma jogada de scrum do rugby de onde o termo scrum é utilizado.

Um dos principais pontos do porque os requisitos de muitos softwares e projetos não funcionam no método cascata é porque as pessoas não sabem se comunicar ou ocultam determinadas variáveis importantes. Também precisa-se considerar que elas não sabem o que querem.

Situações onde você mostra um exemplo pra elas é um facilitador de comunicação. Esse é um dos motivos pelos quais os requisitos mudam no meio do projeto. Um processo manual é diferente de um processo automatizado.

Uma vez num podcast, ouvi uma história interessante de um empresário que disse que seu filho, quando crescesse iria morar numa casa com uma babá pra ele e pra mulher dele. Do ponto de vista do filho, não imagina que quando crescer não precisará de babá! A automatização é o empresário e o trabalho manual o filho. As pessoas não entendem até verem o que a automação pode fazer por elas.

Por motivos que explicarei melhor em capítulos mais adiante, eu chamei de “Scrum” essa estrutura de desempenho de equipe. O termo vem do jogo de rúgbi e se refere à maneira como um time trabalha junto para avançar com a bola no campo. Alinhamento cuidadoso, unidade de propósito, clareza de objetivo, tudo se unindo. Trata-se de uma metáfora perfeita para o que uma equipe deseja fazer. [p.8]

O problema é que o cenário cor-de-rosa nunca vira realidade. Todo o esforço investido no planejamento, tentando restringir mudanças e adivinhar o imponderável, não serve para absolutamente nada. Todo projeto envolve a descoberta de problemas e surtos de inspiração. Qualquer tentativa de restringir o empreendimento humano de qualquer natureza a diagramas coloridos é bobagem e está fadada ao fracasso. Não é dessa maneira que as pessoas trabalham e não é dessa forma que os projetos avançam. Não é como as ideias florescem ou como as coisas excepcionais sãos feitas. [ibid]

Se você tiver mais curiosidade sobre o porquê alguns tipos de trabalho são simplesmente falácias narrativas eu sugiro os livros do Taleb. Ele é um trader estudioso de riscos e incerteza que trabalhou durante muito tempo em Wall Street. Livros famosos: o antifrágil, coloque sua pele em jogo(eu li em inglês: “skin in the game”), iludidos pelo acaso. São livros fáceis de ler, parecidos com esse, que ilustram situações sobre como não ser enrolado.

O Scrum acolhe a incerteza e a criatividade. Coloca uma estrutura em volta do processo de aprendizagem, permitindo que as equipes avaliem o que já criaram e, o mais importante, de que forma o criaram. A estrutura do Scrum busca aproveitar a maneira como as equipes realmente trabalham, dando a elas as ferramentas para se auto-organizar e, o mais importante, aprimorar rapidamente a velocidade e a qualidade de seu trabalho. [ibid]

De tempos em tempos, pare de fazer o que está fazendo, revise o que já fez e verifique se ainda deveria estar fazendo aquilo e como você pode fazê-lo melhor. É uma ideia simples, mas executá-la exige reflexão, introspecção, honestidade e disciplina. [ibid]

Eu mostrarei a vocês mais pra frente o que é uma retrospectiva. E como ela é lastreada. É um evento que ocorre depois da entrega e tem a finalidade de fazer correções de rota e planejamento.

O FBI e a Lockheed Martin não estão sozinhos nessa empreitada — já vi esse tipo de situação em quase todas as empresas nas quais trabalhei. Aquela pilha alta de futilidade é um dos motivos por que o Scrum pode ser uma mudanç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, como também destrói a alma das pessoas. [p. 9]

Então, depois de ler a pilha de documentos, eles analisaram e priorizaram cada um dos requisitos do sistema, o que é de total importância e mais difícil do que parece. Em geral, as pessoas dizem que tudo é importante. Mas a pergunta que precisa ser respondida, e foi o que as equipes do Sentinela fizeram, é: o que agregará mais valor para o projeto? Faça essas coisas primeiro. No desenvolvimento de um software existe uma regra, criada a partir de décadas de pesquisa, que afirma que 80%. do valor de qualquer parte dele está em 20% de suas funcionalidades. [ibid]

O grande visão aqui é que os erros não são planejados. Eles simplesmente acontecem.

Outro conceito ilustrado aqui é o Princípio de Pareto. (link Wikipedia)

O uso da expressão “metodologia ágil” mostra como o IG sabia pouco sobre o Scrum. O termo “ágil” data de uma reunião de 2001, na qual eu e 16 outros líderes de desenvolvimento de software escrevemos o que se tornou conhecido como “Manifesto Ágil”. Nele declaramos os seguintes valores: pessoas em vez de processos; produtos que realmente funcionem em vez de documentação dizendo como o produto deveria funcionar; trabalhar com os clientes em vez de negociar com eles; e responder às mudanças em vez de seguir um plano. Scrum é a estrutura que eu construí para colocar esses valores em prática. Não existe uma metodologia.[p.9]

Link do Manifesto Ágil

É claro que também é essencial que os membros da equipe descubram o que poderia impedi-los de acelerar. Nas palavras de Jeff Johnson: “Eu lidei com a remoção do obstáculo”. Um “obstáculo” é uma ideia que vem da empresa que concebeu várias das ideias nas quais o Scrum se baseia: a Toyota. E, para ser mais específico, do Sistema Toyota de Produção desenvolvido por Taiichi Ohno. [ibid]

A ideia de Fluxo (fluidez) → para que as coisas sejam fluídas é necessário remover o que as impede de fluir. Essa é a tarefa da gerência.

Tudo o que impede o fluxo é um desperdício. A eliminação dos desperdícios é um dos principais objetivos.

No Scrum chamamos esses ciclos de Sprint [corrida de velocidade de curta distância]. No início de cada ciclo, acontece uma reunião para planejar o Sprint. A equipe decide a quantidade de trabalho que acredita ser capaz de realizar nas duas semanas 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 semanas. [p.10]

Depois de mostrarem o que conseguiram fazer — e é aqui que as ideias de Ohno entram —, a equipe discute não o que fizeram, mas como fizeram. Eles perguntam: “Como podemos trabalhar melhor no próximo Sprint? Quais foram os obstáculos que tivemos de remover durante esse período? Quais são os obstáculos que estão diminuindo o nosso ritmo?”.[ibid]

A último parágrafo é a ideia de retrospectiva. Os sprints no nosso caso serão de um mês (eu me dirigia a minha equipe no IFSP). Nós vamos ter um backlog de necessidades e umas fichas de processos para colocarmos algumas das nossas coisas em ordem. A retrospectiva é uma das coisas mais importantes do SCRUM.

Além de descobrir a velocidade das equipes, ele também queria saber quais eram os obstáculos que as atrasava. O que ele realmente queria fazer era acelerar as equipes para que produzissem mais rápido. Mas não trabalhando mais tempo (explicarei posteriormente por que esse é um caminho inútil que acaba fazendo com que as coisas levem mais tempo), mas sim trabalhando melhor e de forma mais inteligente. Jeff relatou que suas equipes aumentaram a produtividade em um fator de três, ou seja, estavam avançando três vezes mais rápido depois que começaram a se mover, em relação ao início do projeto. O motivo? Ficaram melhores no trabalho em equipe, sim, mas o mais importante: descobriram o que os atrasava e, a cada Sprint, tentavam se livrar dos obstáculos. [ibid]

Aqui está ilustrada a ideia do que é trabalho. Você não trabalha mais tempo, você trabalha melhor. É um conceito difícil de compreender porque a maioria de nós está acostumada com tempo. A ideia linear de que se você trabalha mais tempo vai ser melhor é uma falácia enorme. O foco de todo trabalho deveria ser mais resultado.

E, na opinião dele, qual era a parte mais eficaz do Scrum? “As demonstrações. O trabalho voltado para um produto demonstrável com frequência”. A cada duas semanas a equipe do Sentinel se reunia e demonstrava tudo o que tinha conseguido. E esse sistema de mostrar e contar não era apenas para eles. A equipe levava o que tinha feito e o mostrava para as pessoas que realmente usariam o programa. Todos que tinham interesse no projeto enviavam um representante, o que significava uma apresentação com casa cheia. Gravações. Inteligência. Agentes especiais. Um funcionário do Inspetor Geral. Representantes de outras agências governamentais. Algumas vezes, o Diretor ou Vice-Diretor do FBI estava na sala, assim como o próprio Inspetor Geral. Não era um público muito fácil de se lidar. [ibid]

Essa é a parte boa. Não imagine que resultado é uma coisa gigante pronta porque não é. É algo pequeno, que pode ser feito em um ciclo curto, mas bem definido.

A ideia do Scrum é que os “porcos” são aqueles que estão completamente comprometidos com o projeto e são responsáveis diretos pelos resultados. As “galinhas” são as pessoas informadas sobre os progressos realizados, ou seja, os stakeholders ou partes interessadas. Na parede da sala do Sentinel, temos um sino na forma de uma 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 chamadas. Temos outra campainha do lado de fora, mas aquela é só para as galinhas. [p. 12]

Pra quem não conhece a história do porco e da galinha, pode ler esse capítulo.

O que o Scrum faz é promover a união das equipes para criar grandes projetos, e isso exige que todos não apenas vejam o objetivo final, mas que também façam entregas incrementais para atingi-lo. Não havia ninguém responsável pelo projeto do site Healthcare.gov que tenha insistido para que tudo fosse testado à medida que fosse desenvolvido e, infelizmente, em termos de fracasso, a história desse site dificilmente pode ser considerada atípica. [ibid]

Vamos entrar com mais profundidade neste assunto quando abordarmos a questão da missão, visão e valores.

Fim das notas do Capítulo 1