2

Este conteúdo contempla o resumo original do livro Scrum: The Art of Doing Twice the Work in Half the Time.

A versão completa está disponível para compra e leitura online nas principais livrarias e plataformas digitais.

Por que Scrum?

3

Se você já foi surpreendido por quão rápido o mundo está mudando, Scrum é uma das razões. Para aqueles que acreditam que deve haver uma maneira mais eficiente de se fazer as coisas, este é um livro instigante sobre o processo de gestão que está mudando a maneira como vivemos.

Desde o advento do método, já foram registrados ganhos de produtividade de até 1.200%. Jeff Sutherland, empreendedor que desenvolveu a primeira equipe Scrum há mais de vinte anos, apresenta a iniciativa de maneira brilhante e lúcida.

Tecida com insights de artes marciais, tomadas de decisão judicial, combate aéreo avançado, robótica e muitas outras disciplinas, Scrum é sempre fascinante. Seja para inventar uma tecnologia pioneira ou para estabelecer os alicerces de prosperidade de uma família, a razão mais importante para ler este livro é que ele pode ajudá-lo a alcançar o que outros consideram inatingível.

Criei o Scrum, junto com Ken Schwaber, há vinte anos, como um jeito mais rápido, confiável e eficiente de desenvolver softwares na indústria de tecnologia.

Até aquele momento –e até 2005 –, a maior parte do desenvolvimento de softwares era executada com base no método em cascata, de acordo com o qual um projeto era concluído em etapas distintas e levado passo a passo até o lançamento para os consumidores ou usuários.

O processo era lento, imprevisível, e muitas vezes não resultava em um produto que as pessoas quisessem ou pelo qual se dispusessem a pagar. Atrasos de meses, ou até mesmo anos, eram endêmicos. Os antigos planos passo a passo, confortavelmente detalhados em diagramas de Gantt, davam à gerência uma sensação de que se tinha total controle sobre o desenvolvimento de um projeto.

No entanto, na maioria esmagadora dos casos, em pouco tempo os atrasos em relação ao cronograma começavam e o orçamento era ultrapassado em uma escala desastrosa.

O surgimento do SCRUM

4

O termo SCRUM é, de fato, proveniente de uma expressão de um esporte saxão, contudo, a ideologia dessa diferente forma de trabalho foi inspirada nos pensamentos dos orientais Takeuchi e Nonaka.

Para eles, as equipes de grande desempenho tinham algumas características em comum, como:

• transcendência. Elas têm um senso de propósito além do comum. A decisão de não estar na média, mas ser grandioso, muda o modo como eles se enxergam e o que são capazes de fazer.

• autonomia. As equipes se auto-organizam e se auto gerenciam.

• interfuncionalidade. Também possuem todas as habilidades necessárias para concluir o projeto: planejamento, projeção, produção, vendas e distribuição. E tais habilidades alimentam e reforçam umas às outras.

Nesse contexto, é importante ressaltar que um dos conceitos- chave do SCRUM é que os membros da equipe decidem, eles mesmos, como irão executar o trabalho.

O segredo da metodologia criada está em observar a forma como as pessoas trabalham e não como elas dizem trabalhar.

O termo emprestado foi do mundo do esporte, mais especificamente do jogo inglês rúgbi e faz referência ao modo como os jogadores avançam no campo adversário.

Trata-se de alinhamento cuidadoso, unidade de propósito e clareza de objetivo. Tudo o que uma equipe precisa para se tornar eficiente dentro da empresa.

Uma nova forma de pensar

5

O nome dessa nova abordagem é “Scrum”. Eu a criei há vinte anos. Hoje, ela é a única maneira comprovada para auxiliar projetos desse tipo. Há duas formas de fazer as coisas:

O antigo método da “cascata”, que gasta centenas de milhões de dólares e, com frequência, não consegue nenhum resultado; ou a nova forma, que, com menos gente e menos tempo, consegue mais resultados, com qualidade melhor e custos menores.

Sei que parece bom demais para ser verdade, mas os resultados provam: funciona mesmo. Há vinte anos, eu estava desesperado. Precisava encarar o trabalho de um jeito novo. Com muita pesquisa, experimentação e análise de dados, percebi que todos precisávamos de uma nova forma de organizar os projetos. Não estou falando nada de outro mundo. Já se tocou nesse assunto antes. Estudos da época da Segunda Guerra Mundial mostram algumas das melhores formas como as pessoas trabalham. Contudo, por algum motivo, ninguém tinha ligado os pontos. Nos últimos vinte anos, tentei fazer exatamente isso.

E agora essa metodologia se tornou onipresente na área em que a pus em prática pela primeira vez: na área de desenvolvimento de software.

Em gigantes como Google, Amazon e Salesforce.com, assim como em pequenas startups sobre as quais você ainda nem ouviu falar, essa estrutura mudou radicalmente o modo de trabalho.

O motivo pelo qual essa estrutura funciona é simples. Observei a forma como as pessoas trabalham na realidade, em vez de me basear em como elas afirmam trabalhar. Analisei pesquisas realizadas ao longo de décadas e práticas que deram certo em empresas do mundo inteiro. Também examinei as melhores equipes dessas empresas. O que as tornava superiores?

O que as tornava diferentes? Por que alguns grupos atingiam resultados excepcionais e outros só chegavam a desfechos medíocres? Por motivos que explicarei melhor nos próximos capítulos, chamei de “Scrum” essa estrutura de trabalho em equipe.

6

O termo vem do rúgbi, e se refere à maneira como um time se une para avançar com a bola pelo campo.

Tudo se alinha: posicionamento cuidadoso, unidade de propósito e clareza de objetivo. Trata-se de uma metáfora perfeita para o que quero que as equipes façam. Tradicionalmente, a gerência quer dois elementos em qualquer projeto: controle e previsibilidade.

O resultado disso é uma quantidade imensa de documentos, gráficos e diagramas –justamente o que ocorreu na Lockheed.

Gastam-se meses no planejamento de todos os detalhes, para que nenhum erro ocorra, o orçamento não estoure e tudo seja entregue no prazo.

O problema é que esse cenário cor-de-rosa nunca se torna realidade. Todo o esforço investido no planejamento, na restrição de mudanças e na previsão do imponderável não serve para absolutamente nada.

Em todo projeto surgem problemas e há rompantes de inspiração. Qualquer tentativa de restringir um empreendimento humano de qualquer magnitude a diagramas coloridos é uma bobagem fadada ao fracasso. Não é assim que os indivíduos trabalham e que os projetos avançam.

Não é assim que as ideias florescem ou se desenvolvem criações excepcionais. Pelo contrário, isso gera frustração, porque ninguém consegue o que quer. Os prazos não são cumpridos, os orçamentos estouram e muitas vezes os projetos acabam no mais completo fracasso.

Isso ocorre em especial nos casos em que equipes trabalham na criação de algo novo. Na maioria das vezes, a gerência só se dá conta de que tudo caminha para o fracasso quando milhões de dólares e milhares de horas já foram investidos em vão. O Scrum pergunta por que tanto tempo e esforço são gastos na realização de uma tarefa, e por que somos tão ruins em prever o tempo e o esforço que as atividades vão exigir.

A catedral de Chartres levou 57 anos para ser construída. Posso apostar que, no início do projeto, os pedreiros viraram para o bispo e disseram: “Vinte anos no máximo. Acho até que a gente faz em quinze.”

7

O Scrum acolhe a incerteza e a criatividade. Cria um alicerce para o aprendizado, permitindo que as equipes avaliem o que já criaram e de que forma o criaram, o que é igualmente importante.

A estrutura do Scrum procura aproveitar a maneira como as equipes de fato trabalham, fornecendo ferramentas para se auto- organizarem e otimizarem em pouco tempo a rapidez e a qualidade do trabalho.

