O modelo padrão dos métodos ágeis e suas limitações para times analíticos
Este artigo foi escrito por Jonas Fernades, data analytics manager na QuintoAndar, especialmente para a ebdi.
Como trabalhar com métodos ágeis em times analíticos?
Usualmente, no universo de tecnologia nos pautamos pelos métodos ágeis de trabalho: SCRUM e Kanban, com os seus Épicos e Stories, suas Sprints e Retros.
Diversos rituais fazem parte destes modelos de trabalhos. Contudo, os modelos foram predominantemente pensados para times que tinham por objetivo construir algo, seja um carro, um software ou qualquer outro produto.
Isso implica que estes modelos de trabalho podem ser mais facilmente replicados em algumas situações do que em outras.
No caso dos times de análise de dados, em especial aqueles que são muito conectados com o negócio e suporte, a tomada de decisão e os entregáveis não são tão palpáveis e objetivos quanto os entregáveis dos time de Engenharia de Software, por exemplo.
O que entregamos são “decisões” e fazemos isso nos comunicando com os decisores.
Os artefatos (como relatórios, dashboard e outros documentos) são apenas a mídia para aquilo que queremos entregar, o valor obtido do trabalho é resultado de um processo e não da entrega em si.
Em comparação com outros times, isso torna os entregáveis dos times de suporte a tomada de decisão bem mais subjetivos.
A boa notícia é que os métodos ágeis são insistentes em postular a sua adaptação a diferentes necessidades. Os autores sempre provocaram essa reflexão em tudo o que pude ler.
No caso do times de Data Analytics temos algumas questões iniciais.
Questões para times analíticos:
I) O dinamismo é inerente ao processo:
Dificilmente conseguimos trabalhar com um escopo de trabalho fechado, o fluxo do dia a dia tende a ser muito dinâmico e precisamos estar atentos para priorizar, repriorizar ou despriorizar de acordo com a decisão que precisa ser tomada naquele momento.
II) Incerteza em relação à complexidade das tarefas:
Pode ser muito difícil mensurar a complexidade das tarefas, mesmo para os mais experientes. E esta dificuldade costuma ser maior em tarefas mais exploratórias. Logo, dizemos que todas as tarefas contém algum nível de incerteza.
Uma tarefa simples pode se tornar complexa ao descobrirmos algo que não esperávamos.
Ou ainda, uma tarefa complexa pode ser refutada com velocidade se as premissas não se confirmarem, tornando-se simples.
Por mais que tenhamos experiência e domínio sobre o contexto e negócio, surpresas tendem a ser frequentes (em especial trabalhando em startups). Assim, estimar o tamanho da task pode ser traiçoeiro.
III ) O fluxo de trabalho não costuma ser linear:
A continuidade linear das tarefas não pode ser presumida. Na dinâmica de priorização você pode ter que parar tudo e se dedicar a uma tarefa urgente.
IV) A relação de continuidade entre tarefas nem sempre se aplica:
Em um volume relevante de tarefas não há uma continuidade do assunto ou desdobramento da tarefa inicial. Nem sempre estamos construindo um muro tijolo a tijolo, as vezes estamos só tirando, colocando ou mudando de lugar os tijolos do mesmo muro.
Possivelmente existem algumas outras questões que dificultam a aplicação em um padrão mais comum dos métodos ágeis a times analíticos, não quis ser exaustivo, apenas pontuar aquelas que na minha experiência mais nos causaram dificuldades.
Partindo destas questões, entendemos que algumas premissas principais precisam ser contempladas para melhor performance dos times analíticos em modelos de trabalho ágil.
Quais são as performances para trabalho ágil?
I) Os ciclos de trabalho:
Devem ser abertos e permitir a entrada de tarefas no meio do ciclo.
II) A guerra das prioridades deve ser pacificada:
Deve-se criar formas para que o time consiga permanecer focado no que é importante, e não somente no que é urgente.
III) A temporalidade dos ciclos de trabalho deve forçar um limite para o tamanho das tarefas:
Mas ao mesmo tempo contemplar incertezas da sua natureza.
Dado este contexto, como criamos um modelo ágil adaptado para times analíticos?
Ágil, à nossa maneira
Uma vez conhecidos os problemas e premissas que devem nortear uma adaptação dos métodos ágeis para time de análise de dados para suporte à tomada de decisão vamos entender como isso se deu na prática para nós.
Ao tentar desenhar um modelo de trabalho para o time, estudei com mais atenção o SCRUM e o Kanban.
Li bastante a respeito, e as minhas principais fontes foram os livros: Lean Startup e SCRUM — A arte de fazer o dobro do trabalho na metade do tempo, além de artigos variados sobre o tema.
Analisando com o time as nossas possibilidades, desejos e limitações ficou claro que a melhor opção era uma combinação funcional entre os ciclos de trabalho do SCRUM, mas com o controle de produção do Kanban.
Ou seja, optamos trabalhar em ciclos de tempo definidos com um backlog de tarefas a serem priorizadas, e comunicamos o status da produção usando um painel do tipo Feito / À Fazer / Em Revisão e Concluído.
Definimos, então, que teríamos um backlog onde poderíamos registrar as tarefas que precisamos realizar, priorizamos entre elas quais são possíveis de ser alocadas na sprint e realizamos o status de cada um e seus responsáveis no painel (board).
Na sequência, ao pensarmos sobre a temporalidade dos ciclos de trabalho entendemos que o intervalo de 15 dias era o ideal.
Com base em nossas experiências anteriores notamos que a dinâmica de priorização acabava deixando algumas tarefas por concluir em ciclos de uma semana.
Já com ciclos um pouco mais largos acabam sendo mais flexíveis para acomodar esse vai e vem de prioridades.
Pensando nas cadências do Kanban ou rituais do Scrum, tínhamos alguns em vista para nossa rotina de acompanhamento: uma reunião de planejamento semanal, uma retrospectiva mensal e reuniões de sincronia com os stakeholders com frequência variada a depender da necessidade.
O fluxo de trabalho em alto nível é:
Nas reuniões de sincronia com os clientes internos falamos sobre as demandas a serem atendidas e a prioridade delas.
A partir daí incluímos as tarefas nos backlog e entendemos a nossa capacidade de realizá-las de acordo com o volume e complexidade.
Por fim, realizamos o planejamento semanal em dois ciclos: na primeira semana da sprint, tentamos contemplar o maior volume de tarefas às quais iremos nos dedicar nos próximos 15 dias; na segunda semana, acompanhamos a evolução, entendemos o que entrou e o que terá de ficar de fora para concluirmos a sprint.
Vulgarmente falando, o objetivo primário é terminar com o menor volume possível de tarefas não iniciadas, um volume saudável de tarefas em progresso e o maior volume possível de tarefas concluídas.
Ao longo do processo mantemos comunicação constante com os stakeholders e informamos prazos, progressos, premissas adotadas e resultados. Tudo é feito de forma iterativa.
Acompanhando e medindo resultados.
Nós usamos o Jira, que nos permitiu criar os tipos das tasks no board, onde cada tarefa aberta deve ter um tipo correspondente, conseguimos acompanhar essas métricas utilizando uma planilha com uma extensão do Google Sheets.
Já para as métricas de produtividade, os relatórios do Jira não atenderam às nossas necessidades. Para tanto criamos uma planilha de acompanhamento. Assim, podemos formatar um dashboard ou mesmo uma apresentação onde vemos as métricas.
Ao acompanhar a produtividade considerando as seguintes métricas principais:
- Volume de tarefas no início da sprint
- Volume de tarefas ao final da sprint
- Volume de tarefas concluídas
- Percentual de tarefas planejadas no começo da sprint (sobre o total de tarefas da sprint)
- Percentual de tarefas concluídas do total de tarefas ao final da sprint (sobre o total de tarefas da sprint)
Os volumes de tarefas nos permitem entender o quanto estamos produzindo, entregando e planejando.
Ao mesmo tempo os percentuais nos dizem sobre o quão eficientes somos em planejar as tarefas no início da sprint e assim conseguir ter uma dinâmica de trabalho mais eficaz e o quanto concluir as tarefas que entraram na sprint.
Por outro lado, temos algumas métricas que nos permitem balizar a saúde da sprint:
- Percentual de tarefas por fazer no último dia da sprint (sobre o total de tarefas da sprint)
- Percentual de tarefas em progresso no último dia da sprint (sobre o total de tarefas da sprint)
Acompanhar os percentuais de tarefas por fazer e em progresso no último dia da sprint nos permite controlar o quanto vai ser empurrado para a próxima sprint e também a cadência do time, o ideal é que exista um baixo percentual de tarefas por fazer e que as tarefas em progresso sejam somente um volume saudável para que o time não fique ocioso nos momentos finais da sprint, de forma a não engargalar o início da próxima sprint.
Por fim, temos algumas métricas auxiliares que ajudam o time a se organizar e entender quando estamos descolando dos níveis de produtividade:
- Proporção de tarefas concluídas por número de pessoas no time
- Proporção de tarefas concluídas por número de dias trabalhados na sprint
Entender a proporção de tarefas concluídas por número de pessoas no time nos ajuda a entender a nossa capacidade de produção média por pessoa, bem como entender se estamos sub-aproveitando ou sobrecarregando o time.
Já a proporção de tarefas concluídas por dias trabalhados ajuda o próprio time a ter um balizador médio para prazos, o que ajuda especialmente os novos contratados e analistas com menos experiência no contexto a dar prazos para os stakeholders.
Enfim, os resultados:
O modelo que formulamos atendeu às nossas necessidades e expectativas. Com o passar do tempo fomos aprendendo a melhorar alguns detalhes, adotando novas práticas e deixando outras de lado. Tudo pode mudar e variar de acordo com o momento e necessidade do time.
Aprender a acomodar demandas que entram em diferentes momentos da sprint, trabalhar com um paralelismo sadio e conseguir ter tempo para desenvolver demandas maiores sem ser tão impactado por bloqueios de tempo (na ordem de poucos dias) foram alguns do fatores de sucesso que levaram a um nítido aumento na produtividade e capacidade de priorização.
O time passou a ter clareza de tudo que deveria concluir, se planejar para tanto.
Outros resultados que colhemos foi a melhoria na nossa orientação a problemas (problem-solving).
A divisão em ciclos de tempo forçou o time a quebrar grandes projetos em tarefas pequenas e médias que cabiam dentro da sprint, ao mesmo tempo ao fazer isso acabou reforçando a mentalidade de resolução de problemas para cada tarefa:
Qual problema queremos resolver com essa tarefa?
Ela realmente atende ao problema que estou tentando resolver?
Nós também experimentamos e erramos bastante também ao longo do processo. Inicialmente tivemos dificuldades de comunicar o processo aos nossos stakeholders e fazê-los entender a cadência das entregas, isso foi resolvido reforçando os rituais de alinhamento.
Além disso, tentamos usar a funcionalidade de stories do Jira de algumas formas diferentes, até conseguirmos encontrar uma forma que nos atendesse para conseguirmos agrupar todas as tarefas de um grande projeto em um único bloco.
Testamos também algumas funcionalidades adicionais do Jira, mas elas não são indispensáveis em nosso modelo de trabalho. Sugiro entender com o time e utilizar de acordo com a necessidade.
Para identificar pontos de melhoria, acompanhamos os resultados das métricas no fechamento da sprint e vemos a sua evolução dentro do trimestre.
E mensalmente, vemos a evolução anual dos resultados consolidados por mês em nosso ritual de retrospectiva. Mais uma vez reforço, a utilização de métricas torna todas as discussões bem mais objetivas.
O início e desenvolvimento do processo se deu no escritório, antes do trabalho remoto ser adotado para 100% no momento de pandemia. No contexto de trabalho remoto, o fluxo se mostrou ainda mais necessário.
O fluxo de trabalho já estava um tanto consolidado e com alguns ajustes conseguimos aprimorá-lo considerando a nova realidade do trabalho remoto.
Os rituais de planejamento facilitaram a comunicação do time, alinhamento de prioridades e mantinham cientes da evolução do trabalho.
Uma das adaptações que adotamos no contexto de trabalho remoto foi criar uma pauta que comunicasse dentro e fora do time quais eram as tarefas críticas que precisavam ser concluídas naquela semana.
Por fim, gostaria de deixar o convite para compartilhar as experiências de aplicação de métodos ágeis em times analíticos.
Estou empolgado em conhecer novidades. Além disso, deixo disponível aqui um modelo de template que você pode replicar para fazer o acompanhamento das métricas de produtividade do seu time.
Acredito que melhorar as formas de trabalhar dos times analíticos é crítico para evolução da área e traz muito mais satisfação para nós e para os negócios.
DATA ANALYTICS INNOVATION
Encontro com foco em desenvolvimento do mercado de Analytics no país.
saiba mais
