Agile Fixed Price Contract: Sometimes Tricky but Always Possible

Agile is now common knowledge. IT development frameworks such as Scrum, which emerged 10 years ago, are now the norm. Indeed, most IT projects lend themselves very well to this mode given their complexity and uncertainty.

In a service company doing development for clients under a fixed price contract, is it possible to use this development mode without distorting it? How can we work with our clients in MVP (Minimum Viable Product) mode and respond to a call for tenders without detailing all the features to be implemented?

This is the thorny question we try to answer daily at Uzinakod. It is obvious that IT development in a complex field with changing business needs is impossible to plan exactly in advance.

So why bother writing contracts with a fixed budget, duration and scope?

The Project Sponsor: The True Captain of the Ship

An Agile project must have a captain involved on a daily basis to guide the team and make sure they are working on the right thing at the right time.

The contract should rather talk about risks and gains shared between the two parties. Modules to be developed rather than features. Collaboration rather than responsibilities. Assumptions rather than certainties. At the RFP stage, it is possible to establish a vision for the product and define the modules that will be addressed, but it is impossible to determine exactly the full scope of the entire contract.

Throughout the project, the product backlog will be clearly defined and the sponsor will make the decisions on the work to be done.

A ship’s captain doesn’t look the other way and say at the end that we didn’t arrive at the right destination.

The client, sponsor, Product Owner (PO), proxy PO, or power user, in short the one who determines the functionalities, the execution order, the added value and who gives the feedback so precious to the team: this important actor must be involved and interested throughout the project to maximize its gains and minimize the risks by making sure that the time is invested in the right place without waste.

Moreover, for the development team, there is nothing more demotivating than working hard on an unwanted feature that does not meet the need or even getting only superficial feedback from the sponsor showing a lack of involvement and understanding on her part.

Signs that the sponsor’s involvement is insufficient to ensure the success of the project:

1. The sponsor relies on the development team to detail the work to be done and has little or no input into the backlog.
2. Reference is made to the items mentioned in the contract rather than putting effort into validating and prioritizing the work.
3. Few user tests are done throughout the project, demos are not enough.
4. The conversations are focused on the entirety of the functionalities rather than on the added value and the minimum required to meet the need.
5. The sponsor is not assured of the project’s success and does not promote it to her team. They don’t feel like they are part of the solution.

If you observe one or more of these signs, a tune-up is necessary. Indeed, both parties benefit from having an honest discourse and focusing their efforts on the added business value, the definition and the daily validation of the developments made.

Steering the Project Back on Track

There are four steps to this:

1. To mobilize around a common objective, to bring the system into production as quickly as possible by focusing on the essentials.
2. Find one or several subject matter experts on the client’s side, who can guide the project and reserve a significant proportion of their time to do so.
3. Get the customer actively involved on a daily basis to define the needs, prioritize the developments, identify the superfluous functionalities in a first step and validate the accuracy of the delivered functionalities.
4. Communicate transparently between both parties throughout the project. It is important to have those sometimes-uneasy conversations and to point out mistakes or imperfections: always aim to improve.

Signs that the collaboration is working:

1. The customer participates in the elaboration of the backlog. She makes decisions on the order of execution of the developments and comments on the scope of the stories before their completion. Even better, she adds stories to the backlog.
2. She actively participates in the demos by asking questions and taking notes. Afterwards, she tests the application and provides relevant and constructive feedback to the team to maximize the value added.
3. Identifies unnecessary and low-priority work and defends her vision to her team. She approves less complex alternatives that meet the need.
4. She has a short-, medium- and long-term vision of her product and evangelizes it to her team.

Obviously, working on an Agile project for an external client makes things more complex. However, it is possible to do so by educating the sponsor, identifying the right people and making them aware of the risks, costs and impacts of their decisions or lack of involvement.

The best time to lay the groundwork and get the process off to a good start is at the beginning of the project. You also need to make sure you have the right players around the table. A good sponsor is someone who listens, is flexible and knows the business inside and out.

Furthermore, throughout the project, it is our duty to accompany the sponsor and help her understand our reality. We must also listen to their needs and always make sure that we validate our decisions.

Here are examples of everyday actions that help build trust:

• Mentor the sponsor to understand the ins and outs of this crucial role for the good of the product
• Test with the client to ensure that they understand and validate the features
• Outline the risks or complexities of solution choices so that the sponsor can make informed decisions
• Helping our client keep their requirements concise to allow for iterative feature development
• Always prioritize high value-added developments for the business team
• Have a simple way for the business team to communicate with the development team (example: a support box)

It is also extremely important to have a counterpart on the development team, compensating for the lack of technical expertise of the external PO, who comes from the business world and is not immersed in the field of computer development daily. Customers are a gold mine of information, let’s actively take advantage of it. Let’s teach our ship’s captain the rules of the trade and let her guide us to port.