Na essência, o Scrum se baseia em uma ideia simples: quando começamos um projeto, por que não verificar a intervalos regulares se ele está indo no caminho certo e se aquilo é realmente o que as pessoas querem?

E por que não se perguntar se é possível aprimorar a forma como você está trabalhando para obter resultados melhores e mais rápidos, e o que poderia estar impedindo você de fazer isso?

O nome disso é ciclo de “inspeção e adaptação”. De tempos em tempos, pare o que está fazendo, revise o que já fez e verifique se ainda deveria continuar fazendo o mesmo e como poderia fazê-lo melhor.

É uma ideia simples, mas executá-la exige reflexão, introspecção, honestidade e disciplina. É para mostrar como fazer isso que estou escrevendo este livro. E não estou pensando apenas em empresas de desenvolvimento de software.

Já vi o Scrum ser aplicado com sucesso na fabricação de carros, no gerenciamento de uma lavanderia, no ensino em sala de aula, na construção de foguetes, na organização de um casamento.

Até mesmo minha esposa o utiliza para se certificar de que a minha lista de afazeres domésticos seja cumprida todo fim de semana.

Os resultados do Scrum –o objetivo do projeto, se preferir –são equipes que melhoram consideravelmente a sua produtividade. Ao longo dos últimos vinte anos, montei equipes assim várias vezes.

Tarefas, Processo, Funções

8

1. Escolha um Dono do Produto. Essa pessoa é a responsável pela visão do que você vai fazer ou conseguir. Ela leva em consideração os riscos e os benefícios, o que é possível, o que pode ser feito e o que desperta a paixão na equipe.

2. Escolha uma equipe. Quem serão as pessoas que realmente trabalharão no projeto? Essa equipe precisa ter todas as habilidades necessárias para pegar a visão do Dono do Produto e transformá-la em realidade. As equipes devem ser pequenas; entre três e nove pessoas é o princípio básico.

3. Escolha um Mestre Scrum. Essa pessoa vai orientar o restante da equipe em relação à estrutura do Scrum, além de ajudar a eliminar qualquer obstáculo que os esteja deixando mais lentos.

4. Crie e priorize uma lista de Pendências do Produto. Trata-se de uma lista detalhada de tudo que precisa ser feito ou construído para transformar a visão em realidade. Essas Pendências existem e evoluem durante o desenvolvimento do produto; elas são o mapa dele.

Em qualquer fase do projeto, são a única e definitiva visão de "tudo que precisa ser feito pela equipe a qualquer momento, em ordem de prioridade".

Só existe uma lista de Pendências; isso significa que o Dono do Produto precisa tomar decisões em relação às prioridades durante todo o processo; ele deve consultar todos os stakeholders e a equipe para se certificar de que elas representam tanto o que as pessoas querem, quanto o que pode ser construído.

5. Aperfeiçoe e faça estimativas para as Pendências do Produto. É crucial que as pessoas que irão realmente concluir os itens da lista façam as estimativas de quanto esforço eles exigirão. A equipe deve olhar para cada item das Pendências e ver se aquilo é factível.

9

Existem informações suficientes para conclui-lo? Ele é pequeno o suficiente para ser estimado? Existe uma definição de "Feito"? Ele cria valor visível?

Cada item deve poder ser mostrado, demonstrado e, esperançosamente, ser enviado. Não estime as Pendências em horas, porque as pessoas são péssimas nesse tipo de previsão.

Faça isso usando uma classificação relativa por tamanho: Pequeno, Médio ou Grande. Ou, melhor ainda, use a sequência de Fibonacci e faça estimativas de pontos para cada item: 1, 2, 3, 5, 8, 13, 21 etc.

6. Planejamento do Sprint. Esta é a primeira das reuniões Scrum. A equipe, o Mestre Scrum e o Dono do Produto se reúnem para planejar o Sprint, que sempre tem uma duração definida de tempo menor que um mês.

