Transcenda o mindset de “Fábrica de Features” usando Modern Agile e OKR

Adoções Ágeis na maioria das empresas enfocam a entrega. Frameworks para escalar normalmente não ajudam, pois seguem o caminho de menor resistência e se concentram em melhorar o desenvolvimento de software através de muitas práticas ao invés de dar foco a alcançar agilidade de negócio.

Quando é hora de criar metas, o mindset comando-e-controle ainda é a norma: organizações usam um processo anual, top-down, para criar um conjunto de metas estáticas: um conflito direto com ser ágil.

Cascatear metas é um processo corporativo padrão. Você consegue pensar em uma analogia mais top-down do que uma cascata?

Métricas e metas waterfall transformam times em "fábricas de features" sem nenhum foco em entregar valor. Como John Cutler descreveu, muitos desenvolvedores estão só "sentados na fábrica, trabalhando em feature após feature e as mandando linha de produção abaixo."

Marty Cagan ressalta a enorme oportunidade perdida pelas fábricas de features: "times só estão lá para trabalhar nos detalhes, códigos e testes, com pouco conhecimento sobre os problemas de negócios, e ainda menos crença de que essas são de fato as soluções corretas." Isto é, as pessoas mais próximas do trabalho não têm influência para tomar decisões que ajudem seus clientes ou alavanquem soluções existentes.

Ao invés de dar autonomia para times criarem produtos excelentes, essa versão falha de Ágil se ocupa com um grupo de projetos aprovados pela gerência.

Frederick Taylor ficaria feliz de ver que seus ensinamentos ainda estão em uso nos dias de hoje. "Todas tarefas de cada trabalhador são planejadas pela gerência com pelo menos um dia de antecedência.", ele escreveu no livro Princípios da Gerência Científica em 1911.

Na abordagem Taylorista ao Ágil, times existem para entregar projetos e features planejadas com antecedência pelos executivos. Este modelo de planejamento waterfall reduz a velocidade de empresas e faz com que seja mais difícil para elas se adaptarem à mudança, ao mesmo tempo que aumenta o risco e o desperdício.

Como podemos chamar isso de adoções ágeis? Os praticantes sabem que usar Ágil para entregar planos waterfall traz benefícios limitados: 70% deles reportam tensão entre seus times e o resto da organização, enquanto 63% das falhas de adoção ágil estão ligadas a cultura e filosofia da empresa estar em contraste aos valores ágeis.

Uma Maneira Melhor

Uma alternativa para transcender o mindset de fábrica de features é adotar os quatro princípios do Modern Agile. Porém, como colocá-los em prática? Como que podemos "ser" Ágeis no sentido moderno?

Existe uma ferramenta acionável para agilidade de negócio que, se usada corretamente, vai apoiar a adoção dos 4 princípios do Modern Agile. Essa ferramenta é o OKR (Objectives and Key Results), framework de metas usado por empresas como Intel, Google, e Spotify.

A grande diferença dos métodos de planejamento tradicionais? OKRs são criados e avaliados com frequência - todo trimestre tipicamente. Além disso, ao invés de metas cascateando para baixo na organização pelos executivos, OKR é bi-directional: times criam a maioria de seus OKRs alinhados com as metas da empresa e então entram em acordo com a gerência, em uma abordagem que começa de baixo pra cima.

Esta abordagem é muito mais engajante para times, que agora se sentem responsáveis pelos objetivos que ajudaram a criar, e que são monitorados em um rápido ciclo semanal.

Criar metas desafiadoras é um pilar fundamental de OKR, o que leva a resultados e criatividade. Como Amantha Imber reportou, as pesquisas mostram que se pessoas se sentem desafiadas pelo seu papel, 67% vão demonstrar criatividade acima da média e inovação em seu desempenho.

Dan Montgomery disse bem, "OKR é o motor do dia-a-dia para agilidade organizacional."

Como OKR suporta os 4 princípios do Modern Agile?

Entregue Valor a Todo Instante

Escalar Ágil é difícil por que escalar entrega (que é a razão que corporações querem Ágil) não escala valor. Jeff Gothelf, co-autor de Lean UX e Sense and Respond

Como o Felipe já escreveu aqui na InfoQ, o Manifesto Ágil esta errado. O sétimo princípio, "Software funcionando é a medida primária de progresso," está desatualizado e é enganoso. Ele foi concebido num momento em que os agilistas tinham de convencer as pessoas de que entregar documentação não era suficiente.

