*As a disclaimer, when I mention “CTO”, I want to talk about whoever is in charge of technology, “CPO” as the head of products and “CEO” as the strategy person. Depending on the size and culture of your company, one person might have more than one of those roles.

CEO and the burnup-chart

The CEO will probably not have time to read all of your metrics and understand them. However, they need enough information to plan for the future.

We usually present the burn-up chart. It contains a good summary of the team’s progress and, more important than that, it displays forecasts for each planned release.

CTO and failure demand

To your CTO, I believe that, other than clear information on how many stories the team is delivering, the most critical metric is the percentage of time/throughput spent with bugs and chores. With it, he/she can evaluate the codebase quality and act upon it.

CPO and lead time

Another relevant piece of information that you may need to share is lead time statistics, not with the CEO/CTO, but with the CPO. That person needs to know how long it takes to implement and deploy a new feature. Otherwise, the company might live under constant pressure and with the familiar feeling that the technology department never meets the product goals.

General reports

Sometimes, we’ll find ourselves having to report what we’ve done. Maybe stakeholders haven’t seen many changes in the last weeks, or perhaps that’s just how things work in your company. It may happen due to many backend tasks, because you had to refactor something, etc. Either way, what I always try to do in those cases is to explain the task goals business-wise. Here are some examples:

Update rails ~> We had to update our rails version to improve the security of our app and guarantee that our customers’ information is not threatened.

Refactor bad_code.rb ~> We had to use some time rewriting and dividing this file because it was common to have to change things in it, and each time we had to do so, we spent days trying to understand it and being careful not to break anything. Therefore, doing this, we expect to improve our development efficiency and deploy future features faster.

Conclusion

Different roles need different information to accomplish their goals. Don’t overwhelm people with data they don’t need. In the end, even though it may seem counter-intuitive, you can increase the visibility by decreasing the amount of information you give.

What do you think? Do you agree with us? Leave your comments below!

The post How to report metrics to C-level executives first appeared on Plataformatec Blog.

Here I compile the most common mistakes that teams are committing when using metrics, so you’ll know what not to do when adopting them.

#1 – Being reactionless

If you collect metrics, you need to use them somehow. Therefore, one of the most common mistakes is doing nothing about the metrics you are seeing. Metrics can give you process improvement insights and, to react, you need to understand how they work and what they mean.

For more information on how to use them, check these blog posts:

• Cumulative Flow Diagrams
• Throughput and Burn-up Charts
• Lead Time

#2 – Using metrics with few data

Another mistake is to use metrics without enough data to support them. At the beginning of a project, or when you just started using metrics, we are often anxious to start gathering results from them. However, with a low amount of data, metrics aren’t that trustworthy. A good hint is seeing if they are still changing over time or if they are steadier… When the latter happens, you are probably ready to start analyzing them and act based on results. More on how to act can be found on our metrics blog posts.

Another hint would be to try daily metrics, check our blog post on them: Pros and cons of using daily metrics

#3 – Using metrics without considering their context

This is a very common mistake, not only in software development but with every statistically built conclusion. Numbers alone are used just for algebra or calculus. You need the context in which they are inserted to understand them. With that in mind, to say if your throughput is healthy or not, to understand if your lead time variance is big or not, look. at. the. context.

#4 – Comparing metrics between teams

This problem is related to number 3. It doesn’t make any sense to say something like “team A is doing better than team B because they have a greater throughput”. What if team A has 10 people and team B has 3? What if team A is working in an easy website development while team B is working with complex deep learning stuff? Be careful.

#5 – Having individual metrics

This is a micromanaging problem. People, when trying to improve as much as possible the process, end up measuring individual metrics. This problem is related to #3 and #4. You cannot compare different people. Just don’t. If you do it, you’ll be harming your team’s environment and will even decrease their productivity. Moreover, the process’ metrics should be used to understand the health of the process.

#6 – Simplifying metrics reading too much

