Why is there no product discovery in SCRUM?

What SCRUM is aimed at

The goal behind SCRUM is to produce valuable solutions to problems in a complex environment. It is a framework developed by software developers for the organization and processes in the product team. The product manager plays a central role, especially in the product discovery phase.

By definition, SCRUM is lightweight. This means that it provides a framework - but no strict guidelines - for iterative work steps that you can customize in detail for your team. This freedom is intentional, but often leads to teams thinking that SCRUM alone is enough to create real value for the customer.

What is missing in SCRUM?

In order to create value, as required by SCRUM, you and your product team need to understand your customers. This requires an interplay between SCRUM and Discovery or other methods. These methods are crucial for a successful product development process. According to Sebastian, however, SCRUM lacks concrete methods, even though the importance of the product goal and the product vision are now mentioned.

The problem with the application lies in the assumption that a team only becomes more agile through training in SCRUM. The value for customers cannot be created through SCRUM alone if the focus on the framework alone means that important methods are ignored.

SCRUM in its pure form tempts people to use it incorrectly, where the team's focus is purely on velocity (output) and neglects the real value for the customer (outcome). Sebastian says in the video:

"That makes it totally susceptible to abuse - that SCRUM is simply used as a pure feature-baller machine."

Producing lots of features without creating any real value is not effective. You can prevent this with discovery and the resulting better understanding of the customer.

Combine SCRUM and Discovery efficiently in product development

But how do you integrate discovery into SCRUM? This can be tricky in practice, especially in terms of time. It is rarely absolutely necessary for software developers to participate in the work in the problem space with customers. It is important to understand and take into account the actual needs of the users. Discovery is often faster if ideas for solutions are not fully implemented. In many cases, it is sufficient to first present a solution to the customer visually.

There is often a temporal separation between Discovery and Development. Opinions differ on the question of where discovery is best located on the timeline. It is difficult to cover and implement at the same time in a sprint. This is why discovery is often placed before the sprint.

In the end, there are not too many options for the actual placement of the Discovery. Here are some ideas that Sebastian and Thomas discuss in the video from minute 7:00:

a) Dual-track SCRUM

Use two SCRUM tracks - for discovery and development. These tracks can cover different areas of product development, such as the problem space and the solution space. This allows your team to develop in SCRUM while exploring customer needs to bring a valuable product to market.

b) Integrate UX / Product Owner / Product Manager into the process

Product owners or UX experts can take on certain tasks in discovery and development. It is important that the development and validation of product ideas is continuous. Different areas are easier for different specialists - that's why they exist. At the same time, they should not work completely separately from each other in order to remain efficient and effective.

c) Include finding a solution in the sprint goal

Discovery and development are often seen as two separate processes. Discovery comes first - then the sprint for development. However, you can also integrate finding a solution to "Problem Y" into the sprint goal. This ensures that the team solves the right problem and develops the right product. This way, there is no division between development and discovery in the timeline.

• For great products, you need more than the SCRUM framework in product management.
• Without other methods, such as discovery, SCRUM leads to quantity instead of quality.
• Be aware of the incompleteness, integrate complementary methods...

... and combine these with SCRUM.

‍