The answer to the question of who actually pays the bill should also clarify who calls the shots in software development.

After all, the new application should serve a specific purpose that ideally contributes to a company’s success. Business units such as marketing, product management, or sales bear responsibility for this. They commission the software or its customization from their IT department or IT service provider, effectively making them clients of IT. However, this distinction does not seem to be entirely clear to many developers.

The allegations:

• Business departments constantly put pressure on the IT department.
• They often change their requests or want to add new features at short notice.
• They fail to understand the work provided by IT developers.

This is what many developers still think and thus creates a defensive attitude on their part toward requirements from the business departments.

However, they should be aware that “their customer” has the right to change orders. After all, they are ultimately responsible for the resulting success.

We in IT are engineers. We should know how to deal with change and high demands. After all, even if the ideas originally come from the business units — because that is their job — we are the ones who realize them.

It is precisely this symbiosis that makes IT and business an invincible team. Once everyone has internalized this, they can create great things.

This is all about personal attitude: the IT department does not have the right to mess with the business departments, as we see this happen again and again, especially in the agile environment. We are professionals and should be able to give feedback to those who do not know and cannot assess the complexity of our daily work.

And we should also not forget who pays us in the end. After all, we are developing software and user experiences for the company’s customers.

Now that we have clarified who pays the bill, let’s take a look at the different ways we get paid for our development services.

Fixed price versus time & material

There are many different billing models, ranging from multi-level fixed price to capped effort to requirements unit price. Here we look at the two most common pricing models: agile fixed price and time & material.

Time & Material

For Scrum, now the most widely used agile method, time-and-material is perfectly suited as a pricing model.

This is how it was intended, at least in its execution within IT. From the beginning, the effort measured in Story Points was more of an indicator than a firm promise. The idea was that teams would get better over time, including in terms of ratings, and so it was hoped that the so-called “burn-down chart” would bring steady improvement in terms of completed effort. A very flexible tool, that initially avoided to a large extent any objective evaluation.

In this case, the client simply receives what is finished at the end of a sprint — regardless of whether it corresponds to the expected result or not. You can think of it as ordering a car with your individual extras for a fixed price and at an agreed time. In the end, you either get your car with all the features you ordered, but more expensive and later, or at the agreed time, but not quite ready and perhaps even more expensive. Reasonably, you would not accept this. But this is exactly what often happens in agile projects.

As mentioned, the effort in IT is calculated in story points. This is a kind of currency that is difficult for the business departments to estimate per se. The estimated effort depends on parameters that are not easy to assess from the outside. These include the skillset and the team’s attitude toward self-improvement (self-improving) as well as the assignment of story points to the tasks at hand. The story points are counterbalanced by a monetary amount. However, it remains uncertain what exactly the equivalent value is.

Our take

Scrum does explicitly allow time estimation of a feature or user story, but this is very rarely used. We are a friend of time estimates. In order to do justice to the complexity, one can, for example, also work with “from-to” values for unknown tasks, i.e., set a framework that is at least indicative. This helps in communicating with stakeholders. We also favor estimates by architects or tech leads, but not by the entire team, so that the business gets feedback upfront on what they will have to pay so they can decide if it is worth the effort.

So these are all approaches for dealing with time-and-materials. Our experience has shown that the more reliable a team is in meeting estimates, the greater the confidence in dealing with T&M.

Operational risk

The interaction between the service provider and the client is an important factor in making the project work. At the interface, people are needed who can assess the complexity of the task. If this function is missing, then the work of the IT team (whether internal or an external service provider) cannot be properly assessed. This can quickly lead to mistrust. The client bears a share of responsibility here in the assessment of the effort.

Agile fixed price

Not long after the introduction of Scrum with all its tools, the question arose how to recapture this new agile and integrate it into a fixed price framework.

There are several approaches to force agile projects back into the corset of a fixed price.

1. You can break down individual work packages so clearly that it is much easier to estimate them and then offer a fixed price. As long as these packages are worked out iteratively, you can still talk about agile. But if they are assigned completely or successively out of the scope of the overall project, we are again very close to waterfall projects, where you first have to know the overall scope.
2. Another model is to define a number of user stories (depending on experience or estimation) along Fibonacci numbers (1,3,5,8,13 then corresponds to XS, S, M, L, XL) that value the effort in 5 different T-shirt sizes according to their complexity. This is based on an overall estimate across all user stories that may occur during the entire project duration and thus arrives at an overall price.

Of course, this approach is subject to a high degree of inaccuracy since it is not known in advance how many user stories in the preassumed T-shirt size will actually be generated in the end. In addition, such an approach usually requires the involvement of a change manager. Ultimately, the actual estimation always remains in the hands of IT, which will naturally tend to use the next largest T-shirt size in order to be effective and profitable.

Out take

In short, you can proceed in this manner, but it is not without its challenges. While it may appear to provide a sense of control, it carries numerous risks for both parties, which is why we advise against adopting agile fixed pricing. In practice, it closely resembles the Waterfall approach but merely presented differently.

Moreover, some principles of the agile idea are completely undermined here, such as the self-improving team. But the purchasing department does not care about that at all, because for them it is mainly about economic aspects.

Just to make this clear: We are big friends of plannable efforts and costs. But this requires experienced employees — ideally on both sides.