Still related to context, but now the numbers context. If you tell other people that a team delivers on average 4 stories a week, you are saying nothing. Maybe its delivery data is {0, 0, 0, 0, 0, 24}, maybe is {4, 4, 4, 4, 4, 4}. So, be sure that you are not simplifying your metrics reading. Make sure the whole toolset builds the image that you are trying to draw.

#7 – Using only the metrics you want

Related to the error before, sometimes we see people having to report their metrics to higher management showing only “good numbers”. So, if your throughput increases, you only show your throughput increase. If your backlog decreases, you just show that. Be transparent. Otherwise, they will be living a lie and, when the truth comes up, you won’t be able to explain yourself.

#8 – Using only the data you want

Another related problem is using metrics with only the data you want. Cropping your data to get only relevant results, like in a 10-month project consider only the last 2 months, may make sense since the context of the project changes with time and you wanna make sure you are getting the right context in your results. However, be very careful when doing that because you may actually hide a lot of useful information from yourself.

#9 – “Cooking” metrics

This is by far the most common thing I see. People are afraid of showing bottlenecks or problems and end up masking their results. People group stories into one to diminish their backlog, break stories into more to increase their throughput or even change story points to keep their velocity. With that, you are only fooling yourself and not improving your process.

#10 – Having metrics-based goals

This is a controversial topic. Metrics weren’t made to be goals. They were created to help the team understand the process and try to improve its flow. Metrics-related goals may put too much pressure on the team and have the opposite effect on them, making one metric reach the desired goal but affecting others. Therefore, before defining a metric-based goal, consider if it needs to be that “low-level” and, if it does, confirm with the team if it is actually possible to reach that goal or if there’s some process inherent impediment to it.

#11 – Trying to decrease lead time at all costs

Lead time (LT) is a metric used to understand how long an item takes to pass through your process. So, there are two different questions you can ask the data:

• Is the LT too big?
• Is the LT variance too big?

The second is often much more important to a team than the first. Having an LT distribution of {0, 5, 2, 8} is usually worse than having one like {4, 4, 4, 4}. That because, in the first, your data is not reliable enough to make predictions, while in the second you have a better probability of getting it right. However, don’t forget to look at your context.

#12 – Trying to increase throughput instead of being more efficacious

Being efficacious is doing the right thing. Throughput is not important if you are not doing the right thing. So, focus on your product, on what is best for it, before caring about how fast you will deliver it.

What do you think of these mistakes? Have you ever made one of them? Leave your comments below!

The post 12 Common mistakes when using Process Metrics first appeared on Plataformatec Blog.

Society is defined not only by what it creates but by what it refuses to destroy. – John C. Sawhill

Before we start, if you are not familiarized with the terminology, here is a short explanation:

• Soft Skills: personal attributes that enable someone to interact effectively and harmoniously with other people (Google).
• Hard Skills: specific, teachable abilities that can be defined and measured, such as typing, writing, math, reading and the ability to use software programs (Investopedia). In this case, we are using the analytical part of it.

The rise

Before the agile mindset, project managers used to apply the classical engineering style to handle software projects. The PMBOK (Project Management Body of Knowledge) was, and still is, the source of very good practices and tools for project management. And most of them work in regular industries, the ones that are not as organic as the software area.

However, the software industry misused the PMBOK. They thought all the practices that are mentioned in it were too hard-skilled and wouldn’t work in a fast-paced environment as the software industry. And yes, it has all those hard-skilled practices (and some of them do not work with software development), but they were all glued together by team-building actions that people ignored at the time (some of which can be seen in the Human Resources chapter). But, as I presented in the aforementioned blog, a revolution took place, and made the industry crucify and bury those practices, without even look if they were all really that bad. As a result, they saw themselves tool-less and decided to react and build their own tools.

The death

