Roberto Brasileiro é um especialista em agilidade e ScrumMaster há mais de 10 anos. Ele fundou a Agilhes, uma empresa de consultoria e treinamentos em métodos ágeis. A Agilhes oferece serviços de adoção de práticas ágeis e também treinamentos sobre agilidade.

2. Prazer...
Roberto Brasileiro, CSM
Atua com TI desde de 1999, sempre com desenvolvimento
de software.
Desde de 2008 é entusiasta da agilidade.
Atualmente é ScrumMaster na Ci&T e atua como Agile
Coach e Instrutor pela Agilhes, empresa que fundou em
2011.
@_rbrasileiro
roberto@agilhes.com
Consultoria na Adoção de Metodos Ágeis
Consultoria e Treinamentos, visite nosso site.
www.agilhes.com
www.facebook.com/agilhes
info@agilhes.com

3. Agilidade está
crescendo no
Brasil!
• Empresas estão mais receptivas
• Existem mais pessoas
interessadas e envolvidas
• Mercado profissional já existe
• AgileTalk cresceu 300% em 01
ano!

5. • DoS não está ligada a entrega do projeto e sim
a qualidade do seu processo.
• DoS determina qual caminho a seguir.
• Não devemos resolver problemas que não
temos.
• Os problemas/desafios são consequência do
caminho que seguimos.

6. Vilões da
Agilidade!
Cultura não é next, next,
finish!
Gestores devem se reinvetar
Planejamento realizado e,
lógico, não executado.
Cliente não tem nem idéia
do que é agilidade!

7. Principais
sintomas do
Caos

8. Principais Sintomas do Caos
#01 - Qualidade é #02 - Produtividade é
“excelente”, só que o “boa”, só não é melhor
cliente homologa porque não temos os
cenários não previstos! requisitos Ready.
#03 - Esse cliente é
complexo! Não #04 - Seguimos o
entende que ele tem Scrum, mas não temos
que mudar. Demo Review.
Esconder os problemas é o maior sintoma do Caos. Temos
que ser cuidadosos, para não entrar em uma zona de
conforto.

9. Combatendo o
Caos!

10. FALHAR NO
PLANO É
PLANEJAR A
FALHA

11. Planejando a Falha
• Planejamento de entregas sem conseso e/ou participação do time.
– Eu estimo e você executa.
• Banco de Horas cheios! Hora Extra é normal.
– Planejamento já conta com HE, FDS, Natal, Nascimento do Filho e por ai
vai...
• Quanto mais pessoas, mais rápido a entrega.
– Quanto mais pessoa no time, mais problema você vai ter!
• Data acordada é data não cumprida.
– Vamos testar menos! Assim a gente entrega!
– Riscos/Blocks não estão claros.

12. Consequências...
• Pessoas
– Atrito e desgaste entre time e gestores.
– Provavelmente o GP se tornará o inimigo número 01, de todos!
– Desmotivação das pessoas.
– Sentimento de incapacidade.
– Todo problema vai se tornar grande!
• Custo/Margem
– HE vai impactar os custos/margem do projeto.
• Time
– Novas pessoas, significam menor produtividade (Apoio)
• Prazos
– Nunca serão cumpridos.
– Falta de visibilidade dos riscos do projeto.

13. Evitando problemas no plano
• Planejamento colaborativo
– Envolver o time ou parte do time é fundamental.
– Deixar transparente para o time qual o objetivo de cada entrega e desejos do cliente.
– Comprometimento nasce no planejamento.
– Entender todos os lados, Time, Gestores e Cliente.
• Definitivamente, evite hora extra
– HE serve para correr atras do prejuízo e não para antecipar datas.
• Planejar com o que temos, evitar mudanças no time.
• Prazos possíveis!
– Descobrir a capacidade de produção do time.
– Planejar sempre com a capacidade do time.
– Não assumir riscos sozinho.
• Deixe o cliente ciente de tudo!
– Mostre os riscos, capacidade de produção e tudo que puder.

14. Ritos?
Pra
que
fazer
Daily?

15. • User Story Ready? Vai direto pra Planning.
– Falta o Pré-Game/Grooming/Entendimento/Refinamento/Qualquer nome que
quiser...
• Planning falha = Review furado!
– Time sem planejamento “tático” do Sprint.
• Daily técnica e longa, até demais!
– Ninguém nem presta a atenção.
• Demo Review?!?
• Restrospectiva, sem plano de ação?
– Realiza a retro e não gera insumos de melhoria.
– Lavagem de roupa-suja e mais nada!
– Caças as bruxas!
• Done? Que isso?

