Scrum

O sistema usado pelo FBI para reorganizar e agilizar os métodos de investigação após os atentados de 11 de setembro de 2001

Ideias centrais:

1 – O sistema Scrum ajudou a reorganizar e agilizar os métodos do FBI, após o 11 de Setembro. De que forma? Definindo os objetivos sequenciais em prazos demarcados. Com prazos de execução e orçamentos drasticamente reduzidos, o sistema teve impacto impressionante na poderosa agência.

2 – Segundo pesquisa de Putnam, equipes que tinham mais de oito integrantes demoravam muito mais para concluir as tarefas. Equipes de três a sete pessoas despendiam cerca de 25% do esforço das que tinham entre nove e 20 membros.

3 – Uma equipe deve manter reuniões diárias, de no máximo 15 minutos. O encontro deve ocorrer no mesmo horário, todos os dias. Todos têm de estar presentes e participar ativamente, ficando de pé durante a reunião.

4 – O que realmente faz as pessoas felizes? São as mesmas coisas que produzem grandes equipes: autonomia, domínio e propósito. É a capacidade de controlar o próprio destino, a sensação de estar melhorando em alguma atividade, de estar servindo a um propósito maior.

5 – O ideal é trabalhar primeiro nas tarefas que agregam mais valor e trazem menos riscos. Com as entregas graduais do scrum, o objetivo é começar com elementos que geram receita imediatamente, de modo a eliminar os “riscos” do projeto, os chamados “micos”.

Sobre os autores:

Jeff Sutherland é CEO da Scrum Inc. e consultor sênior da OpenView Venture Partners, onde oferece coaching para empresas de investimento de capital de risco. Cocriador do Scrum e o maior especialista do método, estendeu seus benefícios no desenvolvimento de software para outros segmentos, como finanças, saúde e telecomunicação.

J. J. Sutherland, jornalista, passou a maior parte da carreira cobrindo guerras, conflitos, revoluções, desastres e ataques terroristas para o National Public Radio, dos Estados Unidos. Hoje, escreve e presta consultoria para corporações e ONGs sobre como utilizar o Scrum.

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

Capítulo 1 – A maneira como o mundo funciona está errada

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

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

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

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

Jeff Johnson sabia que o sistema Scrum podia resolver o impasse. Para que o Scrum funcione de fato, alguém do alto escalão da gerência precisa compreender a fundo que os obstáculos são praticamente criminosos. A equipe do Sentinel levou cerca de três meses para descobrir quanto tempo realmente seria necessário para concluir o projeto. Por quê? A resposta nos remete àquele ciclo de “inspeção e adaptação”. O Scrum funciona com definição de objetivos sequenciais, que devem ser atingidos em um prazo definido.

Após reexame do projeto da Lockheed, concluiu-se que o Sentinel seria possível finalizar se o desenvolvimento fosse feito pela própria agência e se o número de desenvolvedores fosse reduzido. Com isso, eles entregariam a parte mais difícil do projeto em menos de um quinto do tempo estimado e por menos de um décimo da quantia orçada.

O sistema teve impacto impressionante no FBI. A capacidade de comunicação e compartilhamento de informações mudou de maneira fundamental o que a agência é capaz de fazer. Em janeiro de 2013, um agente do FBI foi chamado quando uma conta de uma pequena empresa foi hackeada. A quantia de 1 milhão de dólares tinha sido transferida para outro país antes que os bancos americanos pudessem impedir. Usando o Sentinel, o escritório local foi capaz de coordenar uma ação conjunta com a embaixada do país de destino. A embaixada alertou as autoridades locais, que por sua vez impediram que a transferência fosse concluída no sistema bancário.

Capítulo 2 – A origem do Scrum

Eu havia trabalhado na MidContinent e havia colaborado para colocar os caixas eletrônicos em funcionamento nos EUA e mundo afora. Nos 20 anos seguintes, acabei trabalhando em várias empresas como vice-presidente de engenharia. Aconteceu algo insólito quando estava próximo da empresa do pessoal do MIT, em Cambridge, Massachusetts. Esta havia sublocado um espaço na minha empresa. Essa empresa era fabricante de robôs. Num determinado dia, um robô de seis pernas entrou na minha sala e me perseguia. Perguntei ao pessoal da robótica como isso podia acontecer. Então, apareceu Rodney Brooks, um dos fundadores da empresa de robôs, para esclarecer.

