Kanban:
Agilidade para ambientes conservadores
Conservadores
Cynefin
/ k n v n/ˈ ʌ ɨ ɪ
”habitat”
Quais são as
constraints do Scrum
quando fazemos uma
“expedição” na
Complexidade?
(container)
Quais são as
constraints do Scrum
quando fazemos uma
“expedição” na
Complexidade?
- Tempo do Sprint
- Sprint Backlog
- Definição de Pronto
Vermelho:
Dinâmica de uma empresa
que começou com Scrum
mas não “curtia Emergência”
Azul:
Dinâmica de uma empresa
que saiu do caos com Kanban
e entrou em complacência.
Verde:
O que o Scrum/Kanban
realmente deveria fazer.
Amarelo:
“Mergulhinho no Caos...”
Cynefin
Como usar
esse insight?
Cynefin
Kanban
pode te
ajudar...
Questionar crenças que
parecem óbvias, evitando
“cair sem querer” no caos.
(crise)
Questionar crenças que
parecem óbvias, evitando
“cair sem querer” no caos.
(crise)
Cynefin
Dar segurança
para permitir
experimentos no
domínio complexo.
Dar segurança
para permitir
experimentos no
domínio complexo.
Kanban
pode te
ajudar...
Exemplo
Nos anos 90 o Tonhão me
pedia um relatório por dia...
Até que um dia nasceu um “projeto”...
Até que fluiu bem...
Treta: uma demanda demorou demais ...
Mais treta: erramos na modelagem do banco …
(2-3 dias de perrengue)
Treta 3.0: Tonhão saiu de férias, novos requisitos...
Módulo 1 entregue após 54 dias
Módulo 2 entregue após 58 dias
(estouro de quase 100%)
Se perguntar pro
Tonhão por que atrasou
qual seria sua resposta?
Se perguntar pro
Tonhão por que atrasou
qual será sua resposta?
- Você enrolou com aquela demanda...
- Você gerou retrabalho!
- Demorou tanto que saí de férias!
Japonês burro...
O que você faria?
ManagementSchool
A pergunta “Por que atrasou?”
está em qual domínio do Cynefin?
Ache os 4 pontos de alavancagem deste CFD...
1. Demora na Homologação
2. Retrabalho por falta de feedback
3. Férias do Tonhão
4. Entrega em Módulos
Isso é análise! Domínio: COMPLICADO
Modelos utilizados:
- Teoria das Restrições
- Lei de Little
- Teoria das Filas
- Batch Sizing (TPS)
Modelos utilizados:
- Teoria das Restrições
- Lei de Little
- Teoria das Filas
- Batch Sizing (TPS)
Resultados de se trabalhar com lotes menores...
- Tonhão, vamos fazer planejamentos
por módulo e homologar por
demanda no próximo projeto?
Isso é a abordagem
evolucionária do Kanban!
Melhorar QUALQUER ambiente
sem grandes mudanças radicais. Mexer pouco,
mas mexer bem. Lidar com a resistência natural
das pessoas à mudanças.
Cliente da Administração Pública...
Rodrigo, você precisa vir aqui
porque o desenvolvimento
é gargalo...
...o desenvolvimento
é gargalo...
Não flui no desenvolvimento...
Desenvolvedores são
lerdos...
O Cumulative Flow deles de 12 meses
antes da consultoria começar...
O Cumulative Flow deles de 12 meses
antes da consultoria começar...
Na verdade:
Gargalo em Homologação!
Princípios Ubíquos
(Coisas que estão presentes em todos os processos)
Fluxo
(Cumulative Flow Diagram, Lead Time, WIP, Qualidade da Demanda)
Framework Econômico
(Custo do Atraso, Custo de Coordenação, Custo de Transação)
Casos de Uso
Todo sistema é usado por algum agente externo
Testes
Se você não testar o cliente vai testar em Produção
Capacidade
Revolução
“Kaikaku”
(implantação “Big Bang” de processos)
Tempo
Evolução
“Kaizen”
(mudar aos poucos o processo existente)
Status Quo
Novo Status Quo
Explicando Mudanças Evolucionárias
de forma didática
Capacidade
Revolução
“Kaikaku”
Tempo
Status Quo
Meta Antiga
Na vida real:
Problema comum 1: “Eroding Goals”
Evolução
“Kaizen”
Capacidade
“Já somos ágeis”
(aka rodamos Sprints)
Tempo
Status Quo
Causas comuns...
“Já tá previsível”
Capacidade
Não mudam porque
da última vez “doeu”
Tempo
Status Quo
Cenário de Equipes que resistem
em melhorar práticas técnicas
Não mudam por terem alcançado
bons resultados rápidos
Capacidade
Caíram
no penhasco
(óbvio → chaos)
Tempo
Status Quo
Percebem a
perda de capacidade
J-Curve of Change na vida real...
(no longo prazo equipes evoluindo se saem melhor)
Adaptação
Exaptação
O melhor remédio para agilistas
conservadores é um rolê no Complexo.
Cliente de E-Commerce
(manutenção e novas funcionalidades)
1. Precisamos Previsibilidade
e nosso planning é dispendioso
12-15 pessoas numa sala por 4 horas
2 horas de Planning Poker torra o saco
“nunca cumprimos a Sprint”
2. Temos que lidar com urgências!
O negócio deles era dinâmico
Surgiam novas necessidades dentro da Sprint
Por isso o planning estava desacreditado
1. Adotaram quadro com limites
2. Métricas Kanban
3. Planning sob demanda
4. Abandonaram Planning Poker
5. Delivery sob demanda
5 semanas depois...
Demandas Urgentes:
4 dias com 90% de confiança
Demandas Normais:
14 dias com 90% de confiança
Fluxo Melhorado
Melhor Qualidade
Lead Time
Lidar com a Complexidade
Coloque “Enabling Constraints”
Identifique “Attractors”
Entenda que a inovação vem de
experimentos onde é seguro falhar
Kanban habilitando rolês no Complexo:
(Freedom Lane) reservando capacidade para inovação
Raia onde a equipe pode fazer qualquer trabalho que quiser
Não tem workflow na “Freedom Lane”
Mindset #1: Cultive Insatisfações
DOR É UM MOTIVADOR MAIOR QUE OS
BENEFICIOS DE UMA SUPOSTA SOLUÇÃO
Mindset #2: Adote uma abordagem
evolucionária para mudanças
MODELE O SISTEMA DE TRABALHO DE FORMA QUE ELE
SEJA AJUSTADO AO PROPÓSITO DA ORGANIZAÇÂO
Mindset #3: Gestão é um hard-skill
Gestão não tem um
único “botão”...
Quer saber mais sobre
Gestão Moderna de Software além do Agile?
Acessem: http://bit.ly/softzenhttp://bit.ly/softzen
Atenção: Vídeos disponíveis só até 21/8
Eu aprendi Kanban
com esse cara...
Obrigado!!!
Mais conteúdo e um desafio:
http://bit.ly/sgrio2015http://bit.ly/sgrio2015

