Temporary working as a part of existing scrum team

Question

My situation is as follows:

• Working for a company which is opening new office in my country
• Since the plan is to have 10 full scrum teams, at the moment all teams in the new office are partially populated
• Until all positions are filled my team is working as part of an existing team which is in the original office

What are the problems I see:

• The existing team is well organized, working together for several years which makes it difficult from my point of view to feel as part of them. We all know that this is temporary and at the end there will be 2 teams working independently.
• Coming from a company where the Scrum principles where highly valued, even though I'm a developer I have strong opinion on how the things should be done and I have problems accepting some of the concepts of the team that I'm attached to
• Having the two above in mind, I don't feel comfortable taking tasks which at the end is something that I get paid for and should resolve somehow

For what I need suggestions/answers:

• The first thing that really made me feel uncomfortable is that since the communication is not that good (actually pretty bad, because of technical issues) between the two offices, my team is not active in the refinement and planning sessions. As a result I don't feel that I have clear scope for anything, thus I don't feel comfortable to be proactive in asking for certain story/task and as it seems the other team also prefers in some way just to do our work as developers instead of spending additional time to explain us things that are a lot more clear for them and most probably the time that they have to invest in implementing a task is a lot shorter than the time that they should spend with us to explain something. Also, being developer too I can understand why they act like this so I can't really judge them. However not taking real work is starting to get a problem (at least for me personally) so I feel a compromise should be made I just don't know exactly where. As I said, not being part of the refinement meetings later on makes me uncomfortable to take something that at the moment I don't have clear scope of. However on solution is just to set this aside for the moment and just take something hoping that during the sprint the task will get clear enough for me to implement it. I think that this would be the most preferable choice for everyone but somehow I really feel uncomfortable doing this. As alternative solutions to this I see to take only bugs and technical depts until my team here is filled and we can start working on our own, but the problem here is that it's pretty unclear when this will happen.
• Being able to identify that the lack of understanding the scope of the stories is what makes me feel more uncomfortable in committing to tasks I've been thinking about additional sessions between the guys from the new office only and the Product Owner (the idea here is that when the number of people is lower the communication problems could be overcome) and refine several stories specifically for our team. Maybe even PO + 1 developer from the original team, but just keeping the number of people as low as possible in order to avoid the technical issues.

So the three approaches that I'm considering right now is:

1. Forget about the refinement, just commit to some story/ies and hope for the best.
2. Make it clear to anyone that at the moment working on stories is not an option and insist on taking only bugs/technical dept until the team here is ready.
3. Try to involve the PO and maybe one of the developers from the other team in additional refinement sessions where only tasks for our team will be discussed

What do you think about this, and do you think there is other solution different from the 3 that I've listed above?

Answer 1

TLDR: Sit the team together.

I have strong opinion on how the things should be done and I have problems accepting some of the concepts of the team that I'm attached to

Normally, my advice for this would be as follows: Bring it up in the retrospective. Keep in mind that Scrum is Agile and thus intended to fit to the needs of the business - how company A does Scrum can and should be different from how company B does things. That being said, it's still possible that the way company A's doing things might actually be better for company B than what B is currently doing. Hence, retrospective. However.

communication is not that good (actually pretty bad, because of technical issues) between the two offices, my team is not active in the refinement and planning sessions.

This. Is bad. I would say that this here is your core issue. Your team is not only not sat together, but has poor communication and doesn't even fully attend all meetings. At that point, it's difficult to even consider your group as being part of the team at all.

What I would suggest here is one of two options. First, move in with the other team, even if only temporarily (until you become your own team). This is the most straightforward solution, and should fix most problems.

If that is impossible, then instead consider splintering off into your own team now. Do you have at least three developers? If not, hire some - maybe even siphoning one from the other team if necessary. Do you have a Scrum Master? If not, hire one - or, if you can't do that, appoint one of the developers. Do you have a Product Owner? If not, hire one. If you can't do that, get the PO of the other team to split his/her time between the two teams.

Some of these solutions are more viable than others, but I believe all of them are better than having a team that's as fragmented as you describe.

Now, I'll address your suggested solutions:

1. Forget about the refinement, just commit to some story/ies and hope for the best.

This is pretty dangerous. Worst-case, what you complete, while not understanding a story, is accepted due to poor QA and the assumption that you did understand the story. And then you have something in production that might look like it works as intended, but doesn't. More likely case, you'll just waste your own time and the time of those who have to clean up after you as you clumsily attempt to do work that you don't understand.

2. Make it clear to anyone that at the moment working on stories is not an option and insist on taking only bugs/technical dept until the team here is ready.

Why are these any different than stories? Are they somehow better defined? Are they considered less important? (Hint: they're not) I can't evaluate this completely without knowing your exact situation, but this seems to me to be similar to situations where junior/incompetent developers (not that I am calling you such, but without proper requirements your output will be comparable) are assigned all the bugs instead of 'important work'. Which works about as well as you'd expect a system where all bugfixes are made by novices would work.

3. Try to involve the PO and maybe one of the developers from the other team in additional refinement sessions where only tasks for our team will be discussed

This might work, though it seems less than optimally efficient. You're still going to have communication problems. What if your team finds a problem? Then those PO+1dev need to report back. And then one on the other team misunderstands. And then the PO+1dev need to go back and tell you you were wrong. At which point you spend an hour arguing before realizing there was a misunderstanding, at which point...

Suffice it to say, sit the team together. If you can't do that, make two teams and then sit each team together, separately.