O documento discute as experiências de um especialista em escalar Scrum para 9 times trabalhando em um único produto. Ele destaca os desafios técnicos e culturais enfrentados, como código legado, falta de testes e alinhamento entre times. O especialista propõe foco em objetivos compartilhados, métricas, colaboração, excelência técnica e novas cerimônias para melhorar o processo à medida que o produto e número de times crescem.

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. 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. 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. 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. Qual o caminho?
...e o que aprendemos ao longo do processo…

6. OKRs
- Quais são os objetivos?
- Como vamos saber se estamos chegando lá?
- O sucesso se parece com o que?

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. As vezes você
precisa
ir contra o senso
comum,
SE você sabe os
trade-offs
que você está
comprando

9. Problemas também
são potencializados
- Backlog
- Cultura de Produto
- Cultura e mindset de agilidade
- Dívidas técnicas

10. Métricas: sem elas, você fica às cegas
In God we trust, all others bring data
unknown Author

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. 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. Alguém precisa olhar o produto completo
O produto está evoluindo na direção certa?

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. 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. Obrigado
Alberto A Caeiro Júnior
t: @aacaeirojr
linkedin: https://br.linkedin.com/in/albertocaeiro
medium: medium.com/@aacaeirojr
tumblr: leantechbusiness.tumblr.com