Ebook

Como executar
uma(CAPA)
Inspect
and Adapt
OS PASSOS

0INDRODUÇÃO
3
WORKSHOP DE RESOLUÇÃO
DE PROBLEMAS

Passo 1 Acordar qual problema

1
será resolvido

PI SYSTEM DEMO Passo 2 Aplicar Análise de causa

raiz (5 porquês)

Passo 3 Identificar a maior causa

2
raiz com a análise de
pareto
MÉTRICAS QUANTITATIVAS
E QUALITATIVAS Passo 4 Reafirmar o novo
problema para a maior
causa raiz
2.1 Métricas Qualitativas
do programa Passo 5 Brainstorm de soluções

2.1 Métricas Quantitativas Passo 6 Identificar itens de

do programa melhoria para o backlog
INTRODUÇÃO
O evento de Inspect & Adapt ocorre dentro da Iteração IP, ou seja, sempre ao término
da PI.

Assim como ocorre na PI Planning, este é um evento que também demanda

a presença de todos. Isto se faz necessário porque é agora que teremos a
oportunidade de observar os resultados atingidos ao longo de toda a PI e planejar
melhorias para todo o ART.

Este momento pode ser dividido em 3 partes distintas:

1 2 3
PI System Métricas Workshop de
Demo Qualitativas e resolução de
Quantitativas probelmas

Vamos entender melhor cada uma destas partes:

PI System Demo: é uma grande demonstração de todas as Features desenvolvidas

ao longo da PI.

Métricas Qualitativas e Quantitativas: hora de avaliar e debater métricas de times

e ART.

Workshop de resolução de problemas: é como uma retrospectiva, mas uma grande

retrospectiva porque aqui vamos ter a oportunidade de pensar ações de melhoria
para todo o ART.

Tudo isso nós veremos com mais detalhes na sequência, combinado?

Mas, antes disso, vale a pena dizer que normalmente a condução deste evento é feita
pelo RTE (Release Train Engineer) e, ao término da Inspect & Adapt, os times devem
iniciar a PI Planning.

<< VOLTAR AOS PASSOS 3

PI SYSTEM DEMO
Ao chegar no final da nossa PI, precisamos avaliar se os nossos
objetivos traçados na PI Planning foram atingidos. Alinhado
com o princípio #5 - Base Milestones on objective evaluation of
working systems, este evento fecha o nosso ciclo de PI, e assim
começa a nossa I&A, com a PI System Demo.

Diferente da System Demo ao final da Iteração, esta cerimônia

tem um público mais abrangente do que somente os
participantes do ART. Podemos inclusive considerar o envio de
convites para todos os participantes da PI Planning além de
Clientes e Representantes do Portfolio.

Timebox: 1 hora ou menos

Os Agile Teams com o suporte do System Team ajudam o

Product Management a preparar a PI System Demo. Juntos
eles determinam cenários que serão demonstrados com
as funcionalidades integradas e em ambientes próximos
ao real (stage). Esta apresentação deve manter ao máximo
os stakeholders e outros participantes engajados de forma
que possam seguir o fluxo sugerido e receber o máximo de
feedback.

<< VOLTAR AOS PASSOS 4

Aproveite a demonstração do sistema como um ponto de
aprendizado e feedback. O time já realizou as Reviews e System
Demos durante as iterações. A partir delas, foram coletados
indicadores de integração e validado testes. Agora, queremos ser
capazes de ter a visão geral da Value Stream, unindo o que foi
construído iteração por iteração, vendo o todo em funcionamento.

Validação em Staging
Quando falamos que a PI System Demo deve acontecer em um ambiente próximo ao
real em produção, estamos falando de STAGING. Ou seja:

Ambiente que hospeda sistemas validados, a partir

do qual eles podem ser implantados em produção.

Segue um assessment (Baixe aqui) para verificar como está a maturidade de seu time
quando falamos desta preparação da entrega para a PI System Demo.

Agenda do Evento (Baixe aqui)

Então, vamos começar a organizar esta demonstração com a seguinte Agenda:

1 Boas-vindas aos participantes e stakeholders

2 Revisão do negócio, contexto e PI Objectives

3 Descrever e demonstrar cada nova funcionalidade

4 Perguntas e respostas

5 Fechamento – Progresso, Feedback e Melhorias

