-----------------------------------------------------------------------------------

------------

Planejar é útil. Seguir cegamente os planos é burrice. É simplesmente tentador

demais ficar desenhando
diagramas sem fim. Todo o trabalho que precisa ser feito em um projeto de grande
porte deve ser definido para todos
verem — mas, quando os planos detalhados se deparam com a realidade, eles viram
ruínas. 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 de fazer o que está fazendo, revise
o que já fez e verifique se isso
ainda é o que você deveria estar fazendo e se existe uma maneira de fazer melhor.
Mudar ou morrer. Ficar preso ao modo antigo de fazer as coisas, de mandar ou
controlar e manter uma previsibilidade
rígida resultará apenas no fracasso. Nesse meio tempo, a concorrência que estiver
disposta a mudar deixará você
comendo poeira.
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 palpável que pode
ser verificado a curtos possibilita de
tempo pelos usuários. O trabalho que não resulta em valor real é loucura. Trabalhar
em um produto em ciclos curtos
possibilita um feedback inicial do usuário, permitindo que você possa eliminar
imediatamente tudo aquilo que obviamente
constitui um desperdício de esforço.

-----------------------------------------------------------------------------------
------------

Hesitação é a morte. Observe, avalie, decida, aja. Saiba onde está, avalie suas
opções, tome uma decisão e aja!
Procure respostas. Sistemas adaptativos complexos seguem algumas regras simples,
que aprendem a partir do ambiente
em que se encontram.
Grandes equipes. São multifuncionais, autônomas, capazes de tomar decisões e
motivadas por um objetivo
transcendente.
Não adivinhe. Planeje (Plan — P), Faça (Do — D), Verifique (Check — C), Aja (Act —
A): planeje o que vai fazer.
Faça. Verifique se o resultado é o que desejava. Aja de acordo com as informações e
faça as coisas de outra maneira.
Repita em ciclos regulares e, ao fazer isso, obtenha um aprimoramento contínuo.
Shu Ha Ri. Primeiro, aprenda as regras e as formas e, uma vez que as dominar, faça
inovações. Por fim, em um estado
elevado de domínio, descarte as formas e apenas seja — com todo o aprendizado
internalizado as decisões são tomadas de
forma quase inconsciente.

-----------------------------------------------------------------------------------
------------

1. Transcendência: elas têm um senso de propósito além do comum. O objetivo

percebido por todos permite que eles
transformem o ordinário em extraordinário. De uma forma bastante verdadeira, 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.
2. Autonomia: as equipes se auto-organizam e se autogerenciam; têm o poder de tomar
as próprias decisões sobre como
fazer o próprio trabalho e têm o poder de fazer com que tais decisões sejam
acatadas.
3. Interfuncionalidade: as equipes 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 as outras. Nas palavras de um
membro da equipe que projetou uma nova câmera revolucionária da Canon: “Quando
todos os membros da equipe se
encontram em uma sala grande, a informação de alguém se torna sua, mesmo sem você
perceber. Então, você começa a
pensar no que é melhor fazer primeiro e o que é melhor fazer depois pelo grupo como
um todo, e não apenas de acordo
com o que é melhor para você”.

-----------------------------------------------------------------------------------
------------

A alavanca certa. Mude o desempenho da equipe. Isso tem um impacto muito maior — em
várias ordens de grandeza
enorme — do que o desempenho individual.
Transcendência. Grandes equipes têm um objetivo muito maior do que o individual —
por exemplo, participar do enterro
do General MacArthur, vencer o campeonato de basquete da NBA.
Autonomia. Dê às equipes a liberdade de tomarem as próprias decisões e o modo como
vão agir — para ser respeitado
como mestre de sua arte. A capacidade de improvisar fará toda a diferença, esteja a
equipe cobrindo uma revolução do
Oriente Médio ou vendendo algum produto.
Interfuncionalidade. A equipe deve ter todas as capacidades necessárias para
concluir um projeto, seja a missão
entregar um software para a Salesforce.com, seja ou capturar terroristas no Iraque.
Pequenas vitórias. Equipes pequenas trabalham mais rápido do que equipes grandes. A
regra prática são sete membros
por equipe — podendo variar dois a mais ou a menos.
Procurar culpados é burrice. Não procure pessoas ruins; procure sistemas ruins —
aqueles que incentivam mau
comportamento e premiam desempenhos medíocres.

-----------------------------------------------------------------------------------
------------

O tempo é finito. Trate-o dessa forma. Divida seu trabalho em unidades que possam
ser realizadas em um período
definido, curto e regular — o ideal são quatro semanas. E, se você pegar a febre
Scrum, pode chamar essas unidades de
Sprint.
Demonstre ou morra. No final de cada Sprint, você precisa ter algo pronto — algo
que possa ser usado (para voar,
dirigir ou qualquer outra coisa).
Jogue seus cartões de visita fora. Cargos são marcadores especializados de status.
Seja conhecido pelo que faz e não
pelo modo como as pessoas se referem a você.
Todo mundo sabe de tudo. A saturação da comunicação acelera o trabalho.
Uma reunião por dia. Quando se trata de verificar o trabalho da equipe, uma vez por
dia é o suficiente. Reúna-se por 15
minutos na reunião diária, veja o que pode ser feito para aumentar a velocidade e
faça isso
-----------------------------------------------------------------------------------
------------

Ser multitarefa emburrece. Fazer mais de uma coisa de cada vez diminui seu
desempenho tanto em termos de tempo
quanto de qualidade nas duas tarefas. Não faça isso. Se você acha que isso não se
aplica a você, saiba que está errado
— afeta sim.
Fazer pela metade não é fazer. Um carro pela metade só serve para prender recursos
que poderiam ter sido usados
para criar algo de valor ou economizar dinheiro. Qualquer coisa que esteja “em
processo” custa dinheiro e energia, sem
entregar nada.
Fazer certo da primeira vez. Quando você cometer um erro, corrija-o imediatamente.
Pare todo o resto e resolva o
problema que tem em mãos. Corrigir mais tarde pode levar vinte vezes mais tempo do
que corrigir agora.
Trabalhar demais só resulta em mais trabalho. Trabalhar até tarde não resulta em
mais produtividade; ao contrário:
diminui a produtividade. Trabalhar demais resulta em fatiga, que leva a erros, que
leva a necessidade de consertar algo
que você acabou de terminar. Em vez de trabalhar até tarde ou nos fins de semana,
trabalhe apenas nos dias de semana e
apenas em um ritmo sustentável. E tire férias.
Não seja irracional. Os objetivos que são desafiadores estimulam a equipe;
objetivos impossíveis são apenas
desanimadores.
Nada de heroísmo. Se você precisa de um herói para conseguir concluir o trabalho,
você tem um problema. O esforço
heroico deve ser considerado um fracasso no planejamento.
Chega de diretrizes idiotas. Qualquer diretriz que parece ridícula provavelmente é
ridícula mesmo. Formulários idiotas,
reuniões idiotas, aprovações idiotas, padrões idiotas são apenas isso — idiotices.
Se o seu escritório parece tirado de uma
tirinha de Dilbert, conserte isso.
Nada de escrotice. Não seja um e não tolere esse tipo de comportamento. Qualquer
pessoa capaz de causar caos
emocional, inspirar medo ou horror, ou que humilhe e diminua as pessoas, precisa
ser detida.
Busque o fluxo. Opte pelo modo mais suave e sem problemas de concluir uma tarefa. O
Scrum é sobre possibilitar o
maior fluxo possí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 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 [pequena]. 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
-----------------------------------------------------------------------------------
------------
mapa não é o terreno. Não se apaixone pelo seu plano. É quase certo que ele esteja
errado.
Planeje apenas o necessário. Não tente projetar tudo com anos de antecedência.
Planeje o suficiente para manter as
equipes ocupadas.
Raças de cachorro. Não faça estimativas usando termos absolutos, como horas — já
foi provado inúmeras vezes que os
seres humanos são péssimos nisso. Defina o tamanho dos problemas de forma relativa,
de acordo com uma raça do
cachorro ou o tamanho de uma camiseta (P, M, G, GG, XG), ou, o que é mais comum,
usando a sequência de Fibonacci.
Pergunte ao oráculo. Use uma técnica cega, como o método Delphi, para evitar
preconceitos de segurança, como os
efeitos de manada ou halo, ou apenas um modo burro de pensamento em grupo.
Pôquer do planejamento. Use essa técnica para estimar rapidamente o trabalho que
precisa ser feito.
O trabalho é uma história. Pense primeiro sobre quem vai obter valor com algo,
então, pense no que é, e, então, por que
eles precisam daquilo. Os seres humanos pensam em uma estrutura narrativa, então dê
isso a eles. Por exemplo: “como X,
eu quero Y, para conseguir Z”.
Conheça a sua velocidade. Toda equipe deve saber exatamente quanto trabalho
consegue realizar a cada Sprint. E eles
devem saber o quanto podem melhorar a própria velocidade ao trabalhar de forma mais
inteligente, removendo as barreiras
que os tornam mais lentos.
Velocidade x Tempo = Entrega. Uma vez que você saiba a velocidade com que trabalha,
saberá quanto tempo levará
para chegar lá.
Defina objetivos audaciosos. Com o Scrum não é difícil dobrar a produção ou cortar
o cronograma de entrega pela
metade. Se você fizer as coisas da forma certa, a sua receita e o preço das suas
ações também devem dobrar.
-----------------------------------------------------------------------------------
------------

É a viagem, não o destino. A verdadeira felicidade é encontrada no processo, não no

resultado. Em geral, só somos
recompensados pelos resultados, mas realmente queremos recompensar as pessoas que
se empenham para chegar à
grandiosidade.
Felicidade é o novo pretinho básico. A felicidade o ajuda a tomar decisões mais
inteligentes. Além disso, quando você
está feliz, torna-se mais criativo, menos propenso ao emprego e mais propenso a
conquistar muito mais coisas que
imaginou.
Quantificar a felicidade. Não basta apenas sentir-se bem; você precisa mensurar tal
sentimento e compará-lo ao
desempenho real. Outras métricas olham para o passado; a felicidade é uma métrica
que olha para o futuro.
Fique melhor a cada dia — mensure isso. Ao final de cada Sprint, a equipe deve
escolher um pequeno aprimoramento,
ou kaizen, que tornará mais feliz. E essa deve ser a coisa mais importante que
conseguirá fazer no próximo Sprint.
O sigilo é um veneno. Nada deve ficar em segredo. Todo mundo deve saber tudo, e
isso inclui informações financeiras e
salários. A obscuridade só serve para as pessoas que só se preocupam consigo
mesmas.
Torne o trabalho visível. Tenha um quadro que mostre todo o trabalho que precisa
ser feito, e o que já foi feito. Todos
devem vê-lo e atualizá-lo todos os dias.
Felicidade é autonomia, maestria e propósito. Todos querem controlar o próprio
destino, ficar melhores no que fazem
e ter um objetivo maior do que si mesmos.
Estourar a bolha de felicidade. Não fique tão feliz a ponto de acreditar nas suas
próprias besteiras. Certifique-se de que
a felicidade seja mensurada em relação ao desempenho, e, caso haja uma desconexão,
esteja preparado para agir. A
complacência é inimiga do sucesso.
-----------------------------------------------------------------------------------
------------

1. Precisa ser bem-informado em relação ao setor. Com isso, eu quero dizer duas
coisas: o Dono do Produto deve entender o
processo que a equipe está executando o suficiente para saber o que pode ser feito
e, tão importante quanto isso, o que não
pode. Mas ele também precisa entender bem o o quê o suficiente para saber como
traduzir o que pode ser feito em um
valor verdadeiro e significativo. Pode ser um sistema de computador que irá ajudar
o FBI a capturar terroristas ou um
método de ensino que amplie o desempenho dos alunos nas escolas públicas. Esse
profissional precisa conhecer o mercado
a ponto de saber o que fará a diferença.
2. O Dono do Produto deve ter o poder de tomar decisões. Assim como a diretoria não
deve interferir na equipe, ele precisa
ter autonomia para decidir sobre a visão de como o produto será, e o que precisa
ser feito para chegar até lá. Isso é
importante porque o Dono está sob pressão de diversos stakeholders, tanto internos
quanto externos, e precisa ser capaz
de se manter firme. Ele deve ser responsável pelos resultados, mas permitir que a
equipe tome as próprias decisões.
3. Ele tem de estar disponível para a equipe, para explicar o que precisa ser feito
e o porquê. Embora o Dono do Produto seja
basicamente o responsável pela definição das Pendências, é necessário que haja um
diálogo constante com a equipe. Em
geral, o especialista da equipe informa as decisões que o Dono do Produto precisa
tomar. Então, essa figura precisa ser
confiável, consistente e estar disponível. Sem acesso a ele, a equipe não saberá o
que fazer, e muito menos em que ordem
fazer. Eles dependem do Dono do Produto para obter “a visão” e, também, para que a
inteligência de mercado saiba o que
é importante. Se o Dono não estiver disponível para a equipe, todo o processo pode
desmoronar. Eu raramente recomendo
que CEOs ou outros altos executivos ocupem esse cargo. Eles não têm o tempo de que
a equipe precisa.
4. Ele precisa ser responsável pelo valor. Em um contexto empresarial, o que
importa é a receita. Eu avalio o Dono do
Produto de acordo com a receita que gera por “ponto” de esforço. Se a equipe está
produzindo quarenta pontos por
semana, eu quero medir quanta receita é gerada para cada ponto. Mas a medida de
valor poderia ser quantos sucessos a
equipe obteve. Conheço uma equipe de polícia que media o valor pelo número de
prisões de criminosos procurados por
semana, conheço igrejas que usam o Scrum e medem o sucesso avaliando o serviço que
estão prestando à congregação e
se ela está crescendo. O importante é decidir qual medida de valor será usada, e
cobrar do Dono do Produto que ela seja
entregue em maior quantidade. No Scrum, esse tipo de métrica é fácil de observar,
por causa da incrível transparência do
método.
-----------------------------------------------------------------------------------
------------

Faça uma lista. Verifique-a duas vezes. Crie uma lista de tudo que é possível fazer
em um projeto. Depois, classifique-a
por ordem de prioridade. Coloque os itens com mais valor e menos risco no topo das
Pendências, então o próximo item, e
assim por diante.
Dono no Produto. É a pessoa que traduz a visão em itens da lista de Pendências. Ela
precisa compreender o negócio, o
mercado e o cliente.
Um líder não é um chefe. Um Dono de Produto define o que precisa ser feito e por
quê. A forma como a equipe vai
fazer isso e quem vai fazer é ela mesma que decide.
O Dono do Produto. É a pessoa que detém o conhecimento do domínio e que tem a
última palavra. Está disponível para
responder às perguntas e é a responsável por entregar valor.
Observe, Oriente, Decida, Aja (OODA). Tenha uma visão completa do quadro
estratégico, mas aja de forma rápida e
tática.
Medo, incerteza e dúvida. É melhor causar esses sentimentos do que recebê-los.
Entre no ciclo OODA do seu
concorrente e faça com que ele se enrole na própria confusão.
Ganhe dinheiro por nada e faça alterações de graça. Crie coisas novas apenas quando
elas geram valor. Esteja
disposto a trocá-las por algo que exija um esforço equivalente. O que você pode ter
acreditado ser necessário no início
pode ser algo de que você, na verdade, nunca precisou.
-----------------------------------------------------------------------------------
------------
O Scrum acelera todos os empreendimentos humanos. Não importa o tipo de projeto ou
de problema, o Scrum pode
ser usado em qualquer empreendimento, para aprimorar desempenho e resultados.
Scrum para escolas. Na Holanda, um número crescente de professores está usando o
Scrum. Eles conseguem ver um
aumento quase imediato de mais de 10% nas notas dos alunos; e aplicam o método em
todos os tipos de estudantes, das
classes técnicas às avançadas.
Scrum pela pobreza. Em Uganda, a Grameen Foundation está usando o Scrum para
fornecer dados agrícolas e de
mercado para os lavradores pobres da zona rural. O resultado? O dobro da colheita e
da receita para algumas das pessoas
mais pobres do planeta.
Rasgue seus cartões de visita. Livre-se de todos os cargos, gerentes e estruturas.
Dê às pessoas a liberdade de
fazerem o que acham melhor e a responsabilidade de serem cobradas por isso. Você
ficará surpreso com os resultados.

-----------------------------------------------------------------------------------
------------

Implementando o Scrum: como começar

Agora que terminou de ler o livro, aqui está um resumo sobre a melhor forma de
começar
um projeto Scrum. Esta é uma descrição bem ampla do processo, mas deve ser
suficiente
para você começar. O livro foi escrito para explicar o porquê por trás do Scrum.
Esta parte
irá, de forma resumida, explicar o como.
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. (Consulte
o Capítulo 8, Prioridades, para obter mais informações)
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. (Consulte o Capítulo 3,
Equipes, para obter mais informações)
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. (Consulte
o Capítulo 4, O Desperdício é Um
Crime, para obter mais informações)
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 prioridade 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.
(Consulte o Capítulo 8, Prioridades, para obter mais informações)
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. 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. (Consulte o Capítulo 6, Planeje
a Realidade, Não a Fantasia, para obter mais informações)
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. (Consulte o Capítulo 6, Planeje a
Realidade, Não a Fantasia, para obter mais
informações.)
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. 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.
(Consulte o Capítulo 7, Felicidade, para obter mais informações)
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. (Consulte o
Capítulo 4, Tempo, e o Capítulo 6, Planeje a Realidade, Não a fantasia, para obter
mais informações)
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.
(Consulte o Capítulo 4, Tempo, para obter mais informações)
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.
(Consulte o Capítulo 7, Felicidade,
para obter mais informações)
11. Comece imediatamente o próximo Sprint, considerando a experiência da equipe com
os impedimentos e os
aprimoramentos no processo.
-----------------------------------------------------------------------------------
------------------------------------
Ohno fala sobre três tipos diferentes de desperdício. Ele usou palavras japonesas:
Muri,
desperdício causado pela irracionalidade; Mura, desperdício causado pela
inconsistência; e
Muda, desperdício causado pelos resultados. Essas ideias estão bastante alinhadas
com o
ciclo PDCA de Deming, sobre o qual escrevi um pouco antes: Plan [planejar], Do
[fazer],
Check [verificar], Act [agir]. Planejar significa evitar o Muri; Fazer, evitar o
Mura; e
Verificar, evitar o Muda. Agir é sinônimo de vontade, motivação e determinação para
fazer
tudo isso. Vou abordar todos esses passos, um de cada vez, e apontar o que se deve
evitar —
desde o desperdício no estoque, até o desperdício de se trabalhar demais e o
desperdício
emocional de expectativas irracionais