Do we really need Scrum?

According to a recent discussion on LinkedIn, Dr. Jeff Sutherland claims regarding SAFe, "If you remove all the waste from SAFe you wind up with Scrum." Now, it's obvious that the creator of each product promotes their product - and that Dr. Sutherland would promote the merits of Scrum as a "no-waste form of organization". 
Let us ignore for this post the question whether SAFe is really just "Scrum plus Waste" and much rather consider the question "Is Scrum really where we want to take our organization?"

Conway's Law

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" - M. Conway

Any defined structure within an organization channels communication, so any form pre-defined Structure affects the design of the created product.

Conway's Law should spark the question, "Is the form of system created by Scrum even desirable?"
To answer this question, we first need to drill a little into why people actually use Scrum.

The Waterfall Strawman

Scrum is often compared to Waterfall software development, and the portrayed as the "better alternative". Well - that's true.

Waterfall was proclaimed as dysfunctional by Winston Royce even at the time when it was first published. People adopted it regardless.
Now, let us compare Scrum (works) with Waterfall (doesn't work). Of course Scrum looks much better.

Does that mean Scrum is the best way to do things? No. We haven't proven that. All we did was apply the "Strawman fallacy" and combine it with a "bifurcation fallacy".

The real question is not whether we should use Waterfall or Scrum. With a bit of common sense, we would choose option #2.

The real question is "What system do we need?".
In this case, the answer for "Scrum" is much less obvious. Let us explore further.

The problems

Let us examine some common problems that we tackle with Scrum:

1. We can't reliably plan for the Unknown, so we make short-term plans in scheduled, short (2-week) iterations.
2. We don't know the perfect process, so we need Retrospectives at the end of every Sprint to improve.
3. We don't know how the customer likes our product until they see it, so we need Reviews at the end of every Sprint to adapt our plan.
4. We need to remain synchronized on our Sprint Goal, so we need Daily Scrum Meetings.
5. We need someone to keep the Product Backlog healthy, so we need a Product Owner.
6. We need someone to make Scrum work, so we need a Scrum Master.

Well... that all looks sensible. Until you look closer.

Sprint Planning

Statistically speaking, regardless of team size and sprint length, your Sprint should contain at least 4 items in order to guarantee that you have something noteworthy at the end of every Sprint. This means that on average, each item for the Sprint should not be larger than 1/4 of the Sprint.
(The proof is left as an exercise for the reader)

This means that in every Sprint, you have at least one item that you have planned ahead at least three times longer than it takes to actually deliver it!

Think about what this means.
We badmouth Waterfall, because allegedly, we have Unknowns that make it impossible to plan too far ahead, yet we keep a planning horizon of 300% or bigger than the work we're actually doing at the moment.

Does a 300% planning horizon actually sound feasible? Does it sound optimal?
Is it possible to live with a 100% planning horizon? Yes. We plan only the things we actually work on next. Of course, this means that within a 2-week period, we will plan many times, based on more accurate information and consuming less time in each meeting.

When it comes to planning, there is a better way than Sprint Planning.

Retrospectives

When it comes to Continuous Integration, Martin Fowler stated, "Continuous Integration means to integrate continuously". And with that, he meant, not monthly - not weekly - not daily, but: Continuously! Experienced Scrum Practitioners would agree that integration at Sprint End is a terrible idea and a surefire recipe for disaster.

Now, after this slight detour, let me ask this question:
If "Continuous Integration" does not mean "Integrate at Sprint End", why would Continuous Improvement mean "Improve at Sprint End"?

The best time to consider whether we should improve the way we are doing things is not after you have done them - it's while you are doing them!

When it comes to Continuous Improvement, there is a better way than Sprint-End Retrospectives.

Reviews

When is the best point to get customer feedback on a backlog item? About a week after it's Done - or earlier? This question sounds weird, yet it is what we are doing with Sprint Reviews.

The Agile Manifesto states that we should constantly collaborate with business, and that includes customers - throughout development.
The entire idea of MVP is not limited to one-time-up-front delivery of a small portion of value to validate the next step, it can be applied even within a single backlog item.
A single TDD cycle already adds a little more value and can be presented to the customer, without them even knowing the difference. Stuff like A-B testing permit us to get customer feedback on even miniscule changes in real time, without having to wait for a week after getting work to "Done".

When it comes to customer feedback, there is a better way than Sprint-End Reviews.

Daily

We need Daily Scrum, because team members are working on different things and need to ensure that the Sprint Goal will still be reached. Effectively, this is stating that the Daily Scrum is Scrum's way of keeping the team aligned.

That has two implications:
What if:
a) The team isn't working on different things?
b) There is no "Sprint Goal"?

When everyone on the team is working on the same thing, why would we sync on that? We are already synced.

Let us limit the team's Work in Progress to 1 and consider the current WIP as our common goal, and Dailies become obsolete.

When it comes to keeping alignment, there is a better way than Daily Scrum.

Product Owner

The Product Owner ensures product success, which includes critical business decisions.
For all responsibilities of the Product Owner, the Scrum Guide states, "The PO may do these things or have the development team do them." - effectively, even Scrum concedes that the PO is not needed.
That alone should trigger the question whether we need a person who has successfully delegated 100% of their work.

One of their most important responsibilities is ensuring a well-maintained Product Backlog.

The Backlog contains the list of all the currently known undone work. It's the team's "undone queue". I will reduce this to a simple question: "Why do we need a queue?" A queue is always an undesirable state, as it means that something important is waiting.

JIT production systems reduce wait times. Scrum's product backlog effectively does the opposite. It is a vain promise that something may (or may not, depending on new information) be done in the future. It's good to create transparency on what the customer still needs - it's better to deliver it as fast as the customer can order.

The PBL creates many problems that the PO has to solve. Would we really need a PO if we had JIT development?

The PBL itself is based on the idea that we want to optimize team utilization in each Sprint. The entire concept of Utilization is another can of worms that is explored in another post.

The Product Owner is a solution for problems that would not even exist without a Product Owner.

Scrum Master

This point is quite simple: If we aren't going to apply Scrum, why would we need a Scrum Master?
Maybe an agile coach is still needed, but agile coaching works different from how a Scrum Master works.

The Scrum Master is a solution for a problem that exists only in Scrum.

Summary

Based on Conways Law, your communication structures - and therefore - your product will reflect Scrum. None of the structures created by Scrum are optimal.
Consequently: with Scrum, you will not build the optimal product.

Scrum allows you to successfully build products at a low cost, with low risk and in a short period of time. And - it works.

Is it optimal? No.

Should you use Scrum? That depends on where you want to go.

The communication system of your organization should depend on your goal. 
Only then will you build the optimal product.
Don't feel pressured to reformulate your goals in a fashion that fits into a predetermined communication structure.