5
Perguntas e Respostas
Chegando ao final, é interessante abrir um momento para perguntas. É hora de
deixar que os participantes tirem suas dúvidas, discutam sobre a demonstração para
que não haja impedimentos de seguir adiante com o ART.

Fechamento – Progresso, Feedback e Melhorias

Fazer um bom fechamento do evento inclui ressaltar o progresso do que está
sendo desenvolvido, as melhorias que foram implementadas e pedir feedback aos
participantes.

Como temos um timebox definido de mais ou menos 1 hora, segue como sugestão
ter um “Feedback Wall” onde todos possam deixar elogios, críticas e melhorias sobre
o conteúdo apresentado.

Resultados Esperados
O esperado como resultado da PI System Demo são os feedbacks dos participantes,
que podem trazer melhorias, ajustes e novas funcionalidades para a solução que está
sendo entregue.

Lembrando que, ao final da apresentação, os Business Owners irão avaliar os

Business Values para cada objetivo acordado durante a PI Planning. Este é o ponto de
partida para a análise das métricas.

6
MÉTRICAS
QUALITATIVAS E
QUANTITATIVAS
Na segunda parte da Inspect & Adapt, os times ágeis
revisam todas as métricas quantitativas e qualitativas que
concordaram em coletar e, em seguida, discutem os dados e
as tendências.

O Relatório de Desempenho do Programa é uma autoavaliação

altamente subjetiva, embora razoavelmente quantitativa.

É possível que times criem objetivos que sejam 100% atingidos

em todas as PI. Mas, fique atento, pois isso pode significar
que eles estejam “sub comprometidos”. Por outro lado, não
queremos que os times cumpram apenas metade de seus
objetivos de PI.

Outro ponto importante, é estabelecer qual a porcentagem

ideal ou intervalo de porcentagem que queremos que seja
repetível. Esta faixa de percentagem repetível é denominada
“Faixa de Controle Efetivo do Processo”.

<< VOLTAR AOS PASSOS 7

1. Métricas Qualitativas do Programa
Como parte da PI System Demo, as equipes comparam os Objetivos de PI planejados
e os resultados alcançados durante a execução da PI.

> As equipes se reúnem com os Business Owners para conjuntamente avaliar o valor
do negócio alcançado para cada objetivo estabelecido na PI Planning.

> Os valores de negócio relacionados aos Objetivos de PI para cada time ágil
planejados e alcançados são comparados como Medida de Previsibilidade do
Programa

1.1 Avaliação de Desempenho do Time

A intenção aqui é que cada time avalie “Como fomos?” em relação ao atingimento
dos valores de negócio estabelecidos pelos Business Owners para cada Objetivo de
PI.

> Todos os objetivos de PI de todos os times tiveram um valor de negócio atribuídos

entre de 1 a 10, no final do segundo Team Breakout da PI Planning.

> Durante a PI System Demo, Business Owners farão a revisão e avaliarão junto com
os times ágeis as Features e Enablers finalizadas e entregues durante a execução da
PI.

• Cada time irá refletir sobre quão bem foram em relação a seus objetivos de
PI, incluindo pontualidade, conteúdo e qualidade.

• Os Business Owners classificarão cada Objetivo de PI em uma escala de 1 a

10, considerando o valor máximo para o negócio com base na percepção em
relação à entrega.

> Faça a média de todos os objetivos e obtenha uma pontuação percentual de

realização do programa.
Relatório de Desempenho de PI do Time Medida de Previsibilidade do Programa

<< VOLTAR AOS PASSOS 8

1.2 Relatório de Desempenhode PI do Time
Para o relatório de desempenho de PI de cada time ágil, leve em conta os seguintes
pontos:

> O total planejado não incluindo objetivos não comprometidos

> O total alcançado incluindo objetivos não comprometidos

> % Realização = Total Alcançado / Total Planejado

> Uma equipe pode atingir mais de 100%, como resultado de objetivos não
comprometidos alcançados

> O esforço necessário para objetivos não comprometidos é incluído na avaliação de

desempenho porque não representam trabalho extra, mas sim itens planejados cujo
resultado simplesmente não era certo de ser alcançado

> Os totais individuais do time são acumulados para determinar a Medida de

Previsibilidade do Programa

9
1.3 Métricas de Previsibilidade do Programa
A relação de confiança entre o negócio e a tecnologia deve ser estabelecida com
base em previsibilidade de entrega. Para isso, precisamos de uma medida de
previsibilidade do programa que mostre se as realizações estão em uma faixa de
controle de processo aceitável.