Rodney me explicou que tinha usado uma abordagem completamente diferente com seus robôs. Em vez de projetar uma máquina com um único cérebro central, sua equipe construiu um robô em que cada uma das seis pernas tinha o próprio cérebro. Um processador no esqueleto tinha algumas regras simples: ande para a frente, para trás, não bata nas outras pernas. O chip da rede neural na cabeça do robô sabia essas regras e agia como árbitro para todas as partes do corpo. Quando encontrava um obstáculo, ele relatava às pernas o que via através da câmera.

O trabalho de Rodney Brooks me inspirou. Em 1993, levei aquelas ideias comigo para uma empresa chamada Easel, que me contratara como vice-presidente de tecnologia. Os executivos da companhia queriam que a minha equipe desenvolvesse em seis meses uma nova linha de produtos que seria oferecida a alguns dos seus maiores clientes – como a Ford, que usava o software deles para projetar e desenvolver funcionalidades internas. Eu me reuni com minha equipe de desenvolvimento e disse que sabia que não era possível fazer aquilo usando o velho modelo de desenvolvimento de softwares.

Certo dia, um dos desenvolvedores trouxe um artigo publicado na Harvard Business Review em 1986, escrito por dois professores de administração japoneses, Hirotaka Takeuchi e Ikujiro Nonaka. O título era “The New New Product Development Game”. Takeuchi e Nonaka tinham analisado equipes de algumas das empresas mais produtivas e inovadoras do mundo. Eles argumentavam que o velho método usado para o desenvolvimento de produtos, simbolizado pelo sistema de Planejamento de Programas em Fase da Nasa – um sistema em cascata –, era completamente falho. Em vez dele, as melhores empresas usavam um processo de desenvolvimento em sobreposição que era mais rápido e mais flexível. As equipes eram multifuncionais. Tinham autonomia.

Os professores japoneses comparavam o trabalho em equipe a um time de rúgbi e diziam que as melhores equipes agiam como se estivessem em um scrum: “A bola é passada pelo time conforme avança, em unidade, pelo campo.”

Na Easel, não tínhamos nada a perder. Decidimos experimentar a nova abordagem, ainda que o foco do artigo fosse a fabricação de produtos, não o desenvolvimento de softwares. Achei que aquelas ideias abordavam um ponto fundamental, um processo descritivo de como os seres humanos trabalham melhor juntos em qualquer empreitada. Elas tinham estado presentes em todas as outras experiências que eu já conduzira desde meu primeiro emprego no setor privado, na MidContinent.

Esse foi o nascimento formal do Scrum. Entregamos o produto na Easel dentro do prazo de seis meses, sem gastar todo o orçamento e com menos bugs do que qualquer outra entrega anterior. Em 1995, em uma conferência de pesquisa da Association for Computing Machinery, apresentei, com Ken Schwaber, um artigo intitulado “SCRUM Development Process” (Processo de Desenvolvimento SCRUM), que sistematizava essas práticas. Dali em diante, meu trabalho se concentrou no refinamento do Scrum para empresas.

Capítulo 3 – Equipes

Lawrence Putnam é uma figura lendária na área de desenvolvimento de softwares e ele dedicou sua vida a estudar quanto tempo se gasta para fazer as coisas e por quê. Seu trabalho mostrou repetidamente que projetos com 20 pessoas ou mais demandavam mais esforço – muito mais. Uma equipe grande demorava cerca de cinco vezes mais horas do que uma pequena. Ele viu isso se repetir em diversas ocasiões e, em meados da década de 1990, resolveu realizar um estudo abrangente para tentar determinar o tamanho da equipe ideal. Analisou 491 projetos de médio porte em centenas de empresas. Todos eles exigiam a criação de novos produtos ou funcionalidades, não uma reformatação de versões antigas. Putnam dividiu os projetos conforme o tamanho das equipes e notou algo logo de início. Quando tinham mais do que oito integrantes, elas demoravam muito mais para concluir as tarefas. Equipes de três a sete pessoas despendiam cerca de 25% do esforço das que tinham entre nove e 20 membros para realizar o mesmo trabalho.

