Coordination of external partner teams
Hi everyone,
I am Scrum Master for two teams and one of the teams has an external partner team which develops a functionality that will be integrated into the work of my internal teams.
Tasks:
- Technical support
- Selecting tasks from our backlog they can provide and that dont have dependencies on other tasks
- Budgeting on how much money we will spent on the team and how many members are needed
Company Policy:
- They can not be part of our internal scrum events
- The only events the internal and external teams can share are PBRs
Current Situation:
One of the team members with experience in their field of application does the job and has barely no time to do his/other stuff,
Unfortunately he is also one of the most experienced internal developers and we really need his knowledge and time internally to get
our part done in time and in the quality needed.
Our PO is also already loaded with work, as he has multiple teams and we have lots of internal customers.
Question:
Now the team approached me and asked how we can improve this and get this team member to work more for "us" and if I could ask Linemanagers to do the job and the team member just supports for technical questions. They proposed an experiment where every two sprints another team member does that coordination job, but I am not sure this might end up in too much communication problems and not being consistent about what we tell the external team.
Now I have the question about who should to the coordination of external partner teams? They themselves do have a Scrum Master on their own, but no PO (as far as I know... I'm quiet new.) The Product Owner or the Linemanager or one of the Team members or the whole team?
I already looked in the forum and searched for that topic but did not find anything related.
I really appreciate any help here, as I am not sure what the best solution here would be.
Thank you guys.
Best regards,
Ben
They proposed an experiment where every two sprints another team member does that coordination job, but I am not sure this might end up in too much communication problems and not being consistent about what we tell the external team
Your team is trying to be self-organized and self-managed and you are, as a Scrum Master, is pushing back? True, your fear might manifest but it could also not. You will never know until you try.
There is not going to be a best solution that we can propose. The best solution will have to come from the people doing the work. You have them offering suggestions so let them try it and then adapt based upon what they learn.
To build on Daniel Wilhite's comment, it seems you have a team that is willing to try new things in order to improve. At its worst, this sounds like an opportunity for the team to learn.
You might want to help make sure that any experiment is "survivable", and help the team consider things that you think they may have missed. Survivability might be something like making sure that there is a plan B in case this experiment causes problems, or that the financial risk of this experiment is small enough that it won't result in a catastrophic loss of trust from management. This will depend entirely on your context.
But if the team want to try this, probably the best thing you can do is provide the opportunity for them to make a success of it, and at the end of the experiment respond in accordance with the Scrum Values.
e.g. you might be courageous and acknowledge if your concerns were not valid, you might be respectful in acknowledging their commitment to improvement, and helping them learn from this experiment.
They can not be part of our internal scrum events
This seems like a massive impediment to effective collaboration, as does the lack of transparency about how this partner team works (e.g. not knowing if they have a PO).
It seems like you have to manage an imperfect situation, rather than being able to set up the teams to thrive.
Do you see that there would be value in this other team being allowed to attend the Scrum events? If so, how can you make this transparent to those in a position to change the company policy?
In your view, would it be more effective if both teams were able to share skills, staff and responsibilities, so they could function as one or two cross-functional teams?
I am not sure this might end up in too much communication problems and not being consistent about what we tell the external team.
Indeed it might. That would be the price paid for having a co-ordinator...someone who is effectively trying to compensate for a management policy which inhibits team self-organization, and which seemingly does little to encourage teams to limit their work in progress.
Since there appears to be an integration concern between two teams, why not start by making their various dependencies transparent in the Product Backlog? I'd suggest that two teams then ought to be able to self-manage such things, if they are encouraged to do so by good leadership, and to decide how much work they can responsibly take on.
First of all thanks everyone for the quick response!
you are, as a Scrum Master, pushing back?
Concerning what Daniel Wilhite. said: It was never my idea to stop them from doing that experiment. It is awesome that they try to solve it them selves. If it works out I'd be the first to acknowledge this effort.
I am just trying to have a good Plan B as Simon Mayer mentioned and get some input from outside :).
I like the idea of ensuring this experiment is "survivable" and making them aware of things that they might need to additionally consider.
Do you see that there would be value in this other team being allowed to attend the Scrum events? If so, how can you make this transparent to those in a position to change the company policy?
I see a huge benefit if they would be allowed to our Scrum Events (as well as skills, staff etc.), but I already asked the other Scrum Masters at the company if this is possible and I was told it is not possible due to IP- and, as I said before, old company policy.
why not start by making their various dependencies transparent in the Product Backlog?
I really like this idea Ian. Also because we have a lot of other dependencies to other internal teams and we need to be aware of them and the effects all these dependencies have.
By the way, I'm already trying to improve communication and collaboration between the interdependent teams here.
If you have any additional comments I'd be really happy to hear about them.
Thanks everyone for your replies!
you are, as a Scrum Master, pushing back?
That was never my plan. I love the idea that they want to solve the problem themselves and I'd be the first to acknowledge their success.
All I'm trying is to have this Plan B that Simon Mayer mentioned and also get good feedback from outside and I like his idea of making this good experiment "survivable" and maybe make them aware of some things they did not consider.
Do you see that there would be value in this other team being allowed to attend the Scrum events? If so, how can you make this transparent to those in a position to change the company policy?
This would definitely be a huge benefit for both teams (as well as sharing skills, staff etc.)
I already asked the other scrum masters at the company if this is possible but the answer was not, due to IP- and some old company policy.
why not start by making their various dependencies transparent in the Product Backlog?
I really like this idea Ian. Also because we have a lot of other dependencies to internal teams as well and everybody needs to be aware of the consequences these interdependencies have on the results of the teams.
By the way I am also trying to improve collaboration and communication between all those teams in order to make sure find bugs quicker and have less coordination overhead.
I already asked the other scrum masters at the company if this is possible but the answer was not, due to IP- and some old company policy.
I'm just going to quote one line from the Scrum Guide, and let you decide whether it's worth challenging the status quo.
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
I apologize for misunderstanding your comments. I did not mean to offend.
All of the suggestions that @Simon Mayer and @Ian Mitchell gave are, as usual, fabulous. I see one commonality in them. Transparency. In my opinion you are correct to question the "norms". And one way to help others see the impact of the restrictions is to make the impact as transparent as possible. The more you can do to raise the visibility, the more likely there will be some decisions made to change the ways you work. Working with the other Scrum Masters in the organization would be a good idea if they would be willing to also raise the visibility. You mentioned that the external team also has a Scrum Master. I'd include them in the effort to raise the visibility. You may find that they are having similar issues working with you due to the restrictions.
Another option that I have used somewhat effectively on one occassion was a Scrum of Scrums between the internal and external team. Scrum Master, Product Owner and a representative selected by the Development Teams would discuss coordination concerns every day, preferably before the individual team's Daily Scrums. In this way, the external team will not be participating in any of your internal Scrum Events but there is still a way to coordinate and discuss concerns cross team on a daily basis.