4 armadilhas da agilidade que podem atrasar seu produto
No dia a dia das empresas de desenvolvimento de software são raras as equipes que hoje não estão trabalhando com metodologias ágeis, não é verdade? Algumas trabalham com Scrum, com seus time boxes bem definidos, velocidade do time sendo acompanhada de perto, cerimônias funcionando de vento em popa. Outras preferem o Kanban, colocando no fluxo o que o limite de WIP do time nos permite, puxando todas as tarefas para o objetivo final da entrega e estando sempre muito bem tunados nas suas métricas de Throughput e Cycle time.
Mas será que estamos seguindo as melhores práticas? Hoje vim compartilhar aqui algumas armadilhas que muitas vezes caímos quando trabalhamos com metodologias ágeis, algumas que nós até podemos saber que estamos caindo, mas acabamos não tomando ações para sairmos delas.
Para começar, vamos pensar num cenário de uma empresa fictícia, mas muito comum no nosso dia a dia de desenvolvimento de software. Imaginemos uma empresa que trabalha com vários times em paralelo e que juntos eles têm um objetivo em comum, desenvolver e manter um produto [ou algumas classes de produtos] que traz[em] valor para os clientes.
A empresa pensa em melhoria contínua e colocou como meta uma missão clara: diminuir o time to market (o tempo da funcionalidade ser concebida até estar disponível para o cliente). A meta foi apresentada para todos na empresa, que de imediato enxergaram que faz total sentido. — Vai ser moleza, nós trabalhamos com agilidade, melhoria contínua e nossas métricas estão muito bem definidas, conseguiremos melhorar o time to market do nosso produto em algumas iterações — A expectativa é que trabalhando com agilidade iremos diminuir o time to market.
Mas será que o fato de ter a metodologia definida já garante que os objetivos que a empresa deseja estão sendo cumpridos ? As pessoas do time sabem que objetivos são esses? Mas qual o objetivo mesmo?Ah, time to market, não vamos esquecer!
Pensando nisso vejamos abaixo algumas das armadilhas que muitas vezes nossos times caem, sem percebermos [ou fingindo que não percebemos], e que são verdadeiros problemas para não atingirmos o tão sonhado time to market dos projetos.
Armadilha 1: Pensar em mudanças no processo e esquecer do que será entregue
E isso acontece com bastante frequência: Assim que a gerência decide que dailies, retros, equipes multifuncionais, etc., são os requisitos para atingir seu objetivo, a implementação da metodologia ágil passa a ser a própria meta.
Leopold, Klaus. Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility(tradução nossa)
Muitas vezes estamos tão envolvidos no que a metodologia pede, que torna-se mais importante cumprir os seus passos do que o projeto em si. Estar puxando novas atividades no quadro, fazendo reuniões cadenciadas ou respeitando o time box, não é suficiente para que o valor seja adicionado ao produto, se também não estivermos focados em encontrar o que de fato trará valor para o nosso cliente.
As mudanças no processo puxam as mudanças dentro do time. Saímos distribuindo os mais diversos papéis e responsabilidades: um scrum master para essa função, um product owner para aquela outra, agile coaches, service delivery managers… cada um atuando na sua função dentro de um projeto, mas muitas vezes sem ter uma visão maior de como aquilo vai impactar a empresa como um todo.
A empresa no início tinha um objetivo, aumentar o time to market dos produtos que desenvolve, mas agora se olharmos dentro de cada um dos times o que temos são várias pessoas bem mais preocupadas com o processo do que com a entrega de valor para os nossos clientes.
Armadilha 2: Não lidar com as dependências no time
Quando vários times trabalham para um objetivo e um produto em comum, tão importante quanto buscar a melhor performance dos times é estar em alinhamento com as dependências que existem entre eles.
Um produto, várias equipes. Em alguns casos, uma equipe trabalha apenas em um produto. No entanto, muitas vezes são necessárias várias equipes para um produto. Isso cria dependências entre as equipes.
Leopold, Klaus. Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility(tradução nossa)
Trazendo uma comparação com a figura abaixo, imaginem se cada time representasse uma tecla no teclado. No momento que vamos escrever um texto [o objetivo em comum de todas as teclas juntas] não adianta se o time responsável pela tecla A é super rápido, e os demais, responsáveis pelas outras, não serem. O impacto no todo é mínimo quando focamos num único time, buscar o equilíbrio entre as equipes que estão trabalhando no produto, para que todos caminhem sincronizados, talvez seja um dos trabalhos mais difíceis de orquestrar numa companhia.
Armadilha 3: Não mapear todas as etapas do processo
A eficiência de fluxo denota a proporção de tempo em que o trabalho ativo está sendo realizado dentro do cycle time total de uma peça de trabalho.
Leopold, Klaus. Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility(tradução nossa)
Quais são as etapas de seu processo? Qual o tempo de trabalho em progresso de cada atividade? Muitas pessoas esquecem de mapear os momentos de espera de uma atividade, e muitas vezes é onde temos mais gasto de tempo e oportunidades de melhoria. Para o cliente, não importa se entre o desenvolvimento e o teste daquela funcionalidade o trabalho [ticket] ficou 2 dias numa fila, ele quer saber porque que a funcionalidade atrasou 10 dias para entrar e produção. Estar atento a esses momentos de fila e tentar diminuí-los para atingir uma melhor eficiência é essencial para melhorarmos o time to market. E é ao colocarmos isso exposto para todos do time que conseguiremos iniciar um processo de eliminação das filas. Não podemos considerar que filas não existem, elas devem estar sempre visíveis para o nosso time e é nessa exposição dos problemas que vamos enxergar os pontos de melhorias!
Armadilha 4: Não limitar o trabalho em paralelo -WIP
Essa armadilha é transportada muitas vezes da nossa vida para o trabalho. Sempre temos várias coisas acontecendo a todo momento e a nossa tendência é querer paralelizar para terminarmos tudo que nos é exigido.
O problema em muitas empresas é que elas têm muito trabalho em andamento que não faz nenhum progresso.
Leopold, Klaus. Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility(tradução nossa)
Limitar o trabalho em processo (ou trabalho em progresso) é uma tarefa difícil de alcançar e muitas vezes difícil de ser entendida como algo que vai aumentar a produtividade de um time. Para tentar demonstrar que limitar o WIP pode ser algo vantajoso, vamos a um exemplo simples. Imagine que para um determinado projeto, 3 tarefas precisam ser feitas e entregues ao cliente. Nesse projeto [imaginário] temos apenas uma pessoa no time e cada tarefa tem duração de 5 dias [sim… é um exemplo estranho, mas vai servir para a nossa demonstração].
Uma primeira abordagem será de limitar o WIP para 1 atividade por vez, ou seja, ao iniciar uma atividade o nosso colaborador só poderá pegar outra quando a atual for finalizada. Pensando que não temos desperdícios no nosso projeto imaginário as entregas das atividades seriam:
No final do 15º dia o cliente teria todas as atividades entregues, mas ele também pode desfrutar das funcionalidades no 5º e 10º dia do projeto, já que cada uma das nossas tasks são independentes [ou deveriam ser].
Agora vamos aumentar o nosso WIP para 3. Dessa forma, o colaborador conseguirá trabalhar com algumas atividades em paralelo. Dado que no nosso exemplo [e talvez na vida] o colaborador não é multithread, ou seja, não consegue trabalhar em duas coisas ao mesmo tempo, vamos dividir de uma forma que a cada dia ele trabalhe em uma das 3 tasks que ele colocou In Progress, como na figura abaixo:
Veja que da mesma forma, as 3 atividades são entregues no 15º dia (não estamos levando em consideração aqui as perdas que existem ao trocarmos o contexto das atividades), mas olhando tarefa a tarefa enxergamos vantagem pelo menos nas duas primeiras tarefas, que quando o WIP era 1 foram entregues bem antes:
Atividade A — Cenário 1 entregue no 5º dia vs. cenário 2 entregue no 13º dia
Atividade B — Cenário 1 entregue no 10º dia vs. cenário 2 entregue no 14º dia
Atividade C — Ambos cenários entregue no 15º dia
Isso não significa que sempre ter um WIP de 1 é o melhor dos mundos, cada projeto tem suas características e a composição do time pode interferir muito em todos esses cálculos. Além de fatores externos, como um stakeholder trazendo novas atividades para entrarem no nosso sistema alterando o escopo do produto. Mas o que queremos trazer aqui é que temos que ter essa atenção para começar menos e terminar mais as nossas atividades e ter um limitador no que diz respeito a trabalho em processo (WIP) pode ser uma ótima ferramenta para não cairmos nessa armadilha.
Para quem gosta de uma explicação mais matemática, vale a pena dar uma olhada na Little’s Law. Vou deixar os detalhes da Little’s Law para vocês darem uma googlada e verem as várias referências dela para os mais diversos cenários. Um que achei legal foi esse aqui, que explica como pode ser aplicada para melhorar o fluxo num trailer de tacos :)
Bem pessoal, espero que tenham gostado, trouxe aqui algumas armadilhas, já as forma de nos livrarmos delas são as mais diversas e ficarei muito animado em discuti-las com vocês nos comentários ou quem sabe num próximo post. No desenvolvimento de software cada dia mais é exigido que os times não só entreguem software funcionando (como nos traz o manifesto ágil), mas também que os negócios que aquele software se propõe a resolver estejam sendo resolvidos de fato. Não é à toa que grande parte dos projetos ágeis acabam abandonando a definição de metas em suas sprints/iterações, porque os objetivos acabam se tornando sempre entregar o que foi prometido e nem nos preocupamos com o impacto daquilo que estamos fazendo. É buscando a melhoria contínua, estando atento às armadilhas que o dia-a-dia nos traz e tendo como objetivo buscar as melhores soluções para os clientes que nos tornaremos times cada vez melhores!
Um abraço e até a próxima.
