Como Usar OKRs Para Atingir Metas Desafiadoras em um Contexto Ágil
Uma das minhas principais falhas ao iniciar no mundo da agilidade como Scrum Master foi focar em ritos e práticas do Scrum e ignorar a entrega de valor pelo time. Por isso, resolvi falar sobre um pouco sobre OKRs (Objective and Key Results) e como transformar grandes projeções das organizações em objetivos alcançáveis e mensuráveis.
Muito se tem falado sobre Transformação Digital e Business Agility. Para que uma organização possa se tornar verdadeiramente ágil, seus times devem estar alinhados e trabalhar baseados em prioridades táticas e estratégicas.
A utilização de OKRs tem se tornado uma alternativa bem interessante, agindo como um verdadeiro “parser” entre uma visão e o direcionamento para times que compõem a organização.
➡️ Definindo o que é OKR
OKR (Objective Key Results) é um framework de gestão value-driven que mensura resultados e não esforço. Esse framework é baseado na busca de objetivos desafiadores e resultados mensuráveis dentro do plano de crescimento de uma organização. O framework OKR tende a responder às mudanças e orientar as pessoas a objetivos claros, mensuráveis e transparentes.
Os objetivos da organização (Objectives) devem ser significativos, inspiradores e direcionados a uma transformação. É simplesmente, o caminho a seguir para uma projeção futura da organização. Um objetivo deve ser simples, fácil de assimilar e possuir um prazo para ser alcançado.
A proposta é mensurar, geralmente em trimestres ou quadrimestres, através de indicadores (Key Results) se o seu time está contribuindo de forma eficaz para atingir o objetivo estabelecido pela sua organização.
➡️ Estrutura de um Objetivo de OKR:
◾ Começa com um verbo, é inspirador e qualitativo.
◾ Deve ser uma frase simples e clara.
◾ Deve possuir um Qualitativo.
Exemplo de Objetivo: “Ser maior empresa de tecnologia da América Latina.”
➡️ Estrutura de um Key Result:
Um key Result é composto por: Verbo + Indicador + Meta.
Exemplo de Key Result: “Reduzir o turnover anual de 8% para 5%.”
➡️ Boas práticas em OKR’s:
Como já mencionado acima, OKR’s são orientados a resultados e não a performance. Por isso devemos optar por OKR’s value-driven usando verbos apropriados.
- Bad OKR’s (task-driven)
Verbos contra-indicados: lançar, criar, desenvolver, entregar, construir, fazer, implementar, definir, liberar, testar, preparar e planejar e etc… - Good OKR’s (value-driven)
Verbos altamente indicados: Aumentar, reduzir, manter e etc…
➡️ Tipos de OKR’s:
- OKR Moonshot (Tiro na Lua)
São key results mais ambiciosos e desafiadores que tiram o time da zona de conforto e entregam valor mesmo se não forem plenamente completados. Dessa forma, completar de 60% a 75% de um OKR do tipo moonshot pode ser considerado um sucesso. - OKR Roofshot (Tiro para o teto)
Esse tipo de OKR também é desafiador, mas em uma escala de dificuldade menor. Contratar esse OKR é sinalizar que o time tem pleno conhecimento que é totalmente possível entregar 100% do que se comprometeu.
➡️ Observações Importantes:
- Atingir 100% dos OKR’s constantemente, significa que o time não está sendo ambicioso o suficiente.
- Não atingir 100% dos OKR’s constantemente, significa que o time não está sendo eficiente.
➡️ Como utilizar OKR com Scrum e Potencializar Resultados
O OKR e o Scrum são fortemente orientados a entrega de valor para a organização. Enquanto os OKRs destacam os objetivos mais importantes para a organização, o Scrum disponibiliza um framework para desenvolver e entregar produtos de alto valor.
Por isso, o time deve alinhar OKRs com sprint goals. Poderá também associar a entrega de PBIs (Product Backlog Itens) a “experimentos” voltados a alcançar os objetivos. Quando menciono “experimentos”, me refiro a possibilidade de alcançar ou não um objetivo a partir da entrega de uma feature ao usuário.
É recomendável que, na Sprint Planning, o time priorize os PBIs (Product Backlog Itens) que terão a melhor chance de alcançar um OKR. Caso a entrega desses PBIs não tenha contribuído para alcançar um objetivo, o time poderá usar o aprendizado para determinar uma nova hipótese e refinar o Product Backlog.
➡️ Uso de OKRs no Suporte a Priorização de Atividades do Time
Quando trabalhamos com base em OKRs bem definidos, os times possuem foco no que precisa ser priorizado e executado. Dessa maneira, é possível descartar facilmente situações novas que surgem e poderiam ser um fator de desperdício de tempo, esforço e que não entregariam valor.
A utilização de OKRs com Scrum, dá mais confiança ao time sobre o que deve ser feito agora e nas próximas iterações.
A entrega de novas features pelo time, caso confirmadas como efetivas, devem invariavelmente impactar nos Key Results (indicadores).
➡️ Entregas não Representam Geração de Valor
Sim! É isso mesmo que você leu. Entregas nem sempre representam geração de valor. Por isso, falamos que PBIs são meramente hipóteses até que se confirmem efetivas através da sua constante utilização pelo usuário. A ideia não deve ser a entrega e sim o impacto que ela produz nos indicadores.
Por isso, trago alguns questionamentos sobre objetivos e os seus resultados:
◾ Como o time pode entregar valor?
◾ Quais são as hipóteses que nos ajudam a atender satisfatoriamente o usuário?
◾ Quais as deficiências do produto que entregamos?
◾ O que estou fazendo agora pode ser traduzido em satisfação para o usuário?
As respostas para essas perguntas podem ajudar o Product Owner a listar Key Results que irão medir o progresso e alcançar o objetivo do time.
➡️ Relacionando OKRs, Sprint Goals e Product Backlog
Pelo que falamos até aqui, as Sprint Goals e o trabalho do Time Scrum devem ser orientados a OKRs. Por isso, Product Owners devem garantir que o maior número possível de PBIs estejam associado a um OKR.
A associação OKRs e PBIs irá conectar a execução das atividades do time as metas do produto que está sendo produzido. È fortemente recomendável integrar ferramentas de gestão ágil como JIRA ou Azure Devops aos OKRs, utilizando labels ou tags, para que o time tenha uma visão clara do trabalho destinado a atingir um OKR.
Por isso, o Product Backlog deve sofrer um processo de revisão sempre que for atualizado um novo progresso para atigir um OKR. Podemos dizer que entregas baseadas em Key Results geram aprendizados e insumos que impactam na composição do Product Backlog e na execução das próximas sprints.
➡️ Ritos do Scrum Orientados a OKRs
Se paramos para observar, é fortemente recomendável que uma OKR possa ser objeto de destaque nos ritos do Scrum. Isso dará a possibilidade de readaptar a estratégia de execução do trabalho.
Para isso, é muito importante que as OKRs estejam claras e devidamente acessíveis ao time.
Sempre que o time participar dos ritos de Refinamento do Product Backlog e Sprint Planning , as OKRs devem ser consultadas para que haja descarte, inserção e priorização de PBIs. Além disso, o direcionamento e progresso para alcançar as OKRs também deve ser discutido em cada Daily.
Inserção de trabalho não planejado dentro de uma sprint pode impactar no progresso para atingir uma OKR. Por isso, uma OKR também serve como ponto de apoio para decisão do Product Owner de propor ou não um trabalho emergente dentro da sprint ao time.
Por último, o time também deverá focar em OKR durante a Sprint Review, avaliando se o que está sendo entregue na sprint contribui no alcance de uma OKR.
Finalmente, os Times Scrum devem revisar o progresso em direção aos seus OKRs durante as Revisões do Sprint e o processo para alcançá-los nas Retrospectivas do Sprint.
➡️ Erros mais Frequentes ao Determinar uma OKR
Primeiramente, para evitarmos erros é preciso destacar que toda Key Result deve gerar valor para a organização.
É comum Product Owners definirem Milestones em um Roadmap e transformá-los em key Results. Milestones são importantes apenas para a estratégia de entrega do time mas não tem impacto de negócio.
Além disso, é importante lembrar que PBIs não são OKRs. OKRs medem impacto do que o time entrega e não devem jamais ser confundidos com PBIs.
Podemos listar também outros erros como:
◾ OKRs em excesso podem criar distrações e diminuir o foco.
◾ OKRs não ambiciosos não motivam a equipe a alcançar um desafio.
◾ OKRs não realistas, não alcançáveis.
◾ OKRs que não agregam valor ao cliente e desmotiva o time.
➡️ Conclusão
Mesmo executando a melhor estratégia ao rodar Scrum com seus ritos, o time não será efetivo se não tiver objetivos e indicadores que ajudem o time a mensurar esse alcance. Se as OKRs forem bem definidas e utilizadas em conjunto com o framework Scrum, poderão trazer maior coesão e ajudar na eficácia do trabalho do time.
OKR e Scrum formam um ecossistema de prioridades que favorece a efetividade do trabalho do time objetivando a entrega de valor, contribuindo para a tão falada Business Agility.