Como dissemos inicialmente, é preciso estabelecer uma porcentagem ideal ou

intervalo de porcentagem que seja repetível, a “Faixa de Controle Efetivo do
Processo”.

Veja o material extra (Baixe aqui)

Nas primeiras PI, os times podem estar 10, 20 ou 30% fora da faixa estabelecida. É
importante que esse tipo de situação seja objeto de reflexão e avaliação dos times,
para entender os motivos que levaram a isso.

10
2. Métricas Quantitativas do Programa
Neste ponto, cada time avalia “Quanto fizemos?”, observando o fluxo de trabalho
dos times e tendo por base métricas acordadas entre todos os membros de time.
Essas métricas devem possibilitar a identificação de problemas e promover a
melhoria contínua do sistema de trabalho e da qualidade das entregas.

Colete e discuta quaisquer outras métricas do programa que a equipe concordou em

coletar para refletir sobre o sistema de trabalho e a qualidade do que é feito.

Insira quaisquer slides de contexto e faça a revisão das métricas usando esta agenda.

Abaixo, você tem um conjunto sugerido de métricas que podem ser compartilhadas
entre times e com sua organização. Você pode usar outras métricas além dessas,
sendo importante que cada métrica acordada esteja relacionada com o fluxo de
trabalho dos times e estabeleça ações de melhoria a partir de uma análise de causa-
raiz.
Funcionalidade PI 1 PI 2 PI 3
Velocidade do Programa
Métricas de previsibilidade
# Features planejadas
# Features aceitas
# Enablers planejados
# Enablers aceitos
# Stories planejadas
# Stories aceitas
Qualidade
Coberturas de testes unitários %
Defeitos
Total de testes
% automação
Testes de NFR

Duração sugerida para Métricas Quantitativas : 45 - 60 min

Lembre-se que coletar e analisar métricas envolve esforço pode requerer a adoção
de práticas e ferramentas que apoiem essa iniciativa.

Veja o material extra (Baixe aqui)

<< VOLTAR AOS PASSOS 11

WORKSHOP DE
RESOLUÇÃO DE
PROBLEMAS
Na última parte da Inspect & Adapt os times são convidados
a refletir a respeito de problemas que podem estar afetando
todo o ART durante a última PI, ou seja, vamos fazer uma
grande retrospectiva.

Vale ressaltar que aqui serão abordados temas no nível de

programa e não de time. Isto porque os times já têm as suas
retrospectivas ao longo de toda a PI.

Agora é hora de conectar as métricas apresentadas e

debatidas anteriormente e encontrar soluções para alavancar
bons resultados e gerar ações que irão atacar os problemas.

A discussão em torno de números torna o encontro mais

prático do que uma discussão baseada apenas em percepções,
por exemplo. Se os indicadores apresentados anteriormente
forem desprezados o ART pode perder uma boa chance de
evoluir no próximo ciclo.

<< VOLTAR AOS PASSOS 12

Agora que já trouxemos a importância em conectar as métricas com esta próxima
etapa, é bom entendermos que o SAFe propõe algumas etapas para a realização do
workshop de resolução de problemas:

13
Você pode usar o canvas (Baixe aqui) abaixo para orientar todo o trabalho:

Este canvas representa cada uma das etapas que citamos anteriormente:

Na sequência nós vamos detalhar cada uma destas etapas para te ajudar a planejar,
executar e facilitar de forma mais fluída e conectada o seu workshop de resolução de
problemas.

Vamos também trazer algumas dicas práticas, combinado?

14
Passo 1
Acordar qual problema será resolvido

Um ART é composto por 45 a 125 pessoas. Portanto, um volume considerável de

pessoas. Além disso, cada indivíduo tem as suas percepções e questionamentos, e
por mais que trabalhem em um único ART, o seu dia a dia está muito conectado ao
seu time.

Bom, agora que já entendemos o cenário é preciso encontrar o problema a ser

atacado e para isso nós precisamos capturar o feedback das pessoas. Isto pode ser
feito de duas maneiras:

> Pedindo para que as pessoas indiquem livremente os problemas que afetaram o
ART;

> Pedindo para as pessoas indiquem o principal problema que afetou o ART;

As duas alternativas podem funcionar bem, mas é bom você avaliar alguns aspectos:

Proposta Prós Contras

