key indicators for software development

So over the years I have developed two “important” key indicators to measure how well an organization developing software is doing. They are both ratios between things and there are no The correct.

The D/EE indicator

Ratio of number of developers to everyone else

The first one came quite some time ago when someone noted that developers were not even half the folks in the software development part of the company I worked at then. So this is the ratio between people coding and other people in the organization. After all - coding is where stuff actually happens. Everyone else has a supporting role.

Everyone else comes in many shapes and here are som examples:

• managers of line, project or product variety
• product owners and other product roles previously known as requirements something
• user interface/experience/design and such
• testers and test managers, QA and such
• devops engineers perhaps or sysadmins as they were used to be called
• coaches and agile specialist
• change control people
• security specialists
• DBA
• Jira configurators

Yep the list can be made longer than this as well. They are just examples for what kind of “other” roles there can be. And I would only consider roles actually working with software development. Depending on the type of business we have there will be more people around.

So what is a healthy ratio here? I would say that if less than half are developers there is most likely a severe overhead problem in the organization. It will also be likely that the developing teams has less freedom over their work then what is desirable. On the other hand if almost all are developers there are probably things that are not going that well. Like design or figuring out new product paths and such. Or security. This may be fine in a small organization but as it grows, non developing specialist roles are surely needed. Figure out what strengths the organization have and strenghten the ones where there is a deficit.

The P/W indicator

Ratio of time spent doing planning as compared to actually working on the plan

Planning is inventory. This is well known. And some inventory may be needed in order to be able to work as a group of collaborating people. So from the point planning starts, until it is actually either discarded (and erased from everyones brain) or implemented in code or with some other measure, planning is a kind of debt. We invest time in planning in the hope that it will be converted into deployment and business value further on. As you may guess I often feel that we do too much planning. Many times the same improvement is planned over and over again before it is actually done. If the time spent planning actually exceeds the time doing it we can try two times without plans for the same cost. This is why we mostly work with increments these days. As small as possible. But in larger organizations there are planning for the next quarter and sometimes even further than that. This may be necessary to be able to communicate with stakeholders and internally in an organization.

With that said I introduce the ratio between time spent planning and time spent working as an important ratio. Where I work now the ratio is somewhere between 5 to 15 % in planning. This is healthy but I am sure it can be pushed to even less than that. It is something that has to be learned in every group. So what are factors that enables a lower degree of planning:

• an organization based on trust is crucial
• planning happens where it will be implemented. All other planning should be extremely high level and not be expensive at all.
• business specialists available in the organization and present when the planning happens
• don’t keep backlogs and especially do not go through them over and over again
• the right time to do detailed planning is just before implementation or even during it
• the longer it takes between planning and doing, the more likely it is that the planning will need to happen again
• no one is held accountible to the plan - if someone needs to deliver on the plan there will surely be more planning

Connecting the dots

As you can see these two indicators relate a lot to each other. But as D/EE counts heads, P/W counts time. Also not everyone in the everyone else block is doing planning. Some are doing other things. Like assuring quality or taking a stand on security. And natrually also developers do a lot of planning. Nevertheless it is likely that an organization with a low D/EE indicator willl also have a high P/W.

written by fredrik at 2024-08-25