Agile Vendor Management

AGILE VENDOR MANAGEMENT

During PSM training, students often ask me whether Agile can work with vendors or how to work with a client as a vendor. My answer is that this can work, but it requires a lot of trust and courage from all the parties involved,  as well as a willingness to do things differently.

Trust and Courage

The number one issue regarding Agile vendor management is the lack of trust between parties. A common situation is that business units mistrust internal IT and internal IT mistrusts vendors. Vendors also often feel that they are not part of the team.

As vendors, we can either build trust first by personal relationship or team building, but the best way to build trust is to deliver results. The Development Team delivers work Increments Sprint by Sprint. If a Product Owner is not happy with the results, he or she can cancel the Sprint contract (more on that later). We ask both parties to take a leap of faith, and we can start the experiment for a few Sprints.

Contract - Statement of Work (SOW)

The most common contract for outsourcing is a properly-devised statement of work. Clients list out all the requirements, and vendors take care of the delivery.  Under this arrangement, business units often end up blaming IT for anything that goes wrong, while IT, in turn, blames the vendors. We have found that this arrangement does not typically produce the best results, especially for Agile projects.

If we are running Scrum, there will be lots of changes. The Product Owner can change the details and order of the Product Backlog at any time. If we follow the contract strictly, then every time the Product Owner changes his or her mind, we have to follow the change approval process, resulting in a lot of waiting time a lot of paperwork. This is neither realistic nor productive.

A slightly different model under (SOW) would be that we simply list out high-level Product Backlog items to be done and then list out Sprint Goals and the Increment to be done in each Sprint

But that would be still problematic if there’s a great change of direction, which is quite common for large projects or programmes. Once we have built trust through a few Sprints or through a few projects, we can possibly change to a different contract format that is more favorable to Scrum.

Contract - Time and Material (T&M)

As stated in the Scrum Guide

"Each Sprint may be considered a project with no more than a one-month horizon.”

So, naturally we can consider each Sprint by itself a Project, then naturally we can have a contract per project, a fixed-time period as a contract itself that naturally becomes a time and material contract. We specify how much we pay to vendors per Sprint considering the number of people, daily rate, role, experience, and other factors. Then we usually can come up with a lump sum, such as 100k HKD per Sprint. We can also bundle multiple Sprint into a single contract to make the process easier for both parties

Termination Condition

We have asked the client to take a leap of faith and trust the vendor to deliver a flexible scope during a Sprint, but sometimes the Development Team may fail to deliver a working Increment. These terms seem favorable to the vendor, so what’s in it for the client? In the Scrum Framework, the Product Owner can cancel a Sprint, then in the contract, we can specify how many Sprints we plan to go through. This number can be as few as 2 or 3 Sprints. In theory, you can do 1 contract per Sprint, but this ends up being a lot of, so we often bundle to at least a few Sprints. As clearly stated in the Scrum Guide, Product Owner can cancel a Sprint:

“A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.”

Getting Started

So, what should we put in the contract? The following would be a good start:

• Sprint Duration

• Termination condition and notice period (typically by Sprints or months)

• Cost per Sprint (or daily rate for each member in the Scrum Team)

• Scrum Team member names and percentage of commitment (typically just Scrum Master and the Development Team members)

I suggest naming the team members in the contract both to build trust and have a consistent team. Scrum works better if we have a consistent Product Team, and ideally if all the Development Team members are 100% committed.