3rd Parties in Scrum Process Question

Last post 04:28 pm July 18, 2014
by Ian Mitchell
1 reply
Author
Messages
03:54 pm July 18, 2014

I am a new Scrum Master at a fairly small non-profit org. We began implementing scrum in January and are doing pretty well, but have plenty of room to improve. We may be close to a big challenge, which brings me here to seek input.

We are in our 9th sprint of a big, intensive web import project and we only have 3 developers. Management has recently decided that they want our developers to completely re-design the org's website and maintain complete control and ownership of everything. Somehow in this process, it seems they are planning on hiring a 3rd party, outside of our org, to help since we are a small team. I don't know how to work with 3rd parties in the scrum process and need help in ways to do that.

Do we expect a rep from the 3rd party company to become a part of our processes and call into the daily scrum and be in all of our discussions?

Do we let them work as they need to, but refrain from including any of their deliverables in our backlog (as sprint ready) until we can verify those items are ready?

I'm open, I just don't know how to work in that scenario since I'm pretty new at this.

Another side to this is time and prioritization. We will have the same team working on 2 large projects. I do not know if the Product Owner will be the same or if it will be a different person. Whatever the case, I'm not sure how to prioritize work (or coach the PO to do so) so that neither project suffers. Thankfully, there is no time limit that has been announced, but I feel like there should be some form of time goal so it doesn't go on for eternity.

Any thoughts or suggestions on any of this? Thanks in advance!

04:28 pm July 18, 2014

> Do we expect a rep from the 3rd party company to become a
> part of our processes and call into the daily scrum and be in
> all of our discussions?

It sounds as though the 3rd party will be contributing to each increment, and that the Definition of Done will not be satisfied without their efforts. That makes them part of your team. You do not need to run them as a separate team, because you only have 3 developers to begin with.

You should therefore "expect" to have the 3rd party developers on site and fully integrated with the team you have. We are not just talking about a representative here; we are talking about all of the people who will be doing the actual work...the people who are responsible for inspecting and adapting their process, and for meeting and improving the Definition of Done. In Scrum one should expect these people to be co-located in order to make communication and collaboration as effective as possible.

> Do we let them work as they need to, but refrain from including any of
> their deliverables in our backlog (as sprint ready) until we can verify those
> items are ready?

That may be a defensive option if the 3rd party workers cannot be co-located and included in the team. In effect, they would have to be run as a separate team contributing to the same increment. They can collaborate in terms of release co-ordination, possibly via a Scrum of Scrums, but that is less effective than having them inducted and co-located in the same team, which is currently very small.

> We will have the same team working on 2 large projects <...> Thankfully,
> there is no time limit that has been announced

Consider running sprints of no longer than 2 weeks each and interleaving them, so that the team works on each project in alternate iterations. That way, you can still deliver a potentially releasable increment every month for both projects. You can operate 2 different Product Backlogs and it doesn't matter if the PO is the same. All you need is their agreement and organizational buy-in for this operating model. If you have 2 separate PO's, I'd strongly advise getting protocols in place for how fixes or emergency unplanned work will be handled out-of-sprint for each project, as the unforeseen will always arise. This doesn't have to be anything formal; it could just mean deferring the prioritization call to a more senior stakeholder, but whatever it is you should take care to set expectations clearly.