Para onde está indo a energia do seu time?
— 71,05% da energia do squad na última semana, foi gasto com atividades que não geraram valor real para o cliente — disse o Agile Coach para o time na daily.
Aquilo tinha o objetivo de ser uma provocação para a enorme quantidade de carga operacional que o time estava trabalhando. Isso não era lá uma grande novidade, mas em números claros, era algo diferente. Como na maioria das equipes, a alta proporção de atividades operacionais era algo subjetivo, não era metrificado e claro até então.
Logo em seguida, surgiram vários questionamentos:
— E para onde foram os outros 30%? — foi a primeira pergunta do PO com certa preocupação.
— Como você obteve este número? — emendou o TL.
Ainda sem espaço para as respostas, os integrantes do time continuaram:
— O que este número significa?
— É muito?
— Eai, o que vamos fazer com isso?
Esse não é o começo, nem o fim da história. Baseado na experiência com squads de backoffice — que dá sustentação ao negócio como fiscal, conciliação e gestão de pessoas — compartilho aqui algumas técnicas simples que respondem tais perguntas.
… algumas semanas antes
Os squads tinham grandes desafios. Para esse squad, era ainda mais complicado. As áreas clientes tinham um turbilhão de demandas represadas, os novos modelos de negócio da empresa que surgiam exigiam alterações significativas nos sistemas, as metas do ano eram agressivas, o time passava naquele momento por profunda transformação de skills. Frequentemente algum sistema legado apresentava problemas de performance e, para deixar o jogo ainda mais complicado, faltava tempo para desenvolver coisas novas.
De certa forma, como agile coach, sou cético a grandes movimentos que prometem resolver a maioria dos problemas do time de uma vez só (não acredito em receita mágica), prefiro a estratégia “dividir para conquistar”, na qual trabalhamos profundamente em um problema por vez. Apesar do feeling inicial indicar grande proporção do trabalho operacional do time, não sabíamos com precisão quais eram os pontos que geravam tanto operacional, o quanto estes oneravam a entrega de valor e onde focar esforços para diminuir isso.
Você pode questionar:
Mas diante de tantos ofensores ao time, porque focar nesta questão agora?
Clarificar isso através de métricas é fácil, não demanda muito trabalho, basta usar algumas técnicas, e, principalmente, o time precisava muito de entregar mais demandas de valor e ter espaço para inovação, este último não ocorria.
Defender alguma estratégia embasada de números já é algo bem difundido nas literaturas de negócios, já declarava Peter Drucker: “O que não se mede, não se gerencia”. O uso de métricas permite direcionar as ações do time com mais assertividade e viabilizar previsibilidade para as entregas. Contudo, no universo de desenvolvimento de software não costumamos ver isso com tanta frequência. Além de fortalecer a argumentação de uma estratégia, após trabalhar com dezenas de desenvolvedores, percebi que o uso de métricas (como métricas de produtividade) sensibiliza e engaja o time, mais que o feeling do gestor.
Há outro fator relevante: imagine os desafios do Product Owner, com um backlog que não para de crescer, pressão dos stakeholders para entrega dos projetos que representam ganhos financeiros, processuais ou competitividade. Neste cenário, encaixar uma demanda que surgiu a partir do time para diminuir o operacional é uma tarefa muito difícil. Para isso, é preciso ter todos argumentos na ponta da língua para defender que aquele item de débito técnico ou a automatização do processo é algo que precisa ter prioridade maior do que a feature do projeto.
As duas técnicas descritas abaixo foram criadas para ajudar a melhorar a performance do time. Há alguns meses, quando a área de controladoria da empresa levantou a necessidade de medir o Opex e Capex para separar o que era investimento e o que era sustentação, naturalmente as técnicas ajudaram a dar essa resposta com muita prontidão e clareza.
Conceitos e considerações
Neste contexto do squad, vamos considerar quatro tipos de demandas divididos em duas categorias:
Esses tipos de demandas devem ser totalmente acordadas com o squad. Além disso, faz parte do acordo de trabalho do time.
Para essa técnica de análise do lead time de demanda de valor vs demanda falha, o entendimento dos conceitos Throughput e Lead Time é essencial para todos envolvidos. No artigo Métricas Ágeis: O que o Lead Time e o Throughput revelam para nós?, Sony Maia explana esses conceitos.
Nos squads que foram implantados as técnicas, usamos a ferramenta Jira e também replicamos o kanban na parede. No board digital, os times têm rastreabilidade melhor das atividades, podem adicionar evidências e ter maior detalhamento. O board físico na parede é a principal referência nos stand up meetings e ajudam a gerar sinergia.
Ranking através de informações no Jira
No início, apesar do longo histórico de atividades no Jira, os dados não estavam organizados, não podíamos extrair com precisão as informações de processos e sistemas impactados pelas demandas. Definimos que, em cada card aberto, deveria ser preenchidos 3 campos:
- Component: sistema envolvido na demanda.
- Área solicitante: qual departamento da empresa fez a solicitação.
- Label: uma tag que especifica qual é o processo de negócio relacionado.
Acordamos com os integrantes do time, que os campos Label, Component e Área Solicitante deveriam ser preenchidos durante o atendimento de Bugs e Requisições. Várias outras informações ou campos dentro do Jira poderiam ser utilizados, contudo, para manter a praticidade do processo, somente estes 3 campos foram determinados como fontes de informações.
Depois de poucas semanas, os dashboards dinâmicos mostraram visões valiosas sobre o alto volume de atendimentos do squad. Vale mencionar que este squad é responsável por 26 sistemas, dentre soluções de mercados e desenvolvidas internamente. As informações quantificadas no Component nos deu visão precisa não apenas de onde estavam a maior parte de demanda, mas também onde estava acumulada as demandas de falhas, que derrubavam a produtividade do time. Os dashboards mostram informações mensais.
O dashboard das informações que o campo Área Solicitante foi insumo para sensibilizar as áreas clientes do alto volume de atendimento. Antes, os gestores das áreas clientes atentavam-se apenas às grandes entregas e não tinham visibilidade da grande quantidade de “atendimentos do dia-a-dia”.
As informações quantificadas no campo Label foram as mais valiosas, pois determinaram com exatidão quais eram os processos que mais geraram atendimentos operacionais.
O item que apareceu na primeira colocação tratava-se de um ação manual no sistema que chegavam a acontecer 35 vezes por semana. O atendimento não passava de duas horas, porém o volume alto custava muito tempo do time, que poderia ser destinado para o trabalho em novas histórias. Com o diagnóstico de quais atividades tomavam mais tempo, o squad se reuniu para um brainstorming com objetivo de encontrar a solução (no caso automatização) para o item que aparecia na primeira posição. A homologação deste desenvolvimento consumiu vários dias. Porém, a médio e longo prazo, foi algo bem positivo para o time.
Cálculo do lead time para demanda de valor vs falha
Os squads já trabalhavam com throughput e lead time há alguns meses. Semanalmente, as métricas eram apresentadas ao time com objetivo de mostrar como estava o fluxo de entrega e para gerar insights na busca pela melhoria contínua. Contudo, a análise do throughput ainda não indicava com boa precisão onde estava sendo consumido a maior parte do tempo do time. Por exemplo, em certa semana, as métricas indicavam:
- 36 requisições (itens operacionais)
- 4 bugs
- 7 histórias
- Total de 47 itens entregues na semana
O dashboard abaixo mostra o throughput semanal:
Nesta situação, não era correto concluir que 14,89% (7 histórias dividido por 47 demandas no total) do trabalho do time foi em demandas de valor e os outros 85,11% (20 requisições e 3 bugs dividido por 47 demandas no total) foi em demandas de falha, pois as 7 histórias poderiam ter levado mais tempo do time do que as várias requisições.
Por mais que procuramos colocar no board kanban itens com granularidades parecidas, quando se trata de demandas como requisições e histórias, os tamanhos variam consideravelmente. Diante disso, além da quantidade de itens entregues (throughput) foi considerado o lead time de cada um no cálculo. Veja um exemplo onde utilizamos as 7 histórias entregues no quadro acima.
Os 40 itens de demanda de falha (bugs e requisições) tiveram leads times de 1 ou 2 dias cada. Quando somamos todos lead times das 40 demandas, teremos o número de 59. Ao analisar estritamente a somatória dos lead time de histórias, teremos 39. Logo, a partir destes números 39/98 podemos indicar que o tempo do time voltado a histórias representou 39,80% e o tempo para itens operacionais 60,20%.
Análise do lead time para demanda de valor vs demanda falha por semana:
Análise do lead time para demanda de valor vs demanda falha por mês:
Mais do que análises avulsas, é essencial analisar as proporções de lead time para demanda de valor vs demanda falha em períodos de semanas ou meses para monitorar a evolução, melhorar previsibilidade de entrega e, no caso de um atraso inesperado, conseguir ter visibilidade do que pode ter acontecido e trabalhar para eliminar estes operacionais.
Esse modelo de cálculo derivado das métricas ágeis traz um ponto de vulnerabilidade: o lead time utilizado no cálculo não considera o tempo que a atividade ficou bloqueada. Entretanto, ainda assim, gera visões mais próximas da realidade do que apenas analisar o throughput. Trata-se de uma tentativa de aproximar quanto tempo o time está utilizando para cada tipo de demanda, portanto não podemos esperar exatidão.
Outro fator que é muito importante levar em consideração é que não estimulamos o microgerenciamento no Luiza Labs. Uma ferramenta de “controle de atividades” na qual as pessoas têm que indicar o horário que iniciou e terminou cada atividade poderia indicar com precisão o tempo utilizado em cada tipo de demanda. Porém, não consideramos isso como uma prática saudável para os times.
Agora que temos claro quais itens de demanda de falha (inclusive operacionais) precisam ser tratados, o PO tem mais insumos para encaixar no backlog automatizações, desenvolvimento de features que simplificam e agilizam os processos, features que dão mais autonomia ao usuário, débitos técnicos, entre outros. Neste contexto, também surge ações de ajustes processuais e de organização como:
- Acertar o fluxo de atendimento de primeiro nível (exemplo: help desk), que não está funcionando bem ou, simplesmente, não ocorre. Nesta linha, envolve promover treinamento e compartilhamento de base de conhecimento com o primeiro nível do atendimento.
- Re-organização de produtos que estão indevidamente sob responsabilidade de um squad ou tribo.
- Estabelecer melhor triagem na abertura das solicitações (requisições, bugs) pelos key users.
Conclusão
Para tantos desafios desse squad, não será apenas o trabalho em cima de demanda operacional que irá mudar o jogo. Há vários movimentos como re-organização da equipe, formação de novos skills, melhoria de sinergia com áreas clientes, adoção de boas práticas no desenvolvimento de sistemas, adoção de novas tecnologias, customização do fluxo de trabalho, entre outros. Mas estes pontos são assuntos para outros textos.
Há muitos pontos a serem evoluídos neste time. Como aprendemos com o método Kanban, estamos trabalhando para gerar pequenas evoluções dia-a-dia (melhoria contínua). As técnicas mencionadas tornaram-se agentes provocadores, um cutucão contra o conformismo presente na rotina do squad.
Referências
https://implementconsultinggroup.com/media/2663/eliminating-failure-demand.pdf