Pedido que as pessoas indiquem
livremente os problemas que
afetaram o ART
(Múltiplos intens por time)
As pessoas se sentem mais à No final você pode ter muitos
vontade quando podem expressar itens repetidos e certamente não
todas as suas “dores“ haverá tempo para discutir tudo
Pode funcionar bem se o seu ART Pode ser um caos se o seu ART
for bem pequeno comporta muitas pessoas

Pedindo para as pessoas É mais objetiva! Requer uma boa reflexão de

indiquem o principal problema
que afetou o ART
(Apenas 1 item por time)
Funciona bem para grandes ARTs
tudo o que ocorreu durante a
PI. Algumas pessoas acabam
tendo uma visão muito ligada
ao que ocorreu nos últimos dias
ou semanas, então é bom ficar
atento a isto.

<< VOLTAR AOS PASSOS 15

Uma terceira alternativa seria promover uma mini-retro de cada time na sua
respectiva sala. A saída deste momento são itens que serão discutidos com todos os
outros times na sequência.

Observe que você pode combinar esta mini-retro com qualquer umas das opções
que apresentamos acima. Se você combinar com a segunda proposta (apenas 1 item
por time) a sua retro provavelmente será muito mais enxuta.

Por exemplo: se o seu ART é composto por 10 times, seu board terá somente 10
itens. Isto certamente pode ajudar bastante o facilitador.

Para promover a diversidade de ideias e quebrar aquilo que

chamamos de “pensamento de grupo” o RTE pode mesclar os times,
alterando a sua composição.

Caso faça isso, pode ser interessante dar algum tempo adicional
para que a discussão interna possa fluir, já que a probabilidade de
haver diferentes opiniões é grande.

Agora é hora de escolher qual item nós vamos aprofundar a discussão e elaborar um
plano de ação.

A forma mais simples de fazer isso é usar a técnica do Dot Voting.

Porém, certifique que os itens a serem votados são realmente bem distintos. Quando
temos itens com alguma similaridade a votação pode ser prejudicada.

Veja o exemplo abaixo:

Hamburger
Bife e Comida Indiana Vegetais
vegetariano
batatas (vegetariana) Grelhados
no praro

16
Repare que neste exemplo, a opção “bife e batatas” foi a mais votada, no entanto,
as outras opções fazem referência a comida vegana e, se somarmos todos os votos
da opção vegana, teríamos um total de 12 votos contra apenas 6 da opção “bife e
batatas”.

Antes de abrir a votação o facilita precisa checar os itens e agrupar aquilo que estiver
duplicado, ok?

Uma outra opção, caso você não queira usar o Dot Voting, é o Zen Voting.

Normalmente o Dot Voting permite um voto por pessoa. Já o Zen Voting pode trazer a
possibilidades de 2 ou 3 votos por pessoa:

Dot Voting

1 voto 1 voto

Zen Voting

3 votos 3 votos

Abrir a possibilidade de mais de um voto por pessoa pode ajudá-la a se concentrar

nas melhores opções.

17
Muitos facilitadores, quando usam o Zen Voting, também abrem a possibilidade
do votow negativo. Na prática, cada pessoa teria direito a 2 votos positivos e 1 voto
negativo, por exemplo:

2 votos positivos 2 votos positivos

1 voto negativo 1 voto negativo

O voto significa que a pessoa não acredita que aquilo que seja relevante, importante.
Quando usamos desta forma a contagem é diferente:

Baixa cobertura
Problemas de Dependências
de testes
comunicação não mapeadas
automatizados

Total de 7 votos Total de 8 votos Total de 11 votos

6 positivos 5 positivos 4 positivos
1 negativo 3 negativo 7 negativo
Contagem final = 6 votos Contagem final = 5 votos Contagem final = 4 votos

Na prática, a contagem final é igual a quantidade de votos positivos. Simples assim!

Bom, neste caso, o item vencedor é a baixa cobertura de testes automatizados.

18
Para evitar uma concentração de votos e fazer com que as pessoas
visitem mais itens, crie a seguinte restrição:

Seus votos positivos não podem ser no mesmo item ;)

Observe que dada a quantidade de pessoas e times existe a possibilidade de

discutirmos os principais problemas, os itens mais votados. E não apenas um.

Primeiro porque ficaria inviável discutir soluções com um grupo tão grande e, além
disso, seria um desperdício. Outro cenário que pode ser ruim também é quando
todos os times discutem o mesmo problema. Cada um vai gerar um plano de ação e
isto pode ser confuso, pouco produtivo e gerar divergências desnecessárias.

