SAFe Innovation & Planning vs. Sprint Planning
Estamos mudando para a SAFe em minha empresa e não consigo entender as diferenças. Sou certificado em Scrum (CSM / CSPO), mas não sei muito sobre o SAFe, e não vejo muita diferença entre a parte de planejamento do SAFe Innovation & Planning e o Scrum Sprint Planning. Qual é a diferença? Tentei pesquisar no Google, mas parece que eles são iguais, no entanto, em nossa equipe estamos fazendo I&P com pontuação de histórias de usuários e outros enfeites, mas também temos planejamento de Sprint onde também (re) pontuamos USs. Tenho a sensação de que estamos fazendo algo errado.
Respostas
No Scrum, o Sprint Planning ocorre no início de cada Sprint. Na maioria das implementações do Scaled Scrum, o Sprint Planning é sincronizado entre as equipes e geralmente tem um componente compartilhado onde as equipes alinham seus planos para o próximo Sprint. No SAFe, essa atividade é representada pelo Planejamento de Iteração no nível da equipe.
A Iteração de Inovação e Planejamento do SAFe não possui um evento correspondente no Scrum. A Iteração de Inovação e Planejamento ocorre uma vez por Incremento do Programa. No Scrum, cada Sprint (iteração) tem como objetivo produzir um produto potencialmente liberável. No entanto, a Iteração de Inovação e Planejamento é um período de reserva para melhorar o ferramental e a infraestrutura, educação contínua e treinamento cruzado ou construção de habilidades, atividades de verificação e validação formais, teste de aceitação do usuário, outras atividades relacionadas ao lançamento e Planejamento de Incremento do Programa. Ele tem um tipo de trabalho diferente de outras Iterações.
Antes de mudar para uma estrutura ágil escalonada (SAFe, LeSS ou qualquer outro), todos no processo devem ter 110% de clareza sobre o motivo do movimento.
A chave para dimensionar o processo é, como outros já disseram, fazer o mesmo processo que uma equipe normal faria, mas desta vez em outro nível. Tenho trabalhado com programas com mais de 300 engenheiros, portanto, neste caso, uma estrutura escalonada é obrigatória. Como uma equipe de 7 engenheiros faria um planejamento, refinaria e acertaria com o PO o que pode ser entregue nas próximas 2 semanas, o "mesmo" acontece quando você tem 700 engenheiros ... mas o "mesmo" neste caso é .. bem, não exatamente o mesmo.
De volta à pergunta original: "Não vejo muita diferença entre a parte de planejamento do SAFe Innovation & Planning e o Scrum Sprint Planning."
Há uma série de artefatos resultantes de um planejamento de PI que não são comuns em um Scrum Sprint Planning. Sua milhagem pode variar, mas alguns aspectos-chave que observei como fundamentais para um planejamento de PI adequado são:
Participação ativa das partes interessadas de negócios
Em comparação com um Scrum Sprint Planning normal, o negócio é representado pelo PO. No caso do planejamento de PI, é altamente recomendável ter os patrocinadores do projeto e do programa participando ativamente, fazendo perguntas e, no final do planejamento de PI, atribuir um valor de negócio a esses recursos.
Visualização de dependências entre equipes
A visualização de dependências entre times, como outros já mencionados, é quase inexistente em times que usam Scrum puro. Em estruturas escaladas, é (infelizmente) comum ter dependências entre equipes. Eles devem ser destacados, os riscos identificados e as mitigações acordadas entre as partes antes do planejamento do Sprint real. Se a equipe A depende de algo da equipe B e a equipe B não pode se comprometer a ajudar a equipe A, então talvez a equipe A precise revisar suas prioridades ou procurar alternativas.
Há muita pressão em ter essas sessões com todos nos mesmos locais físicos, embora na Covid19 vezes esse não seja o caso. É assim que se parece um quadro de dependência física normal (este quadro está disponível para todos em todos os momentos e as equipes vão escolher itens da lista de pendências e atribuí-los de acordo, destacando dependências e riscos):
Voto de confiança
Além disso, no final do planejamento de PI, cada engenheiro é questionado sobre o quão confiantes eles estão sobre o trabalho comprometido (e descomprometido) para o próximo PI. Se a confiança for baixa, as partes interessadas e patrocinadores podem ter a oportunidade no local de esclarecer dúvidas, dependências e abrir espaço para identificar problemas que, em um modelo normal, os patrocinadores levariam semanas ou meses para perceber.
Esta é a aparência de uma agenda de planejamento de PI:
Mais detalhes sobre o PI Planning no SAFe estão disponíveis em https://www.scaledagileframework.com/pi-planning/
A Inovação e Planejamento no SAFe é efetivamente uma atividade que consiste em duas partes: a primeira é um exercício clássico de inspecionar e adaptar, muito semelhante a uma Retrospectiva do Scrum. A segunda parte é o exercício de planejamento, quando o próximo Incremento do Programa (IP) é realizado por todas as equipes .
A diferença com um Sprint Planning é que no Scrum ele se refere a uma única equipe e uma única iteração. Em vez disso, o SAFe está abordando como dimensionar o Agile com várias equipes .
No SAFe, todas as equipes participam do planejamento de PI e ele abrange várias iterações, normalmente três ou quatro: as equipes são apresentadas com a visão para o incremento (qual é o objetivo do negócio) e os requisitos são divididos entre as equipes com base em sua área, então cada equipe divide e planeja suas próprias iterações e detalha os requisitos atribuídos em suas próprias Estórias de Usuário.
O break out desta equipe pode ser um planejamento Scrum Sprint clássico (SAFe é agnóstico sobre a metodologia de equipe), mas multiplicado por todas as iterações . Não há necessidade de ter um Sprint Planning separado após o planejamento de PI.
E depois que cada equipe preparou seus próprios planos para todas as próximas iterações, eles são revisados com todas as outras equipes para encontrar e resolver / planejar dependências; finalmente, cada equipe está ajustando os planos / atrasos dos sprints com base nessa revisão.
Estamos falando aqui de muitas equipes. Se um projeto for dividido entre menos de cinco equipes, não faz muito sentido usar o SAFe. A coordenação pode ser alcançada usando, por exemplo, Scrum de Scrums