Developing a vision that enables seeing and understanding the whole by analyzing the parts that form it is a great challenge when dealing with uncertain environments.

One of the ways to understand and analyze the work system of an agile team is through process metrics (there is a collection of cool content on the subject here on Ptec’s blog).

Understanding the flow from data is a pragmatic way to incorporate transparently a continuous improvement philosophy without abrupt and chaotic changes for everyone involved in the context (team, stakeholders, product area, managers, etc.). To paraphrase the Kanban community, measuring is a tool that will help the evolution and not revolution of an existing process.

Personally, I like to quantify the process when I am mapping the reality of a team, as I expose facts (data) for discussion and analysis. In my experience with software development teams, I have realized that having this type of behavior helps to reduce a subjective load that may exist on the team and is a way of confronting beliefs like “we don’t need to improve”, “we don’t have problems in the process” and “we work collaboratively”.

In today’s blog post, I’ll share a collection of metrics that will help you diagnose the health of an agile team process.

Assumptions

First of all, I need to list some reservations about using metrics.

Metrics should be used to evolve the process, not to generate destructive demands and comparisons.

Don’t be tempted to compare teams and measure an individual’s performance. If you or the company where you work are interested in rewarding individual results, engineer a method that proposes evaluating the person’s performance from the opinion of managers, peers and customers who have interacted with the results of the individual’s work. In the event of individually rewarding teams for their results, avoid metrics that are not directly related to business results (e.g. what is the value of the team delivering a number of features in the semester if product revenue has not increased?).

I share this assumption so that you and your team don’t behave according to how they are being measured. After all, as Goldratt would say: “Tell me how you measure me, and I will tell you how I will behave“.

Numbers without context are dangerous.

Any analysis done without understanding the variables that form a scenario becomes superficial, skewed and poor. If someone tells you that the number of features delivered in one team is 10 items per week, is it possible to reach any conclusion? Is this metric good or bad? What is the meaning of delivered for that team? Is it software in production or delivery in a QA environment? Well, from the previous questions it is possible to conclude that a loose number is nothing more than a symbol deprived of any meaning.

Look for trends and run away from accuracy. Given the complexity of creating a software product, do not seek to be deterministic in a world that is receptive by nature to a probabilistic reality.

The logic behind the last assumption is: we live in an environment where there is risk, that is, there is a probability of failure due to some uncertain event whose occurrence does not depend exclusively on the team’s will. Therefore, it is unlikely that the team knows for certain the delivery deadline for a demand or project. Rather than fooling ourselves with deadlines that ratify that deliveries will always happen on the same date and in the same way, let’s analyze the team’s data history to project the chance of delivering something.

These assumptions that I shared will help you use metrics effectively. Lucas Colucci wrote a very important article that presents some common mistakes when using process metrics.

Process diagnostics

Given the assumptions shared above, let’s go to what really matters. The metrics listed below will assist you in mapping the health of a team process. As an agilist, I consider that the views below form a workflow cockpit and should be available for teams to use as material for promoting process improvements (e.g., use of metrics in retrospectives, process analysis in daily meetings, etc.).

Work in progress

Monitoring the work in progress will help the team become aware of the work volume that the process has supported over time. I like this kind of view as it shows, for example, if teams are respecting a policy regarding limits to work in progress.

In the example above, we have a situation where the team had close to 10 items in progress a week, until at some point there was a reconfiguration in the number of people, which caused the amount of work in progress to decrease. An insight here is that this view presents an interesting history of the team, helping to identify moments when changes occurred in team structure, changes of direction (the famous pivots), obstacles, etc.

In order to stabilize the process from the productive capacity, it is important that there isn’t a growth trend for the number of items in WIP. If this is happening, the team is likely to need optimizations to reduce WIP. As an agilist, monitoring WIP will support you to reverberate the following mantra with the team: “Let’s stop starting and let’s start finishing”.

Another WIP analysis I have started is related to the lifespan of items that are in WIP within a given week. Essentially, the view considers the items that are in progress that week and accounts for how long they have been in the workflow. For an easier reading of the chart, I group the data by category where I consider the following ranges: (1) 1 day in WIP; (2) up to one week in WIP; (3) from 1 to 2 weeks in WIP; (4) from 2 to 3 weeks in WIP; (5) from 3 to 4 weeks in WIP; (6) over 4 weeks on WIP.

Still on how the view is structured, for the weeks that have passed, items that are in WIP at the end of the period are accounted for and classified. For the current week, items currently in WIP are analyzed.

Applying it to one example, you can see that in the fifth week of WIP lifespan tracking of the team above, there were two items that were over a month in the flow. If the team, by systematically tracking their workflow, realizes that the older categories are growing, it is very likely that a bottleneck is being produced at some stage in the process and an intervention will be needed.

Keep in mind that WIP represents effort and energy that has not yet been validated and the longer the team spends carrying it, the less feedback will be received, the slower the process of validating the assumptions behind the initiatives that originate the work, and the greater the risk of the company missing on a market opportunity.

Lead time

Lead time is an important metric for teams to develop the ability to understand how long they have taken to complete a work item. In addition, teams that develop the skill to analyze such metrics can identify situations that have generated variability in the process (e.g. environment issues, exit of team members, lack of clear acceptance criteria for demands).

The first view that should be available for the team is the lead time scatter plot chart. It will provide an idea if the time for delivering the items is decreasing or not over time.

As shown in the chart above, I like to combine the following information in this view: completed items (represented in the chart by the blue dots) and item in progress (represented in the chart by the red dots); the moving average that considers the last 5 delivered items (this is a completely arbitrary parameter); and the information for 50th percentile (median), 75th percentile and 95th percentile.

Such reference measures are useful because, from the example, they bring to light findings such as:

• The moving average has varied over time.
• Based on the history of completed items, 50% of them were completed within 10 days, 75% took up to 16 days to complete and 95% were completed within 34 days.

In addition, the scatter plot chart can generate answers to questions such as:

• What is the team doing to handle items in progress that are becoming extreme lead time cases?
• What can be improved in the process to reduce lead time?

Another beneficial view to understand lead time is the histogram chart, because, when considering each lead time as a category, it presents data more concisely and allows extracting information about distribution behavior.

As shown in the example above, the histogram enables the team to respond to queries such as:

• What has been the most frequent lead time?
• Are extreme lead time cases very common?
• What is the distribution format? Is there a lead time concentration to the left or right of the distribution? Is there more than one mode? Usually bimodal distributions represent flows of teams that deal with more than one type of demand in their process, because they have similar concentrations in different lead time categories.

Delivery pace

Measuring and visualizing throughput is important for the team to understand what amount of work has been delivered over a period of time (example: week, two weeks, month), as well as helping it identify if there is an upward trend in the number of deliveries. When realizing that throughput is falling, the team can try to understand which factors are affecting the process throughput.

I recommend whenever possible breaking the throughput view by demand type. Thus, it is clear to everyone if the team is able to:

• Balance the number of valuable deliveries (e.g. features) with failure demands (e.g. bugs).
• Deal with urgent demands in a sustainable manner. I often find teams that classify every demand that enters the workflow as urgent and work on them, leaving aside items that will be important to the business in the medium term.