A maioria das pessoas define Sprints de uma ou de duas semanas. As equipes olham para as tarefas no topo das Pendências e estimam o quanto podem fazer naquele Sprint. Se a equipe já está trabalhando a alguns Sprints, ela deve pegar tarefas que totalizem o mesmo número de pontos do Sprint anterior.

Esse número é conhecido como a Velocidade da equipe. O Mestre Scrum e a equipe devem tentar aumentar o número de pontos a cada Sprint. Essa é outra chance para a equipe e o Dono do Produto se certificarem que todos entendem como os itens vão satisfazer a visão.

Além disso, durante essa reunião todos devem concordar com um Objetivo do Sprint. Um dos pilares do Scrum é que, uma vez que a equipe se comprometeu com o que acredita ser capaz de fazer em um Sprint, é isso. Ele não pode ser mudado, nada pode ser acrescentado. A equipe deve trabalhar de forma autônoma durante o Sprint para concluir o que previu que conseguiu.

7. Torne o trabalho visível. O melhor jeito para se fazer isso no Scrum é criar um Quadro Scrum com três colunas: A fazer, Fazendo, Feito. post-its representam os itens que precisam ser concluídos e a equipe os move pelo Quadro Scrum à medida que forem concluídos, um a um.

Outro modo de tonar o trabalho visível é criar um Gráfico de Burn-Down. Um eixo é o número de pontos que a equipe definiu para o Sprint, e o outro é o número de dias.

10

Todos os dias, o Mestre Scrum soma o número de pontos concluídos e os marca no gráfico. O ideal é que haja uma ladeira descendo pelo gráfico até chegar ao zero no último dia do Sprint.

8. Reuniões Diárias ou Scrum Diário. Este é o ritmo do Scrum. Todos os dias, no mesmo horário, durante não mais do que 15 minutos, a equipe e o Mestre Scrum se reúnem para responder a três perguntas:

•O que você fez ontem para ajudar a equipe a concluir o Sprint? •O que você vai fazer hoje para ajudar a equipe a concluir o Sprint? •Existe algum obstáculo impedindo você ou a equipe de alcançar o objetivo do Sprint?

Isso é tudo. A reunião inteira. Se ela levar mais do que 15 minutos, você está fazendo alguma coisa errada. Isso serve para ajudar a equipe inteira a saber exatamente em que ponto estão no Sprint.

Todas as tarefas serão concluídas a tempo? Existem oportunidades para ajudar os outros membros da equipe a superarem os obstáculos? Não há designação de tarefas vindas de cima —a equipe é autônoma; são eles que fazem isso.

Não há qualquer relatório detalhado para os gestores. O Mestre Scrum é responsável por resolver qualquer obstáculo ou impedimento para o progresso da equipe.

9. Revisão ou Demonstração do Sprint. Trata-se da reunião na qual a equipe mostra o que conseguiu fazer durante o Sprint. Qualquer pessoa pode participar, não apenas o Dono do Produto, o Mestre Scrum e a equipe, mas também os stakeholders, os gestores, os clientes, e qualquer outra pessoa.

Esta é uma reunião aberta na qual a equipe demonstra o que conseguiu colocar na coluna Feito. A equipe só deve demonstrar o que satisfaz a Definição de Feito.

O que está total e completamente concluído e pode ser entregue sem qualquer trabalho adicional.

Pode não ser o produto completo, mas deve ser um atributo concluído do produto.

8

10. Retrospectiva do Sprint. Depois que a equipe mostrou o que conseguiu fazer no Sprint anterior —aquilo que está "Feito" e pode ser entregue para clientes para obtenção de feedback —, eles se reúnem e pensam no que deu certo e o que poderia ter sido melhor, e o que podem melhorar no próximo Sprint.

Qual é o aprimoramento no processo que eles, como uma equipe, podem implementar de forma imediata? Para ser eficaz, essa reunião requer certa dose de maturidade emocional e atmosfera de confiança.

