How to avoid training external consultants who hold a different agenda?

Question

A large organisation is undertaking an agile transformation. There is good engagement from the senior management team and external agile coaches were hired to support the adoption of agile.

One agile coach, whilst taking a few teams to coach, realized that the consistency of the team is 80% (consultancy name here) employees and 20% permanent employees. The consultancy has been called to roll out a SalesForce implementation, they have their own waterfall agenda (resources, cross team dependencies, status reporting meetings etc) with no interest in embracing transformation themselves, and maybe fairly so.

I think these teams can't go very far as far as agile adoption/coaching goes, and they wouldn't need to anyway.

How does one circumvent the fact that the teams he opted to coach consist mostly of external consultants?

Answer 1

Agile is a team-based approach.

I don't believe there is any way you can selectively coach or in any way differentiate between team members and still have a successful Agile working environment.

However, it is important that the rules of engagement of the consultancy are set correctly. There needs to be a clear understanding that every team member is expected to follow the Agile approach and to work in a collaborative fashion with the Agile Coaches.

My recommendation would be to get the consultancy management into a meeting with the Agile Coaches and your organisation's senior management. Get a the terms of engagement clearly defined so that nobody is in doubt of what behaviour is expected.

Answer 2

I think it matters how the consultants are contracted for work. If they are contracted as time and materials and are more staff extension, then a team is a team is a team. If they are contracted to deliver a scope of work under a proposed and purchased method, then training them in anything is inconsistent with that kind of set up. Moreover, if their methods are inconsistent with the transformation you are seeking, then you have a change management obstacle that will inhibit or even disrupt your success.

Answer 3

TL;DR

This shouldn't be a coaching question. The real focus should be on how to effectively collaborate with your vendor as a business entity and with their people. It's likely that some critical step was missed when chartering this project, and those initial assumptions should be carefully reviewed to ensure that the project itself is operating as intended.

How to Proceed

How does one circumvent the fact that the teams he opted to coach consist mostly of external consultants?

This is likely to be a problem with the way your company is composing or managing "teams." Teams aren't just gaggles of people thrown together; a team must be composed of people with common goals and a compatible working style. Just because you have both internal and external resources allocated towards the same objective doesn't make them a team; on the other hand, using outside resources doesn't inherently prevent teaming, either!

The underlying X/Y problem isn't about agility, or the lack of it. The primary questions should be:

1. Who is managing the outside consultants or the engagement within your organization?
2. Who is responsible for meeting the project's key objectives?
3. Are the goals of the consultancy and your company's management team contractually or pragmatically aligned?

Embedding your internal resources onto a vendor's team is fine, but doesn't give your organization any control over day-to-day processes. Likewise, bringing in a consultancy to deliver a service doesn't obligate them to follow your internal processes unless it's specified in the contract.

Your company isn't powerless. The golden rule is "He who has the gold makes the rules." If you want a different process or a different organizational or contractual structure with your vendors, you can do that. That's not a question of training or not training them, though; it's a much more complex issue of how you engage with a vendor, and what controls you put in place to manage the processes and outcomes for a particular project.

Before you spin your collective wheels on the training issue, step back and ask why you want these teams to be agile. If they're supposed to be internally-managed teams supported by embedded resources, and if how the project integrates within the overall organization intrinsically matters, then by all means inspect-and-adapt your team management and process framework. Otherwise, you're probably focusing too much on process and not enough on goals or outcomes.