Na época da primeira equipe de Scrum, eu mostrava aos integrantes da equipe, com frequência, um vídeo do All Blacks se preparando para uma partida. O All Blacks, um time de rúgbi lendário da diminuta Nova Zelândia, é uma equipe transcendente. Antes de cada jogo eles realizam a haka, uma cerimônia de guerreiros maoris. A haka é uma dança que energiza as pessoas que estão prestes a enfrentar uma batalha. Ao assisti-la, é quase possível sentir a energia que sai de cada jogador se mesclar em uma grande unidade. A partir de batidas dos pés e das mãos e cantos sincronizados, você vê homens comuns se transformarem em algo maior.

Após a exibição, os integrantes listaram quatro aspectos que mereciam ser imitados. O primeiro é a concentração intensa na meta, o segundo era a colaboração extrema, o terceiro era o ímpeto de destruição, o quarto era o entusiasmo quando alguém conseguia avançar com a bola. Então, estabelecemos essa estrutura de sprints, reuniões diárias de pé, revisões e retrospectivas, e percebi que precisávamos de alguém cujo trabalho fosse garantir que o processo funcionasse. O grupo deu a esse líder um nome: Scrum Master. Ele conduziria todas as reuniões, se certificaria de que houvesse transparência, ajudaria a equipe a descobrir o que estava atrapalhando o andamento do projeto.

Menor é melhor. Equipes pequenas trabalham mais rápido do que as grandes. A regra básica é que sete integrantes são o ideal – podendo ser mais ou menos dois.

Capítulo 4 – Tempo

No começo dos anos 1990, fui convidado a trabalhar na Borland Softwares. Entre outras coisas, percebi que ali a reunião diária durava pelo menos uma hora. Isso me pareceu muito tempo, então examinei quais as questões essenciais a serem abordadas nessa ocasião. E foi assim que a reunião diária foi posta em prática. Tínhamos certas regras. O encontro ocorria no mesmo horário todos os dias, e todo mundo precisava participar. Se a equipe inteira não estivesse presente, a comunicação simplesmente não funcionaria. E não importava a hora que marcássemos, desde que fosse a mesma todo dia. O que interessava era dar à equipe um ritmo regular.

A segunda regra era que a reunião não poderia durar mais de 15 minutos. A ideia era obter a maior quantidade possível de informações valiosas e úteis no menor intervalo de tempo possível. A terceira regra era que todos tinham que participar ativamente. Para ajudar nisso, pedi que todo mundo ficasse de pé. Dessa forma, falaríamos e escutaríamos de maneira ativa. Isso também ajudaria a manter curtas as reuniões.

Na Easel, com a primeira equipe de Scrum, implementamos a reunião diária durante o terceiro sprint. Havíamos planejado quatro semanas para aquele sprint – mais ou menos a mesma carga de trabalho que tivemos no mês anterior. Terminamos tudo em uma semana. Uma melhoria de 400%. Naquela sexta-feira, os integrantes olharam uns para outros e disseram: “Uau!”. Foi então que percebi que talvez eu estivesse no caminho certo.

O Scrum muda a maneira como você vê o tempo. Depois de participar de alguns sprints e reuniões diárias, você para de enxergar o tempo como uma seta apontando para o futuro e passa a vê-lo com algo totalmente cíclico. Cada sprint é uma oportunidade de criar algo totalmente novo, uma chance de melhorar.

Capítulo 5 – O desperdício é um crime

Como já mencionei, boa parte das ideias do Scrum vem do modelo de fabricação japonês apresentado no clássico livro O Sistema Toyota de Produção, de Taiichi Ohno. Nos Estados Unidos esse método foi interpretado como um modelo de produção “enxuta”. Basicamente, a intenção é eliminar a maior quantidade possível de desperdício no processo de fabricação. É claro que a maioria de nós não está tentando melhorar o fluxo de uma indústria de automóveis, mas algumas das ideias são aplicáveis a qualquer tipo de trabalho.

