Which scaling model would you suggest?
Hi guys,
in our company we ran a model with four Scrum teams each consisting of a fixed dev team, a fixed PO, and a fixed set of products/Product Backlogs to work on. Since each Product Backlog was assigned to a specific team there was no need of scaling.
This model worked out pretty well as long as demands for the products were spread roughly evenly across products. However, we see that sometimes a product was about to gain strong focus leading to a higher demand of work for a couple of Sprints for this product. Since there was only one team dedicated to this product this team alone was not fast enough to accomplish the required work. The other teams had their expertise in other products and could not really be of big help. As we now see this model does not suit our company and the market anymore.
Our way for us is to give up the concept of feature teams, i. e., teams being dedicated to a fixed set of products, and want to follow the approach of "each team can work on all products". From my experience this is a delusion but I support the approach that every team is allowed and encouraged to work on more products than an assigned set. By this approach we can solve silos and support knowledge transfer. The most important aspect is of course that we are now more flexible to react to an above mentioned focus shift. Two or more teams can then work rather effortlessly on a single product for some time.
However, we now run into the need of scaling. By following this approach we have to melt all former Product Backlogs into one with a prioritization over all (sub-)products. From this Backlog all teams pull PBIs in a common Sprint Planning (according to priorities).
Looking at the Scrum Framework and the well-known scaling models Nexus and LeSS, I see that you can go with one of two approaches:
1. Several PO's with several Product Backlogs. Several teams strictly assigned to a set of products. (This is as we did since, confom to Scrum.)
2. One PO with one Product Backlog consisting of all products. All teams work on this Product Backlog.
However, the products are rather large and complex. In addition, we will have about 10 Scrum Teams in the near future. So, one PO cannot handle this by himself.
Now to my question: Is there a feasible model
- which allows several product owners (who might have their own Backlogs) providing the PBI's in one common Product Backlog in the Sprint Planning?
- which allows all Scrum Teams to pull PBI's from which product they like (of course respecting priorities)?
If there isn't such a model, why not? Or am I missing something or make false assumptions? I definitely do not want to break Scrum by scaling.
I appreciate any advice! Thank in advance for your support!
Claus
By following this approach we have to melt all former Product Backlogs into one with a prioritization over all (sub-)products.
Why? If the teams are skilled enough to deliver multiple products, why can't they just change the product they are working on each Sprint, and benefit from the focus of a clear Sprint Goal? As long as each product is serviced at least once per month by the same team, empirical process control can be established.
Honestly, I don't think your problems will be solved by scaling. Scaling, regardless of the framework, WILL absolutely introduce complexity.
However, we see that sometimes a product was about to gain strong focus leading to a higher demand of work for a couple of Sprints for this product. Since there was only one team dedicated to this product this team alone was not fast enough to accomplish the required work.
This was the only reason given for why you and the company feels you need to scale. All due respect, I don't think that justifies scaling. You can very easily solve that problem without changing the framework.
I would also strongly suggest against have multiple products roll up onto a single product backlog. The Product Backlog is designed and intended to be used for a single product. That way you're talking, you have multiple products, large products at that. How would you prioritize across products? It wouldn't work.
I don't see any need of scaling based off what you shared. If your car was burning oil and needed a simple oil change and tune up, would you say "nope, the car isn't working for me; I need a brand new car"? I highly doubt that would be the case but that is what it seems is happening here. The problem shared can be solved by setting proper expectations with leadership, providing the team more time to complete the work, slicing the work to smaller sizes, adding an additional team to the product that is regularly struggling. There are numerous ways to solve the problem you shared, I can't see how scaling would solve it. In fact, I imagine that scaling will cause exponentially more problems.
Hi Ian and Curtis,
thanks for your answers!
Maybe I failed to put my problem into proper words. I will try again to wrap it up.
You are right, we have multiple products (which are somehow related, though). And we have several PO's for them. Moreover, we do not want to rigidly assign teams to products anymore. This should result in teams being able to work on any of the products in any given Sprint allowing us to work on a product with more than one team at once.
Now here is my problem: Many products in parallel along with non-dedicated teams calls for an overall prioritization of PBI's. This can only result in a common backlog in my opinion. How could we otherwise represent the different focuses on the products in the Sprint Planning Meeting(s)?
Am I missing something here?
Best,
Claus
Many products in parallel along with non-dedicated teams calls for an overall prioritization of PBI's. This can only result in a common backlog in my opinion.
It *might* result in a common backlog, if in aggregate it represents a value stream that ought to be maximized. In Scrum you'd then have need of a clear Product Owner.
On the other hand, there might be multiple distinct value streams, each one of which ought to be maximized by its own PO. This might just call for the prioritization of products, which could be a strategic matter best handled by the organization. A suitably skilled team could then reasonably service different products in different successive Sprints. How to decide on these priorities is context specific, although Evidence Based Management can help with the measurements.
1 Product
1 Product Owner
1 Product Backlog
Having teams work on multiple product introduces context switching, which will take away the focus on quality as people have to switch on what they're doing, where they're at etc. And let's say a team is working on multiple products, or features for that matter, can you say they are actually working as a team?
Moreover, we do not want to rigidly assign teams to products anymore. This should result in teams being able to work on any of the products in any given Sprint allowing us to work on a product with more than one team at once.
Why don't you want teams dedicated to a product? Have you (and the company) considered the risks involved with having teams constantly shifting focus from 1 product to the next? How would the teams ever achieve any level of mastery? While it may seem like a smart idea to have the teams become proficient in all of the offerings of your company by having this happen, I would bet that it will in turn cause more problems than it's worth. Take the mindset away from software development. How many professional sports players have successfully crossed over to multiple sports? Bo Jackson back in the 80's, Michael Jordan in the 90's, and Tim Tebow; even though both Tebow and Jordan went to minor league baseball not the majors. What about musicians? How many make it big in pop and move to country, rock, R&B, etc successfully? Again, maybe a small handful. While venturing out to a new skill can help in the deep skill set, there shouldn't be a drastic and full time departure.
I predict you will see a great deal of expertise lost through this venture. Being a "jack of all trades" can be helpful but it is also detrimental. Remember the enemy of great is not bad, it's good. We want our teams to be great don't we? We want them to succeed and be the best possible. Being good at multiple products prevents them from being great at 1 product.
In my experience, you can keep scaling until you go from Agile back to waterfall. In my opinion, the beauty of business agility lies in small teams who can get things done. However, a particular scaled framework is taking over all large enterprises and I have yet to see it resemble what I know as Agile.
I can tell you my experience. Be careful
In 2019 we had a cut of 50% (around) in budget and we did the following.
Starting to lend resources to another projects. So is basically the same scenario...our product has less value to organization, we moved people to higher values products.
That does not work. People do not like the change of focus.
What we learned that works is buiding a team and changing the amount of work according to priority. When work is too much or a well planned ramp up of people (temporarily) wortks but never like....ok today you work in Trading....next week you work in payments.
That did not work for us.
When payments were understuffed we just de-scoped. The best way to mitigate is knowledge transfer from overrun products (products you know will suffer.
But teams should be stable. A well performant team will help other in a way you can not predict.
Believe me: We have digital banking with 18 teams :D