O Manifesto Ágil está errado.
É isso mesmo, há um artigo na InfoQ dizendo que o Manifesto Ágil está errado. Segurem os protestos por enquanto. O Manifesto é fundamental, mas um dos 12 princípios está errado:
Software funcionando é a medida primária de progresso.
Manifesto Ágil, 2001
Isso está errado. Está errado agora e estava errado em 2001. A medida primária de progresso devem ser resultados de negócio, não somente software funcionando.
Aliás, este princípio conflita com o primeiro:
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
Então, não deveríamos medir software funcionando, mas software com valor agregado. Isto está 100% correto. Mas, o que é valor agregado? Como definimos valor?
Valor significa coisas diferentes para pessoas diferentes, dependendo do seu ponto de vista. Existem diversas técnicas para lidar com valor de negócios em projetos ágeis, incluindo Value Points, Business Value Modeling e outras.
A maioria delas são simplesmente estimativas e não são medidas reais de valor, que só podem ser mensuradas depois que a funcionalidade é entregue.
Em Janeiro/2015, Ken Schwaber escreveu, descrevendo o Nexus, seu framework para escalar Agile (tradução livre):
No nosso caso, um Nexus são 3-9 Times Scrum que estão trabalhando em um único Backlog de Produto para criar um incremento integrado que atinge uma meta.
Nenhuma palavra sobre o que é esta meta e como definí-la.
Precisamos de uma maneira de definir metas claras que sejam compartilhadas entre os diferentes stakeholders e o time.
O que está errado com Definição de Metas
Planejamento Estático. É como chamo o processo anual tradicional de planejamento. Todos sabemos como funciona: há um evento corporativo no qual o "pensamento estratégico" acontece e as metas para o ano são definidas. Então, ao longo das próximas semanas, as metas são cascateadas pela organização, criando um plano fixo e detalhado para o ano para a companhia.
O modelo estático carrega as premissas que: (1) todas as etapas do plano podem ser definidas antecipadamente; (2) a vasta maioria do plano vai estar correta; (3) condições de mercado são permanecer fundamentalmente as mesmas; e (4) mudanças no plano serão pequenas e serão executadas em uma revisão no meio do ano - na qual um novo plano estático detalhado será criado.
A própria analogia da cascata literalmente se refere à um fenônemo top-down unidirecional.
Em contraste, o planejamento dinâmico aceita a mudança e trabalha em ciclos menores de planejamento, em um modelo incremental e iterativo. Planejamento dinâmico assume que as condições de mercado e o plano em sí vão mudar.
Nassim Taleb, autor do livro A Lógica do Cisne Negro, gosta de comparar o modelo estático aos planejadores centrais do Kremlin que criavam planos quinquenais acreditando que eles podiam prever o futuro.
Se seus times estão trabalhando em iterações (ou sprints) de uma a quatro semanas, saindo do prédio para falar com clientes, testando hipóteses através de aprendizado validado, como é possível utilizar um conjunto estático de metas definido em um processo waterfall anual que poderia ter sido criado pelo Kremlin?
A resposta é: não é possível.
Tem que existir outro caminho.
No seu artigo na MITSloan Management Review chamado "Should You Build Strategy Like You Build Software?", Keith R. McFarland escreveu (tradução livre):
Como a estratégia só pode capturar o melhor pensamento da companhia em um determinado ponto no tempo, ela (assim como um software) precisa ser refinada e melhorada na medida em que as pessoas ganham e distribuem novas experiências e conhecimento.
Dada essa realidade, um processo sólido de desenvolvimento de estratégia deveria permitir que uma companhia crie e adapte a estratégia rapidamente e iterativamente... e aloque recursos em ambientes em mutação.
Então, apesar de usar a mentalidade e processos Ágeis/Lean, taticamente ainda estamos usando a mentalidade e processos waterfall para definição de metas. Isso precisa mudar.
Como podemos implementar uma nova abordagem? McFarland menciona o uso de "scrums de estratégia", mas um framework mais formal ainda estava faltando. Conheça OKR.
OKR: um framework Ágil de Definição de Metas
OKR (Objectives and Key Results) é um framework de definição de metas criado pela Intel e adotado por diversas empresas do Silicon Valley. O Google é o caso mais famoso, tendo adotado OKR no primeiro ano da empresa. Twitter, LinkedIn, Dropbox e GoPro estão entre outras empresas que utilizam OKR.
O investidor John Doerr, que apresentou OKR ao Google, tem uma grande dica para definir metas :
Eu vou ________ medido por ____________.
Um OKR pode ser pensado como um comprometimento redigido como:
Eu vou (Objetivo) medido por (este conjunto de Key Results).
Então, um OKR tem dois componentes, o Objetivo (O que queremos atingir) e um conjunto de Key Results (Como sabemos se estamos chegando lá):
Objetivo
- O que queremos atingir;
- Qualitativo.
Utilizar Objetivos aspiracionais é altamente recomendado. As pessoas não levantam da cama de manhã para "melhorar a conversão por 10%".
Key Results (um pequeno conjunto por Objetivo)
- Como sabemos se estamos chegando no nosso Objetivo;
- Quantitativos;
- Critérios de Sucesso que mostram se estamos progredindo;
- Métricas (recomendado) ou Milestones.
Como um exemplo, imagine uma empresa digital que quer aumentar o engajamento e a satisfação dos clientes:
Objetivo: Encantar os clientes
Key Results:
- Visitas Recorrentes: média de 3.3 visitas por semana por usuário ativo;
- Alcançar um Net Promoter Score de 90%;
- Tráfego não pago (orgânico) de 80%;
- Engajamento: 75% dos usuários possui um perfil completo.
O que é único sobre OKR?
- Simplicidade: Para fazer ciclos frequentes de definição de metas (a Intel costumava usar OKRs mensais), o processo é extremamente simples. Os próprios OKRs devem ser simples e facilmente compreendidos.
- Cadência curta: Ao invés de utilizar um processo anual estático de planejamento, OKR usa ciclos curtos de desdobramento de metas (normalmente todo trimestre), permitindo a adoção de Metas Ágeis e mais rápida adaptação à mudança.
- Open Source: OKR é um framework open source, então as empresas o adaptam para cada cultura e contexto, criando versões diferentes. Este é um grande benefício já que OKR é facilmente adaptável, mas pode confundir aqueles que estão buscando uma receita passo-a-passo.
- Stretch Goals: Metas que tiram o time da zona de conforto e fazem com que as pessoas repensem a maneira de trabalhar para atingir máxima performance.
- Separação de remuneração e avaliação: Desacoplar metas de salário e promoções é chave para que o time possa buscar metas difíceis e aspiracionais.
A Prática de OKR
O principal objetivo de OKR é criar alinhamento na organização. Para fazer isto, transparência é chave. OKRs são transparentes para todos os níveis da companhia - todos tem acesso aos OKRs de todos os outros. Todos os OKRs, inclusive do CEO, estão usualmente disponíveis na Intranet.
OKR existe para definir prioridades claras e focar a organização. Assim, é preciso ter poucos OKRs. Cada indivíduo ou time deve ter até 5 Objetivos com até 5 Key Results - menos é mais aqui.
Definição de Metas Adaptativa e Incremental
OKR usualmente tem dupla cadência:
- Metas de alto nível para a empresa são definidas anualmente.
- Metas detalhadas incrementais para os times e individúos definidas em ciclos mais curtos de metas (iterações) que usualmente duram um trimestre, mas também podem durar 30 ou 45 dias.
No início do ano a companhia define um pequeno número de OKRs de alto nível - de preferência consultando o time - sem definir planos detalhados para o ano todo.
No início de um ciclo de metas, cada time revisa seus resultados da iteração anterior e então define metas para o próximo ciclo de metas. Em um processo paralelo, indivíduos e times definem metas que estão alinhadas com os objetivos da organização e são validadas com os gestores, em um processo simultaneamente bottom-up e top-down.
A partir dos OKRs da companhia os times são capazes de receber um direcionamento claro e compreender como eles contribuem para estes objetivos. Cerca de 60% dos OKRs devem ser definidos pelo time.
Metas que não foram alcançados no ciclo anterior são reavaliadas para que possam ser incluídas no próximo ciclo, ou caso não sejam mais necessários, descartadas.
Alinhamento Horizontal
Para definir seus OKRs, indivíduos e times debatem para solucionar interdependências e criar alinhamento horizontal. Se um time precisa de algo de outro time, eles podem debater e definir prioridades comuns ou mesmo adiar a iniciativa para o próximo ciclo de metas.
Como OKRs são transparentes, se uma área da companhia está desalinhada com as outras, isto pode ser rapidamente identificado pelos outros times e corrigido.
Reforçando Alinhamento: OKRs Compartilhados
Para reforçar o alinhamento, OKRs compartilhados podem ser definidos entre times diferentes, criando critérios de sucesso compartihados entre eles. Então, no lugar de dividir uma iniciativa entre times e fazer com que cada um tenha metas separadas - o que pode fazer com que os times percam a visão do objetivo real - um único OKR compartilhado é criado entre os times.
Por exemplo, imagine que um time de produto deseja lançar um novo produto e precisa que o time de plataforma desenvolva novas funcionalidades enquanto que o time de parcerias assine contratos de conteúdo com parceiros.
Objetivo: Lançar com Sucesso Produto Acme
Key Results:
- 500.000 Daily Active Users da versão gratuita;
- Taxa de conversão de 8% de usuários gratuitos para pagantes;
- Net Promoter Score de 75%;
- Menos de 5 bugs críticos ou blockers reportados pelos usuários;
- Atingir ao menos 40% de revenue share com 5 dos parceiros de conteúdo selecionados.
Ao invés de ter 3 metas diferentes que poderiam ser individualmente alcançadas sem gerar o resultado de negócios desejado, este único OKR é compartilhado entre os times. Cada time tem tarefas diferentes, mas o mesmo OKR - a mesma definição de sucesso.
Pela duração deste OKR, um time virtual será criado entre as 3 áreas que irá se reunir regularmente para acompanhar o progresso do OKR.
Como OKR complementa Lean e Agile
OKR traz disciplina para aprendizado validado
Steve Blank escreveu em seu artigo:
Use o Business Model Canvas para definir hipóteses, Customer Development para sair do prédio e testar hipóteses e Engenharia Ágil para construir o produto de maneira iterativa e incremental
Como saber se está tendo sucesso? O que consideramos uma "hipótese validada"? Precisamos de claros critérios de sucesso compartilhados para aprendizado validado. Então, adicionaria:
…e OKR para acompanhar se você está indo na direção certa.
OKR define Critérios de Sucesso além de features
Projetos ágeis são comumente avaliados pela velocidade com que entregam features (com "qualidade"). Porém, um time que entrega features mas deixa de alcançar os resultados de negócios desejados jamais será considerado bem sucedido.
A OKR coach Christina Wodtke tem um ótimo tweet sobre "successo" (tradução livre):
Sucesso não é marcar uma caixinha.
Sucesso é ter impacto.
Se você completa todas as tarefas e nada melhora, isso não é sucesso.
De fato, entregar features que não afetam positivamente métricas selecionadas (Key Results na linguagem de OKR) pode gerar retorno negativo. O novo código poe conter bugs, terá que ser mantido e o próprio produto terá ficado mais complexo.
Marty Cagan tem um post obrigatório no assunto (assim como diversos outros). Se você não leu seu livro ou seu blog, você deveria:
É por isso que estou tão feliz em ver o retorno dos OKRs. Quando utilizados apropriadamente, eles ajudam a reestruturar a situação de output (features em um roadmap) para outcome (resultados de negócios).
OKR ajuda a evitar o problema da "temperatura do chuveiro"
Se continuar a girar a torneira do chuveiro, a água nunca vai chegar a temperatura que quer. É o mesmo com inovação, se ficar pivotando o tempo todo, nunca vai chegar aonde se deseja.
O uso de de ciclos curtos de metas pode ajudar a evitar o problema. Claro que coisas darão errado, mas como o ex-VP de Produto da Zynga Jon Tien disse em um ótimo video sobre OKR:
Problemas acontecem, mas isso não quer dizer que você não deve usar a mesma disciplina.
OKR permite times auto-organizáveis
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Como se implementa times auto-organizáveis?
Para ter uma organização horizontal, com alto alinhamento e alta autonomia, formada por times auto-organizáveis, é necessário definir um "Norte" para a organização. É preciso dar para os times um direcionamento claro.
Um conjunto de OKRs para cada time fará exatamente isto.
OKR conecta o time com o negócio e seus clientes
É muito fácil para um time se perder nas tecnicalidades de escrever código ou design. Mas, quando se começa a falar sobre resultados de negócios em um processo bottom up, é preciso que os membros do time comecem a questionar o motivo de estarem fazendo o que estão fazendo.
Se continuar falando sobre entregar features como se espera que o time fale do negócio?
Como OKR complementa Scrum
OKR dá autonomia ao time
Em algumas companhias a/o Product Owner é chamado de "Proxy Owner" já que ela/ele simplesmente leva e trás a lista de features que foi priorizada pelos executivos. Como dar a ela/ele o mandato para gerenciar o produto? Como é possível ter certeza que o time tem autonomia?
Se o papel do time é "entregar as features que o cliente/time executivo quer" isto jamais irá acontecer. A mentalidade tem que ser "o papel do time é alcançar os critérios de sucesso como descritos nos Key Results e acordados com o cliente/time executivo. Vamos dar autonomia ao time para fazer isto".
OKR ajuda a priorizar o backlog de produto
Ainda que se deva focar em entregar resultados de negócios e não features, ainda é necessário priorizar o backlog de produto.
Como o Product Owner/Gerente de Produto deve fazer isto? Ela/ele deveria usar "valor percebido" como criterio, mas isto ainda é subjetivo. OKR pode atuar como a peça que falta, um framework simples e claro para decidir em quais features trabalhar.
Como Cagan escreveu sobre product scorecards (agora sendo substituídos por OKRs):
Um dos meus benefícios favoritos é que eles podem usualmente ajudar a eliminar boa parte do seu backlog/roadmap. Se uma feature não afeta diretamente um dos principais KPI's [Key Results] no product scorecard [ OKRs], geralmente está fora a lista.
Conclusão
Espero que este artigo tenha sido capaz de mostrar que OKR pode ser um ótimo framework para criar alinhamento e melhorar a comunicação entre times, complementando Lean e Agile em múltiplas dimensões. É uma técnica simples e clara, que requer somente algumas conversas estruturadas para definir metas.
Para saber mais sobre a prática de OKR, junte-se a nós na OKR Alliance, organização global sem fins lucrativos dedicada a encorajar a adoção bem sucedida de OKR.
Você está usando OKR ou planejando usar? Tem alguma pergunta? Por favor poste nos comentários.
Sobre o Autor
Felipe Castro (@meetfelipe) é OKR Coach é sócio da Lean Performance, consultoria focada em ajudar empresas a construírem culturas Focadas em Resultado, Data Driven e Baseadas em Validação de Hipóteses. Felipe é Engenheiro de Computação pela PUC-Rio.