Você já entendeu que o facilitador precisa se preparar para este momento. Ele
pode, por exemplo, já estabelecer previamente uma determinada quantidade de
problemas. Ele também precisa pensar como os problemas serão endereçados aos
times.

Abaixo estão algumas ideias:

Cenário Prós Contras

Qualquer time escolhe o
problema que quiser
Problemas endereçados a times
específicos
Mesclar times
As pessoas podem não ter
nenhum vipes e mente aberta
para discussão.
A livre escolha pode gerar
engajamento
São conhecedores do problema
com profundidade
Aqui nós temos os mesmo
benefícios que já citamos na
dica acima. Além disso, essa
pluralidade pode gerar uma
“tensão positiva“ interessante.
As pessoas podem saber pouco
sobre o problema e não tem
muita idéia de como podem
resolvê-lo.
Podem gerar discussões
enviesadas e pouco criativas,
limitadas.
As pessoas não se sentem muito
a vontade para discutir.
O facilitador precisa saber
como o ambiente e a cultura se
comportam diante desta mescla

Você também pode misturar estas três ideias, ok?

Só vale novamente a ressalva de como as pessoas podem ser comportar em cada

cenário.

19
Enfim, o que citamos anteriormente diz muito a respeito da organização e sequência
de passos que serão abordados nos próximos tópicos. Porém, como precisamos
finalizar este passo com um problema a ser resolvido é importante já explicar tudo
isso para você agora mesmo.

Até agora focamos muito na questão do que melhorar porque os passos que
veremos na sequência são para gerar ações de melhoria no ART, no entanto, você
sabe que uma retrospectiva também precisa trazer os pontos positivos.

Para levantar os pontos positivos você usar as mesmas estratégias que foram
citadas anteriormente ou promover algo mais leve, lúdico. Algo que dê um destaque
e reforce aquilo que está funcionando bem.

O facilitador pode “provocar” as pessoas a responderem algumas perguntas que

ampliam cada ponto positivo:

> O que nós aprendemos com isto?

> O que podemos fazer para manter isto funcionando?

> De que forma podemos alavancar esta iniciativa?

Existem inúmeras formas de realizar uma boa retrospectiva. Nosso objetivo aqui foi
trazer algumas particularidades quando estamos em um ART.

Como facilitador, lembre-se também de, sempre que possível, trazer algum elemento
novo para este momento. Normalmente os times se sentem mais engajados na retro
quando há algo de diferente.

20
Passo 2
Aplicar a análise causa raiz (e 5 porquês)

Deste passo em diante, a sessão passa a ocorrer em diferentes salas, ou seja, cada
sala vai discutir um problema que foi votado anteriormente. Vale lembrar que o
facilitador pode novamente utilizar aquela dica de mesclar os times.

É extremamente importante que cada sala tenha um facilitador. Scrum Masters já

reúnem as habilidades de facilitação, porém, eles precisam saber exatamente o
passo-a-passo que apresentaremos. Sem este preparo, a sessão do time pode ser um
tanto quanto confusa.

Considerações feitas, agora vamos investigar as suas origens, ou seja, a sua

verdadeira causa raiz. Para isso vamos explorar as “espinhas” do diagrama:

<< VOLTAR AOS PASSOS 21

Antes de explicar melhor esta etapa precisamos entender melhor cada uma destas
dimensões:

Processo – Aqui devemos considerar todas as causas originadas de falhas de

processo, ou seja, devemos analisar o quanto a forma de trabalhar influenciou no
problema. Por exemplo: se a execução seguiu conforme o planejamento.

Pessoas – As causas podem envolver atitudes ou dificuldades das pessoas na

execução do processo. Por exemplo: pressa, falta de qualificação, imprudência.

Ferramentas – Aqui devemos identificar todas as causas originadas de ferramentas

utilizadas pelo time durante o processo. Como exemplo: funcionamento incorreto de
softwares, falhas mecânicas etc.

Programa – Aqui analisamos o programa como um todo e identificamos falhas que

ocorreram em todo o funcionamento do ART. Falha no sincronismo e ausência de SoS
podem ser alguns exemplos.

Ambiente – Neste item, devemos analisar o ambiente interno e ambiente externo

da organização e identificar quais são os fatores que favorecem a ocorrência dos
problemas, como calor, falta de espaço, layout, barulho, reuniões em excesso etc.