O importante é lembrar-se sempre de que você não está procurando culpados; está olhando para o processo. Por que aquilo aconteceu assim? Por que você não percebeu aquilo? O que poderia ter acontecido para sermos mais ágeis?

É essencial que as pessoas na equipe assumam a responsabilidade pelo processo e seus respectivos resultados, e que busquem soluções como uma equipe. Ao mesmo tempo, elas têm de ter coragem de levantar as questões que realmente as incomodam, de forma que a solução seja orientada, em vez de acusadora.

E o restante da equipe precisa ter maturidade para ouvir o feedback, absorvê-lo e procurar uma solução, em vez de assumir uma postura defensiva. No final da reunião, a equipe e o Mestre Scrum devem chegar a um acordo sobre um aprimoramento no processo que será implementado no Sprint seguinte.

Tal aprimoramento no processo, às vezes, é chamado kaizen, e deve ser colocado nas pendências do próximo Sprint, acompanhado de testes de aceitação. Desse modo, será fácil para a equipe verificar se o aprimoramento realmente foi implementado, e que efeito ele teve sobre a velocidade.

11. Comece imediatamente o próximo Sprint, considerando a experiência da equipe com os impedimentos e os aprimoramentos no processo.

O “11 de Setembro”

12

Você acreditaria se lhe dissessem que a tragédia do dia 11 de setembro de 2011, em Nova York, poderia ter sido evitada se as pessoas envolvidas em fiscalizações terroristas estivessem trabalhando de maneira mais eficiente?

Obviamente, nenhum trabalhador norte-americano desejou aquele ataque.

A inteligência do FBI possuía as informações que poderiam evitar a tragédia, mas, infelizmente, além de não ter recursos tecnológicos viáveis, a instituição pecava em uma coisa muito importante: o modo de trabalho dos funcionários.

Os agentes costumavam atualizar seus relatórios por meio de um software que foi muito útil na década de 80 e obedeciam à metodologia de cascata para cumprir as funções diárias.

Isso quer dizer que eles trabalhavam para obedecer diagramas complicados, onde cada etapa, evento importante e data de entrega do projeto estão detalhadamente definidas.

É um “faz de conta” que impressiona, mas não é funcional ou traz resultados. Nesse caso, não pode nem evitar tamanho desastre com a população estadunidense.

O que é planejado vs. O que acontece de fato

Ter previsibilidade e controle nos negócios é o sonho de qualquer empreendedor.

Por isso, é comum funcionários terem que lidar com inúmeros gráficos, documentos e diagramas. Tudo isso com muito esforço para que nada saia do esperado.

Isso, infelizmente, não leva a nada. Todo projeto enfrenta novos problemas e surtos de inspiração a cada fase e qualquer tentativa de limitar o desenvolvimento dele ao que ele chama de “diagramas coloridos” é algo cujo destino certo é o fracasso.

Não é assim que as pessoas trabalham, de fato, e, consequentemente não é dessa forma que os projetos avançam. Por essa razão, criei um método cujo os pilares são:

13

• seguir cegamente os planos é burrice. Planejar é preciso, mas dar continuidade num plano se difere do cenário real totalmente contrário ao desenvolvimento do projeto.

• inspecionar e adaptar. Pare o que está fazendo, revise o que já fez e veja se isso é realmente algo que você deveria estar fazendo.

• mudar ou morrer. Não fique preso aos modos antigos de fazer as coisas. Enquanto você fizer isso, a concorrência o fará comer poeira.

• fracassar rápido. Assim, dá tempo de corrigir o problema. Os quatro tópicos podem ser a base do SCRUM, mas tem muito mais coisa por trás dessa metodologia. Inclusive uma pesquisa sobre estatísticas e câncer.

Aviões de papel para treinar equipes