With that, came all the Agile methodologies and their toolsets. Moreover, since the industry lacked soft skills at that time (the trend was to act like bosses: telling other people what, when and how to do stuff), a natural path for the revolution was clear: improving soft skills.

And it happened! At least the new practices facilitate that… if people apply it or not on a daily basis, it’s another story. With that mindset in place, the boss image was abandoned and leader figures were created. Focusing on the code quality and not so much on documenting everything. Letting developers get much closer to product stakeholders than before because that communication between them needs to be proxy-less (in a perfect world at least).

But things were still not smooth. Most companies started using Scrum, improved their process, but reached a stagnation point in which something was wrong, but they didn’t know what. The team felt better, working this way, but it was more difficult to spot problems in the process. Talking about deadlines with clients became taboo. And scrum masters would basically annoy the business area of the companies, which wanted predictions to improve their plans.

Basically, the process improved inward: the development team was happier and more effective. But they forgot to improve the technical communication outward: with other areas, with business, marketing, clients, etc. These areas need more data about the software in order to build their plans. And with that in mind, some hard skills, that got lost years ago, came back.

The rebirth

At Plataformatec we embraced hard skills, as most of our agile blog posts show it. We think that having good and advanced hard skills is not a sin, we can and should have as many metrics as possible. However, with metrics, comes great responsibility (this is somehow familiar… ).

Metrics serve as a way to ease the conversation between areas (or with an external client) and to improve our processes inside the team as well. For both, we need to be cautious and not present loose metrics (showing them without the proper explanation and contextualization). If that happens, they can become a way to demand more work and to micromanage the team’s deliveries, which, usually, is not healthy. (Another post on the common mistakes when using metrics is on its way…)

If you wanna take a step further and improve your hard skills toolset, you can take a look at our free Monte Carlo spreadsheet, which uses Monte Carlo simulations to inform you the probability of finishing your project in each of the next weeks!

So… Which one is more important?

Both are extremely important. Soft skills without hard skills make the team happy at work but probably inefficient. Hard skills with no soft skills make the team aware of their problems but with no motivation to change. We need to balance both. I’ve already heard questions like: Oh but should it be like, 50/50? 80/20? And I answer with this question: How would you even measure how much soft skills and hard skills you have?!

So, the conclusion is: have both, improve both, care for both. If you think you already have enough of each, you are likely wrong. This should be the mantra of all project managers/Agile coaches out there… You must have a motivated team and enough data to facilitate communication and improvement.

What about you? Do you prefer one skill over the other? Leave your comments below!

The post Hard skills on project management first appeared on Plataformatec Blog.

• Forecasting software project’s completion date through Monte Carlo Simulation
• Lead Time Experiment: Calculating Lead Time of the whole process
• Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits

Another experiment that we did was to analyze the metrics that we generally use, however, instead of tracking them on a weekly basis, doing it daily. The project was supposed to be very short and weekly metrics would have shown us the problems when it was already too late to act. The intention here was to see if with a shorter feedback cycle, the metrics would make us notice problems faster: like bottlenecks, queues etc.

If you are not aware of the metrics we use, here are some blog posts about them:

• Why we love metrics? Cumulative flow diagrams
• Why we love metrics? Throughput and Burnup charts
• Why we love metrics? Learning with Lead time

We will present next our opinion on the effectiveness of using each one of those metrics on a daily basis.

Cumulative Flow Diagram (CFD)

The daily CFD was the most used daily metric for us. In the first weeks, it was too difficult to find bottlenecks only by seeing the weekly metrics. But as you can see on our daily CFD chart, we spotted some queue growth throughout our project and could act on them on a daily basis to avoid losses.

Burnup chart

We didn’t use much the daily burnup chart, but we believe that it can be very helpful in case your client and/or product owner want faster feedbacks on how the project health is.

It is possible to see that the backlog changed on a daily basis in the beginning of the project, that information could help the stakeholders take faster actions to mitigate possible delays.

Throughput and Predictions

