Developers - Cost or Asset?

When things get big enough there might be functional silos that concentrate on specific activity. These could classically be something like sales, development, support and marketing. Of course these functions should be made as efficient as possible taking into account the whole. Customer value is usually built in co-operation between all the functions, not by a single unit.

Metrics can be a double-edged sword, if they are applied to functions instead of taking into account the whole value chain. Sales funnel is quite easy to quantify. You have numerable amount of possible clients. You can count how many units you can sell to this market, thus getting the absolute limit value for your cash inflow. It's easy to measure how much a single sales person or sales unit can close deals and bring in money.

If you sell development hours, it's also quite easy to measure how much a developer generates turnover or how big the billing rate is.

In typical cases salaries are even easier. There's usually a fixed sum of money that is paid to the person monthly. This is the cost of a developer (plus hardware & licenses too).

But it’s much more difficult to quantify the financial benefit of an in-house developer who works in R & D. One could make a rough estimate about how much an equivalent consultant would cost. But this doesn’t take into account the subtle knowledge that is accumulated over time or the internal relations. Possibly this person is the glue that keeps the team together, the humorist that keeps people in high spirits or the oil that lubricates the internal cogs and makes things happen. Not impossible, but difficult to quantify.

Without visibility and understanding, one can draw wrong conclusions about the situation. Classic would be rewarding sales department for bringing in the money and cutting costs in operations by sacking people.

 

"What should I do then?"

To remedy the silo problem and optimizing parts in expense of the whole, you should concentrate on metrics that measure the whole value chain and are difficult to gamble. Some examples:

• NPS. How the customer experienced your service?
• Lead time. How long it took your organization to meet the customer’s need?
• Profitability. Do not concentrate on (just) how much sales you make. Pay attention to how much it costs for you to develop, deliver and market the product/service.  

 

 Photos by "My Life Through A Lens", Spenser H, Fabian Grohs and Mike Wilson on Unsplash.

From Forecasting to Cycle Time

I like measuring for the sake of improvement. I believe that measuring something helps to understand its nature. And by measuring you might learn if something is good or bad and going to positive or negative direction.

We have been using so called forecast hit-rate to measure how well the Scrum Teams are able to predict their velocity. It's the result of dividing planned number of Story Points with the actually realized number of Story Points for a Sprint. But in case the number of stories is small, there's easily large deviations when things don't perfectly as planned. And usually things don't go perfectly as planned.

Also this measure can result in some rather nasty dysfunctions. Teams start to favor keeping the forecast instead of trying to maximize the amount of customer value in a Sprint. Or even though some Story becomes obsolete it isn't dropped because that would flaw the statistics. This isn't nice.

We use Atlassian JIRA and JIRA Agile for our Backlogs and Scrum boards. (I guess I should start calling it JIRA Software soon.) It offers a handy Velocity Chart where one can follow these planned vs. completed results. This is essentially the source of our forecast hit-rate information.

But due to all the possible events that affect the Scrum Teams and the #NoEstimates movement that gains momentum also in our company, the data has a really high variance. Even after couple of years it shows no signs of stabilizing. (Of course it can argued that is a systemic dysfunction. As it is. But let's not go there.)

Another tempting alternative for this metric that I've been thinking about is Cycle Time. Average time that a Backlog item takes between the start of work until it is completed. Let's assume that such metric would be easily available and that there would be target on it or that management would follow the number. What kind of behavior would this drive?

My assumption is that it would make the Stories smaller. That teams would strive to get things done faster instead of having mammoth size stories. So In the end there would be a bigger number of smaller Stories and tasks that could be made in shorter time. I would like that. Also it would fit nicely with #NoEstimates.

Since this is still simply hypothetical, I don't have any results yet. But this is an experiment that I'm about to try.