SlideShare uma empresa Scribd logo
1 de 33
Baixar para ler offline
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
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 é        #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.
Combatendo o
    Caos!
FALHAR NO
  PLANO É
PLANEJAR A
   FALHA
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.
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.
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.
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
  
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.
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.
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.
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

Mais conteúdo relacionado

Mais procurados

O que a alta administração ainda não entendeu sobre a gestão de projetos
O que a alta administração ainda não entendeu sobre a gestão de projetosO que a alta administração ainda não entendeu sobre a gestão de projetos
O que a alta administração ainda não entendeu sobre a gestão de projetosAndré Choma
 
Amostra 21 erros classicos da gestao de projetos por eli rodrigues
Amostra   21 erros classicos da gestao de projetos por eli rodriguesAmostra   21 erros classicos da gestao de projetos por eli rodrigues
Amostra 21 erros classicos da gestao de projetos por eli rodriguesEli Rodrigues
 
Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...
Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...
Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...Thulio Ultramari
 
Práticas do Extreme Agile
Práticas do Extreme AgilePráticas do Extreme Agile
Práticas do Extreme AgileDairton Bassi
 
Guia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de JaneiroGuia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de JaneiroIdeationBrasil
 
QA Sampa Meeting - Como criar um produto - 2019jul
QA Sampa Meeting - Como criar um produto - 2019julQA Sampa Meeting - Como criar um produto - 2019jul
QA Sampa Meeting - Como criar um produto - 2019julAndressa Chiara
 
Treinamento Scrum - Português
Treinamento Scrum - PortuguêsTreinamento Scrum - Português
Treinamento Scrum - PortuguêsJonas Elias Flesch
 
O que acontece quando limitamos o WIP (Work In Progress)?
O que acontece quando limitamos o WIP (Work In Progress)?O que acontece quando limitamos o WIP (Work In Progress)?
O que acontece quando limitamos o WIP (Work In Progress)?Mary Provinciatto
 
Você está evoluindo seu produto de forma ágil?
Você está evoluindo  seu produto de  forma ágil?Você está evoluindo  seu produto de  forma ágil?
Você está evoluindo seu produto de forma ágil?Mary Provinciatto
 
Testes Ágeis - Quallis
Testes Ágeis - QuallisTestes Ágeis - Quallis
Testes Ágeis - QuallisQuallis
 
Construindo uma cultura de agilidade - O processo de transformação de uma eng...
Construindo uma cultura de agilidade - O processo de transformação de uma eng...Construindo uma cultura de agilidade - O processo de transformação de uma eng...
Construindo uma cultura de agilidade - O processo de transformação de uma eng...André Suman Pereira
 
Novidades ALM Summit 2013
Novidades ALM Summit 2013Novidades ALM Summit 2013
Novidades ALM Summit 2013Lambda 3
 

Mais procurados (19)

MBA em projetos - Gestao Ágil
MBA em projetos - Gestao ÁgilMBA em projetos - Gestao Ágil
MBA em projetos - Gestao Ágil
 
O que a alta administração ainda não entendeu sobre a gestão de projetos
O que a alta administração ainda não entendeu sobre a gestão de projetosO que a alta administração ainda não entendeu sobre a gestão de projetos
O que a alta administração ainda não entendeu sobre a gestão de projetos
 
Teste de software gestao e kaizen
Teste de software gestao e kaizenTeste de software gestao e kaizen
Teste de software gestao e kaizen
 
Scrum trainning
Scrum trainningScrum trainning
Scrum trainning
 
Amostra 21 erros classicos da gestao de projetos por eli rodrigues
Amostra   21 erros classicos da gestao de projetos por eli rodriguesAmostra   21 erros classicos da gestao de projetos por eli rodrigues
Amostra 21 erros classicos da gestao de projetos por eli rodrigues
 
Manage your project portfolio
Manage your project portfolioManage your project portfolio
Manage your project portfolio
 
Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...
Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...
Kanban everywhere! - O uso de Kanban nos níveis estratégico, tático e operaci...
 
Práticas do Extreme Agile
Práticas do Extreme AgilePráticas do Extreme Agile
Práticas do Extreme Agile
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
Guia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de JaneiroGuia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
Guia para a competição Ideation Sua Ideia na Prática - Rio de Janeiro
 
QA Sampa Meeting - Como criar um produto - 2019jul
QA Sampa Meeting - Como criar um produto - 2019julQA Sampa Meeting - Como criar um produto - 2019jul
QA Sampa Meeting - Como criar um produto - 2019jul
 
Treinamento Scrum - Português
Treinamento Scrum - PortuguêsTreinamento Scrum - Português
Treinamento Scrum - Português
 
O que acontece quando limitamos o WIP (Work In Progress)?
O que acontece quando limitamos o WIP (Work In Progress)?O que acontece quando limitamos o WIP (Work In Progress)?
O que acontece quando limitamos o WIP (Work In Progress)?
 
Gestão de projeto- conceitos essenciais
Gestão de projeto- conceitos essenciaisGestão de projeto- conceitos essenciais
Gestão de projeto- conceitos essenciais
 
Você está evoluindo seu produto de forma ágil?
Você está evoluindo  seu produto de  forma ágil?Você está evoluindo  seu produto de  forma ágil?
Você está evoluindo seu produto de forma ágil?
 
Minha história
Minha históriaMinha história
Minha história
 
Testes Ágeis - Quallis
Testes Ágeis - QuallisTestes Ágeis - Quallis
Testes Ágeis - Quallis
 
