Team setup, sprint goals and disturbances

I work as a PO for two products that are handled by the same team.

I get my road map items from a Product lead that are responsible for several products and it's that person that communicates with our real customers. This person can in the middle of a sprint request high level estimates for new roadmap issues. The issue can be small or very big and require investigation which messes up the sprint.

It sounds like you aren't a Product Owner. It sounds like you are not accountable for the value of the product, nor do you have a lot of freedom to order the Product Backlog. It also sounds like this "Product Lead" is far enough removed from the team that they don't necessarily understand the impact of their requests on the team or how to take advantage of aspects in Scrum like the Sprint Review and ongoing refinement to adapt the Product Backlog.

Internally we have specific customer teams that are responsible for adding customer specific features and verifying that everything works for that specific customer before that customer gets a new release. These teams can ask questions (support) that might take time to answer. They sometime require bug fixes asap also. This messes up the sprint. Some of these teams also works waterfall although claim to work scrum just by having the sprints and ceremonies but they have a set date and a complete scope that is not allowed to change.

This seems very strange to me. It's not clear if these "specific customer teams" are doing design and development or configuration. If they are doing product design and development, then it seems like not only are they Developers, but they don't have all of the skills necessary to do their work if they need to interrupt other teams with ad-hoc requests so frequently.

I have seen similar situations where the product is really a platform and these teams are available "for hire" as services to customers who want the platform extended but don't have the internal technical resources. They can also build custom integrations between a platform product and customer tools. In this case, I'd say that the fact that they are finding and requiring immediate bug fixes is a sign of quality problems within the platform development teams. If there are missing features, there could also be disconnects between what the end customers and users expect and what the product actually is, which could be related to the layers of product management that exist.

The dev. team I work with consists of two frontend devs, three backend devs, one architect and two QAs (one of the QAs is also SM). The frontend devs only know product A and two backend devs knows product A and B, one backend dev only knows product A and the architect is quite new and only knows product A also. When we have refinements it's a recurring thing that the team is very silent. During retros they then often complain about lack of information. In our planning méetings they're also quiet so it's basically me and the SM that plan eveeything.

There are a few problems here. From this description, I don't see a cohesive team. I see individuals who have their own skills and work in silos. There's no cross-functionality or ownership of the product and the associated work. The lack of involvement in planning is also a sign of the team not being self-organizing. What is being done to make sure that people are trained, not only on the different products, but also to work in other aspects? Just because they are a "frontend dev" doesn't mean that they can only work in the frontend, if there's a lot of backend or QA work to happen. People need to work collaboratively.

1) How do I (help) plan a sprint when it's so dependant on which developer that can work with frontend/backend for my two products?

Cross-train the developers. The frontend devs should teach the backend devs enough about frontend development to be able to be effective. The backend devs should train the frontend devs on backend development. The QAs should be teaching everyone how to think like a tester when decomposing, designing, and developing work. The architect should be teaching everyone good architecture and design practices. People should be training across product boundaries, as well.

2) How do I get rid of things disturbing the sprint such as estimates, support questions that are sometimes not critical at all? Do I plan it in the sprint? Do I assign a specific person to work with it in a separate board so it doesn't affect the sprint?

Use the Product Backlog. When work comes in, order it into the Product Backlog. If it's high enough, it'll come up for refinement and development sooner. If it's not important, it'll wait a while. Minimize the time that the team is interrupted. Don't forget the refinement should be an ongoing process, so the team should be looking and making sure that whatever is at the top of the Product Backlog is being moved closer to being ready for an upcoming Sprint. The exact mechanics of how to do refinement depend on the team, but pushing work to people is rarely the answer for getting things done effectively.

3) How can I get the team to become more involved so they take more responsibility and not expect to be "served" a solution that they are suppose to implement? 

The first step would be to figure out why they are not involved. It can be a change, if they are used to being told what to do and how to do it. Shifting to a self-organizing, self-managing team is a cultural change. Understanding why may help figure out next steps. Even if the team wants to, there may be gaps in skills and knowledge that need to be filled before the team is capable of coming up with good solutions on their own.

4) How do I get stakeholders to stop expecting an end date for big features that are not possible to give a specific end date for? All I get from everyone today is that it must be possible to give proper estimations so the customers know when they can get a new feature.

The stakeholders need to be educated. The best way would be to explain how the process works. When they come with a big feature, the Developers need to decompose it into smaller pieces and those pieces will be ordered with all of the other work. Feedback will drive changes to the work as well. The problem with a big feature is that it's not clear if what is envisioned is complete or correct - there could be more or less work. The feedback loops help everyone understand what is done, what remains, and make sure the team is on track. Having a regular cadence for the delivery of something that is minimally demonstrable is key to building trust with the stakeholders.

I work as a PO for two products that are handled by the same team.

OK. Let's focus on your own accountabilities as Product Owner first.

I get my road map items from a Product lead that are responsible for several products and it's that person that communicates with our real customers. 

Have you decided to delegate some of your responsibilities in this way -- where someone else is held to be a "product lead" for example -- bearing in mind that you are accountable for the outcomes?

You go on to describe problems with interruptions then interfering with Sprint commitments. So, are you satisfied with the arrangement you describe and that this is the best way to optimize product value?

If you aren't happy with these arrangements, is anything stopping you from changing them?

Thanks for all the great feedback. 

To start with the arrangement with the product lead is not my idea. The company has been setup like that for several years now probably since it was decided that we should switch to scrum and they changed department setup. 

When I started as PO I took over from someone who knew nothing about our products which disn't work and as a QA people thought that I would be a good fit so I was sent to a course in product ownership. And the interesting part here is that the product leads have not taken any educations at all.

When I started as PO I still worked as QA also and not that much changed because we already ran a smooth operation. The only difference was that I cleaned up the backlog and got things in order there. We were an awesome selfsufficient team with a really dedicated SM that made things happen and was always trying to get us to try new ways of doing things. Then management came up with new ideas...

It was decided to take in consultants working from another country to make things cheaper. This caused my team to implode in about 1 year since everyone disliked the idea. Most people here prefer to sit in an office with their coworkers and also speak the native language.

The consultants, however good hey are, doesn't seem to have taken any interest in scrum. They just do what they're told which has changed the team dramatically.

Nowadays I only work as PO and I try to start discussions with the other POs and management regarding the way we work and I get absolutely nothing back. I'm starting to think that the others have no interest in scrum whatsoever and management just goes on with what the customers want which is set dates for when features are supposed to be delivered. I've tried talking to my manager, suggested that he should read certain articles regarding scrum and that they should get a mentor for scrum that should work with the teams for a while but nothing happens. I feel like an old fashion proj.lead where my job is to update different excel sheets with estimates and just nag my team for estimates when things will be done which is a completely brainless job. And of course I'm accountable for all the deadlines we're missing but no one is accountable for throwing extra work as support, bug fixes, other changes at us because "it just needs to be done" without affecting our plans. I'm totally frustrated and really don't know how to make things move in another direction. I'm probably considered the troublesome PO since I'm the only one having objections regarding how we all work.

Try a different message. Given that you aren't a Product Owner, or allowed to be one, you are by definition failing to be accountable. Perhaps your message ought to be: please help me to succeed.