4 products, 9 developers, 1 team.

Given your current set-up, how is a coherent Sprint Goal being agreed during Sprint Planning?

Your new PO is willing to manage 4 separate products within their backlog.   Definitely not ideal, but good that the Development Team is only working with one PO, and not fielding requests from 4 separate input streams.

Ian brings up a very valid observation - how is your Scrum Team identifying Sprint Goals?

Now that the PO has prioritized the work, the Development Team should no longer be "cherry-picking" items; instead, they should be working strictly from what the PO is identifying as most critical.

Unsure why the Development Team is concerned about Scrum vs. Kanban - have they looked at the hybrid Scrumban approach yet?

but due to the managing software, I'm trying to push scrum

Be careful with this, and keep in mind the Agile Manifesto: Individuals and Interactions over Processes and Tools.

My thoughts:

"The company has decided to make the declaration that we will be agile and we have been given software to facilitate scrum." Merely stating that one _will be_ agile means nothing if they don't understand the benefits (I've seen it again and again - we need to become agile, but then...). Software to facilitate scrum doesn't mean much. In one of my first Scrum roles, we were using just a whiteboard and postit notes.

"My team has 4 applications that have nothing to do with each other." You'd need 4 different backlogs to keep things clear, organized and transparent not just for the team, but for everyone (especially stakeholders).

"We recently got a new product owner who has been getting our backlog up to speed but we have been cherry picking items from the backlog during planning. Developers pretty much have been picking what they are going to work on as individuals vs. a development team jumping on the priority work." It is up to the PO to prioritize the backlogs (4, as I mentioned above, and I'd question their ability to own 4 different applications that, as you said, have nothing to to with each other) and negotiate with the development team what can be worked on, with the ultimate end of formulating achievable sprint goals.

"Since our backlog has been prioritized, we're ready to use the prioritized items to bring in to the sprint (we are treating the 4 applications as 1 product backlog and the PO is determining priority across products)". Good stuff, but I don't recommend using the same backlog for 2 or more products.

"We can't seem to define ourselves. Half of us say we should hit scrum head on while others argue we're kanban." That's your first (and most critical) issue to solve. Kanban is better suited for product maintenance, Scrum has other benefits. None is perfect. Once you choose one (vote if you have to), give it a go for a while, the inspect whether it's working fine and you should continue. Switch as needed. 

"We have several user stories that always end up in a state of waiting for feedback" From whom? Do your stories satisfy INVEST? Have they been properly drafted, with clear acceptance criteria? Are you maybe using TDD? What's your definition of done? Is the team aware they should only select stories that can be done within a single sprint?

"Others are delivered in an on demand fashion. We're about 75% scrum 25% kanban" I'm afraid you're not :) You're either 100% or you aren't. What you are is a basically transition to an agile way of working. A hybrid that you're trying to improve in order to fix a set of problems.

"What's the best way to manage this in a scrum format?" As long as the team isn't convinced Scrum is the best approach and you don't have a proficient coach, you'll have to decide, as a team, whether Scrum should be used. If you chose it, it should be slowly and gradually implemented per the rules set forth in the Scrum Guide.

We can't seem to define ourselves. Half of us say we should hit scrum head on while others argue we're kanban.

Why does it matter? Is your current process working or not? If not, find a way to address the problems. Never mind the name.

"My team has 4 applications that have nothing to do with each other." You'd need 4 different backlogs to keep things clear, organized and transparent not just for the team, but for everyone (especially stakeholders).

Eugene, I vehemently disagree with that statement. Having multiple backlogs impedes the teams ability to self-organise. Priorities are unclear, as is the approach to backlog refinement. I've seen teams ignore a second backlog more or less completely, unless the items were very much pushed into a sprint by the PO. I also disagree with your assessment that having four backlogs makes things more transparent for stakeholders. How will they know what the team will be working on next, if the team could pull from any of four backlogs? A situation with four products being handled by one team is already less than ideal. But I don't think four separate backlogs are the way to address this, unless there is a realistic chance that three of those will be taken over by another team very soon.

"We can't seem to define ourselves. Half of us say we should hit scrum head on while others argue we're kanban." That's your first (and most critical) issue to solve.

Again, I disagree. I'd say that putting a label on the process is a very low-priority issue. While it certainly would increase transparency to clearly communicate which framework is being used, I'd argue that since there is already a process in place, a better option might be to refine that process and see what you end up with. Maybe you arrive at a Kanban process, or a Scrum process or Scrumban or some as-yet-unheard-of agile thingamajig. But putting a label on the current process isn't going to help anyone as it's clearly a hybrid of some sort.

