For example, the Scrum Guide states (emphasis mine):

The Scrum framework, as outlined herein, is immutable**. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

This appears to imply that to do Agile with Scrum on has to do all of it, and indeed I've seen Scrum proponents state that unless you do Scrum to the letter of the Guide you will not reap all the benefits it could provide you. I have also seen managers propose an incremental approach to adopting Scrum.

Is there some research showing how the diminishing returns curve behaves for adoption of Agile methodologies like Scrum?

Such a study would for example clarify how the likelihood of success your Agile project is impacted if you are attempting to do Scrum but you are not doing "Daily Scrum" vs not doing "Sprint Review" vs not doing "Sprint Retrospectives". Does such a study exists?

  • 1
    You can say whatever you like. What actual problem are you trying to solve though? Commented Sep 25, 2020 at 22:54
  • 1
    "Can we say that Agile is first of all flexibility of application and freedom of interpretation?" - flexibility and freedom for whom (you, or your manager)? "Remaining tied to the achievement of the objectives" - whose objectives (yours, or your manager's)? Your manager applying Agile in a rigid and fundamentalist fashion, and whose primary objectives are to subordinate you to a relation of power and profitable exploitation, appear to be entirely consistent with the flexible and goal-oriented tenets of Agile!
    – Steve
    Commented Sep 26, 2020 at 9:52
  • 1
    This is a rant, not a question.
    – Lie Ryan
    Commented Sep 27, 2020 at 6:21
  • I once attended a conference where Martin Fowlers spoke about the adoption of Agile methodologies. Long story short, adopting Agile and success might take 10y or more (estimation) for any company. It's then reasonable (and necessary) to make a progressive adoption and balance. It's not necessary to go all in or nothing.
    – Laiv
    Commented Oct 31, 2022 at 8:34

2 Answers 2


This may seem pedantic, but you cannot apply Agile to the letter, it is just a series of values and principles. There are probably two aspects of what you are referring to. First, there are frameworks and methodologies in the agile umbrella and there are some very strong arguments for following those to the letter (to start). Second, there is an obsession in many industries with best practices and the idea that saying what you will do and then following that no matter what is somehow a good thing (spoilers: it isn't).

Frameworks in Agile

Scrum, XP, Kanban, etc are all pre-packaged approaches to getting certain results. You don't have to use them, but they are a shortcut off of someone else's success (or really, thousands of someone elses). The catch is, you void the warranty if you don't practice it as intended. Think of it this way: I need a new shelf. I could build a shelf in my garage, but that would require that I buy a bunch of tools, learn carpentry, practice and fail many times. Instead, I'm going to IKEA and buying a shelf. Now, I get the shelf home and I want to put it together. Should I follow the instructions or just start putting screws in holes until I run out of both? Well, it's my shelf, so I don't have to follow the instructions, but if I put it together a different way and throw the stabilizing brace in the trash because it uses a flat-head screw and I only have a philips driver, can I really complain when the shelf breaks?

I hope every team that uses scrum or XP eventually grows past it, keeping the parts that work and retooling others to fit their unique context. But you do that after you've used the out-of-the-box option and really learned why it works like it does. Then you customize.

Best Practices

To borrow some phrasing from the cynefin model, best practices only work with clear, simple problem. Complicated problems have a whole bunch of "good" practices with each one being slightly better depending on your circumstances. If you get into complex problems, there are only emergent practices. Knowledge work falls almost entirely in complicated and complex spaces, meaning best practices aren't really applicable. That means no practice should be taken as obviously the right thing to do. Everything is up for review. I have no idea how organizations have become obsessed with best practices, but it's really problematic.

Now, to tie those together: If I'm using Kanban, I should be using WIP limits. Otherwise, I'm not using Kanban. A corvette with a motorcycle engine in it isn't a corvette. Does that negate my statement about best practices? No. the practice of WIP limits should be up for review. But if you've never used this before, you don't have the knowledge to effectively evaluate its effectiveness in your context. If you try using a little piece of it, it's hard to tell if it didn't work because it's a bad fit or because you didn't use the supporting practices alongside. So, you practice one of these frameworks in its entirety to learn how and why they work, then start challenging them.


Daniel's answer does an excellent job of addressing Agile as a set of values and principles and the strict application of Agile methodologies and frameworks. However, I'd expand on the other question - can we say that Agile is the flexibility of application and freedom of interpretation?

The core of Agile is adaptability and responsiveness to change. I don't think there's much freedom in the interpretation of the values and principles. Still, there are some. The Manifesto for Agile Software Development was written about 20 years ago and built on work that is easily 25-30 years old (the work on various methods predates the Manifesto by several years, if not more).

The heart of adaptability and responsiveness (agility) relates to the product and services being offered. However, being agile requires some level of flexibility in the process. This is reflected in the Manifesto itself - "We are uncovering better ways of developing software by doing it and helping others do it." The practices of retrospective and process improvement are the only practices called out in any of the values and principles of Agile Software Development.

If you look at a framework like Scrum, however, there can be some rigidity in the rules that can enable agility. I believe that it is difficult to argue that Scrum done right does not promote agility. Note that this does not mean that you must follow Scrum to be agile, but rather that practicing Scrum in the context of the Agile Software Development values and principles can promote agility. However, there are specific immutable rules of Scrum that constrain the team. The existence of these rules does not make Scrum not agile.

The most important aspect of Agile is adaptability to the context in which the team works - the requirements, the technology, the stakeholders. Since the essential principle is customer satisfaction through the delivery of software, you can have more rigid frameworks that still enable product or service adaptability. However, too much rigidity could make it more challenging to adapt. It's a balancing act.

  • Can we say that Agile is the flexibility of application and freedom of interpretation? -- Sort of. Part of the premise of Agile is that there are certain ideas that categorically do not work in many software development scenarios, like waterfall methodologies and hard date estimates of feature completion. Commented Sep 26, 2020 at 1:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.