Scrum of scrums: Competencies and soft skills of the team

None of this sounds much like Scrum to me. You haven't mentioned products even once, or using Sprints to validate any assumptions about what value is. Instead, you've got projects and managers and possibly a matrix. Anything to do with Scrum has apparently been reduced to "liturgies", which paints an intriguing picture.

Who actually wants Scrum in the situation you describe, as opposed to ritualized sacraments, and what outcomes are they hoping to achieve from its implementation?

Thank you very much for your comment Ian.

It is a more complex context, which is why I called it Scrums of Scrums. There is no single team, no single product.

In this company there are 9 units of approximately 60 people. Within each unit they are subdivided into teams of 15 people, which in turn are usually subdivided into 2 (to comply with the maximum recommended for working with Scrum). And these in turn are teams working on different products from different customers, but they have common ground so it is useful that they act as a single team and can help and learn from each other. So we have scrum with the customer, scrum with the small team, and then also at the unit level. This is a very brief summary of the working methodology, as you will understand it is a bit more complex.

Scrum is used because in addition to the events or liturgies, the values and principles of this framework are followed, the artefacts are used, etc. 

There is no project manager role as such, the team is responsible for the product delivered to the client. But as you will understand, there are other engineering manager roles that are responsible for other functions once the company is negotiating new clients or making offers. The members of the team are the ones who are going to define the offer for the client and manage it with the client in all its phases, but initially a decision has to be taken as to which members are going to belong to this new team, and this has to take into account availabilities but also the preferences of the team members or expertise in order to include different profiles that can complement each other.

The context I wanted to give is that there are so many people involved and that, although we are all versatile, autonomous and multidisciplinary, it is difficult to have this information collected in a document, whether it is the knowledge matrix, an Excel, a table,.... And that I would like to know about tools, methods,... Any suggestions you have regarding the importance of having that vision of how the team is, the strengths, the weaknesses, the concerns,... And that it is an approach of something maintainable, that can grow and be modified without having a strong impact on the teams. This is also useful for the members of the sub-teams because you can have a bigger vision of what is outside your own team, if you need help from someone or if you are interested in learning something.

Scrum usually has long running teams of individuals that have all the skills necessary to do the work to improve a single product.  The only time that I have ever encountered the kind of matrix you are referring was in the 1990s when I worked as a software consultant.  That kind of matrix existed for many of the reasons you are mentioning.  However, as you have found, that matrix was never kept up to date unless there was a single person responsible for doing so.  That individual had to constantly interact with the matrixed individuals, asking if they had any new skills or change in preferences. Even with that level of attention the matrix was not always accurate. 

I wish you luck in finding a way to keep it accurate.  I also want you to realize that there is nothing about what you described that is Scrum like.  Using some of the terms, working in timeboxed intervals, honoring the values and principles does not mean you are using the Scrum framework. I don't think you will get many responses in this forum because most of the people that do respond to posts here will not be exposed to your type of scenario. I could be wrong and I hope I am so that you can get some kind of answer. 

I think we have gone off-topic and are debating something for which you have no context or information other than the brushstrokes I have given you. I don't want to pursue the issue further because otherwise the focus will be lost, and I won't get an answer to what I need or care about.

As you have said, and as I have said, the matrix solution seems archaic to me. That's why I started to investigate what other possibilities there were. Wearing in mind that the team is made up of people: they change (not only the product), and it seems interesting to me that we should also iterate on them, and improve the processes and be able to cover the needs of the business as well as the personal needs and those of the teams. It is all very easy to say that in scrum, for example, everyone should know about everything, but the reality is that not all members of a team are the same, nor do we have the same concerns. My question is, how could this be addressed? How could these needs of the teams be detected, if they are covered by others who could give training, if we have to look for something external? Deciding the members of the teams, because it is clear that the products are for the medium term, but that also changes, people enter and leave the teams for various reasons, and you have to act, and know what is needed and what is best for the team.

I was trying to look for information on the internet, beyond the knowledge matrix, and not finding newer information or adapted to agile environments I decided to put it on this blog, because I thought that someone had had a similar experience or that here I could find some help or guidance. But as I have already said I think that the topic is being focused in the wrong debate, and I will have "to look for my life elsewhere". Thank you very much