O documento descreve o conceito japonês de Nemawashi, que é um processo informal de estabelecer bases para mudanças através de conversas e obtenção de apoio. Explica como o Nemawashi foi adotado pela Toyota para melhorar a comunicação durante mudanças e é hoje um pilar da filosofia lean. Também resume como o Planning Poker, um método ágil de estimativas baseado em cartas, aplica os princípios do Nemawashi para tomada de decisões por consenso.

1. Nemawashi
(Implementando mudanças)
Nemawashi (根回し?) significa um processo informal de estabelecer as bases de
alguma proposta de mudança ou projeto, falando com as pessoas envolvidas,
conseguindo apoio e feedback e assim por diante. É considerado um elemento
importante em qualquer grande mudança, antes de quaisquer medidas formais, sendo
que o Nemawashi bem sucedido é aquele que possibilita mudanças com o consenso de
todos os lados envolvidos. Ele normalmente é realizado em pequenos grupos, várias
vezes e com diferentes pessoas, a fim de captar os elementos chaves que podem
influenciar o projeto em questão.
Nemawashi pode ser traduzido literalmente como dando voltas na raiz, de 根 (ne, raiz)
e 回す (mawasu, dar volta em algo). Seu significado original era literal: cavar ao redor
das raizes de uma árvore para prepará-la para um transplante.
Nemawashi é frequentemente citado como um exemplo de palavra japonesa que é
difícil de traduzir efetivamente, pois é muito intrínseca à cultura japonesa, apesar de
muitas vezes ser traduzida como lançando as bases.
Nemawashi nas empresas: O Nemawashi começou a ser difundido nas empresas
japonesas, mais precisamente na Toyota em meados do século XX quando o seu
engenheiro-chefe Taiichi Ohno percebeu que o principal fator de falta de sinergia
durante um processo de mudanças era a falta de comunicação. Então os colaboradores
da Toyota tinham de, antes de fazer alguma nova alteração no processo, conversar com
todos os envolvidos em busca de informações relevantes. Hoje o Nemawashi é um pilar
importante da filosofia lean (ou Toyota Production System), codificado por John Shook
e James Womack durante um estudo mundial do MIT que, subsequentemente,
fundaram o Lean Enterprise Institute, berço da disseminação cultura lean ocidental
juntamente do Lean Institute Brasil.
O princípio Lean do Nemawashi, estabelece que as decisões sejam tomadas lentamente,
através de consenso, para que todas as alternativas relacionadas possam ser avaliadas e
para que haja amplo comprometimento com relação ao que for decidido.
Isso soa um tanto estranho quando confrontado com o imediatismo dos tempos atuais.
Nas culturas ocidentais, a demora do processo decisório costuma ser associada a algo
negativo, como a hesitação.
Já nas culturas orientais, aguardar até o último momento para tomar uma decisão
representa sabedoria, por isso saber o momento certo para se tomar uma decisão torna-
se importante e para isso estimar tempo em projetos é fundamental. Por este motivo, as
estimativas de tempo nos projetos Scrum seguem os preceitos do Nemawashi.
Se você não está familiarizado com estimativas em projetos ágeis, deve estar curioso

2. para saber como isso funciona na prática, certo? Então vamos lá. Como tudo no Scrum,
é bem simples, desde que feito da forma correta e com a ajuda das ferramentas certas.
Mas fiquem calmos, mesmo sendo um processo lento, uma vez que pode demandar
discussões prolongadas, está longe de ser chato. Na verdade, definimos estimativas para
os requisitos do Backlog do Produto jogando cartas e o nome desse jogo é “Planning
Poker”.
É isso mesmo, você não entendeu errado. Aliás, em minha opinião, o Planning Poker é
uma das melhores abordagens, senão a melhor, para definição de estimativas através de
consenso. Sei que parece esquisito, principalmente para quem está habituado a engolir
estimativas, normalmente empurradas “goela-abaixo” pelo gerente do projeto ou algum
especialista da equipe (felizmente no mundo ágil não existe espaço para essas “boas
práticas”). Sendo assim, vamos ao jogo.
Se vamos jogar cartas, precisamos de um baralho certo? Exato, e temos um específico
para essa finalidade. Abaixo apresento um modelo bastante utilizado em projetos ágeis:
Existem vários modelos de baralhos para jogar Planning Poker, na verdade, são muito
parecidos e o que muda é a quantidade de cartas (normalmente variam de 12 a 14).
A escala de números, de 0 a 100, é utilizada para determinação das estimativas.
Podemos utilizar essa escala para representação de horas, dias, pontos de função ou
story-points (unidade utilizada especificamente em projetos de desenvolvimento de
software). Os números também podem ser utilizados como unidades de comparação,
por exemplo: um requisito 40 é duas vezes maior que um requisito 20, o qual é quatro
vezes maior que um requisito 5 e assim por diante.
Observe que a seqüência numérica das cartas não é linear. Isso ocorre por que está
baseada na escala do matemático italiano Leonardo Fibonacci. A série de números
evolui através da soma do número anterior com o número seguinte e assim
sucessivamente. Esta sequência foi desenvolvida por Fibonacci na idade média, para
descrever o crescimento de uma população de coelhos.
A utilização desta escala para estimativa de requisitos tem duas finalidades principais:
1) Mostrar que quanto menor o requisito, menor será a variação da estimativa. Por
exemplo: para um requisito com esforço de desenvolvimento 3, pode ocorrer uma

3. variação de estimativa entre 2 e 5 (utilizando as cartas), o que corresponde à uma
oscilação baixa. Já para um requisito com esforço 20, pode ocorrer uma variação bem
maior, entre 13 e 40. Dessa forma, o Time de Projeto é encorajado a trabalhar com
requisitos menores, com o objetivo de reduzir a variação das estimativas.
2) Forçar a discussão e a análise mais aprofundada das estimativas entre os
integrantes do Time. Escalas lineares tendem a favorecer discussões mais rápidas e
superficiais, uma vez que os impasses tendem a ser resolvidos através da adoção de
médias, por exemplo: uma discussão entre estimativas de 13 e 20 pode resultar em um
consenso entre 16 ou 17.
Legal, mas e aquelas três últimas cartas da seqüência, o que representam? Bem, vamos
começar pelo ponto de interrogação. Quando alguém apresenta esta carta para uma
estimativa, está dizendo aos demais integrantes do Time que não tem a menor idéia do
esforço para construção do requisito, na prática, está abstendo-se de votar. A carta com
a xícara de café (pode ser de chá ou chocolate, se preferir), quer dizer que está sendo
solicitada uma interrupção no jogo (intervalo), para descanso ou atendimento dos
chamados da natureza. A carta com “E” representa um Épico. Épicos são estórias ou
requisitos muito grandes que, segundo o proponente da carta, não pode ser estimado da
forma como está. Se o Time concordar com essa opinião, o requisito será “quebrado”
em unidades menores, até que possa ser adequadamente estimado.
Jogando Planning Poker
Para começar, estabeleça um timebox de 4 horas para esta atividade. Todos os Porcos
podem participar: componentes do Time de Projeto, Dono do Produto e ScrumMaster.
Galinhas e Vacas, se presentes, serão meros expectadores. É importante reforçar que o
Dono do Produto e o ScrumMaster participam para assessorar o Time com informações
que poderão auxiliar na definição das estimativas, entretanto, somente os responsáveis
diretos pelo desenvolvimento do produto podem jogar.
Sentados ao redor de uma mesa, cada integrante do Time segura um baralho com as 14
cartas apresentadas anteriormente. Um requisito é selecionado do Backlog do Produto
para estimativa. Normalmente, costumo começar pelos requisitos menores, mas com
prioridade mais alta. Caso ainda exista alguma dúvida com relação ao item escolhido,
os integrantes do Time de projeto pedem esclarecimentos adicionais ao Dono do
Produto. A partir do momento que o Time acredita possuir as informações
necessárias, o processo de definição das estimativas é iniciado da seguinte forma:

4. 1) Cada integrante do Time escolhe uma carta que corresponde à sua estimativa para
o desenvolvimento do requisito;
2) À medida que são escolhidas, as cartas são colocadas sobre a mesa, com a face
(estimativa) virada para baixo;
3) Após todos os integrantes do Time terem definido suas estimativas, as cartas são
viradas e apresentadas ao mesmo tempo;
4) Se as estimativas foram iguais, adota-se o número como esforço de construção
estabelecido para o requisito;
5) Se houver divergência de estimativas, cada integrante do Time apresenta seus
argumentos para justificar o número escolhido;
6) Encerradas as argumentações, o processo de votação é repetido, até que uma
estimativa de consenso seja alcançada pelo Time.
Cabe ao Time de Projeto estabelecer as regras para alcance de consenso sobre as
estimativas, durante as rodadas do Planning Poker (unanimidade, 3 rodadas, 2 rodadas
etc.).

5. Definido o esforço de construção do requisito, outro item é selecionado do Backlog do
Produto e o ciclo é repetido até que todos os requisitos estejam estimados.
Considerações Importantes:
A definição de estimativas não precisa, nem deve, ocorrer em um único evento. O
processo de desdobramento, o qual também podemos chamar de refinamento de
requisitos, ou grooming, deve considerar inicialmente os itens de maior prioridade do
Backlog. Os demais requisitos (de menor prioridade) podem receber estimativas de
alto-nível, até chegar o momento de serem desenvolvidos, quando então o
desdobramento será necessário. A figura abaixo ajuda a explicar essa dinâmica:
Estimativas são como um bom vinho, melhoram somente com o tempo. À medida que o Time
acumula ciclos de entrega, utiliza a experiência adquirida para aprimorar o processo e a
qualidade das estimativas. É extremamente importante que o Time adote sempre estimativas
consideradas reais, sem contar com milagres ou margens de segurança (gorduras). Somente
dessa forma haverá condições para melhoria contínua das estimativas ao longo do tempo.
Por fim, vale reforçar que as estimativas nos projetos Scrum são determinadas exclusivamente
pelo Time de Projeto, através de consenso. Em nenhuma hipótese os integrantes devem aceitar
números que não considerem viáveis, impostos por pressão do Dono do Produto ou qualquer
usuário-chave.
Por outro lado, o time não pode utilizar essa condição para trabalhar somente com estimativas
“confortáveis”, sem nenhum desafio. Trata-se de um equilíbrio delicado, que exige
profissionalismo, maturidade e muita transparência. Nesse contexto, cabe ao ScrumMaster
exercer sua liderança, através do método Socrático, para assegurar a qualidade e a eficácia do
processo.
Créditos do texto a:
http://pt.wikipedia.org/wiki/Nemawashi
Roberto Simões
http://scrumex.com.br/blog/?p=1239&goback=%2Egde_2379511_member_51150242
Por: Jose Donizetti Moraes - 02/09/2012