Best way to scale Scrum for 4 teams

How many products are there in the situation you describe, and how is empirical feedback on each Increment obtained?

" I went through SAFe, Less, Spotify Model, Scrum@Scale and Nexus, but it still doesn't reconcile in my head. What would be the ideal process given such pre-conditions?"

Basically you tried all what is known. Why don't you try to create a scaling model of your own? Or lets try it together, here at scrum.org

Best first step is always VISUALISATION

Create a map of your current teams and product with value flow.

It might actually give you some idea already.

If you want us to participate, share the map here....

When thinking about Ian's question about how many products and how empirical feedback is obtained, it may help to reference this simple definition of product from the Scrum Guide: 

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.

Understanding where and what the boundaries are and who the stakeholders and customers are could be a good place to start. This also feeds into the suggestion from Nicholas in terms of mapping out your product(s) and value streams.

As an example, if you determine it is one product, with one Product Owner, and you have multiple Scrum Teams working on elements of that one product and need focus on dependency and integration management, and want a lightweight framework to sit on top of and compliment Scrum, Nexus could be explored further (or perhaps LeSS).



If it is multiple products, perhaps it is less about scaling and more about alignment or release management. Each individual product team may be able to leverage Scrum without scaling. As per your example, if one team is building reusable functionality, the other consuming teams may be like stakeholders or users who benefit from reusing that functionality. Those teams would be amongst those providing empirical feedback to the supplying product team.

"There are multiple BAs supplying requirements for work to team POs." and "Handover of work from BAs to POs" statements have me wondering if existing teams are Scrum Teams, or if perhaps some elements of Scrum are being leveraged without alignment to the framework. Before scaling anything, it may be worth exploring how each team is functioning and if there are opportunities to move towards working as cohesive units of professionals focused on one objective at a time who are self-managing, internally deciding who does what, when, and how. Or, if your delivery model is working for you, exploring what Nicholas suggested about creating your own scaling model to fit your ways of working could be the way to go.

As per the definition from the Scrum Guide, it can be considered as a single product.

Here is my attempt to create a value-stream map. Please don't judge it too hard, as this is my first attempt creating it, but I will be more than happy to amend or completely redraw it. This is the current state.

The problem with this state is that groomings are supposed to happen for all the four teams in one meeting.

1. It is impossible to do a proper planning poker with that many people from different teams. That's why only key representatives from each team are invited.
2. Each epic has a responsible BA. Meaning that to groom 5 different epics 5 different BAs might be required and all 4 scrum teams. This makes the amount of grooming meetings 5x4=20. On the other hand if teams only do their own grooming, they might lose a sight of an overall feature being built.
3. Some stories turn out to be dependant on other team's stories, hence there are handoffs.

Once again appreciate your time and effort. I believe this discussion can be valuable for others seeking alignment of multiple Scrum teams.

The picture did not embed. Here is the link: https://drive.google.com/file/d/17xnAuvNKBDGUURqB__US9KceIEd80wrl/view?…

"How many products are there in the situation you describe, and how is empirical feedback on each Increment obtained?"

There is one product, and the functionality produced by all the scrum teams is being demoed to the customer at the end of a sprint by the BA who is responsible for the epic.

Here, by customer, I mean a company who would order a web store for themselves, and not the store clients.

There is one product

Then shouldn't there be one Product Owner with one Product Backlog by means of which team dependencies can be self-managed and visualized?

Ian,

1. We can assign one PO for the product, but in this case the PO won't be able to understand all the details of the work, as the product is very big and rather complicated. The PO would need to communicate to those multiple BAs to form a product backlog, but won't be able to provide all the answers the teams would need in order to properly estimate functionality.

2. And if a single PO is responsible for multiple scrum teams, what would those grooming sessions look like? Would the PO need to bring the respective portions of a functionality to individual scrum team grooming sessions? Some potions of work may not be very clear as to which team's functionality is affected (i.e. functionality can be borderline), whereby reviewing the functionality with representatives from multiple teams helps to understand to which team some stories should go.

As per the definition from the Scrum Guide, it can be considered as a single product.

Based on what you have said, I believe it could be considered multiple products as well.  Remember that stakeholders do not have to external or even paying customers.  You could have stakeholders internally.  For example multiple APIs consumers could be stakeholders for those APIs. I have worked in multiple companies where we considered some APIs to be products because they provided data needed by multiple workflows, internally and externally.  Remember the definition provided by @Ryan from the Scrum Guide

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.

