Should the scrum team be involved in the product discovery process. If so, why?

Welcome to part 10 in our scrum master interview questions series where John McFadyen answers common questions posed to scrum masters in interviews and client engagements.

This is an odd question to be asked in an interview because if the scrum team aren’t involved in the product discovery process, who else would be doing it?

Remember, the product owner is a part of the scrum team, and they act almost like a CEO of the product. They need to be informed, educated, and empowered to make great decisions regarding the product.

In my experience, a great product owner leads product discovery.

And so, why wouldn’t there be developers involved in the product discovery process too?

If they are the ones who are going to build the product, and solve complex problems associated with customer requirements and demands, it makes sense that they should be a part of the discovery.

The product may simply not be viable or doable.

The developers are going to be the ones that could tell you that and help shape conversations around what is doable, possible, and achievable. They are the ones who are the experts at solving complex problems and building complex products and so they must be involved.

Product Development

I’m baffled by the question because the interviewer is making the assumption that product discovery is separate to product development, when a key part of product development is ongoing discovery.

Scrum is built on empirical process control.

The idea that we are transparent in what we are going to work on, that we frequently inspect what has been built and receive feedback on that work, and that we use the feedback, data, and evidence to inform what we do next.

So, building products and features in a complex environment is a process of continuous discovery, experimentation, iteration, and adaptation.

Are we clear about the problem that needs to be solved?
Do our customers want the proposed solution?
Do our customers perceive value in what we are creating?
Has this iteration yielded a working product or feature that solves a customer problem?
Are the next 10 items on the list still the most valuable things for our customers?
Has circumstances changed in our customer environment that require us to pivot?
Have we captured 80% of the value through 20% of the features? Do we need to finish the list or do our customers want us to work on something more valuable?

And so forth.

We are continuously learning, through doing, and using the data and evidence and feedback to help the team decide where their time, efforts, and capabilities are best invested.

Continuous discovery and adaptation.

Experimentation

So, in the early days of product development, the developers are very much invested in developing a hypothesis, designing an experiment to prove or disprove that hypothesis, and using the data and customer feedback to determine whether value is being created and captured.

In theory, the developers are tying to do the least amount of work to capture or create the greatest amount of value. They aren’t following a predetermined plan and executing one step after another, it is a process of continuous discovery, testing, and adaptation.

What is the specific problem we are trying to solve?
What is the specific job the customer is trying to get done?
What is the specific need that the customer has, and how will this meet that need?
Does the customer know what they want or is this a process of discovery for them too?
Do we know what a great solution looks like or do we need to discover that through frequent experimentation and customer feedback loops?

This is how we deal with uncertainty and complexity.

We develop a hypothesis, design an experiment, run the experiment, and then use the data and feedback to inform step 2.

We are trying to validate ideas, learn, develop new skills and capabilities, and understand what needs to be done for us to continuously improve and create value for customers.

Your developers, product owner, and scrum master are likely to be key people in this process.

Project Management versus Product Development

In traditional waterfall-style project management, you generally have a team of project managers and stakeholders who attempt to define the scope of a project or product upfront.

A customer representative will often attempt to articulate what the customer wants or needs to the project management team, and they will focus on defining how long that will take, how much it will cost, and who needs to be onboard for the project to be delivered.

In this 20^th century style of working, the primary assumption is that the managers are smart, whilst the people doing the work are simply cogs in a machine.

They simply need to do what they are told, within the time frames specified, and within the cost constraints identified.

That’s fine for simple or complicated work, such as building a bridge, but when we move into the space of complexity, this tends to fall over because we can’t know the answers upfront nor can we anticipate all the variables that may impact the product or environment.

The question of whether a scrum team should be involved in product discovery arises from this traditional project management environment where the primary assumption is that managers and leaders are better positioned to make strategic calls than the experts who build the product.

As I’m sure you can see for yourself, it makes sense for the experts who build the product or solve the problem to be involved in the discovery process rather than leaving it to people whose primary job role is to manage things, people, and processes.

Managing something is not the same as designing, building, and improving something.

Therefore Agile, and Scrum, focus on having skilled, experienced, and capable experts involved in the decision-making process and use frequent reviews, customer feedback loops, and periods of reflection to ensure they are always working on the most compelling problem or building the most valuable product/feature.

So, in closing, yes you should have the scrum team involved in the product discovery process and it would be a big mistake to not include them in strategic decision-making around that product.

About John McFadyen

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster