In recent years particularly IT industry is turning towards lot of openness and adoption of Agile contracts in partner management departments. As in most organizations, agility is spreading across all the corners of the corporate environment and many of them started reflecting upon key areas to enable end to end organization wide agility, one of the pain point is certainly the nature of existing contracts is in place with vendors or the suppliers.
With the issue identified, several organizations ventured into exploring the various mode of contracts with vendors who supports agile working approach. Lot of good practices and methods have been evolved in recent years but still vacuum of knowledge and half-hearted agile experience triggered some concerns in this transition process.
In many instances, organizations preferably choose an option to define own customized Agile contracts and contracting process considering their organizational specificity. This is one of the best organic approach to deal with the subject however sometimes with limited knowledge, understanding of agile fundamental concepts in procurement departments, in my observations, several anti-patterns started emerging. I would like to touch base upon these anti-patterns and deep dive into some of easy to fall in trap anti patterns while defining Agile contracts as below:
1. Old wine in new bottle / traditional contracts in Agile terminology
This is simplest way to transition from traditional contract to agile contracts with minimal efforts and change management. This is a beautiful short cut yet most dangerous choice from outcome perspective. In this approach, not only agile terminology overrides traditional prominent keywords and definitions but also most fundamental problems triggered by non-compatible contracting mode. So you start defining same old problems, issues in more agile language rather rooting out using agile approach. Ultimately the benefits expected from move towards agile contract are grossly missed opportunity.
2. Core of contract still carrying legacy of RACI
Even though teams have started working in close collaboration mode, just above the team level and at higher management level it’s a still exception. Lot of engagement between the client and vendors solely dealt on RACI based principles which inherently promote silo-accountability work culture and it’s an anti-pattern towards collaborative approach. Dealing towards foreseen adaptation in high level scope, priorities and timeline is done lot more based on accountability of individual organizations rather than dialog based and shared responsibility. Apart from above, several activities are expected to be performed in isolation for example, scope prioritization decision making (client owned), reports preparation (vendor owned) and vendor has to pass by several stage gated client approvals throughout development life cycle.
True spirit of collaboration and shared ownership is also applicable at middle or top layers of the organization and not to be only limited to team level functioning in order to achieve end to end agility. The basis of this culture fundamentally emerges from contract definitions. If collaboration, shared ownership towards project goal and delivery is agreed and defined in contracts, it will start living on the floor.
3. Agile Contracts measuring progress with traditional metrics
In some scenarios, the teams owning the products and services are working in agile environment with several agile metrics at team level. As we climb the ladders of organization, slowly these KPI’s replaced with traditional metrics which management is very comfortable at measuring it. Isn’t it the way they did all these years? This triggers another problem of management pushing teams produce traditional KPI’s along with the agile team KPI’s to meet contractual governance needs.
The major side effect of traditional type of measurement yard stick is, with the nature of old KPIs, management still want and trying to maintain control where agile KPI’s mean to foster collaboration and more autonomy in the team.
4. Agile Contract in water-scrum-fall way of working:
In some scenario’s I observed that agile contract is centered on scrum-based delivery, but little deep observation tells nothing but another implementation famously known as water-scrum-fall (scrum and waterfall combined working). In this approach, teams work in sprinting mode but the rest of the surrounding organizational functioning is still waterfall based. This creates an illusion of agile delivery approach but it’s nothing more than waterfall approach wrapped in agile terminology.
In several parts of the world, lot of good work is also done on this subject and I would like to share some reference to avoid you ending up into one of those anti patterns of agile contracts.
- https://agilecontracts.org/
- 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
- https://www.wiley.com/en-us/Agile+Contracts%3A+Creating+and+Managing+Successful+Projects+with+Scrum-p-9781118640128