Nesses anos em que tenho trabalhado com métodos e práticas ágeis, tenho observado diversas composições e formatos de times (comumente chamados de squads, talvez por influência do modelo Spotify). De forma geral, muitos aspectos e características dessas equipes se repetem, tais como:

• A utilização de métricas ou indicadores;
• Algum formato ou técnica de decomposição de objetivos em partes menores;
• A ocorrência de eventos periódicos.

Enfim, esses são apenas alguns exemplos comuns. E, fazendo uma análise bem enxuta, isso tudo parece muito bom! Há muitos conceitos ágeis por trás dessas características, como, por exemplo, a auto-organização de times, a melhoria contínua, o alinhamento estratégico, entre outros.

Estruturando um Time Ágil

Pensando nisso, resolvi compartilhar com vocês um exemplo genérico, e relativamente simples, para estruturar processos e práticas em times ágeis. Um time considerado ágil provavelmente terá uma estrutura semelhante a essa:

A composição de um time ágil deve, na minha opinião, contemplar as seguintes esferas:

• Ambiente interno: o fluxo de desenvolvimento e suas particularidades;
• Ambiente externo: entregar valor para seus usuários e/ou consumidores;
• Análises qualitativas: melhorar continuamente e compreender/atender os feedbacks de clientes;
• Análises quantitativas: coletar dados do seu processo e tangibilizar opiniões externas.

Mas não se apegue aos exemplos específicos do desenho, mas sim ao conceito atrelado a eles. Vou explicar rapidamente, com um pouco mais detalhes, cada pedaço deste exemplo. Vamos lá!

OKR e Story Mapping

Tanto os OKRs (Objetivos e Resultados-Chave, do inglês Objectives and Key Results) quanto o User Story Mapping (Mapeamento de Histórias de Usuário) são muito utilizados por times ágeis. Mas, a ideia aqui não é necessariamente utilizar ambos, mas sim compreender que, de alguma maneira, sua empresa tem que possuir a capacidade de criar objetivos para o negócio e decompor eles em partes menores (entregáveis).

Ou seja, baseado no Planejamento Estratégico da organização, por exemplo, criar um processo de decomposição até que o time desenvolvedor do projeto consiga atrelar o que estão entregando com o que a empresa espera de resultados de negócios. Em outras palavras, o time estará trabalhando na esfera da eficácia (fazendo as coisas certas). Dessa maneira, haverá alinhamento e a empresa conseguirá conceder autonomia para os times, sem o risco de as entregas não responderem às necessidades do negócio. Para entender melhor o conceito de alinhamento e autonomia, sugiro a leitura do blogpost O desafio de analisar a maturidade ágil de uma empresa, escrito por Raphael Albino.

Para conhecer mais sobre OKRs, framework criado pelo ex-CEO da Intel, Andrew Grove, sugiro a leitura do blogpost Dilemas de PO: como definir OKRs em equipes ágeis, escrito novamente por Raphael Albino. E, se você deseja entender mais sobre Mapeamento de Histórias de Usuário, técnica criada por Jeff Patton, recomendo a leitura do blogpost Vamos falar sobre Story Mapping, escrito por Felipe Gimenes.

Utilização de Kanban e eventos do Scrum

É extremamente provável que você já conheça o método Kanban e o framework Scrum. Caso contrário, sugiro a leitura do e-book gratuito Kanban em 10 Passos, escrito por Jesper Boeg, como também do Guia do Scrum, mantido por seus criadores Ken Schwaber e Jeff Sutherland.

Você pode, sem dúvidas nenhuma, utilizar as práticas mencionadas acima de forma integral. Porém, assim como no tópico anterior, a ideia não é dizer que, necessariamente, você precisa utilizar ambas as práticas, total ou parcialmente, para formar um time ágil. O objetivo aqui é: estruture uma forma de gerenciar seu fluxo de desenvolvimento e tenha um mecanismo de melhoria contínua. Para isso, eu costumo utilizar o método Kanban, movendo as histórias de usuário de etapa em etapa, bem como as reuniões diárias para alinhamento contínuo/constante e retrospectivas para melhoria contínua. E, se necessário, algum processo de validação interna de entregas (comum quando temos muitas integrações no sistema ou homologações de parceiros externos, por exemplo).