16. • Construção/Qualidade
– Critérios de aceites são rasos, vai gerar defeito.
– Vários conceitos de Done.
• Produtividade
– Várias atividades não planejadas aparecem dentro do Sprint.
– Blocks!
• Dia-a-dia do time
– Não existe alinhamento nas atividades.
– Não atua na prioridade.
• Melhoria Continua
– Não existe! Sempre os mesmo problemas e culpados.
– Não sobra tempo para melhorar.

17. • Se planejar para a Planning (validar os requisitos).
• Estruturar com o time a Planning dos sonhos!!
– Conceito de Ready
• Metas diárias, ajudam no alinhamento.
– Metas ajudam a atuar na prioridade e dão visibilidade de progresso.
• Conceito de Done = Chave do Sucesso!
• Melhoria Continua
– Gerar ações na retro com data e owner!
• Gestão Visual
– Exponha os problemas, deixe tudo a mostra!

19. • Não existe time.
– Não existe dialogo sobre o projeto.
• Acomodação é geral.
– Se não entregou hoje, entrega amanhã.
• Despersão é a principal característica do time.
• Auto-Desorganização
– Cada um por si!
• A pessoa mais comprometida é a “chata” do projeto.
• Todos se acham os melhores dos melhores!
– Não tenho mais nada para aprender.
– Esse projeto é fácil.

20. • Entrega/Prazo
– Time não se incomoda com os problemas.
– Não se importa se não cumpriu objetivos/metas.
– Erra em todas as estimativas.
– Não sinaliza os blocks que encontra.
• Produtividade
– Desviar as atividades é normal. Estimei 2 horas e faço em 20 horas.
• Qualidade
– A velha máxima de: Na minha máquina funciona!
• Não vê desafios no projeto
– Acomodado com a situação, não consegue mais pensar “fora da caixa”

21. • Trazer a realidade a todos.
– Traçar ações de melhoria.
– Envolver o time em tudo! (Comprometimento nasce aqui)
• Ajustar e descobrir o fluxo de trabalho do time.
• Conceito de Ready e Done
• Testes, Testes e mais Testes!
– Ensinar o time a testar.
– Criar metricas de qualidade.
• Desafiar o time
– Integração Continua, Builds, Teste Automatizados e por ai vai...

22. Time x Cliente/PO

23. • Cliente é contra o agile!
• Só quer saber de quando e quanto.
• Não entende meus problemas e não me ajuda
a resolver.
• Sempre os mesmos blocks.
• Ele não entende, que tem que mudar.

24. Insatisfação e desgaste dos dois lados!

25. Seu cliente não vai mudar por sua
causa. Mas, ele pode aprender
com você.

26. • Demonstre os impactos de forma clara
– Blocks e Atividades não planejadas.
• Compartilhe o planejamento com ele, deixe
ele planejar também.
• Mostre os problemas dele.
• Proponha soluções para os problemas dele.
• Coloque ele dentro do Taxi!

27. Scrum
Master,
doente


28. Scrum Master, doente 
• Acomodado com a situação.
• Resistênte/Cansado em buscar melhorias.
• Tem medo de mostrar a realidade.
• Os problemas não o incomodam mais.
• Se sente incapaz.
• Não acredita no Scrum/Agile!
• Influência negativa ao time.

29. Consequências...
• Entrega/Prazos
– Não entrega ou “entrega” tudo a 90%.
– Datas sempre mudam ao 48 do segundo tempo(Sem gestão de Blocks).
– Cliente insatisfeito e sem confiança.
– Não se sabe o que tem q entregar.
• Qualidade
– Poucos defeitos internos e muitos externos.
– Engenharia de Software fraca.
• Custo
• Time perdido e desmotivado
• Pra que SM?
• Não existe Agile!
• Se torna um influência negativa ao time.

30. Curando o Scrum Master!
• Entender os problemas do SM.
– Entender a causa raiz e buscar resolver em conjunto.
• Demonstre as situações que precisam ser melhoradas.
• Alinhar expectativas
– Feedback deve acontecer on-line
– Acompanhe os passos, fique sempre por perto.
• Problemas devem ser priorizados
• Coloque SM para conversar com SM.
– Trocar experiências e práticas é uma excelente ferramenta.
• Faça o SM se expor, se sentir dono da situação novamente.
• Envolva na resolução de problemas do Projeto.
– Estreite a relação entre Gestores, SM e PO.

31. Cuidado!
Conteúdo apresentado, não é receita
pronta. 

32. Conclusão
Não se acomode aos problemas.

33. Obrigado!
Visite nosso site
www.agilhes.com
info@agilhes.com