[agiletalk] do caos ao resultado
DESCRIPTION
Apresentação do Talk - Do Caos ao Resultado no AgileTalk BH em 16/03TRANSCRIPT
Prazer...
Consultoria na Adoção de Metodos Ágeis Consultoria e Treinamentos, visite nosso site.
www.agilhes.com www.facebook.com/agilhes
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 [email protected]
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
#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.
• 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
• 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...
• 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.
• 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!
• 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!