Scrum is mostly used to improve delivery, not for discovery
In my experience, the vast majority of orgs that use Scrum do it to improve on their delivery. With delivery I mean accelerate software delivery, increase team productivity (get more stuff done), increase quality, improve forecasting etc. I browsed through the latest "State of agile" (see stateofagile.com) report and found the the most important reasons for adopting agile within a team/org are (in order)
- Enhance ability to manage changing priorities
- Accelerate software delivery
- Increase team productivity
- Improve business and IT alignment
- Enhance software quality
- Enhance delivery predictability
- Improve project visibility
- Reduce project risk
- Better respond to volatile market conditions
- Improve team morale
- Improve engineering discipline
- Better manage distributed teams
- Reduce project cost
- Increase software maintainability
Although the results reflect the options available when taking the survey I find it quite depressing that there are very few reasons that have anything to with delivering actual value. I would have hoped to see something like "Improve the value delivered to our customers" or something like that at the top but it's not.
Scrum is all about inspect-adapt and a huge part of that is to explore and discovery WHAT we have to deliver and adapt accordingly, but mostly that loop is only used internally to ensure that we improve our delivery (the HOW).
What's your thought on this?
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:
- Delivering value to customers (71%)
- Flexibility, responsiveness (56%)
- Quality (44%)
- Transparency (42%)
- Schdule deadlines (46%)
- Visibility (39%)
- Team engagement and satisfaction (38%)
- Cost (27%)
- Innovation (27%)
- 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.
@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.