The Non-Agile Aspects of Scrum

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 built to deliver this promise: the Product Backlog and the Sprint. My main complaint is with the way Sprints are designed and implemented. This is a paradox because I agree with the idea that features have to be built iteratively but I disagree with the way Sprints are defined within the Scrum framework.

The Sprint duration

Let's discuss 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 a 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 wait 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 or parts that are carried over to the next sprint.

This time-box constraint is getting arbitrary and disconnected from 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 organizations and give them a sense of false agility. What commonly happens is that a team spends half a day on a Friday to showcase the work and get feedback then starts a new Sprint 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 teams should deliver value to customers. The product owner is not a customer or an end user. He/She is an internal team member. The pushback 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 stakeholders will probably still be internal employees. Even the CTO/CEO or other managers are still not the real end users.

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

Framework VS Implementation

Ultimately Scrum is a framework, not a rigid process; it can be adapted to each organization's 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 of being agile. You may implement Scrum but it doesn't mean that you are really agile. It is at least important to understand and to be transparent about the process.
Also, I would not totally separate the framework and the implementation. Even if there will be better ways to implement Scrum, I still think that Scrum can be misleading in its principles.

Other options? Scrumban?

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

The part that I like the least is the Sprint. For this part, I think that Kanban gives a better way to follow the implementation. It also gives more control of the flow. You can add more columns to account for other steps of the process. Features are managed individually so some features can go through the validation process independently.

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

If an organization is more mature and has fully embraced continuous deployment, then Scrumban is an interesting option.
If an organization is very rigid and still has 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.