An Agile Team and a Vendor Walk Into a Bar

Agile VendorMany Agile teams interact with vendors. Often times the way the team works clashes with the expectations of the vendor. This is especially true for new Agile teams that suddenly operate quite differently than what long-time vendors, through previous experience, have come to expect.

In this post, I don’t attempt to define all the nuances and different possibilities of an Agile team’s relationship with a vendor. Instead, I want to describe the two different ways of working with a vendor that I have seen or helped with. Hopefully these experiences can give the reader an idea of how to approach what can sometimes be a difficult situation from a different angle or with a different perspective. In reading this, I invite you to remember the third value statement of the Agile Manifesto

“Customer collaboration over contract negotiation”

As the customer of the vendor, the Agile team should strive to move the relationship in a collaborative direction.

Experience One: Planning Ahead

An outside vendor provided the platform of functionality for an Agile team I was coaching. The vendor provided API calls and data for the team’s application. From time to time, the team would discover the need for a new way to use the vendor’s platform. This would result in a request to the vendor for the needed functionality. After some back and forth writing a feature specification, the vendor would use waterfall planning and scheduling processes to fulfill the request.

The Scrum team had just started working in two-week Sprints. They soon realized that the vendor would not expect to provide the requested functionality within two weeks of the request. Historically, the discussions that resulted in a specification took about a week. Then the work would be scheduled 3-6 weeks out from that time and be delivered a week or two after that. The new functionality wouldn’t reach them for another five to ten weeks.

The team tackled the request fulfillment delay with a two-pronged approach.

First, they could do more Agile planning, detailing requirements just-in-time and for two or three Sprints into the future. However, for features dependent on the vendor, longer-range planning was required. They created two “user” stories for such features. The first was called something like a specification story, since user value would not result. This spec story was planned in an early Sprint as the work needed to build the request specification with the vendor. Acceptance criteria stated that the goal was to have the specification in the vendor’s waterfall schedule with a promised date for delivery to the team. A second dependent story, a real user story, was then written into the backlog where it would likely be picked up in the first Sprint after the expected vendor delivery. In this way the team made the work and schedule transparent to themselves, the vendor and the organization.

The second prong fell mostly to the Product Owner and other stakeholders to perform. They made efforts to collaborate more often with the vendor including:

  • Using phone conferences and video instead of email when coordinating
  • Being more open about the team’s Agile processes so the vendor better understood the new way they worked

Over time the relationship with the vendor was enhanced such that the specifications could be simpler and turn-around time of deliveries even improved.

Experience Two: People Integration

This situation involved a vendor providing what amounted to a full product and user experience that was subsequently embedded into the Agile team’s product. The major difficulties were low visibility into the vendor’s progress and slow resolution of defects after the coded features were delivered by the vendor.

The improvement here called for three significant adjustments:

  1. The vendor’s leadership and developers were invited to the team’s next release planning activities. They were able to work side-by-side to define deliverable and schedule all in one day rather than over weeks with phone calls and emails. The focused interaction also improved the shared ownership of the outcome, moving them closer to a true partnership.
  2. Concurrently, the Agile team worked with their operations people to provide an appropriate sandbox environment for the vendor. This allowed the vendor developers to test the new features within the Agile team’s product, which allowed them to reproduce reported issues, unlike in the previous work arrangement.
  3. The vendor and the Agile team also took the measure of inviting vendor developers to work at the Agile team’s location during key integration times or when particularly difficult issues arose. The vendor developers would participate with the Agile team as team members when they were working this way, increasing the connection between the team and vendor developers.

While the vendor did not change their own process very much, implementing these changes allowed them to become more integral to the work, and the Agile team enjoyed smoother deliveries as a result.

Collaboration Is Key

Collaboration is the key to a good working relationship between individuals, period. Its utility and necessity is much more palpable when groups of people are working together. My goal here was to detail how one group of people (an Agile team) can work well with another (an external vendor). My personal experience has shown me that enabling collaboration is largely a factor of building trust and rapport between the groups and between the individuals in each group. If there is one take-away from reading this post, let it be this: abandon email as the primary form of correspondence on difficult and/or time-sensitive workflows. Effective collaboration is a high-interaction process that email simply cannot reproduce. When we rely too heavily on ineffective communication means, the resulting value often falls short of our expectations.

What are your experiences working with external vendors? And what have you learned? Comment below!