Inspire-se, pois planning fácil e burocrático é mal sinal

Reunião de planejamento (Sprint Planning) é oportunidade de alinhamento de valor, combate ao desperdício, um momento importante para o time e para o projeto, se ela for quadradinha, sem uma pitada de sal ou pimenta, sem debates e dúvidas, é sinal que algo está errado, ou o sprint está folgadaço, a equipe esta intimidada, esqueceram o que é Agile, … alerte a galera e tentem descobrir.

Se você não conhece bem o que é Sprint Planning <clique aqui> e se ainda não leu sobre Discovery-Delivery <clique aqui>, pois não reeditarei aqui todos os conceitos e fundamentos de planejamento do Scrum, os mesmos são relevantes para iniciantes e estão bem detalhados nos posts acima sugeridos, aqui vou dar um passo além baseado em nossa prática.

Um detalhe importante dentro de nossa experiência é de que TODO o time está convidado a participar de TODO o planning, não consideramos desperdício ou arriscado que o Product Owner, o designer (UX) e SEO estejam junto durante todo o planning, consideramos isto um investimento de todos para o maior entendimento possível e eliminação de todo e qualquer pressuposto, mesmo que por pouco tempo, passível de ser elucidado na mesma hora.

sprint-planning

Scrum Guide – Sugestão de um planning com tempo proporcional ao tamanho da Sprint, de forma que uma iteração de duas semanas necessitaria uma reunião para planejamento de 4Horas, splitada em 2Horas de apresentação pelo Product Owner para entendimento do que seriam as User Stories selecionadas para este Sprint, seguido de 2Horas de debate e desdobramentos para as estimativa por parte da equipe e confirmação do Sprint Backlog, gerando um pacto.

Desconforto – Com frequência temos plannings com histórias para as quais a equipe não se sente confortável para estimar, quer pelo ineditismo ou inovação, no início seguiamos uma abordagem de que algumas histórias tinham um tempo estimado para análise até uma posterior estimativa de construção, mas inevitavelmente isso incomodava a maioria, pois saíamos do planning com algumas ou muitas incógnitas.

Alternativas – É claro que um maior envolvimento de um ou mais integrantes da equipe durante a fase de Discovery é a melhor solução, mas com frequência isso não tem sido possível, já tentamos alternativas perigosas como abrir um ou mais dias entre o fim de uma Sprint e o começo da outra, no meu ver puro desperdício, mas uma boa solução é entender o Planning em 3 momentos.

Planning – Momentos 1, 2 e 3

Não é linear, não é cascata, varia de acordo com a oportunidade, não precisamos fechar o #1 para iniciar o #2 e depois o #3, seguimos sempre a intuição e vamos seguindo o trabalho de entendimento e estimativas, quer em três etapas lineares, em blocos ou unitário, mas eis o conceito por trás de cada momento:

Momento #1. Apresentação das User Stories pelo Product Owner, todas, em lotes ou individualmente, o importante é entender que o Product Owner aqui apresenta o melhor possível cada história, contando com a valiosa ajuda do designer (UX) e SEO, caso algum desenvolvedor tenha participado do Discovery, com certeza terá a acrescentar também.

Momento #2. Discussão técnica com o objetivo de entender como uma ou mais histórias serão feitas, quebrando-as em pedaços, em tarefas passíveis de serem estimadas com maior precisão e que oferecerão melhor percepção de fluxo no quadro de tarefas, o ideal é que tenhamos tarefas na escala de horas ou no máximo um dia de trabalho estimado, este momento pode se prolongar um pouco, mas lembre-se “o bom é inimigo do ótimo!”, não gere desperdício.

Momento #3. Pacto quanto ao Sprint Backlog, certos da velocidade, entendido onde estamos, estimadas as User Stories, decompostas em tantas tarefas quanto conveniente, fechamos carga horária, oportunidades e objetivos, é fundamental que ao final repassemos o Definition of Done (DoD) e tenhamos tudo o que foi discutido visível a todos, especialmente as estatísticas de tempos e calendário.

Exemplo Prático

Na manhã do dia 15/07/2013 fizemos o planning da equipe de rádios, cfe segue:

  • 09:10 – início com velocidade, visão roadmap e estratégia macro
  • 09:40 – início da apresentação das User Stories selecionadas
  • 11:00 – debate técnico para fragmentação em tarefas
  • 13:00 – saída para almoço
  • 14:00 – reinício, velocidade, planejamento e comprometimento
  • 15:00 – pacto e conclusão (já com postits e quadro montados)

Alerta: Um ensinamento importante é que cada um destes momentos seja o melhor conduzido possível, o equilíbrio é o segredo, precisamos entender e não podemos estimar no escuro, mas de nada adianta querer ficar um dia em tentativa, afinal, a cada hora na sala lembrem-se que temos 5 desenvolvedores, um dia de debates equivale a um desenvolvedor por cinco dias sem construir nada, só debatendo … é muito. Sei de equipes que abrem uma semana entre Sprints e considero isso o maior absurdo e desperdício, não tem outro nome.

O mais importante: O Planning é mais alinhamento que garantias, então alinhe, arregace as mangas e mande bala, as dailys irão apontar e ajustar o caminho … Seja Agile e desapegue de tentar ter garantias, pois garantias é 100% waterfall, é gastar energia em planos que normalmente em SW já nascem caducos, ao invés de trabalhar na construção de valor para o negócio.

Desculpa ai, não tem receita de bolo, mas acho que passei a ideia, passei???

2 comentários sobre “Inspire-se, pois planning fácil e burocrático é mal sinal

  1. Pingback: Um ano e meio de blog – Obrigado galera! | Jorge Horácio "Kotick" Audy

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s