Early Stage Startup vs Scaling Scrum (after 7 weeks)

My advice is to get Scrum working with just one team first, before you even think about scaling.

That doesn't seem to be happening yet, given that you are still reflecting on:

• how you manage a team, rather than on how it will become self-managing
• "ceremonies" of some kind which are observed, rather than on the Scrum events which promote inspection and adaptation.

The key is to establish empirical process control with just one team first, identifying and removing the systemic organizational constraints that impede its progress. Failure to do so will result in the scaling of organizational dysfunctions along with various contra-indications to innovation and agile practice.

Thanks for your answer, Ian!

Sounds like the advice of an experienced scrum master.

I understand that it should be 1 team per X clients all the time, until we catch the basics of the framework.

In fact, we are currently focusing on the ceremony wondering how it should go, rather than supporting the inspection and adaptation ... that's right.

Maybe we don't fully understand the concept of "self-managing", but we try to take care of our duties as sm / po / devs and deliver increments together.

I understand that it should be 1 team per X clients all the time, 

Actually is should be one team per Product.  There is no concept of a Client Backlog.  It is a Product Backlog.  One team working on a single product can support many clients as many clients can use a single product.

I suggest that you read the Scrum Guide.  Pay attention to what it says about the focus on products and not clients.  Pay attention that there are Events and Artifacts and not ceremonies.  Pay attention to all of the opportunities for inspection and adaptation.  

There is a lot more to Scrum than using the terms Sprint, Product Owner, Scrum Master, Backlog.  In fact, many companies that use those terms are not utilizing the Scrum framework or using the terms to refer to what is described in the Scrum framework.  They are doing Scrumbut (We do Scrum but we this differently because ...). 

As @Ian suggested, don't even think about scaling Scrum until you have mastered it on a team by team basis. I have not worked in a company that had scaled Scrum.  Those companies had between 6-12 Scrum teams.  But there was no need to scale because each team worked on individual Products and no product had more than 1 team. 

I very much appreciate being able to talk to you gentlemen! 🙏

Thank you, Daniel, for your comment!

 Those companies had between 6-12 Scrum teams.  But there was no need to scale because each team worked on individual Products and no product had more than 1 team. 

It's so basic, and you've brightened my knowledge so much! 🤯

Scalable scrum models are used towards working on 1 product. 

In our case, we actually focus on several products. 

That's why it hits me so much to say to create a few individual scrum teams working on a few products first.  

With each day and new knowledge, I understand why implementing scrumbut is so easy, but iteratively implementing 1:1 scrum so difficult at the same time, it's beautiful. 

There are challenges in my mind regarding multiplicity of customers, 8 vs 8 developers.

In this case it's hard to have 1 developer per 1 scrum team, plus the PO/SM role is focused on 8 scrum teams.

This is probably not an effective way to solve the problem. 

a) Increase the number of developers, for which there is currently no space (bootstrapping).

b) Reduce the number of customers by focusing all the manpower on achieving product goals faster and more efficiently.

c) Maybe scrum is not the best form of framework at the moment.

The main objective in Nexus is to manage dependencies. The easiest way to remove dependencies is to have only 1 team at a time work on a certain product.