Muitas pessoas se perguntam como usar OKR e Scrum. OKR e Scrum são semelhantes, pois ambas as estruturas precisam de uma pessoa dedicada à sua implementação, um “Scrum Master” ou um “Embaixador da OKR ”. Ambos têm papéis claramente definidos, e sua responsabilidade é garantir que as equipes sigam as estruturas de cada framework. Scrum é uma estrutura altamente prescritiva com funções e cerimônias específicas. Os benefícios do Scrum incluem transparência, visibilidade do projeto e comunicação constante. A equipe decide coletivamente o trabalho que eles podem concluir em breves “sprints” de duas semanas, o que torna o scrum um processo muito democrático.
O OKR também possui um conjunto de regras, embora não seja tão codificado quanto o Scrum. Essas regras determinam o que um Objetivo pode ser, quais são os Principais Resultados e como eles trabalham juntos para medir a consecução dos objetivos. Como o Scrum, o OKR possui prazos, no entanto, estes são muito mais longos (trimestrais e anuais) do que as corridas de duas semanas. A criação de OKRs envolve primeiro, a liderança da empresa decidindo o que eles desejam alcançar, depois as equipes criando seus próprios OKRs e alinhando-os aos objetivos da empresa.
Como combinar Scrum com OKR
Você já dever ter percebido que existe como usar OKR e Scrum, correto? O OKR e o Scrum podem e trabalham juntos com bastante êxito, desde que todos sejam claros sobre o escopo e os parâmetros de cada estrutura. A metodologia OKR inclui Iniciativas, o que as equipes trabalham para alcançar seus Objetivos. Os sprints se encaixam perfeitamente nas Iniciativas para trabalhar dentro de um ciclo trimestral para os OKRs do Grupo.
Para ajustar essas duas estruturas, é importante que, ao iniciar cada trimestre, um Embaixador da OKR e um Scrum Master se reúnam com a equipe de desenvolvimento para decidir as três coisas mais importantes que precisam ser alcançadas nesse trimestre. Como a OKR lida com prazos mais longos e com objetivos mais amplos, e a Sprint com a organização mais granular do trabalho, as OKRs devem vir em primeiro lugar.
Para que o OKR funcione corretamente nesse estágio, é importante enfatizar a necessidade de Resultados Chave. Medir o número de bugs encontrados, por exemplo, é um Resultado Chave ruim se o problema que você está procurando resolver é um software com bugs. A correção de um bug pode reduzir os erros em um, mas se mais erros forem relatados, você não está tornando o software menos problemático, apenas contando quantos bugs existem.
Próximo passo
Com os objetivos e os principais resultados chave definidos, o momento do planejamento da Sprint pode começar. A duração das Sprints é algo importante para decidir nesta fase. Se os Sprints forem mensais, um único objetivo do Sprint provavelmente corresponderá diretamente a um dos três objetivos das equipes de desenvolvimento. Para sprints mais curtos de 2 semanas, que são mais comuns, os Objetivos do Sprint se tornam Iniciativas do OKR.
Cada OKR requer sua própria linha do tempo da Sprint. Isso funciona bem se você tiver uma grande equipe de desenvolvimento trabalhando em diferentes áreas de um produto, como front-end, back-end e sys-admin. Com essa abordagem, cada área lidera 1 linha de tempo do OKR e 1 linha do tempo da Sprint, enquanto todo o grupo possui 3 OKRs entre elas. Para equipes de desenvolvimento menores que não têm capacidade para executar três cronogramas do Sprint, recomendamos o uso dessa abordagem, mas mantendo uma única OKR.
Scrum e OKR jogam juntos e funcionam bem em projetos nos quais os objetivos da Sprint se tornam iniciativas para OKRs. No entanto, para ver o valor real de ambas as estruturas, é vital que elas sejam bem compreendidas por todos os envolvidos, que seja reservado um tempo para gerenciá-las e que sejam indicados um Scrum Master e um Embaixador da OKR.