Essa antiga premissa de que software que funciona é a medida de progresso se sustenta na crença de que todo software que funciona tem valoré. Sabemos que isso não é verdade. Precisamos prover software valioso - assim como diz o primeiro princípio do Manifesto. Modern Agile nos ensina a focar na entrega contínua de valor real, ajudando a fazer nossos clientes serem sensacionais.

Modern Agile sabe que "pronto" só importa se adicionar valor, assim como nessa grande provocação de John Cutler: "a geralmente esquecida coluna da direita: Funcionou?".

Precisamos abandonar conceitos baseados em tarefas, como a definição de pronto, gráficos de burn-down, e velocidade, para focar em valor. Ao invés de critérios de aceitação, nós precisamos de critérios de sucesso - com OKR.

Por mais que as palavras do Manifesto sejam enganosas, alguns de seus autores escreveram explicitamente sobre a necessidade de foco em resultados:

A chave para [ganhar do] waterfall é perceber que agilistas valorizam Resultados sobre Features. A lista de features é uma ferramenta valiosa, mas é um meio e não um fim. O que realmente importa é o resultado final, que eu vejo como valor para os clientes. Martin Fowler

Como é só um framework, OKR pode ser usado para medir a produção de features. A mera medida de atividades, porém, não é um uso correto de OKR e é incompatível com Modern Agile.

Praticar Modern Agile requer criar e avaliar OKRs baseados em Valor com frequência, que medem a entrega de valor para organização cliente.

Os dois exemplos abaixo mostram a diferença com clareza:

Times podem dar foco à entrega de valor adotando OKRs baseados em Valor. Mas como podem fazer isso "continuamente"?

O ciclo trimestral do OKR pode agir como o timebox final para entregar valor: todos times tem que gerar valor durante o trimestre, melhorando os resultados chave selecionados. Ao invés de grandes releases, times investem energia em testar hipóteses e experimentando e aprendendo rapidamente, o que nos leva ao próximo princípio.

Experimente e Aprenda Rápido

Ao invés de ser guiado por dados, Ágile antiquado é dirigido pelo HIPPO: the Highest Paid Person's Opinion, como ilustrado brilhantemente no livro How Google Works:

Empresas estão presas na antiga ilusão ágil de que mostrar software para os stakeholders durante o review do sprint ou uma demo é uma medida adequada de progresso.

Só é possível experimentar e aprender rapidamente quando damos foco aos resultados e evidência ao invés de opiniões pessoais.

OKR substitui o HIPPO com experimentos mensuráveis que permitem que o time itere e aprenda. Ele permite que o time a adote práticas como Desenvolvimento Dirigido por Hipóteses, como descreveu Barry O'Reilly:

Nós acreditamos que <esta capacidade>

Vai nos dar <este resultado>

Nós teremos confiança para proceder quando <observarmos um sinal mensurável>

Se nosso objetivo é um resultado de negócio e damos ao time liberdade para experimentar em direção a essa meta, pequenos investimentos podem levar a resultados sensacionais. Em um exemplo, uma feature de 20 minutos levou a 'Know Your Company' a triplicar suas vendas, e Eric Elliott entregou "um ticket no Jira que gerou ao seu empregador $1MM/Mês".

Torne Pessoas Sensacionais

Se você só usa seus engenheiros para escrever código, você está recebendo só metade do valor deles. Marty Cagan

A premissa por baixo do modelo da fábrica de features é que o time é incapaz de decidir o que construir. Essa abordagem é baseada no princípio taylorista de separar o planejar do fazer, uma visão tanto tóxica quanto desmotivante.

O princípio 'Torne Pessoas Sensacionais' do Modern Agile é fundamentado em prover pessoas com a oportunidade de contribuir suas melhores idéias.

Quando seu time não tem voz em relação ao que construir e só "esvaziam seu prato" de features do backlog uma atrás da outra, eles não são sensacionais. Além disso, você não terá uma contribuição completa deles.

Para realmente capacitar times auto-organizados, você precisa dar a liberdade de decidir como alcançar o resultado valioso desejado. O propósito do time tem que mudar de "entregar as features que os stakeholders querem" para "alcançar os OKRs baseados em Valor concordados."

