In recent years, the IT industry, in particular, is turning towards transparency and the adoption of agile contracts in partner management departments. Agile contracting is a product that is one of the essential requirements for successful organisation development. However, traditional thinking can lead to anti-patterns and consequently a short-term solution.
In most organisations, agility is spreading across all the corners of the corporate environment and many have started reflecting upon key areas to enable end-to-end organisation-wide agility. From data collection and processing to project planning, changes adopting the agile approach are the way forward. However, for example, one of the pain points is certainly the nature of existing contracts in place with vendors or suppliers.
With the issue identified over time, several organisations have ventured into using the various modes of contracts with vendors who support the project to product agile working approach. Many successful business practices and methods have evolved in recent years but there is still a vacuum of knowledge in this area. Half-hearted agile experience has triggered some concerns in this transition process as in some cases there seems to be a focus on old methods rather than new, which causes a backlog in successful production.
In many instances, organisations preferably choose an option to define their own customised Agile contracts and contracting processes, taking into account their individual case. This is one of the best organic approaches to deal with the subject. However, with limited knowledge and understanding of agile fundamental concepts in procurement departments, several anti-patterns have started emerging. I would like to reflect on the anti-pattern scenario, to help organisations avoid some ‘easy to fall into’ anti pattern traps while putting agile contracts in place.
1. Old wine in new bottles: traditional contracts in agile terminology
This is the simplest way to transition from traditional contracts to agile contracts with minimal effort and a degree of change management by the procurement teams. It is an ideal shortcut yet the most dangerous choice from an outcome perspective. In this approach, agile terminology not only overrides traditional prominent keywords and definitions but also the most fundamental problems triggered by the non-compatible contracting mode.
In other words, you start defining the same old issues and practices, and issues in agile language rather than rooting them out using the agile approach. Ultimately, the benefits expected from the move towards agile contract project to product management are a grossly missed opportunity in terms of a focus on lean and effective working methods.
2. The core of the contract still carries the RACI legacy
Even though teams and stakeholders have started working in close collaboration, just above team level and at higher management level this is still an exception. There is a lot of engagement between the customer and vendors that is solely dealt with on RACI-based principles, which inherently promote a silo-accountability work culture which is an anti-pattern towards the collaborative approach.
Agile team managers give teams the flexibility to achieve their goals in their own way; they remove the obstacles and fully support the methods teams choose to reach an objective. They believe in the team and know they will deliver the results required. They recognise people are human and do their best work when they are motivated and allowed the freedom to work in their own way.
When dealing with foreseen adaptation at a high level, scope, priorities, and timelines are more based on the accountability of individual organisations rather than dialogue-based or shared responsibility of the user. Apart from this, several activities are expected to be performed in isolation, for example, scope prioritisation decision-making (customer owned) and report preparation (vendor owned), plus the vendor has to pass several stages of client approval throughout the development life cycles.
The true spirit of collaboration and having a shared ownership is also applicable at the middle or top layers of a business, and not only limited to team level functioning to achieve end to end agility and maximise value. The basis of this culture fundamentally emerges from changes in contract definitions. If collaboration, shared ownership towards a project goal, and delivery are agreed upon and defined in contracts, it will begin to be the norm.
3. Agile Contracts measuring progress with traditional metrics
In some scenarios, a team or stakeholders, who are the owners of the products and services work in an agile environment with several agile metrics at team level. As we climb the ladders of an organisation, these KPIs are slowly replaced with traditional metrics that management is comfortable measuring. Isn’t this how they have reached a project goal for many years? Why should things change? Why should we use new software when our old way of doing things has always worked? What’s the price? This triggers another problem: the case of management pushing teams to produce traditional KPIs along with the agile team KPIs to meet the need for contractual governance.
The major side effect of this traditional type of measurement is, with the nature of old KPIs, management still wants and tries to maintain control, whereas agile KPIs means fostering collaboration, working in cycles, and more autonomy in the team. The lean business model of agile contracts avoids this previous way to deliver results and results in optimised value through a new working method.
4. Agile Contract in the water-scrum-fall way of working:
In some scenarios, I have observed that the agile development approach is centred on scrum-based delivery, but a little deep observation shows that another implementation famously known as water-scrum-fall (scrum and waterfall combined working). In this approach, teams work in sprint mode (a specific time period) but the rest of the surrounding organisational functioning is still waterfall based. In sprint mode, the team has to complete a scheduled volume of work, whereas the waterfall method is a sequential approach. This lack of coordination between teams can lead to blocks in workflow, for example in data supply, delays in planning, staff liaison issues, and a backlog in project planning.
This creates an illusion of agile delivery but is nothing more than the waterfall approach wrapped in agile terminology. It does not represent the need for change and the use of new methods, such as software, to deliver added value. Agile projects are delivered fast and on time, and work to the sprints philosophy. Sprints mean a constant turn out of products or services that continue to evolve, as opposed to a long-term project that may take months to reach fruition. This delay can pay the price if the competition is ahead in the agile game.
In several parts of the world, a lot of good work has been carried out on this subject and I would like to share some references to help you avoid the anti-patterns of agile contracts:
https://agilecontractmanifesto.org/
https://www.agilesoftwaredevelopment.com/posts/10-agile-contracts/
https://www.lean-agile-procurement.com/lean-agile-procurement-approach#the-lap-approach-overview
