Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Fazendo ágil com mindset waterfall

O que pode dar errado?

Agilistas, vocês provavelmente vão querer um álcool gel pra acompanhar esse texto. Mindset é uma parada que infecta, e tem que ser analisado com cuidado, senão pega.

A verdade incômoda é que o mindset ágil é utópico por natureza. Sempre dá pra ser melhor, sempre dá pra ser mais autogerenciável, e o Scrum Master nunca se vai se desnecessário, desculpa aí.

Pensar ágil envolve diretamente encarar nossas falhas e tudo que ainda temos que melhorar. E, no entanto, é frequente que pessoas trabalhando em times ágeis recaiam para o mindset waterfall. Recentemente, tive uma conversa com o Scrum Master do meu time sobre isso, e chegamos à conclusão que, deixado em inércia, qualquer cliente ou time começa a pender para o waterfall (ou para o caos). Não por demérito, mas simplesmente porque são muitos anos à mercê deste mindset, e old habits die hard. Precisamos nos desafiar constantemente, provocar constantemente para que um efetivo processo de inspeção e adaptação, de melhoria contínua, efetivamente se instale.

Ágil é esforço contínuo. É simples, mas não é fácil.

E isso é chato, gente.

É cansativo manter esta tensão, nunca relaxar, estar sempre vigilante. Mas é nisso que acreditamos.

Continuous Discovery, essa frescura

Eu sento com o stakeholder, ele me explica o escopo, o PO detalha e o time faz, certo? É só fazer, não?

Sei que é difícil lidar com stakeholders que cismam em dizer que já sabem a solução, mas para isso tem uma coisa linda chamada dinâmicas de consenso. O que acontece boa parte do tempo é que o conhecimento necessário para criar uma hipótese de produto está na cabeça dos stakeholders e do time, e precisa de uma retroescavadeira pra tirar isso de lá e plotar num quadro de forma racional. As dinâmicas de consenso vêm justamente como um saca-rolhas, e expõem as informações que todos os stakeholders têm mas não falam. Elas botam as ideias no quadro e pedem aos próprios stakeholders para iterar e consensar o que será construído.

Isso feito, você tem um Backlog inicial, mas nada garante que o curso que você traçou no início vai se manter. Pra isso tem pesquisa, coleta de dados, feedback com usuários, teste a/b e muitas outras ferramentas.

E adivinha? Você terá que repetir alguns exercícios de consenso à medida que os testes de usuários vão gerando novo conhecimento.

OKRs e a síndrome de Dorothy

Acho que não estamos mais em Kansas, Totó. Voce recebeu a incumbência de construir um produto, e o que você faz? Você pergunta pro stakeholder/usuário o que ele quer, certo?

Errado.

Se você seguir por este caminho (extremamente waterfall, a propósito), de cara você está abrindo mão de duas coisas importantes.

– do empirismo

– da compreensão do porquê

64% de todo o software construído é utilizado raramente ou nunca. Não tenho dúvidas de que teve alguém que pediu aquilo. O problema é que teve alguém que executou sem perguntar o porquê. E, frequentemente, esta é a mesma pessoa reclamando que o usuário não sabe o que quer.

Porque adivinha, ele não sabe mesmo. Ou melhor… Ele sabe o que quer, mas não sabe do que precisa. E quando você mostra pra ele o que ele pediu, ele descobre que não era bem daquilo que ele precisava, e não usa. Ora,

se o usuário não sabe se o que ele quer é do que ele precisa, quem é você pra saber?

Você precisa do empirismo para, por tentativa e erro, descobrir qual é a necessidade que você precisa atender e como.

Para isso, você estabelece alguns (poucos) objetivos, e métricas para cada objetivo. Você *não* precisa fazer o roadmap baseado em features, e sim em hipóteses a validar com base no objetivo que você está perseguindo.

Keep calm e mostre métricas

Como lidar com os stakeholders ensandecidos que estão sempre inseguros sobre o que o time está fazendo, ou em quantas features (elas de novo) o time entregou?

Mostre métricas. Defina métricas de esforço (pontos em Fibonacci por exemplo) e métricas de valor para o seu produto (como RUT). Defina uma frequência curta (toda review, por exemplo), e mostre o acompanhamento dessas métricas ao longo do tempo. Direcione para que eles cobrem as coisas certas (valor agregado e atingimento dos OKRs) e desviem das erradas (cobrar velocidade do time como forma de pressão para aumentar o volume de entregas).

É perfeitamente viável manter o mindset ágil, mesmo quando a tendência é recair ao waterfall. O maior desafio começa em você, ao definir sua estratégia de produto usando um mindset ágil, evitando a armadilha de uma execução ágil com estratégia waterfall.

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.