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.
2
Por que Scrum?
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.
3
O surgimento do
SCRUM
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.
4
Uma nova forma de
pensar
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 [Link], 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. 5
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.” 6
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.
7
Tarefas, Processo,
Funções
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.
8
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. 9
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.
10
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.
8
O “11 de Setembro”
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: 12
• 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.
13
Mestre SCRUM
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.
14
Planos de casamento
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”.
15
Conversa com a plateia
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.
16
Felicidade também faz
parte
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.
17
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.
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.
18
Senso de prioridade e
Dono do Produto
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.
19
Dicas essenciais:
Planejar é útil. Seguir cegamente os planos é burrice. É muito
tentador desenhar inúmeros [Link] 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.
20