Henrik Kniberg tem um slide bom que demonstra essa mudança de propósito:

Na abordagem Ágil tradicional, equipes trabalham em coisas por que alguém mandou ("Sam"). No outro extremo, times trabalham em coisas somente pela razão de que "eles sentem que querem."

Para tornar pessoas sensacionais, precisamos de uma terceira opção. Equipes que tem um propósito e entendem como podem ter impacto. Eles têm uma visão clara e direta entre seu trabalho e a estratégia da empresa.

Faça da Segurança um Pré-requisito

Um time de pesquisa do Google descobriu que a dinâmica de liderança que separa times de sucesso de outros times é a segurança psicológica: Podemos nos arriscar nesse time sem nos sentirmos inseguros ou envergonhados? Podemos superar o medo e relutância de falar com idéias controversas ou perguntas?

Um dos pilares fundamentais de OKR é que empresas não deveriam punir pessoas por perseguir metas ambiciosas. Desacoplando OKR de salário e promoções, empresas podem criar ambientes seguros psicologicamente onde pessoas podem experimentar idéias audazes.

Mesmo assim, para fazer da segurança um pré-requisito, empresas também tem que diminuir seus ciclos de validação drasticamente. Anos após o lançamento do livro The Lean Startup, a maioria das organizações ainda trabalha durante meses sem entregar nada ao usuário final.

Eles se expõem ao risco colocando equipes, em sua maior parte compostas somente de desenvolvedores, incrementalmente e cegamente entregando um backlog waterfall para um ambiente de validação, sem nenhuma forma de confirmação externa.

Para reduzir riscos, empresas precisam parar de seguir planos cegamente e evoluir de integração contínua para entrega e validação contínua.

"A única maneira de que tudo está indo de acordo com o plano é se você não aprender nada." Kent Beck

Para piorar, esses planos são criados por um único gerente ou Product Owner, que muitas vezes nem tem acesso aos dados do produto para tomar melhores decisões. Esse tipo de situação é desmoralizante e inseguro. Mary Poppendieck, autora do Leading Lean Software Development, escreveu:

Talvez a maior deficiência de práticas de desenvolvimento ágil é a maneira como equipes decidem o que fazer. [...] por muito tempo, responder a essas perguntas não foi considerado a responsabilidade das equipes de desenvolvimento e DevOps. Mary Poppendieck

OKR faz da segurança um pré-requisito garantindo que times colaborem para criar objetivos e decidir o que construir (ou qual experiência conduzir) e adotar ciclos de feedback menores, reduzindo risco e desperdício.

Como David J Bland escreveu, "[o processo de] planejamento e orçamento anual colide com seus esforços de se adaptar à mudanças e mudar seu roadmap enquanto você aprende no mercado... Líderes estão finalmente entendendo que para tornar suas organizações mais ágeis, eles vão precisar começar a questionar algumas destas funções [fundamentais] para conseguir agilidade organizacional."

Conclusão

Assim como qualquer outro framework de planejamento, OKR não é perfeito e pode ser usado erroneamente. Nós acreditamos que os quatro princípios do Modern Agile podem ser guias valiosos na sua prática de OKR e ser um começo acionável para sua jornada pelo ágil moderno.

Combinando Modern Agile com o uso correto de OKR pode ser uma maneira leve, e prazerosa para organizações alcançarem resultados sensacionais.

Para mais sobre Modern Agile e OKR, visite modernagile.org e felipecastro.com.

Agradecemos a Lael Gold, Joshua Kerievsky, Bill Wake e Tim Ottinger pro revisões em versões preliminares deste artigo.

Sobre os autores

Felipe Castro é um Goal Hacker. Ele ajuda organizações a transformar seu uso de objetivos adotando OKR, , o framework do Silicon Valley para a definição de metas. Ele criou o ciclo Set-Align-Achieve, um método simples para evitar os erros mais comuns com OKR. Seu blog é felipecastro.com.

Alexandre Freire Kawakami é um programador, coach, cientista e estudante que ama empurrar as fronteiras do desenvolvimento ágil de software. Como Diretor na Industrial Logic, trabalha para entregar software e serviços de qualidade para resolver os problemas reais dos nossos clientes, e ajuda a prover as ferramentas necessárias para criar um caminho para seu time se tornar sensacional.