Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

O desafio de escalar Ágil

Hoje em dia, não basta ser Ágil. Não basta entregar mais valor mais cedo. Não basta testar hipóteses e validar o mercado para seu produto. À medida que mais empresas entendem como o Ágil é um game changer, mais ele terá seus limites testados para entregar mais valor em menos tempo.

A agilidade partiu de um incômodo sobre a forma que projetos eram construídos e geridos. Com práticas que efetivamente atuam contra todas as disfunções encontradas no gerenciamento de projetos tradicional, o mindset ágil buscava fazer primeiro o que agrega mais valor, validar se a entrega faz sentido, e com isso, acabar deixando os itens que não entregam valor para o fim do Backlog, para serem feitos por último, se feitos.

Considerando que em projetos tradicionais 64% das features jamais ou raramente seriam usadas de qualquer forma, não é uma estratégia pouco ousada. Disruptivo, mas perfeitamente sensato, o mindset Ágil vem mudando o mercado.

Agora, o desafio declarado não é mais fazer Ágil — apesar de eu humildemente achar que poucos fazem Ágil direito. O desafio é escalar Ágil de forma a entregar mais, e mais e mais.

Sabe aquele lance de que 9 mulheres não geram um filho em um mês? Isso é bem verdade. Se você tentar colocar vários times para trabalhar em um único backlog, com código compartilhado, a situação é realmente inviável. Já sobrevivi a 6 times trabalhando o mesmo backlog e tendo que fazer merge a cada sprint (por restrição da forma que o cliente trabalhava) e não desejo isso ao meu pior inimigo.

Mas isso quer dizer que não dá pra escalar Ágil?

Claro que não. É perfeitamente viável escalar. Mas você tem que ter em mente que se você montar sua estratégia achando que um time mistura a massa, o outro coloca a assadeira no forno, o outro faz a cobertura e o outro confeita o bolo, tudo em paralelo, a coisa vai desandar.

Então o que fazer?

Para escalar Ágil, é necessário olhar para cada time como um núcleo que precisa ter ownership de um pedaço do produto. Por exemplo, se estamos falando de um e-commerce, teremos uma área de cadastro de produtos e ofertas, uma área de gestão de conteúdo, toda a parte de controle de compras e carrinho, bem como todos os itens de pagamento e atualização de status da ordem.

Colocar todos os times para mexerem juntos no carrinho de compras é um erro, e é um pensamento extremamente waterfall. É um pensamento que diz “vou fazer tudo que há pra ser feito desta funcionalidade pra nunca mais ter que voltar nela”. O objetivo deste tipo de mindset é terminar o projeto, e não fazer um produto incrível.

estratégia ágil (iterativa) x estratégia waterfall (incremental)

Para escalar Ágil, é necessário olhar para o produto, identificar os alicerces básicos do mesmo e se questionar: qual é o mínimo de cada um destes alicerces que eu preciso para validar uma hipótese? Desta forma, você vai ter, para um dado e-commerce, um time trabalhando no produto mínimo viável (MVP) de cadastro, outro no MVP de conteúdo, outro no MVP de carrinho de compras, e por aí vai.

Este tipo de estratégia garante que cada time seja dono do seu pedaço do produto, e que um git merge não seja a reencenação de 300. Alinhando os objetivos cross-times, se torna perfeitamente possível garantir releases que façam sentido entre si, e colaboração intra e extra-times. É como fazer vários cupcakes em vez de colocar múltiplos times para trabalhar no mesmo bolo.

Uma vez estabelecida a estratégia de produto, partindo da premissa que os times vão trabalhar com scrum, é possível puxar um (ou mais) membro de cada time para formar um time scrum que tenha seu próprio SM. Este time vai debater integrações e impedimentos, e alinhar o que é necessário fazer pelo time a nível de corporação. Além dele, deve haver um time de POs, cada qual representando seu segmento de produto, que alinham estratégia de negócios com um PO cross.

Esta estrutura pode ser escalada quantas vezes for necessário, podendo inclusive ser aplicada a nível de organização, e pode substituir de forma muito mais eficiente o cenário que vemos hoje, de empresas hierarquizadas que usam ágil só para execução, e não para estratégia.

Para saber mais, dê uma olhada no Scrum@Scale, aqui.

Siga a tag codelikeagirlBR para ver nossos posts! 😀

Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.