Prazer...

Consultoria na Adoção de Metodos Ágeis Consultoria e Treinamentos, visite nosso site.

www.agilhes.com www.facebook.com/agilhes

info@agilhes.com

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

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!

• 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.

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!

Principais

sintomas do

Caos

Principais Sintomas do Caos

#01 - Qualidade é

“excelente”, só que o

cliente homologa

cenários não previstos!

#02 - Produtividade é

“boa”, só não é melhor

porque não temos os

requisitos Ready.

#03 - Esse cliente é

complexo! Não

entende que ele tem

que mudar.

#04 - Seguimos o

Scrum, mas não temos

Demo Review.

Esconder os problemas é o maior sintoma do Caos. Temos que ser cuidadosos, para não entrar em uma zona de

conforto.

Combatendo o

Caos!

FALHAR NO

PLANO É

PLANEJAR 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.

Planejando a Falha

• 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.

Consequências...

• 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.

Evitando problemas no plano

Ritos?

Pra

que

fazer

Daily?

• 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?

• 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.

• 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!

• 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.

• 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”

• 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...

Time x Cliente/PO

• 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.

Insatisfação e desgaste dos dois lados!

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

com você.

• 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!

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.

Scrum Master, doente

• 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.

Consequências...

• 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.

Curando o Scrum Master!

Cuidado!

Conteúdo apresentado, não é receita pronta.

Conclusão

Não se acomode aos problemas.

Obrigado!

Visite nosso site

www.agilhes.com info@agilhes.com