Construindo uma cultura de agilidade - O processo de transformação de uma eng...
Construindo uma cultura de agilidade - O processo de transformação de uma eng...Construindo uma cultura de agilidade - O processo de transformação de uma eng...
Construindo uma cultura de agilidade - O processo de transformação de uma eng...
 
Novidades ALM Summit 2013
Novidades ALM Summit 2013Novidades ALM Summit 2013
Novidades ALM Summit 2013
 

Semelhante a [AgileTalk] Do Caos ao Resultado

Previsão Orçamentária - Palestra da Supply
Previsão Orçamentária - Palestra da SupplyPrevisão Orçamentária - Palestra da Supply
Previsão Orçamentária - Palestra da SupplyDora Machado Consultoria
 
Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...Avelino Ferreira Gomes Filho
 
Introdução às Metodologias Ágeis de Desenvolvimento
Introdução às Metodologias Ágeis de DesenvolvimentoIntrodução às Metodologias Ágeis de Desenvolvimento
Introdução às Metodologias Ágeis de DesenvolvimentoJerry Medeiros
 
Desenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrumDesenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrumRômulo Gomes
 
Testador Tipo T
Testador Tipo TTestador Tipo T
Testador Tipo TGTS-CE
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumNoaldo Sales
 
O que aprendemos no #AgileBrazil
O que aprendemos no #AgileBrazilO que aprendemos no #AgileBrazil
O que aprendemos no #AgileBrazilRafael Bandeira
 
Scaled Scrum - 9 times contribuindo para um único produto
Scaled Scrum - 9 times contribuindo para um único produtoScaled Scrum - 9 times contribuindo para um único produto
Scaled Scrum - 9 times contribuindo para um único produtoAlberto Caeiro, CSPO, CSM, PMP
 
Como escalamos agilidade em 32 times [TDC Floripa 05/2017]
Como escalamos agilidade em 32 times [TDC Floripa 05/2017]Como escalamos agilidade em 32 times [TDC Floripa 05/2017]
Como escalamos agilidade em 32 times [TDC Floripa 05/2017]Cleiton Luis Mafra
 
Gestao do tempo e organizacao do trabalho
Gestao do tempo e organizacao do trabalhoGestao do tempo e organizacao do trabalho
Gestao do tempo e organizacao do trabalhoINSTITUTO MVC
 
Palestra Procrastinação - Leandro Stok
Palestra Procrastinação - Leandro StokPalestra Procrastinação - Leandro Stok
Palestra Procrastinação - Leandro StokAgile Think® Share
 
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael RochaRafael Rocha
 

Semelhante a [AgileTalk] Do Caos ao Resultado (20)

Visão rápida sobre o SCRUM
Visão rápida sobre o SCRUMVisão rápida sobre o SCRUM
Visão rápida sobre o SCRUM
 
Previsão Orçamentária - Palestra da Supply
Previsão Orçamentária - Palestra da SupplyPrevisão Orçamentária - Palestra da Supply
Previsão Orçamentária - Palestra da Supply
 
Estimar ou #NoEstimates
Estimar ou #NoEstimatesEstimar ou #NoEstimates
Estimar ou #NoEstimates
 
Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...Levando a Agilidade para além do Desenvolvimento de Software na Administração...
Levando a Agilidade para além do Desenvolvimento de Software na Administração...
 
Treinamento - Scrum.pptx
Treinamento - Scrum.pptxTreinamento - Scrum.pptx
Treinamento - Scrum.pptx
 
Não São Apenas Sapatos
Não São Apenas SapatosNão São Apenas Sapatos
Não São Apenas Sapatos
 
Introdução às Metodologias Ágeis de Desenvolvimento
Introdução às Metodologias Ágeis de DesenvolvimentoIntrodução às Metodologias Ágeis de Desenvolvimento
Introdução às Metodologias Ágeis de Desenvolvimento
 
Desenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrumDesenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrum
 
Scrum na Prática
Scrum na PráticaScrum na Prática
Scrum na Prática
 
Testador tipo t
Testador tipo tTestador tipo t
Testador tipo t
 
Testador Tipo T
Testador Tipo TTestador Tipo T
Testador Tipo T
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
O que aprendemos no #AgileBrazil
O que aprendemos no #AgileBrazilO que aprendemos no #AgileBrazil
O que aprendemos no #AgileBrazil
 
Scaled Scrum - 9 times contribuindo para um único produto
Scaled Scrum - 9 times contribuindo para um único produtoScaled Scrum - 9 times contribuindo para um único produto
Scaled Scrum - 9 times contribuindo para um único produto
 
Como escalamos agilidade em 32 times [TDC Floripa 05/2017]
Como escalamos agilidade em 32 times [TDC Floripa 05/2017]Como escalamos agilidade em 32 times [TDC Floripa 05/2017]
Como escalamos agilidade em 32 times [TDC Floripa 05/2017]
 
Gestao do tempo e organizacao do trabalho
Gestao do tempo e organizacao do trabalhoGestao do tempo e organizacao do trabalho
Gestao do tempo e organizacao do trabalho
 
Palestra Procrastinação - Leandro Stok
Palestra Procrastinação - Leandro StokPalestra Procrastinação - Leandro Stok
Palestra Procrastinação - Leandro Stok
 
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
#HubEscola2016 | Gestão ágil de projetos para "não TI" | Rafael Rocha
 
Metodologias ageis
Metodologias ageisMetodologias ageis
Metodologias ageis
 
Enter SCRUM
Enter SCRUMEnter SCRUM
Enter SCRUM
 

[AgileTalk] Do Caos ao Resultado

  • 1.
  • 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!
  • 4.
  • 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!
  • 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.
  • 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!
  • 18.
  • 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...
  • 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!
  • 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