Métricas que todo Scrum Master deveria estar olhando

Sempre costumo dizer em meus treinamentos que “ágil não é bagunça”. A prova disso é a disciplina necessária para conseguir pôr em prática as 19 páginas do Scrum Guide, fora a quantidade de estudo que demanda as técnicas complementares como User Stories, Pair Programming, Kanban, Planning Poker e muito mais. Mas algo pouco debatido e muitíssimo importante é a parte de métricas ágeis do time.

Mas porque eu preciso de métricas em times ágeis?

Para que exista um plano de melhoria contínua concreto em execução junto ao time.

Sem métricas o time simplesmente pode rodar o ágil na sua forma mais básica, mas não estará melhorando continuamente o que é um grande risco. Estudiosos dos processos japoneses de manufatura, de onde o Lean surgiu (Toyota) e de onde o Scrum foi baseado, são categóricos em afirmar que todo processo enxuto de produção (logo os processos ágeis também) sofrem deterioração ao longo do tempo se não estão sempre em contínuo esforço de melhoria. Ou seja, ser ágil é uma jornada, não um destino.

Logo, se para me manter ágil devo sempre estar buscando a melhoria contínua e para que possa melhorar continuamente de maneira sustentável e assertiva, preciso de métricas. Isso fica ainda mais evidente quando você como Scrum Master full-time ou Agile Coach (meu caso) deve estar olhando para mais de um time ao mesmo tempo, mas não subestime o poder de ter métricas sob constante vigilância mesmo em times pequenos e avulsos.

Velocidade (Velocity)

Essa é a métrica mais básica que todo Scrum Master tem de mensurar. Qual a capacidade de entrega do seu time?

Não importa qual a unidade de medida que você utilizar: número de cards, Story Points, T-Shirt Size (número de itens P, M ou G que o time entrega por Sprint) ou horas. Você tem de conhecer o passo do seu time para que seja possível fazer ajustes quando há variação pra menos ou quando se quer acelerar o time. Além disso, ter a métrica de velocidade auxilia na previsibilidade do roadmap do Product Owner, obviamente sempre respeitando o bom senso e a máxima de que “a única constante em software é a mudança”.

Como medir a velocidade do time? Os métodos ágeis são empíricos, logo, baseiam-se em experiência prática passada para poder tirar conclusões sobre o futuro próximo. Sendo assim, o único jeito de saber a velocidade do time é fazendo com que ele rode de uma a três sprints, de preferência com a mesma formação, para ter uma média e poder descobrir essa métrica.

Muito importante ressaltar que a velocidade de um time é reflexo de todo um contexto que envolve: tecnologia, perfis de pessoas, experiência do time, quanto tempo trabalham juntos, o quanto conhecem do projeto, etc. Qualquer alteração nesse sensível contexto irá provocar oscilações na velocidade.

Mais importante ainda é ressaltar que jamais você deve comparar a velocidade de dois times. Medimos a velocidade de um time para compará-lo sempre com ele mesmo, jamais com os outros.

Na ferramenta Visual Studio Online (TFS) a velocidade (Velocity) é calculada automaticamente no Product Backlog, desde que você use o campo Effort dos Product Backlog Items/User Stories (dependendo do seu template) corretamente. Você encontra esta informação no canto superior direito da tela, na visão de Product Backlog. Também é possível adicionar um widget Velocity no dashboard do time.

Velocity
Velocity

Tempo por Lead e Tempo por Ciclo (Lead Time e Cycle Time)

Lead time na área de supply chain é o tempo total de um pedido ser feito por um cliente até o mesmo ser entregue a ele e a ideia aqui não é diferente. É uma métrica que geralmente está associada ao uso do Kanban e dá um pouco mais de trabalho para ser medida dependendo das ferramentas que você tem à disposição. Basicamente o Lead Time é o tempo que leva de uma tarefa que foi criada no backlog até ela chegar no estado DONE ou seja, o tempo total de vida de um item de backlog (não necessariamente de desenvolvimento).

Já o Cycle Time é o tempo de desenvolvimento de uma atividade, ou seja, desde quando ela entrou em DOING/In Progress, até ela chegar em DONE, sendo sempre menor ou igual ao Lead Time.

Ambas métricas vão te dar um número de horas ou dias para finalizar cada atividade, sendo que para o cliente, o que importa é o Lead Time (total, desde o pedido).

Times ágeis devem buscar quebrar seus itens de backlog em pedaços executáveis dentro de um espaço de tempo razoável. Obviamente razoável varia de time para time, mas algumas boas práticas recomendam que o lead time de uma história não seja maior do que uma sprint. Também podemos incluir nas boas práticas que o lead time de uma tarefa (lembrando que uma história pode desmembrar em várias tarefas) não deveria levar mais do que um ou dois dias.

