Agile product development and fixed prices - it works

Customers plan their budgets for projects for which they want fixed prices. Nevertheless, agile product development is not off the table. How is that possible for fixed-price projects? How do the two go together? We have identified 5 points that are important to consider.

Everyone who has been in business for a while has faced this unpleasant situation in a project. The budget is gone and the product is not ready. If all goes well, an extra budget is found to fill the gap and the product sees the light of day. If things are a bit more challenging, then the project is put on hold and the team waits for the next year and the next budget to resume their work. But it also happens that the project doesn’t go any further. By the time another budget is set, the product idea is outdated or requires substantial rework to adapt to the current needs.

In the days of the Waterfall method, this was pretty common. Budgets had been properly planned, but the users had not been involved at all. After the product had been finished, the (negative) surprise was often too big and the product beyond remedy. That's why agile methods have been created. The product development process had to get closer to the users and the black holes where budgets disappeared had to become smaller. So how does this work?

From our experience, we have gathered 5 points that help our products make it to the go-live:

• 50% rule: Initially, we only plan to use 50% of the budget, the rest is a buffer. How high the percentage is, depends on the client, the stakeholders, and the product. It can also be closer to the actual budget, but not for the first project with a new client.
• MVP taken seriously: Together with the client, we define what an MVP is. This may sound trivial given that definitions for it are easy to find. What we mean by this: we define which customer-based and market-specific criteria define the MVP.
• Breaking the conception cycle: We start the development early on. Even if many conceptual questions are still open and the client is passionate about discussing them. Even if we know we might have to throw something away, we start developing. It’s better to rewrite part of the frontend than having the product not go live. This is a key insight into agile development. It’s not about getting more out of the budget. It’s about letting the users see and test the product as early as possible. It’s about getting users’ feedback on what is good and where there is room for improvement.
• Early commitment: In our experience, this is the most difficult point. In the beginning, ideas sound promising, and little attention is paid to how they will be implemented. As it gets closer to the (imaginary) release date, everything is considered more seriously. That is why we plan a lot of room for feedback from the start and ask our clients for critical reviews as well. Doing so ensures we do not fall into the Waterfall trap (“Actually, I expected that very differently”) and the product is assessed closely and critically from the start.
• Expectation management: We don’t promise a Porsche if the budget is that of a Golf. And we also don’t talk about a Porsche once we have outlined what is possible with the given budget. In other words, we don’t talk about what can’t be done but rather focus on what is feasible.

Agile does not mean chaos, nor does it mean that there is no reliable planning. On the contrary, the probability that a project will be delivered on time, in scope, and within budget is even higher.