#90-Agile With Vendor Relationships

If you are agile but your vendors are not, how can we operate effectively?  That's what this episode is all about.

Transcript

Agile With Vendor Relationships

When planning and implementing an agile process, it must be acknowledged that a given organization does not exist in a vacuum. There is an ecosystem that surrounds the effort, which includes governmental regulators, subcontractors, vendors, and other organizations that are impacted by what we do but also impact what we do. 

This week I want to focus on how we can be effective when working with subcontractors and vendors who may not themselves be engaged in an agile approach. 

I once worked with an organization that managed large commissary kitchens. We're talking about airlines, schools, prisons, and other places where large amounts of food need to be prepared on a regular basis. Whereas this organization embraced agile methodologies, they were dependent on many other organizations such as food vendors and subcontractors that created elements of their dishes, most of which were more traditional in the way that they operated. 

Part of the problem deals with the fact that agile is all about embracing change, and change creates uncertainty in planning. But vendors often depend upon predictability so they know exactly what they're going to deliver, when it's going to be needed, and how much they're going to be paid for it. They often have fixed schedules determining when they will be able to deliver needed elements of a product that they are unwilling to change. But agile teams need flexibility, and this can create a conflict especially when negotiating contracts. 

The first and most crucial step in overcoming this mismatch is in redefining the relationship from supplier to strategic partner. Rather than seeing the relationship as transactional, the vendor must embrace the idea that this is a partnership where everyone will benefit from success. A vendor may be resistant to this idea, but I find that the best approach is to offer a pilot program so that they can see the benefits they will accrue from operating in this way. 

If they are willing to do this, then we involve them very early in the planning of the product itself. This allows them to understand the value of the business that we will be engaging in, they will be able to participate in the discovery of requirements and constraints, and they will not be held solely responsible for the outcome of their responsibilities. This means literally inviting them into sprint planning, or whatever similar process you engage in, backlog refinement, sprint reviews, and after-action reports.  The result will be that vendors will understand why something should be made and not just how it should be made, not just what to build but why it matters. 

This also requires that we change the nature of the contract between us. Agile does not eliminate contracts but it does change them.

An agile contract suggests incremental delivery, clear exit points when problems are discovered, and defined metrics for success. In the organization I worked with they used scrum to manage their business and so they came up with the notion of a fixed cost per sprint, where the scope of work was flexible but that the costs were stable. This allowed vendors the predictability they need in terms of their own finances but allows for a structure that supports learning as we go. 

This all ties into the notion that agile is simply a reflection of reality, that transparency helps to eliminate surprises, and surprises are expensive to everyone. 

One thing that became clear to us is that the product owner is a critical role because we need to be able to assign responsibilities for each aspect of our process in the right way, and this requires someone with that expertise. The product owner will decide who prioritizes the backlog, how change is managed, and the acceptance criteria for completed work. Product owners can help to prevent unnecessary meddling in the vendors internal processes, which they will appreciate. A good product owner will define the roles and rights of decision making early in the process, which again creates a level of predictability that vendors need. 

Vendors who participate in an experiment along these lines will learn that what is measured in an agile process is outcomes not just deliverables. They will learn that customer impact is the most important measurement of success, that cycle time and defect rates need to be measured to create more predictability on future sprints, and that business value is always paramount. 

In the commissary organization I mentioned before, this turned out to be even more successful than was hoped. The relationship they had with their vendors became much more healthy, and the improved communication and focus on outcomes actually allowed those vendors to manage their own businesses better. Many of them ended up adopting agile themselves. 

Next week I will discuss the best practices for dealing with regulatory regimes in an agile process. I hope you'll join me.