Stakeholders, users, or customers do not have to be human. Value can be delivered electronically to other electronic means.  For example, there are services that provide credit information to other entities in order for them to process credit card applications.  Most of that is automated so that no human has to get involved. 

You currently have a definition of a single product that is causing your organization difficulties. Instead of trying to change everything to fit that definition, maybe it would be easier to revisit the definition.  I have never worked anywhere that used Product Managers/Owners where that individual was not able to fully understand their entire product from the business perspective. Has anyone thought to consider that the problem is not with the processes you use but with the definitions you have adopted? 

Daniel,

that is one way to think about it, and it's what I am thinking as well. Almost each module can be considered a separate product from this perspective. But then again how do we structure the teams and the workflow in this case?



Would each "product" need to have a PO assigned? Should there be a dedicated Scrum Team per each product?

And most importantly, if a functionality required by a BA (and there are many) affects multiple products, how the Scrum ceremonies should be held?

We can assign one PO for the product, but in this case the PO won't be able to understand all the details of the work, as the product is very big and rather complicated.

My advice is not to "assign" a PO. Instead, find out who ought to be accountable for product value. There's a truth to be uncovered, not imposed, and maybe you don't have a single Product but multiple ones. A value maximizer doesn't have to understand all the details of the work -- that's for the Developers to take care of.

And if a single PO is responsible for multiple scrum teams, what would those grooming sessions look like?

In Scrum, Product Owners aren't responsible for multiple Scrum teams at all, or even for one of them. The PO owns the Product. It's the responsibility of teams, of which the PO is a member, to self-manage. That's the essence of Nexus, and that's what refinement and everything else continues to look like "at scale".

Would each "product" need to have a PO assigned? Should there be a dedicated Scrum Team per each product?

Scrum assumes that there will be a single Product Owner responsible for that product's direction.  It also assumes that "Developers" will turn the Product Backlog Items into valuable and usable increments.  Notice I didn't say a Team of Developers. I said Developers.  

The Scrum Guide defines a Scrum Team being made up of individuals that consists of three accountabilities; Product Owner, Scrum Master and Developers.  These are accountabilities not job titles or descriptions.  It is possible that someone with a Business Analyst could fulfill the Product Owner accountability. The only key factor is that the individual that is fulfilling that accountability is trusted and empowered by the organization to own the future for that product. There is nothing in the Guide that states only one Scrum Team exists for each Product.  If you read the section of the Scrum Guide that explains the Product Owner, it seems (at least to me) that they are expecting there to be a single individual that is accountable.  It states that some of the work can be delegated but there is only one accountability for the work. 

I have worked in companies where there was a single individual that fulfilled the Product Owner accountability for multiple Scrum Teams. That was done when there were some shared functionality and needs for the multiple products.  In all of those situations, there were multiple teams of Developers that worked on separate products.  We used Jira (just like most everyone) and we had it setup to have a single Product Backlog but we had multiple Developer teams that created Sprint Backlogs from it.  We used keywords or labels to create the ability to create views for each Developer group but we could also view the work "as a whole" by not filtering. It worked for us but I am not going to say it is the right solution. We found a way to use the tool to our benefit instead of arranging ourselves according to the tool. 

Scrum Events (not ceremonies) should be according to the guidance of the Scrum Guide.  Each event has different purposes and the attendance should be organized according to the needs.  The same can be said of all of the scaling methodologies and frameworks. They all have some adaption that works for them.  I suggest studying some of them to determine what would work for you specific organization. 

There must be the PO for the whole product, who is 'above' the BAs and can prioritize in case there is too much on the plate. Probably there is such a person but it's named differently, like the product manager, delivery manager etc..

The BAs should be part of the Scrum Teams (as Developers whose primary responsibility is facing the PO and the stakeholders and maintaining the clarity of the PBIs)

Now, I suggest taking the perspective of value and dependencies management. We want to deliver value effectively with the least dependencies. We want to discover which setup is optimal for this purpose. 

We could start from the value perspective with the below exercise:

Let's imagine we have a prioritized list of the PBIs (created by BAs and prioritized by PO with input from the Developers)

