Scrum is mostly used to improve delivery, not for discovery

Look at the words. In most organizations value is not delivered, projects are. This construct frames and prejudices the thinking of those surveyed. It might even be an a priori assumption within the report.

Projects are the common currency of organizations, but they might not be the best vehicle for delivering value.

There are people out there pitching for jobs who want to get paid saying "Agile helps you do more, do it faster, do it better, and do it cheaper." Basically speed, cost, quality, and quantity all at once. They are pitching this to managers at big companies, and they are eating it up.

PSM enters the game, and hears this expectation. Oh no! That's not how it works! Trying to do that will be anti-lean and not scrummy at all!

We are challenged to spread a better message: Scrum is an iterative, incremental, team-based, feedback-loop based framework that helps you be more selective about what you build, focus so you actually start finishing work, hit the requested target more accurately with regular feedback, and improve quality through increased commitment to the work. And let's not forget the power of sprint and product goals helping with a sense of mission and purpose.

I think we just have to keep coaching and teaching where we can that it does great things, but not by boosting a company's old scientific management efficiency measures. A good way to do that is to get people to try to do scrum in their context.

First, I'm going to start with my feeling that the report is biased from the beginning. It was funded and created by Digital.ai.  A company that markets DevOps tools.  That market segment is focused on being able to deliver software to the end user quickly, reliably, and fast.  It honestly doesn't focus on the value the software provides at all.  It doesn't provide any information on how the individuals were selected for participation so for all we know they are all related in some way to Digital.ai. 

This report states that a large number of companies are using Scrum. But as evident by a lot of the questions posted in these forums, not all companies that say they use the Scrum framework are using what is described by the Scrum Guide.  So I hesitate to say that report is an accurate representation of actual Scrum usage.

I know I'm a bit of a purist but when a report is created about the state of Agile, I automatically discount it.  I've said it before in these forum. Agile does not exist beyond the use of a marketing campaign or terminology.  And since every implementation of any practices that will help an individual organization be more effective at adapting to changes will be unique to that organization, these type of rolled up reports don't carry much weight for me. 

I did some further reading on different sources and stumbled upon the 2017-2018 State of Scrum report from Scrum Alliance. There the top reasons for choosing Scrum was:

1. Delivering value to customers (71%)
2. Flexibility, responsiveness (56%)
3. Quality (44%)
4. Transparency (42%)
5. Schdule deadlines (46%)
6. Visibility (39%)
7. Team engagement and satisfaction (38%)
8. Cost (27%)
9. Innovation (27%)
10. Improving org. design and culture (25%)

Some similarities but as you are suggesting, the results are reflected by the survey was conducted.

I don't know if "value" is something the Scrum Framework should include directly, it's a delivery process IMO. The Product Owner is tasks to find value and get this delivered within a Project or gradual improvements of an existing platform.

If the PBI has no business value then it shouldn't be on the backlog. The Product Owner should ensure that shareholders understands the "value add" and that it's been quantified. 

The delivery/scrum team will forecast to deliver a Sprints worth of PBI. If these items have no business value then IMO this is a direct fail at the Product Owner level. (of course it's a team effort so the team take the hit).

I promote to my teams that they must challenge "fake value" where a bright idea is technical flawed or at the user level, unsuitable. They are train to use the Toulmin model to challenge PBIs. This is a Scrum-And but this helps.

This can also backfire as Scrum Teams can push-back when something must be done for a sensitive business requirement. So take care with this advice. 

https://en.wikipedia.org/wiki/Stephen_Toulmin 

@Garry, I am afraid I totally disagree with you.

Scrum is all about value. My point with the initial question is that it is in my experience mostly used as you describe, a delivery process. The feedback to evaluate whether what we are delivering is right or wrong is often missing.

The empirical process is based on the past, e.g. we must base our decision for the future on existing facts, we cannot successfully analyze the problem upfront and decide what the best action is, but it must come from experience and what is known. You say that if a PBI has no value it should not be on the backlog, but the problem is that often the PO does not know what is valuable and what is not. What is and is not valuable is a qualified guess until delivered and validated by users. How much uncertainty there is about what is valuable differs, of course.

I agree with you Fredrik. We could not put for the the product we complete without assigning a value to it first. Our team can't just pat themselves on the back because they are pushing projects out the door completed. My PMs and POs are constantly asked how many people this fix/update will impact. 



Not all high value projects can be delivered in a single 2 week sprint, so we must redefine what people think Scrum does. It's not just a faster assembly line. It's a smarter assembly line that asks questions and challenges ideas to create the best value.