Série: Transição de Kanban para Scrum | Parte 2 de 4 | Documentando a evolução estruturada do nosso time de Kanban para Scrum
Criando a Base para a Mudança
Depois de percebermos que nosso processo atual não estava servindo nossos objetivos, o próximo passo não foi “implementar Scrum” — foi construir entendimento comum. Mudança não se sustenta sem significado. Então abrimos um quadro no FigJam, reservamos tempo, e perguntamos: Por que queremos mudar para Scrum?
Começamos ancorando a conversa nos objetivos do time: autonomia, transparência, rotina e eficiência. Cada um desses emergiu de feedbacks reais, não de livros. Não queríamos Scrum porque é moda. Queríamos porque acreditávamos que poderia resolver nossos problemas reais.
Como Saberemos que Está Funcionando?
Não paramos nos objetivos. Perguntamos: Como saberemos que estamos chegando lá? Isso nos levou a criar indicadores visíveis e concretos:
- Um único ponto de contato diário.
- Transparência no escopo e bloqueios.
- Épicos progredindo a cada sprint.
- Sprint reviews que fecham o ciclo de feedback.
Esses não eram indicadores para prestação de contas para fora. Eram para nós. Eram a evidência de que o sistema estava melhorando e apoiando nossa forma de trabalhar.
Valores e Pilares do Scrum
Também não assumimos que todo mundo conhecia Scrum. Durante a sessão, perguntamos a cada pessoa: Quais são os pilares do Scrum? Com quais valores você se conecta mais?
Falamos sobre Transparência, Inspeção e Adaptação — não como teoria, mas como comportamentos. Depois, exploramos os valores: Comprometimento, Foco, Abertura, Respeito e Coragem. E perguntamos: Qual valor mais fala com você, e por quê?
Essa conversa, por si só, mudou o tom da transição. Trocamos a mentalidade de adesão pela de convicção. Scrum deixou de ser algo que aplicaríamos no time e virou algo que estávamos escolhendo como time.
Co-criando Definition of Ready e Definition of Done
Outra sessão importante foi a construção coletiva do nosso Definition of Ready (DoR) e Definition of Done (DoD). Em muitos times isso é imposto — nós fizemos o oposto.
Usando FigJam, mapeamos o que nós precisamos para começar uma tarefa com segurança: contexto claro, critérios de aceite, link de design, dependências mapeadas. Isso virou nosso DoR.
Depois, fizemos o mesmo para o DoD: logs criados, traduções revisadas, dashboards atualizados, testado em staging, revisado pelo PO, e implantado em produção.
Visualizar isso junto tornou a responsabilidade coletiva — e deu mais confiança aos engenheiros para puxar stories.
Desenhando Nossos Rituais de Scrum
Na mesma sessão, mapeamos como seriam nossas cerimônias Scrum. Não apenas o que o guia diz, mas como nós gostaríamos de fazer: Planning, Review, Retro, Refinamento. Quem facilita? Quem é dono? Qual o objetivo?
Não estávamos mais apenas trocando métodos. Estávamos desenhando uma nova forma de trabalhar — juntos.
E na Parte 3, conto como isso virou prática com o time assumindo, aos poucos, a facilitação de todas as cerimônias.
# Acordo de time criado nessa sessão
echo "As cerimônias Scrum são de responsabilidade do time e facilitadas em rodízio." >> acordos-time.txt
Anterior na série: Parte 1 - Reconhecendo a Necessidade de Mudança
Próximo na série: Parte 3 - Desenvolvendo Engenheiros para Liderar o Processo
Série Transição de Kanban para Scrum:
- Parte 1: Reconhecendo a Necessidade de Mudança (27 out, 2022)
- Parte 2: Alinhando Metas, Métricas e Entendimento Compartilhado (Este post)
- Parte 3: Desenvolvendo Engenheiros para Liderar o Processo (10 nov, 2022)
- Parte 4: Lições Aprendidas e Melhoria Contínua (17 nov, 2022)