Strategy

Even when measuring and having data, people are still a key component of the strategy to deploy metrics and to have a driven-data process change. Metrics that lead to a process improvement or a motivational change are needed to be understood and approved by those that will be tracked. And there is not a need to measure everything, but to focus on specific areas of developers work that help to understand if this is working.

In addition to all of this, the metrics strategy is directly linked to the general purpose of the process update. From time to time organizations update their goals and those goals force a change in the metrics used to parse how far the organization is from those goals.

Thus, there are two main components in this process: goals and people. And developers must be aligned with the goals of the organization so everyone is walking the same path to success.

Developers and middle management should be part of the process to understand what the useful metrics are, to help to reject useless metrics and improve the metrics cycle. This will also help to introduce a data-driven development cycle and let the developers feel comfortable when using them.

When using metrics in InnerSource, we have already detailed the following purposes:

• Awareness: be aware of the work in progress

• Process Improvement: detect issues and understand the root causes of those issues (look for bottlenecks of your current process).

• Motivational: let the development team follow some track (e.g.,: foster new contributions to a new project)

A usual way to apply a new methodology consists of following the PDCA (Plan-Do-Check-Act) to continuously improve. The steps ‘Plan’ and ‘Check’’ are the interesting ones for this metrics chapter, while the others are application of improvements in the process (‘Do’) and decision making (‘Act’).

The Planning actions consists of understanding the current situation of the process within the organization. For this and from a metrics point of view, it is necessary to retrieve qualitative and quantitative information. Quantitative in the sense of measuring what is taking place in the current development team and understand how developers and middle management use the infrastructure and interact among them. This will help to have a first glimpse of the situation of the project in a given moment in time.

From a qualitative point of view, feedback from developers and middle management is also necessary as they understand how the current process actually works. This is expected to fill the gap left by the quantitative approach and will help to understand if metrics are useful for their daily work, from a more managerial point of view or if they are useless at all for them.

Finally, it is necessary to define the goals, questions and metrics that will help to understand how much improvement we had when applying new policies in the software development process and other areas. Those metrics can also be linked to some actions such as alerts when the software process is not evolving as expected. And those alerts should end in actions or decisions in the ‘Act’ step.

Summarizing: qualitative and quantitative feedback, definition of goals and questions that will be checked later to measure success and tracking of the current situation of the project at the point of initiating this process.

Once the metrics and KPI’s were defined, the ‘Do’ step will take some weeks or months of work where developers work in a certain situation with some specific conditions. The ‘Check’ step will help to determine if this process was successful enough depending on the original goals defined at the ’Plan’ step. We may have improved the performance of the development model, but if the goal of this cycle was to attract more developers, we would have failed.

On top of this, the application of different policies or actions may take place in parallel and with different projects. Let’s take the example of selecting a new governance model for three different inner source projects: benevolent dictator, pure meritocracy where developers can work on their own and a mixing model of meritocracy but where developers are guided in the type of tasks they can work on.

This may help to follow a testing process where the governance model can be tested in small scale and the most successful govern later exported to others. This test A/B may help to understand the best governance model in certain circumstances. And having qualitative and quantitative feedback from the people involved in the process and the data sources they used provide great insights about the performance of the several models.