Bom, agora temos condições de seguir adiante.

O facilitador deve manter o grupo em uma dimensão por vez.

Podemos, então, começar da seguinte forma:

De que forma o processo impacta o problema relatado?

22
Para isso, o facilitador normalmente usa a técnica dos “5 porquês”. Isto ajuda a
aprofundar a nossa investigação.

Antes de ir adiante vamos entender melhor esta técnica.

Muitas vezes os relatos podem ser vagos ou superficiais. Os “5 porquês” convidam o

time a fazer uma espécie de brainstorm com o objetivo de aprofundar mais aquele
relato.

Vamos pensar no exemplo abaixo:

Estou com dor de cabeça (primeiro porque)

Não consegui almoçar hoje (segundo porque)

Tive uma reunião de trabalho (terceiro porque)

Estou acumulando atividades (quarto porque)

O planejamento do trabalho está ruim.

Pelo exemplo você já entendeu que uma aspirina pode até “resolver” o problema em
um primeiro momento, mas caso o planejamento do trabalho não seja corrigido esta
dor de cabeça vai se repetir com alguma frequência. Bom, é isso!

Nem sempre é necessário chegar até o quinto porque. O facilitador

deve explicar a técnica previamente e trazer esta técnica com
alguma leveza para que a sessão não se torne um interrogatório.
Lembre-se que as técnicas devem ser usadas para ajudar o time.
O mais importante são as discussões geradas.

Voltando a “espinha de processo”, depois de aplicar os “5 porquês”, seu diagrama

deve ficar com a seguinte aparência:

23
Depois de esgotar a discussão a respeito do processo é hora de partir para outra
dimensão do diagrama:

24

24

24
E aplicar os “5 porquês”:

Este processo se repete para todas as demais dimensões do diagrama.

Feito isso, temos uma vasta gama de possibilidades, o grupo aprofundou, discutiu e
entendeu melhor o que está por trás daquele relato inicial.

25
Passo 3
Identificar a maior causa raiz com a Análise
de Pareto

Agora precisamos decidir qual é a principal causa raiz, qual problema iremos atacar.
Para isso a recomendação é utilizar a Análise de Pareto. Esta teoria estabelece uma
relação 80/20, por exemplo:

> 80% dos resultados de uma empresa vêm de 20% das ações.

> 80% dos chamados de uma central estão relacionados a 20% dos serviços
oferecidos.

> 80% da utilização que você faz do seu smartphone está relacionada a 20% dos
aplicativos instalados.

A ideia é concentrar-se naquilo que realmente irá gerar algum efeito positivo. Em
outras palavras, colocar energia naquilo que trará mais valor.

Logo abaixo tem um passo-a-passo para deixar mais claro com funciona:

Passo 1 – Faça uma lista de problemas e a frequência com que ocorrem;

Passo 2 – Organize os problemas em ordem decrescente;

Passo 3 – Calcule a porcentagem com que os problemas se acumulam;

Passo 4 – Coloque tudo isso em um gráfico onde o eixo “x” indica os problemas e
o eixo “y” a frequência

<< VOLTAR AOS PASSOS 26

Bom, para entender mais na prática como isso funciona, vamos ver juntos o exemplo
abaixo.

Exemplo: suponha uma empresa que registrou um total de 150 reclamações dos
seus clientes no último mês

Passo 1 – Faça uma lista de problemas e a frequência com que ocorrem;

• Atraso na entrega – 120 ocorrências

• Custo elevado – 6 ocorrências

• Mau atendimento – 12 ocorrências

•Qualidade do produto – 9 ocorrências

•Outros motivos – 3 ocorrências

Passo 2 – Organize os problemas em ordem decrescente;

Problema Frequência (qtde de ocorrências)

Atraso na entrega 120

Mau atendinmento 12

Qualidade do produto 9

Custo elevado 6

Outros motivos 3

Passo 3 – Calcule a porcentagem com que os problemas se acumulam;

Problema Frequência (qtde de ocorrências) %

Atraso na entrega 120 80

Mau atendinmento 12 8

Qualidade do produto 9 6

Custo elevado 6 4

Outros motivos 3 2

27
Passo 4 – Coloque tudo isso em um gráfico onde o eixo “x” indica os problemas e
o eixo “y” a frequência

Para te auxiliar nós já colocamos na área de materiais extras o arquivo que gera este
gráfico (Baixe aqui).

