Fixed price vs agile SCRUM - what is better for your project ?
Software development is the art of solving complex problems, and any problem can be solved in many ways. Very often, the development team must estimate before starting work how much time it will need to do the job, which will result in working software. What's more, the team is required to fit in the estimated time. Projects that use a fixed price approach are called fixed-price.
They are most often carried out in the waterfall methodology. Work in it consists first of all in collecting requirements, designing a solution, preparing detailed documentation - and then carrying out development works.
It would seem that this is a perfect approach. You know how much you will ultimately pay for the solution you create, and the supplier knows exactly what to do. However, the popularity of the waterfall approach in combination with the fixed price decreases from year to year, which results from the fact that many projects were unsuccessful.
Why is this happening? Are you sure this is a wrong approach? In this article, I will try to answer these questions.
Business value delivered during the development
Software products are created to generate the most significant business value. How does it usually work? You commission the application, and you have a defined goal that you want to achieve. The created product is to help with this. For this to happen, the solution cannot be designed based on incorrect hypotheses. The fixed price approach means that all business value is included in the product specification being created. The specification is created before development begins.
Imagine that after starting development, it turns out that the specification contains incorrect assumptions. This will cause the business value delivered to be much smaller. In fixed-price projects, it is difficult to change the scope of work after starting the project, because it causes many negative consequences and is very complicated. It requires a lot of work that affects the duration of the project and its budget. As it turns out, this is a pervasive case. It results from a simple reason - when creating a new software solution, it is challenging to predict everything well before starting work. Most often, the most valuable feedback is received as the first versions of the application reach your users.
In the agile approach - here, we will consider the SCRUM methodology, which is one of the more popular agile methods, the business value is expressed differently.
First of all, it is associated with sprints. A sprint is a unit of time during which the team works on delivering the next iteration of the product. One sprint usually lasts two weeks. For each sprint, its goal is defined, which should be directly related to providing the highest business value. What is the conclusion? It is effortless - business goals can be changed in every sprint. This gives you fantastic opportunities to adapt development work to your current needs quickly.
What's more - in addition to sprints, the agile approach includes daily planning called daily standups, which are meetings at which work planning is carried out for the next day. If the team notices that for some reason, it can provide even higher business value, decisions to change the scope of work can be made daily. It can be easily seen that with the waterfall - fixed price approach, the team's response to the evolving needs is complicated. In the case of the agile approach, it is much simpler because it is part of the methodology.
More about dayli standups here:
Goals and priorities
The fixed price approach is a precarious situation. Well, the goals and priorities of the development team are different from your goals and priorities. What do you want to achieve? Regardless of the method used, you want to create a product with the highest business value.
What are the goals of the development team? The first and primary goal is to do everything that was included in the specifications prepared before development. This is the main criterion from which the team will be billed.
team members see that certain functionalities can be performed in a way that will provide higher business value
they see that the specification is not consistent and does not describe cases that were discovered during development (often this happens in the case of complex projects)
This is an unsafe situation. Once you realize that the created product should work differently than described in the specification, you start negotiations with the supplier to change the scope of work. It is a complicated process and takes a lot of time due to the implications of having to make a new version of the documentation, change the work schedule, and annex the contract.
In the agile approach, the goal is the same for all those involved in development. It is merely providing the most significant business value, the assumptions of which have been explained above. The team is open to all ideas. Moreover, it generates them and presents them to you. This is a situation where both sides win.
In the fixed-price approach - all features must be defined before starting work. Their description must be as accurate as possible, which is difficult because part of the functionality is probably complicated, and it is practically impossible to describe all use cases.
Imagine that you have to accept a 200-page document in Word, which specifies your application precisely - additionally assuming that you are not a technical person and half of the material is written in a language that you do not understand (because it contains implementation details) Estimating complex functionalities is very difficult and involves a high risk of making a mistake.
In the agile approach, the functionality should be defined at a level that allows estimating the order of project size and commencing work before commencing development work. New functionalities and changes are regularly added to the product backlog, and with each planning, you decide with the team which ones will be implemented.
What's more, when you decide to implement a given functionality, the team decides how it will be carried out and, on this basis, estimates the time needed for work. As you can see, this approach saves time that would typically have to be devoted to analytical work, so that the functionality is precisely specified before the start of development.
This is particularly important when it turns out during development that the requirements and priorities have changed, and the functionality will not be implemented. In the agile approach, the team will save a lot of time that they can spend on other things because it was not devoted to specifying the functionality that will never be implemented.
In the fixed-price approach, the specification is created so that during the project, there is no doubt as to how a given functionality should look and work. It is a kind of contractor's insurance policy. The specification documents elements that do not generate any business value for you. Thanks to their conclusion, the supplier tries to minimize the risk - so that there is no doubt what you agreed on. This approach not only documents what is to be implemented but also HOW. Of course, it is again about the apparent minimization of risk that inaccuracies will occur during development, which the contractor will interpret as changes, and you as the agreed scope within the set price.
The consequence of this is that the development team has no scope and is not able to propose solutions. Still, it only implements everything that has been invented often by someone else who is not involved in the development (a frequent case when the analysis and specification are prepared by people, which are not later involved in progress).
As I mentioned earlier - due to the degree of detail in the specification, any change during the duration of the fixed price project must be re-documented to allow final acceptance of the product (which is based on the established specification). It is redundant, unnecessary work that adds no value. In an agile approach, the goal of specifying a product is first to ensure that the team understands what you want to achieve.
Secondly, thanks to a properly prepared specification, the team can determine the order of magnitude of the budget needed for development. The specification is also to ensure the safety of product development for a long time. Therefore, it documents only those elements that are critical for the long-term development of the application. It is also essential here that the application code is written so that you do not have to create additional documentation for programmers... and that automatic tests are also a part of documenting how the product works.
Documenting changes in the agile approach is minimized. It mainly consists of adding the appropriate user stories to the product backlog and determining acceptance criteria. The team updates specifications only when necessary.
There are three factors in IT projects that matter most to it. Those are:
In the case of a fixed price project, you cannot change the budget and scope of functionality to be implemented. They were established before the start of development works. If anything happens during development, it usually has a negative impact on the quality of the solution provided.
Quality is usually defined in the specification in a general way. The effects of poor quality are visible when the project is received, when it turns out that the product contains errors, some scenarios were not implemented (because, for example, they could not be predicted) or the product suffers from poor performance.
It is also very interesting that the quality is affected by changes that have been implemented in the project and which have not been adequately specified. Very often, it is visible in the number of regression errors that appear in the created product.
With the agile approach, product quality is usually adjusted to the stage at which development is. This is very logical.
When you create the first version of the product, where your goal is to answer the question - whether it meets all users' needs or solves their problems, you need a different definition of quality than when thousands of customers use your application.
When creating MVP, except in exceptional cases (or selected elements of the solution), you should not invest an enormous budget in thorough testing of the application, because many of its parts will change. Also, the business goal is usually to verify the usability of the app among the first users, and not to release a very stable production version. When multiple users work on the solution, each functionality must be thoroughly tested before it is added to the next version. To sum up - quality can and should be controlled in time, but it is challenging in the fixed price approach, and it generates additional unnecessary costs.
The fixed price approach means that the project is a kind of black box, where the specification falls into, and the finished product comes out. You distribute subsequent versions for testing, and it often turns out that the list of errors and problems is very long. What's more, everything on this list is from critical errors, through changes, to new functionalities. After receiving such a list, the development team analyzes it thoroughly for a long time. It begins with haggling about what should be done, what an additional budget is needed for, and what consequences it will have on the course of the project.
In SCRUM methodology, transparency is one of the fundamental values. As a customer, you are invited to become a member of the scrum team. Transparency is ensured by all scrum events such as daily standups, planning, or review. Feedback is always provided regarding where the product development is located, what problems the team is facing. During the review sprint, the team shows a demo of what has been achieved, and more importantly, everyone talks and sets priorities for the next sprints. Thanks to this, you get very accurate information on the course of the project.
Motivation and commitment
In fixed-price projects, team motivation and commitment is difficult to achieve. This is directly due to the difference in the goals that are put before the development team and the goals that you want to make.
It is difficult to get motivated when the developer's work is limited to implementing everything that was specified before the start of development. Even if the developer would like to add something from himself, propose a new solution, it is not very possible. It results from the already mentioned complicated process of introducing changes and improvements.
In the case of an agile approach, the team decides what the implementation will look like. Letting the group decide on how to implement functionality and propose it is the best way to build motivation and responsibility. Often, you only need to indicate only the business goals that you intend to achieve, and the team will be happy to suggest what is best to implement in the product so that they can be completed faster.
An application with offers from the beauty industry. The client's goal for the first quarter was to attract as many service providers as possible who will start using it and thereby attract their clients.
After obtaining information from the client about this goal, the team proposed:
Automatic notification to all customers of a given service provider immediately after registration on the platform
A cosmetic gift for the first 10 clients who make an appointment using the platform. Interestingly - these ideas were put forward by engineers - technical persons, after whom no one expected ideas at the business level. Separating business from engineers is a misconception that Marty Cagan extensively discusses in the book "Inspired: How to Create Tech Products Customers Love."
Risk of budget overruns
Why are fixed price contracts not suitable for agile?
This is a topic that appears in both the fixed price approach and the agile approach.
Theoretically, in the fixed price approach, all risk is on the contractor's side.
But are you sure?
The problem begins to appear when trying to introduce changes, new functionalities, which must be thoroughly analyzed and included in subsequent annexes to the contract. The most significant risk for you is that if it turns out that the budget has not been correctly calculated - and the contractor will be under pressure of work without the possibility of negotiating the budget, in the worst case:
the contractor will not be interested in further cooperation
will work in a sense of harm
the contractor will lose team with the best knowledge of the product
finding the next team, passing on product knowledge is expensive and does not guarantee that the next team will work better
What is agile pricing?
That is why it is much better to minimize the risk by spreading it over the entire project. Agile methodologies are helpful again. Why Establishing a budget within which the team creates a solution is an excellent approach. Usually, the initial specification is sufficient to determine the order of magnitude needed to implement the project. After each sprint, the contractor and the client analyze how much budget is left, at what moment of the project we are now, and the implementation of what functionalities will bring the most significant business value. The scope of work in subsequent sprints is created in this respect, and the product backlog is updated.
And what if the team does not work effectively?
This is a risk that you try to eliminate, thanks to the fixed price. If it is that the team is weak, then you will find out about it - unfortunately - at the very end when the whole budget has already been spent, and you will receive a product of poor quality. With an agile approach - thanks to transparency and the opportunity to engage in development by you or the person you specify, you have the chance to detect such risk much faster...
If you are still in doubt as a client, which methodology is better?
First of all, find out why agile methods work. This article should give you some food for thought :) Secondly, start using the small steps method:
agree with the contractor the minimum scope of work
let the team estimate the order of magnitude - we consider it a fixed budget, which in the worst case will be transformed into a fixed price
allow the team to perform three sprints that you will also engage in - e.g., as a product owner or a product supporter
If everything is done correctly, it is very likely that:
You'll find agile methods
You will quickly feel the motivation and commitment of the team and its positive impact on your product
But when is it worth using a fixed price?
Are there projects that are better to do in the fixed price model? Of course. Any project that is the same or very similar to the previous one can be successfully executed in this mode. It is not worth rediscovering the wheel and carrying out projects in which the team has extensive experience in agile methodologies does not make much sense, Agile methods are useful wherever we solve complicated problems, and the team has not addressed them many times in the past.
In the article, I did not address all the challenges associated with long-term thinking about the application as a product and not a project. This is another thing you should consider when creating IT solutions. If you are working on a product whose life cycle is calculated for years, then all the more you need an agile approach in which your team will respond to the changing needs of customers, new market conditions, or even new versions of operating systems or libraries.
I can't imagine now that the fix price model could work properly and could have value. In my opinion, it will only reduce the likelihood of success, which of course I should not and cannot wish you :)
More about SCRUM: