Scrum for a project with multiple squad on a multiple modules Product
Hi all.
My team is developing a social platform like Facebook, I am playing role manager and I want to apply Scrum to my project, I just passed PSM I.
My project has about 50 members, grouped by Squad, each Squad handle one or many modules of an application - a Social Platform, such as User squad - handle user and authentication modules, Content Squad handle content module for content managing features. Group Squad handle group managing feature. Each squad has Squad Lead to manage the squad. Each squad has one PO one Production Backlog. Sometime there are features cross squad so squad sometime must collaborate together.
Now I want to apply Scrum to my project, I wonder how can we make this big change.
In fact, although it's required in Scrum, but combining squads' product backlog into only one is big challenge for us. One PO cannot handle a huge number items of multiple modules and he/she also doesn't have enough domain knowledge to handle the items. I also wonder how other POs are after we choose one of them to become only one PO of whole production.
I hope my English is good enough to help you understand my concern.
I look forward any advices, how I can resolve this problem.
Thanks so much.
Right now you seem to have many feature-oriented modules, each one of which is a value stream in its own right, with a backlog and a Product Owner.
What problem would actually be solved by combining everything into a single product? On the whole it is usually best to go the other way and try to descale the challenge.
For your question "What problem would actually be solved by combining everything into a single product?"
In fact, I think that combining everything into a single product is impossible, it will make a mesh for my project, and many people will disagree.
The thing I concern come from Scrum Guide "If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner."
I understand that our application has many feature-oriented modules but is one product, if we follow Scrum, we should follow this rule, no customization, right?
Is there any butter approach?
In fact, although it's required in Scrum, but combining squads' product backlog into only one is big challenge for us.
Not sure where you found that this would be required. The Scrum Guide states that there should be one product backlog per product. It also states that each team should work on a single product. It provides a description of what a "product" is for the purposes of the guide but many people overlook it. Here is the definition. It can be found in the section of the Scrum Guide that defines the Product Backlog. (https://scrumguides.org/scrum-guide.html#product-backlog)
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
From the description you provided, it seems that your organization is already aligned on the boundaries described in that statement. So, I do not see any reason that you would need to make any changes to this.
Is there something else that you feel is preventing the organization from using the Scrum framework that you did not mention?
Each squad has one PO one Production Backlog
This statement could be an antipattern as Scrum says there should be one PO for the product, and it is advisable to have one PO for the product. Each team can have a PO (if there is a domain knowledge issue) but there should be one PO (or call him a Product manager or whatever) who will set product level priorities. Team level PO's might tend to focus on team priorities rather than the whole picture and hence someone is needed who can get all onto the same page. Let the team PO's and product PO's connect and set priorities for individual teams.
Also it is important in your case to have some cross team planning and meetings so that all are clear and on the same page with respect to product priorities (you should look at some scaling frameworks and implement what best suits your case).
Have a close eye on the below:
- Dependency management (have a Scrum of scrum kind of meeting where leads from the different teams connect to solve dependencies / unblock each other etc.)
- Integration of work done by the teams - how often should you integrate to show progress (how the work done by different teams combine and add to the product)
- Risk and delays - you may see some slippages in your plans due to unforeseen delays hence tracking this (if you have timeline set for completion) is critical.