Impediments in applying Scrum

A small development department has 10 people on board. That is exactly 1 more than the maximum limit

Are you sure that Scrum prescribes a "maximum limit" of 9?

In Scrum, we should not have 2 products and 2 product owners for the same team

Why? Are you sure that this arrangement is forbidden in Scrum?

It should go live on a given exact date. How about frequent releases?

Would risk be mitigated through validated learning and empirical process control?

A part of the solution is delivered by another organisation

Is there anything to stop Scrum Development Team members from belonging to different organisations, or from teams in different organisations belonging to the same Nexus?

First of all, thank you for your answers.

I am afraid I gave a too dramatic title to this conversation since the mentioned problems are not really blockers in applying Scrum. I would not really consider Scrum to 'prescribe' or 'forbid' anything. The guide is certainly not a law, just a guide, teams throughout the world do whatever they think is good for them, and there is no Scrum Police to force them to change course.

However, Scrum Masters are hired for doing Scrum right, following the guide, and also the guidance of Schwaber, Sutherland and further credited authors endorsed by the founders. I guess the books recommended for preparing for the PSM exams are considered dependable. I assume I am not the first person to notice that these books, commentaries take a rather doctrinaire stance, even use a very strict language, talking about 'misconceptions', 'myths', etc., and making suggestions on what the teams _should_ do. We cannot even say these commentaries are completely arbitrary since the test questions of the PSM exams apparently penalise alternative opinions. What concerns me is that these recommendations typically disregard the scenarios where applying them seems to be impractical if not inappropriate.

On the other hand, there is of course value in the aforementioned explanations and recommendations. It is easy to understand what benefit we can expect from them, and probably we all have seen situations when taking them would have resulted in a more favourable outcome.

The reason I started a conversation is to discuss/see/understand what other people do in the case when their own assessment of a situation and the comms from scrum.org are difficult to match. We all want to do the best for our teams, so deciding not to take the expert advice cast some doubts over our decisions. In this context, I believe my questions are valid and it makes sense to exchange views and talk about our relevant experience in dealing with such scenarios.

Getting back to the questions:

>> Are you sure that Scrum prescribes a "maximum limit" of 9?

"Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful."

Thus it is explicitly mentioned in the Scrum Guide. That is why I am interested in other peoples' opinion/experience in exceeding this limit.

>> Are you sure that this arrangement is forbidden in Scrum?

Adding 2 products for 1 team is not a scenario detailed in the scrum guide or in any major exemplary sources. If you consider, it is not straightforward either: 2 product owners using the same team probably require agreement on sharing the resources. On the other hand, it is emphasized in many sources that the product owner should be a single person with a mandate to make decisions. Having 2 product owners does not match this description. Any ideas welcome.

>> Would risk be mitigated through validated learning and empirical process control?

When talking about a hypothetic scenario, I say hopefully would.

>> Is there anything to stop Scrum Development Team members from belonging to different organisations, or from teams in different organisations belonging to the same Nexus?

I am afraid, typically yes. Ties are rarely strong enough between independent organisations for setting up a Nexus. Moreover, there is a good chance that not all parties would apply Scrum at all.

This is from the 2020 Scrum Guide: 

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. 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 totally agree that your scenario's make it hard for Scrum to be implemented, especially if both products need to be developed at the same time. 

In fact, even if for example each product was developed every other month, I would think that this would prevent the developers from having full focus on both products due to regular switching; however, a one month period should hopefully be enough for them to at least have a high level of focus. 

Then we come to the situation where the next sprint is supposed to start right after the previous sprint has finished, which means if you do choose alternate months, then you are no longer doing Scrum. 

We have a similar situation where I work, in that we have a large number of products but only a small number of developers, and at least one of these products is a very complex beast that is decades old.  After talking with some of the developers I found out that they did try scrum some years ago (I do not know to what level), but discovered that they could not get it to work in such an environment, especially for the legacy product.

From your description you have 10 Developers, 2 Product Owners, 2 products.  Why not create 2 Scrum Teams consisting of 5 developers, 1 Product Owner to work on a 1 Product each? That was the very first thought that came to my mind and it provides solution to a number of the issues you bring up.  Would 5 people be able to do as much work as 10 people in the same time frame?  In some cases yes but that is up to the teams to determine as they arrive at a sustainable cadence and then the organization will have to adapt to align with that cadence. 

As for part of the solution being delivered by other parts of the organization I see no problem as delivery is not something described in the framework.  There is an expectation conveyed by the Definition of Done that can determine when it will be in a releasable state.  Scrum doesn't require that you release every Sprint or even when you do release.  You just coordinate with the other part of the organization so that both parties are ready to deliver at the same time.  Part of your Definition of Done can provide the state that is needed and your team(s) work towards that.  

"Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful."

That is a quote from the 2017 revision of the Scrum Guide.  The 2020 revision changed that to the excerpt that @Scott Anthony Keatinge provided. You can find the full Scrum Guide at https://scrumguides.org/. 

- A small development department has 10 people on board. That is exactly 1 more than the maximum limit of a Scrum development team. However, all deliveries are built on the same platform, the same stack, everything is pretty much intertwined. Do you really split this team into 2?

"The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product."

The above is taken from 2020 Scrum Guide and notice the word typically is used. That just indicates that it's more likely to be successful based on historical data than if it exceeds 10 people. Can you still be successful with larger teams? Yes. This is not an impediment to Scrum directly.

- Software is just one component of a product family. A large number of people are working towards success, managed by multiple product owners. There is development work for 1 single team, but the number of products to support is 2. In Scrum, we should not have 2 products and 2 product owners for the same team, regardless they implement the products on the same platform and the products should evolve in parallel. Shall the tail wag the dog (e.g. adjust the entire product development process to software development)?

This sounds like a scaled scenario in which the company is trying to use the same platform for two products simultaneously, which as you've identified would be anti-scrum, although it may not be inherently anti-agile. It's important to understand that Scrum is not the end-all-be-all of agile development. 

That being said, you could just de-couple the platform, and allow both products and their teams to have their own platforms. 

- A regulatory project requires a solution, should be delivered in e.g. 6 months. It should go live on a given exact date. How about frequent releases?

This doesn't sound like a Scrum product, or an Agile product in general in that it violates the rule of early and continues delivery of value, and obtaining feedback to organically evolve the product. If it is already fully decided before it goes live, there's no need to try and release using an Agile approach, revert to traditional waterfall models instead.

- A part of the solution is delivered by another organisation. Go live should happen at once. How about continuous integration and potentially releasable software?

This could be a scrum product so long as the other organization's team is working from the same product goal / product backlog, have the same product owner, and the same definition of done. Although, I would argue again this needs to be de-coupled. Separate the product into multiple products, and allow each team to deliver independently. 

What would be your suggestion?

Scrum is not a one-size-fits-all framework. It has specific parameters that are in place. Failure to meet these parameters isn't a failure to apply Scrum, it's an acknowledgement that Scrum is not the correct approach. You can still have an Agile approach, and not be using Scrum. It's also not correct to say that a Non-Agile delivery, or specifically a Non-Scrum delivery is somehow inferior or "worse". There are multiple correct ways to reach the final destination, it's a matter of using the right tool for the right problem.