Our Monte Carlo simulation didn’t work well with “daily throughputs”, that are actually the number of deployed stories per day. That happened because, if you remember how we use Monte Carlo from our blog post Forecasting software project’s completion date through Monte Carlo Simulation, we base our simulation on our throughput history. Moreover, if you see our throughput histogram, you’ll be able to notice that on most of the days there weren’t deploys, which means that the simulation would be extremely pessimistic and skewed to zero.

Conclusion

At the beginning of projects, we usually feel we don’t have enough data to make decisions, but if you start gathering data on a daily basis you might have enough information to perform fast changes on your process and guarantee an even better cadence to your deliveries.

At the end of the project, after we already had enough weekly input, we abandoned the idea of a daily metric. We did that because with the progress of the project, the daily data became more noisy than helpful, and the weekly data was already reliable enough. Therefore, this approach seems to work best at the beginning of a project.

What do you think of daily metrics? Would you use them? Leave your comments below!

The post The pros and cons of using daily metrics first appeared on Plataformatec Blog.

• Forecasting software project’s completion date through Monte Carlo Simulation
• Lead Time Experiment: Calculating Lead Time of the whole process
• Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits

Outro experimento que fizemos foi registrar algumas das métricas que usamos normalmente mas, ao invés de fazer o registro semanalmente, registrá-las também diariamente. A intenção era ver se uma atualização mais rápida das métricas nos faria perceber problemas mais rapidamente também, como gargalos, filas e etc.

Se você ainda não conhece nossas métricas, aqui estão alguns dos nossos blog posts que explicam-nas:

• Why we love metrics? Cumulative flow diagrams
• Why we love metrics? Throughput and Burnup charts
• Why we love metrics? Learning with Lead time

A seguir, apresentamos nossa opinião sobre a eficiência e eficácia de usar cada uma dessas métricas diariamente, através das visualizações que utilizamos.

Diagrama de fluxo cumulativo (Cumulative Flow Diagram – CFD)

O CFD diário foi a visualização diária mais usada. Nas primeiras semanas era muito difícil de acharmos gargalos apenas analisando as métricas semanais. Mas como você pode ver em nosso gráfico de CFD diário, nós avistamos algumas filas se formando ao longo do projeto e conseguimos mitigá-las para aumentar nossa eficiência de processo.

Gráfico Burnup

Nós não usamos muito o burnup diário, mas acreditamos que seu uso pode ser interessante quando seu cliente ou P.O. necessitar de feedbacks mais rápidos em relação à saúde de seu projeto.

É possível observar que o backlog mudou diariamente no começo do projeto. Tal informação poderia ajudar stakeholders a tomar ações mais rapidamente para mitigar possíveis atrasos de entrega.

Vazão e Predições

Nossa simulação de Monte Carlo não funcionou muito bem com a vazão diária, ou seja com o número de histórias finalizadas por dia. Isso aconteceu porque baseamos nossa simulação no histórico de vazão semanal (mais detalhes podem ser vistos em Forecasting software project’s completion date through Monte Carlo Simulation). Além disso, ao observar o histograma de vazão, perceberá que na maioria dos dias não ocorreram entregas, o que significa que a simulação seria extremamente pessimista e enviesada para zero.

Conclusão

Sabendo que o início de um time ou projeto é naturalmente um período de estabilização do processo, é comum a falta de dados para a tomada de decisão. No entanto, se começarmos a colher dados diariamente, podemos ter informação suficiente para aplicarmos mudanças rápidas em nossos processos e garantir uma melhor cadência nas entregas.

O que você achou das métricas diárias? Você as usaria? Deixe seu comentário abaixo!

The post Os prós e contras de usar métricas diárias first appeared on Plataformatec Blog.

One of the most common challenges that you will face in your career, or even in your life, is to choose one thing over another. It could be a decision between going out to eat at a sushi place and a pizzeria, or it could be between a 2-month-long software project that costs $1M and a 10-day-long project that costs $10K. The fact is: we spend a long time deciding the best path.