Com o gráfico pronto nós já podemos estabelecer a relação 80/20:

28
Então, podemos afirmar que 80% dos problemas relatados estão associados a 20%
de uma causa específica.

E a causa “atraso na entrega” representa 20% das causas mapeadas (ao todo são 5
causas, portanto, cada uma delas equivale a 20% do todo).

Este foi um exemplo bem simples para você entender bem como funciona.

Vamos agora para um exemplo um pouco mais complicado para garantir que
entendemos bem a ferramenta.

29
Voltando agora ao passo da Análise de Pareto dentro da sessão, você pode linkar
as métricas apresentadas anteriormente (passo 02 – métricas quantitativas e
qualitativas) com este tema.

Isto te dará mais insumos para a discussão. Se você não quantificar pode ser inviável
fazer a Análise de Pareto. Por isso, pode ser interessante ter algumas informações
adicionais, métricas de negócio ou algo similar.

30
Passo 4
Reafirmar o novo problema para a maior
causa raiz

Depois do time fazer uma boa análise é hora de reescrever o problema. Esta etapa
nos ajuda a reafirmar aquilo que estamos discutindo e aprofundar ainda mais o que,
quando, onde e impacto do problema.

Para isso o SAFe utiliza um conceito chamado “anatomia de um problema bem

definido”. Vamos entender como isso funciona.

Digamos que o “passo 3”, que vimos anteriormente, apontou pouca comunicação
entre POs de diferentes times, ok?

Isto é legítimo e já nos dá alguma direção, mas pode ser insuficiente. Podemos então,
com base nos relatos, reescrever este problema já indicando os seguintes pontos:
O que, Quando, Onde e Impacto.

Veja como ficaria:

Nossa priorização de objetivos apresenta problemas quando o Product Owners

de diferentes times não se comunicam de forma efetiva especialmente durante
as PO Sync.

Isto gera impacto nos times durante os testes integrados e na implementação

de algumas estórias durante as iterações.

<< VOLTAR AOS PASSOS 31

Observe como agora temos mais profundidade. O próximo passo é para pensar
soluções. Explicitar cada um destes pontos vai ajudar o time a ter um brainstorm
mais efetivo.

Mas antes disso precisamos indicar no nosso board o problema reafirmado:

32
Passo 5
Brainstorm de soluções

Brainstorm é uma técnica muito disseminada, no entanto, precisamos ter alguns

cuidados para que a sessão seja inclusiva e produtiva.

Muitos times fazem o brainstorm sem nenhuma regra, mas como isso nem sempre é
muito efetivo nós vamos trazer algumas dicas e orientações.

O facilitador pode estabelecer algumas regras como, por exemplo:

Sem julgamentos

> Todas as ideias são bem-vindas. Principalmente no início da sessão nós não
devemos julgar ou avaliar ideias porque isso limita muito o grupo já no começo. Crie
um momento mais adiante para isso.

Quantidade

> Quanto mais ideias, melhor!

> Mas podemos ir além: a diversidade de ideias também é algo valioso.

Para isso, o facilitador deve estimular ideias diferentes, ideias criadas a partir de
outras ideias, decompor ideias, encorajar novas abordagens, inverter cenários.

Uma conversa por vez

> Criar alguma estrutura (acordo) para que as pessoas se mantenham em uma única
conversa. Manter o foco de todos evita desgastes e falta de alinhamento.

Seja visual

> Trabalhar com imagens, desenhos ajuda a alinhar todo o grupo. Criar metáforas
também podem ser uma alternativa interessante.

<< VOLTAR AOS PASSOS 33

Uma forma lúdica e eficiente de manter as pessoas com a mente
aberta para novas opções é criar um acordo onde “frases que
matam a criatividade” não podem ser ditas. Frases como:

• Aqui as coisas são diferentes.

• Não temos tempo/budget para isso.
• Nós já tentamos isso antes.
• Pare de sonhar.
• Vamos voltar para a realidade.
• Isto não é meu trabalho.

Ou seja, é uma tentativa de impedir que os “matadores de ideias”

entrem em ação e trabalhem junto com o grupo.

Bom, feito o brainstorm, o time precisa decidir quais ideias serão levadas adiante.
E novamente vamos lançar mão das técnicas de Dot Voting e Zen Voting para
selecionar as principais ideias:

34
Passo 6
Identificar itens de
melhoria para o backlog:

<< VOLTAR AOS PASSOS 35