Construindo vs aprendendo em equipes Agile

Por mais que eu goste de Agile, eu sei que ele possui suas limitações. Na verdade, eu estou lidando com uma dessas limitações em um projeto atual.

Esse projeto é muito grande e bastante nebuloso. Embora os objetivos de negócio sejam claros (ou seja, nós sabemos por que estamos fazendo isso), existem várias outras coisas que não são. Temos muitas questões em aberto sobre os requisitos de negócios (que características específicas/funções precisamos para construir) e os seus fundamentos técnicos (qual é o conjunto certo de tecnologias para esse problema).

Nossa abordagem inicial para fazer esse projeto foi firmemente baseada em uma metodologia Agile padrão. Nós compilamos um backlog de funcionalidades, as priorizamos, escolhemos as mais importantes, fizemos uma decomposição nelas, definimos os critérios de aceitação e começamos a executar.

À medida que fomos avançando, tornou-se logo evidente que algo não estava funcionando. A equipe estava infeliz com um monte de coisas: não tinha uma direção clara, muita divagação, sem um entendimento comum, e, o mais alarmante: uma aparente falta de progresso.

Agora, é importante observar algumas coisas por aqui. Primeiro, tínhamos um grupo de engenheiros inteligentes, dedicados e experientes. Segundo, havia um monte de trabalho que estava sendo feito por todos. Em outras palavras,  era um time forte, que estava fazendo tudo para ter sucesso.

No entanto, não estava funcionando e queríamos descobrir o motivo. E foi isso que achamos.

Construímos, portanto somos

A metodologia Agile se destina a produzir. Tudo que você faz em uma equipe agile é voltado para um objetivo: construir coisas.

Essa mentalidade de entrega afeta muitas coisas. Ela impacta o modo como as pessoas pensam e se comunicam sobre o trabalho que fazem (stories, por exemplo) e os progressos que fazem (ou seja, story points completos). Na verdade, equipes Agile medem o progresso (e, por extensão, o sucesso), principalmente pelo quanto eles construíram.

As práticas Agile também têm checagens seguras para garantir que a equipe esteja continuamente focada na entrega. Considere o que acontece quando nenhum cartão foi terminado em uma determinada iteração (a temida “velocidade zero”). Se o time for bom, uma retrospectiva para tal iteração envolverá, inevitavelmente, uma grande busca por respostas e brainstormings sobre como voltar ao caminho correto.

Em suma, as equipes Agile são condicionadas a atrelar a construção de coisas com o sucesso.

Aprendemos, portanto somos

Mas e se for muito cedo para começar a se preocupar com a construção de coisas? E se existirem muitas incógnitas para se trabalhar? Como você avalia o progresso quando você não pode concluir os story cards?

Nossa equipe penou com essa questão. Havia uma dissonância cognitiva que se formou na mente de todos: se não estamos construindo nada de concreto, não devemos estar fazendo progresso. E se não estamos fazendo progresso, então estamos falhando.

Bem, fazer as coisas é apenas uma forma de fazer progressos. Outra maneira é aprender as coisas.

Por exemplo, um dos princípios fundamentais do movimento “Lean Startup” é o aprendizado validado. Ele funciona através de um simples mas eficaz processo de teste de hipóteses. Ao formular e testar hipóteses, a equipe busca aprender. O que eles aprendem leva a mais hipóteses, uma mudança de direção (pivô) ou a interrupção.

Então, decidimos modificar a nossa abordagem e adotar essas ideias. Em vez de tentar construir uma característica, procuramos aprender. Em vez de escrever histórias, formulamos hipóteses. Em vez de mostrar a funcionalidade, nós revisamos as descobertas.

A propósito, estamos obviamente conscientes dos spikes como uma maneira de lidar com perguntas e respostas desconhecidas. Na verdade, você pode certamente chamar o que estamos fazendo de um tipo de spiking estendido. Qualquer que seja a maneira que irá chamá-lo, acho que a chave é ter uma abordagem disciplinada e estruturada para construir iterativamente o entendimento.

Por que isso importa?

Essa mudança aparentemente sutil na mentalidade da entrega para a descoberta faz uma diferença surpreendentemente grande. De repente, gastar tempo investigando algo que ajuda no teste de hipótese não parece uma distração ou um desperdício de tempo. Obter uma resposta, mesmo que negativa, parece tão satisfatório como construir algo. Gerar e perseguir mais hipóteses faz parecer que o progresso está sendo feito.

Isso é importante porque as pessoas e as suas perspectivas sobre as coisas são importantes. O sucesso e o fracasso são ambos contagiosos. Quando está tendo sucesso, você é motivado a ter mais sucesso. Da mesma forma que quando você está falhando, é motivado a desistir.

Eu já não ouvi isso tudo antes?

Dan North escreveu sobre esse fenômeno em seu artigo chamado “Introducing Deliberate Discovery” alguns anos atrás. Nele, recomendou sistematicamente irmos atrás das incógnitas, a fim de reduzir a ignorância e o risco.

Fomos certamente inspirados por suas ideias ao tentar descobrir como lidar com a situação. De fato, decidimos usar a metáfora de testes de hipóteses para implementar o conceito de descoberta deliberada em nossa equipe. Vamos ver o quão bem ele funciona.

***

Texto original disponível em http://tatiyants.com/building-vs-learning-on-agile-teams/