Now, there might be a benefit to agreeing on an approach (Scrum or Kanban) and then working on refactoring the current process to fit the agreed-upon framework. But to me, it doesn't sound like any sort of consensus is forthcoming right now (that's an assumption, I may be wrong). So in this case, I'd advise to work with whatever process is in place and improving it. If you run into problems Scrum or Kanban can solve, use the tools from those frameworks. Pushing for Scrum will only lead to resistence - I have first-hand experience on that.

"Eugene, I vehemently disagree with that statement." That's alright, Julian. We all have different experiences behind us, and through discussions we express what we believe (or we think) is best under some circumstances. I wouldn't go as far as say I vehemently disagree with your statement though :P

"Having multiple backlogs impedes the teams ability to self-organise. Priorities are unclear, as is the approach to backlog refinement. I've seen teams ignore a second backlog more or less completely, unless the items were very much pushed into a sprint by the PO." For clarity, organizational and lots of other reasons, most people keep dishes separate to shoes, shoes separate to watches, and spoons, knives and forks next to each other. If you have (as the OP mentioned), 4 completely different applications, it is unwise, based on my experience and research, to keep it all on the same backlog. That is on the assumption they are indeed completely different. Priorities change, people move from a role to another, or leave the company, management changes direction, may hire new people, outsource work, etc. While I don't recall seeing any Scrum literature expressly prohibiting using the same backlog for two or more products, it is certainly possible. Though, again, I repeat, in my experience and per my knowledge, that isn't feasible given the mixture.

If you've seen teams ignore a second backlog more or less completely that raises concerns in terms of commitment and focus. And why would the PO push for the items into a sprint? Something tells me the PO and development team didn't fully understand how it's actually supposed to work.

"I also disagree with your assessment that having four backlogs makes things more transparent for stakeholders. How will they know what the team will be working on next, if the team could pull from any of four backlogs?" If you really have 4 different products, you will have scores of stakeholders, each chasing their own interests. Let me reverse the flow. Since there aren't 4 self organizing, cross functional teams, with 4 dedicated POs, and independent backlogs, how would the top of the backlog look? What transparency would it show? How would backlog management be performed? Would stakeholders for product A understand the backlog when A is mixed with B, C and D? 

"Again, I disagree. I'd say that putting a label on the process is a very low-priority issue. While it certainly would increase transparency to clearly communicate which framework is being used, I'd argue that since there is already a process in place, a better option might be to refine that process and see what you end up with." During the past three decades (and maybe more) people have been thinking how to improve software development. There are plenty setups that people have validated, over the years, through empiricism. When and where needed, they sought improvements or changes (hacking the "system"). Why waste time trying to find a new process when said time can be invested in accommodating themselves with a certain methodology, commit to it, then inspect (and change to another one, if needed)?

In my view, refining the process won't take you too far - where does one hope to get? Inventing a new framework or methodology? There are already multiple ways of working, choose one, try it. If it works, continue and improve, if not, choose something else. As I said, there's no perfection. Scrum itself has many areas that can be improved.

While I don't recall seeing any Scrum literature expressly prohibiting using the same backlog for two or more products, it is certainly possible. Though, again, I repeat, in my experience and per my knowledge, that isn't feasible given the mixture.

I agree it's not an ideal setup either. But given my experience I would opt for the single backlog over multiple backlogs. I do see and understand your points about stakeholders, though. From that perspective, multiple backlogs may have their advantages as well. Then again, it will require a lot of transparent communication between the PO and the stakeholders to communicate why (for example) PBIs from one backlog weren't pulled into a sprint as opposed to PBIs from other backlogs given that priorities between those PBIs are not clearly visible as they would be on a single backlog.

During the past three decades (and maybe more) people have been thinking how to improve software development. There are plenty setups that people have validated, over the years, through empiricism.

I agree. And I am all for making use of them. However, it has been my experience that if the development is already underway and some sort of more-or-less agile process is already in place there often is no consensus from throwing away what is in place and starting with a new framework. When you try to push those things, you will most certainly encounter serious opposition. Whether someone can overcome that resistance depends on a lot of factors (executive sponsorship, situation of the team and the product development, ...). It has been my experience that a lot less opposition is encountered when starting with what the team has and improving that. If the team isn't doing Scrum, but is meeting the problems that Scrum is adressing, it's a good idea to adopt a Scrum practice. That way, a team can adopt Scrum (or Kanban for that matter) bit by bit. In my eyes that is better than pushing people to use Scrum (which they may only use reluctantly). I know there are other view points on this matter.