Um conceito que quero abordar aqui é o do “trabalho em andamento”, ou apenas “inventário’. Devemos lembrar que é um desperdício ter à nossa volta um monte de itens que não estão sendo usados para construir nada. Muitas coisas podem estar largadas na fábrica, sem ter uma utilidade. Um exemplo do que está em andamento é um monte de carros semiconstruídos numa indústria automobilística. Isso quer dizer que ela gastou um monte de dinheiro e trabalho, mas não criou nada que realmente tenha algum valor. Na produção enxuta, a ideia é minimizar a quantidade de material semiconstruído parado na fábrica. O poder dessa ideia pode ser aplicado a qualquer tipo de trabalho.

Como já foi dito, há um ritmo de trabalho no Scrum. A cada ciclo ou sprint, a equipe tenta fazer várias coisas. Mas, para que passe para a coluna “Feito”, o produto precisa estar completo, pronto para ser utilizado pelo cliente. No fim do sprint, algo feito pela metade é pior do que algo que ainda não tenha sido iniciado, pois recursos, esforço e tempo foram gastos e nada foi desenvolvido a ponto de poder ser entregue. É o mesmo que ter meio carro. Talvez fosse melhor criar algo menor, mas que realmente funcionasse.

Capítulo 6 – Planeje a realidade, não a fantasia

Em seu trabalho, quantas vezes já lhe deram uma tarefa que você não entende por que precisa ser realizada? Alguém lhe pede que determine a variação das vendas mês a mês na região A, em lojas com mais de 50 metros quadrados. Você o faz, mas não sabe por que isso é necessário. E, por esse motivo, é possível que você forneça o tipo errado de dados, que interprete a pergunta de maneira errônea ou que fique ressentido por ter recebido um monte de trabalho inútil. Ou então, se for gestor, pode ficar chocado por seus funcionários não entenderem de primeira que você está cogitando fechar lojas pequenas e abrir estabelecimentos grandes.

O problema é que você não está recebendo ou fornecendo informações suficientes para que o trabalho seja feito do jeito certo. As pessoas pensam por meio de narrativas, de histórias. É assim que entendemos o mundo. Compreendemos intimamente personagens, desejos e motivações, mas temos dificuldade em extrair papéis discretos do enredo principal e lidar com eles fora de contexto.

Assim, quando estiver elaborando uma tarefa, o primeiro elemento que você deve levar em consideração são os personagens ou os papéis – por exemplo, um cliente, uma noiva, um leitor, um funcionário. Para quem esse trabalho está sendo feito? Devemos nos colocar no lugar de quem, ao construir essa coisa, tomar essa decisão ou entregar esse produto?

Em seguida, você se pergunta o quê – o que queremos fazer primeiro. Em geral, começamos e encerramos os projetos com essa informação. Mas ela é apenas o meio do processo que estamos executando. Por fim, você precisa pensar na motivação. Por que essa pessoa quer isso? Como esse produto vai servir e encantar esse cliente? E, de certa forma, essa é a parte mais importante. A motivação é o que dá cor a tudo.

Na prática, descobrimos que, se as histórias estiverem realmente prontas, a equipe duplicará a velocidade de implementação. E, se as histórias forem de fato concluídas até o fim de um sprint, as equipes podem dobrar velocidade novamente. Esse é um dos truques necessários para fazer o dobro do trabalho na metade do tempo.

Saiba sua velocidade. Toda equipe deve saber quanto trabalho consegue realizar em cada Sprint. E também deve saber quanto pode aumentar essa velocidade ao trabalhar de modo mais inteligente e ao remover barreiras que diminuem seu ritmo.

Capítulo 7 – Felicidade

