Agile Vendor Management- The Promises and the Pitfalls

For a large number of companies Agile development has been very successful.

Agile development methodologies have enabled companies to drastically reduce product release times and become more responsive to user needs.

In Agile development, business and IT is joined at the hip and this necessitates a drastic shift in mindset for everyone involved. For developers it means that they will have to focus on solving business problems over and above overcoming coding challenges.

Therefore leaders need to raise trust levels between team members, encourage frequent communication, and break down silos associated with traditional software development.

But Agile can happen only when the team is co-located and communications happen in real time. There is no way it can work in situations where the coding is done by a third party vendor at a remote location, possibly in a different time zone.

The growth of Distributed Agile

Or can it?

Distributed Agile, or Agile development by teams spread out across multiple locations is slowly taking off across multiple industries.

VersionOne’s State of Agile 2015 report which surveyed 4000 IT pros, 65% of who were based in North America, found that nearly 80% of the respondents had experience or familiarity with Distributed Agile in 2014, up from 35% in 2012. (pp. 8).

Distributed Agile is driven by factors like limited IT budgets, skill set mismatch, and the need to adjust to rapidly changing market conditions and customer preferences.

For instance, a logistics company who needs a mobile app for its employees in the field will have to opt for a third party vendor to design, build, test, and maintain it.

However the app development process may have to be Agile because of rapid changes in the mobile landscape and because of the need to rapidly incorporate new features as per user feedback.

And while the benefits of Distribute Agile might seem apparent, the exact process is quite murky.

The Culture Gap and the Incremental Way of Working

Working with third parties is always a risk in software development. If the stakeholders choose the Agile way the risks can multiply because specs keep on changing and costs and timelines cannot be locked at the outset.

One of the biggest issues in these kinds of projects is culture mismatch.

Agile projects succeed in a collaborative culture where team members work in an incremental fashion, and where there are high levels of trust.

Think of it like this:

I am a member of the client team and you are a member of the vendor team.

If we are doing an Agile project, it will go smoothly only if all my team members collaborate and rapidly build upon previous features and quash bugs…

….and your team members collaborate and work iteratively…

…and all the members of our teams, including you are I, are in constant touch with each other and work incrementally.

Essentially, the client-vendor relationship for a successful Agile project would look like this grid:

 The Three Questions to Ask your Agile vendor

In case you have decided that it makes business sense to bring in a vendor for an Agile development project and there is a cultural fit between you two, you need clarity on certain issues before getting started.

1) How much is it going to cost?

You should get an idea of the estimated costs before signing on the dotted line. If project costs are fixed then you have two options- keep the scope and/or the time flexible.

A number of companies set specific amounts per story point to estimate total cost of the project.

2) How much time is it going to take?

For some projects budget can be adjusted but if there is a hard deadline (for example, shipping a product whose launch date has already been announced) it is important to understand what features will be included at what cost so that there are no unpleasant surprises in the future.

3) Is it going to solve my problem?

Software needs to solve business problems. Even though in Agile development the SoW might be more open ended than in the Waterfall model the final product still needs to meet certain standards.

In such a scenario drafting an outcome based contract instead of detail specific contract is the key, because then everyone can focus on the end results instead of getting bogged down in specifications and other minutiae.

Pre-requisites for Distributed Agile Success

In traditional Agile development the product owner is also responsible for building the product. This is not so in client-vendor Agile model.

However, this does not let the owner off the hook and unless she is intimately involved with the vendor’s team especially during the first two or three sprints the project is doomed to fail.

Don’t consider upfront cost savings while engaging a vendor for Agile development.

Consider Agile vendors for the benefits that you will accrue if a business problem is immediately solved without having to invest in an in-house team.