Agile Vendor Management

Scope:
Sometimes it makes sense to outsource a delivery or augment an existing Agile delivery using a people externally to your company from a Vendor. This article talks about how to still be Agile once the people come on board for your delivery.

Problem:

While there are many great articles on the net about how to engage a Vendor to supply people, few discuss what happens how to manage when the Vendor is on board. The often talk about how to get them in not how it works once the engagement is authorised.

Examples Include:

• Agile Vendor Management [1]
• Agile can’t be adapted to manage/control vendors. [2]
• Create a Vendor Contract While Keeping Agile [3]
• Making agile work for clients and vendors [4]
• Managing Client and Vendor Expectations [5]

While these are fantastic articles, one you have them in? What do you do?

The the real problem with Vendor Management is the same for all teams whether they are internal or external. How do you keep them Agile on the delivery?

We need an Agile approach for Vendor management set-up. But what does that mean? Let us look at the tangibles.

As most organisation often do, when creating a new team, to ensure that it remains Agile we can use proven prescribed methods such as Scrum to help us here. Scrum Theory as advocated within the Scrum guide has:

“Three pillars uphold every implementation of empirical process control transparency, inspection, and adaptation” [6]

Scrum Pillars [7]

Team Augmentation Set-Up:

For augmentation when using Vendor product as an enabler for the overall end product, it is wise to have at least one member of the delivery team from the Vendor. This means that Vendor enabler for delivery can be set-up, integrated and supported by the Vendor itself with visibility of transparency to the team, from within the team as it delivers. It also allows the team to inspect and adapt to the underlying product as knowledge is transferred from Vendor to the rest of the team.

Examples of this could be a racing team that uses a different underlying engine from a Vendor manufacturer. Having the Vendors expertise on site will greatly help the racing team integrate the engine correctly and fine tune it overall as the racing car is raced again and again. Similarly for a micro-services team leveraging a Vendors ESB product. Having a Vendors expertise working with the team to set-up, integrate and maintain the product allows transparency and the opportunity for the team to inspect and adapt with the underlying technology.

The augmented member of the team must become one with team and the team one with them.

External Team Set-Up:

In the situation when the team is supplied by a Vendor, things get more complicated naturally with more external people. Thus a different approach to leveraging Scrum is required.

When looking to on-board a team, co-location is paramount. However how does one gain transparency to the team if co-location is challenging? Including the technical delivery level, when the team is not part of the organisation? Here the reverse of augmentation can be applied. Whereby an internal employee joins the team, preferably as the Team Lead/Scrum Master.

If you cannot supply a trained, experienced Scrum Master then it is better to have Vendor face off. Whereby one Vendor supplies the Scrum Master and the other supplies the team. The Scrum Master then should be able to provide the transparency into the teams Agile capability at all times. Their job will be to servant lead the other Vendor team. Make it clear that they will never be able to supply their own team so, they must work together to make it work. This should stop the risk of mini-waterfall happening under the covers.

Most Vendors do not like this as they often over the long term want to keep all their failings hidden, having their own lead allows them to arbitrage the Client when they need too. Do not let them get away with it. If they won't comply then do not give them the Business. It's that simple.

Next, if you can possibly do this, is to interview everyone who is in the team. Often Vendors will hoodwink the Clint by supplying one or two top people as loss leaders and the rest are so, junior they might as well be off the street. Why would you want to hire a mediocre team? Make sure the team is stocked with senior people in the expertise that is required. Creating an Elite team is the only way to provide a delivery on time, to budget and to quality. If you cannot do this, then once again get another Vendor to interview them. Bring the expertise in, but in the right way.

Once again most Vendors will be aghast at this. Often stating that:

“we supply a managed service, we do not allow body shopping”

Actually this is how Vendors recruit themselves, one person at a time. They hardly ever recruit whole teams. Remind them of this, because if its good enough for them. It is should be acceptable and good enough for their Clients. 

As a side note when recruiting software engineers/developers it has been my experience that rather than asking for Agile ones, asking for people that are experienced in TDD is more beneficial for the delivery. Agile methods seem to be quicker to teach than TDD. Thus I find TDD experts learn Agile faster, than the other way around. Focus on this first for skills in recruiting developers if you can.

TDD Source [8]

The other excuse is:

“How can we ever develop our people if the more junior people are never allows to work with the customer?”

Their miss-management of their Business, should not be your problem. If they want to develop junior staff, then you may be willing to risk allowing them in the team your paying for if they are supplied for free. If not, then that is their problem. It is not up to you to manage their Business. You have your own to worry about. Do not let them place sub-standard people within the delivery team your paying for. If this costs extra, then it is worth it to avoid the risk of failure.

The Product Owner must be from your Business. This role cannot be outsourced. It is too critical. From the principles of the Agile Manifesto:

“Business people and developers must work together daily throughout the project.” [9]

Which leaves us to apply the some standard Agile/Scrum framework techniques:

• Single PBI system to track all work. This avoids arbitrage of priorities.
• Independent Scrum Master supporting the team, whilst also being loyal to the Client.
• Team is empowered to get on with the delivery and is not hit by any politics of Vendor vs Client.
• Agreed Ready state (not Scrum, but you can use a DoR) that evolves as the team makes discoveries. Avoiding Garbage In.
• Agreed DoD that evolves as the team makes discoveries. Avoiding Garbage Out.
• Review Event has two inputs, a demo for sign off in an independent environment and potentially shippable product.
• As the Product is delivered, then document the delivery. Preferably in the company Wiki and knowledge transfer everything. How everything is enabled, set-up, maintained. Everything to do with the Product and around the Product.
• Provide collaboration tools, chat, tele/video conferencing not just email or issue trackers. Work as a team. This allows Inspect and Adapt, with Transparency.

Scrum States of Ready and Done source [10]

Charging Model:

Fixed Price never works, unless you know the Future. Either the Client gets a deal and the Vendor sacrifices Quality to make a profit or the Vendor gets a deal and the Client over pays. There is no in between and anyone who has done it successfully has gotten lucky. Luck is not a professional way to run a Business, it is gambling.

Time and Materials gives you a complete breakdown transparency of costs as you go along. With fixed team sizes in Scrum one see costs upfront for 3-6 months in advance. Here the Client has the lead and the Vendor gets paid for the work they actually deliver, not what everyone guesses they may deliver or not!

It also allows you to see a breakdown of the costs per person and allows you to hire by each team member as eluded to above. As long as the Scrum Master and Product Owner are internally your people, then they can also prevent the risk of the Backlog growing forever with perceived never ending work.

Here both sides win as the details of the delivery are not constrained by the contract but by collaboration. As the Agile Manifesto states:

“Customer collaboration over contract negotiation” [11]

Client leadership, by renewing when needed or off-boarding the team after any 2-week Sprint.

Off-boarding:

Very few Agile articles talk about this. Even with long-lived teams at some point either you will provide your own team members or the delivery is done, done. At this point the Vendor has to go. If you have followed the approach above, with Time and Materials, independent Scrum Master, Business Product Owner, full transparency, documented Product whereby the artifacts are all owned in-house. Then it is as simple as just ending the Business contract.

This is why the above approach is optimal for delivery, as it mitigates the risk and puts most of the power back in the Clients hands without crippling the delivery team.

Do we have to use Scrum?

No we do not. Kanban for example is quite affective for flow based deliveries. However Kanban can quickly turn into “throw it over the wall” for immature teams, then quality is lost and it becomes an Agile cargo cult.

Thus a prescribed approach at the start with a Vendor lets everyone know where they stand. Scrum is also well known and understood. Re-use what we know works.

Agile Link:

The link is to leverage Scrum, to utilise a Time and Materials approach whereby the Roles and Responsibilities are defined up front without sacrificing the capability of the team being Agile. This is why Scrum is a part of my Agile poster [12].

While Elite teams often move towards a more flow based Kanban approach over time, some of us have to deal with Vendors. In this case Scrum comes ready made Out Of The Box. If we are careful we can have the best of both worlds.

References:

[1] Agile Vendor Management: https://blogs.msdn.microsoft.com/nickmalik/2004/10/16/agile-vendor-management-removing-waterfall-from-outsourced-projects/

[2] Agile can’t be adapted to manage/control vendors: http://agencyagile.com/agile-for-agencies-myth-14-agile-cant-be-adapted-to-managecontrol-vendors/

[3] Create a Vendor Contract While Keeping Agile: https://www.techwell.com/2013/05/create-vendor-contract-while-keeping-agile

[4] Making agile work for clients and vendors: https://austin2014.drupal.org/session/consultancy-scrum-making-agile-work-clients-and-vendors.html

[5] Managing Client and Vendor Expectations: http://www.agilealliance.org/wp-content/uploads/files/session_pdfs/Managing%20client%20and%20vendor%20expectations%20in%20an%20agile%20project.pdf

[6]: Scrum Guide: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf#zoom=100

[7] Scrum Pillars Image: http://www.slideshare.net/vineetpatni31/scrum-a-short-guided-tour

[8] TDD Image: http://blog.cellenza.com/alm/visual-studio/tutorial-test-driven-development-with-visual-studio-2012/

[9] Agile Manifesto Principles: http://agilemanifesto.org/principles.html

[10] Scrum States of Ready and Done image: http://www.innolution.com/blog/definition-of-ready

[11] Agile Manifesto: http://agilemanifesto.org/

[12] Agile Poster:
https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html