Often it is used the term methodology relative to the Scrum framework. Some says that these terms: method, methodology, process frameworks are equivalent. Maybe that could be true in common language and maybe not in specific domains as software development in particular, or for process management in general.
For Scrum, it is better to listen the voice of its authors:
>>>
Ken, the Scrum Guide does not say who
defines the Sprint Goal. It also does not say who
selects the person to be Scrum Master. It ALSO does
not say who defines the super-important Sprint length
(it is limited to 4 weeks of less, but the Guide does
not say who decides the actual Sprint length.) In the
current version, exactly how the Product Owner is
selected is also somewhat vague. Question: Is Scrum prescriptive enough? If so, why so and if not, why not?
What a fine line we walk between a framework and a
methodology. A methodology tries to provide answers to
all situations, to be prescriptive and complete. In
doing so, of course, it would be so long and hard to
parse as to be useless. All contingencies can never
be posited or described. I’ve always erred on the
side of brevity – let intelligent people find out
the best approach, what works for them in their situation.
Then they are free to change the approach
when it is no longer appropriate.
The “black holes” that you describe above in
Scrum would be easy for me to fill. However, I’d be
filling them from my point of view, and the answers would
become a methodology. As I find floundering in
the holes, I try to fill them with Tips in the
Scrum Guide, blog entries, videos, and even talks.
But I resist making the Scrum framework prescriptive. I hate methodologies.
>>> (Interview with Ken Schwaber, Part1 - by Dan Mezick on Aug 26, 2010)
"I hate methodologies" ! - Scrum was not intended to provide all the answers and the practitioners should find the best approach in the context .
Anyway, the Scrum knowledge is organized in levels: the basic information could be find in the Scrum Guide. Considering the amount o (and not necessary the content) there is few information in the Scrum Guide, but - in the same time - it is the most generic. More advanced knowledge could be found in other artifacts of the two authors: books, courses or as Ken Schwaber says blogs, videos, talks. Of course, this information is less generic, and sometime are even very specific case studies.
Another aspect is the engineering part - not explicitly specified in the Scrum, but if you read again, you can find some tips about aspects that need strong engineering practices. Jeff Sutherland helped Kent Beck on XP - Extreme Programming creation and has used from the beginning the engineering practices that are part of XP as pair-programming, refactoring and TDD (or A-TDD).
Another aspect is the engineering part - not explicitly specified in the Scrum, but if you read again, you can find some tips about aspects that need strong engineering practices. Jeff Sutherland helped Kent Beck on XP - Extreme Programming creation and has used from the beginning the engineering practices that are part of XP as pair-programming, refactoring and TDD (or A-TDD).
Scrum is a lightweight framework, an Agile "method" that provide very generic aspects that helps to solve complex problems by offering some instruments to practically use the Inspect & Adapt principle. Anything else you will need to add to the process remain at your decision in the specific context and according to professions rules.