Na metodologia, grupos se dividem em três funções: a de buscar melhores modos de construir aviões e acelerar o processo; a de verificar quantos aviões conseguem voar de verdade até o outro lado da sala.

As equipes têm um minuto para planejar como vão construir o avião; três minutos para fazer e, finalmente, dois minutos para verificar se tudo deu certo. O treinamento vem do ciclo PDCA. Do inglês, plan, do, check e act, ou seja: planeje, faça, verifique e aja.

Uma metodologia do americano W. Edwards Deming, que influenciou grandes nomes da indústria japonesa após a Segunda Guerra Mundial. Isso foi o que fez a Toyota se tornar a empresa automobilística número um do mundo.

Quantidade não é qualidade. Quanto mais melhor, não é mesmo? Bem, não é assim que as coisas funcionam. O ideal é se trabalhar em equipes com sete pessoas, permitindo variação de até duas pessoas para menos ou para mais.

Se as equipes ficarem grandes demais, a capacidade de todos se comunicarem de forma clara, ao mesmo tempo, fica confusa e a interfuncionalidade se perde.

Quando isso acontece, as reuniões que deveriam levar apenas alguns minutos, infelizmente, chegam a durar várias horas.

Mestre SCRUM

14

Mestre SCRUM é aquela pessoa que é responsável por dirigir os processos e as equipes.

O papel desse membro é importantíssimo para nortear o trabalho de todos. E isso é possível apenas por meio de reuniões frequentes. Esses encontros têm que ser diários e não devem durar mais de 15 minutos.

O Mestre SCRUM deve fazer as seguintes perguntas durante essas reuniões:

• o que você fez ontem para ajudar a equipe a concluir o projeto? • o que você vai fazer hoje para ajudar a equipe a concluir o projeto? • quais obstáculos a equipe está enfrentando?

É o momento de saber o básico, ou seja, saber se as tarefas estão sendo cumpridas no prazo e se há possibilidade de aprimorar o desempenho da equipe.

Malabaristas do trabalho

“Deve ser capaz de gerenciar cinco projetos simultâneos de forma equilibrada”.

Com certeza, você já deve ter lido um anúncio de vaga como essa frase.

O mercado de trabalho exige que as pessoas sejam multitarefas, malabaristas de suas profissões. E elas orgulhosamente mostram que são. Mas não deveriam.

David Sanbonmatsu, da Utah University, fez uma pesquisa que mostra que “as pessoas não são multitarefas porque são boas nisso. Elas fazem (muitas coisas) porque são mais distraídas. Elas não conseguem inibir o impulso de fazer outra atividade”.

Outro risco que se corre quando o trabalho é feito dessa forma é o de deixá-lo pela metade, o que acarreta na perda de tempo, recursos e dinheiro.

Planos de casamento

15

Você já planejou um casamento?

Se ainda não, o que a organização de uma boa festa tem a ver com priorizar os processos do trabalho.

A primeira coisa a se fazer é criar uma lista com todas as coisas que tornam a cerimônia e a recepção um sucesso.

Depois, o ideal pegar todos esses elementos e classificá-los por prioridade.

Agora, é hora de descobrir quanto esforço, tempo e dinheiro serão necessários para desenvolver cada item da lista.

Feito isso, a atenção deve ser redobrada para lidar com outro fato: os envolvidos nos processos da cerimônia precisam de esclarecimento e não apenas de uma lista de prioridades. Ou seja: sua equipe precisa de orientação antes de definir a própria forma de trabalho.

Reflita que as pessoas pensam em narrativas, em formas de história e lidam muito melhor quando há personagens envolvidos. Mostre a elas para quem aquela tarefa deve ser desenvolvida e aí as coisas funcionam mais fácil.

Depois, pense no que quer que seja feito primeiro e, por fim, em uma motivação.

Por que esse personagem quer isso? Como isso vai ajudar e encantar esse determinado cliente?

Histórias ao invés de tarefas

