Stay updated

Debate, Henrik Zangenberg

Let’s Get Better at Talking About Productivity in the Agile Programmes

Financial management in agile processes is a challenge for most people. Do we simply throw money away by allowing teams, whose productivity does not live up to similar teams, to continue without managerial intervention? That is something we need to discuss with our providers

Do you have complete control of your agile development project budget?
If the answer is ‘no’, then you are not alone. The fact is, in general, financial management of agile projects is tricky.

Usually we have only very uncertain estimates of how much it will actually cost to reach an ‘acceptable end product’ – if there actually is such a thing.

We set aside funds for a number of ‘Agile Release Trains’ and the result is whatever you get out of this.

If you find out along the way that you need to move in a different direction, then both budget and scope can change.

Virtually unacceptable
From the perspective of certain CFOs, this uncertainty is often virtually unacceptable.

This is due to the fact that it challenges a basic premise in many organisations: the choice to launch an initiative based on an assessment of cost in relation to profit.

Agile frameworks feature various tools for containing the problem. But there is one major challenge that the frameworks do not solve: the lack of insight into the actual productivity of the teams appointed to tackle the task.

The productivity of developers is a key parameter for success in the agile process and thus also for the financial management of them.

This is the case, whether you have insourced or outsourced the development task. But it can be particularly challenging in outsourced scenarios, where access to insight into team productivity can be more difficult.

Our analyses of agile processes reveal that productivity varies greatly among developers and agile teams.

If you put five developers in a room with some users for two weeks, the quantity of output can vary greatly, depending on whom you have put together, how they are managed, their experience, knowledge of methods and the culture of the team.

It’s all about management
It takes management to get a handle on these imbalances in the various teams. You need to identify the teams that have problems, and help them.

This can be done through training, new team members, relieving tasks and many other measures.

But the fact remains that you can only remedy problems if you actually see them: if you have knowledge of actual productivity and, from a financial perspective, knowledge of whether the development teams working on the task are performing at a level that actually corresponds to the price you are paying.

But it is not impossible.

The actual productivity of the development task can be expressed in time consumed per unit produced.

‘Unit’ can be story points, function points or other composite values that express the actual functionality implemented.

The challenge of all these goals is the fact that they require an independent count every time you have developed something new.

To put it mildly, this is a colossal amount of work, and that is why no organisations do it.

On the other hand, the number of lines of code (SLoC – Source Lines of Code) is an immediately available output target.

While not immediately translatable into function points, for example, it is possible to find the FP/SLoC ratio for a developer or team, and it can be used to triangulate a value for productivity in a single sprint for a given team.

These can in turn serve as a benchmark for relative productivity in the individual teams, measured in relation to each other, and absolute productivity, measured in relation to the outside world.

As mentioned before, financial management in agile processes is a challenge for the majority of us. But we should be willing to initiate the discussion about whether we simply throw money away by allowing teams, whose productivity does not live up to similar teams, to continue without managerial intervention.

And we can only do this by seeking insight and by improving in terms of discussing productivity with our providers when we outsource our agile processes.