One team, multiple products and the scrum events

My opinion... You can work with several products with these 3 people, prioritizing the demands and acting one at a time with the 3 developers working together, as they will be faster.

That way you can perform the cadences together.

But if you keep it separately, it's better to keep separate events as well, as they are different contexts. Evaluate whether it is more productive to maintain a direct conversation with each developer, instead of scheduling events just to fulfill the process that your company wants.

Start by trying to show your company the concept of a squad in a collaborative way. I hope I helped.

Hugs.

If it's 3 people sitting in their corner of the office doing their thing with their personal product, you don't have a team and the Scrum events indeed don't make very much sense.

So, can everyone work on all products?

Three different developers are therefore working on three, smaller, products. My company wants to see this as 'one team'.

Has the company explained why? If the Developers are working on different products, they will have no reason to integrate their work, and there will be little reason for them to collaborate. Why does the company wish to obfuscate this reality? Or do these products have more in common than might first appear, and which might make integration necessary and teamwork worthwhile?

Scrum state that each product has its own product backlog. Will you be maintaining one product backlog or three for each product? Of course, the latter is what you may end up doing on three distinct and separate products. 

As far as events, looking with Scrum Guide lenses, you'll have three separate sets of events for each developer since really, each developer and you would constitute one scrum team. Having events where all the developers across each of the products participate at the same time, isn't as effective since the purpose of the events is to collaborate on the one product as it relates to the Product Backlog and Sprint. For example, having a retrospective will do little for two of the three developers that did not work on that Sprint. The same can be said for Sprint Planning, Sprint Review, etc. Not sure if there is a Professional Scrum Master at your company that can help them better understand Scrum and agility.

You need to ask or think about more questions before making it one team and having same evenys for all 3 developers

1. What is The purpose of making one team: Are they making all three understand each other products so that anyone can work on any of the product and remove dependency on one person?

   1.1 If no, then there is no requirement of any common events or may be just a retrospective meeting if there are common pain points

  1.2 If yes, then start with sprint grooming but make stakeholders understand that this would hit velocity during initial sprints as all 3 of them have to be involved in grooming of each product.

Hi all,

Thanks for all the helpful answers! The reason for the three people to ideally act as one team, falls back on the fact that the products are developed in the same programming language. Therefore, the company would like to see the developers being able to change products once one of them deserves more priority. For example: Developer 2 now works purely on product 2, but when product 1 has an urgent matter, it would be really helpful if developer 2 could help developer 1 on product 1. 

Hope this gives more clarity on why the company would like to see it as 'one team'. 

How are those priorities determined, and by whom? If "products" must be prioritized in relation to each other, do you then have one Product Backlog within which all of that work is ordered? 

Just because they all know the same programming language doesn't mean that they could work on different code bases.  That is similar to saying that an American Baseball Player knows how to swing a bat and hit a ball so they should be successful at Cricket. 

And as @Ian pointed out it will require that priorities be set across 3 products.  Because if Developer 1 needs to work on Product 3, there will be no work done on Product 1.  

As you stated in your original post, there is nothing "scrum-like" about any of this.  This is an attempt by an organization to use some Scrum terms so that they can say they are "Agile".  There is honestly no great way to provide Scrum advice for this unless the organization is willing to make some significant changes.  I am not even sure I can see a benefit of using Scrum in a situation like you have described. The events are overkill when there is only a single Product Owner and a single Developer per Product. 

My suggestion is to have a discussion with the 3 Developers and ask them if they have any ideas on how to make it possible so that they can back up and help each other when needed. After all, they will be the ones that have the hardest part in this. They should be involved in the solution.