Assim, cravando alguns objetivos desejáveis ou apenas medindo o histórico vs situação atual, podemos analisar itens que possuam variações grosseiras de lead time e de cycle time e ajustar onde que está o problema no seu pipeline de desenvolvimento. Esse processo de melhoria contínua do Lead/Cycle Time é tema do famoso Improvement Kata da Toyota (onde o Cycle Time é chamado de Takt Time), onde objetivando chegar em uma visão ideal, partimos de uma condição atual para condições-alvo mais próximas rumo ao objetivo, aplicando PDCA a cada ciclo para melhoria.

No Visual Studio Online é possível ver todo o ciclo de vida de uma tarefa indo na aba History dela, como no exemplo abaixo.

Task History
Task History

Analisando o tempo entre a troca de estados da tarefa é possível perceber que o gargalo dela foi no Code Review, que demorou 15 dias para acontecer, contra apenas 2 dias de desenvolvimento e 2 de espera para entrar em desenvolvimento. Assim, temos um Lead Time de 17 dias e um Cycle Time de 16 dias. É óbvio o problema aqui e onde devemos colocar nosso esforços, muito diferente do que apenas tentar melhorar a velocidade de codificação do programador, quando não é nisso que reside o problema.

Obviamente que analisar tarefa por tarefa não é uma tarefa muito ágil e por isso é recomendada a instalação da extensão de Analytics no Visual Studio Online, para ter à disposição aos widgets de Lead Time e Cycle Time que podem lhe ajudar muito nos seus dashboards. Apenas analise individualmente as atividades que tenham fugido grosseiramente do Lead/Cycle Time e que possam ser a razão de suas sprints não estarem rolando tão bem.

Lead Time
Lead Time

Como o Lead Time não é tão bem rastreado pelos times quanto o Cycle Time (que é bem representado nas colunas do Kanban), recomenda-se para tarefas cujo lead time não tenha sido satisfatório o desenho do processo de pré-jogo (antes de entrar pra sprint) com as estimativas de tempo em cada etapa para entender onde está o gargalo. É bem comum os times se focarem em otimizar o cycle time quando muitas vezes o gargalo é antes disso, em processos de análise, especificação, etc.

O desenho abaixo que mostra um processo de pedido de software até a sua entrega na nuvem mostra como muitas vezes o maior tempo é o de espera entre cada uma das etapas do desenvolvimento, em especial (mas não somente) como acontece no modelo waterfall.

Processo de Exemplo
Processo de Exemplo

Neste processo, enquanto que o desenvolvimento levou 3h, o teste 30min e o deploy 4h, o Lead Time da demanda custou um mês de espera pra empresa. O que você faria neste caso, pediria para os desenvolvedores programarem mais rápido? Você investiria pesado em um sistema de deploy automatizado?

Outras métricas

Algumas literaturas consideram o Burndown Chart como uma métrica também,  assim como Burnup, embora eu não irei incluir aqui para não chover no molhado. Você também pode querer medir a quantidade de incidentes que entram por sprint e agrupar as razões do mesmo, para fazer uma sustentação adequada e assertiva no seu time (chega de paliativos!).

Dependendo do background do Scrum Master, outras métricas podem ser incluídas como Test Coverage e Bugs por Sprint. Se o time for responsável por manter a operação do produto que desenvolvem, métricas de disponibilidade como Uptime/Downtime podem ser adicionadas, mas sinceramente eu não acredito que tais métricas sejam responsabilidade do Scrum Master, mas sim do Time de Desenvolvimento, a menos que o Scrum Master também vista o chapéu de líder técnico do time, o que já fiz muito no passado.

Algumas dessas métricas são facilmente coletadas e apresentadas em dashboards caso você use o Visual Studio Online, seja com os widgets ou com as queries. Caso você seja mais oldschool e use quadros físicos, a coleta e apresentação terá de ser manual, o que pode desmotivar um pouco a prática constante. Nestes casos eu recomendaria uma apuração mais sazonal, principalmente quando as retrospectivas mostram que algo poderia estar indo melhor na produtividade do time.

E você, quais métricas usa em seus times ágeis?

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

O que é melhor: feature teams ou component teams?

A organização dos times de tecnologia dentro de uma empresa pode ser dividida basicamente entre dois tipos: feature teams ou component teams. Neste artigo pretendo explicar os conceitos de ambos times, as vantagens e desvantagens de cada um e lhe apresentar algumas conclusões práticas de quem já viveu (e ainda vive) os dois cenários nestes 12 anos de carreira com tecnologia.

Feature e Component

Uma feature é uma funcionalidade do sistema que entrega um benefício ou resolve um problema real do cliente, geralmente representada através de User Stories nos métodos ágeis. Para que as features sejam construídas é preciso que sejam criados os seus componentes primeiro, fazendo com que eles se comuniquem.

Um componente é uma parte de um software ligada a uma ou poucas tecnologias. Um banco de dados é um componente que é utilizado por várias features. Um webservice é um componente também, assim como uma tela do sistema e a somátoria de diversos componentes geram as mais variadas features.

Com isso em mente, podemos definir um Component Team como o tipo de time de tecnologia mais comum nas empresas médias e grandes: eles são organizados por uma tecnologia específica como o Time de Front-end Web, o Time de Back-end Java, o Time de Administradores MySQL e assim por diante. Também é comum serem criados Technology Teams focados em uma única skill, como o Time de Arquitetura, o Time de Redes, etc em uma visão departamental bem conhecida no mundo corporativo onde cada profissional fica no seu quadrado, entregando uma parte do produto/serviço da empresa.

Geralmente existe a figura do líder técnico e/ou gerente daquela tecnologia, dependendo do tamanho da empresa, que costuma trazer responsabilidades de gestão e uma hierarquia bem clara. É um time com uma especialidade vertical muito forte, mas bem menos versátil.

Component Teams
Component Teams

Já um Feature Team é um tipo de time de tecnologia mais comum em startups e pequenas empresas: eles são organizados por um produto ou funcionalidade específica dentro da empresa como o Time da Plataforma PHP (em uma empresa de hospedagem) ou o Time de Cartão de Crédito (em um banco). Empresas grandes que adotam esta formação geralmente quebram grandes produtos em partes ainda menores, em features (daí vem o nome) como o Time de Busca (focado na feature de busca do software) ou o Time de Relatórios (focado apenas em novos relatórios do sistema).

Nestes times as skills e backgrounds dos membros são mais diferenciadas, podendo haver mais de uma linguagem de programação envolvida (backend em Java e front-end mobile iOS, por exemplo) e pessoas de diferentes “setores” como infraestrutura, negócios, etc. Geralmente a liderança é compartilhada e mesmo quando ela é existente, é mais no intuito de apoio e servo-liderança do que gestão propriamente dita.

Feature Teams
Feature Teams

Encarando friamente o que os métodos ágeis pregam em termos de times, em especial o Scrum, os Feature Teams possuem um fit maior pois são verdadeiramente multifuncionais, conseguindo entregar o valor completo que a empresa precisa, de uma ponta a outra. Independente disso, vamos explorar as vantagens e desvantagens de cada um.

Vantagens e desvantagens

Falando de component teams as vantagens são:

  • avanço tecnológico: times focados em uma tecnologia promovem uma evolução mais rápida, coesa e equilibrada daquela tecnologia entre todos os projetos da empresa. Quando você tem os programadores JavaScript espalhados por toda empresa é muito mais difícil de garantir padrões mínimos de qualidade e arquitetura, de garantir a evolução dos profissionais menos experientes (pois não estão tendo contato suficiente com os sêniors) e assim por diante.
  • gestão/liderança: é muito mais prático elencar um gestor ou líder técnico para um time que possua uma tecnologia muito clara como foco. É natural que desenvolvedores Java enxerguem e se sintam representados por um profissional Java sênior como seu líder, além de ser muito mais fácil encontrar profissionais com um perfil “vertical” na área de tecnologia.

Enquanto que como desvantagens temos:

  • cascateamento do projeto: uma vez que Component Teams não conseguem entregar produtos e soluções completas para a empresa, eles dependem do recebimento de insumos de outros times e/ou outros times dependem do insumo deles e essa cadeia completa precisa rodar muito “azeitada” para que as entregas aconteçam, no melhor estilo waterfall.
  • foco na tecnologia: embora isso soe contra-intuitivo, o foco do time na tecnologia muitas vezes causa uma cegueira quanto ao produto e, principalmente, quanto ao valor gerado pelo seu trabalho para o usuário final. É sempre importante lembrar que a tecnologia é apenas um meio, não um fim.

Agora quando entramos em Feature Teams, temos algumas vantagens diferentes da sua contraparte:

  • foco no cliente: mais do que foco no produto, quando o time é realmente focado em features e no valor que elas geram para os clientes, geralmente tende-se a criar produtos mais user-centered, com melhor usabilidade, com retorno financeiro maior e muito mais. Afinal, empresas vivem de clientes.
  • velocidade: feature teams completos, ou seja, com todas as skills necessárias para a entrega acontecer, conseguem fazer entregas muito mais rápidas uma vez que a informação flui mais fácil entre todos os envolvidos, não há dependências (ou ela é menor) com outros times e todos os problemas do produto são compartilhados entre os membros do time.