Mas, independentemente do método, framework, modelo ou metodologia utilizada, é sempre oportuno lembrar que você precisa procurar qual é o melhor conjunto de práticas que se adequa ao contexto do time. Como opinião, o método Kanban e o framework Scrum, bem como uma forma híbrida de ambos, sempre são boas opções para considerar nessa análise e respectiva escolha.

Métricas (WIP, Lead time e Throughput)

Gosto muito dessa famosa frase de William Deming (1900-1993): “Não se gerencia o que não se mede”. E, principalmente se você estiver escolhido o método Kanban para gerenciar seu fluxo de trabalho, é extremamente recomendável que você limite seu trabalho em progresso, o famoso WIP (Work in Progress). Este, aliás, é um dos princípios do Kanban. Para entender mais sobre o aperfeiçoamento do seu fluxo de desenvolvimento, recomendo a leitura do blogpost 5 Estratégias para otimizar o fluxo de desenvolvimento de software, escrito por Wesley Zapellini.

Ao limitar o WIP, você conseguirá trabalhar com outras métricas. Neste caso, consigo destacar o Lead time e o Throughput. Entender a relação da média dessas três variáveis é muito importante, pois, ao limitar o trabalho em progresso (WIP), você potencialmente conseguirá entregar mais rápido (em outras palavras, diminuirá seu Lead time). A compreensão da relação dessas variáveis surgiu em um estudo do início da década de 60, quando o professor John Little e Stephen Graves publicaram um artigo pelo Massachusetts Institute of Technology (MIT) chamado Little’s Law, ou Lei de Little. Nós, da Plataformatec, falamos um pouco disso na parte 1 do episódio “A relação entre Lead time, WIP e Throughput”, do ContÁgil Podcast.

Entretanto, seguindo o mesmo raciocínio dos casos anteriores, trabalhar com WIP, Lead time e Throughput é apenas uma – ótima – opção. O recado aqui é: tenha um sistema de medição que consiga produzir e coletar dados confiáveis, com o objetivo de compreender e melhorar continuamente seu formato de trabalho, e, por consequência, melhorar seus resultados de forma contínua.

Para finalizar, recomendo a leitura do blogpost 12 Erros comuns no uso de Métricas de Processo, escrito por Lucas Colucci. Neste texto há dicas que irão lhe ajudar a evitar erros que podem prejudicar a análise de seus dados.

Features e entrega de valor

Entregar valor. Essa talvez seja a parte mais difícil de rodar na prática. Como garantir, por exemplo, que as entregas dos times estão efetivamente entregando valor para seus clientes? E o que é exatamente valor?

Se você procurar pelo significado desta palavra, provavelmente encontrará várias definições. Eu, particularmente, gostei muito de uma das definições apresentadas pelo Dicio (Dicionário Online de Português): “Qualidade que faz com que algo se torne importante para alguém.”

Portanto, antes de entregar é preciso compreender o que é o valor para esse alguém (no caso, seu cliente). Tente responder essas perguntas:

• O que seu cliente realmente valoriza?
• O que o cliente espera de seu produto e/ou serviço?
• Quais são as expectativas de seu cliente?
• Qual(is) problema(s) seu produto e/ou serviço está resolvendo?

Se você consegue responder essas perguntas, provavelmente entendeu o que é valor para seu cliente. À partir disso, tudo fica mais fácil: garanta que as features (entregas) de seu time estão alinhadas com as respostas dessas perguntas. E, se você montou corretamente a primeira parte do exemplo de estrutura de um time ágil, a de criar objetivos para o negócio e decompor eles em partes menores (entregáveis), você provavelmente conseguirá isso. Claro que há uma premissa aqui: seus objetivos de negócio estão atrelados com o que o mercado (seu cliente) está demandando de produtos e/ou serviços.

