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:
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?”
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
[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/