Para ser eficaz, um sprint requer certo nível de maturidade emocional e um ambiente de confiança. É essencial que todos se lembrem de que não estão procurando um culpado, mas sim examinando o processo. Por que isso aconteceu dessa forma? Por que não percebemos aquilo? O que faria com que trabalhássemos mais rápido? É crucial que as pessoas assumam a responsabilidade pelo processo e pelos resultados em equipe e busquem soluções em equipe. Ao mesmo tempo, os indivíduos precisam ter estrutura emocional para mencionar as questões que os incomodam de modo a buscar uma solução, não de uma forma que apareça acusatória.

A “métrica da felicidade” foi o melhor método que encontrei para captar tudo isso. É uma maneira simples, mas muito eficaz, de chegar àquilo que o kaizen [melhoria, em japonês] deve ser, mas também ao kaizen que fará com que as pessoas fiquem mais felizes. Já empreguei essa técnica e obtive ótimos resultados.

Ao fim da cada Sprint, cada integrante da equipe responde a algumas perguntas:

1. Em uma escala de 1 a 5, como se sente em relação ao seu papel na empresa?

2. Nessa mesma escala, como se sente em relação à empresa como um todo?

3. Por que se sente assim?

4. O que faria com que ficasse mais feliz no próximo sprint?

O que realmente faz as pessoas felizes? São as mesmas coisas que produzem grandes equipes: autonomia, domínio e propósito. Ou, usando mais palavras para dizer a mesma coisa, é a capacidade de controlar o próprio destino, a sensação de estar melhorando em alguma atividade e de estar servindo a algum propósito maior.

Como já mencionei, não me importo muito com o desempenho individual; só o que interessa é o desempenho de uma equipe. Sou capaz de dobrar a produtividade de uma equipe em um mês, mas a de um indivíduo? Uma empresa inteira? Isso poderia levar uma eternidade. Portanto, uso a transparência para me concentrar em melhorar a equipe. Em geral, observo que a própria equipe consegue resolver problemas individuais de desempenho. Os integrantes do grupo sabem exatamente o que as pessoas estão fazendo, quem está ajudando, quem está atrapalhando, quem faz com que a equipe seja ótima e quem torna o trabalho penoso.

As “bolhas de felicidade” é um assunto que pede comentário. Elas preocupam muito porque são o ponto em que as fórmulas do Scrum talvez saiam do eixo. Vi isso se repetir várias vezes: a equipe faz tudo que o Scrum ensina – priorização, realização de uma tarefa de cada vez, multifuncionalidade, rituais de revisão -, mas para de melhorar. O pessoal relaxa: “A gente não precisa melhorar mais.” As consequências são previsíveis…

Capítulo 8 – Prioridades

O segredo, portanto, é o que você decide realizar primeiro. Esta é a pergunta que deve ser feita: quais são os itens que têm o maior impacto sobre o negócio, que são mais importantes para o cliente, que podem gerar mais dinheiro e que são mais fáceis de fazer? Você precisa ter em mente que há um monte de itens da lista que nunca serão postos em prática. O ideal é trabalhar primeiro nas tarefas que agregam mais valor e trazem menos riscos. Com o desenvolvimento e a entrega graduais do Scrum, o objetivo é começar com os elementos que vão gerar receita imediatamente, de modo a eliminar os “riscos” do projeto.

No desenvolvimento de produto, há uma regra simples que tem se provado verdadeira repetidas vezes. Já falei sobre ela: 80% do valor estão em 20% das funcionalidades. Em qualquer coisa que você compre, a maior parte do valor – a maior parte daquilo que as pessoas realmente querem – se concentra em apenas um quinto do que foi desenvolvido. O truque do Scrum é determinar como desenvolver esses 20% primeiro.

Quando for escolher um Product Owner, contrate alguém que consiga se pôr no lugar de quem receberá o valor do que está produzindo. Como diz um amigo meu: “Minha esposa é o Product Owner perfeito; ela sabe o que quer. Eu só tenho de realizá-lo.”.

O Product Owner não precisa apenas de uma gama de habilidades mais ampla que o Scrum Master. Essas habilidades também precisam ser postas em prática de acordo com um conjunto de padrões diferentes. O Scrum Master e a equipe são responsáveis pela velocidade do trabalho e por quanto podem aumentá-la. O Product Owner é responsável por traduzir a produtividade da equipe em valor.

