23 / Jun / 2016

Scaled Scrum 9 times, 1 produtoScrum Gathering Rio - 2016 #scaledscrum #sgrio2016

Alberto Augusto Caeiro Júnior, CSPO, CSM, PMP t: @aacaeiro; skype: aacaeirojr

medium.com/@aacaeirojr leantechbusiness.tumblr.com

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 funcionar melhor

✤ Não é uma receita de bolo. A experiência é diretamente influenciada pelas circunstâncias da empresa nesse período

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!”

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

Qual a 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, 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

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

Entre Time & POs

Algumas pessoas não conseguem fazer o shift de mindset

Excelência TécnicaEm 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 AutomatizadoEle te dá confiança e agilidade.

Além de mais qualidade e um processo mais robusto

Alguém precisa olhar o produto completoO 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 Planning * Release Review * SoS Meeting * Weekly Coordination Meeting * Weekly Tickets Followup Meeting

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.

Obrigado

Alberto A Caeiro Júnior

t: @aacaeirojr

linkedin: https://br.linkedin.com/in/albertocaeiro

medium: medium.com/@aacaeirojr

tumblr: leantechbusiness.tumblr.com