What is the minimal set of Developers, which is capable of independently delivering given PBI (stretched through various application components and technology stack)? Why not ask the developers, to select the team capable of delivering the PBIs autonomously? Now, let's take the next PBI and do a similar exercise. 

I assume not all PBIs require the same skills and component knowledge. In the end, we may find out that it is not possible to create stable teams this way. However, I think it is worth trying. We need to be aware that we will never get read of the dependecies between the teams. It is just a matter of finding the best balance. Later on, we need to manage the dependecies through Backlog refinements and Sprint plannings. 

If we have the teams created, I would use Nexus, as it seems the most "clear" and obvious framework. The key point is to have a well-organized Product Backlog, where the dependecies are made transparent through Backlog refinement.

Thank you so much for all the inputs! They are really valuable.

The client-facing BAs (who are not POs) is an inevitable part. Should a PO/PM come before the BAs or after them? Who creates PBIs, BAs or a PO? If PO is to create PBIs, then the PO would not be able to effectively provide acceptance criteria or answer developer's questions; and if BAs create PBI, then Developers will need to consult with multiple BAs, and there won't be a single source of thruth.

Would the PO be just prioritizing PBIs, but not writing their description and acceptance criteria?

Absolutely Andrie. POs main focus should be prioritizing the PBIs and not creating and filling details in JIRA, that can be done by BAs. For grooming also, once the PO has prioritized the backlog, the BAs can take it from there with the scrum teams. Having a transparent backlog (Common for all the teams) with clearly marked dependencies can be really helpful.

You can also set up something like Scrum of Scrums (with only leads/BAs) to discuss the dependencies.

Not sure if it is feasible for you but the setup I imagine could be like this:

• There is on PO for the whole product 
• Particular Scrum Teams have all skills to be able to deliver Value (from your example "Support Vendor ABC")
  
  That includes
  • Developers:
    • BA(s), who is leading the PBIs clarification/creation based on the requirements (from your example: unlist the item from the catalog, handle it correctly in baskets..., replace out-of-stock items in advertising)
    • engineers knowing necessary application components and technology stack
    • other missing responsibilities such as 'testing', 'security' etc....
  • Scrum Master (could be supporting more than one team)
    
     
• During the Product Backlog refinement, the PO and the representatives from each team (BAs, other engineers if needed) discover which team can deliver which requirements/PBIs. The Teams and the PO decide which team will do what. They also make clear any dependecies between the teams. Further, more detailed Backlog Refinement can be done within the Scrum Teams, where BA is breaking down the PBIs with the team, they size it etc...
  
   
• During the Sprint Planning, there is already visibility on which team is designated to which PBIs and what are the dependecies, so they can plan the Sprint with this knowledge. The Sprint Planning can be in two stages, first where the initial plan is made (the work is distributed between teams), 2nd further detailed planning in the Scrum Teams. If there are issues discovered in the 2nd stage, further follow-up might be needed
  
   
• Every day the work of the teams is integrated. The representatives from the Scrum Team (Integration Team in Nexus) meet to resolve any integration problems and any dependencies, which could appear on the previous day.

Certain roles on the Scrum Teams might need to be shared between the teams, at least for the time being until the developers extend their skills. Let's say you don't have enough Front end developers, or not enough engineers familiar with the "Ordering process" part. You may want to have them 50% on two teams for example. The same with the BAs - one BA could be on two or more teams...

@Jacek's suggestion is pretty much what I was thinking also.  But remember to go into it with the understanding that it may not work and will need to be adjusted based upon your needs.  But if you don't start with something you will never learn what needs to be changed.  You already seem to think that something needs to be changed so use empiricism...do something, inspect the results, adapt if necessary.  It is a never ending cycle because there are always new influences being introduced. 

BTW, no one ever asked you this but since we've gone this far with along I would really like to know. Is this a real scenario or just something you thought of?  And if it is a real situation, what do others think about the current situation. Do all of the individuals involved feel like this is a problem? What do your Scrum Masters have to say about a possible solution?  I am assuming you are the Product Owner based upon your PSPO II certification.

Daniel,

This is a real-life scenario, although, of course, I changed it to desensitize the data, hence it is hypothetical in this sense. We have internal discussions with Scrum Masters and others but I thought I could bring the issue here to see what it gauges. I will definately bring what was mentioned here to our Scrum Masters. I don't think there can be quick wins, but I am confident we can refine the process as we move along.



Can't thank you all enough for providing your opinions here!