In the example above, the team managed to balance during most weeks user story deliveries with bug fixes. In weeks marked with red arrows, the team had to act and deliver critical issues that were affecting the company’s operation, therefore, it delivered only bug fixes.

Analysis of flow input and output rate

In addition to using the CFD chart (I wrote a full blog post to talk about this view), I would like to present an analysis that I have not seen many agilists do: the relationship between workflow input and output rates. Basically this view compares the amount of items that the team has committed to deliver with the number of items delivered over time.

What insight can be provided by can this type of view? Let’s look at an example.

Based on the image above you can make some deductions:

• Of the 27 weeks analyzed, 10 of them had an input rate (items the team committed to delivering) greater than the number of delivered items.
• In week 17 the team had a peak of items committed to being delivered. This happened because the team’s PO was about to go on vacation. Speaking of inventories, I suggest reading Guilherme Fré’s blog post on the subject.

Analyzing the process input and output rate will support the team in understanding whether the delivery pace is tracking the number of committed items. I have seen teams making commitments that are over their actual capacity. This type of behavior leads to lack of trust by stakeholders because the team delivers less than requested, as well as frustration in the team for never being able to deliver “everything”.

In a perfectly stable system, the input and output rate should be the same. If you and your team can develop a process where most weeks these rates are equivalent (e.g., for every 4 weeks, 3 have equal input and output rates), this will demonstrate workflow maturity and represent a highly predictable context.

Conclusion

Incorporating a culture that brings data to your team will enable you to monitor a process that has an essentially complex nature (software) providing progress visibility to anyone interested in what is being built or maintained.

Furthermore, proposing data-driven improvements and evolutions is an excellent way for removing subjective and, to some extent, empty analysis. Basically, I hope that this blog post helps you, agilist, on encouraging people to use less feeling and more facts when they are analyzing a team’s workflow behavior.

If you are looking for advanced material on metrics, I recommend the book I have written Agile Metrics – Get better results in your team. Check out the reviews posted by those who have read it

And you? What metrics have you used to track process health? Share your experiences in the comments below!
What challenges do you face to track the health of your process?
Schedule a 30-minute conversation with one of our experts. A consultant will help you map out your biggest challenges in the development process.

The post An Agilist’s Guide: Analyzing Process health first appeared on Plataformatec Blog.

O atraso de uma semana em um projeto, gera dois custos diferentes:

• O primeiro custo é o custo das pessoas presentes no time do projeto, por terem que trabalhar por mais uma semana.
• Já o segundo, trata-se do custo de atraso (normalmente chamado de cost of delay) que por sua vez é a receita que deixa-se de receber pelo atraso, por exemplo: supondo que um novo produto tenha uma receita diária de 100 reais, o custo de atraso seria de 700 reais (100 reais x 7 dias), aqui no blog temos um post muito interessante sobre o assunto.

Como esses custos podem ser altos, é preciso utilizar ferramentas que possam dar visibilidade para as datas de entrega. Uma das formas encontradas para dar visibilidade a estes potenciais problemas, foi através da adoção do Diagrama de Gantt, para gerenciamento de projetos, nele é possível identificar os pontos mais delicados do projeto (os caminhos críticos) em que deve-se dar maior esforço para que não atrasem, visto que ao atrasar nesses pontos o projeto inteiro também irá atrasar.

Embora essa ferramenta seja ótima para alguns tipos de projetos (normalmente onde existe um grau de incerteza baixo), ela não é a ideal para projetos com previsibilidade baixa devido a variância de entregas, como ocorre em projetos que lidam com o campo do conhecimento (redigir um livro ou desenvolver software, como exemplos).

Aqui na Plataformatec temos sempre feito o máximo para que todas as nossas previsões de entregas sejam embasadas em dados e sigam métodos científicos comprovados. Os dois métodos que mais utilizamos são:

• Progressão linear
• Simulação de Monte Carlo

PROGRESSÃO LINEAR

Na progressão linear, fazemos uma análise dos dados de itens de trabalho entregues durante algum período (normalmente trabalhamos com periodicidade semanal) e através de uma análise destes valores elegemos quais são os melhores valores a serem alocados na progressão. Por exemplo: supondo que tenhamos os valores de histórico de itens de trabalho entregues por semana (throughput), conforme o gráfico abaixo:

Um valor que faz sentido para a progressão pessimista será de que a cada semana iremos entregar 1 item de trabalho por semana, visto que tivemos 5 casos em que a entrega foi de 1 ou 0, para a estimativa otimista podemos utilizar o valor 3 ou 4 ou até mesmo 3,5 visto que tivemos 4 casos em que o valor foi 3 ou mais, por fim para a progressão provável o melhor valor seria o de 2 visto que é o valor da mediana do dataset e é o valor que mais aparece (a moda).

O maior problema da progressão linear é de que estamos informando os valores a serem utilizados para cada cenário, algo que pode ser perigoso caso a pessoa que está fazendo a progressão não tenha um bom domínio de análise de dados. Além disso, a progressão linear também ignora a variância. Desta forma, em sistemas com uma variância de entrega muito elevada, a progressão linear pode não fazer tanto sentido.

MONTE CARLO

Outra técnica que utilizamos chama-se Monte Carlo, para entender melhor como o método funciona, bem como ter uma inferência do que ele faz, recomendo esse blogpost que é bem completo.

Tenho utilizado o método desde que entrei na Plataformatec com grande sucesso, porém uma coisa sempre ficava na minha mente era: “Quantas iterações são necessárias para que eu possa ter um bom grau de confiabilidade no método?”. Para responder essa pergunta eu fiz muitas pesquisas em livros estatísticos e pela internet e não consegui encontrar nenhum tipo de informação que me auxiliasse.

Dessa forma resolvi fazer um estudo desse assunto. O objetivo do Monte Carlo é de inferir a probabilidade de algum evento, “forçando” que o evento ocorra tantas vezes que o resultado me dê a probabilidade da ocorrência do evento. Por exemplo, ao lançar uma moeda mil vezes se eu contar quantas vezes a moeda cai em “cara” e dividir esse valor pelas mil vezes que a moeda foi lançada, obterei uma inferência da probabilidade da moeda cair em “cara”.

Para conseguir saber a qualidade do método eu realizei testes nos quais eu já sabia o resultado esperado, e fui fazendo com que o problema fosse cada vez mais complexo, de forma a ver se existe alguma relação entre a dificuldade do problema e a quantidade de iterações necessárias para que o valor inferido pelo método seja o mais próximo possível do valor calculado.

O objetivo é verificar quantas iterações são necessárias para que o erro entre o valor inferido pelo método e o valor calculado seja mínimo (para previsões de probabilidade de entrega um erro a partir da segunda ou terceira casa decimal é bem aceitável). Gostaria de ressaltar que esse blogpost não é um estudo científico acerca do assunto, e seu objetivo é entender através de inferência qual é um valor de iterações bom para ser utilizado em predições para projetos.

OS TESTES

Os testes foram todos realizado utilizando a linguagem de programação R, que pode ser baixado neste link. Caso prefira utilizar um IDE, recomendo o RStudio.

