Product owner is not a commette? but it is!
The vision of the project I'm working on is to build an "orchestration platform".
It means that will orchestrate different existing applications.
I should be the "technical" product owner of the platform. However:
1. each existing platform has its own product owner
2. my business knowledge is limited, I'm no domain expert, I have to rely heavily on people with business knowledge to understand business requirements and user stories.
3. my technology knowledge is also limited either because obsolete, either because different from what I know. I need to rely heavily on technical leaders to understand stories and tasks.
4. the "team" working on the orchestration platform is often borrowed from other applications and working part-time on the orchestration.
5. the teams working on other applications use scrum and/or kanban, with different sprint timelines, cerimonies and structures.
I think I could bring some experience in the process of building a product, prioritize features and story mapping, however, it's clear to me that each product has its own priorities and its own product owner.
I'm trying to organize a "team" of product owners, to align processes and methodology.
I'm trying to participate in all dailies, even if it's a bit time-consuming. Even more for developers that have to attend 2-3 daily meetings per day.
I gave up actually organizing daily for my core team, as it's embedded in other dailies.
I find all this a bit challenging and confusing.
It's not easy to organize "scrum of scrum" between selected people as it seems that everybody wants to know information first-hand, we are spending time in endless meetings.
Any suggestion is welcome. I read a lot of things about "fluid teams", feature teams, etc, but it seems all very abstract compared to my real situation
Sounds like you need a time boxed structure. Each meeting should not take more 15 mins and stick to the 3 pillars of scrum. Anything outside of that should be handled offline for a detailed discussion.
I'm trying to organize a "team" of product owners, to align processes and methodology.
Why not start with products first? How many are there, and who would be best positioned to account for value?
Ab, did I get you right, the various products are somehow your clients? So, especially the various Product Owners are your stakeholders? Or are you thought to be a kind of Program Manager for the various platform products?
My alarm bells rang when I read "technical Product Owner". Are you empowered to decide what's valuable in the scope of your product and what is less valuable?
Wrt your limited business knowledge: you might learn from the other Product Owners. This would also help to get in close contact with these people - and I think you definitely need close contact to them.
Wrt your limited technology knowledge: you might learn from the developers what is necessary.
Working part time on a product doesn't make it easier. Teams should be self-organizing. Might be a good idea to discuss with the Scrum Master and the whole Scrum "Team" if they see this as an impediment and how to tackle it. A question might be: "How to evolve from a 'team' to a Team?"
Different approaches for teams of different products, IMHO, are no problem per se: this shows that the teams have reached a certain level of self-organization and adapt the way they think is best to their individual situation.
Please consider this reply a first "increment" in order to get feedback and plan the next answering Sprint :)
My alarm bells rang when I read "technical Product Owner". Are you empowered to decide what's valuable in the scope of your product and what is less valuable?
Well, I'm trying to decide a role for myself actually. Let's say I'm empowered to deliver a fuzzy idea of MVP for a certain deadline. I'm struggling to define my role, because people don't understand where I can add value: I don't understand business enough, nor technology enough. I probably understand what a product is and how to create one in general, but teams feel probably they can do without me. Nobody labeled me as Scrum Master, because I've never been a Scrum Master myself and I wouldn't feel comfortable calling myself SM, even if I'm actually trying to address organizational issues and procedures across the different teams.
What makes the MVP is open for discussion, I'm not the person in charge of it, several stakeholders are, but I can negotiate with different parties what to include and what not, in order to satisfy the general deadline.
Since the deadline implies also developers and resources allocated by each project manager, I need also to negotiate with them.
I don't have a Scrum Master with me alone. Each team has (or does not) its own Scrum Master.
So it would be a discussion between Scrum Master and Project managers.
Also, I don't really have a sprint, but I participate in 3-4 sprints, not all of them have retrospectives.
It's a bit overwhelming and scary for me right now.