Choosing vendors with agility.

Choosing vendors with agility

Blog post by Ieuan Wickham

Why you need an Agile RFx to find an Agile vendor.

As of last year, more than 50% of companies using Agile practices internally are not using them when they engage an external vendor¹. Instead, they are using Waterfall processes to bring a vendor in to an otherwise Agile environment. These companies recognise the benefits of Agile – including managing changing priorities, project visibility, time to market, and predictability. But, by using Waterfall processes, they are choosing not to get the benefits of Agile practices from their vendors.

There are a number of recommendations on how to include vendors in our Agile practices as part of a wider scaling of Agile within the organisation² ³ . Many organisations are aware of, and are using, these frameworks in whole or in part. Yet, they are still not using them to engage vendors. The engagement usually begins with a Waterfall RFx, which will define the vendor engagement.

The common reason for this, for the organisations and projects I have been involved with, revolves around risk:

 

The organisation feels that the best way to ensure value from the vendor is to agree on a fixed scope for a fixed cost and a fixed time.

Think about that for a moment.

We know this doesn’t work internally. But when it comes to our vendors, we think it’s going to be different this time. We think we can transfer the risk to the vendor and still be successful. We’re going to write a comprehensive procurement document which adheres to a documented procurement process. We’re going to negotiate a contract and follow the plan. And we’re going to rely on these things to deliver a successful outcome.

But we’ve already agreed that there are better ways. We know that the certainty we think we have by fixing scope, time, and cost is an illusion. We know that Agile practices provide us with the levers to control value, time, and cost. And yet, we’re choosing not to use them here.

There are a number of different frameworks but they have three key principles in common:

  1. Build relationships rather than contracts;
  2. Communicate what you want using stories rather than requirements;
  3. Discover the best option rather than choose.

Build relationships rather than contracts

A Waterfall RFx will:

  • Negotiate a contract that will define a required result;
  • Negotiate a collaboration that will lead to a valuable result.

Instead:

  • Ask about a vendor and their ability to deliver;
  • Ask about their values and their culture, to determine their ability to work with you. Introduce your company and its values, the project, your motivations. Ask the vendor to introduce themselves, as a company and as individuals. Find out what you need to start to build trust;
  • Ask about methodology, and specify documentation and results;
  • Agree a way of working together. Describe your project processes. Communicate how you want the vendor to behave. Define roles and responsibilities. Be clear about your expectations, the outputs you require, and at what stages you require them.

Communicate using stories not requirements

A Waterfall RFx will:

  • Define the current state, future state processes, requirements, and what the solution will do.

Instead:

  • Define the outcomes you are looking to achieve, and the value you want to realise;
  • Structure it using personas and stories, which will be the starting point for a conversation. The stories should be focused on the outcomes you want. They should avoid either spending too long building the RFx or over-specifying the solution too early. Only include the details that are significant in your stories;
  • You’ll still need to define the current state, but you can also do this using stories.

I’ve worked on a number of story-driven RFPs which have also included lists of requirements, or lists of required capabilities as a compromise. Key stakeholders will want to tie all of the user stories back to the list in the original RFP. Sometimes that’s useful, to keep the user stories together under a coherent scope. Sometimes it gets in the way, particularly if that RFP list was detailed.

Discover the best option rather than choose

A Waterfall RFx will:

  • Define a selection process that requires a fully-formed proposal for a solution, subject these to a short list, demos, and a final selection.

Instead:

  • Short-list and then conduct short discovery sessions with one or more vendors to find out more about their products and approach – and more about your problem;
  • Pay the vendors for their time – if they’re doing it for free then everyone’s more invested in making the project proceed with that vendor;
  • Use this time to further refine the epics and features, and potentially user stories, for the project.

I’ve been involved in this more than once using a shortlist of two or three, starting with the top candidate vendor only. We started the discovery work for a defined period of time, and dug into more detail about what needs to be solved and how it would be solved.

The premise was that, even if the first vendor didn’t work out, we’d still get a lot of learning done – and at least some of what we learn during this discovery would be useful. At the very least we would have learned that our first choice vendor didn’t work out, and that’s good to learn before we spend any more money.

Because this is the best option

Right now, you’re more likely than not to be searching for vendors using Waterfall RFx processes, which are built around a Waterfall methodology that you already know won’t deliver what you want. If that’s the case, then you’re more likely to fail.

If you’re already building Agile vendor relationships, then good for you! Encourage others to do the same. Help them, if you can.

If you’re not, then next time you start a procurement process, think about how you can use it to build a collaborative partnership rather than a contracted solution. Use an Agile RFx approach rather than a Waterfall one. If you do, you can unlock the benefits of Agile practices when finding and engaging a vendor, so that your projects can succeed – because we all want our work to be successful, to leave a lasting and tangible benefit.


 

Ieuan Wickham is a facilitator, investigator and analyst, helping organisations find solutions for difficult problems at the intersection of people, processes, and technology. He is particularly interested in helping organisations unlock the existing knowledge and information they have to break through the barriers or realise opportunities that exist.

You can find Ieuan at [email protected]

 


¹ 12th Annual State of Agile, VersionOne
² Scaled Agile Framework (SAFe)
³ Disciplined Agile Delivery (DAD)
Distributed Scrum: Agile Project Management with Outsourced Development Teams (Jeff Sutherland, Ph.D.; Anton Viktorov, Jack Blount, Nikolai Puntikov)
The Agile Manifesto
Finding a Partner to Trust: The Agile RFP (Peter Stevens)
Agile contracting: How to ensure speedy development and accountability (Robert Kriss, Brad Peterson)