Scrum Kick Off: como dar o melhor pontapé inicial no seu projeto

Faz um bom tempo que não publico aqui no Agile Momentum, pois estava focado em outros projetos. Mas, aqui estou de volta! E comemorando o novo logo do blog, voltado para uma nova fase de postagens que aparecerão por aqui em breve.  Até lá, dá uma olhada lá em cima da página e diz o que achou da nossa nova identidade. 🙂

Bem… Estamos iniciando alguns projetos aqui na empresa e alguns times me procuraram com um questionamento bem bacana:

Como podemos fazer um kick off de um projeto Scrum que seja eficiente e que nos dê todas as informações pra que iniciemos o trabalho de forma tranquila?

Eu acredito muito em alinhamentos e contratos de trabalho. É como diz o velho ditado: o combinado não sai caro! Se você alinhar as expectativas entre Time e Stakeholders, é bastante provável que o teu projeto corra mais macio.

O kick off é, sim, uma cerimônia de alinhamento que pode nos fornecer as respostas que precisamos. Mas o que nos garante que vamos ter uma cerimônia produtiva e que vamos sair dela com a maioria das respostas que precisamos?

Nunca tinha pensado num formato padronizado ou organizado para essa finalidade, confesso! mas, a partir desse momento em que algumas pessoas me fizeram mais o menos o mesmo questionamento, fiquei matutando sobre a necessidade de um guia de práticas de um bom kick off.

Scrum Setup Canvas

Foi aí que eu cheguei no Scrum Setup Canvas, do amigo Jorge Audy, uma ferramenta visual (adoro!) muito bacana para balizar o Time Scrum em seus primeiros passos no projeto.

O canvas “passeia” por algumas sessões bastante interessantes, mas (sorry, Audy) eu usei ligeiramente diferente do formato original proposto:

Elevator Statement

Manja o Elevator Pitch? É mais ou menos a mesma coisa: uma frase curta, de conhecimento de todos os envolvidos e que explique, em linhas gerais, o que é o projeto. Se conseguir dizer quais são os ganhos esperados, maravilha!! Geramos comprometimento desde cedo!

Equipe e Envolvidos

Quem são as pessoas diretamente envolvidas? Mais que uma lista simples, esta é uma lista de contatos, com informações importantes para que ninguém fique desatualizado. Aqui é bem importante deixar claro quem faz parte do time interno e quem é Cliente (no nosso caso, onde trabalhamos como fornecedor).

Aproveitamento – Sprints – Dias – Horas Úteis

Este já foi um ponto bem polêmico nos meus projetos e acho sensacional ter um acordo de trabalho previamente combinado. Além de definir o formato das Sprints, o que precisa ser definido é o período útil do time (tempo de desenvolvimento). Ou vai me dizer que nunca te perguntaram, numa bela tarde de verão se as plannings, refinamentos, reviews e retrospectivas contam no tempo de Sprint e no Capacity do time? Construa sua Sprint Ideal.

Arquitetura & Integrações

Não raro temos que falar com algum outro sistema. Fatalmente o time precisa definir questões de arquitetura da solução, a menos que você seja abençoado (ou não) por um projeto envolvendo sistema legado. Mesmo assim, algumas decisões deverão ser tomadas e acordadas com os stakeholders. Por favor, evitem conversas desagradáveis envolvendo a frase “mas como assim vocês não sabiam que estamos refatorando o código legado à medida que evoluímos no projeto?”

Indicadores & Métricas

Product Owners e Gestores piram nesse item! Brincadeiras à parte, pra você saber se está chegando em algum lugar (e se está chegando bem) você precisa medir! O melhor momento para mostrar o que e como medir e como interpretar os números é no início do projeto. E não quando está tudo “dando ruim”.

Boas Práticas e Ferramentas

Existem práticas que o time decidiu usar? Quais são elas e quais ferramentas vocês precisam para utilizá-las?

DoR

O que o Time Scrum considera um item aceitável e pronto para iniciar o desenvolvimento? Serão utilizadas histórias de usuário? O que se espera destas histórias, de uma maneira geral?

DoD

Da mesma forma que você se protege de requisitos mal escritos, o Product Owner precisa se proteger de requisitos mal implementados. Simples e justo assim! O que o Product Owner considera como requisitos básicos e genéricos para aceitar um item?

Feriados – Férias – Eventos – Ausências

Geralmente no mês de outubro de todos os anos já é possível acessar o calendário de feriados bancários no site da Febraban (suficiente para montar o calendário de datas não úteis do projeto). Da mesma forma, existem alguns eventos que sabemos que não estaremos disponíveis: férias, casamento, e, até mesmo, algumas folgas, eventos e cursos que participaremos. Este é um acordo que deve ser revisitado em todos os planejamentos.  Sempre.

Sprint “Zero” ou Pre Game

Eu prefiro o termo Pre Game para definir o tempo necessário que o Product Owner precisa para escrever os requisitos (dentro da DoR) e que o Time Scrum precisa para fazer o setup/organização técnica do projeto. Afinal, quantos projetos que você participou em que a primeira Sprint foi uma Sprint de Setup e a Review foi uma constrangedora apresentação técnica de esqueleto de solução para um time de negócio?

Reserva Técnica

É fato que seu time não vai trabalhar 100% do tempo focada em implementar os requisitos do projeto? Por favor, separe um bolsão de capacidade para estes trabalhos, que poderão envolver manutenções, atendimentos e possíveis alocações externas. Não estou dizendo que você precisa separar uma quantidade de horas para essas atividades e abrir um precedente para o microgerenciamento. Mas você precisa mostrar para o seu Time Scrum que ele, talvez, não poderá pensar em dias ideiais quando estiverem fazendo o planejamento.

Scrum Kick Off Planner

Por mais bacana que o Scrum Setup Canvas seja, senti falta de algo ainda mais estruturado para guiar o kick off do projeto. Pesquisei um pouco e encontrei o Scrum Kick Off Planner, do Adam Weisbart.

Esta ferramenta é como um template para muitos dos pontos do Setup Canvas e detalhando alguns outros.

Não é minha intenção aqui descrever o Planner. Na verdade, eu não o usei. Mas depois da sua leitura e análise, ele me ajudou a formular questões que poderão ser usadas para apoiar o kick off, nos dando as informações que queremos.

• Como será a comunicação remota? (no nosso caso ela será bastante usada)
• Há um horário esperado para interação?
• Quem é o Product Owner? Qual a sua disponibilidade?
• O Product Owner quer/será envolvido no dia a dia do projeto? Como?
• Qual o tamanho das Sprints?
  • Fixar a agenda de cerimônias
  • Definir o período produtivo de uma Sprint Ideal (sem férias, feriados ou folgas)
• Como serão as Reviews?
• Deverão acontecer refinamentos? Quando e como?
• Como as estimativas serão feitas?
• Quanto tempo precisamos para organizar o time e fazer o primeiro planejamento?

Comece Simples

Você pode tomar essa lista como base. Mas recomendo que você vá adequando à sua realidade. Sempre revisite esta lista a cada projeto, para que os próximos comecem cada vez mais alinhados.

Como eu disse anteriormente, o combinado não sai caro! Nem causa dores de cabeça!

Sucesso e até a próxima!

Publicidade