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.
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.