Em todos os testes eu rodei o sistema por 100 vezes utilizando as seguintes quantidades de iterações: 100 (cem), 1000 (mil), 10000 (dez mil), 100000 (cem mil), 1000000 (um milhão), 10000000 (dez milhões), 100000000 (cem milhões) e 200000000 (duzentos milhões). Os resultados são os consolidados dessas 100 “rodadas”, em cada iteração.

A MOEDA

O primeiro teste que fiz foi em cima de um lançamento de moeda. Uma moeda tem 50% de chance de cair em qualquer um de seus lados e este é o valor que queremos que seja inferido pelo Monte Carlo. Para isso utilizei o seguinte código em R:

LancaMoeda <- function(iteracoes)
{
# Cria o vetor com os valores possíveis para a moeda 1 = Cara e 0 = Coroa
moeda = c(0,1)
resultado = 0

# Soma todos os resultados em que a moeda foi "Cara"
resultado = sum(sample(moeda, iteracoes, replace=T))

# Divide o valor pela quantidade de iterações e transforma em percentual
resultado = (resultado/iteracoes) * 100

return(resultado)
}

# Inicializa variáveis
vetor_resultado = 0
vetor_tempo = 0
controle = 0

# Informa a quantidade de iterações a serão executadas
rodadas = 100

# Aloca os resultados percentuais em um vetor de 100 itens e aloca os tempos de execução em outro
while (controle != 100)
{
tempo_inicial = Sys.time()
vetor_resultado = append(vetor_resultado, LancaMoeda(rodadas))
tempo_final = Sys.time()

tempo = tempo_final - tempo_inicial
vetor_tempo = append(vetor_tempo, tempo)

controle = controle + 1
}

# Mostra os percentuais
vetor_resultado

# Mostra os tempos de execução
vetor_tempo

Alterando os valores da variável iterações e compilando os resultados obtive a seguinte tabela:

No caso de um problema simples, como o lançamento de uma moeda, podemos ver que a quantidade ideal de iterações seria algo entre 10 e 100 milhões de vezes. Visto que é nessa faixa em que o desvio padrão dos resultados começa a ser na ordem da terceira casa decimal, outro ponto interessante é que se você deseja mostrar apenas a primeira casa decimal um valor de 1 milhão de iterações já atenderia.

O DADO

Com o teste da moeda podemos ter uma idéia de quantas iterações são necessárias, para cada grau de confiabilidade desejado. Porém uma pergunta que fica é se esse comportamento é o mesmo para sistemas mais complexos. Por este motivo fiz um teste parecido, porém agora rodando um dado de 6 lados, que tem 16,67% de chances de cair em qualquer face.

RolaDado <- function(iteracoes)
{
# Cria o vetor com os valores possíveis para o dado
dado = 1:6
resultado = 0

# Aloca os resultados das rolagens do dado
resultado = sample(dado,iteracoes,replace=T)

# Soma todos os valores que tiverem sigo iguais a 6
resultado = sum(resultado == 6)

# Divide o valor pela quantidade de iterações e transforma em percentual
resultado = (resultado/iteracoes) * 100

return(resultado)
}

# Inicializa variáveis
vetor_resultado = 0
vetor_tempo = 0
controle = 0

# Informa a quantidade de iterações a serão executadas
rodadas = 100

# Aloca os resultados percentuais em um vetor de 100 itens e aloca os tempos de execução em outro
while(controle != 100)
{
tempo_inicial = Sys.time()
vetor_resultado = append(vetor_resultado, RolaDado(rodadas))
tempo_final = Sys.time()

tempo = tempo_final - tempo_inicial
vetor_tempo = append(vetor_tempo, tempo)

controle = controle + 1
}

# Mostra os percentuais
vetor_resultado

# Mostra os tempos de execução
vetor_tempo

Alterando os valores da variável iterações e compilando os resultados obtive a seguinte tabela:

Podemos ver que neste caso também temos que a quantidade ideal de iterações seria algo entre 10 e 100 milhões de vezes, para termos um erro a partir da segunda ou terceira casa decimal. Esse resultado mostra que, ou a complexidade do problema não tem influência na quantidade de iterações ou de que o problema da moeda e do dado têm complexidades parecidas. Analisando os tempos de execuções da moeda e do dado verifica-se que eles demoram tempos parecidos de execução, o que corrobora a hipótese de que os problemas tem complexidades próximas.

DOIS DADOS

Para saber se a complexidade era muito próxima e por isso que os valores de iterações ideais ficaram iguais, decidi dobrar a complexidade do problema ao rodar dois dados em vez de um (entendo que nem sempre ao dobrar a quantidade de funções teremos mais complexidade por conta da ordem de complexidade ou Big-O Notation, porém fiz o teste para ter certeza se isso se aplicava). A maior probabilidade de resultado encontrada ao rolar dois dados é o valor 7, tendo 16,67% de chances de ocorrer.

RolaDoisDados <- function(iteracoes)
{
# Cria o vetor com os valores possíveis para o dado
dado = 1:6
resultado = 0

# Aloca os resultados das rolagens dos dados
primeira_rolagem = sample(dado,iteracoes,replace=T)
segunda_rolagem = sample(dado,iteracoes,replace=T)

# Soma os vetores, item a item
resultado = primeira_rolagem + segunda_rolagem

# Soma todos os valores que tiverem sigo iguais a 7
resultado = sum(resultado == 7)

# Divide o valor pela quantidade de iterações e transforma em percentual
resultado = (resultado/iteracoes) * 100

return(resultado)
}

# Inicializa variáveis
vetor_resultado = 0
vetor_tempo = 0
controle = 0

# Informa a quantidade de iterações a serão executadas
rodadas = 100

# Aloca os resultados percentuais em um vetor de 100 itens e aloca os tempos de execução em outro
while(controle != 100)
{
tempo_inicial = Sys.time()
vetor_resultado = append(vetor_resultado, RolaDoisDados(rodadas))
tempo_final = Sys.time()

tempo = tempo_final - tempo_inicial
vetor_tempo = append(vetor_tempo, tempo)

controle = controle + 1
}

# Mostra os percentuais
vetor_resultado

# Mostra os tempos de execução
vetor_tempo

Novamente alterando os valores da variável iterações e compilando os resultados:

Novamente verificamos que uma quantidade de iterações entre 10 e 100 milhões traz uma variação baixa o suficiente para ser confiável. E nesse caso pude identificar que o problema era sim mais complexo, visto que o tempo de execução para 200 milhões de vezes levou em média 7,47 segundos a mais que o problema de um único dado.

CINCO DADOS

A inferência que tive até este momento é de que a complexidade do problema influi muito pouco na quantidade de iterações a serem realizadas, mas para ter certeza eu fiz o teste com 5 dados. A maior probabilidade de resultado encontrada ao rolar cinco dados são os valores 17 e 18, tendo 10,03% de chances de ocorrer.

