Scrum is an interesting methodology. I would like however to discuss some aspects of Scrum that tend make projects non-agile. I also hope that I will be able to challenge the idea that some people have that "agile" necessarily means "Scrum".

I personally want my projects to be agile and this is what I mean by "agile":

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Scrum has 2 core concepts that are build to deliver this promise: the Product Backlog and the Sprint. My main complain is with the way Sprints are designed and implemented. This is a paradox because I agree with the idea that features have to be build iteratively but I disagree with the way Sprints are defined within the Scrum framework.

The Sprint duration

Let's discuss about the duration and content of the Sprint.

The Scrum guide defines the Sprint as follows:

• The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort.
• Also the Sprint should ideally be defined by a goal:
  The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

I agree that the goal and duration are guidelines, but these are the first issues that I have with Sprints: some features are implemented at the same time not because they serve a common goal but because they are the next priority in the list. It would be better to be able to define a clear goal for a Sprint but what I usually see in organizations is that Sprints are made of heterogeneous set of features.

But the biggest problem is not actually the goal. It is the time. Some features are implemented in 2 hours and others in 2 months. The small features happen then to be implemented and waiting for the end of the sprint to be fully cleared and the big features are artificially cut into parts that can't be delivered at the end of the sprints of part that are re-conducted to the next sprint.

This time-box constrain is getting arbitrary and disconnected to the real cycle of delivery. I would rather eliminate the concept.

The Sprint Review

The biggest problem that I see with Scrum is the Sprint Review concept.

These are 2 excerpts from the Scrum Guide:

• "A new Sprint starts immediately after the conclusion of the previous Sprint."
• "Attendees include the Scrum Team and key stakeholders invited by the Product Owner"

These principles are flawed in my opinion. And the worst is that those principles mislead organization and give then a sense of false agility. What commonly happens is that a team spends half day in a Friday to showcase the work and get feedback then start a new Sprint start the next Monday morning. Most of the time the recipient of the review is the product owner or a manager (not specified by the Scrum Guide but this is how Scrum is often implemented)

The principle of agility is that team should deliver value to customers. The product owner is not a customer or an end user. He/She is an internal team member. The push back that I often get on this point is that the review should be performed with the relevant stakeholders, not only the Product Owner. But what is often the case is that those stakeholder will probably still be a internal employee. Even the CTO/CEO or other manager are still not the real end users.

The other problem with this process is that the review done in half day. It might be OK for some features but most feature need more time to validate. A real validation my include Maybe including some A/B testing or analyzing analytics data.
Also if you are working on a relatively complex organization, you may other teams may have to perform more tests or a feature may go though multiple deployment stages.

Framework VS Implementation

Ultimately Scrum is a framework not a rigid process, it can be adapted to each organization needs.

The problem that I see is that a lot of managers think that Scrum and Agile are strictly equivalent. Implementing Scrum can give the false impression to be agile. You may implement Scrum but it doesn't mean that you are really agile. It is is at least important to understand to be transparent about the process.
Also I would not totally separate the framework and the implementation. Even it there will be better ways to implement Scrum, I still think that Scrum can be misleading in its principles.

Other options? Scrumban?

Personally I think like to study Scrum principles and I do think that Scrum is a good place to start.
The best part of Scrum remain the management of the Product Backlog.

The part that I like the least if the Sprint. For this part I think that Kanban gives a better way to follow the implementation. It also give more control on the flow. You can add more column to account for other steps of the process. Feature are managed individually so some feature can go thought the validation process independently.

One aspect that I would consider before recommending Scumban or Scrum: what is the delivery process?

If an organization is more mature and as fully embraced continuous deployment then Scrumban is an interesting option
If an organization is very rigid and still have long delivery times, you may not fully benefit from Scrumban. Scrum can be an option. But keep in mind that you may not be validating your feature with the real end-user