source: xkcd

What is cost of delay

Cost of Delay (CoD) is the economic impact of a project’s delay. In other words, it is how much you will fail to make if the product, or feature, is not ready on a certain date. The benefit of using it is to be able to make more-informed and better decisions because you’re taking into account the economic impact.

How to calculate cost of delay

To calculate CoD you can just estimate how much profit is expected from the software project’s result after a period of time.

Let’s say you expect that the software product you are developing, once finished, will give the company a return of US$ 10,000 per week. In that context, the cost of delay is US$ 10,000/week. In other words, for every week that the project is delayed, the company would be losing US$ 10,000. Not that good, uh?

Another metric related to cost of delay is CD3 (Cost of Delay Divided by Duration). The difference between both is that in CD3, we divide CoD by the duration of the project. That can be a good metric for prioritization. Here’s how to calculate it:

• Calculate the expected project’s weekly profit (CoD);
• Calculate, approximately, how much time it would take to implement it;
• Divide the profit by the estimated project duration;

The higher the CD3 value is, more important it is, since the return on the investment will be faster.

Types of cost of delay

Standard Curve

In standard curves, the CoD of the project grows almost linearly with time. This is the simplest CoD to calculate, since it does not change with time.

Urgent Curve

In urgent curves the project needs to be delivered really fast in order to generate value to the company, otherwise a lot is lost. This happens, for example, when you know of a competitor’s big launch and there is not much time to react and compete in the market. The CoD will probably be extremely high starting on the deadline week and increase just a little over time.

Fixed date curve

Fixed date curve is the classic example of a project in which the deadline is immutable. In this case, the CoD is highly linked to a specific date. The urgent curve example is also valid here if you know of a competitor’s launch beforehand. Another example is when there is a national TV advertisement scheduled for a certain date, or even the implementation of new legislation that will affect the project. In this case, the CoD calculation will be a little bit more complex. In the first weeks the CoD will be growing at a moderate rate, however, after a certain week, the cost receives a huge increase, and after that, it returns to have a small growth rate.

Intangible curve

The intangible curve covers those projects that have a low CoD. In this case, the projects usually have low priority inside the company, because they cause little or no impact on its results. The CoD in these cases is almost static, since there is not enough risk on delaying the project.

How to use it

Besides the obvious outcome of using CoD, that is the knowledge of how much you will lose weekly if the project gets delayed, it is possible to use it as a decision-making tool to prioritize projects.

Example

Let’s say you have two software projects: A and B. Both with standard-curve CoDs.

One may think, based on the projects’ details, that project A is more important than project B. However, if you calculate the CD3, you will see that CD3_A = 138.8 while CD3_B = 200.

But what does that mean? It means that if you work on software B first, you will anticipate revenue generation when compared to starting with software A. Don’t believe it yet? Here is a 75-week simulation:

Attention Point

It is important to notice that the CoD curve that a project follows may change with time. To illustrate that, let’s say that a software that will bring a never-seen-before product to the market is running. Since there is no competition, it follows a standard curve. However, after a year of development, some news arrives and the team discovers that a competitor is now developing something with the same features, and will launch it on day X. From now on, the project’s curve will probably follow the fixed-date, with the steep line being on day X.

Conclusion

You can, and should, use CoD every time you are in doubt on how to prioritize two or more projects. It is an easy to calculate method and, by thinking about all those details, it may give you even more insights about the projects.

If you discover that you need to launch your product sooner, after calculating the CoD, and you don’t have enough time or people, contact us to learn more about how we’ve been helping our clients on developing high-quality custom software, written in either Elixir or Ruby, and what we can do for you.

What about you? What do you think about using cost of delay to help you prioritize projects? Leave your comments below!

The post Calculating Cost of Delay for software projects first appeared on Plataformatec Blog.