One of the obstacles for organizations looking to use implement an Agile strategy and framework across a Program Portfolio comes when they bring in suppliers to work with the Implementation Teams on value delivery. Software development contracts have historically been based on the principles of Waterfall projects, which are sequentially scoped from requirements gathering, design, development, and testing. If changes to the requirements occur, the approval has to some from a change control board.
In contrast, Agile is iterative and rarely starts from a fully defined specification. Agile value streams involve developer and customer being on a long journey together, where the overall goal is broken down into small parts that are individually developed in short timeboxes – called iterations typically less two weeks. This can lead to friction when it comes to defining the services needed from a supplier when negotiating a contract.
Even though, a vast majority of contracts are still waterfall-based, but Agile development is growing in use. This poses a number of risks to both sides.
Organization from heavily regulated banks to legal entities are getting into Agile in a big way, pushed by their business and technology teams hungry for a flexible and Agile way of working to deliver products much faster to market.
It should go without saying that the program portfolio leaders considering any value delivery needs to be clear about its goals. But with Agile, the need is greater.
When two parties craft Agile contracts, there needs to be flexible to realize the benefits while accepting the reality of the challenges. While advocates of Agile are optimistic about its ability to deliver based on mutual trust, others tend to look at contracts as mechanisms for apportioning risk.
Despite the differences between Agile and waterfall, Agile Program Managers still need updates and forms of interaction with suppliers. The updates need to reassure leadership and teams about adhering to the A2F Agile framework, collaboration, estimates, transparency, and trust.
The contracts that work well are generally those where customer and supplier both have experience of working in an agile way – and ideally with each other, so there is already a track record.
There will be more work to do where the relationship is new. In particular, education of the new vendor/supplier will be required through the Agile lifecycle because of the degree of day-to-day collaboration.
The financial terms of an agile contract can be a source of tension. A2F recommends setting up the contract based on iterations and “time and materials” basis – paying for third-party resources based on the number of days (iterations) they work, rather than for a price fixed up-front.
Generally, customers will ask for some degree of additional protection or incentive through a hybrid process, whether through a priced “minimum viable product” or an agreed success-based delivery fee if the product/work is delivered before the exhausting the number of allocated iterations - but this requires good contract governance to keep both sides happy.
In reality, though, there are a number of different pricing models that can be adopted, and it will come down to negotiating power and willingness to share risk. As part of the contract terms – A2F strongly recommends touchpoints. This can be the vendor’s staff calling into certain standups, Scrum of Scrums, attending demos/showcases, program sync ups, and progressive elaboration and backlog grooming sessions.