RolaCincoDados <- function(iteracoes)
{
# Cria o vetor com os valores possíveis para o dado
dado = 1:6
resultado = 0

# Aloca os resultados das rolagens dos dados
primeira_rolagem = sample(dado,iteracoes,replace=T)
segunda_rolagem = sample(dado,iteracoes,replace=T)
terceira_rolagem = sample(dado,iteracoes,replace=T)
quarta_rolagem = sample(dado,iteracoes,replace=T)
quinta_rolagem = sample(dado,iteracoes,replace=T)

# Soma os vetores, item a item
resultado = primeira_rolagem + segunda_rolagem + terceira_rolagem + quarta_rolagem + quinta_rolagem

# Soma todos os valores que tiverem sigo iguais a 18
resultado = sum(resultado == 18)

# Divide o valor pela quantidade de iterações e transforma em percentual
resultado = (resultado/iteracoes) * 100

return(resultado)
}

# Inicializa variáveis
vetor_resultado = 0
vetor_tempo = 0
controle = 0

# Informa a quantidade de iterações a serão executadas
rodadas = 10

# Aloca os resultados percentuais em um vetor de 100 itens e aloca os tempos de execução em outro
while(controle != 100)
{
tempo_inicial = Sys.time()
vetor_resultado = append(vetor_resultado, RolaCincoDados(rodadas))
tempo_final = Sys.time()

tempo = tempo_final - tempo_inicial
vetor_tempo = append(vetor_tempo, tempo)

controle = controle + 1
}

# Mostra os percentuais
vetor_resultado

# Mostra os tempos de execução
vetor_tempo

Compilando os resultados:

E mais uma vez podemos ver que entre 10 e 100 milhões é valor ideal. Interessante notar que esse caso realmente foi mais complexo, levando 35 segundos a mais em média quando comparada com a rolagem de um único dado.

Conclusão

Depois de realizar todos esses testes, é possível concluir que, para a utilização em gerenciamento de projetos, uma quantidade de iterações entre 10 e 100 milhões atenderia adequadamente a necessidade de prever alguma data de entrega.

O valor que tenho utilizado é de 10 milhões, quando vou passar os dados para algum stakeholder. Porém como o processo fica demorado (em média de 30 minutos para rodar com 10 milhões), quando eu preciso verificar os dados no dia-a-dia utilizo algum valor menor (algo entre 100 mil a 1 milhão).

E você? Tem utilizado o método? Se sim, quais valores de iterações têm usado para a análise? Os resultados obtidos tem tido valor para os stakeholders de seus projetos? Caso queira trocar experiências, podemos iniciar um bate-papo por e-mail, através do endereço gabriel.lopes@plataformatec.com.br

The post Monte Carlo na Prática: Encontrando o valor de iterações ideal first appeared on Plataformatec Blog.

O discurso de que a agilidade torna o negócio eficaz (saber priorizar as iniciativas corretamente) e eficiente (ter um fluxo de trabalho e um ferramental que permitam entregas constantes e com qualidade) faz sentido desde que acompanhe uma perspectiva econômica (utilizar da maneira mais otimizada os recursos escassos da organização). A combinação dessas três perspectivas é o que chamo de uma “gestão efetiva” que habilita a formação de um ambiente de excelência.

Não existe um consenso sobre o quão agilmente madura uma organização está. Algumas pessoas são contra medir o nível de maturidade de uma equipe ou empresa, pois creem que o ágil é um tipo de disciplina difícil de sintetizar em uma métrica. A comunidade Kanban tem divulgado um modelo de maturidade chamado Kanban Maturity Model, que tem como premissa desenvolver nas organizações a capacidade de:

• Criar um ambiente que promova a agilidade organizacional;
• Aliviar a sobrecarga de trabalho;
• Atender as expectativas dos clientes;
• Gerar resultados econômicos previsíveis e uma robustez financeira;
• Desenvolver uma capacidade de sobrevivência.

A seguir, gostaria de compartilhar um modelo que tenho utilizado para analisar o nível de competência, capacidade e maestria em ágil nas empresas.

Afinal de contas, o que significa ser ágil?

Em uma frase, resumiria agilidade como: “entregar pequenos lotes, em curtos espaços de tempo a fim de validar hipóteses de negócio, reduzir riscos e responder com rapidez às mudanças de mercado”.

Elaborando um pouco mais a definição, ser ágil constitui desenvolver capacidades que ofereçam agilidade ao negócio. Considerando empresas digitais, é como se a tecnologia e os processos de trabalho criassem um ambiente no qual fosse possível entregar pequenos experimentos dentro de um curto espaço de tempo, a fim de provar hipóteses que gerem eficiência operacional, aumentem a capacidade de geração nas receitas atuais, e propiciem inovações nos produtos e nos processos organizacionais.

Tal definição exige que a empresa seja agnóstica a metodologias, frameworks, crenças e práticas milagrosas. Se você acredita que a partir de um ferramental encantador seu ambiente se tornará ágil, sinto lhe dizer que isso não vai acontecer. Sobre esse assunto, recomendo fortemente a leitura do texto do meu amigo Lucas sobre o porquê nós não somos necessariamente Ágeis, mas com certeza somos ágeis.

Considero que uma cultura ágil é construída dentro de uma empresa a partir da combinação de um alto alinhamento e um alto empoderamento.

Alinhamento quer dizer que a empresa e seus líderes estão plenamente conscientes de onde desejam chegar e conseguem comunicar tal visão de forma clara, objetiva e que engaje a todos. Uma liderança participativa e ferramentas como os OKRs são excelentes alavancas para desenvolver um ecossistema onde as pessoas estejam alinhadas.

O empoderamento é a soma da habilidade (que nada mais é do que a capacidade das pessoas conseguirem executar a estratégia da organização a partir de ferramentas, técnicas e práticas) com autonomia (que é a capacidade das pessoas se adaptarem e se auto organizarem).

Para que a empresa usufrua dos benefícios da agilidade é fundamental que ela desenvolva uma visão sistêmica do negócio a partir de 4 macro etapas. Partindo do pressuposto que os recursos são limitados, torna-se necessária uma análise da viabilidade financeira das iniciativas nas quais a empresa trabalhará, a fim de tomar melhores decisões a partir das oportunidades que podem ser perdidas pela manutenção do status quo.

Após filtrar as iniciativas com a lente estratégica, a empresa precisa compreender se ela possui capacidade operacional para executar o que foi definido como prioridade. Neste momento, a empresa pode cogitar a contratação de terceiros, a capacitação da sua equipe interna ou até mesmo um redesenho da sua estrutura com o propósito de criar células capazes de construir soluções que comprovem as hipóteses de negócio.

Os dois últimos estágios seriam a execução e a entrega. Saber executar com lead times curtos fará com que a empresa valide rapidamente suas suposições e tenha aptidão para mudar de rota quando necessário. Por fim, entregar bem representa disponibilizar o que o cliente precisa com qualidade e rapidez (ex: deploys automatizados, integrações contínuas, testes de integração etc.) e com o mínimo de ruído interno (comunicando os stakeholders da empresa impactados pela entrega da iniciativa) e externo (garantindo que as informações cheguem de forma clara aos clientes e usuários).

Um modelo para analisar a maturidade ágil de uma organização

O modelo que venho utilizando para analisar a proficiência em ágil das organizações leva em consideração 4 perspectivas:

Práticas e papéis

Esta dimensão tem como objetivo compreender se a empresa tem utilizado de forma eficiente os processos e se há clareza dos papéis e das respectivas responsabilidades. Geralmente utilizo as seguintes perguntas para analisar esta dimensão:

