In today's fast-paced business world, clients are constantly seeking the best of both worlds: the flexibility and speed of agile development, as well as the perceived safety of fixed-time fixed-price contracts. This trend of blending agile delivery with fixed contracts is becoming more and more prevalent as clients aim to find a balance between agile freedom and contractual security.
One potential reason behind this trend is that clients may be hesitant to enter into a lease agreement with a development team and instead opt for a fixed-time contract. This uncertainty may stem out of the unknown, a belief that a fixed contract offers more security for the scope of work, doubts about the supplier's ability to deliver on the agreed scope, or the client's own internal processes that prevent them from entering into such agreements.
This post covers such a hybrid model from the supplier's perspective.
Uncovering the pitfalls
When implementing an agile approach with a fixed-time fixed-price contract, a common structure involves a product owner from the client company. This dynamic can bring its own unique challenges as the supplier company is bound by the scope and price outlined in the contract, with the product owner significantly impacting the return on investment. In this scenario, trust is of the utmost importance as the supplier must rely on the product owner to make well-informed decisions regarding the project's direction and priorities.
One of the main risks for the supplier associated with this approach is the potential to deviate from the contract scope. Suppliers may want to do so to accommodate the client's requests and be more agile. However, as the contract is legally binding, the client may take advantage of this deviation and exert pressure on the supplier team. This poses a significant threat to the project's financial success as the supplier team may have already allocated budget towards items requested and discovered during the course of the project, leaving the client in a position of power and potentially exploiting the supplier team to the detriment of the project's outcome.
Furthermore, the typical behavior of a product owner in this situation is to focus on completing one feature area (epic) before moving on to the next rather than maintaining constant prioritization. This can lead to the desire of perfecting everything before progressing, causing further delays to the project and potentially damaging the supplier's budget. On the other hand, suppliers may have to fit the project budget at all costs, resulting in a loss of quality. The combination of both phenomena can be deadly.
Balancing Flexibility and Control
Balancing the complexities of agile development within the constraints of a fixed-time, fixed-price contract can be a challenging task. From a supplier's perspective, effectively balancing the benefits of agile delivery with the security of a fixed contract requires a strategic mindset from the very beginning. One common trap is for the supplier to overestimate the control of the product owner over the project scope without involving the development team in the process. To avoid this, it is essential to engage in ongoing negotiations about how newly prioritized items will affect the original scope and what to deprioritize.
The main motivation of the business relationship described is to deal more effectively with unplanned and unexpected work. Maintaining transparency about unplanned scope items that have been delivered and what needs to be exchanged is crucial. By implementing these practices from the beginning, the mindset of "trading" one item for another can become ingrained in the team's nature and working style.
It's also vital that the client understands from the outset that while an agile approach brings added flexibility in making the product more relevant and potentially better, it does not equate to a wildcard for obtaining more for less. The responsibility for decision-making goes hand in hand with this approach and must be made clear by the supplier's team. Furthermore, involving the development team in the process is crucial to ensure that the project stays on track. The team should be responsible for providing rough estimates of newly discovered items, allowing the product owner to make more informed decisions about prioritization.
Ultimately, managing scope in fixed-time fixed-price contracts relies heavily on a mutual understanding between the client and supplier. Therefore, honesty and transparency are crucial for the success of this approach. The supplier must provide realistic and accurate estimates for newly discovered items and be transparent about any obstacles or issues that arise during the project. Tracking development velocity may also be beneficial. In return, the client must be honest about their expectations and priorities and be willing to make trade-offs to keep the project on track.
Building trust through honesty and transparency is key to the success of this approach. Furthermore, having a solid understanding of the client's business and goals can help the supplier team to better align the project's scope and priorities with the client's needs and anticipate any potential roadblocks or challenges that may arise during the project.
Make the contract work in favor
Navigating the choppy waters of agile development with fixed contracts may seem like a breeze at first, but in reality, it takes a steady hand and discipline to steer the ship toward success. Creating a successful contract for agile development with fixed-time fixed-price contracts requires a balance of flexibility and control. As a supplier, it's important to approach the contract with a defensive mindset, taking into account that clients may not always be upfront about their expectations or try to expand the scope. Here are some key points to keep in mind:
Be cautious when crafting the scope and contract, being aware of scope items that are prone to inflation, and carefully formulating them in the contract. Clearly state that anything outside of the scope is considered a change request, and anything not explicitly mentioned is out of scope.
Use the difficulty of defining a comprehensive scope in an initial contract to your advantage by stating that nothing not explicitly mentioned in the contract is included, which can level the playing field and motivate the client to be fair when trading new items for the original scope.
Create flexible payment milestones that can accommodate changes in the scope and maintain cash flow. For instance, the milestones can be triggered once a scope worth X gets finished.
Describe the roles and responsibilities of key stakeholders from the client, such as the product owner, key users, and testers, to ensure smooth and efficient communication and decision-making throughout the project. This includes specifying that decisions and feedback must be provided quickly to avoid delays and blockages on the supplier's end.
Such definition should include the process for acceptance and sign-off of scope items throughout the duration of the contract, rather than waiting until the end of the project to ensure efficient progress and increase transparency.
Clearly define general acceptance criteria for scope items and require a continuous client testing and acceptance process throughout the project.
Keep in mind that the client company may try to enforce delivery of the entire defined scope while diminishing the value of the items developed extra, and make sure the contract reflects that.
In conclusion, while combining agile development with fixed-time fixed-price contracts can be tricky, it can also offer benefits for both parties. The contract should be viewed as a framework, keeping the development team working within a certain timeframe. The supplier should be mindful in formulating the scope items, making it specific enough for the client to have an idea of the product but not so strict that it limits the supplier's flexibility. Furthermore, trust and open communication between the client and supplier are vital in ensuring the project's success. It's important to be prepared for the fact that the client may try to enforce the original scope and to write the contract with that in mind. It's important to remember that the contract should serve as a backup plan in case things don't go as planned. But from experience when a contract gets pulled out and evaluated along the project, it is a telltale sign that the project is already in severe trouble. Thus the primary focus should be on building mutual trust through transparency and honesty. This approach is the most effective for successful long-term project outcome for both parties.
Still, there is no doubt that using a traditional agile delivery contract by hiring a team of experts is usually more beneficial for all stakeholders than adopting a hybrid approach when the situation allows.
Otakar Krus
Twitter: @otakarkrus
Top comments (1)