Capítulo 9 – Mude o mundo

De fato, comecei a ver o método ser aplicado nos setores mais improváveis, para resolver os problemas mais espinhosos que a humanidade enfrenta. Pense em alguns desses problemas. Por exemplo, pessoas que vivem na pobreza, o que é não somente aviltante, mas também gera uma série de males sociais, como a criminalidade, a corrupção, a guerra e a destruição. Há também nosso sistema educacional, que fracassa com alunos do mundo inteiro. Em vez de ensinar habilidades do século XXI, atolamos nossos jovens em métodos de ensino e aprendizagem criados no século XIX. E outro elemento disfuncional que vem à mente é o governo, que usa métodos ultrapassados.

Mas não desanimemos. Há bons exemplos a ser imitados. Em Olympia, capital do estado de Washington, os dois últimos governadores adotaram o que chamamos de governo enxuto. O governador Jay Inslee, criou cinco pontos que podem ser encontrados em qualquer plataforma de campanha: 1. Um sistema educacional “de ponta”, desde a pré-escola até a faculdade; 2. uma “economia próspera”; 3. tornar Washington um líder nacional em energia sustentável e meio ambiente limpo; 4. comunidades saudáveis e seguras; 5. governo eficiente, eficaz e responsável.

O diretor de tecnologia da informação do Estado de Washington é responsável não só pela tecnologia que é comprada, mas também por como ela é produzida. O departamento é composto de 20 pessoas cuja função é garantir que enormes falhas de TI, que podem custar dezenas de milhões de dólares, não ocorram.

Para fazer isso, o departamento usa o Scrum. Os funcionários se organizaram na forma de equipes de Scrum. Michael D’Angelo, o vice-diretor de TI, conta que toda semana a equipe tenta entregar aos departamentos estaduais políticas que possam ser postas em prática: “Estamos atualizando o processo de como nossas agências apresentam planos de investimentos. Estabelecemos o objetivo de mudar uma coisa por semana. Nossa abordagem é progressiva. Toda semana temos um produto potencialmente utilizável e que pode ser experimentado pelas agências. Elas recebem algo tangível.”

Scrum nas escolas da Holanda. Na Holanda, um número crescente de professores usa o Scrum para dar aula no ensino médio. Eles veem uma melhora quase imediata de mais de 10% nos resultados das provas. E têm obtido o engajamento de todos os tipos de aluno, desde os que querem seguir uma profissão mais simples até os superdotados. O eduScrum, como o professor Willy Wijnands chama sua abordagem, é apresentado aos estudantes no primeiro dia de aula. A primeira tarefa deles é escolher as equipes, que precisam ser multifuncionais. Os alunos as avaliam em várias categorias, como bravura, gosto pela matemática, preocupação com os sentimentos dos outros e “foco nos objetivos”. Em seguida, são orientados a formar grupos multifuncionais, que tenham todas as habilidades necessárias para aprender a matéria.

Fundação Grameen em Uganda. A Fundação Grameen foi criada pelo banco Grameen, do vencedor do Prêmio Nobel Muhammad Yunus. A fundação se concentra em ajudar a tirar da pobreza pessoas de todo o mundo. Em Uganda, a instituição resolveu tentar fazer exatamente isso: dando aos pobres a capacidade de compartilhar e produzir conhecimento. O Scrum colaborou para isso.

Eric Kamara lidera o grupo de tecnologia do escritório da Fundação Grameen em Kinshasa. Seu grupo usa o Scrum para desenvolver seus aplicativos, dedicados principalmente ao compartilhamento de técnicas agrícolas e facilidades de comercialização. Ele diz que, cada vez que alguém pede um conjunto de funcionalidades, sua equipe classifica o pedido em uma escala de 1 a 7. Antes do Scrum, as pessoas pediam tudo ao mesmo tempo. Com os recursos limitados de uma organização sem fins lucrativos, era impossível fazer tudo. O Scrum ajudou a fazer a escala de funcionalidades, de forma transparente.