• Existe clareza de quais são as responsabilidades dos papéis disponíveis na empresa atualmente?
• O fluxo de trabalho das equipes está visível?
• As equipes possuem políticas explícitas (ex: definição de pronto para ser trabalhado, definição de pronto etc.)?
• Gargalos e filas estão visíveis no fluxo de trabalho das equipes?
• As equipes possuem clareza das principais fontes de retrabalho?
• Práticas de engenharia de software estão sendo utilizadas para manter o código saudável?
• O processo de publicação está automatizado?
• Existem testes automatizados?

Métricas

Este aspecto visa compreender em qual nível a empresa tem utilizado as métricas de negócio e de processo. A essência dessa perspectiva é ir contra a ideia de que métricas moldam comportamento, mas sim reforçar a importância de se desenvolver uma referência comum que promova melhoria e ações para o negócio. As perguntas que uso para esta dimensão são:

• As métricas de negócio estão sendo utilizadas no processo de tomada de decisão?
• As métricas de negócio estão visíveis para todas as pessoas da empresa analisarem?
• As métricas de negócio são utilizadas como referência no processo de definição de uma iniciativa (ex: quais indicadores de negócio serão alavancados pelo projeto X)?
• As equipes utilizam métricas de processo para projetar prazos de entrega?
• As equipes utilizam métricas de processo para analisarem a saúde do processo?

Priorização orientada ao negócio

Quando tudo é prioridade nada é prioridade. Essa é uma frase que tenho utilizado com equipes que têm o desafio de gerenciar o portfólio de iniciativas de uma empresa. Esta dimensão serve como guia para entender se de fato há um processo estruturado de priorização e para isso levanto as seguintes informações:

• Existem critérios claros de priorização?
• A priorização tem levado em consideração as necessidades dos clientes?
• As métricas de negócio são utilizadas no processo de priorização das iniciativas?
• É realizada uma análise das dependências entre as iniciativas antes da finalização do processo de priorização?

Resultado financeiro

esta dimensão tem por objetivo compreender em qual nível a empresa tem mensurado os resultados financeiros das suas iniciativas. Levanto as seguintes informações para analisar este aspecto nas empresas:

• A liderança da organização tem clareza dos objetivos de negócio de cada iniciativa?
• As equipes estão metrificando o resultado financeiro das entregas?
• A organização consegue classificar as iniciativas quanto ao resultado esperado (ex: essa iniciativa gerará maior eficiência no negócio, ajudará a conquistar market share, será uma inovação, antecipará o custo do atraso?)

O modelo acima ajudará você a diagnosticar em cada uma das dimensões qual é a situação atual e se existem problemas que precisam ser tratados.

Tenho observado que uma empresa madura em ágil é aquela que consegue ter:

1. Uma gestão de fluxo eficiente, isto é, que tenha domínio das práticas e dos processos;
2. Saiba priorizar a partir de critérios quantitativos (métricas);
3. Tenha consciência dos riscos e utilize um ferramental para reduzi-los;
4. Entenda as necessidades do cliente e as transformem em oportunidades viáveis;
5. Disponha de uma estrutura flexível e orientada por propósitos;
6. Respeite as individualidades das pessoas e saiba comunicar de forma clara suas responsabilidades (alinhamento de expectativas).

Conclusão

Tentei compartilhar um pouco como nós da Plataformatec temos levado agilidade para os nossos clientes. A proposta do modelo é ser algo evolucionário e que respeite o contexto de cada empresa. Buscamos identificar alavancas que permitirão gerar um ambiente onde haja agilidade no negócio. E você, como tem analisado a maturidade em ágil no seu contexto? Deixe sua opinião nos comentários abaixo.

The post O desafio de analisar a maturidade ágil de uma empresa first appeared on Plataformatec Blog.

Desenvolver uma visão que possibilite enxergar e compreender o todo por meio da análise das partes que o formam é um grande desafio ao lidar com ambientes de incerteza.

Uma das formas de compreender e analisar o sistema de trabalho de uma equipe ágil se dá através das métricas de processo (há uma coletânea de conteúdo bacana sobre o assunto aqui no blog da Ptec).

Entender o fluxo a partir dos dados é uma maneira pragmática de incorporar uma filosofia de melhoria contínua, sem mudanças abruptas e caóticas e de forma transparente para todos que estão envolvidos no contexto (equipe, stakeholders, área de produtos, gestores, etc.). Parafraseando a comunidade Kanban, medir é uma ferramenta que ajudará a evoluir e não revolucionar um processo já existente.

Pessoalmente, eu gosto de quantificar o processo quando estou mapeando a realidade de uma equipe, pois exponho fatos (dados) para discussão e análise. Na minha experiência com equipes de desenvolvimento de software, venho percebendo que ter esse tipo de conduta ajuda a diminuir uma carga subjetiva que possa existir na equipe e é um jeito de confrontar crenças como “não precisamos melhorar”, “não temos problemas no processo” e “atuamos de forma colaborativa”.

No blog post de hoje, compartilharei uma coleção de métricas que ajudarão você a diagnosticar a saúde do proceso de uma equipe ágil.

Premissas

Antes de qualquer coisa, preciso deixar algumas ressalvas quanto ao uso das métricas.

Métricas devem ser usadas para evoluir o processo e não para gerar cobranças e comparações destrutivas.

Não caia na tentação de comparar equipes e medir o desempenho de um indivíduo. Se você ou a empresa no qual trabalha estão interessados em premiar resultados individuais, formulem um método que proponha avaliar o desempenho da pessoa a partir da opinião dos gestores, pares e clientes que tenham interagido com o resultado do trabalho do indivíduo. No caso de recompensar individualmente as equipes por seu resultado, fuja de métricas que não tenham relação direta com o resultado do negócio (ex: do que adianta a equipe ter entregue um número de funcionalidades no semestre sendo que o produto não teve um aumento de receita?).

Compartilho essa premissa para que você e sua equipe não se comportem de acordo como estão sendo medidos. Afinal, já diria Goldratt: “diga-me como serei avaliado e eu lhe direi como me comporto”.

Números sem contextos são perigosos.

Qualquer análise feita sem compreender as variáveis que compõe um cenário se torna superficial, enviesada e pobre. Se alguém lhe contar que o número de funcionalidades entregues em uma equipe é de 10 itens por semana, é possível concluir algo? Tal métrica é boa ou ruim? Qual o significado de entregue para aquela equipe? É software em produção ou entrega em um ambiente de homologação? Bem, pelos questionamentos anteriores é possível concluir que um número solto nada mais é do que um símbolo privado de qualquer significado.

Procure tendências e fuja da precisão. Dada a complexidade que é criar um produto de software, não busque ser determinístico em um mundo que é receptivo por natureza a uma realidade probabilística.

A lógica por trás da última premissa é: vivemos em um ambiente onde há risco, isto é, existe a probabilidade de insucesso em função de algum acontecimento incerto, cuja ocorrência não depende exclusivamente da vontade da equipe. Portanto, é pouco provável que a equipe saiba ao certo o prazo de entrega de uma demanda ou projeto. Ao invés de nos enganarmos com prazos que ratificam que as entregas acontecerão sempre na mesma data e na mesma forma, passemos a analisar o histórico de dados da equipe para projetarmos a chance de entregarmos algo.

As premissas compartilhadas ajudarão você a utilizar as métricas de forma efetiva. O Lucas Colucci escreveu um texto muito importante que apresenta alguns erros comuns ao utilizar métricas de processo.

Diagnóstico do processo

Dada as premissas compartilhadas acima, vamos ao que de fato interessa. As métricas listadas a seguir servirão para você mapear como está a saúde do processo de uma equipe. Como agilista, considero que as visualizações abaixo compõem o painel de análise (cockpit) de um fluxo de trabalho e devem estar disponíveis para que as equipes utilizem como material para a promoção de melhorias no processo (ex: uso das métricas em retrospectivas, análise do processo em reuniões diárias, etc.).

Trabalho em progresso

Monitorar o trabalho em progresso ajudará a equipe a ter consciência de qual é o montante de trabalho que o processo tem suportado ao longo do tempo. Gosto desse tipo de visualização, pois ela demonstra, por exemplo, se as equipes estão respeitado uma política de limite do trabalho em progresso.

No exemplo acima, temos uma situação onde a equipe estava com a quantidade de itens em progresso próximo de 10 por semana até que em determinado momento houve uma reconfiguração no número de pessoas, o que fez com que a quantidade de trabalho em progresso diminuísse. Um insight aqui é que essa visualização apresenta um histórico interessante da equipe, ajudando a identificar momentos em que ocorreram mudanças na estrutura do time, mudanças de rumo (as famosas pivotadas), impedimentos, etc.

Visando estabilizar o processo a partir da capacidade produtiva, é importante que o número de itens em WIP não entre em uma tendência de crescimento. Caso isso esteja acontecendo, é bem provável que a equipe precise de otimizações para que o WIP passe a diminuir. Como agilista, monitorar o WIP apoiará você a reverberar o seguinte mantra com a equipe: “vamos parar de começar e comecemos a terminar”.

Uma outra análise de WIP que tenho começando a fazer diz respeito ao tempo de vida dos itens que estão em WIP dentro de uma determinada semana. Essencialmente, a visualização leva em consideração os itens que estão em progresso naquela semana e contabiliza há quanto tempo eles se encontram dentro do fluxo de trabalho. Para facilitar a leitura do gráfico, faço um agrupamento por categoria onde considero as seguintes faixas: (1) 1 dia em WIP; (2) até uma semana em WIP; (3) de 1 à 2 semanas em WIP; (4) de 2 à 3 semanas em WIP; (5) de 3 à 4 semanas em WIP; (6) acima de 4 semanas em WIP.

Ainda sobre a estrutura da visualização, para as semanas que já passaram, é feita a contabilização e a classificação dos itens que estão em WIP no final do período. Já para a semana corrente, é realizada uma análise dos itens que estão em WIP no momento.

Aplicando em um exemplo, é possível perceber que, na quinta semana de monitoramento do tempo de vida do WIP da equipe acima, existiam dois itens que estavam há mais de um mês dentro do fluxo. Se a equipe, ao acompanhar sistematicamente seu fluxo de trabalho, perceber que as categorias de mais idade estão crescendo é bem provável que um gargalo esteja se formando em alguma etapa do processo e uma intervenção será necessária.

Tenha em mente que WIP representa esforço e energia que ainda não foram validados e quanto mais tempo a equipe passar carregando-o, menos feedback será recebido, mais lento será o processo de validação das hipóteses por detrás das iniciativas que originaram o trabalho e maior será o risco da empresa estar perdendo uma oportunidade de mercado.

Caso queira saber mais sobre WIP, não deixe de ler post Um estudo mais profundo sobre Limites WIP

Tempo de entrega

O lead time é uma métrica importante para que as equipes desenvolvam a capacidade de entender quanto tempo elas têm levado para concluir um item de trabalho. Além disso, equipes que desenvolvem a habilidade de analisar tal métrica conseguem identificar situações que geraram variabilidade no processo (ex: problemas em ambientes, saída de membros da equipe, falta de critérios de aceite claros nas demandas).

A primeira visualização que recomendo estar disponível para a equipe é o gráfico de dispersão do lead time. Ele oferecerá uma ideia se o tempo para que os itens sejam entregues está diminuindo ou não ao longo do tempo.

Conforme ilustrado no gráfico acima, gosto de combinar nessa visualização as seguintes informações: itens finalizados (representados no gráfico pelos pontos em azul) e em progresso (representados no gráfico pelos pontos em vermelho); a média móvel que leva em consideração os últimos 5 itens entregues (esse é um parâmetro totalmente arbitrário); e as informações de percentil 50 (mediana), percentil 75 e percentil 95.

Tais medidas de referência são úteis, pois, a partir do exemplo, trazem a tona constatações como:

• A média móvel tem variado ao longo do tempo.
• Baseado no histórico de itens concluídos, 50% deles foram finalizados em até 10 dias, 75% levaram até 16 dias para serem finalizados e 95% foram concluídos em até 34 dias.

Além disso, o gráfico de dispersão pode gerar respostas para questionamentos como:

• O que a equipe está fazendo para tratar os itens em progresso que estão se tornando casos extremos de lead time?
• O que é possível melhorar no processo para que haja uma diminuição no lead time?

Outra visualização benéfica para entender o tempo de entrega é o gráfico de histograma, pois, ao considerar cada lead time como uma categoria, o mesmo apresenta os dados de uma maneira mais concisa e que permite extrair informação sobre o comportamento da distribuição.

Conforme ilustrado no exemplo acima, o histograma permite que a equipe tenha resposta para indagações do tipo:

• Qual tem sido o lead time mais frequente?
• Os casos extremos de lead time são muito frequentes?
• Qual o formato da distribuição? Há uma concentração do lead time a esquerda ou a direita da distribuição? Existe mais do que uma moda? Geralmente distribuições bimodais representam fluxos de equipes que lidam com mais de um tipo de demanda em seu processo, pois apresentam concentrações semelhantes em diferentes categorias de lead time.

Ritmo das entregas

Medir e visualizar o throughput (vazão) é importante para que a equipe compreenda qual tem sido o montante de trabalho entregue em um período de tempo (exemplo: semana, quinzena, mês), bem como para que ela identifique se há a criação de uma tendência de aumento no número de entregas. Ao perceber que o throughput está em queda, a equipe pode buscar entender quais fatores estão afetando a vazão do processo.

Recomendo sempre que possível a quebra da visualização do throughput por tipo de demanda. Dessa forma, fica explícito para todos se a equipe está conseguindo:

• Equilibrar o número de entregas de valor (ex: funcionalidades) com demandas de falha (ex: bugs).
• Lidar com o urgente de forma sustentável. Volta e meia me deparo com equipes que classificam todo tipo de demanda que entra no fluxo de trabalho como urgente e atuam em cima delas, deixando de lado itens que serão importantes para o negócio no médio prazo.

No exemplo acima a equipe conseguiu equilibrar em grande parte das semanas entregas de história do usuário com correções de bug. Na semanas sinalizadas com as setas em vermelho, a equipe precisou atuar e entregar problemas críticos que estavam afetando a operação da empresa e por isso entregou apenas correções de bugs.