No entanto, nem tudo são flores com os feature teams:

  • débito técnico e de processos: a comunicação entre feature teams geralmente é fraca uma vez que eles são bem desacoplados uns dos outros, gerando desigualdade de tecnologias e práticas entre eles. Assim é comum termos uma pluralidade de arquiteturas e formas de conduzir os projetos que não necessariamente gera resultados positivos pra empresa, associando-se geralmente um débito técnico pesado se não há um equilíbrio entre entregar rapidamente e entregar “porcamente”.
  • produtos que não se conversam: uma vez que tenhamos o desenvolvimento dos produtos espalhados entre os diversos times sem qualquer tipo de centralização dos padrões de arquitetura, UX, etc é muito comum que cada um siga uma linha de raciocínio diferente, com layouts diferentes, usando stacks de tecnologia diferentes, padrões de comunicação com o usuário, etc. Embora essa liberdade facilite as entregas, em grandes empresas isso gera um caos de gestão e pode acabar levando a uma experiência final ruim aos usuários do produto.

Tenha em mente que todas essas vantagens podem não ser a regra dependendo do perfil de profissional e de empresa que você esteja trabalhando, bem como as desvantagens podem ser contornadas sempre, desde que você tenha uma cultura forte de melhoria contínua na empresa.

Quando usar um ou outro

Note que essas classificações não são excludentes na totalidade da sua empresa, ou seja, você pode ter alguns feature teams e alguns component teams na sua organização. No entanto, elas são excludentes dentro de um time obviamente. Frameworks como SAFe falam do equilíbrio (vantagens x desvantagens) ser alcançado quando temos algo em torno de 75-80% de feature teams na empresa e o restante como component teams.

Segundo, note que não há um modelo que necessariamente seja melhor do que o outro. Tudo vai depender do seu quadro de profissionais, dos seus projetos, da cultura da sua empresa e das limitações que você possui. Como exemplos temos as pequenas empresas, onde existem poucos profissionais de cada skill, geralmente nem faz sentido organizá-los por componente, gerando times multifuncionais organicamente.

No entanto, caso você realmente queira adotar uma abordagem ágil de desenvolvimento, Feature Teams devem ser o seu objetivo para a maioria dos times. Obviamente este objetivo pode ser alcançado aos poucos, uma vez que a maturidade necessária é grande para que Feature Teams funcionem sem gerar um débito técnico altíssimo (nesse caso deve focar em Chapters fortes). Muitas transformações ágeis começam com Component Teams, para amadurecer o pessoal no core tecnológico de cada um, e aos poucos vão extraindo os profissionais preparados para atuar “solo” (sem seu líder técnico em constante contato) nos Feature Teams.

E por fim, em casos críticos onde sustentação esteja tomando todo o tempo dos times, o débito técnico esteja cobrando seu alto preço e a maturidade tecnológica esteja ridiculamente baixa, uma força-tarefa de Component Teams podem resolver este problema bem mais rapidamente antes de deixar as formações dos times mais livres novamente.

E você, como é na sua empresa? O que mais você vê como vantagem ou desvantagem em cada modelo que deseje compartilhar?

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

O que é um Agile Coach?

No final do ano passado eu fui promovido a Agile Coach, função que até então eu nunca havia desempenhado na minha carreira antes, apesar de estar trabalhando com Scrum e métodos ágeis de desenvolvimento de software desde 2010. Hoje, após meses exercendo esta função me sinto corajoso o suficiente para tentar definir a mesma e ajudar outras pessoas a trilhar este caminho.

Agile Coach foi um termo que passou a ser falado em 2010 ao redor do mundo, popularizando-se por volta de 2012, sendo que no Brasil só atingiu um mínimo de popularidade em 2015, segundo dados do Google Trends. Em 2012 especificamente, ano em que o Spotify publicou seu famoso vídeo sobre Engineering Culture, Agile Coach nada mais era do que um Scrum Master “descolado” do Scrum, ou seja, um líder/mentor/facilitador em métodos ágeis, mas não obrigatoriamente Scrum.

Mais tarde, com a evolução dos modelos de agilidade em escala, passou-se a defender o papel de Agile Coach de maneira diferente do Scrum Master, com um propósito mais abrangente e menos operacional dentro das empresas ágeis. E é dessa evolução do Agile Coach que venho falar hoje.

Agile Master