Como dica complementar, recomendo a leitura do livro Sprint. O Método Usado no Google Para Testar e Aplicar Novas Ideias em Apenas Cinco Dias, escrito por Jake Knapp, John Zeratsky e Braden Kowitz. Eu tive a oportunidade de participar de um processo de concepção de produto baseado neste modelo do livro e, sem dúvida nenhuma, foi uma ótima experiência. Se você conseguir compreender seu cliente, é muito provável que irá entender o que é valor para ele e, dessa forma, entregar features compatíveis com esta situação.

Feedbacks estruturados

Por fim, a última parte da composição de um time ágil é, na minha opinião, a capacidade de conseguir coletar feedbacks qualitativos e quantitativos do ambiente externo, neste caso, seus clientes. Você não precisa apenas de um mecanismo interno de melhoria continua do seu processo de desenvolvimento, mas também de um externo.

O feedback qualitativo pode ser obtido através de formulários, pesquisas de opinião, entrevistas com seus clientes, enfim, de diversas maneiras. O importante não é só obter, mas agir com base nestes feedbacks. Essa talvez seja a parte mais importante: se você ouvir o cliente e não fizer nada a respeito, você poderá errar em dobro: eventualmente entregará features equivocadas e não agirá perante os feedbacks colhidos.

Mas como medir se suas ações estão efetivamente surtindo efeito ao longo do tempo? Uma forma de fazer isso é transformar os feedbacks em dados tangíveis (números). É muito complicado observar feedbacks qualitativos de, por exemplo, 1 ano atrás e verificar se os atuais estão melhores do que os antigos. Além de complexo e trabalhoso, a interpretação do avaliador também pode afetar o resultado, podendo se transformar em algo subjetivo. Logo, tenha também um mecanismo de medição numérica.

Uma forma interessante de obter feedbacks via dados é utilizando o Net Promoter Score (NPS), metodologia criada por Fred Heichheld. Nela, seu cliente responde, de 0 a 10, a possibilidade dele recomendar seu produto e/ou serviço para outra pessoa. Ao longo do tempo, você poderá, por exemplo, comparar os valores obtidos há 1 ano com os valores que estão sendo obtidos atualmente.

Se você trabalha com aplicativos, os valores de avaliação mostrados na própria página de download (geralmente de 1 a 5) também são interessantes de registrar (mensalmente, bimestralmente, enfim, em uma periodicidade que seja relevante para seu negócio). E, ao longo do tempo, você poderá comparar se as avaliações estão melhorando ou piorando. Com isso, é provável que você consiga verificar se suas entregas estão efetivamente respondendo ao valor esperado por seus clientes.

Resumindo

Se você está gerenciando seu fluxo de desenvolvimento com a limitação do trabalho em progresso, você potencialmente entregará em um tempo menor e, por consequência, obterá feedbacks dos clientes mais rapidamente que, por sua vez, realimentarão seus objetivos. Se você conseguiu entrar neste ciclo, parabéns, seu time provavelmente está sendo ágil!

Resumindo todo o raciocínio deste blogpost, para conseguirmos estruturar um time ágil, precisaremos, na minha opinião, das seguintes características:

• Possuir a capacidade de criar objetivos para o negócio e decompor eles em partes menores (entregáveis);
• Estruturar uma forma de gerenciar seu fluxo de desenvolvimento e manter um mecanismo de melhoria contínua;
• Ter um sistema de medição que consiga produzir e coletar dados confiáveis sobre seu processo de desenvolvimento;
• Garantir que as entregas de seu time estão alinhadas com o valor esperado por seus clientes;
• Conseguir coletar feedbacks qualitativos e quantitativos de seus clientes.

Feedbacks sobre o texto? Por favor, fique à vontade para comentar. Vamos trocar experiências!