How to measure software team productivity

Why it's important

Applying Function Point Analysis at a granularity incompatible with productivity variability in indicators, which use it as a basis for measuring production, is one of the main causes of failure in initiatives that seek the benefits of functional software measurement. "APF does not work" is the residual stigma for those involved in these situations. This article is important to better understand how APF can be used consistently in team evaluation.

When it applies

The material (from 2015) is still current (in 2020), because with the advent and awareness that Agile development is not a "fashion", but something that came to stay, performance monitoring becomes even more relevant than the Applications of APF for estimates.

Summary published in July/2015 in FATTO Magazine in focus Year 01 I Nº 01

"Often the interest is not to evaluate whether a team is productive or not, but: how much more productive does the team need to be? how is the performance compared to others in the market?"

Organizations that develop or hire software development should have as one of their goals to achieve maximum levels of productivity in the teams mobilized in these initiatives.

To this end, there are important reflections that must be made by the executives responsible for managing development in these organizations. They are: knowing and evaluating different alternatives to ensure that those teams are productive, and have strategies on how to improve the group's performance to achieve higher levels of efficiency and quality.

All the reflections mentioned will be discussed in this article.

What does it mean for a software team to be productive?

People ask me, "What does it mean for a software team to be productive?". The answer: "It's a team that produces results!". That answer seems too simple as Deep Thought's classic "42" answer in The Hitchhiker's Guide to the Galaxy when asked about the answer to the question for life, the universe, and everything else. So we can explore this question a little further before reaching a conclusion.

The term Software may refer to a variety of different products that have different natures, such as computer programs, configuration scripts, user interface specifications, requirements documents, design and architecture plans, test cases, among other software representations. Therefore, when performing productivity planning and evaluation, it is necessary to establish a broader and more complete overview in order to consistently assess how productive a team is when compared to a reference scale.

The reference scale is a necessary part of this panorama, because often the interest is not to evaluate whether a team is productive or not, but: "how productive is the team? how much more productive does the team need to be? how is the performance of the team's productivity compared to others in the market?".

If management chooses a reference scale based on a business perspective, rather than a technical perspective (which requires much more details about the design and implementation of the software, problems relating to these already resolved and refined items at a level that allows for their detailed understanding), then the appropriate choice is functionality

delivered or impacted by a project. For software maintenance activities, this is possible in certain cases, and the functionality in the scope of that maintenance activity would be functionality added, deleted, modified, or tested by the associated project.

"There are maintenance activities where the result of its realization is not associated with the production of something new or the improvement of something existing. In such cases, the result is associated with maintaining service levels offered by the software product in production"

Maintenance and productivity activities

There are different types of software maintenance activity. These include fixing bugs in incident resolution, introducing improvements that modify the configuration of the features offered by the software, updating a product to support a new hardware or software technology, etc. You can measure the productivity associated with all of them. However, first, you must determine what you expect to receive and what results are relative to each type of maintenance.

There are maintenance activities in which the result of its realization is not associated with the production of something new or the improvement of something existing. In these cases, the result is associated with maintaining service levels offered by the software product in production. The main interest of administration in these cases is responsiveness in a short period of time. For this, there must be availability of resources even if there is not necessarily work planned to mobilize these resources. Maintenance activities like this are bug fixes (when they are no longer covered by warranties), the provision of third-level help-desk services, and other application support activities after their transition from development to full production.

When there are no occurrences or incidents that require these activities, the team does not consume direct effort to achieve the desired result. However, when it does, it should be fast enough to restore normality to the functioning of systems at a time that reduces the negative impact on business. Typically, these results are defined earlier in the form of service level agreements (or SLA).

Therefore, in this maintenance segment, managing productivity is observing service level agreements; it is not an assembly line subject to production planning and control as happens in the development of systems or other types of maintenance.

Productivity as a process attribute

The concept of measuring a team's productivity is, in fact, a simplification. In fact, the broader interest of management is to evaluate the performance of a production process (in this case, a software process). Therefore, data on the measurement of support activities should not be mixed, such as those described above with a development project for a new system.

Each software production process has unique cost factors, and the productivity derived from these cost factors follows a specific probability distribution. For example, the development processes of a new application and the ma nutenção in existing application are different.

In to make a single metric better used in both processes, the Netherlands Software Measurement and Analysis Association (NESMA) has developed the Improvement Function Point (VET) and the Test Function Point (TFP). VET is nothing more than the standard Function Point adjusted for an impact factor according to the degree of change in a functionality, and the TFP considers in its scope the functionalities included, altered and tested (disregarding the excluded ones that, affnal, could not be tested).

Similarly, Q/P Management Group has made available the solution adopted by your company in the measurement of demands that do not involve creating or modifcar application functionality. It calls the unit resulting from the measurement using this Point of Impact solution and consists of applying the default method considering not the functionality included, changed, or deleted, but the functionality impacted by that activity.

A very complete example of the segmentation of production processes in which the same product unit is maintained is the SISP Software Metrics Roadmap, which drinks from all these cited sources. This Roadmap is applied in improving software performance in terminated functionality

Some processing takes up to 48 hours to complete. The mission is to restructure the architecture and implementation of programs, so that after its completion, these same processing (considering a functional perspective) does not take more than 24 hours.

The associated process is not that of an improvement project, so the IFPUG standard guides that this type of activity is not measured as such. The functionality does not change. Change software configuration items associated with the project (the internal architecture) and implementation.

In a scenario like this, i could compare this type of process to the standard development method and conclude that it represents, say, 70% of the effort that would require further development. Hence, if the impacted scope is measured as 100 PF; performance in this process is considered to have a production equivalent to 70 PF.

"A very complete example of the segmentation of production processes in which the same product unit is maintained is the SISP Software Metrics Roadmap that drinks from all these sources cited"

Advantages of using APF in productivity measurement

It is important to indicate that Function Point Analysis (APF), a technique that produces representative units of functional size measurement, is a method with a high level of maturity, has a greater number of qualified professionals in its application and has a wide range of organizations that use it. There is no other method on the market that compares to it in these three highlighted points.

There is also the International Group of Point of Function Users (IFPUG), an organization responsible for its maintenance and evolution since 1986.

The use of functional measurement uses as input the functional requirements – related to the tasks and services of the user – as defined in the segregation of roles and responsibilities by the organizational structure; organized by the operational flow that describes business processes. Information is available early when developing in contrast to implementation or project decisions made much later comparatively.

If some other measurement method that considers internal or technical aspects were used, then it would not be possible for the client to audit the results presented by the development team. This alone is already a great reason to discourage its use for productivity assessment fns.

Using a functional metric balances the different trends in action when planning and evaluates productivity. There is a natural tendency on the part of the development team to inflate the use of resources, while the customer has a tendency to impose pressure in the opposite direction to increase production. Without a functional metric such as APF, there is no reference with a common meaning for everyone involved.

Can a NON-IT PROFESSIONAL USE APF?

Some may think that if the person is not in the area of Information Technology (IT), then they will not be able to use APF. This thought is wrong. I have been training thousands of people in APF for over 20 years and I can safely say that about half of the time spent has been devoted to supporting IT professionals to unlearn to have only a technical view of software and learn to have a vision of the software under an operational procedure in the business.