Análise da taxa de entrada e saída do fluxo

Além do uso do gráfico de CFD (escrevi um blog post completo para falar sobre essa visualização), gostaria de apresentar uma análise que não tenho visto muitos agilistas fazerem: relação entre as taxas de entrada e saída do fluxo de trabalho. Basicamente essa visualização compara a quantidade de itens que a equipe se comprometeu entregar com o número de itens entregues ao longo do tempo.

O que esse tipo de visualização pode trazer de insight? Vamos analisar um exemplo.

Baseado na imagem acima é possível fazer algumas deduções:

• Das 27 semanas analisadas, 10 delas tiveram uma taxa de entrada (itens que a equipe se comprometeu) maior do que a quantidade de itens entregues.
• Na semana 17 a equipe teve um pico de itens comprometidos para serem entregues. Isso ocorreu pelo fato da pessoa que era PO da equipe estar em vias de entrar de férias. Falando em estoques, sugiro a leitura do blog post do Guilherme Fré sobre o assunto.

Analisar a taxa de entrada e saída do processo apoiará a equipe no entendimento de se o ritmo de entrega está acompanhando a quantidade de itens comprometidos. Tenho visto equipes assumindo mais do que sua real capacidade. Tal tipo de comportamento gera desconfiança dos stakeholders pelo fato da equipe entregar menos do que é pedido e frustação da equipe por nunca conseguir entregar “tudo”.

Em um sistema perfeitamente estável, a taxa de entrada e saída deveria ser a mesma. Se você e sua equipe conseguirem desenvolver um processo onde na maior parte das semanas as taxas forem equivalentes (ex: para cada 4 semanas, 3 tiveram as taxas de entrada e saída iguais), isso demonstrará maturidade do fluxo de trabalho e representará um contexto altamente previsível.

Conclusão

Incorporar uma cultura que traga dados para sua equipe fará com que você monitore um processo que possui uma natureza essencialmente complexa (software) trazendo visibilidade do progresso para quaisquer interessados no que está sendo construído ou mantido.

Além disso, propor melhorias e evoluções baseadas em dados é um excelente caminho para a remoção de análises subjetivas e, até certo ponto, vazias. No fundo, espero que com esse blog post você, agilista, estimule que as pessoas utilizem menos o recurso do feeling quando estiverem analisando o comportamento do fluxo de trabalho de uma equipe.

Se você busca um material avançado em métricas, recomendo o livro que escrevi sobre o assunto Métricas Ágeis – Obtenha melhores resultados em sua equipe. Aproveite para dar uma olhada nas revisões feitas por quem já leu 

E você? Quais métricas tem utilizado para acompanhar a saúde do processo? Deixe suas experiências nos comentários abaixo!

jQuery( document ).ready(function() {
new RDStationForms(‘nurturing-agile-blog-post-guia-de-um-agilista-analisando-saude-do-processo-1d8b67d69ba6b19eaca3-html’, ‘UA-8268430-1’).createForm();
});

The post Guia de um Agilista: Analisando a saúde do Processo first appeared on Plataformatec Blog.

Características de uma boa métrica de negócio

Primeiramente, uma boa métrica de negócio deve ser comparável. Saber que a taxa de conversão de pessoas interessadas no seu produto para clientes é de 10% não lhe servirá para muita coisa se você não tiver como analisar o comportamento da mesma ao longo do tempo. Como estava a métrica na semana passada? No mês passado? No ano anterior? As conversões estão crescendo? Responder questões como essa permitirão que você possa fazer melhor uso da métrica.

Outra característica importante sobre métricas de negócio é que elas devem ser simples para que todos compreendam o que elas representam.

A métrica de negócio deve também ser uma relação ou uma taxa. A quantidade de usuários pode ser pouco útil, porém, a porcentagem de usuários ativos diários já poderá trazer tendências de crescimento. Razões e taxas são comparativas, o que o ajudam a tomar melhores decisões.

Por fim, lembre-se: métricas de negócio boas se transformam. Se a métrica muda e você não sabe a motivação ou o que fazer com ela, então você tem uma métrica ruim.

Métricas de produto

A seguir, listarei um conjunto de métricas que você poderá utilizar quando tiver o trabalho de analisar os resultados dos produtos de software, porém, sugiro leituras complementares como Lean Analytics e Product Management (uma boa dica de leitura é o livro Gestão de produtos de software: como aumentar as chances de sucesso do seu software do Joaquim Torres).

• Receita recorrente mensal: total de receita gerada pelos clientes que assinam o produto mês a mês.

• Receita recorrente anual: total de receita recorrente gerada pelo produto (ex: soma das receitas mensais gerada pela assinatura do produto).

• Receita recorrente anual por cliente: total de receita recorrente gerada por cada cliente da carteira. Se o valor dessa métrica está subindo, isso representa que você está conseguindo, por exemplo, aumentar o preço do serviço, aumentar o ticket médio no geral ou vender novas soluções aos clientes.

• Receita anual total: total de receita gerada pela organização tanto via produto como via serviço. Geralmente os investidores avaliam as empresas a partir da sua capacidade de geração de receita recorrente, pois prestação de serviço é algo periódico e menos escalável do que a venda de um produto.

• Taxa de conversão: é o percentual entre os pontenciais interessados em seu produto (leads) e os que acabam efetivamente se tornando clientes. Quanto maior for a taxa de conversão, maior será a capacidade de monetização do seu produto. Outra variável importante de analisar em conjunto da taxa de conversão é o tempo no qual um lead levou para se tornar um cliente. Neste caso, quanto menor o tempo mais otimizado estará o funil de conversão dos leads em clientes.

• Custo de aquisição do cliente: é o custo total de aquisição de clientes (CAC). É possível considerar o CAC a partir de duas perspectivas: (i) custo para a aquisição de qualquer cliente do produto; (ii) custo para a aquisição dos clientes oriundos de investimentos feitos em marketing. Ao calcular o CAC total como um custo que inclui os clientes adquiridos organicamente ao invés de isolar clientes adquiridos através de marketing “pago”, você deixa de saber o quão bem suas campanhas pagas estão funcionando e se elas são lucrativas. É por isso que os investidores consideram que o CAC pago é mais importante do que o CAC misturado na avaliação da viabilidade de um negócio, pois ele informa se uma empresa pode escalar seu orçamento de aquisição de usuários de forma lucrativa.

• Evasão (churn): indica a média de cancelamentos de assinaturas dos clientes de uma empresa, assim como as perdas financeiras que elas representam, em determinado período. Pode ser calculado através de um taxa do total de clientes cancelados dividido pelo número total de clientes ativos do último mês ou pela receita recorrente mensal gerada pelos clientes cancelados dividido pelo total de receita recorrente mensal.

• Número de usuários ativos: pode ser considerada uma métrica que não ajuda na tomada de decisão dado que você pode ter muitos usuários ativos que não geram receita, porém, tal métrica pode ser útil como forma de entender o engajamento da solução no mercado.