Kanban: agilidade para ambientes conservadores

  • 1.
  • 2.
  • 3.
    Cynefin / k nv n/ˈ ʌ ɨ ɪ ”habitat”
  • 7.
    Quais são as constraintsdo Scrum quando fazemos uma “expedição” na Complexidade? (container)
  • 8.
    Quais são as constraintsdo Scrum quando fazemos uma “expedição” na Complexidade? - Tempo do Sprint - Sprint Backlog - Definição de Pronto
  • 10.
    Vermelho: Dinâmica de umaempresa que começou com Scrum mas não “curtia Emergência” Azul: Dinâmica de uma empresa que saiu do caos com Kanban e entrou em complacência. Verde: O que o Scrum/Kanban realmente deveria fazer. Amarelo: “Mergulhinho no Caos...”
  • 11.
  • 12.
    Cynefin Kanban pode te ajudar... Questionar crençasque parecem óbvias, evitando “cair sem querer” no caos. (crise) Questionar crenças que parecem óbvias, evitando “cair sem querer” no caos. (crise)
  • 13.
    Cynefin Dar segurança para permitir experimentosno domínio complexo. Dar segurança para permitir experimentos no domínio complexo. Kanban pode te ajudar...
  • 14.
    Exemplo Nos anos 90o Tonhão me pedia um relatório por dia...
  • 15.
    Até que umdia nasceu um “projeto”...
  • 16.
  • 17.
    Treta: uma demandademorou demais ...
  • 18.
    Mais treta: erramosna modelagem do banco … (2-3 dias de perrengue)
  • 19.
    Treta 3.0: Tonhãosaiu de férias, novos requisitos...
  • 20.
    Módulo 1 entregueapós 54 dias Módulo 2 entregue após 58 dias (estouro de quase 100%)
  • 21.
    Se perguntar pro Tonhãopor que atrasou qual seria sua resposta?
  • 22.
    Se perguntar pro Tonhãopor que atrasou qual será sua resposta? - Você enrolou com aquela demanda... - Você gerou retrabalho! - Demorou tanto que saí de férias! Japonês burro...
  • 23.
  • 24.
  • 25.
    A pergunta “Porque atrasou?” está em qual domínio do Cynefin?
  • 26.
    Ache os 4pontos de alavancagem deste CFD...
  • 27.
    1. Demora naHomologação 2. Retrabalho por falta de feedback 3. Férias do Tonhão 4. Entrega em Módulos
  • 28.
    Isso é análise!Domínio: COMPLICADO Modelos utilizados: - Teoria das Restrições - Lei de Little - Teoria das Filas - Batch Sizing (TPS) Modelos utilizados: - Teoria das Restrições - Lei de Little - Teoria das Filas - Batch Sizing (TPS)
  • 29.
    Resultados de setrabalhar com lotes menores...
  • 30.
    - Tonhão, vamosfazer planejamentos por módulo e homologar por demanda no próximo projeto?
  • 31.
    Isso é aabordagem evolucionária do Kanban! Melhorar QUALQUER ambiente sem grandes mudanças radicais. Mexer pouco, mas mexer bem. Lidar com a resistência natural das pessoas à mudanças.
  • 32.
    Cliente da AdministraçãoPública... Rodrigo, você precisa vir aqui porque o desenvolvimento é gargalo... ...o desenvolvimento é gargalo... Não flui no desenvolvimento... Desenvolvedores são lerdos...
  • 33.
    O Cumulative Flowdeles de 12 meses antes da consultoria começar...
  • 34.
    O Cumulative Flowdeles de 12 meses antes da consultoria começar... Na verdade: Gargalo em Homologação!
  • 35.
    Princípios Ubíquos (Coisas queestão presentes em todos os processos) Fluxo (Cumulative Flow Diagram, Lead Time, WIP, Qualidade da Demanda) Framework Econômico (Custo do Atraso, Custo de Coordenação, Custo de Transação) Casos de Uso Todo sistema é usado por algum agente externo Testes Se você não testar o cliente vai testar em Produção
  • 36.
    Capacidade Revolução “Kaikaku” (implantação “Big Bang”de processos) Tempo Evolução “Kaizen” (mudar aos poucos o processo existente) Status Quo Novo Status Quo Explicando Mudanças Evolucionárias de forma didática
  • 37.
    Capacidade Revolução “Kaikaku” Tempo Status Quo Meta Antiga Navida real: Problema comum 1: “Eroding Goals” Evolução “Kaizen”
  • 38.
    Capacidade “Já somos ágeis” (akarodamos Sprints) Tempo Status Quo Causas comuns... “Já tá previsível”
  • 39.
    Capacidade Não mudam porque daúltima vez “doeu” Tempo Status Quo Cenário de Equipes que resistem em melhorar práticas técnicas Não mudam por terem alcançado bons resultados rápidos
  • 40.
    Capacidade Caíram no penhasco (óbvio →chaos) Tempo Status Quo Percebem a perda de capacidade J-Curve of Change na vida real... (no longo prazo equipes evoluindo se saem melhor)
  • 41.
  • 42.
    O melhor remédiopara agilistas conservadores é um rolê no Complexo. Cliente de E-Commerce (manutenção e novas funcionalidades) 1. Precisamos Previsibilidade e nosso planning é dispendioso 12-15 pessoas numa sala por 4 horas 2 horas de Planning Poker torra o saco “nunca cumprimos a Sprint” 2. Temos que lidar com urgências! O negócio deles era dinâmico Surgiam novas necessidades dentro da Sprint Por isso o planning estava desacreditado
  • 44.
    1. Adotaram quadrocom limites 2. Métricas Kanban
  • 45.
    3. Planning sobdemanda 4. Abandonaram Planning Poker 5. Delivery sob demanda
  • 46.
    5 semanas depois... DemandasUrgentes: 4 dias com 90% de confiança Demandas Normais: 14 dias com 90% de confiança Fluxo Melhorado Melhor Qualidade Lead Time
  • 47.
    Lidar com aComplexidade Coloque “Enabling Constraints” Identifique “Attractors” Entenda que a inovação vem de experimentos onde é seguro falhar
  • 48.
    Kanban habilitando rolêsno Complexo: (Freedom Lane) reservando capacidade para inovação Raia onde a equipe pode fazer qualquer trabalho que quiser Não tem workflow na “Freedom Lane”
  • 49.
    Mindset #1: CultiveInsatisfações DOR É UM MOTIVADOR MAIOR QUE OS BENEFICIOS DE UMA SUPOSTA SOLUÇÃO Mindset #2: Adote uma abordagem evolucionária para mudanças MODELE O SISTEMA DE TRABALHO DE FORMA QUE ELE SEJA AJUSTADO AO PROPÓSITO DA ORGANIZAÇÂO
  • 50.
    Mindset #3: Gestãoé um hard-skill Gestão não tem um único “botão”...
  • 51.
    Quer saber maissobre Gestão Moderna de Software além do Agile? Acessem: http://bit.ly/softzenhttp://bit.ly/softzen Atenção: Vídeos disponíveis só até 21/8 Eu aprendi Kanban com esse cara...
  • 52.
    Obrigado!!! Mais conteúdo eum desafio: http://bit.ly/sgrio2015http://bit.ly/sgrio2015