How can Scrum be *agile* if it enforces strict rules?

Question

So I just started to read into Scrum and did the (free) online assessment. Somehow I can't stop thinking that Scrum is a contradiction in itself. Even though the Scrum Guide never uses the word agile, it is often referred to as such:

Scrum is an iterative and incremental agile software development framework for managing product development (source)

However, solely the term agile to me at least has a very flexible and adaptive tone. Adapting to the situation, getting rid of fixed structures and rules. Scrum however has very rigid rules on how to work (Daily Scrum, Scrum Review, Team size etc.). Isn't that somehow a contradiction?

Answer 1

Scrum works well as a starting point. From the Scrum Guide:

although implementing only parts of Scrum is possible, the result is not Scrum.

There are a few takeaways from this. Notably:

1. Scrum itself is immutable. If you're being fully Agile, you likely cannot do (true) Scrum (all the time).
2. It is possible (and frequently a good idea) to only implement parts of Scrum. "Scrumban" is a common example of this. Just because this is 'not Scrum' does not mean it is bad.

Scrum is a framework. Like any framework, it is a tool. And like any tool, its worth comes from knowing how, when, and if to employ it.

Rigidly following Scrum, no matter what, is antithetical to Agile.

Using it as appropriate based on the situation is not.

---

EDIT: I should note that the above is from a theoretical viewpoint (which is what I believe the OP was asking for) and therefore is working under the assumption that the Team has already matured and is otherwise being productive with Agile practices. An "ideal", if you will.

An approach I've frequently seen suggested is for a Team just starting out with Agile/Scrum to begin by following everything by the book, strictly to the letter. Then, as the Team grows used to the process (and begins to understand it), they start to take more and more ownership of the process. Until, finally, once the Team fully understands the 'why's behind the process, they are given free reign to modify it as needed to fit their organization.

For what can happen if this 'customization' stage is attempted too early, see We Tried Baseball and It Didn't Work.

Answer 2

(bold emphasis mine)

However, solely the term Agile to me at least has a very flexible and adaptive tone.

You are taking a specific term and applying your subjective definition.

1. There is no Agile(tm)^* methodology or framework since it is a philosophy of 4 values and 12 principles.
2. Not having any structure is known as "cowboy" coding/agile and results in many of the same issues as traditional, Taylor-ist, project management.
3. The Scrum framework is one of the foundations for the Manifesto for Agile Software Development.
4. Misunderstandings and ignorance continually propagate such misinformation.

I just started to read into Scrum and did the (free) online assessment.

What source?

Perhaps a chat would be beneficial.

^*Although Sarov changed the casing, the point remains valid and exemplifies a common misunderstanding.

ADDITIONALLY

As a framework and not a highly defined method, Scrum is very flexible and adaptable.

Scrum ... functions well as a container for other techniques, methodologies, and practices.

Focusing on self-organization allows the Scrum Team and Development Team to choose the techniques, tools, approaches, etc. that empower them to create a product of high value and quality.

Answer 3

How can any software development methodology be "agile", if the compiler/interpreter has strict rules about acceptable syntax? Since we live in a universe governed by pretty laws of physics, we have to accept that there will always be rules that we're stuck with. We cannot do "whatever we want", we innately accept certain restrictions to our abilities, and work within those restrictions to accomplish our goals and desires.

The goal is understanding what is most important and then putting focus on that. The Agile manifesto intentionally says that the items on the left are more important than those on the right; not that the items on the right are undesirable.

Scrum, likewise, has a strong focus on what is important. Through experience, its creators have written down what they think is most important when developing certain types of products, and left the rest open for their users to fill in.

The key to using Scrum is to start by asking: "Is what I am trying to accomplish the same as what the creators of Scrum meant for it to accomplish, and do I value the same things they do?"

If the answer to both is yes, then you will find that Scrum isn't all that restrictive. It might have rigid rules (though not nearly as rigid as your compiler/interpreter), but those will not bother you much, because they happen to be rules that you should want to follow if you want to focus on what is important.

If the answer is not yes to both, you shouldn't be using Scrum, because you feel constricted. You will be focusing on different things as your rules are, which will lead to conflicts and confusion. This isn't a problem with Scrum not being Agile, but a problem of you using the wrong tool for the job at hand. Remember: people are more important than processes. I'm sure the creators of Scrum would agree with you that you shouldn't use a process that isn't helping you.

It's like cooking. Are you more Agile for throwing some random things in a pot and claiming it's food, or if you find the proper recipe for what you are trying to make and follow it? Only one of the two focuses on what is important. You can claim recipes aren't Agile because they are rigid, but if you focus on what matters, you'll learn soon enough that they are useful regardless. Even if, through experience, you realize the perfect cake requires two spoons of cinnamon instead of one. It's not like the writers are going to bust down your door to force you to follow it.

Answer 4

Rigidly following Scrum indefinitely is a bad idea and as you rightly point out, would not be Agile.

However, rigidly following Scrum until you understand it is a very good idea.

There are a lot of concepts in Scrum that take a while to understand and it is easy to fall in to the trap of adapting that which you are not used to or do not recognise the value of.

I suspect that part of the reason the Scrum Guide is written in such an inflexible way is that organisations often adapt Scrum from day one and if things go badly state that "Scrum has failed".

Answer 5

It is a great question.

I will try to make my answer short.

If you need to have a successful project then you need to have these meetings or to have all of the documents that substitute these meeting (and do not forget the communication part to distribute the documents).

Note:- documents include. Status reports and consolidating them, also sharing them Requirements and updating them and sharing. Management reporting. And many more documents and other practices.