• Relação entre clientes pagos e o total de usuários: é o percentual entre os clientes pagos (geradores de receita) e o total de usuários do seu produto. Se o seu produto possui diferentes planos, tal métrica pode ser útil para analisar, a partir da base total de usuários, a representatividade de cada plano a partir do total de usuários pagos. Ex: Caso seu produto possua uma base de 5.000 usuários sendo que 4.900 fazem parte de um plano “free”, apenas 2% (100) dos clientes compõe os planos pagos.

Conclusão

As métricas discutidas acima ajudarão você e a sua a equipe na tomada de melhores decisões quando estiverem discutindo qual funcionalidade trará maior resultado para o negócio e, principalmente, servirão como um guia para análise da saúde dos produtos que estiverem sob a tutela da empresa.

E você, tem visto algum tipo de métrica diferente das comentadas? Não deixe de compartilhar nos comentários abaixo sua opinião.

The post O que seriam boas métricas para produtos digitais? first appeared on Plataformatec Blog.

Neste post, compilei os erros mais comuns que os times cometem quando usam métricas, assim você saberá o que evitar quando adotá-las.

1 – Não ter reação

Se você coleta métricas, você precisa usá-las de alguma maneira. Portanto, um dos erros mais comuns é não reagir ao que as métricas apontam. Métricas podem lhe dar insights e, para reagir, você precisa entender como elas funcionam e o que significam.

Para mais informações sobre como usá-las, dê uma olhada nesses posts:

• Cumulative Flow Diagrams e Lead Time Breakdown
• Throughput e gráfico de Burnup
• O que Lead Time fala sobre seu projeto

2 – Usar métricas com poucos dados

Outro grande erro é utilizar métricas quando não existem dados suficientes para suportar suas conclusões. No começo de um projeto, ou quando começamos a coletar métricas, geralmente ficamos ansiosos para melhorarmos nosso processo. No entanto, com uma quantidade baixa de dados, as métricas não são tão confiáveis.

Uma boa dica seria observar o comportamento dos dados e verificar se algum padrão já se formou. No caso de ter um padrão, você provavelmente já pode começar a usá-las e atuar em cima dos dados.

É importante notar também, que esse não é o único método, mas em geral, eu esperaria no mínimo 3 semanas para começar a questionar o processo. — Mais sobre como agir baseado em métricas pode ser encontrado em nossos blog posts.

Uma possível saída, caso você tenha um projeto curto e precise de métricas o quanto antes, seria utilizar métricas diárias. Temos um post falando sobre isso também: Pros and cons of using daily metrics

3 – Usar métricas sem considerar o contexto

Esse é um erro muito comum, não só no desenvolvimento de software, mas em toda conclusão construída estatisticamente. Números sozinhos são usados apenas em álgebra ou cálculo. Você precisa do contexto nos quais os números estão inseridos para entendê-los. Com isso em mente, para dizer se a vazão do seu projeto está saudável ou não, para entender se a variância do seu lead time é muito grande ou não, observe. o. contexto.

4 – Comparar métricas entre times

Esse problema está de certa forma relacionado com o 3. Não faz sentido falar algo como “time A está melhor que o time B pois eles têm uma vazão maior”. E se o time A possui 10 pessoas enquanto o time B possui 3? E se o time A trabalha com o desenvolvimento simples de um website e o time B com algum deep learning complexo? Tenha cuidado.

5 – Ter métricas individuais

Esse é um problema de microgerenciamento e está relacionado com os erros 3 e 4. Pessoas, tentando melhorar o máximo possível o processo, acabam medindo métricas de indivíduos. É praticamente impossível comparar pessoas diferentes. Apenas não o faça. Se o fizer, estará afetando o ambiente do seu time e vai até diminuir a produtividade geral. Além disso, as métricas do processo devem ser usadas para entender a saúde do processo.

6 – Simplificar demais a leitura das métricas

Ainda relacionado ao contexto, mas agora com o contexto dos números. Por exemplo, se você comunica às outras pessoas que um time entrega em média 4 histórias por semana, é só isso, você não está dizendo nada do time. Talvez os dados sejam {0, 0, 0, 0, 0, 24}, talvez sejam {4, 4, 4, 4, 4, 4}. Então, tenha certeza que você não está simplificando demais a leitura das suas métricas e que todo o seu ferramental constrói a imagem que você está tentando desenhar.

7 – Usar apenas as métricas convenientes

Relacionado ao erro anterior, pessoas reportam as métricas para seus gerentes/diretores mostrando apenas os “números bons”. Então, se a vazão aumenta, você mostra apenas a vazão. Se o backlog diminui, você mostra apenas isso. Seja transparente. Caso contrário, eles estarão vivendo uma mentira e, quando a verdade vier à tona, você não conseguirá se explicar.

8 – Usar apenas os dados convenientes

Outro problema é usar apenas métricas com os dados que você quer. Recortar os dados para ter resultados mais relevantes, como considerar apenas os últimos 2 meses em um projeto de 10 meses, pode fazer sentido já que o contexto de um projeto muda com o tempo e você quer ter certeza que está considerando o contexto certo nos seus resultados. No entanto, tenha cuidado quando fizer isso, pois você pode estar escondendo muitas informações úteis de você mesmo.

9 – Falsificar métricas

Este é de longe o mais comum que vejo. Pessoas tem medo de mostrar os gargalos ou problemas e mascaram resultados (às vezes sem perceber). Agrupam histórias para diminuir backlog, quebram histórias desnecessariamente para aumentar a vazão ou até mesmo mudam pontos de história (quando os usam) para manter a velocidade do time “constante”. Com isso, você está apenas enganando você mesmo e não está melhorando o processo.

10 – Ter metas baseadas em métricas

Esse é um assunto muito polêmico. As métricas não foram feitas para serem metas. Foram feitas para ajudar o time a entender como o processo está e tentar melhorar o fluxo. Metas relacionadas à métricas podem colocar muita pressão no time e ter o efeito contrário ao desejado, fazendo com que o time cumpra uma métrica mas desregule todo o processo. Então, antes de definir uma meta com base em métricas, pense se a meta precisa ser tão “baixo-nível” e, caso precise, confirme com o time se é possível, de fato, atingir essa meta ou se existe algum impedimento inerente ao precesso.

11 – Tentar diminuir o lead time à todo custo

Lead time (LT) é uma métrica que serve para entendermos quanto tempo um item leva para passar por todo o processo. Então, existem duas perguntas que podem ser feitas aos dados:

• O LT está muito alto?
• A variância do LT está muito alta?

A segunda pergunta é muitas vezes mais importante para o time do que a primeira. Ter um LT com distribuição {0, 5, 2, 8} é geralmente pior do que ter uma como {4, 4, 4, 4}. Na primeira os dados não são confiáveis o suficiente para se ter uma predição assertiva, enquanto no segundo você tem maior probabilidade de acertar. No entanto, não esqueça de olhar para o seu contexto!

12 – Tentar aumentar a vazão ao invés de focar na eficácia

Ser eficaz é fazer a coisa certa. Vazão não é importante se você não está fazendo a coisa certa. Então, foque no seu produto, no que é melhor para ele, antes de se importar com o quão rápido você entrega.

O que achou desses erros? Já cometeu algum deles? Deixe seus comentários abaixo!

The post 12 Erros comuns no uso de Métricas de Processo first appeared on Plataformatec Blog.