As histórias sobre possíveis clientes funcionam. Assim, a equipe consegue visualizar para quem deve produzir determinada coisa e fazer algo mais específico para o grupo de pessoas que deseja atingir.

Imagine, por exemplo, a história da famosa Amazon: “como cliente, eu quero a maior livraria virtual do mundo para que eu possa comprar qualquer livro no instante que eu desejar”.

Conversa com a plateia

16

Muito geral, não é mesmo? Por isso, a melhor alternativa é dividi- la nesses tópicos:

• “Como cliente, eu quero poder navegar pelos livros por gênero, para que eu possa encontrar o tipo de livros de que eu gosto.”

• “Como cliente, eu quero colocar um livro em um carrinho de compras, para que eu possa comprá-lo.”

• “Como gerente de administração de produtos, eu quero poder rastrear as compras de um cliente, para que eu possa oferecer livros específicos para ele, com base nas compras anteriores.”

Para saber se tem um boa história em mãos, o pensador Bill Wake desenvolveu os critérios INVEST, um mnemônico para Independente; Negociável; Valiosa; Estimável; Small, que quer dizer “pequena”, em inglês, e, por último, Testável.

Independente A história precisa ser prática e passível de ser “feita” por si só. Ela não deve ser inerentemente dependente de nenhuma outra história.

Negociável Até que esteja sendo realizada, ela precisa poder ser reescrita. A permissão para alterações está embutida nela.

Valiosa Ela realmente deve acrescentar valor ao cliente, usuário ou stakeholder. Estimável. Você deve ser capaz de mensurá-la.

Small A história precisa ser pequena o suficiente para que você possa estimar e planejar facilmente. Se ela for grande demais, reescreva-a ou divida-a em histórias menores.

Testável A história precisa ter um teste no qual deve passar para ser completa. Escreva o teste antes de fazer a sua história. Esses são os tipos e critérios de histórias que as equipes conseguem compreender e pensar em formas de implementá-las.

Felicidade também faz parte

17

Pessoas felizes produzem mais e têm mais sucesso profissional. Isso é claro.

A Métrica da Felicidade para o ambiente de trabalho é uma forma simples de aperfeiçoar o desempenho das pessoas.

Ao final de cada atualização diária de 15 minutos, cada pessoa na equipe responde às seguintes perguntas:

• em uma escala de 1 a 5, como você se sente em relação ao papel que desempenha na empresa?

• usando essa mesma escala, como você se sente em relação à empresa como um todo?

• por que você se sente assim?

• o que tornaria você mais feliz no próximo projeto?

O método expõe o que é mais importante para cada um e o que eles acreditam ser o melhor para a empresa.

Senso de prioridade e Dono do Produto

Se você se concentrar apenas no que pode construir, é possível que acabe fazendo algo que ninguém, na verdade, quer - mesmo que esteja entusiasmado com a ideia.

Se você só se concentrar no que pode vender, talvez prometa coisas que não conseguirá construir. E se você só construir o que consegue vender, mas sem qualquer entusiasmo, acabará trabalhando duro para construir algo medíocre.

Por essas razões, você precisa ter uma visão do produto, pois 80% do valor está em 20% dos atributos dos seus produtos. Imagine onde o maior valor pode ser gerado com o menor esforço, e faça isso logo de cara.

Para isso, primeiro você precisa descobrir qual é a visão e onde o valor está. O responsável por essa obrigação é chamado de Dono do Produto, e é o responsável por entregar valor.

Senso de prioridade e Dono do Produto

18

Se você se concentrar apenas no que pode construir, é possível que acabe fazendo algo que ninguém, na verdade, quer - mesmo que esteja entusiasmado com a ideia.

Se você só se concentrar no que pode vender, talvez prometa coisas que não conseguirá construir.

E se você só construir o que consegue vender, mas sem qualquer entusiasmo, acabará trabalhando duro para construir algo medíocre.

