How to deal with external vendor using agile approach?
Hi All,
Today question is: how to deal with external vendor, when our project is supposed to be agile/scrum based? It is not based on some specific project, case study rather.
Few risks I can see here are:
- unclear goal we want to reach, from requirements perspective. We don't have full requirements analysis upfront - it is supposed to be conducted during the project.
- hard to plan project end - as requirements and feedback can change the scope and make project longer
- costs - time&material is risky for our organization, on the other hand, fixed price is hard to negotiate without significant overhead due to previous two points.
- control over the project - which organization should PO and SM came from, as almost whole dev and qa teams are from vendor's side.
I will appreciate your input both theoretical and from your practice.
BR,
Maciej
What do you think of the idea of having multiple small projects one after the other, each providing an increment of functionality that is immediately usable, and which thereby leverages empirical process control to maximize value?
What is the exact relationship between your organization and the vendor?
Many of your concerns should have come up during your vendor assessment and selection process. One example is that you don't have full requirements up-front. This should have been made clear to the possible vendors and they should have been able to address how they intend to satisfy those needs as part of their bidding process. Likewise, using statements of objectives rather than statements of work can help handle the changing requirements and feedback.
If most of the development team is from the vendor, it would probably be best to work with the vendor to understand what practices they want to use and how you can best support them. Your vendor is providing you with products and services, so in most cases, I'd want to assess the service provider to make sure they can meet my needs and then let them do so, providing the information and interactions that they need to be effective. The type of information to be provided, possible formats of the information, who the key contacts between the organizations are, and how the interactions are managed would all be part of the agreements between your organization and the vendor.
Hello Ian,Thomas,
Split for smaller projects is indeed good idea, worth considering.
Relationship is in fact none, this is external vendor. And indeed whole development team is supposed to be from vendor's side. We assume for the case, that vendors selection is limited to those who work in scrum framework.
In this study important factor is control or measurement of the project progress. There is doubt that if both PO and SM are from vendor's side, this will affect those factors. Additionally multiple (2-3) streams, and dedicated teams are expected, so each of them will have separate PO and SM probably. Would it make sense to require from vendor that some of these roles are taken by our organization's members?
BR,
Maciej
Relationship is in fact none, this is external vendor.
This needs to change and evolve incrementally and as quickly as possible from both your organization's end and vendor's end.
In this study important factor is control or measurement of the project progress. There is doubt that if both PO and SM are from vendor's side, this will affect those factors.
Would you rather have complete control and ability to measure everything at all times (especially if there are a lot of unknowns in the product) or a collaborative relationship with transparency and respect?
Additionally multiple (2-3) streams, and dedicated teams are expected, so each of them will have separate PO and SM probably.
If the vendor is working on a single product it is highly unlikely that they have multiple POs. There is no strict mandate on the number of SMs in the Scrum Guide. However, if you notice there are multiple POs working on a single product and they have branched the product the way your organization deems irrational, your organization should inspect it and must step in to address the issue.
Would it make sense to require from vendor that some of these roles are taken by our organization's members?
I may be sensing it incorrectly but I feel that there is a fear of losing control. There is a lack of trust and it is understandable. However, I sincerely feel it may be unwarranted unless there is a precedence that this vendor has failed to deliver the value in the past consistently (then it is unlikely that would be chosen). Otherwise focus should be on building trust and collaboration and not exaggerating about losing control over measurement and progress.
Relationship is in fact none, this is external vendor.
It is impossible for you to have no relationship with the vendor. There are all kinds of options. They could be simply a supplier or there could be varying levels of partnership and collaborative work. Regardless, there's some kind of relationship between your organization and the vendor. You should define that relationship.
And indeed whole development team is supposed to be from vendor's side. We assume for the case, that vendors selection is limited to those who work in scrum framework.
In this study important factor is control or measurement of the project progress. There is doubt that if both PO and SM are from vendor's side, this will affect those factors. Additionally multiple (2-3) streams, and dedicated teams are expected, so each of them will have separate PO and SM probably. Would it make sense to require from vendor that some of these roles are taken by our organization's members?
As a customer of a vendor's product and services, I wouldn't concern myself with the framework that they use or any kind of control over the effort. I would assess their ability to meet my needs and work with my organization. If they can't, then a new vendor should be found.
Unless you have a more collaborative relationship, I'd be very hands-off. No one from your organization should have any roles other than "stakeholder" or "customer" or "user". Ask the vendor to explain how can do what you need them to do within the constraints that you have and then let them do it. Define and observe some key metrics and SLAs, and if they aren't met, either work with the vendor to correct them or find a new vendor.