How to become an Agile vendor…. Getting started

18 December

As Agile methodologies are becoming more popular, many organisations are looking to deliver all projects using incremental and iterative delivery approaches – not least of all those organisations looking to thrive in the highly competitive field of delivering software development services. This is the start of a 4-part series discussing the benefits of becoming an Agile vendor as well as some approaches on how to take your clients “on the journey” with you.

While the foundations required for a successful transformation from linear (waterfall) to Agile development have been well documented (for a quick refresher try ) one question that is becoming increasingly relevant for those in a vendor environment is “how do I manage my client relationships in an Agile environment”?

Having been fortunate to work for a variety of vendors using both waterfall and Agile approaches I have experienced some of the challenges both customer and vendor organisations face when transitioning their working relationships into the Agile space – this blog series is an attempt to summarise my past experiences as well as learnings.

In the first blog of the series we’ll be looking at the differences in bidding for and contractualising software development services in an Agile environment:



Yes, even before your services have been selected, there are challenges. Traditionally, an organisation would send out a “Request for Proposal” (RFP) containing more or less information about their high-level requirements and asking for (often fixed cost) quotes for different phases /activities  (e.g. Requirements Analysis, Design, Hardware & Infrastructure, Development, Testing, Deployment) deemed relevant.

So how do you answer an RFP asking for quotes applying to a linear development approach when your delivery method is based on incremental / iterative development while embracing changes in requirements throughout the project?

One option would be to simply answer the RFP as you usually would and explain your choice of delivery approach and your associated requirements regarding customer input and collaboration in the “Approach” or “Methodology” section of the document. While this can work, this approach might also just help you to find out exactly how many people read an RFP cover-to-cover (in my experience, the answer would have to be “not many”). The alternative here would be to start the engagement in the way you would like it to progress – openly, honestly and collaboratively. Approach your (potential) client to explain your approach and why you believe Agile methods would be most suited to their project and how this will impact your response to the RFP document. If possible, ask for a face to face meeting to reinforce the benefits of your suggested approach – not only will this establish a relationship with (some of) the project stakeholders from the outset, it will also give you a much better understanding of the project background, strategic drivers, etc. thus providing an advantage over your competitors.


Contract Negotiation

Congratulations – you have made it through the first hurdle and have been selected from a pool of vendors. Introduce Hurdle no 2 – contracts in an Agile environment! Needless to say, fixed price, fixed scope contracts will negate many of the benefits provided by Agile methods so it’s clear we need to change our approach to contractual agreements in order to set the stage for a successful vendor-client relationship. An informative and useful overview of the dos and don’ts in Agile contracts  can be found on the Cutter Consortium’s website on

At this stage you might have decided that I’m a) over-optimistic or b) a fool in believing that any of your clients (or maybe even your boss?!) would agree to any of the above – you definitely wouldn’t be the first one to think so! Personally, I go with the Agile Manifesto ( ) and value customer collaboration while firmly believing in the benefit of openness, honesty and transparency – even if it means having “hard conversations”! Yes, you may lose a bid or two (in fact, I’d almost guarantee that you will), but how many of your projects are currently unprofitable? How many of your “successful” projects have become “bottomless pits” you throw resources at to avoid the fallout of disgruntled customers? Looking at the bottom line, were they really worth that extra discount or those additional contract clauses that sealed the deal?

If any of this sounds familiar, hard conversations may be just what you need, and improved client relationships may be just what you’ll reap!

In the second part of the series, we’ll be looking at what to look for in an Agile project /product vision and how to plan an agile project with your client, so watch this space….