Scrum only for complex products?
Recently I have come across defining Scrum as a "framework for creating complex products" many times. It's even in the Wikipedia: https://en.m.wikipedia.org/wiki/Scrum_(software_development)
I might be wrong, but I can't agree with such a definition. I also don't see its justification in the Scrum Guide.
I agree that problems can be complex. Creating and managing products is also a challenge. But does a complex product really have to be a solution we are looking for? Isn't simplicity the strength and competitive advantage of many products?
From my perspective Apple and Uber products are everything but complex. Creating, managing and sustaining them is a different story.
What is your opinion?
Perhaps these sources are not reflecting the latest version of the Scrum Guide, and are instead using earlier language.
*Someone may disagree with the examples I gave. I mean the user perspective only. Nevertheless I believe the product itself that solves a complicated problem can also be simple.
Similar phrasing continues to exist in the November 2020 Scrum Guide:
We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots.
And also:
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
And also:
In complex environments, what will happen is unknown
I've probably used words and phrases like "complex" when describing the suitability of Scrum for a given context. When I use it, I'm referring to the complicated and complex domains of the Cynefin framework. Given some of the information around the Scrum Guide, I suspect the authors are using it in a similar way.
In the Cynefin decision-making framework, there are 5 domains - obvious, complicated, complex, chaotic, and disorder. The obvious domain is one that is tightly constrained and very well-understood. In this domain, there are clear best practices and it's relatively easy for someone with the right knowledge to be able to make clear connections between causes and effects. However, there are plenty of domains that are not like this. Instead, they fall into the complicated and complex domains that are full of good practices that must be carefully selected based on the context and a great deal of experience and knowledge to select the best way to carry out work in a given context. The ability to observe what is happening and make adjustments to it is key to making good decisions in the complicated and complex domains.
Considering this, there's nothing about the complexity of the product. The complexity lies within the space where the product is being created or used. Since Scrum is built around short (less than 1 month) iterations with daily feedback loops among the Developers, it's well designed to support working in environments where you cannot predict the impact of events on what happens in the future. The team is always adapting - their Sprint Backlog on a daily basis at the Daily Scrum, the Product Backlog regularly through the Product Owner and on a Sprint basis through the Sprint Review with key stakeholders, the Product Goal on a regular basis as the environment changes. Even the Sprint Retrospective allows the team to reflect and adapt their way of working to maximize their effectiveness as the context changes. Nothing is set in stone for a long period of time.
Thomas Owens,
Thanks for your answer
The complexity lies within the space where the product is being created or used.
Exactly this is what I was trying to say. I still can't find any argument why the product itself would have to be complex.
'The Scrum Guide has been updated to make it less prescriptive, using simpler language to address a wider audience. These changes have been done to make Scrum a "lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems".'
https://www.infoq.com/articles/changes-2020-Scrum-guide/
Your original question comes from a wikipedia article. If you look at the Scrum Glossary from this site (https://www.scrum.org/resources/scrum-glossary) you will find this.
Scrum: Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems as defined in the Scrum GuideTM.
Notice is says nothing about a complex product only complex problems. In the Scrum Guide there is only one statement that describes what a Product is
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.
Notice that there is nothing said about the Product being complex.
I feel like the basis of your confusion is from relying on information that is not created or maintained by individuals involved in the definition of Scrum. @Ian Mitchell pointed this out in his first reply to this question.
Perhaps these sources are not reflecting the latest version of the Scrum Guide, and are instead using earlier language.
And @Thomas Owens' correlation to the Cynefin framework and following explanation shows how Scrum focuses on the work needed to solve a complex problem not a complex product.
Exactly this is what I was trying to say. I still can't find any argument why the product itself would have to be complex.
TL;DR The Scrum framework is meant to help with complex problems, not complex products.