Por essas razões, você precisa ter uma visão do produto, pois 80% do valor está em 20% dos atributos dos seus produtos. Imagine onde o maior valor pode ser gerado com o menor esforço, e faça isso logo de cara.

Para isso, primeiro você precisa descobrir qual é a visão e onde o valor está.

O responsável por essa obrigação é chamado de Dono do Produto, e é o responsável por entregar valor.

SCRUM para tudo

O método pode ser aplicado à resolução de problemas de vários âmbitos. Como na educação, onde, numa sala de aula da Holanda, os alunos são se sentam em fileiras, mas sim em grupo de quatro.

Mas antes de sentar as cadeiras, eles, espontaneamente, pegam um grande cartaz de papel coberto com post-its, colam-no na parede e se reúnem em volta dele.

Senso de prioridade e Dono do Produto

19

O cartaz está dividido em algumas poucas colunas largas que dizem “Todos os itens”, “Pendências”, “Fazendo” e “Feito”.

Na parte inferior das colunas, há quatro títulos adicionais, mostrando o progresso deles em direção ao objetivo; e, por fim, há “Retrospectiva” e “Velocidade”, no qual medem quantos “pontos” eles conseguiram durante cada aula.

Seus projetos costumam ser de quatro ou cinco semanas, terminando com uma prova.

Em frente aos quadros, os alunos planejam quais lições vão terminar naquele dia.

Obviamente, eles têm o suporte do professor durante o tempo todo. O resultado é uma sala de aula mais motivada, interativa e geradora de resultados, ou seja, alunos que tornam-se competentes no que se propõem.

Esse foi um exemplo educacional, mas o SCRUM também está sendo utilizado para resolver outros problemas sociais, como a pobreza.

Em Uganda, a Grameen Foundation utilizou a “ferramenta” criada por Sutherland para fornecer dados agrícolas e mercadológicos para lavradores pobres da zona rural a fim de gerar mais colheita e lucro.

Dicas essenciais:

20

Planejar é útil. Seguir cegamente os planos é burrice. É muito tentador desenhar inúmeros diagramas.Todo o trabalho que precisa ser feito em um projeto de grande porte ali, detalhado, para todos verem –mas, quando deparam com a realidade, os planos desabam. Inclua no seu método de trabalho a possibilidade de mudança, descoberta e inovação.

Inspeção e adaptação. De tempos em tempos, pare o que está fazendo, revise o que já fez, e verifique se deveria continuar fazendo o mesmo ou se existe uma maneira de fazê-lo melhor. Mude ou morra. Ficar preso ao modo antigo de fazer as coisas – comando, controle e previsibilidade rígida – só resultará em fracassos. Nesse meio-tempo, o concorrente que estiver disposto a inovar vai deixar você para trás.

Fracasse rápido para que possa corrigir o problema o quanto antes. A cultura corporativa costuma dar mais valor a formulários, procedimentos e reuniões do que à criação de valor concreto, que possa ser verificado a curtos intervalos de tempo pelos usuários.

O trabalho que não resulta em valor real é loucura. Trabalhar em um produto em ciclos curtos permite que se obtenha um feedback do usuário logo no começo do desenvolvimento. Assim, você pode eliminar imediatamente tudo aquilo que constitui um desperdício óbvio de esforço . Hesitação significa morte. Observar, Orientar, Decidir, Agir. Saiba onde você está, avalie suas alternativas, tome uma decisão e aja.

Olhe para fora para obter respostas. Sistemas adaptativos complexos seguem algumas regras simples, que são captadas do ambiente. Equipes excelentes são. Elas são multifuncionais, autônomas e capacitadas, com um propósito transcendente. Não adivinhe. Planeje, faça, verifique, aja.

Planeje o que você vai fazer. Faça. Verifique se o produto alcançou o resultado desejado. Aja em relação a isso e mude a forma como está fazendo as coisas. Repita o processo em ciclos regulares e, dessa forma, alcance um aperfeiçoamento contínuo.