Talvez você veja por aí o termo Agile Master também, mas ele sim é “apenas” (sem desmerecer) um Scrum Master mais genérico, que não prescreve somente o Scrum. Isso evita a criação de XP Master, Kanban Master, etc. Apenas tenha em mente que Agile Master não é o mesmo que Agile Coach.

Coach

Para quem não conhece o termo, um Coach é literalmente um técnico, uma pessoa responsável por ajudar pessoas a desenvolverem o seu potencial. Não confundir com um mentor, que seria uma pessoa mais experiente em uma área de conhecimento na qual a pessoa busca se aprofundar, embora um Coach também possa ser um mentor. Existem Coaches em diversas áreas, sendo os mais famosos os coaches de liderança (que atuam com executivos geralmente) e cada vez mais na área da computação, os Agile Coaches vem tomando um lugar cada vez mais expressivo nas empresas.

Um Agile Coach é um treinador de práticas ágeis. Na sua essência ele nasce como um Scrum Master experiente que possui um rol variado de dinâmicas e práticas ágeis e larga experiência aplicando métodos ágeis em times de desenvolvimento de produtos. É alguém que já vivenciou implantações de modelos ágeis antes, aprendeu com os erros de outros times e empresas, etc. Basicamente um Scrum Master calejado e com muita empatia, com estômago forte para os desafios e conflitos que vem junto com a agilidade em grande escala.

Com esse arsenal de recursos, ele capacita times a se tornarem ágeis mais rapidamente, empodera Scrum Masters, orienta Product Owners, remove impedimentos estratégicos e operacionais para adoção da agilidade em escala empresarial e muito mais. Em escala corporativa, cabe ao Agile Coach fazer a ponte cultural entre os times ágeis e as demais áreas “não-ágeis” da organização.

Pense no Agile Coach como o Scrum Master dos Scrum Masters. É a ele que recorrem quando possuem impedimentos do processo.

Vale ressaltar que o papel de coach, seja com qualquer expertise técnica, é algo que pode ajudar profundamente as pessoas e os times a evoluírem mais rapidamente rumo a uma condição-alvo desejada. Infelizmente a palavra hoje em dia sofre com a má atuação de muitos charlatães por aí. Os poucos Agile Coaches que conheço eu sei que fazem um trabalho sério, mas infelizmente não posso dizer o mesmo de vários coaches de outras áreas.

Rotina

Trabalho dentro da área de Governança de TI da empresa, uma vez que como Agile Coach não posso estar vinculado a nenhuma tribo de desenvolvimento específica, sou um recurso compartilhado entre as nove tribos que temos. A minha rotina como Agile Coach é divida entre um operacional e projetos. Até aí nenhuma novidade, não é mesmo?

Meu operacional principal é o coaching que faço com os Product Owners, Scrum Masters e Team Leaders (como chamamos os gerentes ágeis no Agibank). Além desse operacional tem o Scrum of Scrums, que é a reunião semanal com os Scrum Masters pra alinhar as práticas e processos, mediações de conflitos ocasionais, a organização mensal da Sprint Review dos times (que fazemos publicamente e chamamos de Demo) e uma avaliação mensal de indicadores dos times.

Já a parte de projetos envolve criação e melhoria contínua dos processos institucionalizados, capacitações em grande escala, criação de materiais de apoio e muito mais. Sempre visando a evolução do modelo desenhado originalmente e a disseminação de uma cultura ágil dentro da empresa.

Cultura

A parte mais difícil do trabalho do Agile Coach é ser agente transformador da mudança cultural de uma organização. Uma coisa é aplicar Scrum em um time, tal qual eu sempre estive acostumado a fazer como Scrum Master. Você consegue o apoio do seu chefe imediato e o resto é com você, não há muita mágica.

Quando se fala em diversos times trabalhando no modelo ágil, é necessário que exista o aval para criação de uma cultura ágil de desenvolvimento. É necessário educar as áreas que demandam os projetos que o modus operandi muda nesse novo modelo. É necessário empoderar os Product Owners para que consigam priorizar os backlogs com sucesso e que não sejam meros fantoches dos gerentes.

Formar times reais é uma prioridade aqui e o “eu” dá lugar ao “nós” quando o assunto são objetivos e entregas a serem feitas pelo time. E essa mentalidade não surge do dia pra noite, cabendo ao Agile Coach e outros líderes deste processo ágil serem os catalisadores dessa mudança.

Este não é exatamente um artigo pronto. Pretendo atualizar ele conforme for descobrindo mais facetas da minha nova função e até mesmo corrigi-lo caso meu entendimento se mostre equivocado com o passar do tempo.

Obviamente adoraria receber o seu feedback nos comentários.

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.