The development of a digital solution requires a continuous process of improvement. From conception and requisite mapping, to the actual development of an implemented solution, the success of a project is identified by the health and stability of its elaboration progress.
Project metrics arise as a set of indicators responsible for showing interested parties the information necessary for decision making, which assist in identifying points of attention.
The purpose of this article is to raise awareness to the importance of these metrics, in addition to addressing the main methodologies used by the market. Thus, we will open the doors to those who seek to satisfy the wishes of his/her customers, investors and others interested in the progress, status and delivery estimates of their digital projects.
The development environment for a software product can be unpredictable.
Some demands and features become priorities, like urgent bugs that must be resolved, and even so, the progress of the digital solution must continue at a healthy and consistent pace. Disorganization and lack of coordination make this environment increasingly chaotic, and the waste of resources is inherent in the absence of managing this entire process.
Controlling the health of the development of a digital solution and making increasingly sound decisions are some of the biggest challenges in software engineering, even in the most mature and traditional companies. It is the type of work that requires lots of learning and analysis. It is impossible to conclude it without transparency and alignment of objectives.
To quote one of the leading experts in quality consulting, H. James Harrington: “If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.”
Even with the measurement of processes as a key activity to continuously improve the quality of digital products, it is identified in several companies, of different sizes and origins, a poverty in the acquisition, monitoring and intelligent usage of tools and a culture of measuring the progress of projects .
As a result of this lack of control, there is a high degree of unpredictability in product progress and one can lose the ability of accurate risk management.
In addition, anxiety can be a clear result of unmonitored projects. Without measurements, it becomes almost impossible to clarify whether the resources are being used in the most efficient way and whether, in fact, the deadlines will be met.
While it is essential to communicate the results of what was invested, the habits of measuring performance and project progression also help technical leaders to make better decisions. More than that, they even allow margins of effort and delivery pace to be given to those who actually build the solution.
If, on one hand, we conclude that it is extremely important to know what is happening in our project, there are still doubts about what to measure and what would be the best way to do it.
If we are looking to show stakeholders the progress of the project and, at the same time, have control of the team’s delivery performance, three main points must be monitored:
These indicators are only obtained when we track the quantity, time spent, frequency and quality of activities delivered by the team. For this, we need to generate this data, track it and analyze it.
Typically, this is done by computing the progress and status of each of the activities being performed on a daily basis.
Kanban, for example, facilitates monitoring. The following is a basic example of Kanban, which allows you to track activity states in developing a product.
Having a cake recipe for all projects in the same company is not the right way to adopt measurement habits. What makes sense for some projects may not matter for others, as each project has its own peculiarities.
It is the project leaders’ role to map out in advance what are the resources, materials and data that make sense for monitoring the progress of a project.
However, there are some market patterns that dictate which indicators, reports and charts are most relevant. The main delivery objects are:
Below, you can see a compilation of these annotated analyses, which will be covered in detail in a future post.
If you’ve decided to start implementing reporting routines on project metrics, you can start by mapping out what should be measured. It is essential that they are aligned with the expectations of these reports, in order to know how often you need to generate them and what makes sense to be in them.
After mapping the metrics, the next step is to include the habit of generating this data in the culture of the development team. For example, through the correct use of a Kanban tool.
Building a metrics report, especially at the beginning, is often an evolutionary process. Through the feedback from those involved, it will be possible to arrive at a concise document that allows safer and more accurate decisions to be taken.
In the next article of this series of agile metrics, the most used graphics and I will present, in detail, the most common tools and graphs in the monitoring process. In addition, I will also address what are the most common and interesting ways to present these agile metrics to stakeholders.
Follow us not to miss it!