23 / Jun / 2016
Scaled Scrum
9 times, 1 produto
Scrum Gathering Rio - 2016
#scaledscrum #sgrio2016
Alberto Augusto Caeiro ...
Disclaimer
✤ O que vamos falar aqui é a minha experiência em trabalhar com
Scrum, em um ambiente com muitos times contribu...
Cenários - Pros
✤ Produto bem conceituado no mercado (com vários prêmios internacionais e bem
colocado nos quadrantes do G...
Cenário - Issues
✤ Técnicos
✤ Produto “acoplado”
✤ Código extenso (~ 3M LoC) e
“legado" (~7 anos de código),
✤ Mix de tecn...
Qual o caminho?
...e o que aprendemos ao longo do processo…
OKRs
- Quais são os objetivos?
- Como vamos saber se estamos chegando lá?
- O sucesso se parece com o que?
Pessoas, inspeção e adaptação
Sua estrutura deveria 

ajudar a resolver os problemas.
Se você não pode mudar os
problemas,...
As vezes você
precisa
ir contra o senso
comum,
SE você sabe os
trade-offs
que você está
comprando
Problemas também
são potencializados
- Backlog
- Cultura de Produto
- Cultura e mindset de agilidade
- Dívidas técnicas
Métricas: sem elas, você fica às cegas
In God we trust, all others bring data
unknown Author
Colaboração entre os times
é caminho crítico de sucesso
Mudança de cultura é
difícil e leva tempo
Entre Times
Entre POs
En...
Excelência Técnica
Em um cenário de múltiplos times,
a dívida técnica cresce bem mais
rápido. Em pouco tempo ela
se torna ...
Alguém precisa olhar o produto completo
O produto está evoluindo na direção certa?
Você precisa de
novas cerimônias
Onde as metodologias
mais ajudam (SAFe, LeSS, Nexus)
* OKR Planning Sessions
* Release Pl...
Concluindo
✤ Não existe muito receita de
bolo
✤ Com o mindset ágil correto, o
resto você consegue ir
acertando
✤ Saber ond...
Obrigado
Alberto A Caeiro Júnior
t: @aacaeirojr
linkedin: https://br.linkedin.com/in/albertocaeiro
medium: medium.com/@aac...
Próximos SlideShares
Carregando em…5
×

Scaled Scrum - 9 times contribuindo para um único produto

118 visualizações

Publicada em

Quais as experiências e aprendizados tivemos ao longo do processo de gerenciar múltiplos times scrum, contribuindo para um único produto.

Publicada em: Tecnologia
2 comentários
1 gostou
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
118
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
0
Comentários
2
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Scaled Scrum - 9 times contribuindo para um único produto

  1. 1. 23 / Jun / 2016 Scaled Scrum 9 times, 1 produto Scrum Gathering Rio - 2016 #scaledscrum #sgrio2016 Alberto Augusto Caeiro Júnior, CSPO, CSM, PMP t: @aacaeiro; skype: aacaeirojr medium.com/@aacaeirojr leantechbusiness.tumblr.com
  2. 2. Disclaimer ✤ O que vamos falar aqui é a minha experiência em trabalhar com Scrum, em um ambiente com muitos times contribuindo para um único produto ✤ Ao longo da apresentação vou comentar algumas coisas que eu acho que funcionavam bem e outras que eu tentei mudar para funcionarem melhor ✤ Não é uma receita de bolo. A experiência é diretamente influenciada pelas circunstâncias da empresa nesse período
  3. 3. Cenários - Pros ✤ Produto bem conceituado no mercado (com vários prêmios internacionais e bem colocado nos quadrantes do Gartner) ✤ Múltiplos times contribuindo para um único produto ✤ Scrum, no que tange cerimônias e artefatos já institucionalizadas ✤ Time tecnicamente competente ✤ Bastante autonomia para mudar e testar coisas novas ✤ Contanto que não impactasse as entregas ✤ Tanto a Engenharia quanto Produto dispostos a fazer algumas experiências para melhorar o processo ✤ Atitude: “Yes we can!”
  4. 4. Cenário - Issues ✤ Técnicos ✤ Produto “acoplado” ✤ Código extenso (~ 3M LoC) e “legado" (~7 anos de código), ✤ Mix de tecnologias & frameworks ✤ Pouca cobertura de testes, e pouquíssima automatização ✤ Muitas reclamações sobre a qualidade do produto (principalmente US) ✤ Muitos problemas onde ao consertar uma coisa, se quebra outra ✤ Produto ✤ Cliente principal Governo / RFP ✤ Processo ✤ Release: 3 meses, Sprint : 2 semanas ✤ 1 Sprint de “testes” manuais ✤ Time com prioridades conflitantes (tickets, stories, dívidas, e bugs) ✤ Cultura & Alinhamento ✤ Baixo alinhamento entre produto vs engenharia ✤ “A culpa é do PO” / “A culpa é do time” ✤ Relacionamento entre áreas ruim
  5. 5. Qual o caminho? ...e o que aprendemos ao longo do processo…
  6. 6. OKRs - Quais são os objetivos? - Como vamos saber se estamos chegando lá? - O sucesso se parece com o que?
  7. 7. Pessoas, inspeção e adaptação Sua estrutura deveria 
 ajudar a resolver os problemas. Se você não pode mudar os problemas, mude a estrutura A estrutura externa que interage com o time é tão importance quanto a estrutura do time O skill set das pessoas é fundamental na montagem dos times Com múltiplos times, você precisa tomar mais cuidado com as políticas e procedimentos comuns Suporte? Serviços? Clientes? Divide responsibility and nobody is responsible. Edwards Deming
  8. 8. As vezes você precisa ir contra o senso comum, SE você sabe os trade-offs que você está comprando
  9. 9. Problemas também são potencializados - Backlog - Cultura de Produto - Cultura e mindset de agilidade - Dívidas técnicas
  10. 10. Métricas: sem elas, você fica às cegas In God we trust, all others bring data unknown Author
  11. 11. Colaboração entre os times é caminho crítico de sucesso Mudança de cultura é difícil e leva tempo Entre Times Entre POs Entre Time & POs Algumas pessoas não conseguem fazer o shift de mindset
  12. 12. Excelência Técnica Em um cenário de múltiplos times, a dívida técnica cresce bem mais rápido. Em pouco tempo ela se torna quase que impagável! Muitas vezes você toma um atalho que pode incorrer em problemas para outros times Teste Automatizado Ele te dá confiança e agilidade. Além de mais qualidade e um processo mais robusto
  13. 13. Alguém precisa olhar o produto completo O produto está evoluindo na direção certa?
  14. 14. Você precisa de novas cerimônias Onde as metodologias mais ajudam (SAFe, LeSS, Nexus) * OKR Planning Sessions * Release Planning * Release Review * SoS Meeting * Weekly Coordination Meeting * Weekly Tickets Followup Meeting
  15. 15. Concluindo ✤ Não existe muito receita de bolo ✤ Com o mindset ágil correto, o resto você consegue ir acertando ✤ Saber onde você quer chegar é o primeiro passo para alcançar o sucesso ✤ Usar os frameworks de mercado não é garantia de sucesso.
  16. 16. Obrigado Alberto A Caeiro Júnior t: @aacaeirojr linkedin: https://br.linkedin.com/in/albertocaeiro medium: medium.com/@aacaeirojr tumblr: leantechbusiness.tumblr.com

×